What skateboards and motorbikes can teach us about designing digital services

Service design embraces uncertainty. There’s so much we don’t know at the beginning of a project. Even after doing good user research you still can’t be sure how your users will respond or how much your service will meet their needs.

That’s why designing iteratively is important.

“Iterative design is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made.” - Wikipedia (yeah, not always accurate but in this case we like how it describes it)

So what has this got to do with skateboards and bicycles?

‍

This metaphorical image from Spotify’s Henrik Kniberg (whose original article inspired this post) seems self-explanatory. But there’s actually more to it.

How we used to do it

We used to do it like this.

This is also known as Waterfall or Big Bang development. You specify all service or product features up front then build it. But notice there’s no user in this picture, because they aren’t involved until the end.

Four reasons not to do it this way

• It takes a long time
• The user gets nothing they can use until the end
• No user testing is possible. You can’t test a set of wheels that size.
• The end product will have design flaws. Because early assumptions were never tested. The user is unlikely to be smiley as in the picture.

So what should we do instead?

Focus on the underlying need first

When you do this, more options become available. What’s the underlying problem and what’s the smallest, testable thing we could do to solve it?

In this case the problem is that the user wants to get from A to B. But we’re not trying to deliver a solution that makes them happy just yet (that’s why in the image they aren’t). We’re only interested in learning from them. A skateboard is pretty simple to make and learn from. We can easily ask for feedback on it. It represents the minimum testable solution.

If we didn’t want to make a skateboard we could also give them a bus ticket then ask them about their experience. But we might already know that buses don’t meet their user needs. 

Shorter journeys become longer journeys

The skateboard works, a bit. But for most people it isn’t going to be very usable. It’s tricky to learn and not very fast.

In the next iteration adding handlebars makes it easier to use. You can balance better and travel further. It's now a scooter and it's become more usable. Some people call this the minimum usable product.

But people’s legs still get tired. And sometimes they want to travel further and arrive less sweaty.

Usable turns to lovable

So you iterate again and build them a bike. It’s more complex design makes it better for longer journeys. OK, so you can’t use it to whizz around the office anymore. But it does get you to work and across the park quickly and efficiently.

And it’s fun to cycle along and feel the breeze. It’s probably the minimum lovable product.

But unless you’re a cycling enthusiast it’s still tiring to use on that weekend trip from London to Cornwall. And who wants to arrive at their Monday morning job interview even just a little sweaty?

The motorbike is enough

The motorbike solves the problem. It takes the user from A to B quickly without effort, even 200 miles away. They’re happy because they still get to feel the wind in their face.

You could stop there. You’ve actually solved the problem.

But maybe you find that some users want to travel together, or carry their kids. So you build a car without a roof, so they can still feel the wind in their face while travelling with others.

And what if it rains? Then you build a roof.

Why you can’t know all this in advance

It’s easy to look at the car metaphor and think that we could have worked out what to build in advance. It’s particularly easy to think this because the car is such a familiar product.

With good upfront analysis you can work some of it out. For example maybe the original problem was about taking kids to school in the rain. You could still have started with a skateboard (or two) and raincoats, or prototyped a bike plus trailer.

But real life isn’t like that. No amount of research or analysis will tell you what’s going to happen when someone uses your product. There will always be assumptions. And assumptions and lack of testing leads to flops and failures.

SOME FAMOUS FLOPS

• Lego Universe online game – tried to build it to perfection before releasing
• Radar app – Samaritans’ app wasn’t very well tested
• Israel’s electric cars – they refused to launch until they had a full network of charging stations

SOME FAMOUS SUCCESSES

• Zappos – tested online shoe sales using pictures of shoes from a shop down the road
• Lego – Lego designers have cool jobs where they get to test new characters and kits with real children first
• Spotify – tested whether they could make online streaming work consistently enough before they went anywhere near building an interface

Learn to design iteratively

learn how to build your own digital service skateboard with our Design Hops. We'll teach you how to apply digital service design principles to your organisation's service delivery challenges. Sign up here (it's free).