There are five phases in our design process.
See Specs for deliverables from this process.
During this phase, we try to define the boundaries and context of the design problem by drawing connections between the product’s current situation and its desired future state. Once we understand the gap between these two, we can describe the design problem from the user’s perspective. We look at the situation from their perspective and consider what they need.
Frame the design problems that need to be solved to implement the roadmap.
The desired future state is defined by our product strategy and the required functionality that it aims to deliver as captured in our roadmap. The product strategy is the “big picture” that drives our work, and it helps us communicate what the product stands for, why it exists and where it should go.
In a perfect world, we would build everything we outlined in our product roadmap. However, as we often learn the hard way, nobody has time to do everything in the roadmap at once. So we have to compromise and determine what we absolutely can build based on constraints like time and current team size.
When prioritizing, we select the features that will significantly impact users or that we already know will require less effort for us to build.
To understand the user needs, we develop use cases. A use case scenario depicts how a user would use the product to solve a particular problem. We validate these use cases against our current roadmap version. If the features fail to solve the user needs, we revisit them to add the missing parts or simplify the use case.
Design problems are concerned with design aspects of the product that are lacking, unresolved, or otherwise preventing a desirable future state from being achieved.
During the point-of-view phase, we turn the problem into an actionable, goal-oriented statement. ‘Actionable’ is the key word here, as we understand there’s no “right” product feature or design solution; we have to decide which is best for a particular situation. The point of view is essential for decision-making and helps us focus our energies to prioritize.
Transform the framed problems into a set of goals and use those to kickstart the possibility exploration process.
During this phase, we explore the universe of possible design solutions and identify those that can potentially help us meet the goals we’re trying to achieve. Design solutions don’t have to be fully worked out to start the selection process.
Explore the different ways in which we can solve a design problem
We work towards selecting ideas in different ways, based on the implications of the decision being made. Some design solutions are critical for the product strategy, and others are less so. Identifying which ones are the most critical allows us to define the criteria we’re going to use during the final selection process.
As is the case with most design projects, there isn’t a single correct outcome. While methods, when applied properly, have a solid chance of leading to good results, creativity often trumps methodology when exploring the seemingly endless options and nuances of design ideas. We need to sacrifice our methodology to stay open to new possibilities, loosen up, and embrace the chaos from time to time. The fewer constraints we put on ourselves during the ideation process, the more creative we can get.
During the prototyping phase, the ideas from the previous step will evolve into more realistic representations of the final solution. To this end, prototypes can be interactive, use actual data, or whatever means exist to make the concepts more tangible. Prototypes should be used to create a testable solution that the team can implement.
It’s essential to be attentive to sources of feedback when iterating through prototypes. We often over-design a prototype to the point where we are not testing the intended solution but simply refining it. To ensure that every iteration has a clear purpose, we must move from prototyping into testing as soon as possible and many times as necessary during the design process.
Create a testable, working model of the solution that the team or users can experience.
During the testing phase, the prototypes produced in the previous step go through different forms of user-centered testing, where they are evaluated based on pre-established acceptance criteria.
Evaluate how usable (i.e., can users use it?), desirable (i.e., do users want it?), and performant the prototypes are; collect that information to improve the final design or start an additional prototype iteration.
User-centered testing can be conducted with or without actual users depending on the requirements and context. However, in the end, both types of testing will always be required.