“Design is as much a matter of finding problems as it is solving them.” – Professor Bryan Lawson, architect and psychologist
If you’ve read the first two parts of this blog series (which I highly recommend), you’ll be familiar with the pros and cons of design thinking (cheers, Gabi) and with a whole host of successful examples of design thinking (muchas gracias, Rosie). In this third instalment, I’ll look at how you do it: how to implement design thinking to achieve your desired outcomes.
As Gabi noted, Natasha Jen persuasively criticises the dilution of the term ‘design thinking’ to essentially refer to a pretty diagram such as the one below with its straight-forward, checklist-style appeal. This doesn’t reflect or encourage the hard work, innovative thinking and, most importantly, collective and constructive criticism that should be taking place at each of these hexagonal checkpoints. These core principles of any good designer’s work have slipped away from the concept of design thinking.
So buckle up. We’re going to put them back in. We’ll walk through today’s often over-simplified design thinking process and consider how you can apply design thinking in a meaningful and ultimately successful way.
Step 1: probably the most iconic phase of design thinking, the one it’s most famous for.
This is the stage where, instead of jumping straight into fixing the problem that’s been raised (say, employees aren’t adopting a new system very well), you take a step back to consider what the problem actually is and if the solution you’ve been asked to provide (say, more elearning to train employees on using the new system) is really going to fix it. It’s the stage at which you consciously work to empathise with end users, putting yourself in their shoes to uncover what the true barriers are. This Barrier Identification Tool (BIT) is a good place to start when considering what different types of barriers could be involved.
There’s a whole host of ways in which you could approach this step – focus groups, shadowing, questionnaires, following the end user’s journey yourself. Whatever method you choose, the difficulty lies in asking the right questions, in the right way. You don’t want to ask closed or biased questions which unintentionally lead your audience to a pre-conceived answer. For example, if you ask employees how they think the training on the new system can be improved, you’re making an assumption that there’s something wrong with the training.
Instead, the aim is to pose open, unbiased questions that leave room for the audience to raise issues you may not anticipate so you can uncover what current users are truly experiencing. Using this method, you might discover that employees aren’t failing to adopt the new system because they haven’t been provided with good quality training; instead, the problem is that they don’t have time to take this training in their working day. Or that the training itself does not reflect their reality. Apart from asking the right questions, you have to consider when you do get the response what the biases and perspectives of the group are already and do they represent the target audience accurately in terms of age, gender, geographical location, role etc? What if any data analytics do you have to support your hypothesis and is this then borne out in the responses you receive from the focus group?
It is essentially evidence-based design.
Now that you’ve empathised with end users and worked out what the real barriers to success are, you can get on with working out how to fix it, right? Not so fast, my friend. After investigating the sources of the problem, any good design team will take a moment (really, much more than a moment) to pause and reflect on what you learned from step 1. To make sure step 1 isn’t just ticked off and then completely forgotten as you progress through the project, you need to define the problem based on its findings.
Taking the time to commit this to paper, typically using a Theory of Change model document, forces you to accurately and specifically describe what the problem is and what your desired outputs and outcomes are. This process helps identify any gaps or confusions in your understanding of the problem. If any are identified, you can go back to end users for clarification before design work begins.
This step is crucial to ensuring that the important work of step 1 remains centre stage throughout the project: defining its goals and then leading your thinking and decision-making so your end solution hits the mark.
Thanks to step 2, you know where you’re starting from (what the problem is) and where you’re going (what goals your solution needs to achieve). Now you need to work out how to get there: you’re ready to start considering what the solution might look like.
Initially, you want to generate as many ideas as possible: the more out-of-the-box,the better. So, get your project team together, and, ideally, individuals outside the team who could give some good contributions.
Brainstorm together. Use post-it-notes, a whiteboard, a digital ideas board, whatever works best, to build up a messy web of ideas, some fully fledged visions, some just passing thoughts. From this broad base, you can then start to narrow down and construct a solution.
Once you’ve identified the most-promising ideas to address the problem, you can prototype these. The purpose of this is to be sure that your proposed solution really is going to fix the identified problem before you invest time and resources into developing and implementing it in full. Hence, you develop an indicative, low-cost version of the solution. This allows you to test something tangible and collect results which can inform any amendments or significant redesigns of the solution.
Your prototype may not cover all elements of the solution but even testing parts of it is likely to highlight any major flaws. For example, if your solution is an adapted app-based training course, you might want to develop a content outline and a wireframe of mobile-first digital layouts before writing and developing the course in full.
Testing a prototype with a sample group of end-users will allow you to reconnect and empathise with them once again to see how far the solution really goes to overcoming those barriers.
Once you’ve done your prototyping testing, perhaps going back to the ideating phase and prototyping again if needed, and are confident the solution is going to work, it’s time to develop the solution in full and test the real thing. Testing and evaluation to see whether the solution will actually achieve the desired outcomes is a topic in itself and will be the subject of another blog! But ideally comparator groups and quantitative and qualitative methods are all desirable. This then leads to a re-iteration of the cycle again to refine the solution.
And finally, the most important step that runs through the entire design thinking process: constructive criticism.
Everything you do throughout the process should be shared amongst a group of peers. We all know how much a single fresh pair of eyes can help when you’ve dug yourself into a bit of a hole with a piece of work. Well imagine what several fresh pairs of eyes can achieve before you’ve even got into the hole. The more peers you share and discuss your work and thinking with, the more viewpoints you will get to inform your thinking. Each question that’s asked is an opportunity to ensure your end solution is the best it can be.
The designer is clearly the maker or breaker of a behaviour-led design solution. At Saffron we have been using this approach for decades and that’s why our solutions always make a positive impact and lead to performance improvement that is quantifiable. This is a longer process than banging out a rapid course, but then, the results speak for themselves
Each step follows on from the last but also feeds back into it, revising and refocusing your thinking and design as you mould your solution to perfectly target and resolve the real problems at hand.