Design runs a sprint ahead of engineering.
So what arrives in the development sprint has already been tested.
The cycle
Nine questions a team has to be able to answer. They are grouped into three phases, and the three phases are a loop, not a line — what you learn in Validate is what you Discover with next time.
(01)
Discover
- Who are our users?
- What do they need?
- What do we build?
(02)
Optimize
- How do we design it?
- Will they use it?
- How do we improve it?
(03)
Validate
- Are there showstoppers?
- Did we have impact?
- What do we do next?
My operating model
- 01 Understand the requirements and target audience
- 02 Create concepts to validate flows, designs and content
- 03 User testing
- 04 Refine based on findings
- 05 Deliver to engineering and iterate as needed
- I create the stories describing what is needed from my team. Sequence following the business priority.
- Scoping the work with the team and making sure the understanding is aligned.
- Prioritization based on business and respecting the team’s capacity/velocity.
- Depending on the type of request, it would be a usability testing story or defining how the experience should be.
What is different about this approach
Validating / optimizing
Validate and optimize designs and flows before code, on every sprint.
Final screens
Content creation together with design creation.
Working together
Designers, engineers and stakeholders working together and ahead of development sprints.
Understanding dependency
Distributed team working together and understanding dependency.
Consumer experience design sprints
Two rituals hold the whole thing together: a daily stand-up where one person on the team organizes the sprint — what is in it, and the team’s capacity — and a weekly internal review and approval, so there are no surprises when the product is built and so the people who were not in the room still know what happened.