We had our team wide sprint demo yesterday where each team presented what they have been working on in the sprint.
These meetings are a great opportunity to share and learn about the world outside our immediate teams.
In this meeting one team decided to use personas to present their work.
It is not the first time they’ve used visuals and role play to demonstrate the work, but it’s the first time they’d used print-outs of people and given them names and background details.
Each team has settled in to their own way of presenting. Some are able to use a demo and talk through the stories they have finished whilst others talk through what they have done as their work often has no visuals to show (our test infrastructure team). No way is better than any other as each is characteristic of the work and the teams.
From these meetings, we all learn a lot about the product, the work each team does and to some extent, ourselves, as we share with the wider team what we are doing.
Our product is Contact Centre (Call Centre) software and as such we can use personas to visualise the flow of calls, the states and the interactions. Assigning roles, personalities and context to each person in the scenario allows us to really understand the motives, user story and operational context clearly.
Applying personas in this way allows us to seek empathy with each user in the system and to understand a little more about why the product is working the way it is. After all I’m sure most of us have interacted with a call centre at some point in our lives; some experiences good, some bad and some very much dependent on our own contexts (in a rush, bad mood, upset, angry, anxious)
- One product owner played the role of Mary (a tech savvy stay at home mum awaiting a call back about an issue)
- Andy played the role of Claire (a call centre agent who was new to the role and was making the return call to Mary)
- Another teams scrum master/dev was Clive (a senior call centre agent who was to be transferred to in order to solve the problem)
Getting people playing roles in the demo proved to be a good way of articulating interactions and stories too. This approach might not be suitable for all, but it went down well with the team yesterday.
Can personas be helpful for testing?
We’ve started to dabble with personas for testing also.
By having a core set of user interactions/capabilities we can start to apply different personas to each interaction shedding a different light on it.
For example, one of the most fundamental aspects of our product is the ability to connect callers to agents.
We could break this capability out in to many different scenarios for testing, for example:
- There is no agent available immediately, the call is queued, then an agent becomes available and takes the call. (testing – queuing, dequeuing and call allocation, stats, call recording, etc)
- The agent can deal with the call immediately. (testing – straight forward two party call, stats, call recording, etc)
- The agent cannot deal with the call immediately and needs to consult a colleague (testing – hold, consult, retrieve, 3-party call, call recording, stats etc)
- The agent cannot deal with the call at all and has to transfer to a colleague (testing – hold, transfer, retrieve (by second agent), call recording, stats etc)
I could go on with many different scenarios….
Now let’s apply personas.
For each scenario we could approach the interactions with different personas.
- We could have agents who are experienced, stressed, new to the job, coming to the end of a shift, working under strict call handling times, etc.
- We could have callers who are relaxed, angry, frustrated, fed up of being transferred, knowledgeable in the subject of the call, not knowledgeable in the subject of a call.
- We could be in a large consumer driven call centre, or a small inbound support desk.
I could go on.
What do personas bring to the testing?
Well personas allow us to understand how and why someone is using the system.
They allow us to seek empathy with the agent, caller, supervisor and any other persona in the mix. It allows us to think clearly about waiting times, queues, effective use of routing, call quality, expectations, sub systems that support the interaction (stats, call recordings, audit) and it allows us to fine tune our own exploration to look for aspects of the interaction we might not have considered previously.
There are some fundamental expectations that the system must meet.
The expectations though will vary in their scope depending a lot on the context. Personas allow us to look at the product differently and see if it’s still meeting expectations from that view.
Elisabeth Hendrickson, in her excellent book Explore IT! (What? You’ve not read it yet?), refers to personas as a great tool for exploring the product and gives a really neat insight:
Just as personas are useful for designing systems, they’re also useful for exploring systems. Adopting the mantle of a persona prompts you to interact with the software with a self-consistent set of assumptions, expectations, desires, and quirks.
We’re finding Personas useful for design, testing and now presenting work back to the team.
As with anything though, there is no silver bullet solution; personas are another tool and technique we can use to achieve our goals, not the only one.
Some things are best presented and tested in other ways, but sometimes personas can be quite helpful.