Using this type of process is collaborative, ensures that team members are on the same page, helps create buy-in to the usability process, and breaks down the process enough to spot parts where the system might have usability issues.
The blog entry from last week was focused on usability testing and finding usability problems within the testing setting. This blog entry is focused on developing an understanding for a user’s workflow through a task analysis, which helps map out issues and pain points. This method can be used in conjunction with usability testing or as an alternative to testing when combined with an expert review.
For instance, an online banking system has found a drop-off in their bill-pay enrollment since updating their website. They know that there must be a usability problem impacting the user’s ability to complete the process, so they need to find the pain points in the process. They might engage in the task analysis process, where every step in a user’s experience is broken down (known as the current workflow).
A task analysis could be used to compare a workflow between your company and a competitor to give your company an advantage in usability.
This task analysis requires the team to determine the user’s process from start to finish, referred to as the trigger and the goal. The goal should be defined first: what is it that the user is ultimately trying to achieve? For instance, they may be looking to pay their cell phone bill. The user has many options to do that, such as going to their cell phone store and paying on a machine in cash, paying on the cell phone company website, or paying through their bank, but ultimately the goal is the same.
The trigger is the point that starts a user on their journey to the goal. This may be noting that the bank website offers free, online bill pay with 24-48 hours for delivery. It is a good idea to name your user to make them more relatable and ensure your team has empathy for their user during the task.
You can use low fidelity, low cost tools, such as post-its and markers to create a current workflow, starting with the trigger, ending with the goal, and outlining all tasks, decisions, and pain points in between.
In this example, the (1) and (2) indicate the tasks you should do first. Then you fill in the workflow with each step and areas of possible frustration in the process, as determined by research, existing product documentation, and previous support calls. As you can see, three pain points, indicated by the pink boxes, contributed to Katie ultimately deciding to pay her bill on the Verizon website.
Current workflows can be more complex than the example below. The team could create a workflow with multiple users or areas that branch out when different options in the user’s journey would change their course.
Once a current workflow is established, it is the team’s responsibility to come up with either: local solutions to the pain points in the process, or to re-think the future workflow at a global level.
If the team decides to address problems individually, then it is important to prioritize these problems based on severity and success/error rates when tasks are completed. Prioritization was discussed in last week’s blog. Even if the team determines that they want to address each problem individually, it is a valuable process for the team to collaborate on a future (blue sky) workflow that idealizes the process for future considerations and releases.
Using this type of process is collaborative, ensures that team members are on the same page, helps create buy-in to the usability process, and breaks down the process enough to spot parts where the system might have usability issues. This is a low-cost way to detect usability problems based on expertise in your team, and can be used to supplement usability testing.
For more information and methods, see links below:
http://www.usabilitynet.org/tools/taskanalysis.htm
http://www.usabilitybok.org/task-analysis
http://www.usabilityfirst.com/usability-methods/contextual-task-analysis/