My Process
No two projects are the same and the design process adapts to the project needs. That said, there is a general flow to how I approach a design problem. And at the end of the process, regardless of size, scope, tools or timeline, these questions need to be answered -
Who is the user?
What need are we solving?
How can we solve for that need?
What does that solution look and feel like?
Did the solution meet their need?
1. Plan and Organize
Who is this for? What need do we think we are solving? Why should the user care?
Project kickoff. This is the stage where projects turn real. Designers are assigned, requirements if they exist already are reviewed and if they don’t are defined alongside the stakeholders. We get our first taste at what kind of problem we are trying to solve. What is the business ask? Who are the stakeholders? Is it a whole new feature? An enhancement to something that already exists? What do we know? What don’t we know? What is our timeline? Why work on this?
Outcome:
Early review and alignment with stakeholders. Who is this for? What user need do we think we are solving? Why should the user care?
2. Immersion & Synthesis
What is the design ask? What are the design goals?
Take all of those questions that came up as we did our initial planning and start diving. What persona are we building for? What assumptions are we making? What data do we have? What data do we need? What might we need to test? Anything similar out there? What’s good about it? What’s bad about it? Is there more opportunity here? How does this fit into the bigger product roadmap/strategy? Is this a solution in search of a problem? What are the business goals? How are we balancing user need and business need? Do we need to redefine the problem we are solving? Redefine the scope?
Outcome:
What is our design ask & goals? What are our primary use cases? What is the most important, frequent task? What are our measures of success? What does success look like?
3. Design Direction
What are the different ways we could solve this? Which one is most promising?
Based off all the info we have so far, what are the possible ways we could solve this? Are they distinct? Or just iterations of the same idea? If they aren’t distinct, is there really no other way to solve this? How well does this direction address the primary use cases and design goals? Does it do a really good job of solving the most important/frequent tasks? What are the pros/cons of going with this direction? How does this direction fit within the larger product? What assumptions are we making about this direction? Can this be technically supported?
Outcome:
Proposed design direction.
4. Final Design
Design solution. Validated and documented.
Iterate. Iterate. Iterate some more. Tease out all the granular details. What are ALL the cases we need to account for? Detailed UI and refinement. Repeat validation against the design ask, goals and primary use cases. Prototype. What do we want to learn from usability testing? Make sure that desired design and feasible design are as close as possible. Document the final design.
Outcome:
Design solution that has been validated and documented.
5. Measure & Evolve
Did we succeed?
So, we think we’ve solved the right problem with the right solution. Let’s find out. What are our KPIs? Which metric do we care about most? How are we doing on our measures of success? What will we be doing with what we learn?
Outcome:
Next steps informed by data.
Having said all of that, Bill Watterson captured the process better than I ever could.
