Proving the dough

Hola 👋🏻

I’m still trying out a bunch of different types of content on here to see what works, alas very little of it is getting much in the way of engagement. So I’m going to try some content that, while nobody ever asks me for, I can see there’s a market for it.

And by market, I mean I’ve not seen anyone else doing it, but know it’s useful.

How do I know it’s useful? Well, every Monday until the start of next month, I’m teaching two groups of teenagers how to do design thinking. While they’re obviously not my target audience, they are helping me to realise the kind of resources people who have never solved a problem or created something with design methods might need.

I’ve been creating lists of things that I know would make their lives easier (and help me to teach it). So as a dry run, I thought I’d start creating the resources that would be useful. These are tools and techniques that I’ve picked up or developed myself, from working in professional design studios for the last 20 years.

A lot of the content that exists out there is either targeted at design / tech professionals or people who’ve worked stuff out themselves and now do it (💪 💪 💪 to the people who’ve worked it out themselves).

Before I dive into the different tools and techniques that we use, and how we use them, I’m going to give you a run down of what the design process actually looks like. We all follow a variation on this process.

Discovery

The design process is usually split into two distinct phases, starting with discovery and moving on to design.

The discovery phase we look at:

• Problems
• The people with the problems
• Why it’s a problem for them
• What causes the problems

Essentially, we’re looking for why these problems are painful for our end user. It’s understanding these pain points that helps us to identify solutions to the pain points.

The key stages in Discovery looks like this

What’s the problem you’re trying to solve?

Believe it or not, in most (but not all) design studios we start with a specific problem we want to solve. The idea being that if you’re solving a problem, you’re helping to make someone’s life easier by giving them a solution to that problem.

The problem is usually defined by a Product Manager, or the board. We’re given a problem statement that we subsequently have to pull apart. We do that by carrying out research.

Research

There are more flavours to research than you might think, but here are just a few that we might pick at this stage:

• Jobs to be Done (JTBD) - we learn the jobs that people do as part of their day-to-day work or even around the house. The job never changes, how they do it can.
• Journey mapping - understanding the step by step journey someone takes to do something helps us identify causes and trigger points that cause the pain.
• Diary studies - these can inform JTBD data, but largely it gives us a longitudinal understanding of someone’s day-to-day activities.
• User interviews - we use these to dive into their insights, experiences, frustrations and pain points.
• Competitive analysis - by understanding what others are doing in the market to solve the problem you want to solve, or similar problems you can understand how to give you a market edge. This is one of my fave bits of research, and one I’ve used in creative ways to help clients catapult them ahead of their direct competition (my skills are a sheep-free zone 🐑)

The broader the types of research you apply, the better you’ll be able to help come up with creative solutions to spicy problems.

Research synthesis

When we’ve got research, we wring out all the juicy bits to help us move closer to where we should be going. We do this in the following ways:

• Empathy mapping - an empathy map allows us to climb into the shoes of the people we want to help. It can really help us feel for the people with the problems.
• Personae - a persona is a snap-shot of the person you want to help. Although if I’m being truly honest, most design studios don’t like persona because it’s a moment in time and our goal is to create solutions to help evolve that persona. Note, in design studios we never call them avatars.
• Journey maps - Journey mapping research gives us the data which we turn into a journey map, it shows how someone moves through a task, a job or an application. I love a good journey map, probably because one of my (many 🥴) super powers are process flows, logic flows and service blueprints.
• Pain point mapping - by collating all the insights from the research we sort the insights looking for common themes, pain points or problems that we can then solve.

To borrow (and bastardise) a Batman Begins quote, it’s not what we’ve got, it’s what we do with the data that’s important. You’ll notice, for example, that we don’t look for problems to fit an existing solution.

Define

Defining what we’re going to focus on comes from all that amazing research. We agree (with the people who hold the purse strings), what problem we will focus on and how far we might want to go to solve that problem.

Define can also allow be used to define what a strategy looks like. You’ve taken all the data and research, and use to accurately define the direction of travel you want to take things in. This is genuinely my favourite part, although I’ve never technically held a job with the title of strategist, strategy is effectively what I do, and what I kick ass at doing.

The way I see strategy is setting the direction of travel to go in, why you should go in that direction and how to do it. It brings me so much joy doing this.

We can also define what’s called the release strategy. This is where thin slicing comes in. At this stage you’re saying what each slice of the product you want to build, why that makes it a slice, and what signals you might be looking for to allow you to move to the next slice. However, this gets further refined in the ideate stage.

And pause

There’s a pause point between the two phases, in large design studios you don’t really know it’s there because we’re a perpetual motion engine. However, we run design work in what we call sprints. In every place I’ve worked as a contractor we’ve usually worked in two week design sprints.

At the start of the sprint we agree what our focus will be for that sprint for each team and what we’re aiming to get to at the end of it. One block of research can easily take one sprint, but often takes longer.

The pausing allows us to run what we call a retro (short for retrospective). We use an hour to look at what went well, what went badly, what we’d like to change and what we’d like to build on. It’s a chance to discuss spicy topics (like stakeholders who aren’t on board with what we’re doing). Done well, they’re transformational.

Design

This stage is usually the one most people enjoy. It’s the stage where we come up with ideas to solve the problem (the bit I enjoy) and what those ideas end up looking like (the bit I no longer enjoy so much). Design has four distinct parts to it:

1. Ideate
2. Design
3. Prototype
4. Test

The design phase should work in a loop. So you’re constantly designing and refining so that what you release is built on what you’ve learned. Each incremental (i.e. thin slice) release builds on the previous. Giving your end user a better experience. I say should work, because let’s be honest, there are a bunch of products out there where the release is designed to make the experience worse for you.

Ideate

We come up with lots of different ideas of how we could solve the problem. No idea is a bad idea. We often come up with daftest, most off the wall ideas because in between the chaos is where the great ideas lie. The best ideas, like Inception, are the simplest to implement.

Design

What will the thing look like in reality. We take the ideas we’ve come up with and turn them into something that resembles what we’ve thought about. This part is usually the one everyone likes and has an opinion about.

Did you know that these days, design doesn’t start with making it look pretty? Most large design studios now have content designers who design the content first. Well written content in any product or service is now the standout thing.

Prototype

We the designs and turn them into a prototype.

In terms of something digital, that could be a website or an app. We can create these using tools that create clickable prototypes which simulate how the thing works, or by building the front-end code that do something similar.

Think of it like building a set of a room in a studio. Done well you can’t tell it’s a set, but it’s not the real thing, you can’t move throughout the set like it’s a real house.

Test

We then take the prototype back to people who fit our customer profile and ask them to use it. We ask them to complete tasks that we’ve mapped as being pain points to see if the problem has been solved.

The testing tells us what works, what doesn’t, what we need to change and what we need to bin.

Btw, it’s always usability testing, not user testing. We’re testing the product, not the person using it.

Release

Most releases that you work on as a designer are so low key they barely register. Occasionally you’ll get to work on a big bang launch, but they’re a lot more stressful (as all eyes are on you). Let’s be honest, we’ve all pointed and cringed at a launch that has some flaws in it. If you’d ever worked on something with so many moving parts you’ll know how disheartening it is when someone picks out the flaws instead of the thousands of things that went really well.

Review

What should happen post launch is a review cycle that takes things that are working (so you don’t break them) and things that aren’t (so you can fix them). That doesn’t always happen.

Whenever I’m creating something for myself, I’m a perpetual loop of learning and adjusting. Can you see where I get my thin slicing from?

WHEW! That was a long one.

So here’s what I’m going to be doing over the next few weeks (months?!?) is create content that delves into specific areas of research and how to use that research to make better products or services for yourself.

I’ll be adding my secret sauce, my Good Fours, so you’ll learn how to work out what good looks like.

If you haven’t read about Good Fours yet, check it out next over here 👇🏻

The Thin Slice - Good Fours

Emma Chittenden • May 31, 2024

Hola 👋🏻 What does good look like to you, *personally*? I want you to hold that thought for me and let bubble away in your noggin, I’m coming back to it later.

Read full story →

Have an awesome weekend people!

Emma