Last week I had a brilliant day helping mHabitat run a workshop on participatory design. They asked me to share my thoughts on co-designing services with users, in particular my experience working with vulnerable communities, and specifically building Elefriends – now the UK's most successful peer support platform for people struggling with life.
The most important question
As a software engineer, I'm constantly asked if it's technically possible to build something specific. Nowadays it's possible to build pretty much anything. The real issue at stake is figuring out if people will really want to use the thing, before you start to build it. With this is mind you should start by asking the question: "Should it be built?". This is exactly where Elefriends started.
A popular way of helping to answer this question is by using an approach called the Lean Startup defined by a guy called Eric Ries. It's based on the thinking that at the end of a failed project, people pat each other on the back and say: "Never mind, at least we learned something!" Ries says so why not focus our approach on learning from the very beginning? His Lean Startup approach advocates doing this in small rapid build-measure-learn cycles – basically as a series of experiments.
So start by building the smallest and simplest version of your new idea (called the Minimum Viable Product, MVP). Measure how people use this prototype and don't work on new functionality or improvements until you have measured real interest. Use metrics to learn and tweak your idea based on actual usage. Build the next version based on these insights and repeat the cycle of improvements until you have a product people really want to use. Basically, "fake it until you make it".
Using this build-measure-learn approach, Elefriends has grown to be a huge success from what started as a simple prototype. Today 2,000 private messages will have been sent and at least 50 new people will have joined the site. Every month, members publish over 400,000 posts and comments. Every six seconds somebody posts a message supporting each other through often dark and difficult times
Seven tips for participatory design
Without further ado, here are my seven tips on participatory design:
Create a following of fans
To be in a position to engage users in your product's design, it's important to start by creating a community of supporters who get behind your idea before you even start designing. To do this you'll need a strong vision. Think of your product as a movement, with a vision and values. Without a strong vision, it will be hard to pivot and change your strategy.
This initial stage is all about mobilising a group of fans; super engaged users (eg. working groups, beta testers, 'digital ambassadors" whatever you care to call them) to support your vision. Branding, tone of voice, values, vision and mission are all super important to this end.
Once you have a group of hardcore fans, then you can test new ideas on them. There's no need to build any software yet. You can make paper prototypes, or animations of what your solution could look like.
Elefriends had a head start, as they already had a Facebook group of 4,000 people to work with before the new platform was developed (called "The Elephant in the Room"). Many of them are real life friends and committed to the idea of making an online community work.
Using social media channels is a great way of gathering together potential users who are interested in your new digital product's mission.
With Elefriends we were able to make paper prototypes of the online platform and share them with a small group of engaged users before even building the first version of the platform. They were able to tell us which features and ideas were unsuitable; thus saving a lot of wasted development time.
I also recommend getting this group of hardcore fans to help you define target users. We use a process called "Persona development" and it's something you can do with before any code is written, or screens designed. Personas are fictional characters created to represent the different user types who might use a site.
Involve users regularly
Second tip: don't just involve users at the beginning. Make sure you regularly consult with them during development. I recommend at least monthly user testing sessions.
The Government Digital Service recommend that every six weeks, all members of the development team spend at least two hours consulting with real users.
Also make sure that you "get out of the building". Mind were very good at consulting with users from all around the country. When I worked with Girlguiding, we went on tour for a couple of weeks travelling up and down the country to speak to a huge mix of people. I've seen too many projects fail because a London-based client hasn't bothered venturing up north to speak to people!
Keep making prototypes
For Elefriends, we made sure new features were prototyped, and users were consulted on new ideas before building them. We even made fake prototypes of new functionality to see what people thought about it. (See below for an example).
When thinking about users' needs, I've found it useful to think about what stage in the engagement process users are at. Joshua Porter describes five levels in his book Designing for the Social Web: The Usage Lifecycle. They are unaware, interested, first timer, regular and finally passionate.
You can think of each level as follows:
Start with unaware
Make sure that you don't rush into designing and building features for regular users before you have a decent traction of users converting from unaware, to interested, to first timer and to regular.
I've seen many a project fail because the focus has been on building all the features before there has been decent conversion from unaware, up the levels and past first timer.
So, keep your initial focus on getting decent conversion from unaware, to interested and to first timer.
This is a hard lesson for engineers to learn. If their job is to build lots of complicated stuff, then this is what they will naturally gravitate towards. But to succeed with participatory design and co-creation it's important not to start building a huge Death Star.
By keeping things small and bulding in baby steps, you'll find it easier to take on feedback, make tweaks and ultimately change direction, if you need to. So focus on the core offer, keep it simple and gradually build on top of it.
Elefriends started as a really simple posting wall, without many features. The moderation features were simply an email link. More features were added after consulting with the community, user testing, surveys and prototyping.
Don't do a big press launch
Despite its success, Elefriends has never been launched. A big press launch implies that a product is finished and perfect. If you do have to launch, then make it very clear that you want feedback and that realise there could be issues with your product.
A bad example is the Samaritans Radar that was withdrawn within a couple of weeks after launch. It was a great idea designed to offer people a second chance to see a tweet from someone they knew who might be struggling to cope. After launch there was a massive online backlash about data protection and privacy issues. This could have been avoided, if the application had had more users involved in the design, and if the press launch was delayed until the application had been tested properly by real users.
Explain the process
When you are consulting with users and involving them in user testing, prototyping, research or co-design workshops, make sure you explain the process you're following and the context of the work you're asking them to do.
Don't patronise them by assuming they won't understand. I find users easily understand the five engagement levels, and can put themselves in the shoes of unaware users. It's also useful if you're working with passionate users to explain the different types of users and get them to think back to when they were further down the engagement levels.
It's also a great idea to set up a project blog to share the design process and report progress to your fans. It also serves as a place to collect feedback about the project and recruit new participants.
Build in feedback
Make sure the tool has feedback built in. For example Elefriends has its own 'feedback wall' which is a separate space for users to discuss the tool and potential improvements. It's important to keep this separate from the core discussion space – you don't want people trying to discuss their mental health issues at the same time as other people are complaining about the tool.
Above: Example feedback wall from Elefriends
Above: Feedback on Elefriends.It helps the team to the be motivated and focussed on the vision.
Remember to have fun!
Finally, remember this is all about real people. So think of yourself as a host at a meal. Make sure it's fun for people to take part. I always make sure our workshops are fun and we have a 'no screens' rule. Instead we use lots of pen and paper, sticky notes, cutting out and gluing! Anything to make the activities fun.
But be safe
Last but not least, it's essential that you make sure the environment is safe and you're sensitive to people who may need to take regular breaks away from what you're doing. So, make it clear people can step away and there are safe spaces available they can retreat to, if necessary.
If you want any more information, then please do get in touch.