I always like to begin with some form of design planning. In an Agile world, this may seem out of fashion, but you cannot iterate your way to unstated product or design goals, except through blind luck. Especially for products that must fit into an enterprise ecosystem or tackle complex business or human needs. Product and development managers want design and build teams to hit the ground running. Yes. But which way? How far? Design plans help us all start from the same place–and move faster, once we’re ready to build.
The design plans I create typically cover four phases for my user experience teams. While UX facilitates design thinking activities (using the double-diamond process, as shown below), we cannot do this alone. Our design plans always include three voices: business needs, user desires, and technical realities. I prefer to start with a small, empowered team of just 3-4 people, growing to the full delivery team when we all agree on exactly what problem we are solving and for whom.
Learn the space
This research phase can range from a short effort to gather details about known product shortcomings and the affected user personas to a longer exploration of risky unknowns from the user and business perspectives. The design research activities entirely depend on what we need to learn. Maybe a simple “research round-up” of existing data is enough. Or maybe we need an internal stakeholder alignment workshop to set goals and a field study to gain empathy and understanding of people and situations that are unknown to us. We know we’ve learned enough to proceed when we have crisp, clear answers to questions like:
- What do we already know about this? What do we still need to know to reduce risk?
- What does the business want to accomplish and why? What’s it worth?
- What audience matters most? Why? What are they trying to do?
- What technical hurdles exist or have stopped us before?
Define the problem
Too many product design efforts start with a solution, but no clarity about the problem to solve or main audience to serve. In this phase, we’re boiling down what we’ve learned to a precise definition of the problem we will tackle, for whom, and how we’ll measure success, leaving the rest behind. Research findings and recommendations help the design planning team choose the product opportunity and personas that meet our goals, all based in evidence. We may even create a broad design concept to review with our intended audiences for its value to them, just to quell any doubts or disagreements. Sometimes, this phase ends with a decision to stop the work. This is still a win in my book, because finding out you’ve made a strategic mistake early is better than building products that create no value and may even do the opposite.
At most, product design and build teams can address only a few, clear priorities to create deeply loved and useful products, yet they usually hear a wide range of conflicting, vague, unmeasurable goals. Problem definition is critical. Once you have it, you can expose larger teams of designers and developers to what we’ve learned and what we’ll do about it together, begin storymapping, and move the work into Agile planning. Teams can ramp up quickly, yet still have room to innovate on problems that come to them with the reasons and goals made clear.
Model and test
At this stage, my teams generate wireframes that model the main path through the experience for the intended user. We do this iteratively and review additions or changes with delivery teams to get feedback and improve our ideas. We also create lightly clickable prototypes, so we can engage with users earlier to gauge reactions, settle a creative conflict, and see what does or doesn’t work. For smaller check-ins with users, we may generate a small animation of the flow we’ve designed or even just a key screen or two and send it out with a survey to get quick responses.
Build and test
Usability testing doesn’t have to be extensive, but it’s good to bring back the few, main goals for the product or feature and see how well you’ve accomplished them. Is it faster? Is it easier? Does it give the user true value? I often like to wrap up a usability test with a few broad questions about what they found most valuable in the product or feature we tested. I also encourage product managers to measure their product goals through analytics, where possible, and empower my teams to dig into usage data or run surveys to see if we’ve been successful in solving problems and improving the user experience.