Design is a team sport

Speaker notes: Product Innovation Summit in Dublin, March 15 2016

Let me introduce myself. I’m Marcus Castenfors. I’m Head of Product Design at a Nordic bank called Nordnet. Our focus is on creating products and services for savings and investments. We are pretty excited that we just reached 500,000 customers.

We see ourselves as a challenger to the larger Nordic banks, and we are big advocates of making the banking industry more transparent.

But I’m not here to talk about Nordnet. I’m here to talk about Innovation, and something that’s very near and dear to my heart: and that is treating design as a team sport.

I’m going to start off by telling a few scenarios. If they sound at all familiar, please raise your hand.

Scenario 1: You spent weeks or months writing and detailing requirements for something, but then you found out, either it wasn’t feasible, or customers didn’t want it.

How many of you have been in that situation? Another one…

Scenario 2: You were almost ready to launch, and to push the button, but just a few days before, someone, completely out of left field, needed to make huge changes.

Last one…

Scenario 3: You had a great idea that you felt passionate about, but the process for bringing it to life was so frustrating because of all the back and forth, back and forth, between different departments.

They sound familiar, right?

There is a remedy to these things. The cure, in our opinion, is:

• Collaboration
• Prototyping
• Customer insight

The vehicle to facilitate these three principles is to treat design as a team sport, and to run Design Sprints.

So, what is a Design Sprint?

A Design Sprint is a 5-day design process that was invented by GV, Google’s Venture Capital arm. It’s a process that has a bit of agile methodologies, Design Thinking, and some Google secret sauce.

The essence is that a cross-functional team learns about the problem to solve, designs together and then validates ideas on customers, in one week’s time.

It’s both Divergent, you generate tons of ideas. And, Convergent, you decide as a team on the best ideas to prototype.

At Nordnet, we run Design Sprints, pretty much every week, or every other week. Sprinting has become part of our product development process. Whenever we need to bring an idea to life, we run Design Sprints.

In the next 20 or so minutes, I’ll explain what setup you need to be successful, who you need to involve, and how you run a design sprint.

What setup you need to run a Design Sprint

First of all you need a dedicated space with a lot of whiteboards. You need a room that you can use for a week’s time. In most organizations that’s hard to find, but I’m sure you’ll manage.

At Nordnet, we have a space by the entrance in which we have tons of whiteboards, walls to write and sketch on, and ample space for hosting a large group. In the spirit of transparency, everyone in the Stockholm office can peak into the “Lab” as we call it, when they walk upstairs.

You also need plenty of gear, such as:

• Post-its (lots of them)
• Paper
• Tape
• Sticky dots
• High quality pens
• Plenty of whiteboard markers
• Small magnets

I’ll talk about why you need these things in a few minutes. But next, let’s talk about the team structure.

Who you need to recruit for a sprint

Just like a football team has a goalkeeper, defenders, midfielders and strikers: a Design Sprint needs a Core, Support, Expert, Extended teams.

Core

The Core team consists of a Sprint Master, Product Designers and Front-end Developers. This team is involved during the entire week.

Sprint Master

The Sprint Master’s role is to facilitate the process. This person needs to have gravitas to handle senior stakeholders who are opinionated, and also manage when discussions get out of hand. Essentially, a diplomat with design skills. The Sprint Master is also responsible for creating the schedule, well in advance, and sending out calendar invites to everyone involved.

Additionally, the Sprint Master is in charge of taking notes on the whiteboards. That’s very important. The whiteboards in the space are a visual memory that we refer back to during the entire week.

Product Designers

How many depends on the size of the problem you are solving. Their role is to quickly bring ideas to life by prototyping. We have a simple workflow of using Sketch, a design tool, and then prototyping in InVision. InVision is an app that lets you easily drag and drop designs and create hot spots to mimic real interactions.

Front-end Developers

We don’t do this in every sprint, but we want to do this more and more, and that is to have Front-end Developers in the Core team. We have a created a UI kit on GitHub containing core interface elements in HTML, CSS and JavaScript. We will continuously build this out and that will enable us to become much faster in prototyping in code. But we are not there yet. However, that is the end-goal.

Supporting team

The Supporting team is involved Monday and Tuesday and then to review the prototype on Friday.

It normally consists of:

• A Product Owner: who has the business hat on
• A Requirement Analyst: who knows the nitty-gritty details
• A Scrum Master and Engineers: who understand the technology
• A Data Scientist: who brings insights from analytics
• A Design Researcher: who understands the customers’ perspectives

Expert team

The Expert team consists of a group of experts from various different functions within the organization. They are invited to the kick-off on Monday and then to review the prototype on Friday. The constellation really depends on the problem you are planning to solve.

Extended teams

Lastly you have the Extended team which is our product organization consisting of all Product Owners, Requirement Analysts and Local Business Developers from the Nordic region. The Local Business Developers have their local “hats” on, so-to-speak, and give valuable feedback from their country’s perspective.

The Extended team is generally involved in Stakeholder interviews, which I’ll talk about in a few moments and then to review the prototype on Friday.

OK.

Now you have set up the space, you have invited the right people. It’s now time to run the sprint.

It’s Monday morning.

Monday

Mondays are about understanding the problem you want to solve. That’s the only thing you focus on: learning about customers, learning about the business, learning about technology. The idea is that, by end of the day, you should feel invested in the problem you are about to solve.

This is a typical schedule of what a Monday looks like. It consists of a set of Lightning Talks and Stakeholder interviews.

Lightning Talks are 10–15 minute presentations. You might say: “That’s ridiculous. No one can do a proper presentation in 15 minutes.” I beg to differ. If you are constrained for such a short time, it actually makes you prioritize what to talk about. In our opinion, it ensures that you stay on topic.

You typically start off the Monday session with a Product Owner presenting, from a business perspective, why we are doing this. He or she brings up metrics, success criteria and states the goal of the week.

Before the sprint, the Product Owner is tasked with boiling down the goal of the week into one sentence.

We also walk through the existing site or mobile app, and learn about the current feature-set. We might also do lightning competitor demos to get insights around their functionality.

After that, a Design Researcher, presents insights from a customer perspective. We use a framework called Jobs To Be Done to write requirements but also to frame our research. Jobs To Be Done was coined by Clayton Christensen, the author of the Innovator’s Dilemma.

Essentially, the concept is about understanding the jobs that customers hire a product or a service for. We all hire products to do something for us. We hire Netflix to feel entertained. We hire a glass of water to quench our thirst. We hire a bank to manage our finances. You get the picture. Why is this valuable? Because it frames our way of thinking. Instead of focusing on solutions, which we most often tend to do, we focus on the job-to-be-done and the problem to solve for customers.

Next, we dive into analytics data. We look at Business Intelligence and Google Analytics data to see things from a different perspective. We, for instance, highlight key customer journeys, drop off points, and click data.

Combining both qualitative and quantitative data help to give a more complete picture of the problem we want to solve.

We don’t do this all the time, but it’s powerful: Stakeholder interviews. If the problem we are solving is politically sticky or if the solution touches a lot of people in the organization who can’t be present, these interviews are highly recommended.

We invite stakeholders for 15–30 minute interviews and divide the team into around 4 groups to interview stakeholders. We give the team a set of example questions and urge them to ask “why” a lot. The “5 Whys” help to understand the root cause in their statements.

Stakeholder interviews are a powerful way of empathizing, not only with the business, but also with customers. Because most of us at Nordnet are customers and are also interested in personal finance.

After the interviews are done, each team reports back with what they have found. We write notes on the whiteboard spaces. Patterns start to emerge.

Now, we have aggregated a lot of data and insights. It’s time to find communalities, and to boil things down. We typically do this by:

Grouping insights

We use the whiteboards throughout Monday to write down all notes. When grouping all insights, we challenge the team to state the most important insights they’ve discovered during the day. And, then the Sprint Master lists them on a whiteboard.

Job Stories

Another powerful tool we use to end Monday’s session is to challenge the team to each write two Job Stories. Job Stories are similar to user stories, but it frames us to focus on the situation and the motivation of the customer.

We have printed templates that the team uses, and as a last step we put them up on a wall, and the team dot votes on the most important job stories.

That’s a wrap for Monday. The team is now bubbling with ideas to sketch.

Tuesday

It’s now time to get creative and to bring out your inner designer. Tuesdays are for sketching, as a team.

Here’s a typical schedule for a Tuesday.

The first thing you do on Tuesdays, after you have your morning coffee — of course — is to recap the most important insights and Job Stories from yesterday. It’s really important that the Sprint Master refers back to the insights throughout the week, steering the team in the right direction.

After the recap, it’s time to warm up the brain.

Crazy 8’s

A perfect way of ramping up your creativity is to do a Crazy 8 exercise. You take a piece of paper and fold it into 8 parts. You set the timer for one minute. Each team member will sketch an idea in one minute’s time, and do that eight times. It might sound intimidating at first but I’m always surprised how setting a time limit fuels creativity. I’m a firm believer that creativity flourishes by constraints.

Storyboard

Next, after you’ve generated 8 sketches, it’s now time to combine and refine your ideas into a storyboard. You take a piece of paper, and then you put 3 post-its on it, each post-it is a frame of a customer story interacting with your idea. On the right hand side, you write a short description of what happens in each frame. The timer is set for 15 minutes, and then off you go.

What typically happens is that the ideas you generate from the Crazy 8 exercise become more detailed and thought through.

Presentations

After everyone is done with their storyboard, we get up and put them on the walls. Each team member quickly explains their story. The Sprint Master’s job is to help everyone explain their idea in detail.

After the presentations, everyone gets 5 sticky dots that they can use to vote on the best ideas. It basically generates a heat map of the best concepts.

Round 2

Depending on the size of the problem, you might do two rounds of sketching. We’ve tried 3 rounds in the past but that is too much. Two seems to be the perfect amount.

Prioritization

At this point, you have a sense of the most valuable ideas. It’s now time to prioritize what to prototype. We use a simple model. On a whiteboard, you draw two axes, one for complexity and one for customer value. And then the team is challenged to put the ideas with the most dots up on the whiteboard. You might think that it will be chaotic and political, but most often, it’s a straight-forward process.

Decision time

We typically prototype everything that’s up in the top left corner: ideas that have high customer value and low complexity. We use a whiteboard marker to draw lines of which ideas to prototype.

We now know what to prototype.

Wednesday

Wednesday is when it all starts to come together. It’s when the Core team starts to prototype. The day begins with a daily standup, recapping what the team did yesterday and what to focus on.

After the standup, the Core team gets to work. If you are a large group of designers, you divide up the work, and we might also do some simple sketches to detail out a flow.

Thursday

We have another daily standup and the team continues to prototype. The group also meets with a Design Researcher who discusses the flows to test on customers. We run these sprints on a regular basis, so we already have customers recruited for the next day’s tests.

Friday

The day has come. The customers are coming. It’s now time to validate the concepts. This is what a typical Friday might look like.

The first part of the day is spent conducting user tests. We typically conduct three tests in the morning. The setup is simple and effective: we give customers a scenario to test and then we analyze how they are interacting with the flow.

After the user tests are done, the Design Researcher puts together a simple list of key usability issues and other highlights.

In the afternoon, we have a Design Critique meeting, where typically 20–30 people attend. During the meeting, we present:

• The key job stories we wanted to address with the prototype
• The prototype flows
• Key learnings from the usability tests

We use a structure that Facebook has adopted for their Design Critiques.

Essentially, you have one presenter and one facilitator. The presenter shows the prototype. The facilitator guides the discussion, takes notes, and sets up ground rules:

• Ask questions, don’t judge. For instance “Why did you choose the color blue for the button?”
• Be objective, not subjective: “When I’ve reviewed customer research, it often points out that they don’t scroll.”
• Be concrete, not vague: “In this case, I would suggest you move the button, above the fold.”

When the presentation is done, and we have received feedback, the last step to conclude the week, is to do a retrospective. We gather the Core and Supporting teams and learn about what went well, what could have been improved — to keep perfecting how we run sprints.

It’s been an intense week, but if you’ve been involved, you will feel a great sense of accomplishment.

In one week’s time, you have learned about the problem, collaborated across the entire organization, prototyped a solution, tested on customers, and also validated the ideas with your peers.

In short, this process is a game-changer for us, and I am positive it can be a game-changer for your organization. By using Design Sprints at Nordnet, we have become more design-driven, and customer-focused in our product development.

It’s remarkable what you can achieve in just one week’s time.

Get your post-its and pens ready: when will you run your first Sprint?

Thank you,

Marcus Castenfors