Paper Prototyping and Evaluation: Task Analysis and Heuristic Evaluation (1/4)

Michael Bengwayan Jr.
4 min readNov 7, 2020

This blog is the first of four posts of an academic group project. The goal of the project is to iteratively redesign and evaluate a paper prototype for a specific task in Microsoft Teams. In this blog, we will be looking at how we evaluated user experience of Microsoft Teams using Heuristic Evaluation and Task Analysis.

To understand the issues that users are encountering with Microsoft Teams, our team must first understand the goals users want to achieve and the tasks they are performing to achieve these goals (Usability.gov 2020). To do so, we have conducted a task analysis on the scheduling of meetings in Microsoft Teams.

After our tasks analysis of the “current state” of Microsoft Teams, we should be able to evaluate the usability of the task and recommend a “future state” of the task. To do this, we did a Heuristic evaluation of the task by judging it using Jacob Nielsen’s 10 Heuristic Principles (Nielsen 1994).

Both methods of task analysis and Heuristic evaluation provided a quick and inexpensive feedback to our team.

In our first task analysis, we discovered that the application does not have an “accelerator” for users in scheduling meetings. However, later on in our design process when we conducted user interviews, we discovered that there is a scheduling feature in Microsoft Teams although it is not available to certain user roles. (More details of the user interview is found in the third post of this series.)

Our team has also realised that the solution to the problem is too straightforward — we only need to add a adding a scheduling feature.

Current State Task Analysis on Scheduling a Meeting in Microsoft Teams. Heuristic Evaluation are on the sticky notes placed near the corresponding task.
Future State Task Analysis on Scheduling a Meeting in Microsoft Teams.

Second Task Analysis and Heuristic Evaluation

…we have identified a repetitive pattern: in all five subtasks, the user needs to switch back and forth between the presentation window and the meeting window just to carry out their tasks.

In our second task analysis, our group analysed the task of presenting in Microsoft Teams. The three main tasks are (1) starting or joining a meeting, (2) sharing a presentation and (3) presenting itself. The third task may be vague at this point so let’s see a deeper breakdown of this task.

Current State Task Analysis of Presenting in Microsoft Teams

In the diagram above, we have broken down the presenting task to five subtasks, and the subtasks have been broken down to detailed actions. With this, we have identified a repetitive pattern: in all five subtasks, the user needs to switch back and forth between the presentation window and the meeting window just to carry out their tasks.

In our Heuristic evaluation, we judged the subtasks of presenting against Jacob Nielsen’s 10 general principles. We determined that the repetitive pattern is connected to most of the issues we identified.

1. Limited view while presenting impedes the sser from seeing certain meeting statuses

Principle Violated: Visibility of System Status

Since users have limited view while presenting, they are not able to immediately determine (1) whether their video is showing or not, (2) whether someone is messaging in the chat box or “raising their hand” for a question, (3) the preview of what they’re presenting and (4) their audience.

2. Lack of viewing options while presenting

Principle Violated: Flexibility and Efficiency of use

Because users lack viewing options for them to use the information they want, they are forced to switch back and forth between windows. This is actually is actually a cumbersome and an inefficient workaround.

From our findings, we aimed to eliminate the repetitive pattern in the “future state” task analysis of the presenting task.

Future State Task Analysis of Presenting in Microsoft Teams

Reflection

I’ve come to conclude that problems that are solvable by technology alone, do not need redesigning.

In our initial task analysis, our team realised that the problem we were trying to solve has already been solved. On top of that, we have realised that the solution to the problem was too straightforward. We have come to conclude that problems that are solvable by technology alone do not need redesigning.

References

Nielsen Y. (1994) 10 Usability Heuristics for User Interface Design. Retrieved from nngroup.com/articles/ten-usability-heuristics on 8 November 2020.

Task Analysis. Retrieved from www.usability.gov on 8 November 2020.

--

--

Michael Bengwayan Jr.

T-shaped designer and life learner, portfolio design enthusiast and nerd.