Design Process¶
There are five phases in our design process.
Information
See Specs for deliverables from this process.
Design Problem Framing¶
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.
Goals¶
Frame the design problems that need to be solved to implement the roadmap.
Activities¶
- Research: practical research on the problem from literature review, user testing with prototypes, user interviews, and collected product feedback.
- Data Analysis: learn more about the problem through analyzing qualitative and quantitative data.
- Facilitated Discussion: have a discussion to gain an understanding of the way each team member views the design problem.
Questions¶
How do we know what the desired future state is?¶
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.
What if the roadmap changes?¶
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.
What are design problems?¶
Design problems are concerned with design aspects of the product that are lacking, unresolved, or otherwise preventing a desirable future state from being achieved.
Point-of-view, Goals and Constraints¶
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.
Goals¶
Transform the framed problems into a set of goals and use those to kickstart the possibility exploration process.
Activities¶
- Exploratory Wireframing
- User Journey Maps
- Storyboards
Explore Possibilities¶
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.
Goals¶
Explore the different ways in which we can solve a design problem
Activities¶
- Possibility Definition
- Define Selection Criteria
- Possibility Selection
Questions¶
How are ideas selected?¶
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.
How do we balance methodology and creativity?¶
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.
Prototyping¶
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.
Goals¶
Create a testable, working model of the solution that the team or users can experience.
Activities¶
- Select components and patterns
- Design interactive prototypes
- Share prototypes
Testing¶
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.
Goals¶
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.
Activities¶
- Informal action analysis
- Take a look at the sequence of actions users have to perform to complete a task
- Analyze each action based on how frequent they might be, how many facts does the user have to learn to perform an action etc.
- Cognitive walkthrough
- Imagine what people are thinking or doing while using the prototype
- Find obvious problems, missing controls, confusing labels
- Heuristic evaluation of prototypes (against predefined design principles)
- Evaluate a design based on guidelines or general principles
- Evaluators do the analysis alone then problems are combined
- Often useful to analyze combined results as a group activity
- Conduct user testing (comparative or explorative)
- Conduct surveys or interviews to obtain user insights
Questions¶
Do we need to always test with actual users?¶
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.