Clarity in the design process: how to create a process map for your team

There’s something I often hear from designers at early-stage startups in my work at Designer Fund: “I wish we had more clarity around the process we use to take a product from idea to launch.”

This is why I often recommend to teams and leaders that they create a process map of their ideal design process. In other words, a template that everyone can refer to as they bring a product from idea to ship.

A process map can help a growing design team scale, produce quickly, maintain brand cohesion, and make sure each individual is working on projects that come to fruition. It also helps adjacent teams like product management, marketing, and engineering know exactly how to work with design.

It starts with a simple question: What’s your ideal design process? The resulting discussion produces an artifact to circulate around the organization, such as a PDF chart, spreadsheet, task list, Google doc, or poster to hang on the wall.

But the real fruit of the process map exercise is less about the artifact and more about helping your team gain clarity. When you verbalize and visualize your ideal system, you set expectations and remove ambiguity. Without that step, people waste tons of time on projects that shouldn’t move forward or feel anxious about how to proceed at each phase.

A process map can help a growing design team scale, produce quickly, maintain brand cohesion, and make sure each individual is working on projects that come to fruition.

I’ll discuss how you can make a process map for your design team (or any business activity that requires team cohesion). To start with, I’ll share a story about the importance of a process map from my past as a design lead at Facebook.

Design process at Facebook

It was 2008, and Facebook was swiftly expanding. We were right around our 100-million-user milestone, and our ten-person design team was hustling to keep up. We operated organically, with each designer having the autonomy to build and ship.

This naturally gave rise to some unspoken rules. For example, products that the CEO was particularly focused on needed his approval before going live. For everything else, we tended to make judgement calls. It wasn’t clear when and if to bring work to Mark Zuckerberg.

But as Facebook spun faster and faster, our loose design process started to wear at the edges. The CEO started to see too many unbaked ideas. Some features were designed in the open and some in private, which led to frustration if people found out about a product or feature only after it had shipped. And our visual language became less consistent. Details like different tab styles and color shades emerged as people hustled to get their projects out the door, and it would be unclear whether a new style was now official, or just a trial.

As more teams around the company wanted to work on projects with design, we needed a way to set expectations with them about how our collaboration would work. For example, other teams accidentally made design changes without knowing who owned Facebook’s visual design and needed to give approval—like when an engineer would alter a button style to fit what they perceived to be a unique use case exempt from our visual canon. In another example, we’d forget to tell customer support about a new launch until the day before, and they’d have to scramble to prepare for incoming issues.

All in all, when we looked at our products across the board, we’d see different quality levels and different production speeds.

When we examined what was happening, we realized a big root cause was that we didn’t have an agreed upon process that every designer, engineer, and PM could point to.

A big root cause was that we didn’t have an agreed upon process that every designer, engineer, and PM could point to.

In response, we created a process map. A process map visualizes the ideal process that takes a feature from Idea to Shipped, and puts a stake in the ground about the actions, people, tools, and decisions that should be involved in each phase. There might be exceptions, but all things being equal, it’s the process everyone’s expected to follow.

Two or three designers on our team defined and visualized the perfect design process, then we all discussed and agreed on it. We turned it into a designed PDF that we could email to people around the company.

This process map exercise introduced or made official some very helpful practices. We established working groups to make sure changes received rigorous feedback before they hit the CEO’s desk, like a visual design group that would review all buttons and tabs for consistency. We knew to when to clue in a teammate from customer support (in the first meeting about a new project), and when to get legal review (usually much later). And teams that wanted to work with us could expect a kickoff meeting where we’d review their data and research.

If teams want to survive the real world, they need built-in flexibility to accommodate compressed timelines, unexpected variables, and intuition.

As a result, we had a set of default actions that often relieved us of cognitive burdens while we worked. “Should we make a creative brief for this project?” Yes; that’s something our team officially does. “Should we show Mark?” It depends on the priority and scale of the project.

If teams want to survive the real world, they need built-in flexibility to accommodate compressed timelines, unexpected variables, and intuition. At Facebook, this happened plenty of times, such as when we got only two weeks’ notice that CNN wanted us to build a commenting infrastructure for the live stream of Obama’s 2008 inauguration.

So our go-to plan also became a baseline to measure how far we’d deviated when projects didn’t follow the process perfectly, and served as a true North to shoot for over time. It helped us ship faster, work in concert, and play nice with other teams.

Below are some ways to create a process map for your team or organization.

Elements of a process map

Process maps don’t have a prescriptive structure because they should clarify the unique steps and requirements native to your design team and company. But for illustrative purposes, your process map might use the 4 phases of Dave Merholz’s Double Diamond Model of Product Design:

1. Ideation (Understanding customer issues and thinking about product strategy)
2. Definition (Further defining the strategy and project requirements)
3. Iteration (Prototyping and testing)
4. Implementation (Fleshing out and refining the solution)

For each of those phases, you can define what must be in place before moving the product forward. Specify things like:

• People: How many designers need to be involved at the Ideation phase? Who needs to approve prototypes before we can implement them? When does the CEO come in?
• Tools: What software and design tools are we using at each phase?
• Artifacts & deliverables: What tangible or digital-tangible items will each phase produce? A creative brief? Wireframes? A recap presentation of customer interview learnings?
• Meetings: What meetings should we be having? If we need to review a design with the head of product, when should that happen?
• Decisions & outcomes: What exactly is the data or decision we need to make before we can release a product out of the prototyping phase and into execution?

Process at Plaid

Young companies in particular struggle to pin down these elements. So, one evening at Designer Fund’s Bridge program, we had a group of designers go through the process map exercise. We told them to think of the last project that went out the door and chart the path that brought them to that point.

For Al Hertz, design lead at Plaid, mapping out a process brought to light new ways to focus his team. Plaid had recently hired a second designer and intern to join Al, so it was a good time to create discourse about what kind of team and company they wanted to build.

In fact, the entire company was at an inflection point where they wanted to make decisions in a structured way and were creating new processes to support that. “As we grow, we need to evaluate more and more possible changes to our core products,” Al says. “We want to root those decisions in a more quantitative place and create a culture around measuring them.”

Al took the empty process map grid, and on one side, he mapped out the version of Plaid’s design process when things are going well. Then he flipped over the page and drew a big question mark on the other side: the design process at its worst. In other words, when things were going poorly and he didn’t even know what process people were following.

Al’s ideal process, he explains, is structured. It starts with a dedicated research phase and brings important people along for the ride, such as internal stakeholders and external customers. They’re successfully doing this with a yearlong initiative to make fundamental changes to Link, one of Plaid’s core products. The team is about halfway through, and have taken three months to speak with customers and non-customers as they develop a high-level roadmap.

But the question mark side of the page is representative of projects when the team is just focused on getting things done, without leaving much time to research and understand the root of the problem. “This can happen when we think a project is important, but we don’t have dedicated resources. Or perhaps the design team is acting as a factory-line-style creative services bureau, as opposed the collaborative, creative team design is supposed to be,” Al says. “It can feel like throwing spaghetti at the wall.”

The process map exercise also brought to light some of the organization’s problematic tendencies and how to be more mindful of them.

“I was struck by how easy it was to list all the tools that were part of a design phase,” Al shares, “But it was incredibly difficult to identify concrete decisions that needed to come out of a phase — the data, success metrics, and other knowledge we needed to move forward. I might have identified 12 tools but only one bullet in Decisions & Outcomes.”

Al realized the team may not always be aligned around what they’re trying to accomplish, getting distracted by tools because they’re easy to adopt and play with. “We should be focusing on outcomes instead. The process map exercise is helping me make that mindset shift.”

Diagnose: Does your team need a process map?

Here are some common symptoms of a murky process:

• Two people on the same team describe the “official team process” very differently.
• Executives swoop in at the last minute and make changes to projects before they go live.
• People get pulled on and off projects midstream.
• Projects get cancelled halfway through.
• People get frustrated because they don’t know who made a decision and why they’re prioritizing one thing over another.
• People are surprised to learn of work their teammates are doing, or even find out about it only after it has shipped.

Here’s a great way to test it. At your next team meeting or offsite, pass a paper to everyone in the room and ask them to map out one of your core team processes on their own. Then compare. If multiple teammates try this and have very different process maps, it’s a good signal you need to meld your ideal process into one the whole team can agree upon.

Put the process into practice

Here are four basic steps to creating a process map:

1. Diagnose: See above.
2. Clarify: Rework your process as a team. Dredge up the steps and requirements, polish them off, and look at them in the light. Write down the three to five major phases of your process, and specify the people, tools & software, artifacts & deliverables, important meetings, decisions, and outcomes that go into each one.
3. Create an artifact: Then create an artifact of your agreed-upon process and distribute it within and outside of your team, whether it be a poster, spreadsheet, Google doc, or task list.
4. Circulate and iterate: Once that artifact is created, you want to use it to get feedback, iterate on your process until people feel good about it. Then think about how to communicate it to the team and codify it in your tools and resources.

Spread process maps to different business functions

An agreed-upon path can help any team be more successful (not just design). For example, you can use this exercise if you are:

• A product team prioritizing features
• BD deciding whether to partner with a business
• Hiring and interviewing new teammates
• A manager conducting performance reviews and promotions
• A team undergoing quarterly planning

At Designer Fund, we’ve created a process map for our employee onboarding and offboarding. We set up the high-level milestones, and then codified all the tasks into Asana templates. This gives new hires clarity, speeds up the process, and helps managers and coworkers offload rote tasks. Enrique and I also created a map of our startup investment process as companies pass through five stages, from the initial referral email to close.

We can’t follow all our process maps perfectly. But the clarity that they’ve created is like oil in a motor, helping things run smoothly at a fast clip. A little goes a long way.

Ben Blumenfeld is co-director of Designer Fund where he invests in tech startups that are design leaders including Stripe, Gusto, and Omada Health. He helps build and educate design teams through Designer Fund’s professional development program, Bridge, with top designers from companies like Dropbox, Pinterest, and Facebook.