Hello lovely design and tech leaders. Either you’re here because we sent you a link or you wandered here of your own accord.

If you have been following along you’ll know that our mission is to help you build an effective skills framework for your team, to help them grow at work. We want to save you a tonne of time and empower your team all at the same time.

If you haven’t done so yet you should check it out and join the waitlist! This post will go into more detail about how this first stage of our launch will work.

We’re aware that some of the below may mean Progression isn’t right for you right now. That’s absolutely fine, but if possible please do still give us feedback via our chat bubble, Twitter or by email so we can learn what you need that you’re not getting.

If you’ve read everything and are ready to go, just let us know (hello@makegrow.co) and we’ll set the wheels in motion.

FAQs

We’ve heard a few of the same questions when talking to people about Progression, the alpha program and how to get involved. Let’s get some of these babies answered!

I’ve been staring at my spreadsheet and dreaming of Gin. Why use Progression?

You’re right. Our research shows that Gin is significantly more fun than spreadsheets. But here’s the point.

Designers are in more demand than ever before, and losing a designer (or engineer, researcher etc.) can cost over 40% of their salary to replace. Your designers, to stay with you, need to feel like they’re valued at the company and growing professionally. You need a way to do that. But we know from experience that setting up and maintaining a progression framework can be pretty soul-destroying.

So what is Progression?

Through personal experience and months of conversations and research, we can see that helping a team to grow requires a couple of things:

1. A map: In the form of a well written, objective and granular rubric, to ensure that they don’t need clarification from you to be able to make progress. If they’re left staring at your words wondering ‘what does that really mean?’ they’re not going to be able to make progress autonomously.
2. A bike (or scooter, or whatever): A spreadsheet alone isn’t enough. Not even close. Your framework is a product, not a project. The process needs constant love and attention to avoid your hard-won rubric being lost in the sands of Google Drive. That means removing yourself from the process, it means giving people visibility. Otherwise you’re adding to your workload, and none of us need something else on the to-do list.
3. Trust: You need to prove, repeatedly, that if people do the things you have asked of them then they will be justly rewarded. Hard to do when some people’s work is more visible than others, and some people are greedy with your time while others never make a fuss. A data layer would help you to be fairer and more systematic with your rewards.

That’s what we want to help you solve.

We want to give you quite literally hundreds of hours back (ever written one of these?) while helping you to empower your team and get them excited about growing at work.

This problem is really hard to solve, but we’re pretty much the only people trying to solve it right now. We would love to have you on the journey with us.

What’s in the Alpha?

As an Alpha team, from day one you’ll have the ability to:

• Use our carefully written content or your own (or a mixture!) to build a detailed interactive progression framework for designers, researchers and content designers. (Non-design team? Keep scrolling)
• Browse our career ladder templates and add them to your team, or build your own from scratch. We can help you decide how many levels you need, or you can recreate your existing spreadsheet of dreams. (we even have some of the well known open source frameworks from progression.fyi set up for you)
• Invite your team, assign them to positions and give them access to the skills they need to grow
• Create public skills to share with the community of teams using the framework.
• Chat to us about the best way to set up your team.

What level of support will I get?

We have a slack channel which we’re on every day. I’m also personally very happy jumping into calls or chats to help set up, and learning is priority number one so we’ll do as much 1–1 as we can. That said, our response times will vary — we don’t have a dedicated support team yet.

How big is the team?

Currently there are two of us working on the product (myself and Neil), with a third (very talented designer and UX instructor Austin) supporting on some offline stuff too. We’re self-funded right now with no immediate plans to raise money, so our focus is on building a product that is really valuable, not growing customers exponentially. With two of us able to ship code and two designers on the team, we should have all bases covered for the short term.

How long is the alpha program?

We think we’ll run this for three months. What that means is we’ll freeze pricing, carefully limit numbers (and even hand-pick teams) and offer a very high-touch service to ensure that you’re succeeding and we’re learning what works and what doesn’t. This timescale may change as we learn.

Can I use it for a non-design team?

Theoretically yes, and if that’s a hard blocker to you using it at all we’ll happily get you going. The library of content is set up best for design disciplines right now though, and we won’t be able to fully support non-design content at this stage so consider that risk.

Can I share my framework publically?

Not at launch, but we have big plans for not only allowing you to share your framework, but use it as a core component of your hiring strategy. We’d love to understand more about what you need, so please do tell us.

I’m on the waitlist but I need this yesterday. Can I jump the queue?

If you’re willing to pay, keen to give good honest feedback and are comfortable using early stage software (with a couple of bugs), then get in touch. For the right teams we’ll happily fast-track you.

Is this an HR tool?

Good question. Short answer: we don’t think so.

Why’s that? Well, when was the last time you enjoyed using an HR tool as a member of a team (not as a manager)? The only way we believe this can work is if everyone is getting value, and typical HR tools are bought with pure efficiency in mind.

Sure the cost may come out of your HR budget and it may be measured on HR-type metrics like retention and satisfaction, but our mission is actually to help designers (and everyone in tech) to grow. Progression should be a positive, empowering tool for everyone in a team, not just something for companies to weaponize. This is heavily reflected in our future roadmap and really excites us.

With that in mind, our perfect customer is whoever runs the design team. If you’re in a ‘people’ team we still like you, but please bring your nearest design leader along with you.

Pricing

First of all, Brass Tacks.

Pricing for the Progression Alpha is very simple: for the first ten people in your team, we’re charging $39 (£29) per month, total. That’s for every feature and all the support we can provide.

But we’re a big team and it has to be fair!

If you have more than ten on your team, that’s great too. We have pricing plans for larger teams — and several large teams using Progression .

However we don’t want to overwhelm ourselves at this early stage with loads of big teams with complex requirements and we know that your first few days of setting up will be a solo journey anyway. If you love what we’re doing we’ll be only too glad to ramp you up when you’re ready.

Why isn’t it free?

1. We can’t afford to not charge — we aren’t raising money and we fully believe in building a business rather than an expensive gamble (for more strong opinions on VC feel free to ask) so starting to charge at this stage is how we can become sustainable.
2. Related: We need to know that this is a problem that people want to pay for, and we want to know who those people are. Confusing noise from free users may mean we bark up the wrong proverbial tree!

Will I get grandfathered (keep the same pricing) afterwards?

That’s absolutely the goal — as mentioned above we’re self-funded so we’ll need to ensure that grandfathering is sustainable for us, but regardless, being part of the product this early will offer you lower prices and more access and influence over the roadmap than at any other stage.

Can we cancel if it’s not for us?

Of course. We will try to understand and fix what’s not working for you, but you can leave at any time and we’ll work out a refund if that’s what you want.

We really believe that Progression is the only way to get out from under your spreadsheets and start truly supporting your team’s growth, creating happier more engaged people with better careers. We can’t wait to show you how it works and what we have in store.

That’s it! If you have more questions please ask and we’ll give you an answer and add them to this document.

Progression Alpha: FAQ’s and pricing was originally published in Progression HQ (retired) on Medium, where people are continuing the conversation by highlighting and responding to this story.

In these short months, I’ve built a lot, learned a lot, and am now excited to move onto the next stage of product development (and the company’s evolution) by opening up the official Progression alpha program.

The last three months have seen pilot customers of the static Progression Pack product go through team structure organising, team workshops, design assessments (sometimes several times), level and expectation adjustment and ultimately more clarity over the skills in their teams.

I’m hugely excited by and proud of the progress to this point, and hearing from early users has in part validated that there’s a problem here, and that it’s valuable to solve.

However, it’s also been a time of huge (and often painful) learning about where Progression Pack falls short, and what needs to exist to truly solve these problems for designers, design teams and ultimately all makers in tech.

Many of these problems are through poor design or understanding of team dynamics (my bad) but a whole load are also unavoidable technical obstacles, brought on by the fact that v0.1 is self hosted and single purchase.

I’ll take a separate post to elucidate my early product learnings, but here are a few of the technical limitations of Progression Pack, which I knew about but have reared their collective heads earlier than planned.

• Customers have to self-host, which requires signing up to three third-party platforms (Github, Airtable and Netlify). All excellent services, but the overhead of managing the spider's web of interconnected data and dependencies makes it very hard to bug-fix and crazy complicated to get going.
• All the data lives in Airtable. This has been an incredible way to test the product, but as each customer has their own clone of the Airtable base, there are almost unlimited opportunities to break the product with anything from empty rows to changing column names. Some of this brittleness I could undoubtedly design out, but some more guardrails would be ideal.
• Related: every time I want to update content, I have to do it individually for every customer. Not only is this labour intensive and completely unscalable, but the possibility for human copy-paste error is large, and I get no version history which means the ground would have to change under people’s feet. Not good.
• Zero auth out of the box. It’s not difficult to implement auth on top of the platform, but it feels like table stakes to be able to securely sign people in.
• I can’t charge anything other than upfront. As I’m giving the content away on day 1, a monthly plan makes no sense — after all, you could cancel on day 2 and still have everything. I also can’t easily scale billing as teams scale (Facebook could pay the same as a 3-designer startup). Most importantly, I can’t offer a free trial period, which I’ve realised is essential when introducing a new SaaS product category to market.
• It’s hard for me to automate transactional events (emails, push, slack messages etc.) — a bit of a no brainer for a product like mine.
• I can’t open the platform up to individual designers. This is a big goal of mine, and for several reasons, it would make no sense to introduce a second product as it stands.

There are actually many more reasons than this, but you get the point.

So, what am I doing about it?

Introducing Progression

Clearly, Progression Pack needs a complete rethink.

So I’ve decided to bite the bullet and am currently building the next version of the product. It won’t have everything, but I’m hoping to have a basic product available in the next month or so, and after getting my first few customers onboard, I’ll be drip-feeding the alpha waiting list onto the product for more feedback.

I’m also dropping the word ‘pack’ — Progression is a better name for a tool that can grow as your team does. (I’ve been playing with a few other names, but I figured this is the easiest change to make, and I have a tendency to boil the ocean and buy most of the domains on the internet when in this mode, so I’m forcing a choice.)

So, if you’re currently trying to scale a design team with nothing that answers ‘what does ‘good’ look like?’, do sign up on progressionapp.com. I can’t wait to hear more, and show you what I’m working on.

Jonny Burch is the founder of Make and Grow. You can find him on Twitter, Instagram, Twitch and pretty much anywhere else as @jonnyburch.

Progression update: From pilot to alpha was originally published in Progression HQ (retired) on Medium, where people are continuing the conversation by highlighting and responding to this story.

How do I make sure my product serves its end user?

In building something completely new, in an underserved market, with no existing products to compare to, the possibilities are endless. Doing it on your own compounds the problem — deciding which opinions to have and which directions to go with your product can become paralysing (believe me).

So as a designer by trade, my instinct is to always set some principles by which to work. Those should be born directly from problems with existing solutions or needs I’m hearing every day.

In looking to understand how existing progression frameworks work, studying several dozen and talking to the folks who created them, I’ve developed a set of guiding design principles for the framework I’m building at Progression Pack.

Some frameworks I’ve seen achieve some, or even most of these items. I don’t think any of them achieve all six.

If I achieve all six design principles, I believe that this framework can be useful to a team of any reasonable size and adaptable enough to grow with that team.

It will serve the end users — the makers who need to feel value and momentum in their careers, as well as solving problems for their managers by giving them a vital tool in their every day work and saving them a bunch of time.

I’m building Progression Pack in the open, so my principles are open. Here they are.

1. Not replacing managers, just making their lives better

Your relationship with your manager is your most important one — as the old adage goes, people leave people not companies.

I recognise the value of a good manager, from candid and constructive feedback-giver to your biggest champion. The best managers are mentors and lifelong friends.

What I build shouldn’t be aimed at replacing that vital manager role. It should instead allow managers to be better by freeing up their time and giving them more and better data, so they can focus on the things that only humans can do — talk, understand, support and empathise.

2. Everyone has somewhere to go — even at the most senior levels

Picture the scenario: you’ve got to ‘senior designer’. The only person more senior than you is your manager. You have two options: leave and look for a bigger company, more pay or a more senior title somewhere else, or wait it out and hope they leave.

Neither is a good option. Wouldn’t it be nice if you did still have goals to aim at — perhaps not linked to title, but rewarded in other ways.

As that manager, even though your manager is a non designer and there’s no more senior place for you to get to, you should still have goals.

What I build shouldn’t allow team size or org structure to define where the path ends, for anyone. Learning is for life.

3. Allow people to develop at what they’re best at

‘Hey, I know you really want to go deep on prototyping but this manager position just opened up and this is the only way you’re going to get ahead.’

This is one of the quickest ways to not only lose a very valuable contributor to your output by moving them into management, but push them out of the door when they lose energy every day doing a job they didn’t sign up for.

What I build shouldn’t have defaults which force people to change their job description to grow. Growth should be a trellis, not a ladder*.

4. Scale levels without moving goalposts

You’re working hard, hustling and shipping great work. One level above you is Lead Designer. One more project and maybe you’ll be up for it.

Oh wait, because the team has grown, a few more levels have been slotted in between. Now you’ve got to get three promotions to get where you thought you nearly were.

It wasn’t clear to you before how far you were from lead, and now it’s clear that you’re not getting there any time soon. That LinkedIn message with a Lead Designer job title is looking more interesting. And why shouldn’t you take it?

What I build by default shouldn’t allow new roles and titles to change where people stand. It should be absolutely clear not just how many levels there are, but proportionately what skills go into getting there.

5. No room for ambiguity

Those conversations where you think you’ve achieved a milestone, but it turns out that your manager actually was thinking of something different? Something bigger, more impressive? Not fair. You worked hard towards that milestone, and now it’s like you’re back to square one.

What I build should by default be unambiguous in its expectations on people. Everyone should agree on what has and hasn’t been achieved.

6. Keep it do-able

How are you meant to keep all eight improvement areas in your head, especially when so many of them are dependent on the right project or opportunity? No wonder that goal-setting can be overwhelming and difficult.

The reason so many of the current spreadsheet-based implementations fall down is the sheer size and complexity of them. Achieving one thing at any one time is hard, we can’t be expected to be simultaneously growing in 12 different directions.

The challenge is that anything too reductive will lose the necessary detail to solve the goal above. So that complexity needs to be abstracted away.

Clarity of purpose and a focus on small, achievable goals in a few areas will mean less context switching and more measurable progress.

What I build should be simple and focused for the end user.

Do these problems feel familiar? Are you interested in learning more about Progression Pack?

Head over to progressionpack.com and sign up for updates, chat to me using the chat bubble, or email me at jonny@makegrow.co.

*Credit: Org Design for Design Orgs

Building Progression Pack: The importance of design principles was originally published in Progression HQ (retired) on Medium, where people are continuing the conversation by highlighting and responding to this story.

This was originally published at jonnyburch.com

Back in February, I left my job as a design lead at Deliveroo to start something new. Two and a half years seeing the product explode in popularity and company grow about 700%, after another three and a half helping to build a bank for children, had left me with ‘the bug’. It was time to build something again.

I had two fantastic co-founders in Siadhal and Shahriar, who I’d been friends with for a couple of years and had a shared passion for tech, products and startups. We’d worked together once before and enjoyed the experience, saying one day we’d get together on something new.

This was it. Having chatted about ideas for a long time beforehand we decided to get the band together for real.

The challenge was, we didn’t yet have a problem locked down.

We had ideas, plenty of them. Ideas are cheap. But we hadn’t yet landed on the one, a problem that we all wanted to commit to. But we were undeterred, we now had plenty of time to learn, research and make that decision, and some personal savings to give us a runway.

And we had a process.

Committing to building a startup around a single problem involves building your conviction in a number of areas.

1. First of all, you want to see that the problem exists, in some form. It may not be an incumbent inferior product — more a behaviour you’re seeing in the world. You want to chat to people exhibiting it (your future customer) and learn more about the nuance of the problem
2. You want to size the market. How many people have this problem right now? Are there other, similar problems you could solve too?
3. You want to know that you’re in a good place to solve that problem. Do you have domain expertise? A network? A secret bit of tech that gives you an unfair advantage?
4. Is now the right time to try? What social or technological tailwinds might you be able to ride?
5. You’ll want to imagine where this will lead you and make sure that this is a problem you can fall in love with, and stay in love with, for a good period of time.

Not all of these have to be a complete yes, but the last one really should be. If all else fails, it’s that that will keep you in the game. That’s why you chose this crazy, poorly paid, unpredictable life over a lovely pay check and a ping pong table. If you loved it, and tried it, you’ll have no regrets.

Now, I was given this advice by more than one very successful entrepreneur as we started.

Make sure you’re in love with the problem.

I believed that it would be possible for me to fall in love through our discovery process.

But in a complete democracy with no ‘problem’ locked down before inception, it’s that last one that seemed to be getting us. While we were very much aligned about some aspects of what we want to achieve as a company, it turned out we had subtly different areas of interest. I just couldn’t fall in love with the same problem as everyone else.

What that meant is we could all gather around an idea and riff on it for a while, even build something and iterate on it. But inevitably, when the first few experiments or data points didn’t point to a complete success, one of us may lose interest, start chatting about a different idea, take our foot off the gas. It turned out that person wasn’t totally sold on it anyway.

I’m putting it all down to a slight misalignment in our goals. I realised that, while I’m open to the idea of global scale, VC money and a monster business, it’s not my primary goal. I’m much more interested right now in finding out what kind of thing I want to work on.

So I’m taking a step back from our company to re-evaluate. I’m going to be venturing out on my own — not rushing to a problem right away but letting my mind wander, and wonder. I have a laundry list of problems I want to learn more about, and they aren’t going away. I’m ok to let one find me when it’s good and ready.

In the meantime I’m spending a bit of my week helping to build a design and product team at a fantastic startup, and am open to other *very* part time consulting. If that sounds like something for you, just get in touch.

Siadhal and Shahriar are cracking on, (I know, we still all sit together) and will undoubtedly crush it. Follow them (Siadhal) (Shahriar) on twitter for news.

This was originally published at jonnyburch.com. For more stuff like this, sign up to my newsletter (scroll to the bottom in the link above).

After nine years and literally thousands of happy memories, we’ve decided to formally shut ShellsuitZombie down.

ShellsuitZombie deservedly belongs to all of you, earned through early morning train journeys and evenings spent proof reading articles, through boozy pub sessions and Skype discussions. We’ve distributed tens of thousand of magazines that you’ve illustrated, designed and written for, we’ve run raucous events that you’ve organised, helped out at and cleaned up after, and we’ve published hundreds of online pieces which you’ve carved with your beautiful hands and minds.

We’re completely humbled by the amount of time, energy and creative thought you’ve all brought to this crazy idea — creating things that we couldn’t have dreamed of.

We’ve also created opportunities for hundreds of creative grads, enabled conversations between future collaborators and created serendipitous moments left right and centre. We hope that — through new friends and connections — you’ve also felt it was worth the effort. We know that there are lots of now successful, confident and impressive people that have come through the zombie doors at some point.

So why end it now?

We can all sense that SSZ has been limping along for a couple of years. The problem at the centre of it is time. We’re all growing, getting busier and finding the things we’re most passionate about and pursuing them. Which is really fucking awesome. That means less time for Zombie projects. And that’s ok. But SSZ at its best requires a serious chunk of time.

While there have been some epic efforts in the last couple of years, both online and in the latest issues of the magazine, the amount of stuff we’ve all done together has dropped off.

So we thought, rather than see it drop off even more we’d make the call.

Thanks to (in no particular order):

Ellie, James, Rob, Karen, Ross, you started it all. Everyone at D&AD back in the day, who let us run silly events at your less silly events. Jo C for an epic effort at Boxpark, Steve from Stack for supporting us and talking about us, anyone we’ve interviewed or who’s written or created something for one of our issues, all the myriad folk who contributed over five hundred blog posts and features, anyone who came along to help run one of our chaotic nights. Lee Denny for giving a space at his magical festival for us to play Garage music out of a van, there must be more…

All the ‘fresh meat’ generation of zombies — it’s great to see what everyone is up to and has gone on to do. And special thanks to Matt Becki Sam and Alex for heroic efforts through the years. We really did some shit together.

Long live ShellsuitZombie.

Jonny and Andrew

How we’re using Experience Principles to keep each other honest at Deliveroo.

In the last three years, the Deliveroo Content, Research and Design team has grown from a single designer to a team of nearly thirty designers, researchers and content writers, with no signs of stopping any time soon. (We’re hiring by the way.)

This is great. It means we can support the product teams as they grow (over 250 people now work in our product and tech organisation), we have capacity and time to do better work, and we can also think about what processes, rituals and artifacts we need as we grow.

We’ve grown fast, which means change in our team culture has happened fast too. We’re very proud of the (incredible) people in the team, but sometimes you need more than talent when there are so many moving parts and everyone is embedded in their own product team and project, with less time to all hang out.

We’re doing a few things to help us grow well — including setting up a UI infrastructure team to work on our design systems, constantly iterating on how we critique and review work and improving our working patterns and team rituals. But sometimes even these are hard to share across our disciplines.

The other thing I notice– helping the rest of the business understand what we as designers, researchers and writers actually do is a constant task.

I get asked the question ‘what does the product design team work on’ more often than I would have expected — despite the fact that our partners in the rest of the business are very smart and technically savvy. The fact is, from the outside it’s hard to understand how we think and what we’re up to every day.

While the whole company doesn’t need to know exactly how the magic happens, the basic principles of user-centred design, empathy and designing usable interfaces would allow for design thinking to permeate further into the company culture and also allow us to share a lexicon when talking about our work.

We wanted to align ourselves and educate those around us, so we started talking about principles — if we can’t explain everything we do, we can at least tell people some of the things that we believe.

Enter our Experience Principles

Our goals for these principles were two-fold:

• Allow us as a team to have better discussions about the quality of our output, and easily bring new joiners to the same shared conversations.
• Introduce conversations about user needs, scaleable design and things we care about to the product teams and wider organisation.

After hours post it note-ing and whiteboarding (and some good advice from Stanley Wood, thank you sir) we ended up with a list of seven principles that fitted the following criteria:

1. Feel uniquely ours
   While it would have been tricky to write a set of good experience principles that no-one has ever used before, we wanted to make sure our tone of voice was clear in writing them.
2. Feel directly actionable by anyone, even outside our team
   Our dream is that these principles are used in rooms that we’re not in. That means engineers, product managers, customer support folks, even up to our CEO, can find something they can use in them.
3. Are general to all of our disciplines
   Our team (Content, Research and Design, acronym CRD) is made up of three equal but different disciplines. Going deep on principles that primarily related to only UI, or research techniques, wouldn’t have been usable to all three.
4. Are opinionated (you could argue against them)
   It’s easy to write principles like ‘make things usable’ — there is no clear sacrifice to doing this, it’s just good practice. We wanted our principles to be opinionated and have some cost tradeoff, a proxy for which we decided was that we could point to exceptional companies who had chosen not to demonstrate them. This turned out to be really hard.

Some were about being able to work more efficiently at scale, some were about ensuring we were designing for the right people, some were more about our internal working culture. We whittled these further, down to four immutable and clearly distinctive ideals.

What was interesting was that what we ended up with, we were confident we were already doing in some capacity — but in articulating them we could double down on them. Still, some would ask — if they’re so obvious and everyone already agrees, why have them at all?

The answer is — these things aren’t always obvious to everyone. Designers, researchers and UX writers, and even other people in a product team, may read them and see them as no-brainers, but by being first principles-based and general, we can educate others too.

By stating them we can double down on them ourselves and point at them to explain the things we say, and as we grow, new people on the team can read them and understand our beliefs immediately.

There are only four so far, which has the added advantage of meaning I can remember them all without looking. We may add more in the future, or update these, but for now we’ve agreed on four things. That was hard enough.

Below these sit team and discipline specific principles, which are much more focused on single user groups and execution. Teams can add and use those as they wish, but these four are enough for the business as a whole to get on board with what we’re up to and how we think.

We’re at the start of this journey — building one of the pillars of our plans to scale design. Watch this space to see how these go!

At Deliveroo Design Team we’re hiring! Check out our website, deliveroo.design, and follow us on twitter to see all our waffles and doodahs.

Go out and empathise! was originally published in Deliveroo Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last four years, Deliveroo has grown from its first delivery to a food delivery service spanning 12 countries, 130+ cities with 20,000+ restaurants and 30,000+ riders delivering restaurant quality food to a lot of hungry people every week.

At Deliveroo Design we’re constantly looking for ways to improve how we work. As the team and the surface area of our product has grown, our design team has had to grow too. We’re now nearly 20 people, including 5 user researchers. As we grow, we need to become more efficient and be able to deliver better experiences, not just more of them.

Tooling Up

We’ve always explored new tools early. From insight gathering with NomNom, to version control using first git and now Abstract, we’re constantly looking for ways to make ourselves better, smarter, more efficient, more data driven. So it was inevitable that we would look to Framer — which we believe to be the most powerful and versatile prototyping tool on the market — to describe and explore how our interactions and interfaces work.

Our team is made up of designers with mixed backgrounds. Some know Framer and have coding ability. Others are comfortable with Javascript, but have never used Framer before. A fair number have played with Framer before but never ‘in production’, while the rest are starting from scratch.

We would like to get to the point where new people joining our team ramp up on Framer as part of their first month, and the wider company looks to a prototype as the best way to explain any complex problem they want to solve.

Making Framer an intrinsic part of our workflow

We’re now into our first month with Framer Enterprise. We kicked off with a fantastic workshop with two of the Framer UX engineers, who flew over from Amsterdam to take us through some basic interactions as a team. Now we’re all working it out, line by line.

How is this translating into real product work? Honestly, slowly. People have their tools of choice already, so making a conscious decision to open Framer over something familiar is hard, especially when you’re under time pressure.

But we’re seeing things happening already. We’ve already used Framer prototypes for some simple projects, and our CTO recently asked for a Framer prototype to help understand one of our particularly tricky product problems. That’s buy-in!

The Future

Soon we’ll get to the exciting stuff. Hooking up data so we can test prototypes based on where people actually live. Connecting a database so we can react to what people do and throw in curveballs and edge-cases. Re-using elements and curves and sharing code so projects get started more quickly. Version control and code review, so everyone learns at the same time.

That’s how you move fast when you’re 30, 60, 90 designers and researchers. As that’s looking a real possibility for us at some point, we need to lay the groundwork now. We believe Framer is a huge part of that.

We hope to have a meaty Framer-led project to show off very soon. Watch this space.

We’re hiring designers and Framer knowledge is a real bonus. So if you fancy working for one of the fastest growing companies in Europe, get in touch or find us at a Framer meetup in London soon!

You can also follow the Deliveroo Design Team on Medium for more about how we work and what we’re up to.

Deliveroo x Framer: One Month In was originally published in Framer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Are you having a hard time getting your designs built? Does it feel like everything’s a priority? Are your product owners too obsessed with numbers, and don’t value the quality of the experience?

At Deliveroo we’re incredibly lucky to have not only a great design team, but also a fantastic set of product people who value what we do. However that doesn’t mean shipping ‘good design’ is always easy.

Whether you’re in a big company or a small one, early stage or decades old, at some point you’re going to experience the frustration of feeling like you can’t ship good work.

You may already be feeling it. Blocked at every turn, forced to whittle down your projects into an also-ran ‘MVP’. The prototypes may be piling up, in tickets or folders, never to see the light of day.

As product designers, our job is to create a good user experience. But no-one else respects that right?

(hint: Wrong.)

It turns out it takes more than a good designer to ship good design. You need the support of your decision maker (whether that’s within a sprint team or your CEO) as well as a shared understanding with engineers and other colleagues in your company.

It also turns out good design is about more than a great prototype.

What are the requirements of good design?

Julie Zhuo, VP design at Facebook Design, published a great sketch listing the ‘Ambition heirarchy of Designers’, which speaks well to what we designers value.

Defining good design is tricky, but there are some qualities that are broadly considered important.

1. Good design is a pretty thing
   Sure, that’s probably what my mother would say. After all, if it looks good, ship it, right? Who cares whether it does anything useful.
2. Good design is powerful features
   OK, clearly it’s important for your thing to do stuff. Perhaps the more stuff your thing can do, the better it is? Let’s add some stuff, and more stuff.
3. Good design is a logical and usable experience
   Yeah, this one is important. After all, if people can’t work out how to do the stuff, the stuff is pretty much useless. Let’s make it logical and usable.

But there’s one more, critical requirement.

Good design needs to solve a problem.

Sounds obvious, and Julie alongside many other people more qualified than myself have written about it, but fundamentally we’re problem solvers. Only by proving that we can solve actual business or user problems can we gain the influence we so desire.

Stanley Wood, Design Director at Spotify and writer of Design doesn’t scale told me that one thing he drills into the Spotify design team is the importance of selling the problem.

‘Sell the problem, find a solution’ — Stanley Wood

This strikes to the heart of influencing people at your organisation. Get everyone agreed that the problem you want to solve exists and they’ll buy in to the solution you come up with much more easily.

Ok, now that’s sorted, we need to sell the problem. But it’s still really hard to get through to people!

To sell the problem you need to work out what the problem is, right? It takes research, data, space to think. For those precious resources, you need to persuade people that they’re worth spending time on.

You need to be able to have good conversations about your work and what’s important. So lets run through a couple of the bad conversations you may be familiar with when persuading people that a problem exists…

(For brevity I’ve decided to call our designer protagonist ‘Sam’ and our Product Owner ‘Lucy’)

‘No time for exploration, design the button’
Lucy has no respect for the value of design, and is short-sightedly papering over the cracks.

Or: There’s massive internal stakeholder pressure or the need to unblock another business unit. This is a tactical solution and Sam shouldn’t be so dogmatic.

‘Not convinced that’s the problem, design the button’
Lucy, who has so far had to rely on her own judgement, or define the problem herself, may not trust someone else to help.

Or: Sam may not have put together a convincing enough argument.

‘It doesn’t help our goals’
Lucy only cares about the numbers — good UX can’t be measured quantitatively!

Or: Sam may be off finding ways to improve the user experience without taking into account the business needs. Lucy is reporting on solving different problems, Sam needs to help her out.

Prescriptive solution, despite not solving the problem
Lucy thinks she’s the designer, and designers just provide the polish.

Or: Sam didn’t involve Lucy enough in the design process.

Let’s be better. Let’s lead from within.

These are tough conversations that we all go through from time to time.

But the reason they’re tough is not because everyone’s an asshole. They’re tough because your incentives and values aren’t aligned with the people you’re trying to convince. They’re your fault as much as anyone else’s.

It’s too easy in these situations to think ‘this person isn’t a designer, they don’t get my vision, this is design by committee’.

These are also the very same moments in which you can become an ally, influence and most effectively change minds. After all, assuming you’re working with people who want the best for your company, you’re all after the same thing.

This presents a golden opportunity, not just to be able to ship better work, but also be more trusted and influence a wider sphere of people. Some call this ‘leading from within’.

Get people on your side and suddenly you’ll find yourself consulted on decisions, invited to meetings. People will ask to work with you.

Leading from within comes down to communication and empathy. Be excellent at communicating and empathetic to the people you’re talking to, and you’ll be able to affect change– maybe not the first time but gradually more and more. (Yeah, it requires patience too).

Ok, so what are these 4 principles?

I’ve seen all of these things work — but they’re easier said than done (and I’m no master). They won’t all be appropriate for all situations, and they equally aren’t a silver bullet. But they should help.

Principle One: Make People Look Good

Dave from sales, PM Lucy, and in fact everyone else in the organisation, is judged on different criteria to you. Work out what they need to be successful at their job and use that understanding to focus your effort and arguments on things they’ll care about.

There may also be other factors — like how your company grew, which may explain biases. For example if you’re the first designer, someone was doing and maybe enjoying your job before you. Be sensitive to that.

Principle Two: Tell a good story

Often the complexities of the problem are difficult, you need to distill them into a compelling and brief presentation. Think deeply about the most appropriate medium for this — and again what people respond to best. I’ve worked with people who just don’t get it until they see a tappable prototype, and others who need a slideshow.

Be cognisant of how you present your data and, honestly, think about narrative structure.

• What’s the beginning, middle and end of your story?
• What tricky questions will come up, and how do you build them into the presentation?
• What one thing will blow Lucy’s hair back?

Principle Three: Be Pragmatic, not Dogmatic

You’re going to be wrong sometimes. In fact you should aim to be wrong a bunch — if you’re not, then you’re not questioning things enough.

Being wrong well, or having ‘Strong opinions weakly held’ is crucial in building a rapport with co-workers, and you’ll avoid the whole ‘I don’t want to question this because I don’t want an argument today’ reputation that is so counter-productive.

Back down, and be open to a counter argument.

Principle Four: Quit whining, Own the problem

If you think something is important, but you just can’t persuade someone to work on it, it’s time to get creative. After all, you’re still judged on the quality of the experience.

• Is there something you can do to further prove the value of your idea? (User research, examples in other industries/products)
• Is there another product team or part of the business for whom this makes more sense to work on?
• Longer term, can you build this into a future roadmap item or initiative?
• Is there something smaller you can do to make progress?

Fundamentally, throwing your hands in the air and saying it’s impossible isn’t going to do anyone any good, least of all yourself. Tackle the challenge head on.

In Summary

It’s not enough to just be a good designer, at least not in a fast-moving product environment. You need a bunch of soft skills to get things done.

You need to be a salesperson, a psychologist, a storyteller and a glutton for punishment.

Managing ‘up and out’ is important for anyone, but designers tend to find it hard due to the nature of what we do — our craft produces outputs that are subjective and easy to critique.

This isn’t just true of designers. To become influential and essential in your organisation, you need to get close to the people. Understand how to speak their language, and speak to the things they care about.

Good luck! It’s not easy, but the result will be a better product for everyone.

This article was adapted from my presentation on the Google stage at Slush 2016 in Helsinki. Thanks to Google Developers for inviting me to that. The fingerprints belong to my wife Karen — I stole them off our 2015 Christmas cards...

Please hit ‘Like’ or comment if you have something to add, I’d love to learn more about this from others. I’m also on twitter @jonnyburch, if you have a strong need for more retweets of goat pics.

Most importantly, the Deliveroo Design Team is hiring! Check us out at www.deliveroo.design and follow us on twitter at @deliveroodesign

4 principles for shipping good design when everything’s on fire 🔥 was originally published in Deliveroo Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s a funny thing, food. We talk about it all the time, it consumes anywhere between 40% and 100% of our waking thoughts, we socialise using it, and complain about it, and hide it from each other when we want it for ourselves. It directly dictates our mood, health, wellbeing and general ability to not die. Yet the subtleties of our gastronomical cravings remain little-understood.

Why is it that at 1am after a few pints of the amber nectar all I want is a big pot of hummus and some soft white bread? What makes insufferable social networking types feel the need to take more pictures of breakfast than any other meal of the day? What socio-economic factors lead one to ‘spiralize™’?

These are the kinds of problems the design boffins at Deliveroo HQ are aiming to answer. We don’t just sit around all day eating premium burgers and nudging pixels around (that’s merely 90% of it). No no. We’re constantly devising systems, algorithms and cunning pie charts to help us understand more about what you eat, when you eat it, and why it tastes so goddamn good.

To this end, I’d like to share just one piece of research coming out of Deliveroo labs — I call it the C.U.M.F.I. — Completely Unvalidated Mood Food Indicator.

The C.U.M.F.I. aims to give us at Deliveroo insight into not only the kind of food you like generally (broad demographic segmentation) but also the micro-fluctuations in your food cravings that lead to the knee-jerk 3am Chicken Cottage (lager), or the sudden switch to low-fat vegan alternatives (you followed somebody new on Instagram). This way we can improve the food we offer to our loyal Deliveroo scoffers.

But first let’s go back to the root of the C.U.M.F.I — one of your average Management Consultants favourite tools. Myers Briggs, (or the MBTI personality test).

Many of you, learned readers, will have used the Myers Briggs personality test to discover the four letters that define your very being. Are you Introverted? Are you Judging? Tough shit, whatever you thought you are, you aren’t because Myers Briggs gave you four different letters. It told me I was Ron Weasley. Great.

This chart tells you what you are deep down, but I thought it might be interesting to create a similar chart but for food types. My magical tool would help you know, based on your social situation, your general propensity for grease and several other factors, what you should eat at that point in time. But first I had to define my axes.

Defining The Axes of Food

There are some general factors that will affect the food you choose on Deliveroo — price, for example, or how quickly it will get to you. The former is less interesting to me as I’m trying to avoid traditional demographic segmentation and the latter should always be as fast as possible on Deliveroo so isn’t a useful variable to plot.

There are some factors though, that are more about personality– they describe the mood and situation you may be in, regardless of the cost and convenience.

Factor 1: Are you a food snob?
Do you eat to be seen? Will you only eat something with a Michelin star, or are you happy with your local (as long as it’s clean and friendly)?

Factor 2: Are you eating alone or with others?
Be honest, how often would you cook a three course dinner on a Monday night for your GoT TV meal? We go to more effort and pick certain food types when we’re entertaining friends.

Factor 3: How healthy are you?
Do you know how to say the word quinoa, with confidence, in public? Or do you love the grease and you’d stuff a crust with anything?

Factor 4: How brave are you?
Do you eat what you know? Or will you go for the Hungarian cold fish stew? Do you see a restaurant experience as comfort food or a culinary adventure?

So with these factors in mind I can now plot them onto my grid.

I know. This looks pretty incomprehensible at this stage. So how about we define some of the food zones you could end up in at any point in time.

• Dirty is on the left, healthy on the right
• Alone is the top half, together is the bottom half
• As you get towards the centre, people are braver and more snobby (so the outsides are more familiar).

This means that the top left hand square UADF is generally reserved for meals you don’t want anyone to know about, in stark contrast to SAHB which you’ll sing from the rooftops.

In fact, it might help if we put some foods into these boxes to make it extra clear. Clearly these foods are subjective– one thing that we see every day is how much perception of a food type changes culturally across cities and countries.

I know what you’re thinking. Indeed, I reckon in one day I could tick 4–6 of these boxes off.

What we’re looking at here isn’t describing someone’s food personality for good — in fact hour by hour I’d be jumping around the board depending on my mood.

Mind Blown

Here’s the thing. Because the food you want is always based on your context, we can’t create traditional personality types here. Even the most ardent yoga-loving clean-living Spiralizer™ can fall off the wagon and nail a kebab, given enough time and alcohol. This is more of a ouija board of food sins, where we can watch ourselves tracking grimly from the bottom right with our post workout rabbit food all the way to the top left of doom, tinny in hand, stumbling into next door’s garden to throw the remains of our large Doner at their cat.

So how can we use this? Well, perhaps the C.U.M.F.I will help us at Deliveroo map our own users’ food habits. Maybe we can ask them to self-identify as one of these types before ordering, to better offer them what they want? Perhaps we can map the faintly disgusting eating habits of the average early twenties male and create a wildlife documentary? The world is our oyster (or kebab).

Knowing what people want and how best to give it to them is the most important job that we have. So even though the C.U.M.F.I is a bit silly, it’s rooted in a real need. When you’re hangry and want food NOW, every second that we can speed up your ordering experience by is vitally important. Winter is coming, you need sustenance.

Take the test!

You can find out where you stand by answering these four questions.

1. Are you feeling unfussy about the place you eat (U) or are you a food snob (S)?
2. Are you eating alone (A) or in a party/group (P)?
3. Are you after something dirty (D) or something healthy (H)?
4. Do you want something you’ve had before (F) or are you feeling a bit braver (B)?

This should give you four letters which may put you in a box on the C.U.M.F.I. Good luck and happy eating.

We’re hiring designers! Come and work with us at Deliveroo where we’re shaping the way people choose and eat food across the world. deliveroo.co.uk/careers

We know how Hangry you were last summer was originally published in Deliveroo Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last night Apple announced that Apple Pay was coming to the Web. The announcement was squashed between an updated Siri and tabs on your macOS windows in a jam packed keynote, blink and you’d have missed it.

But in the slide of partners for the launch of the feature, there we were! Deliveroo is one of the chosen few brands working with Apple in the UK (and then further afield) to offer Apple Pay to our Web users.

Jonny Burch ⛄ on Twitter

Second row, third from the right. Boom.https://twitter.com/terijyu/status/742413804022075392 ...

So why do we think this is so exciting?

The Web, here at Deliveroo, is our oldest platform. It’s a bit more creaky than the newer, shinier iOS and now Android apps, but a team of us, including a small bunch of militant ex Government Digital Service employees, believe strongly that when Web is given the tools it can strongly compete with the more sexy platforms of native apps.

We’re charged with turning Web into a platform that feels every bit as powerful and modern as our other consumer platforms, and – unfashionable as it may seem – we believe we can do it. The barriers to Web are lower for users anyway (no app installs, instant access from the most basic of links) – the experience of actually using it just needs to match the ease of finding it.

This move by Apple represents confidence in Web the likes of which we rarely see from the tech giants of the West coast – Facebook famously attempting then dropping HTML5 as their tech of choice for their own mobile apps a few years back. In a world where some of the biggest names in consumer tech barely (Spotify) or don’t (Uber*) have a web version of their products this is exciting to see.

What’s more, this technology will really help us. Nothing is more important, for your average vanilla e-commerce site, than a smooth checkout experience. For a site that deals almost exclusively with people who are hungry and expect food in as little as 10 minutes, that need is even more important.

I can’t go into detail about exactly what our plans are for our Apple Pay integration, but let’s just say that filling in forms, the bane of any mobile device user experience, may become a thing of the past. Completely.

It’s safe to say we’re excited about this. We’re excited about the Web. Soon you may see why.

Do you love the Web? We’re hiring product designers and engineers who believe, as we do, in the power of the internet. Go to https://deliveroo.co.uk/careers to get involved.

[*Correction (thanks Dave Ganly) — Uber does have a mobile web product. But for both Spotify and Uber (and many others) web seems to be a secondary consideration.]

Apple Pay on the Web: why we’re so excited about it. was originally published in Deliveroo Design on Medium, where people are continuing the conversation by highlighting and responding to this story.