No one process is right for every project!
Part of being an experienced designer is knowing what activities are right for the type and stage of process you’re addressing right now. Whatever the phase of your project, the design thinking toolkit has an activity and a template ready for your needs. I’m a fan of the Luma System templates in Mural, but there are many options. I frequently choose to customize an activity to suit the needs of the moment.
Even before an official kickoff, I will begin with a high-level mapping of user flows, and a quick heuristic analysis to identify pain points. One innovation that I’ve incorporated into my process is to take these pain points and translate them into opportunity statements. I have observed that a purely pain point driven conversation can lead to a band-aid or quick fix mentality, while opportunities drive a more positive, and holistic approach.
Vision
Having outlined a problem or opportunity, many product organizations are inclined to start defining and scoping the work. More user-centric teams tend to start with research. Initial discovery can take the form of internal (stakeholder) and external (user) research, as well as traffic/usage data, customer feedback, CX and support calls.
In the early phases of a project I ask a lot of questions, and try to talk with as many people as possible. Users, first and foremost - current, prospective, former - anyone who will talk to me, respond to a survey, or take part in moderated or unmoderated testing.
I am a huge proponent of a deep approach to competitive analysis. Understanding direct competition is a must, but I am also keen on finding similar patterns from outside of direct competition. I want to know “Who does this best?”. That answer becomes my jumping off point for “...and how can we do it better?”
While seeking out users, I also like to interview stakeholders; product leaders, customer service reps, frontline devs - anyone with insight into the problem space. This last group (dev) has been the key to many successful projects. In my experience it is critical to involve the engineering team early and often!.
Foundations
Once a team has coalesced around a vision, the mechanics of the design process kick in, and progress begins to happen quickly. This is the time for sketching, writing user stories, and charting flows. During this period I prefer to keep my concepts in a low-fidelity state to avoid distractions that might interfere with testing ideas.
I also like to work a set of concepts forward in parallel, rather than investing all effort in a single direction. This strategy helps ensure that a team doesn’t have to start fresh if an idea fails in early testing. It also offers the potential for cross-fertilization of ideas as the parallel concepts are fleshed out. Scenarios, storyboards and wireframes move this process quickly towards a set of testable designs.
Testing Business Ideas
I include the word business here to emphasize that all this effort, ingenuity and scientific method is not being deployed simply to learn some interesting facts – no, we’re here to make money! This is why I advocate for a rapid fire process that can quickly zero in on the best possible design. This process should also be as cheap (in terms of effort) as possible; If a paper prototype can get the answer you need, perfect. But, if a fully functional live-code prototype is the only way to test your idea then that’s what you need.
I’m especially excited for the potential of AI-facilitated “vibe coded” prototypes to make the high end of this spectrum more accessible.
This is also the phase of the project where I begin thinking about the instrumentation, data, and user feedback collection strategy. These steps require close collaboration with engineering teams.
Refine and Verify
The testing phase should deliver a clear direction, and with that in hand, this phase should practically build itself, particularly if with a strong design system in place. This is when I start to connect all the dots - with activities that span both UX and UI, such as:
- Information architecture
- Navigation
- Copy/Microcopy
- Layout
- Usability and accessibility
- Color palette
- Iconography
- Typography
This is also the time for accessibility testing, and last minute user testing, to make certain your approach is rock-solid. A firm plan to collect usage
Ship It!
When I hand off high-fidelity mockups, redlined and annotated as needed I also commonly provide code examples, and any updates or additions to the design system. Monitoring and feedback systems should be in place to monitor the performance of the ew design and collect