Improving Glide Volunteer Experience
In the beginning of November visited we the Glide Foundation in San Francisco to help propose a better Experience Design for people that volunteer to make and serve food for homeless people.
The first step was to sign up as volunteers. We jumped right in and got carried away finding issues with the web signup user interface. How many volunteers are lost due to the signup just not working properly on mobile devices. This was good to note, but in hindsight this is probably not nearly as important as several other improvements.
Holding off on jumping to solutions is something we as designers must try to remember and remind others of.
Monday morning we joined for lunch to actually volunteer and serve food. It was an eyeopening experience in so many ways. My main takeaway was that the most low hanging fruit for a good design would probably not be much about use of technology. It was all about making sure to give a certain type of volunteer a good first time experience.
Tuesday we jumped in and used a couple of group exercises to come up with a primary persona.
Then we moved on to create a journey map to describe the journey a volunteer goes through from joining a shift to leaving. This is super useful as it gives a single overview of the whole experience, not only the one interacting with the website or serving the food. It gives different angles such as the emotional roller coaster and the goals Glide and the Volunteer is aiming for. It also reminds you to describe it from the persona and stakeholder perspective and try to leave your own ego out of it. Once captured you can go back to your own ideas :-) and know that at least the map will remind you of those other perspectives.
Phew, it was hard to hold off coming up with solutions for this long, but I think it is important to take time to capture the experience while it is still fresh, and get all the details clear. Especially since without recording this part it is hard to give a clear argument for the solutions later, so a good solution may be shot down because it lacks a clear set of existing experiences that are problematic.
This is also the point where you see the meaning of goal-directed design. It isn’t enough to consider the goals of the Stakeholder. You must also plot the goals of the User throughout the process. Sometimes they conflict or diverge. What if you support a user goal to make them get over a stressful part of the experience. It might not help with any specific stakeholder goals, but it will make Heidi feel better about Glide when considering to volunteer again.
At this point it was time to focus on what we are going to do about the current service. We used stickers to pull out Pain Points, Service Strengths and Opportunities in the cards that we already had on the Journey Map. We then singled out 3-4 Opportunities with a potential for a juicy solution. So which one to focus on. We really wanted to do all of them, but you can’t, it would require much more time. So we voted on them giving points (score of 0 - 10) to each of them based on how much benefit they would provide:
- Value to Heidi
- Value to Glide
- Alignment with Glide capabilities
- Overall gut feeling for the idea
This was great! Usually it would just be a voting of “What idea do we like the most”. But we are not designing for ourselves. We are designing for Heidi and Glide. It was really clear that some opportunities would be easy for Glide to do, and some would vastly improve the volunteer experience. No opportunity had top score in all areas, so you had to consider your gut feeling of which were a better candidate. Great discussions.
So now we had a small number of opportunities to work with. Words are really important in setting the way you think of a problem. Designkit has a great description of how to make good opportunity statements starting with “How might we… ?”.
Next up we had a great exercise, “The Worst Idea contest”. If you try to come up with ideas right away, you tend to get carried away with showing how clever you are instead of making something great for Heidi. So we tried to quickly sketch a change to the service that would give Heidi a terrible experience. What would she absolutely hate? There was nothing clever about these solutions, they were quite simple.
After this exercise it was quite obvious what would make a good experience. The great solutions we came up with were quite simple. It was also interesting to note how quickly we settled on the solutions to pursue. This bit of decision making was uncontroversial in the group and probably didn’t take more than 20 minutes, if that much, from “Worst Idea contest” to solutions.
Based on the solutions we had now planned it was time to make another User Journey Map showing how the Volunteer Experience will be with the solutions and changes we had planned. Instead of showing the whole experience we narrowed in on the part that was relevant for our solutions. So in our case the focus was on the part from when the patrons had had their lunch and left until Heidi left the building. This period is a crucial time where Heidi reflects on her experience and decides if she will come back.
To challenge the details of the solutions early you want feedback to see what part works and what part doesn’t. Instead of implementing it and rolling it out we tried out a much quicker way to test the ideas. Body Storming is a simple process whereby you act out in a group the roles of user, webpage, distracting colleagues, noisy servers; Basically any thing or person involved in the interaction. It forces you to slow down and observe the idea in action rather than writing or drawing it on paper/canvas. When slowed down your mind draws many parallels that you would normally miss, and when spoken aloud you see it from an emotional perspective. When you first hear about Bodystorming you will this “This is a rubbish idea mad up by hippies and lunies”, but just give it a try with some great idea that you’re working on and there will be something that become obvious which wasn’t before.
After that is was time to make presentations for the solutions.
In Closing
What we liked the most about the project:
- We are usually focused on technology solutions. On this project we had a chance to focus solely on the flow of a service. It was purely about interactions between people.
What we learned by doing the project:
- When you design content for a web page workflow, e-mail series or app workflow it is easy to make big mistakes on the length, tone, chain of argument etc. By acting the visit to a website as a dialogue it quickly becomes obvious what works an what doesn’t.
- You can produce real design outcomes with very little time available.
The presentations: Since we were on two different design teams we made two different pitches in the end of the week:
Thank you to Cooper for arranging the Workshop to come up with these designs in record time, and of course to the others we worked with Kyle, Samantha, Walter, Glen, Ellen, Connie, and Bill.