This is a guide to the process that I like to follow when designing new products or non-trivial features. Whether it’s best 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.
I got a lot of value out of the book INSPIRED: How to Create Tech Products Customers Love by Marty Cagan, He provides a great framework for how to frame opportunities:
These are not questions that a product designer should have to answer by themselves, but being equipped with this sort of information can really help you make more relevant and informed design decisions.
Often times however a framework like the one above can be overkill, especially for a small feature or an existing product. There are a few simple questions that I always like to try and answer before starting design work:
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 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.