This is a guide to the process that I like to follow when designing new products or non-trivial features. Whether you need to follow all the steps or not will depend on the specific context. The opportunity assessment part is more formal and better suited to new products, whereas the rest is generally equally applicable to features as well as new products.
Most of this part is lifted straight out of the brilliant book INSPIRED: How to Create Tech Products Customers Love by Marty Cagan, I think it’s a must-read for both product designers and product managers.
These are not questions that a product designer should feel compelled to answer but this is the sort of information that you want to have at your disposal so that you can make more relevant and informed design decisions.
Create a simple product specification, a simple product spec. is more likely to be read and maintained. I break this document down into three categories:
The end goal of this stage is to create high-fidelity interactive prototypes that can be tested by users. A good prototype is equivalent to “measure twice, cut once” as it greatly decreases the likelihood of having to do costly post-deployment redesigns.
Your prototype should serve as:
How you arrive at the high-fidelity prototype is largely down to designer preference and feature/product complexity. If I have a good design system at hand and the complexity is low I might feel confident to jump straight into the high-fidelity design work. If complexity is high then I might start with flowcharts, sketches, mind maps, greyscale wireframes or any other combination of techniques that I feel is suitable.
Ideally you want real users to test the prototype who are as close to your target market profile as possible and you want to be able to see them interacting with what you’ve designed, whether via screenshare or by sitting next to them. I find that an initial round of 3 -5 users is sufficient to identify any glaring issues. If there are some real blockers that those testers all pick up on then you want to try and resolve those before doing anymore tests, which is why I’m hesitant to schedule a large group of testers initially.
There’s no point designing a fantastic solution if you just don’t have the technical capacity to implement it so somebody on your engineering team needs to answer the question: do we have the capability and resources to build it?
There’s plenty of details that I intentionally left out of this article for brevity. This is just an outline of some of the steps you may want to take to ensure you are following a thorough and considerate design process. I hope it’s useful.