I have just said goodbye to 15 brilliant people on Cardiff Metropolitan’s PDR ‘Greenhouse’ training. Led by Dr Anna Whicher and her team, the course is aimed at ‘public service innovators’ and gives you the skills and capability to deliver effective service design projects.
As a psychologist working in a public sector Behavioural Economics & Data Science team, I went in to the course wondering what design was and if/how it can be applied to policy and regulation. What are its roots? Is there an underlying theory? Can you prototype a policy or regulation? What are the benefits?
I haven’t answered all these questions in the last 2.5 days, but hope to. In the meantime, here are 3 things I learned:
1. Just do it. Design as creative problem solving. I was obsessing with defining design. A tool kit? A way of reasoning? A way of re-arranging elements in a system? We didn’t cover the history or roots of design – we got stuck right in doing it. For me, it seems design is about thinking through practice – a way of solving complex problems which can result in better outcomes. The design process (e.g. the double diamond) and tools can be applied to pretty much any problem.
At work, most of us want to jump straight to the solutions. In contrast, the design process forces you to spend a lot of time defining the problem from the perspective of users’ needs (note, not always stakeholders) and to think concretely. In our applied design project for the Wales Life Sciences Hub we completely re-defined the problem. According to Anna, this is common. I think behavioural science can play a big part in understanding user needs, behaviours and defining the problem (as well as the experimenting in the ‘develop’ stage).
The OECD estimates that 80% of the impact of any product or service is determined in the design phase, early in a project when key decisions are formed and tactics established. Many of the outcomes policymakers seek are a result of early policy decisions. In government, policy successes and failures can often be traced back to decisions made in the first 10% of the process. Dr Andrea Siodmok.
2. Do it side by side, not me then you. My fellow Greenhousers were a diverse group – chemical engineers, statisticians, designers, behavioural scientists, digital and tech experts, architects and policy wonks. For the whole 2.5 days we worked, ate and drank together on our live challenge. Working with people totally different to you felt great. Plus we know from the evidence cognitive diversity increases team performance. Our user research anchored the whole process.
Collaboration is obviously good. But it’s rarely done. The whole policy-making process is typically sequential, siloed and separate from the end-user and the people actually delivering the policy. The status quo is to work alone on ‘your bit’, then maybe pass on it to another person or team to do some market research, then to another team to implement it.
Anna Whicher said “one of the biggest problems with the policy process is that consultation with the users comes after the policy options have been developed. Only a very small minority of users actually contribute to the consultation and feedback basically makes no difference.” This is no surprise: confirmation bias is the tendency to search for, interpret, favour, and recall information in a way that confirms one’s pre-existing beliefs or hypotheses.
Design has a critical role in facilitating policy makers, end-users and the doers (the people who implement the policy or make it happen) right from the start in defining the problem and working side by side to implementation. As one Greenhouser (Gavin Skull) said: it’s all about “designing with people rather than for people”
3. User error to use error – it’s us, not them. Dr Andrew Walters described the paradigm shift in design from describing errors as user errors to use errors. This shift is much bigger than dropping an ‘r’. Previously, when a user interacted with a product and something went wrong the most common explanation was ‘user error’. This term implies two conclusions: first, the direct cause of the problem was the user, and second, that the user was therefore at fault. Instead of fixing the error-prone design, stakeholders (be it the responsible organisations, authorities etc) can attribute the error to the user. In contrast, ‘use error’ avoids the immediate assignment of cause by identifying only what happened, not why. The focus shifts to the likely cause – the poor design of the product / service / system – not the user.
This is hugely relevant for policy makers. When a policy doesn’t achieve its intended outcome, how many times is the citizen/consumer ‘blamed’? People are irrational, they didn’t have the information, they didn’t understand, they lack self-control, they are dumb. But surely we need to design better policy in the first place! And design it for the end users (and so it works for implementers), not the requirements of the system. One example – competition is generally a good thing for driving better consumer outcomes. But competition relies on consumers switching to better products and services. Switching rates across different markets are often very low (for good reasons). But policy interventions are often designed to drive switching, then fail to work. Are they failing because policy makers are not designing from a user perspective, but from their/a system (competition) perspective?
I haven’t got the answers to all my questions – and now I’m not sure I’m even asking the right questions. I also have new questions:
- How do we think about needs vs preferences, given we know from the behavioural sciences that preferences are not stable or consistent, but often constructed in the moment (e.g. see here). How do we know what people really need/want?
- What people need/want now isn’t always in their best interests in the future (think food choices and financial choices like spending/saving).
I’ve certainly learned a lot. Thank you to everyone at PDR and my Spring 2018 Greenhouse cohort. Look forward to staying in touch and eating more welsh cakes.
Further thoughts to come. Views welcome!