Having worked with many companies and Start-ups I often bump against two recurring problems when planning and executing projects.
The first problem I encounter is that Project stakeholders and Product Managers want to unify seamlessly developers and designers in the Agile Process of product development. And usually fail hard.
This is due to the different needs and methodologies the two teams follow. The truth is, in my humble opinion, that Designers and Developers will never get a long happily.
The second problem is that, due to the current hype around Design Thinking, many companies want to start using it but are struggling to actually apply it in practice.
All teams are now trying to be agile, but we are not really there yet.
In the last year I did many experiments trying to work out which frameworks, activities and organisational models and activities will be the most effective when trying to combine Design Thinking, Lean UX and Agile Process Delivery.
Before jumping to the result of my experiments allow me to provide you with some context.
If you are confident regarding Agile and Design Thinking you may skip this section.
Design Thinking and Design Sprints
In its simplest form, design thinking is a human centered process of creating new and innovative ideas and solving problems.
It is not limited to a specific industry or area of expertise.
Developed by IDEO founder David Kelley, design thinking is defined as a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.” Thus, the method focuses on three main elements of a product or solution: people, technology, and business. All of these aspects evolve around the customer.
Google Ventures recently released a handbook that collects industry best practices that allow teams to run design sprints: rapid prototyping and testing sessions.
A Design sprints is a framework for teams of any size to solve and test design problems in 2-5 days. The idea of sprints originates with the Agile framework. The idea of design thinking was developed at IDEO and the d.school at Stanford. These frameworks were adapted to the idea of “design sprints” thanks to the Google UX teams, Google Ventures and Google [x] and teams across the industry.
While sprints are popular at Google, they are also used by startups and companies of any size.
I really enjoyed how Google rationalised some common UX best practices making them easy to adapt to teams who are just beginning their design practice. For this reason I now never start a project without a Design Sprint session.
Download now the Design Sprint Methods Handbook.
Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. These principles support the definition and continuing evolution of many software development methods.
The term agile was first coined for this in 2001, in the Manifesto for Agile Software Development (Agile Manifesto).
The Solution: Design Waves
Inspired by Agile development, Lean UX and Design Thinking theories, I found out that the best way to approach a succesful project is trough Design Waves.
I've called them waves because, as a amauter surfer the project goes trough some defined stages before going "Pro".
First we understand the context, looking at the ocean, studiying other surfers.
Then we start swimming, trying to reach some easy waves in order to start to have some fun while learning.
Then as soon as we get the grip of it we start looking for bigger waves, buying better boards, having much more fun and why not, maybe compete with other surfers.
You get the idea.
Design Waves bring the true nature of design work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.
By starting lean and applying Design Thinking, the frequent collection of feedback minimizes the time and budget spent heading down the wrong path.
The approach also decreases development time. Thanks to Design Sprints and fast MVP generation we are able to provide the development team an early insight into the design’s direction.
Day 1 - High Level Planning and Research
As a Facilitator, before Starting take some time to do some research on the subject. This will allow you to oversee bottlenecks and manage them appropriately.
Send out the invitations for the upcoming week. In my opinion, the best Design Sprints are the ones with teams made out of 5 people plus a Facilitator.
Usually I work with multiple teams with a cross functional set of skills including Design, Development, Product Management, Sales and Marketing. Use this day to set up the "War Room" and prepare all useful material.
Don't forget to Define the Design Challenge.
The critical task before the sprint is to formulate a meaningful design challenge that the sprint will center around. A great design challenge is inspiring, short and specifies the target use groups and deliverables of the sprint.
Day 2 - Design Sprint day 1: Understand, Define, Diverge and Decide
Day two will tackle the design challenge and include the first brainstorming activities.
Phase 1: Understand
Start by having a 360° Lightning talk: Lightning talks allow the team to understand the problem from many different points of view. The talks should include:
Business goals and success metrics / 15 min
Technical capacities and challenges / 15 min
Relevant user research / 15 min
Competitive overview / 15 min
Stakeholder Map: Products and services often have multiple types of people they are designed for. The stakeholder map lists all the possible people concerned in a situation.
1. List all possible stakeholders in a project / 10 min
2. Group the stakeholders in meaningful sections / 5 min
3. Decide what stakeholders you will design for during the sprint, and in what order.
4. Plan need finding activities and consider creating a team to work on each group.
Phase 2: Define
The User Journey: The define stage of the workshop is about breaking down the ideas into meaningful categories and defining strategies. One of the ways to do that is to create a user journey: a map that lists all the stages that someone goes through from learning about the product to becoming an expert user. / 30 min
The first Tweet: Imagine it’s time to launch your product. What is the first announcing tweet you will send out? Writing that can help the team focus their strategy in 140 characters... or less. / 15 min
Phase 3: Diverge
Crazy 8s: This technique invites the team to work individually and sketch 8 ideas in 5 minutes. The aim is to identify solutions to frustration points selected from the customer journey. / 5 min
1 Big Idea: Continue the previous exercise. The team must now work individually and sketch 1 big idea. Give it a catchy title. / 10 min
The Storyboard: Sometimes, the ideas are too complex to express on 1 page. This is when the team need to think in terms of stories or flows. The team must now sketch a storyboard of all the key steps the user must take. If the team is new to design, it is easier to think in terms of comic book strips. Remember to add the ”catchy title”. / 30 min
Phase 4: Decide
Art Museum + Zen voting: After the Sketching, it is time to share the ideas on a whiteboard.
The team will now perform Zen Voting: reviewing the ideas and voting in silence.
This allows everyone to form their own opinions before they get biased by others.
Team Review: At this point, the team can discuss the best ideas. The best way to do this is to ”invest” on the ideas. Each team member will have a “budget” of 10 dot stickers. The Idea with the most dots will be the winning idea.
Day 3 - Design Sprint day 2: Prototype
At the end of day 2 the team usually has come up with a few ideas that will be the focus of the prototype. The Prototype can be of course high level as doing it on paper, but if the Designer on the team is skilled enough, with the help of the group be sure that he will be able to come up with a mockup of the idea that can be "understood" by anyone.
A prototype is something that makes your ideas “real enough to feel,” so you can get feedback from users.
Teams tend to spend the most time in this stage.
If you're feeling creative why don't give a try to Lego Serious Play?
Rembember, the prototype must be just a facade of the final project. Design it wisely and efficiently.
Day 4 - Design Sprint day 3: Test, Refine and Validate again
Spend the morning by testing in just 3-5 minutes the prototypes between teams (if you're working with more than 5 people). If you have only 1 team, find some volunteers in the company. Typically, when we have enough time we invite people who have no idea on what the project is about. 5 test are sufficient.
- Gather all valuable insights quickly.
- What do users like and dislike in the prototype?
- What would they like to improve?
- Does the solution meet their needs overall?
- Check also with the development team, do the design ideas match or exceed the technical capacity of the team?
At the end of the day integrate user feedbacks in the prototype.
Day 5 - User Stories and Prioritization
Start the morning by discussing all prototypes and repeat the "investment" exercise done on day 2. As a group you may decide to integrate more than one prototype together. Before moving on further, it is mandatory to define a minimum viable product (MVP) to begin the process.
User Journey Blueprint
Similiar to the Customer Journey map, it is now time to break down all the tasks we want users to be able to achieve. The only main difference, is that now you'll have to be very detailed. Use a whole wall for this purpose.
User Stories mapping
The activity that I do is to ask the teams members to think of delivering their experience over a series of three phases, as an example "Sunbathing, Swim, Surf, Cruise”. The metaphor is to represent that the first release will be very limited, but it should equally be a great experience on its own, and after each release the experience just keeps getting better.
Week 2 - Sprint 0
Sprint 0 will focus on setting up Organisation and logistics, assemble the team and refining if needed the prototype and user stories. The Design team will kickoff detailed design of the MVP in order to provide an enhanced prototype at the end of the sprint to the development team.
After that the classic Agile project approach will start, the only main difference will be that the Design team will be always ahead of the development team in order to provide them with "fuel" (the design). When their job is complete they will focus on Quality assurance.
When to plan a new Design Sprint?
At the end of each release I like to plan a new Design Sprint in order to enhance the current product and solve any problems.
Clearly I'm still experimenting with this methodology, now that InVision has been integrated with Jira it is easier to create a better synergy between design and development team but the road is still long.
What do you think of this process, any suggestions? Do you apply something similar with your team?