Google Design Sprint in 8 hours

Artigo

Partilhamos um artigo de Catarina Garcia, UX/UI Designer, Trainer e Design Thinker, onde nos fala do Google Design Sprint e da sua metodologia mas aplicada a apenas 8 horas.

This article is a summary of 4 sessions I ran some days ago, using the Google Design Sprint methodology on msg life Iberia, a IT company focused on insurance software with a lean development approach.

As a Design Thinking trainer, I was invited to run some sessions, using problem solving methodologies on an environment focused on agile and really lean solutions and I realized that was the right moment to put in practice all I read about Google Design methodology. This was the first time that the company would use this type of approach to find innovative solutions for their problems.

What is Google Design Sprint?

For those who are reading about Google Design Sprint for the first time, it is a methodology divided in 5 work days to solve and prototype a solution for a problem.

– Monday: agree with a long term goal; map the experience; define a target

– Tuesday: remix and improve ideas; sketch them

– Wednesday: make a solution storyboard

– Thursday: make a prototype

– Friday: test on the field

My challenge

Instead of the five days suggested, it was given 2 hours, for 4 days!!!

Set up the stage

Before these sessions, you need to ensure that the team has enough information about what these type of sessions are. It’s also important to be sure that they know exactly what the focused pain point is — the point that is a problem, the true challenge!

The team was composed by 7 people:

– 2 Deciders: they supervised the results of the sessions but were only present in the setup and presentation meeting

– 3 Engineers: the company has 3 coding dojos. One person from each dojo was invited to the team

– 1 Expert: the person who better knows the core problem; this guy was also part of one of the coding dojos

– Me: as a facilitator

We talked with the people in person, to explain what would be happening; Following this, some emails were sent to the team, explaining the process, giving examples,… Everyone should be at the same page the moment this process starts.

You need to do some previous research to understand the type of problem your team will be working on and choose the appropriate tools to use during the process and define a duration for the use of each tool. Otherwise, it would be impossible to keep the schedule.

The Meeting Room

The sessions wouldn’t be long, but it’s important that everybody is comfortable and focus. The available room for these sessions was small even for a group of 5 people. This fact wasn’t an excuse not to focus on details. We prepared some posters indicating that no cell phones would be allowed. Fresh water was available for everyone. As suggested in the Design Sprint book, it’s definitely a good idea to have some snacks to pick for longer meetings.

Before the team arrives, it’s important that all the logistics are prepared. We used:

– One white board

Sheets of paper (A4 and A3)

– Lots of post-its with different colours and sizes

Board markers: black, red, blue and green.

Day 01 — Defining the problem

During the first two hours the team dissected the problem. It took some time to put everybody in the mood and start working. But after a quick conversation and with the help of the Expert on the problem everybody started to be involved. They began to map the players and the actions that take part of the process. A very quick and summarized journey map of the problem. It was really helpful to understand the pain points and their dependencies.

The main goal of the solution was clear at this moment and it was written at the top of board. During the following sessions this goal was always visible to help keep the focus.

After this, the team wrote a group of assumptions that should be true to validate the solution.

To clarify the problem, the team made a diagram, at the center they wrote the core problem and, like a molecule, they filled in the satellite problems that cannot be ignored.

Day 02 — Defining the problem/Diverging

Lots of questions, they made lots of questions to each other during the problem definition. So, to keep these questions in mind, and trying to evaluate which would conduct to the solution, the team made a How Might We… session. During 20min, they wrote all of their questions.

They could understand that they had different points of view over the same question, and they started discussing the meaning of each question.

It was necessary to choose a group of realistic questions to answer.

They use a election to chose the questions. Each team member could vote twice. The expert could vote four times. At the end, the group had three main questions two answer.

Day 03 — Evaluating ideas

In the previous session, the team had defined the main questions to answer in this process. Now, it was time to think about solutions. Our problem was too technical to apply crazy 8 technique. Together we found out the best approach would be brain-writing.

During two periods of 20 min they write all their ideas.

In the first 20min, silently, they wrote down their ideas, not minding on what others were writing. Over this time, they stopped writing ideas and started explaining some of them to each other for 15 minutes. The new ideas started to come out automatically.

For 20min more, this time talking to each other, they had more ideas.

They discussed their ideas and organized them into clusters. They started to evalute the ideas according to the assumptions they had defined on the first session. Some of these ideas were put apart because they found out they weren’t realistic or couldn’t be answered properly.

Day 04 — Roadmapping the solutions

The team had identified 4 clusters of solutions in the previous session. They realised that the number of clusters corresponded to the satellite problems they had defined at the beginning. So, they found out that the best solution roadmap for this problem, should be divided in 4 scenarios.

They divided each scenario in 2 areas:

– main goals: what will be solved in this scenario

– actions: necessary steps, hierarchies, people, duration for the scenario

At the ending of this session, the team was enthusiastic, confident, happy and proud of their work (and they had reasons for it).

Conclusions

Google Design Sprint is a really powerful methodology to solve any kind of problem and it fits perfectly in a IT environment:

The preparatory work with the team is mandatory, specially for people who are doing these kind of sessions for the first time

Google Design Sprint suggests specific activities for each session and it helps a lot to focus, organizing the agenda and giving the team a vision of what’s gonna happen

It should be a very specific and clear problem, otherwise the team will lose plenty of time defining the problem

Have everything prepared before starting the sessions: the schedule, the room, the materials; the checklists you find at the of the book are extraordinarily helpful

Always use the same room — and leave the posters, post-its, everything there: the team feels that is their work room

The team needs to feel that what they are doing is their work. You, as facilitator, are only there to give them tools

– Guide and don’t manipulate the results only to get things done

Focus and always have a timer, it’s easy to start talking and lose the main goal

– At the end, talk to the team and show them how everybody can be creative and come up with great solutions

“Everybody has a creative mind, most of the time they just need the right stimuli and the right tools to discover that.”

  • Artigo originalmente publicado no Medium da Catarina Garcia.


Partilhar:

    Fale connosco

    Interesses

      Subscrever Newsletter

      Interesses