Redesigning a feature in Microsoft Teams part 3: Prototyping
After conducting research, we began to design solutions to the problems we had identified. Prototyping a Help feature requires large amounts of content which the requires a higher fidelity prototype than the project scope permitted (Nielsen Norman Group, 2016). Therefore, we decided to switch from redesigning Help, to Meetings, which lent itself far better to low fidelity prototyping (see appendix for research for competitor analysis and task flow analysis of Meetings).
User needs statement
User needs statements define the goal of a design; something to measure our solution against (Sarah Gibbons, 2019). Our user needs statement:
“New users need a clear and straightforward way to schedule meetings — from inviting internal and external participants, to editing and rescheduling. A solution should while ensuring the user is fully confident their meeting will take place on time and with the participants they invite.”
Paper prototypes
Paper prototypes are fast and easy to design, meaning we could begin testing ideas early (Snyder, C. 2003). Working fast limited personal attachment to our designs, allowing us to objectivity critique our work. We individually created paper prototypes, quickly generating a variety of ideas. We each identified ways to improve Meetings. Some of my initial ideas included:
- Sending custom meeting invitations within the app.
- Rescheduling past meetings.
- Redesigning how meeting times are selected.
- Adding error prevention screens.
- Increasing feedback through confirmation screens.
The most critical aspects of scheduling meetings is picking a time, inviting people, reviewing meetings and pre-meeting preparation; all of which were deficient in Microsoft Teams’ current design.
Testing
We used the same on-boarding script, task, and set of questions, to categorise each participant. This limited variables between testing to the designs and the users. We tasked users with scheduling a meeting. They were asked to add a meeting title, date, time, and invite two people they work with and one person they do not. The task tested the designs learnability and highlighted errors, fore-fronting problems and users intuitive actions.
We asked each participant to verbalise their thoughts, feelings and actions throughout the test. I informed participants that the prototype was not a final design, and not to worry if they got stuck, and to explain why they were having trouble. After testing, we asked participants for any closing comments or suggestions they may have had for the design.
Transcript of usability testing:
Testing revealed:
- Users were unsure whose calendar they were viewing when choosing a time for their meeting.
- While searching for contacts to invite to their meeting, one user experienced uncertainty as to what would happen if they clicked a contacts name.
- While browsing contacts to invite to a meeting, users were unsure whether clicking a contacts name would invite them or open a biography page.
- Users felt trapped and unsure of what to do whenever there was lacking a clear call to action.
Digital Wireframe
After testing, we critiqued one another’s designs. Referencing personas, research and testing kept our critiques objective. We selected what to include in the next prototype. We decided to expand our tasks to include:
- Reschedule a past meeting.
- Customising an invitation.
- Scheduling a meeting with their whole team.
- Inviting additional people to an existing scheduled meeting.
We used Figma to design a wireframe, allowing us to work better collaboratively, and gain access to more first time users through remote testing.
Wireframe:
Testing over Zoom was very different from the paper prototype. While interacting with the digital wireframe, user expectations far exceeded what was feasible to prototype. Many issues that arose during testing were down to the low fidelity of the prototype.
For the most part, the participants intuitively understood the design. However, they became frustrated whenever they encountered something that wasn’t prototyped, such as visual feedback on checkboxes and using keyboards.
References:
Nielsen Norman Group. (2016). UX Prototypes: Low Fidelity vs. High Fidelity. [online] Available at: https://www.nngroup.com/articles/ux-prototype-hi-lo-fidelity/.
Gibbons, Sara and W.L. in R.-B.U. (2019). User Need Statements. [online] Nielsen Norman Group. Available at: https://www.nngroup.com/articles/user-need-statements/.
Medium.com. (2020). Redirecting you — Medium. [online] Available at: https://medium.com/r?url=https%3A%2F%2Fwww.nngroup.com%2Farticles%2Fuser-need-statements%2F [Accessed 7 Nov. 2020].
Snyder, C. (2003). Paper prototyping : the fast and easy way to design and refine user interfaces. San Diego, Ca: Morgan Kaufmann Pub.
Appendix
Competitor analysis and Task flow analysis
Currently creating a meeting in Microsoft teams is relatively easy. However, there’s no fast way to add multiple groups of people to a meeting or attach any custom messaging or pre-briefing to your invitations from within the app.
The ability to check that your meeting time slot against your guests’ schedules in Google hangouts stood out and is something Microsoft teams could do well to include. Zoom stood out for how easy it was to join a meeting either as a guest or host.
