Co-author: Peter Russo
Empathy workshops for non-designers
Empathy, the ability to understand the feelings of another, is an indispensable tool for user experience designers. We design better solutions when we understand the human environment of the user while they are using our product: are they relaxed, under stress, working with physical or cognitive impairments?
We’re not only better problem solvers when we’re empathetic, but, since empathy strengthens our active listening skills, using it makes us better researchers and collaborators.
Of course, empathy isn’t just a skill for designers: being able to quickly empathize with someone lets us start every conversation, whether problem-solving or negotiation, from a place of understanding, rather than judgement.
Empathy workshops help you understand users
Empathy workshops are facilitated group activities and discussions dedicated to helping us learn about people whose life experiences are sufficiently different from ours, because understanding their specific needs and abilities is crucial to designing for or interacting with them in a useful way.
HR teams often run empathy workshops to build a culture of understanding in their organizations. You may have taken one yourself (Fierce Conversations, for example).
Design departments use empathy workshops to help interface designers and developers build interfaces that users with physical impairments can use successfully.
The workshop described here is was intended for those wishing to learn design thinking. It was facilitated by UX designers who run meetups in Portland, Oregon, to promote design thinking for non-designers and accessible (also known as inclusive) design.
We combined forces to offer an empathy workshop that would help us engage participants in active empathy as they designed solutions for vision and motion impaired users.
Below you can see preparation, facilitation and results. We hope you’ll be able to use our work as a template you can modify to run your own empathy workshop.
Preparation: Finding Two Active Learning Exercises
We started with a brainstorming session with some wonderful food and wine — it’s good to keep people’s mouths full to give their brains space to work!
We began with an exercise to free our thinking: we could suggest anything related to empathy, with no regard to practicality, as one of us took notes. It’s important to designate a note-taker during brainstorming: they won’t get to participate as fully as the others in ideation, but they free up the others to ideate without fear that a useful idea may be forgotten.
Then, we defined constraints:
- We wanted the workshop to be an exercise in active learning, so we needed participants to jump into activities as quickly as possible. This meant that the exercises had to be easy to understand.
- We expected about 40–50 participants, so the exercises had to be suitable for groups.
- We wanted participants to compare solutions, but not get bored, so we needed two or three variations of the exercise, rather than just one for the room.
- We were financing the workshop ourselves, so materials needed to be cheap!
We reviewed our ideas with constraints in mind. We had talked about products designed for accessibility, like the OXO peeler, a kitchen tool designed for easy gripping. What if we had participants re-design familiar, yet inaccessible everyday items? They would already be familiar with the items, so they could dive into the activity quickly, and, if we chose wisely, we could furnish the items at a reasonable cost.
We settled on a redesign of a restaurant menu and a television remote control.
We planned two hours for the workshop. Participants would have 30 minutes for networking and pizza, followed by a 10 minute presentation to introduce concepts and terminology. Then we planned 15 minutes for a full-room exercise to help participants experience mild vision and motion impairment. We would ask them to think about their future, much older, less able selves, as they tried to use their mobile phones while wearing special glasses to blur their vision, and modified gloves to lessen dexterity. The main activity would require 45 minutes: participants would group together at tables. Each group would redesign either the menu or the remote control. We would provide both the items for re-design, and a context story of a fictional user attempting to interact with the items.
We would finish the workshop with 15 minutes for groups to share solutions with the room.
We hoped that, through simulations of physical impairment, and an exercise in applying design thinking to improve accessibility of an item for a fictional user, participants would walk away with an understanding of the power of empathy in identifying usability issues and how to approach a design problem using empathy.
For the menu, we googled for restaurant menu PDFs. We found one that combined both a visually attractive design with serious usability issues for visually impaired users.
For remote controls, gloves and strong reading glasses, we went to the Goodwill, where we found almost everything we needed for under $30.
Modifying the gloves
While the thin gloves were inexpensive, it was surprisingly easy to use the remote control through them. We wanted to recreate an approximation of the numbness and joint stiffness common with arthritis. So we added some padding to the index fingers and thumbs by cutting up a melamine cleaning pad and wrapping the fingers securely using a compression bandage. While there are more realistic (and expensive) options out there, this fit our budget and needs nicely.
We provided one context story per item (we’ll share the complete stories a little later). A context story is a fictional recounting of the full experience of a user interacting with a product — sometimes context stories recount the problem, sometimes they describe the solution. In our case, we provided stories around problems:
- Recently divorced Nate is on a date and is having trouble reading a menu because he left his new glasses at home.
- Meg is trying to work a new remote that’s difficult to use due to arthritis.
Guiding Participants Through the Workshop
With preparation complete, we announced the workshop on our meetup pages. The RSVPs flooded in.
Participants arrived early, most coming directly from work. We had pizza and beer ready. Common sense reminder: if your workshop is held in the early evening, ask your local restaurants for hot food donations. Many already have donation policies for local meetups. If you can’t arrange hot food, try supermarket cold cut platters. Remember that you’re asking your participants to actively engage with new material and each other, and if they’re hungry, they’ll be less able to maintain focus.
After networking, and a short presentation (view presentation here), we passed around glasses and gloves and participants pulled out their phones. The reading glasses were strong enough to blur the screen text for most participants. We also had chapstick ready to rub over the lenses, in case some participants needed more blur.
As participants struggled to text and read web content with the gloves or glasses, they rapidly gained a new awareness of the interaction costs of small text and tiny buttons for users with impairments. Many were experiencing difficulty in interface control for the first time.
Role playing with props
Then we turned to the group exercises. We gave half the tables remotes, with a context story for “Meg”, and the other half menus with a context story for “Nate”. Each table role-played their context story, choosing a few people to play the roles in the story and having the others act as researchers, taking notes on the experience being played out for them.
Meg’s table had remote controls (thank you Goodwill!) To simulate Meg’s arthritis, we used the modified gloves. This was by no means perfect, but did work to lessen the sense of touch.
Nate’s table had a menu and prescription glasses. We considered turning the lights down, but thought this might be disruptive. Although we focused on blurred vision for our exercise, you can purchase sets of glasses designed to simulate multiple types of visual impairments:
Good Lite makes an affordable set.
Note takers were given the option to use an empathy map to help them gather notes. An empathy map allows the note-taker to organize their observations around the user’s activities, thoughts, and feelings:
When multiple participants gather and share insights, the whole group can compare and arrive at a shared understanding of the problem they now will attempt to solve.
Defining the problem
After discussing their insights, a group would distill them down into problem statements. A problem statement is a structured prompt to focus design planning on the user’s needs. Each participant was asked to write a problem statement on their own. The group then read all the problem statements and selected one to solve. A problem statement template looks like this:
How can we improve the experience of <task, service> to help our user <goal success>?
As simple as the format appears, it can be difficult to get to gain consensus on the goal. Many participants struggled with a literal interpretation of the goal — they wanted their user to be able to just order food! Goals are more useful to the designer, however, when they are tied to an emotional need. We facilitators pushed each table to find an emotional state to solve for, along with a practical problem:
How can we improve the experience of navigating a menu in a dimly lit restaurant to help our user enjoy a stress-free dinner with a date and not worry about ordering beyond their budget?
Each element of the workshop so far focused on understanding the user and defining the problem. The process we used — flare and focus, in which you explore ideas broadly, then converge on one path — lets participants look at the user and the problem from different angles, and bring all they’d absorbed to the next step: brainstorming a solution.
We asked participants to go to a whiteboard, write their problem statement in the center, and use sticky notes to collect every solution that came to mind, discussing and building off suggestions as they were added.
Facilitators helped the groups identify themes in their solutions. By this time the participants had gotten to know one another enough to feel comfortable with the more rapid communication pace in brainstorming, and ideas came thick and fast.
We then had them put the problem statement in the center of the working space, and brainstorm solutions on sticky notes, discussing and building off of the solutions as they went.
Facilitators checked in with each group, looking for common themes in their brainstorms. The groups had gelled through the other activities and immediately became engaged in the activity.
Participants were excited and eager to share their solutions.
The groups designing a better remote for motion-impaired Meg, discussed solutions involving either minimal controls and larger, more easily pressed buttons, to full voice control to a combination of both.
The groups designing an easier food selection process for Nate talked about larger type, plainer typefaces, plainer language on the menu, larger menu boards that a server would carry to the table. One group, however, presented us with an unexpected challenge when they shared their very novel solution.
This group suggested eliminating a menu by providing only a single food option, which would be fed to diners. The solution, though creative, did not at all address the emotional needs of diners with impairments, and indicated that the exercise in empathy, for these participants, had utterly failed. Unfortunately, this was the only table our facilitators had not visited as regularly as the other tables. Since we had not anticipated this outcome, we had not prepared questions that would have allowed us to understand how the exercise failed for these participants, without embarrassing them before the group. We were left in the awkward position of thanking them for sharing their ideas, and quickly turning to the next group.
Takeaways and suggestions
Limit what you want participants to learn
The workshop was two hours, held after work, and, even with an eager group of participants, it was important to limit what they learn to two or three key points, so as not to burden them with too much to remember. We focused on these points:
- All users experience some impairment with age, so designing to accommodate the widest possible spectrum of users also addresses the widest age range of users (or, designing for “future you”)
- Understanding the user’s emotional needs and the environment in which they will be using a product is critical to designing an effective solution.
Keep it simple
Limit the activity options: participants working on one problem can easily follow the story and solutions of groups working on the other. More than two problem choices means more for each participant set to remember.
Clearly define design scope
Ask groups to design realistic solutions; in other words, menus should still be a vehicle for learning about and choosing which dishes to order. A remote still lets users control their TVs.
Make sure that facilitators are covering all groups throughout the entirety of the workshop, so that if a group is not using empathy at any point, you’re available to help get them back on track, by reminding the to apply the principle of “curiosity over judgement”: ask how empathy played into their decision-making, and gently return to that question, throughout their explanation. Do this with individual groups before they have completed the exercise, to avoid the issue we encountered.
References and resources
Verne Lindner is a user experience architect, and co-facilitator at Portland Accessibility and User Experience.
Peter Russo is a user experience designer, and co-facilitator at Portland Community Design Thinkers.
Design Thinkers’ enables people with expertise in any area to participate in design challenges together, and use design thinking to make positive change in the community.
The mission of Portland Accessibility and User Experience Meetup is to raise awareness of the need, value and methodologies for designing inclusive software interfaces.