A Sense of Where You Are
Another annoying essay on design process
The trouble with essays about design process is that they read like some sanctimonious twit regaling you with stories about their rosy life. I appreciate that you don’t want to hear that it takes organization to get things done. It’s all totally obvious, yet surprisingly hard to do day-to-day when you’d rather be learning Framer and coding a prototype. So I’ll try to keep this rooted in my direct experience.
The problem with simplicity
I used to assume that the product design process worked like this: Some people do some thinking; they ask me for some mocks; I draw the mocks; we code them, user-test them, and tweak them; and we launch the product.
In reality, when their request came, I’d usually be too busy on another project. By the time I could get started, we’d have to rush things. Then I’d show my mocks to people and we’d all argue over trivialities of the visual design. They’d be busy, they’d rush things, and we’d argue some more. The engineers I was working with would get fed up with arguing and just start building whatever they thought was best. Further arguments would ensue.
We’d try to settle those arguments with user testing. But we wouldn’t have a clear idea of what we were testing, the researchers would be busy, and we’d rush the tests. We’d end up with inconclusive evidence that we’d built the wrong thing. When the dust settled, I’d be like, “What happened — I thought you guys had a plan.” And they’d say, “Oh, we thought you had one!”
When team members felt like they were falling behind, or had no idea what should happen next, workable problems and differences of opinion began to seem insurmountable.
Misunderstandings, scope-creep, and blamestorms followed close behind. In most cases, a more realistic plan would have helped us avoid a lot of that pain.
It’ll take *how* long?
Eventually, I got better at working out how long a big project would take. There was still one problem: No one would believe me. I became a project management Cassandra. I could predict where the difficult arguments would come, but I couldn’t convince people to take steps to avoid them.
Few people want to view the design process in a realistic light—to admit that it’s messy and takes cooperation and compromise. They’d rather put their heads down, focus on their own work, and hope that someone else has a plan.
In an effort to get people to buy into more realistic timelines, I’ve worked to become analytical about the projects I’ve done and transparent about how long things really take. I don’t want to take away the fun of discovering your own meltdowns, but I do hope to offer some insight about where the time really goes — and why it’s worthwhile to anticipate some messiness.
Refining the process at Facebook
I joined Facebook as a designer during a time of especially rapid change. Products that used to be managed by a single designer were suddenly fragmenting into huge pieces of infrastructure, supported by hundreds of engineers and supporting millions of dollars of revenue.
Individual designers would now be responsible for overlapping pieces of a puzzle that together had to make a coherent product.
There was a lot of interest in finding best practices for keeping projects moving efficiently. I worked with a research partner and a small group of designers to understand how different teams and individuals were organizing themselves.
We came up with a best practice that wasn’t unlike what you read in most books or articles about design process. But our model allowed more time early in the process to collate research and requirements, brainstorm, test and reject ideas — essentially, everything it took to get from having a rough plan to having a good plan with broad cross-functional buy-in.
· Understand — Agree on the problem to be solved.
· Model — Narrow our thinking and describe the concept visually.
· Build — Engineering builds the product.
· Launch — Test and coordinate with marketing.
I noticed a hesitancy from product managers and engineering leads to accept this approach. They perceived a lot of overhead in the Understand phase — the early work we were trying to make room for. They thought they had the answers we needed, and that a good designer would turn it all into a good design, which they believed they would “know when they saw.”
So I set out to convince them that a less optimistic process would yield better results.
Proving the model
I find that people are more ready to believe me if I come at them with data. Fortunately, I already had much of the information I needed. Since becoming a design manager, I’d watched how different teams were working, and carefully documented what they were doing.
The team also keeps a running doc of status updates, with brief notes about key events in their projects over the previous week. I encourage people to keep these very short and to record only important events, rather than maintaining an exhaustive list of what‘s been done.
By analyzing these records, I was able to assemble a picture for the whole team over the previous 6 months. After continuing to track all our projects this way for another 3 months, I had a picture of progress over a 9-month period. I made a spreadsheet, translating each project into a line, and noting the major events in the life of each project, including:
· When we first assigned a designer or content strategist to a project.
· When we finally agreed on exactly what we were going to build.
· When we all agreed on a particular single set of mocks.
· When research was most useful.
· When we considered the product built. (This was usually marked by a “bug bash” or some kind of test or alpha launch.)
· When we publicly launched the product.
Once I had all this in my spreadsheet, I could step back and compare the different projects, big and small, and their particular timelines. At the detail level, every project was chaotic and different. But at a macro level, they were conforming to our theoretical four-step process:
Unfortunately, the observed timing was way off from the planned timing, particularly for the early steps of a project.
Because product managers weren’t distinguishing between the Understand and Model steps, teams’ initial plans as to what “design” would involve were very sketchy, usually just summed up as “do mocks.”
When I asked PMs how long it would typically take to “do mocks,” the answer was a week or two. On the face of it, that didn’t seem unreasonable. Designers were generally turning around complete sets of mocks that quickly, even for complex products. But the data showed that our typical time from “Assign designer to project” to “Agreed mocks” was about 6 to 8 weeks.
Figuring out where this slip was happening, and why, required a little more detective work.
The curse of ‘almost done’
I started doing detailed observations of teams that were in the early stages of design. I attended their weekly cross-functional team meeting and watched how they were trying to come to agreement. The process would start out OK. People would define what they wanted, and things would get designed.
But when the team started talking about the designs, unexpected problems and arguments would arise. Differences around small details would become huge issues. Team members would go round and round in circles until someone would see a solution that was close enough to what they wanted and try to shut down discussion so they could get that option built.
That would lead to new problems and arguments, cycling over and over. Because the team believed the mocks were “almost done,” they kept iterating on the details.
They didn’t notice that they were actually disagreeing on the fundamental objectives of the design.
I’ve seen teams get so stuck in this cycle that they can’t find a way forward and have to abandon the project.
Creative cycle vs. death spiral
The reason you need a discrete, substantial Understand phase is not to appease designers’ need to be creative. It’s the time it will realistically take your team to express their ideas properly and get them into a form in which they can be realistically evaluated. It’s usually not the designer who takes the time. It’s everyone getting their needs and opinions expressed, and then cycling through multiple sets of mocks to evaluate those opinions.
One of the most useful things a design process can do is help a team avoid prematurely entering a cycle of implementation evaluation.
If I’m going through a cycle of design iteration to help express a new idea, that’s time well spent. But if I’m looping back in order to, for example, “see what this would look like with a checkbox instead of a dropdown,” I’m likely futzing with irrelevancies and avoiding the real problems and the fact that we don’t yet agree on what we’re trying to do.
Out of the loop
I’ve found two main ways to help teams avoid those small iteration death spirals. One is to take more care to explain what a designer needs to have in order to produce useful mocks, which usually equates to clearly separating the process of figuring out what you’re trying to achieve (the Understand step) from doing mocks (the Model step).
The other is to make a map, whether it’s a Gantt chart or other visualization. Use your design skills to show where in the process you think you are. Show this to other members of the team and ask if it conforms to where they think they are.
However scary this might be, it’s better to admit differences in expectations sooner than to discover them later.
When everyone knows they’re nowhere near the finish line, they tend to stop lunging for it.
It might sound simple, but this act of insisting on knowing where you really are — as opposed to where you wish you were or think you should be — can make a radical difference. Not only will it help you avoid a world of pain, it’ll also help you design products that better serve the people you’re designing them for. That’s why defining, sharing, and refining a more realistic design process is worth doing.
