Design Sprint
Sprint Prep
We talk about the next roadmap item, and talk about how other people do it.
We also talk about the goal, the sentiment we want to evoke on people, tone of voice, feel, target audience, etc.
Why Do It?
We do this as a preliminary step for the Scoping session. The whole idea of this session is to capture the the overall vision for the feature we’re about to design.
Desired Outcome
Fill or get references to fill the Supporting Information box of the Product Design Canvas.
Scoping
Workshop in which the team (business, tech and design) gets together to listen, learn, and provide feedback on:
- Overarching Goal
- Personas or Audience
- Design Goals & Principles
After there is some degree of agreement on these boxes, then the team performs an Story Map session to complete the Conceptual Flow.
Why Do It?
We do this to make sure Business, Technology and Design agree on the high level sequence of steps that a user needs to go through in order to traverse a specific task(s) as defined by the roadmap item.
Desired Outcome
Conceptual Flow completed and aligned to a business outcome (e.g. increase number of users). The conceptual flow has enough design and technical details and constrains in each of its steps so that designers can write the Use Case Narrative.
Collaborative Design
- We will go through the general dynamic of the co-design session, at least until everyone is familiar with the dynamic. If you have questions about the session, or have ideas on how to improve it, shoot! :)
- We will pitch the problem (which is what we agreed on yesterday).
- We will go through two to three design rounds with their respective pitch and critique.
- We will recap on the patterns displayed in the solutions and try to get an agreement at the conceptual level. If we cannot agree, a third round of design might help sort the issue, or evaluating diverging solutions.
Activity Dynamic
Prep work (Optional)
- (Optional) Provided what's on the MURAL Board, try to research examples of what you have found to be an useful solution to the particular problem that we're trying to solve.
- (Optional but encouraged) Think of a few ideas on how to solve the problem.
- (Optional but encouraged) Think about the context of use of the particular solution that you thought about. This will help coming up with more refined ideas.
During the workshop
- We will go through the general dynamic of the co-design session, at least until everyone is familiar with the dynamic. If you have questions about the session, or have ideas on how to improve it, shoot! :)
- We will pitch the problem (which is what we agreed on yesterday).
- We will go through two to three design rounds with their respective pitch and critique.
- We will recap on the patterns displayed in the solutions and try to get an agreement at the conceptual level. If we cannot agree, a third round of design might help sort the issue, or evaluating diverging solutions.
Rules of engagement
- Go for quantity, not quality
- Defer judgement and do not censor ideas
- Build off the ideas of others
- Encourage wild ideas
- Not a drawing contest
Dos
- Come early
- Prepare before hand
- Steal ideas from others
- Think outside the box
- Have fun
- Go do something else when finishing a design round
Don’ts
- Bring your computer to the session
- Distract others during or in between rounds.
- Reuse your own “round 1” design and say it is perfect or make minor amendments.
- Criticise other’s ideas
Why Do It?
We do this because we want to see everyone’s perspective on the problem. Explore multiple ways to do things, and try to explore and consider as many different ways to solve the same problem.
Desired Outcome
- Business stakeholders produce two rounds of design using ideas from the tech and the design teams.
- Tech stakeholders produce two rounds of design using ideas from the business and the design teams.
- Designers produce two rounds of design using ideas from the business and the tech teams.
Consolidation
Designers (and optionally Developers) get together and co-sketch a single wireframe flow as derived from the Collaborative Design session.
Why Do It?
During the collaborative design session multiple design solutions are explored and iterated upon. In order to design at a pace that is natural, we instead re-group after the Collaborative Design session to bring all those concepts harmoniously together.
Desired Outcome
One single fit-for-purpose, elegant hand-drawn solution that tackles all the criteria outlined from Supporting Information to Narrative.
Booking Participants
Go into Askable and set up:
- A new test
- Write up a screener
- Launch the recruitment
- Select participants
- Wait for participants to
- Send a link using Zoom (as it is easier to record the sessions).
Why Do It?
We test with real users as testing internally gets biased through the Curse of knowledge; Developers, Business and Designers are way too close to the business-domain, terminology, context, etc. Which provoques a lot of blind-spots if testing internally.
Desired Outcome
- Perform 3 to 5 tests during the iteration is good enough to capture 75 to 85% of the errors.
Release Split
Designers (and optionally Developers) get together to discuss how to break the solution designed during Consolidationinto different releases, e.g Good, Better, Best.
Why Do It?
The reason to do this is twofold.
First, we want to be lean with the design and development operations. Don’t add unnecessary complexity or features that no-one would use without learning first from “an early version”.
Second, we want designers and developers to work proportionally to the time-window of an iteration to remain agile.
Desired Outcome
Two to three version of the same design at different maturity levels.
Design Review
On day 5 we present the wireframe-looking prototype or plain wireframes, to collect general feedback on copy and flow is collected.
On day 11 we present the high fidelity designs.
Why Do It?
We have two feedback points during the sprint cycle.
On day 5 we want to make sure that we have covered copy and flow issues that might have been overlooked during the Consolidation and Release split.
On day 11 we want to make sure we showcase the work that has been done, run a Q&A session and capture whatever visual issues might have been overlooked by the design team during the Design Documentation & Specification.
Desired Outcome
Feedback must be answer the question “why ______ doesn’t work?”.
Answers must be issued from the perspective of particular user groups if defined.
Due to the collaborative nature of the design process and its inclusiveness, we’re likely to capture many feedback issuesbefore we actually design anything. This is a feedforward approach, rather than feedback aimed to reduce rework as much as possible.
We take notes and listen to everyone’s opinions. But on a User Centred Product, the feedback that outweighs internal feedback is the user’s during the Usability Testing sessions.
Feedback during the design sessions needs to be minimal, constructive and shouldn’t ever start with:
- I wouldn’t…
- I think….
- I believe…
- If I were…
- etc…
This goes for Design, Tech and Business.
Wireframing and Prototyping
A designer converts the sketches into wireframes and prototypes using a low fidelity wire-framing tool. Designs can be iterated from usability test to usability test.
Why Do It?
We want to be able to test with users before we make everything pixel-perfect. At this stage the copy and the design are supposed to be considered draft and an indication of what they need to be.
Desired Outcome
Be able to test with a real user the golden path as defined by the Solution Flow.
Usability Testing
- Break the ice.
- Ask the user if you can record the session, and tell them that you will need him to repeat this later during the Facilitation Script “Formalities”.
- Start reading the Facilitation Script.
- Allow the user to answer if they can be recorded
- Continue reading the script.
- Talk through the Scenario in which the user is supposed to perform the task at hand.
- Pay attention. Let the user perform the task and be quiet.
- Be authentically curious. Ask the user to perform the task again, referencing as much as possible what happened on the first run and asking penetrating questions.
- Do the SUS grading.
- Ask if the user has any questions.
- Thank the user and wrap up suggesting you might follow up.
Why Do It?
We don’t test internally because we would produce biases.
We do observation sessions because is the closest we can get with the least amount of biasing (There’s some biases introduced once you ask the user to pay attention to what they are doing - the alternative to this would be an ethnographic study, which are super expensive and difficult to set up).
Desired Outcome
We go in trying to find out what we did wrong, and we capture it in notes.
You should never test to validate what you did right. Instead, be humble and self aware (which is a great thing to have as a designer) and try to uncover your own biases and dispel any gut feelings you might have about design decisions you took.
Design Specification and Documentation
Split the workload between designers. Agree on who does what. And make sure everything is ironed out for elaboration.
If you have any technical questions about feasibility ask early.
If you have any questions about look & feel ask early.
Why Do It?
We want to provide as much clarity as possible into what goes into the design, why, and communicatively confidently.
Desired Outcome
- User stories ready for writing .
- Documentation pages ready for writing.
- Text labels documented in Confluence (priority) and Abstract (not a priority).
- Wireflows.
- High fidelity wireframes ready for Documentation .
- Design System updated.
- Product Design Canvas completed and updated.
Research Readout
- Log Usability Testing notes in a Step / Participant Matrix
- Communicate considerations and key results that came from the usability testing.
- Communicate SUS Score.
Why Do It?
We all learn from this.
Desired Outcome
Get design, tech and business groups better making design decisions.
Activity Outline
Prepwork
