Text of talk given by Mark Brown in the session ‘Co-design for Mental Health – Patients, Clinicians and Minecraft: How We Need to Work Together in the Digital World’ at UK Health Week 2015 on 4th March 2015 at London’s Olympia
In some respects I think I might be preaching to the converted here, but bear with me for 15 minutes. The title is “How we need to work together in a Digital World”; so I’m going to share with you the process by which the HTML5 web app Doc Ready came into existence and share some observations along the way.
Hands up: I’m not a tech person, or a design person. I’m a mental health person. I experience mental health difficulties myself and I spend the majority of my working life in mental health.
I was lucky enough to be involved with the development of Doc Ready, a very simple web based app that does one thing and one thing only: it helps young people (or anyone else) prepare for their first visit to the GP to talk about their mental health. It was delivered by a team comprising of Enabled by Design, FutureGov, Neon Tribe and my own company Social Spider. For securing the contract to begin development to launching a public beta of the app took five months. Which was pretty nippy, I reckon.
Often in mental health we make services that people don’t like. It’s really easy. All you need to do is not spend time listening to people, follow only what desk research tells you is best, don’t show users what the service will be like and then only let them try it once it’s finished. Unfortunately with Doc Ready, we didn’t do this.
Working with people makes sure you avoid putting loads of effort into solving a problem that doesn’t really exist with a solution that doesn’t really match the issue it addresses. I keep looking at mental health services in general and thinking: ‘I can’t imagine what user expressed problem is is being answered by the way this service is designed.’
All projects have constraints. These may be financial, technological, political, knowledge-based. Blue sky thinking, that is thinking without taking account of constraints, is brilliant when you’re trying to come up with ideas. It’s bloody awful when you’re trying to solve problems. The way that Doc Ready was developed involved the people making it directly interacting at all stages with people feeding in their views, ideas, preferences and insights. In doing so they could respond directly to ideas being fed in. This constant feedback forced us to think differently about aspects of the projects and our responses to that feedback invited those providing it to bring their own invention and ideas to the problem.
Traditional public sector involvement mechanisms generally begin from the position that the problem has already been identified and that ‘stakeholders’ will feed into its eventual solution. The professionals set the agenda, shape the interaction then weigh up the contributions.
Doc Ready came into being by a different route via The Paul Hamlyn Foundation/Mental Health Foundation Innovation Labs programme. Across two Labs ideas for digital mental health projects were created by young people; then a selection were refined through further collaborative work. These were then put out to tender, with funding coming from Comic Relief and, in the case of Doc Ready, the Paul Hamlyn Foundation itself. I was there at every stage, from Lab one all the way through to launch and beyond.
Engineers solve problems. Co-production in tech is about delivering great problems to engineers then telling them their solutions don’t work repeatedly until they do. Rather than assuming people already know the solution to the problems they identify, the process of honing the problem to be solved down should move from people knowing stuff about their own lives, to thinking about what that means, to thinking about how that might be changed.
This process can be seen in the way that Doc Ready only became Doc Ready in the second Innovation Lab. It began the day as an evolved Lab 1 idea about building a Star Trek type translator for GPs that would turn teen speak into doctor speak. The problem that had been identified was a real one – young people feeling that GPs didn’t understand them – but the solution wasn’t quite right.
In my experience when put on the spot and asked to come up with a solution to a wicked problem; people usually come up with an idea that isn’t actually THE answer but one that actually helps to clarify the problem further. By the end of the second Lab, our small group of participants had turned it around to being something that young people could use to prepare what they said and the basis of what later became Doc Ready was established.
One of the basic rules of innovation is ‘listen to people, but listen to the right people’. We co-produced Doc Ready by making sure that everyone involved in the process was doing the bit that was best for them to do. You can’t bolt on co-production to an existing project model, it’s about making sure that the right people are in the right place at the right time to move a project forwards.
Throughout Doc Ready’s development we spent time with people, checking all the way along the production process to see that what we were developing was in line with what people actually thought might work.
This isn’t what usually happens in mental health.
Traditionally involving people with mental health difficulties in projects has been done in two distinct ways, neither of which is particularly innovation friendly.
The first way is consultation. Usually this involves asking people what they think of a particular thing prior to it being developed or put into action. It can also be asking them what they thought of that thing once it has been put into action (or ‘brought to market’ for all of you product development types). This can usually be reduced to the question:
‘How much did you like our goods and/or service? a) Loads, b) lots, c) quite a lot, d) loads and loads and loads or e) I hated it.
The other form of involvement is the strange beast that is now masquerading under a number of guises, the most recent of which is ‘crowdsourcing’. Crowdsourcing is actually a term that describes ways of people feeding in small bits of something (ideas, money, processing power) to build a bigger something. It doesn’t mean just asking people for ideas, like when a service or project will ask a group of people with mental health difficulties ‘so, tell us what you would like or tell us your ideas.’ This is often accompanied by lots of open gestures inviting people to share their ideas.
It may sound like this is more likely to generate good ideas for change, but usually it doesn’t. Putting people on the spot and asking what they’d like generally delivers responses that look very like what people have had before. Innovation is a process, not an endpoint It also makes no difference at all if the organisation doing the asking holds all of the cards and plays them very close to their chest, failing to give any indication of whether it financially or organisationally possible to take any of these ideas forward. Most people aren’t app developers. Most mental health professionals aren’t app developers. Both groups might be app users; both will have different perspectives on what problems need to be solved. Both will probably not pull a winning tech idea out of their hats like an end-of-the-pier stage magician.
Consultation doesn’t change things because it only asks how much people like your idea, product or service. It doesn’t really involve any collaboration at all. ‘Crowdsourcing’ looks as if it changes things but actually doesn’t, as the there is a fundamental dishonesty at work; we’ll ask you for your ideas but we’ll only do the ones that suit us and we’ll never tell you the reason why. It looks collaborative but is, in most cases, just a way of dressing up consultation as participation without fundamentally changing the way it works. Being cynical, ‘crowdsourcing’ just assumes that no one who belongs to a category of people who experience difficulties could come up with a worthwhile idea in the first place because it separates them from any of the mechanisms they might be involved with to make the solution to a problem happen. People who say ‘ideas don’t care who has them’ are usually people who want your ideas for their own and have no intention of involving you in any future application of them.
The Innovation Labs used persona work (collaboratively making up a fictional character representative of a particular set of user needs based upon real experience) to enable those involved to bring their knowledge of the real world of mental health difficulty to bear upon the question of ‘what could be made that would make life better?’ The development of Doc Ready used the same technique.
Instead of saying to people ‘what are your problems and how do you want them solved?’, the process asks ‘what kinds of challenges might different young people with mental health difficulties face and how haven’t they been answered so far?’ Using persona allows people to move from just discussing their own experience to collaborating on ways of solving problems faced by others. In essence, it helps us to move on from either of the two traditional involvement mechanisms in mental health.
For anyone’s involvement in a project to count for something it must have a weight and a value. The best way to give it that weight and value is to make sure that it is directed toward advancing the progress of that project. If you’re trying to build something for people to use, how can it make sense to leave people out of the process of building it?
Often people who experience mental health difficulties are involved in projects on the basis that ‘they have lots of personal experience’ but in ways that are actively structured to minimise the importance of their contribution. Asking for people’s opinions or people’s ideas without any idea of how they’ll change the shape of your project might be market research, but it sure isn’t involvement. And it definitely isn’t co-production.
When I talked to people about the Doc Ready idea their response ranged from ‘cool’ to erm…’. Some of them had plenty of opinions about how it might, or might not, work. However, as expected this didn’t really give us any solutions about how to make Doc Ready happen or what the final thing should actually be like.
This is why it makes sense to co-produce and co-design.
In app development it’s also pointless showing people a photoshop mock-up of your app and asking them what they think. They’ll either say ‘lovely!’ or ‘rubbish!’. This won’t tell you anything about the thing that you’re actually making. As the folks from Neontribe are fond of saying “Photoshop mockups sign checks with the end user that your development team can’t cash.” The point being it’s only worth showing people things they can break, play with and make fall over.
Adopting ‘fail often, fail fast’ and other similar lean development mantras we sprinted ahead and created six paper prototypes of ways the app could work. Made entirely out of paper, these were real concrete devices with sliders, buttons, text panels, menus, and even pop-ups. Watching testers try them out and pull them to pieces gave us direct, experiential insight into the functions and methods of interaction that people would value most in the app.
Using this learning we built a quick, rudimentary working version of Doc Ready. It included a version of the cloud of experiences and feelings that was very detailed. When we showed this version to people they hated it. So we created the same function in a different way, with more space for people to input their own experiences and far less ‘symptoms’. They much preferred this.
What’s important to realise here is that it didn’t matter how much we’d talked to people about how this core bit of the app would work, it was only when they saw it and used it that they could see what they did and didn’t like about it.
It’s vital in innovation to have this kind of flexibility in your development process. You may need to change, change and change again before something works; so quickly getting to the point where you have something you can test is vital. If you don’t, you’ll be a year and 90% of your budget into your project before the people who you’re building it for get the chance to tell you it’s crap.
In a mental health service world of limited resources and squeezed funding it’s tempting to see doing stuff with people and spending time with them as a luxury.
But if you don’t spend time with people, if you don’t get up really close to how they feel about the problem you think needs to be solved and as importantly keep returning to those people every time you think you’ve solved one of the problems they set then you might as well dig a great big hole in the grounds of your building and shovel in bundles of cash each day gnashing your teeth, shaking your fist at the sky and howling inconsolably ‘we built it and they didn’t come.’
Which is no fun at all.
Mark Brown is development director of Social Spider CIC. He is @markoneinfour on twitter
(Much of the content in this talk appeared in a different form at the Innovation Labs website)