The practical, tactical, no-nonsense design process for pros
A process that—almost—always works
In a previous post, we talked about the different types of design, and the headspace required to execute in each. In this post, we’ll cover a realistic, tactical design process. What a designer does.
I’ll add a disclaimer: this is not the end-all-be-all design process and not a perfect formula. But, framing the process in this way could help with the day-to-day work. It’s certainly proven helpful for me since going pro. It can help unblock projects, plan and estimate work.
If it’s helpful, here’s a FigJam with each pillar laid out visually. While this is meant to be executed in order, lines can be drawn across at any time. I’ve never seen a project follow a perfect step-by-step process, so this is meant to accommodate similar scenarios. These are decentralized work packages, bundled in pillars, which can be executed in and out of order.
The process
Three phases make up this process. In order, you’ll collect, execute, and implement. As discussed, and as shown in the diagram, this happens in a loop; with loops inside the loops (FigJam link once more). The three phases are…
Collecting
Designing ↔ executing, refining, requesting, addressing
Implementing
Collecting
The collecting phase is the first step of a project. In this phase, you’re shoring up resources to ensure the project is successful.
During this phase, you’re talking to product managers, designers, and anyone who will talk to you internally. Gaining context, qualitative information, and also: documents. Decks, doc, designs, PRDs, comically long Slack threads, reports, and a link to a VCs tweet that’s been used to bolster the project’s priority. Existing research (including quantitative data) is invaluable at this stage if you can find it.
After you’ve done your homework, you can start to collaborate. Do you think you’ll need illustration support? Other design collaborators? Good to get ahead of this early. XFN partners love a good, last-minute, “super small” ask (sarcasm, they don’t).
This is also a good time to request additional research. Conduct research if you have the opportunity. The closer you can get to the end user the better.
Last, this is the time to get buy-in from your larger team. Your product and engineering partners, manager, and other leadership need to be brought along and aware if you’re taking on a larger project. There’s a line dividing when they need to know versus when you can execute without alignment. One heuristic might be something like “will this project negatively affect your existing commitments?”.
The purpose of the collecting is to squirrel away as much information, resources, and buy-in as you can before moving to the next phase.
Designing
Designing is, the nitty-gritty, the part of the process most are familiar with. This is where designers translate the gathered information into tangible artifacts. I’ve separated this phase into sub-tasks because often, you cycle through these tasks a couple of times before finalizing. The larger the project, the more clockwise trips you’ll make through this loop. Let’s go through each.
Executing
This is drawing the rectangles, and assigning colors. What we all know and are familiar with. It could be creating a design component, wireframe, mockup, or prototype.
Refining
After the more generative nature of executing the design, it might make sense to refine the work. You might whittle down the options to a single one, and tighten up the visual design to make it more coherent.
Requesting
Now that you’ve done the “design” work, it might be time to request feedback. You could ask for feedback from your product and engineering partners, or critique from your fellow design team. You also might need clarification or direction from leadership.
Addressing
Treating request responses as input, it’s a good time to address this feedback. This is where you loop: you go back to execution and follow the tasks down. Again, it’s not step-by-step, but typically you can address direction via design execution, and go from there.
Implementing
At some point, the design will be ready to implement. Nothing’s ever final, so I tend to mark the designs with a milestone + date format. Something like MVP 4.30.23
or Updates 5.1.23
.
Implementation is a separate phase because it requires you to switch your brain into a different mode. You’re no longer going wide and generative, you’ve explored the solution space and now you’re making it real. If you get alternative ideas for the solution, you can make a decision—and communicate—whether the need is to go back to the “Design” phase, or continue down the path of implementation.
In this phase, you go into support mode. Making—small—changes, and answering questions. Reacting to changing requirements as the implementation evolves. You are now the pit crew.
Once the implementation phase is done, and the product is in customer's hands, it’s time to collect information: quantitative data and feedback. Then the process repeats.
This process could be used for MVPs of a product, a new feature, or even a seemingly small request. The larger the project, the more time you spend in each pillar, and the more loops you complete. One big loop with smaller, concentric loops within. The circle of life.