You know because you need to know! or Cognitive Task Analysis to those in the know

As Barry the Baptist famously says in Lock Stock and Two Smoking Barrels “You’re doing it for me is all you need to know. You know because you need to know” no time to get into all that now! but…

Cognitive Task Analysis

Most UX designers need to know, what users need to know.. through a process called cognitive task analysis we can firstly gauge the preliminary knowledge of the task the user is trying to complete, so looking at a task as a designer we gather what the user shall be facing when interacting with a user interface.

As an interface designer, you don’t need to be an expert in the area in which the user is trying to complete tasks, but we do need a degree of familiarity with it, so say you were making a sushi restaurant menu app, an understanding of what a bento box was would be essential, you wouldn’t have to know where the fish were sourced though.

After gathering preliminary knowledge designers need to gather some knowledge representations, which is an understanding of what kind of things the user needs to know in order to finish tasks – not exactly the knowledge that they’ll need to have, but whether users need to do things in a series of steps, or certain order, or have access to learning material to complete tasks.

So if we go back to the sushi menu app again, we need to understand that if a user is going to create a custom bento box, what order they shall have to do so, do they add a drink at the end? can they add a few extra crunchy rolls? can they change an order after selecting the sushi and going to the final payment stage..

Finally with cognitive task analysis we need to populate these knowledge representations, as we start to recognise what the user already knows, we can observe the user, we see that they already know how to select different sushi rolls, add a drink, follow the payment instructions etc.

During this late stage, we take notes on all the actions users undertake; designers then map those actions to knowledge that must already exist in the users mind – designers see the equipment involved in the task – they map the sensory experience of the user & identify all the interruptions that might have an impact on, or even change, the users thought processes.

As some of these are things we cannot actually see, we can use techniques to bring out that focused knowledge. Basically we just ask the user to tell us what is going on inside their environments, inside their minds, and anything that may impact our understanding of parts of the task, if any, that the user themselves is not aware of. A major driver of doing this is so we can confirm with users that what we are observing is correct, and check our assumptions that what we understand from what we observe is in fact the case. Once we have all the data, we can then format it in a way that is useful and apply it to the interface we are designing.

The drawbacks of cognitive task analysis is that it’s a time intensive. CTAs involve sourcing lots of experts in the tasks to observe & interview, often over a long stretch of time. Designers then have to amalgamate a large swathe of data, of which hardly any of it is contextual. Cognitive task analysis is less suitable for use by newcomer users, you tend to need people who are expert enough at what they are doing to be able to understandable as to what is going on in their mental unfolding.

Hierarchical Task Analysis

We also looked at Hierarchical Task Analysis which I won’t go on about her ein depth but essentially breaks each part of a users perceived actions down into its own sub-tasks, which allows us to be so granular that these sub-tasks can be seen as useful in different contexts.

If we think of building a house: cable pulling is something you do as an electrician, but you would also do this as a home cinema installer; testing lights is something you do as an electrician, but you would also do that as a conveyancer to get them signed off.

GOMS Model

The GOMS model is based on the view of the user as processor, and sees their role as such within a system.

It is founded on the theory that you need to collect four sets of information about a task in order to understand it:

  • G = the user’s goals within the system.
  • O = the operators the user can perform on the system.
  • M= the methods the user can use to achieve those goals.
  • S= the selection rules the user uses to choose among different computing methods.

The basic premise is that every human who interacts with a system has a goal in mind, and needs to use the system to complete that goal.