Designing in the real world

Design as a continuous problem-solving activity

Too often design is presented as a linear process – from insight to implementation (Livework even wrote a book with this sub-title). In practice, design is an ongoing interaction between problems and solutions. We need to understand the problem to get to the right solution, but it is often not until we test a possible solution that we fully understand the problem.

Design experiments to test assumptions not features

Let’s assume you have a challenge that you have looked into in-depth and concluded that it can be resolved, and you have an idea of what the solution is. Now, identify the biggest risk to the success of the solution and what assumption you have made that, if wrong, will blow up in your face. These are the assumptions you need to test first. Prove yourself right and you can move forward, prove yourself wrong and it is back to the drawing board, but at least you know more about the problem.

When you put something small out there and learn fast, you reduce your risks in the long run. Investments are smaller. The impact on your brand is less if things don’t go to plan. You haven’t spent years making a fully-fledged service only to find its’ failings when you launch it in the real world. One of the great things about designing for services is that you can put things into people’s hands and prove/disprove your assumptions without building the whole thing. Match this with a critical assumptions approach and you have a way to de-risk your designs.

Use a critical assumptions approach

A critical assumptions approach is an experiment designed to test the key factors that will make or break your solution. Service experiences have a natural progression, from initial awareness to long term use, and the critical assumptions often relate to the early stages of understanding the offer and first use. This helps in the identification of which assumptions to start with. See the below illustration for how this might look across a service lifecycle.

For example: Working on a Digital Mental Wellbeing service, we conceived of a service that was delivered through existing online spaces such as social media, blogs, and forums. To experiment in this space we designed a number of Instagram and Facebook campaigns that we could at first deliver in small numbers and observe engagement. By doing this we were able to learn what worked through small, cheap and quick tests that built evidence that our strategy worked and enabled us to scale the service based on real-world evidence.

Devise ways to put something into the world with users

It is important to build in a mechanism for capturing users behaviours and responses to enable learning. Bake the evaluation into the design. Think about testing the overall solution first – the proposition – there are probably assumptions at a high level that you need to check. This can mean very simple tests such as a landing page, email sign-up, handing out flyers on the street. Not only does this test the proposition but it also helps you learn how you might market your future service. Services depend on customer behaviour to be successful. Think about the assumptions that you are making about what people will do and devise ways to test these.

Tip: be careful not to devise ‘vanity’ metrics, for example, ‘50 new sign-ups’ and instead ensure that metrics are relative to what you might expect to see across touchpoints and similar industries.

Gain real-world reactions

To test critical assumptions in the real world requires an experiment that engages people in an early expression of the service, something that we can create quickly with low investment. You are building prototypes that enable you to test the experience for customers, enabling you to move beyond hypothetical proposition reactions to get reactions to your services for real. These kinds of tests have a huge advantage of traditional research in that the data is real and behavioural (things people actually do) rather than staged and hypothetical as with a focus group. The data gathered from actual behaviour has multiple advantages over a focus group or survey. It cannot be disputed, is not swayed by bias in your test, by poor recruitment or screening processes. Most importantly it cannot be swayed by how well you are able to communicate your concepts as it lives and dies on how customers respond to what is in front of them.

For example: When exploring new service concepts for commercial vehicle fleets with Ford, we imagined a service to make regulatory compliance easier. Livework defined a number of experiments that would enable Ford to learn about the concept’s desirability. The experiments were based around putting the concepts out into the real world, primarily to test the value proposition and the most critical assumption, which was: ‘will fleet managers want to sign up to this service?’

Excite stakeholders and gain understanding about how to run the service before committing to scale

There are additional benefits to this approach in terms of relationships with people both internally and externally. Making tangible tests can help to address objections from colleagues and people along the journey. Engaging customers in the innovation process is exciting for them and makes them feel valued to the extent that they become highly engaged advocates.

Finally, a prototype is the service operation in a microcosm. It is a way to develop the service at a small scale, learn about what works and what doesn’t up close and with customers. Only once you have something that works should you aim to scale.

For example: During the development of a new service for farriers (the people who shoe horses) we supported a pilot in Australia. Conducting research in a niche market on the opposite side of the world meant we had to think differently. We used a private Facebook group as an innovation lab, to test communication, branding, value proposition, and more. Acting as community moderators gave us daily interaction with participants and shaped guidance on voice and tone, tech support, customer service, and moderator requirements. 13 testers used the app for 4 months, capturing their use and preferences through digital diaries, with the local team conducting interviews. We used Google analytics, app usage data, and clickable prototypes, capturing all learnings into an insight database.

Problems and solutions are both assumptions requiring validation

Testing assumptions using prototypes that simulate critical aspects of a service enables us to move forward at low cost and reduced risk with imperfect data or insight. The more we test in the real world the more firm in our conclusions we can be. We can never be 100% sure because there are no guarantees when it comes to human behaviour – but we also cannot argue with real-world behaviours.