Participatory Design as a Research Method
When you do user research, there are some things that are just hard to get at. People’s needs, feelings and motivation may be hidden beneath a layer of politeness or people may even be unaware of some of it themselves. This is where we turn to participatory exercises, to find ways to discover and talk about the stuff they couldn’t quite put their finger on earlier.
This winter we were in a situation at appear.in where we felt our mobile apps could be improved, but didn’t really know where to go with it. Interviewing users of the app about their habits and preferences hadn’t yielded much. As it happened, our designer Paul Holliday had just read an interesting book and was keen on trying out some participatory design. With inspiration from IDEO and Frog Design, we soon had a plan for how we could do this ourselves in a workshop.
First of all, we decided on our research goals for the workshop. We were to
1) understand use cases better
2) understand our users’ priorities for functionality on mobile
3) get some crazy design inspiration (nice to have)
Knowing what you are looking for really helps when choosing which activities to include, and which darlings to kill.
As participants for our workshop we invited our ambassadors, regular users of the appear.in mobile apps, and in another round some who were new to appear.in. We did 9 workshops in total, which turned out to be more than we needed. (As it often is, we didn’t learn anything new from the last few ones.) In each workshop, we divided the participants into groups of 3-4, and had one facilitator per group leading them through the day. Having a facilitator there at all times was important in order to maximize our learnings, as having multiple groups per facilitator meant we missed out on interesting discussions.
Structure of the workshop
The first task was to point out what was wrong with the current app. User interviews had failed to discover any obvious issues, and we didn’t expect it to be any different in the workshop. Our goal with doing this exercise was to warm up the participants by showing them that we were open to criticism. Also, we would have the “fix this” poster on the wall all day so they could note down new problems as they uncovered them.
Our plan was to get the participants into a design thinking mindset, starting broad and then narrowing in. We set off with getting an overview of all the situations where they currently use the app (or choose not to, for whatever reason). Then the groups would choose one of these scenarios to map out properly like a timeline.
Once we had the timeline of all the steps that made up a scenario, we asked what they needed to complete each step. After establishing that you need “at least one friend” and an internet connection in order to have a video conversation, we eventually started getting to features. (I use the term features loosely here, as it ranged from ‘a way of telling your friends you want to chat’ to ‘ability to mute microphone’.) And once we had a list of features for each step, we asked them to prioritize them.
The last part of the group work was to design the actual app. Our participants seemed really overwhelmed by this task, but after some gentle nudging (“how about drawing what a conversation looks like first, or maybe what it looks like when you open the app?”) they went at it. We had printed about 10 pages full of icons, design elements and inspiration for them to use, in addition to having phone outlines and colorful pens for drawing. Some groups found the print-outs useful tools, while others were constrained by having limits to their creativity. I’d say it’s better to have the icons at hand, but making sure you do a good job facilitating the creative process if needed.
For the most part, we encouraged the participants to lead and organize their own work. However, some groups had a “yes, and” attitude, which led down really crazy design paths until we asked them to explain their reasoning to us. For example, one group of iPhone users chose the Android navigation buttons as their icons, and randomly chose that triangle means schedule. Here, more guidance from the facilitator was definitely appropriate.
We let them have about an hour to design the actual app, which was too much for some groups, and not enough for others. Throughout the process, we each observed our group and tried to ask critical questions in order to help them make choices. Pointing out and discussing discrepancies between their prioritization in the last task and their designs was especially interesting. We also discussed some of the features we currently have in appear.in which they hadn’t mentioned in their list of requirements for the app. A lot of the learnings came from these discussions rather than from what was presented at the end.
After doing 9 workshops, we were overloaded by sketches, notes and quotes from the sessions. How does one go about analyzing this sort of material? A bit of grunt work, cataloging everything, was the first step. Pro tip: do make sure everything is labeled at the end of each session, you don’t want doubt about which group produced which sketches! Also, remember your research goals. The problems the participants point out and the discussions that go on underway are a lot more important than the sketches they produce.
In the end we had a long list of insights about people’s use cases and how they prioritize features. We had identified over 30 big and small challenges, both UI, UX, technical and social, and a handful of opportunities. How I got the team engaged in working with these insights is the topic of my next post.
