User Research and Usability Testing on Microsoft Teams
Following on from critical appraisal of Microsoft Teams.
Persona Development
Personas are useful tools to capture and convey user research in an easily digestible and concise manner. They also helped us frame our further decisions in a user centric manner.
When based on user research, personas support user-centered design throughout a project’s lifecycle by making characteristics of key user segments more salient.
(from “Personas Make Users Memorable for Product Team Members” by Aurora Harley, February 16 2015, nngroup.com)
Due to the limitations in scope and time of this project we drafted personas that were both motivated by informal interviews and online user research, and also based off our own assumptions.
Each group member made two personas (mine can be found here) based on their own individual research — mostly user interviews. We then met as a group and outlined our findings to each other. We discussed and evaluated what commonalities we could identify across our personas. We then incorporated the most interesting and informative parts of each, and condensed them into our two final personas, Rachel and Jack.
As the project moved on Rachel, the teacher, became our primary persona that we used to inform our further decisions. Here are some examples of what informed Rachel, as well as some of the reasons we felt she was best to progress with:
- All our personas ended up falling into three categories: students, teachers and professionals (mostly tech)
- Of the interviews conducted by the team more than half (3) were interviews of teachers — so it was the group best supported by evidence (and access for future testing and research iterations).
- We noticed common themes in our personas — motivations to improve teamwork, connectedness and engagement, and make communication as effective and straightforward as possible. We tried to distill these commonalities in Rachel’s persona.
- As we are students and using Teams in that context we felt we best empathised with the likely scenarios this persona would lead to as well, hopefully helping make up for our limited capacity for research
- We also used some proto persona creation methods: such as basing the age of her class on the halfway point of primary and post primary education, and the class size on the Irish national average.
Understanding Our Users Needs
From there we looked at the tasks Rachel commonly carried out on Teams.
We had noticed that frustrations around Student engagement, and making sure students felt included, were common concerns across our interviews, and we had conveyed these concerns prominently in our persona, so our studied tasks were largely in this area.
We then developed empathy maps and journey maps to identify and collaborate on what our persona was thinking and feeling at the different stages of these tasks. This let us hone in on the route of the problem in these flows and develop solutions to them.
Empathy Maps — to create a shared understanding in our team regarding what Rachel feels, thinks and says while completing these tasks.
User Journeys — to identify where and why Rachels experience of Teams is less than optimal
Scenario Studies — to understand the wider context of why and when Rachel performs these tasks.
User Needs Statement
By this stage we had settled on student engagement as our primary focus.
In Teams there is no way to really engage a class except verbally, and in a real classroom environment getting an overall impression from a full class is much more natural and efficient.
It also fit the scope of the project very well: a problem so big that you could workshop it for a long time — but that a simple solution could potentially go a long way to addressing. This led us to our user needs statement:
Reflections
I think we created very strong personas — the creation of which not only helped us convey our interview findings, but also helped us organise our own thoughts and understandings, and act as a fantastic tool to ground our future designs in a research driven and user centered light. It helped us form our problem statement, that we referred back to at every subsequent stage of this project.
If we had more time for this step of the project we would have formalised the questions for our user interviews. These interviews were quite casual and unstructured, so it made it more difficult to compare findings, and come to conclusions.
