During a recent project redesigning an absence booking system, ethnographic research kept telling us one thing about the current system: its users didn’t always understand what was happening, or what was being asked of them through the journey.
While sitting observing the users navigate the current system, they made it clear that most of the copy in the journey did not help them to understand what they were doing, or explain what they should be doing. Terms such as ‘forecast balance’ and ‘absence compensation’ weren’t received well by the users, criticized for being ‘too technical’ and ‘unclear’. This left us wondering…
How could we make the journey more natural for the user?
In order to make any improvement to the system, we first had to understand the following:
- What the system needs to know
- How the user expects to be asked this information
The first part is not too difficult to determine. There are set questions the system needs to know in order to book an absence (the general what, when, where, why) along with some business-specific questions, such as including additional comments. For the most part, these were taken directly from the current system.
Things then started to get a little more interesting
We knew we had to create a system that could be used by everybody in the company, from top-level programmers to entry-level graduates, and become something that everybody could understand. We believed that finding a more natural tone of voice and a natural progression through the questions would allow us to create a journey the user would better understand.
In order to capture tone of voice, and the flow of the journey that the user expected, we set up a small experimental role-play exercise. Two participants were each given an envelope with a scenario in it. One participant would be acting as the ‘requester’ and the other be acting as the ‘grantor’.
The ‘grantor’ was given a list of details they had to find out, including the type of leave, the date and the duration. They were also provided with some information about the user, including their remaining holiday balance.
How the two participants asked the questions, which questions they asked, and in what order, was entirely up to them. They were provided with the scenarios and a selection of post-it notes, pens, paper and calendar templates, and allowed to use as much or as little of it as they saw fit.
We ran five scenarios in total, each targeting a slightly different aspect of the current system, allowing us to hear how the participants would interact when booking an absence. Two of the scenarios included errors which allowed us to see how the participants would communicate to each other when something wasn’t possible to do (i.e. having no allowance left to take).
The results highlighted a number of observations
- Deciding who went first in the scenario varied. Two groups started with the ‘requester’ asking to take an absence, and three groups started with the ‘grantor’ asking the ‘requester’ if they would like to take an absence. While not directly important to the journey (the ‘requester’ will always go first as they will have to launch the app/webpage) it was interesting to see how they decided this. In most cases the participants stated they didn’t think about who went first, and just started the exercise
- The order in which the questions were asked varied from group to group, but remained relatively similar. Most groups followed the flow of asking the date, the duration, the absence type then asking if there was reason for taking the absence. One group however checked what type of leave the ‘requester’ wanted to take first. There was nothing unexpected from the order that the participants picked
- The language used by the participants was far more natural than that of the current system. In one instance the ‘grantor’ started the exercise with “Hello Nick! What date would you like to take off?” This showed a far more personal approach compared to the current system. Other phrases used that were more natural included “What type of leave would you like to book?” as opposed to ‘Select absence type’, “What date would you like to take off?” as opposed to ‘Start date’ and ‘End date’ and “What dates do you want to remove” as opposed to ‘Cancel’.
While in some instances these phrases may be too long to use on a form (think mobile), the more personal tone of voice used in each instance, helped the ‘requester’ understand what they were doing more clearly
- How the participants chose to communicate to each other varied between groups, with one group opting to use the printed calendars to pass the dates to each other rather than speaking verbally. This allowed them to visualise what each other was trying to accomplish. Another group followed the same principle, but using post-it notes instead. This ensured that they both knew exactly what was being asked/told. Other groups stuck to the traditional verbal communication, taking private notes to remember what the other participant had said. The visual methods were interesting, with all users stating that having a way to see what they were doing would be beneficial
Overall, while this exercise didn’t provide us with any ground-breaking or divergent ideas, it did allow us to hear first-hand how the users would interact in person, and gave us direction for creating the journey and making it more natural for the user. It allowed us, through a relatively simple task, to understand to a far greater depth what language was most appropriate for the system to use. Having this information is incredibly beneficial to the project, and allows us to create an experience that will be more user friendly.
For further studies, it would be of benefit to get a broader set of users to participate in the workshop, as the pool of users who participated were of similar persona. While there were a lot of similarities in response, the tone of voice did vary slightly; therefore a more varied group of participants may help us make the language more accessible for a greater amount of people.
What is your experience of using role play in system design? Leave a comment below or contact me by email.