How a Skit Improved Our App
Earlier this year, I was part of a team working to develop a somewhat complex tool that would be administered to older adults by a volunteer assistant. The team responsible for building a new tool was going in circles about what the tool should include, what language should be used and whether or not it should be a stand-alone tool or a tool administered by a volunteer. In my INTJ mind, I’m thinking, let’s incorporate some of the prioritized changes informed by recent user testing, and then test the tool again onsite with users. But first, we needed to get everyone on the same page and we also needed another way to explore the experience of using the tool.
Introducing Improvisation
During one of our weekly meetings, I turned to the program lead and suggested we improvise the experience of having a volunteer assist the participant using the online tool so the entire team could see how this experience would play out. Up until this point, the only interaction with the tool was through InVision, which had been great for designing the tool, but it didn’t address how the tool would ultimately be used.
I was first introduced to the concept of bodystorming by Amy Lee Evans at UXCamp NYC 2018 as an immersive form of role-playing a concept or service.
It seemed like the right technique to try and get the answers we're seeking about how the tool could work.
The training lead put together a loose script so we could walk through the experience. The tool handled fairly technical information, and the script provided the context required for the interactions. At the improv meeting, we had most of the stakeholders, including an actual volunteer with 20+ years of experience who was familiar with the program, but not the tool. In the room, we had printouts of the tool screens, the official forms that informed the questions in the tool and the tool screens were presented on the wall, as we walked through the experience.
I wasn’t sure what to expect from the group. This was the first time we saw the tool being used in an actual situation. I had tried this technique with another team, and honestly, it wasn’t quite as successful, because I had difficulty guiding the team away from describing the backend technology and towards the user experience. However, with this group, we were able to engage in rich conversation about how to handle certain types of questions. As we heard the questions read out loud, we recognized that some language was unclear or too technical and required additional clarification in order to get accurate responses.
Because many of the people in the room were communications and technical people without the tool-specific subject matter expertise, the meeting participants were able to see and hear things that an expert may not have questioned, but a participant might. While not exactly improv, it was the role-play interaction the team needed to experience to understand and empathize with both the end-user and the volunteer in the scenario. Everyone was able to clearly see the pain points of administering the tool and agreed on the next steps for making improvements.
Takeaways
- Consider using improv as you think through building a new tool or service. Seeing something on paper, and actually talking or acting through the experience may give you a different perspective. In the case of this tool, a decision was made not to make this a stand-alone tool, because some of the questions require finesse and expertise to ensure that the responses are accurate. Think of it like choosing to invest on your own for the first time, versus using an investment service at your brokerage.
- Be open to change. Reviewing a comp and seeing it being used in action are two different things and could result in significant changes to your project. Hopefully, this happens sooner than later in the design cycle. It’s better to understand and anticipate where there could be a breakdown in procedures before the training manual is finalized. This learning can be achieved by acting different use cases to discover gaps.
- Don’t take yourself too seriously and make sure you have the right people in the room. Doing improv does require a bit of vulnerability. Defensively, people may say, “that never happens” or “it doesn’t happen that way”, or whatever. Have the note taker capture the notes and keep going. Having the right people in the room is important. A combination of different types of thinkers with different levels of knowledge and expertise will make for a richer conversation. This isn’t meant to be a VIP-only meeting. You want people in the room who are able to contribute to the conversation and help make the iterative improvements to your tool or service.
