User centred design ‘hacks’
How to do user centred design when you don’t have the resources to work with researchers or designers.
When I was commissioned by The Catalyst to create experimental content around the idea of user centred design ‘hacks’, I had a hunch there were examples scattered around the public and charity sectors. All I had to do was go out there, collect these examples and bring them together into a valuable resource.
When I threw my Typeform out, the first question was ‘What is a hack’? People challenged the term, suggesting it diminished the efforts of people in this space. I began talking about it as ‘design in the real world’. But what I still think the word ‘hack’ does, is talk to the patched together workarounds that I was looking for. The tangible, quick and easy approaches you can pick up tomorrow if you have no funding and limited time.
On my travels, I found that this had been attempted before (like most things have). Linn Vizard at Made Manifest and collaborators Spencer Beacock and Marie Serrano worked to identify barriers to user centred design in the Canadian Government and created a deck of barrier cards. They also ran workshops globally to identify hacks and collected them in a spreadsheet with the intention of growing a library.
barrier cards.
On speaking with Linn I found she’d had a similar experience of struggling to dig out those tangible and practical hacks to actually doing design and research that we were both searching for. The spreadsheet tells a story of what people need when they are building design maturity in a Government or a large scale organisational context. A lot of the hacks focus on selling in the approach, getting buy-in or securing funding.
The submissions into the Typeform were also interesting. Eleven out of twelve of them focused on user research rather than design. Some were a mix of both but there was only one submission that was purely about design. And if I’m honest it wasn’t a hack. It was a well thought out mini design project, off the back of a larger piece of work with an agency.
This tells us something in itself. That ‘hacks’ are more suited to research than design. But why? Sophie Rankin recently ran an event to ask the question ‘What makes good research?’ This question gets to the heart of what we’re grappling with here. The premise that the quality of user research is related to the level of knowledge and experience. That may be true, in some cases, but a lot of organisations can’t afford to hire or contract ‘professionals’ and don’t have the time or space to train their own people. Surely something is better than nothing? And is that an easier mantra to subscribe to for research than it is for design?
It’s important to point out, as Sophie does, that there are aspects of user research that shouldn’t be ‘hacked’. Professional user researchers can help ensure you’re not causing harm to yourself or others. This is especially important in areas where you’re working with vulnerable participants or exploring sensitive topics. There is rigour in place for a reason in these areas and anything involving safeguarding, consent or data protection needs to be taken seriously.
But there are five hacks that I can share. Quick and easy things people can do to start understanding the needs of their users without expensive tools, professional expertise or a whole project.
Ask users a question when they sign up
Sign up processes are usually fairly functional. This is the point when products or services gain a valuable extra user. Organisations are wary of causing any friction here. But this is an opportunity to gather user insight. When people sign up to Bloom, a programme to help people learn and heal from trauma run by Chayn, they are asked what their hopes for the programme are. This insight is shared in real time on their Slack. Hera Hussain, Founder of Chayn says; “It’s like a stream of consciousness from the users. It’s a really effective way of operationalising user insights and it doesn’t cost us a thing.’Turn troubleshooting into user research
The idea for this piece came off the back of some work I did with Reach Volunteering. At the time they were a small team with limited experience of research and design. One of the team was responsible for answering the phone to users who were having problems. She started recording the issues she was hearing and used these calls to not just fix the problem but also to more deeply understand the needs of the users.
I was excited to see a submission from Reach in the Typeform that shared their experience, 4 years down the line, of front-line staff carrying out useability testing. “We created scripts for them, gave them email templates to use and they're now in the process of running one-to-one exploratory chats with our users.”Hearing/seeing the experience of users first hand
A few people shared this as a hack and I’ve had experience of this myself first hand. This is especially helpful for organisations that work at an arm's length from their users and don’t have day-to-day contact. Listening to call recordings or observing people using a product or service can be enlightening. Complaints are also a good source of insight that in larger organisations are sometimes reserved for a particular department and not linked in with wider service improvement.Join up insight from front-line staff
Organisations with people working in front-line roles are likely working to improve their service on a day-to-day basis. They are the real service designers of the world. However it’s also likely these people are time poor and focused on fixing the problem that’s right in front of them. Finding ways to hack the methods that front-line staff already use to record the problems they are seeing, and joining up this insight could help uncover wider areas of opportunity to improve services. This is possibly not as easy and quick as some of the other hacks offered but could be valuable.Job swap
This is a bit of a wildcard and completely untested but a way for staff to gain insight into the needs of service areas from a new perspective could be to swap jobs. This wouldn’t work with all jobs or in all organisations. If swapping isn’t practical perhaps shadowing. This could be especially valuable in larger organisations where the service journey crosses a number of different departments or areas.
It’s interesting to me that this experiment didn’t play out in the way I expected but that’s a learning in itself. I’m pleased to be able to offer my reflections on why, alongside a few hacks for organisations to try. I’d like to thank everyone who contributed insights and hacks that have helped shape this piece.
If you have a hack you’d like to share I’ll keep the Typeform open and monitor it for new submissions with a view to growing this list with any additional hidden gems that I’ve missed.
