Define the problem, first
The reason task analysis is so critical to the success of a product is that it accurately defines the users’ problems. We can’t accurately solve a problem until we just as accurately define it.
The typical mistake most product teams make is to ardently believe that they already know the users’ problems. Remember, if we don’t know the problem, the best we can hope for is to solve the wrong problem, very well.
Note that many folks mistake use cases for task analysis. Use cases are system-centric, describing how the actors interact with the system, not how the user performs their tasks. It’s vital to remain solution agnostic and avoid documenting the process of using the current technology. Otherwise, you’ll end up merely automating current frustrations.
Cognitive and hierarchical task analysis
We approach a task analysis activity from two main viewpoints. Often, we break down tasks into sub-tasks in Hierarchical Task Analysis. However, we also differentiate your viewpoint by focusing on tasks that require decision-making, problem-solving, memory, attention, and judgment. This process is called a Cognitive Task Analysis. From this viewpoint, we would be concerned not just with how the actual activities involved in meeting a goal are performed but also with finer details that aim to uncover how a novice might perform compared to an expert, the level of cognitive load required for each step, how experts make decisions, or how users develop mental models for an activity which are later reused or adapted for other purposes
Ask for outside inputs. But no analysis paralysis!
Which users to observe is always the question and most tend to research only their existing customers. The problem is, those users have already drunk your Kool-Aid and are biased by the existing design. The best insights come from people who don’t use your product yet. For that matter, you may also want to observe users who are not using any site to solve their problem.
The five key things to look for in a user observation are:
* Trigger: What gets users to start their task.
* Desired Outcome: How they will know when the task is complete.
* Base Knowledge: What will the users be expected to know when starting the task.
* Required Knowledge: What they actually need to know to complete the task.
* Artifacts: What tools or information do they use in the course of the task.
One of the keys to a great design is being able to embed knowledge into the product instead of relying on the users to have that knowledge. Determining the knowledge the users have and the knowledge required in order to succeed identifies the knowledge gap that your design must bridge.
That said, avoid analysis paralysis and don’t go into too much detail.
We like colors
We use different colored sticky notes to represent different aspects of the user’s task. Start with a high-level overall task flow, then create more details task flows for each of the separate tasks.
* Green represents the actions that users need to do.
* Yellow represents a step the system can do.
* Purple represents objects, tools, or information that the users need.
* Orange represents questions or issues about the task.
