How to stop designing things that won’t get built

After sitting down and whiteboarding things out with your product manager and a few engineers, you can’t wait to start cranking away on a new design.

You spend hours designing and tweaking and wholeheartedly believing “Users will love this!”

And then your designs never make it anywhere.

That feeling sucks, but it’s also part of the game. It’s the life of a designer. But throughout my time at RunKeeper and now at Drift, I’ve developed a system to help make sure this doesn’t happen—and to soften the blow when it does.

I call it the 40/40/20 method, and it’s ideal for fast moving teams. It allows you to focus on the now while still looking out at the road ahead, which keeps you from wasting time on things that won’t ever be built.

I started doing things this way because I’ve experienced that scenario described above plenty of times—it’s tough to leave all your hard work on the engineering room floor.

Where the 40/40/20 method started

As a designer, I want to explore things fully and understand how things will build upon each other over time. Throw in some “delightful” moments for users to stumble upon.

But as a lone designer catering to 2 product teams, that’s not always feasible. Yes, my designs need to be thoughtful, but I also need to work at a pace that keeps 6 high-performing engineers moving.

Before I started using the 40/40/20 method, I had a process that was (unknowingly) more optimized for keeping our engineers busy rather than allowing us to quickly tackle the most important thing.

Our team would talk about an idea, and I’d go off to design the ideal version of it. Then when I showed it to my team, we’d strip things out one-by-one until the only thing left was a design I could’ve pulled together in an hour.

Bummer.

This left me constantly scrambling—jumping back and forth between teams, trying not to block anyone, and never really getting ahead. I needed to change my process.

“What feels like a trivial addition to you might be a pile of work for someone else.”

First thing I started doing was spending more time with our back-end team so I could understand what endpoints we had at our disposal, what things we could do with a little bit of work, and what things would require a lot of work to implement.

I needed to recognize that what feels like a trivial addition to me, is probably a pile of work for someone else.

After I had all that information, I would still design the ideal… but I broke down the file completely differently into 3 shippable parts:

• 40% — MVP. The highest impact must-haves. Thought through fully, documented fully, back end in place, ready to be passed off to front end for implementation.
• 40% — V2. The nice-to-haves. Mostly thought through. Might need a little back-end work. Ready to be documented whenever engineering is ready for it.
• 20% — Innovation. Sort of thought through. Could be ready for implementation with another 2–4 hours of design work. Probably requires some back-end time.

Here’s a real example with a recent conversation redesign we implemented, and how we broke it up:

Bucketing and designing things this way has worked wonders for a couple of reasons:

I’m only focusing on the “now,” but I can see the road ahead.
The beautiful thing about partially designing out those last 2 buckets is that I can stress test a design and have confidence it’s not going to break without spending too much time. Considering how things will scale helps me avoid designing us into a corner—and it saves us lots of engineering time in the long run.

“Consider how things will scale and avoid designing your team into a corner.”

I’m not wasting time on things we won’t build.
The most obvious benefit is that I’m not spending any extra time in that last 60% unless engineering tells me that we’re going to be ready for it. Usually we get through the second 40%, but not always. Sometimes we get to that last 20%, if we don’t have anything more important come up. In those moments,  it’s easy for me to jump back, tie up the loose ends, and go back to whatever next “big thing” I was working on.

The other major advantage to this?

I’m able to work on multiple “big things” at a time.
This last one is huge because as a small team,  speed is our advantage. This process allows me to work on major things for both teams intertwined with each other, but the nature of bucketing helps me keep focused on one milestone at a time. And that allows me to deliver more thoughtful work to both of my teams.

Here’s a recent example of this process at Drift:

The other thing I like about this process is it respects the limits on my attention span.  I’m most productive before lunch, so I try to divide my day into 4-hour blocks. In the morning I work on my “one big thing,” and in the afternoon I give my attention to “everything else.”

“Everything else” usually means going back to that last 60% on a previous project and documenting a few more days’ worth of work for that other team. Sometimes it means whiteboarding next week’s “big thing” with my PM so he can start planning. Whatever it is ,  it’s something that needs to get done—but it’s not the most important thing.

As our team grows, developing a process has been more and more important not only for my productivity, but for my sanity. And keeping sane means knowing I’m not throwing away huge chunks of my time on fruitless explorations.

I know this process will need to continually adapt and cater to the ever changing needs of the team.  But right now, it’s working.