(00) Process
Design runs a sprint ahead of engineering.
So what arrives in the development sprint has already been tested.
Three phases · nine questions · one board
2-3 days before the sprint, then a 2-3 week CXD sprint
The cycle
Discover · Optimize · Validate
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.
- Discover: Users, needs, scope
- Optimize: Design, test, improve
- Validate: Risk, impact, next
- And round again
(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
Backlog to production
Five steps
- 01Understand the requirements and target audience
- 02Create concepts to validate flows, designs and content
- 03User testing
- 04Refine based on findings
- 05Deliver to engineering and iterate as needed
- 2-3 days before the sprint, 2-3 week CXD sprint, after
- Backlog: Product requirements; Portfolio review; Prioritized CXD backlog
- Grooming: Explain the stories; Vote on size (1, 3, 5, 8…); Sprint scoping & estimation
- Design sprint: Concepts, flows and content; Test plan & prototypes; Usability testing
- Specs & review: Flows and business rules; Mockups & content; Review with stakeholders
- Production: Handoff to engineering; Design stays a sprint ahead
- Exceeding stories
- Additional feedback
Annotations on the board
- 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
Four departures
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
The cadence, ritual by ritual
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.
- 2-3 days before the sprint starts, 2-3 week CXD sprint
- Monday: Grooming: explain the stories, vote on size, discuss the prioritized list
- Before the sprint: Realistic CXD sprint set after estimation; exceeding stories fall back to backlog
- Daily: Stand-up: one person (PO) organizes the sprint, what is in it, and the team’s capacity
- Weekly: Internal CXD review and approval, plus the weekly design review
- End of sprint: Specs to engineering, so nothing is a surprise when the product is developed
Keep reading
Three more ways in