Task Analysis = What Makes Sense

Previously I introduced my Innovation Design Model. I included a list of distinctions I made between UX disciplines. Here it is again:

  • (Ta) Task analysis centers around what makes sense.
  • (Ca) Circumstance analysis centers around decision-making.
  • (Ga) Gamification analysis centers around user engagement.
  • (Ia) Information architecture centers around what [your product] looks like.
  • (Id) Interaction design centers around what [your product] feels like.
  • (Ua) Usability is concerned with what [your product] does.

In this post I will focus on task analysis and discuss how it centers around what makes sense. To begin with, we’ll remind ourselves of the task analysis definition we’re working with. Task analysis looks at tasks users need to accomplish, how those tasks are accomplished and the environmental circumstance at the time of the task completion. Task analysts conclude from their research that a particular user need is not satisfied properly and bring a product idea to the table with a general concept of what the product will do.

Given this definition, I have placed specific activities within the role of Task Analyst. All of which require some kind of task identification, task understanding, and task patterns. These task analysis activities have deliverables with very specific information that cannot be repudiated because the data backs them up.

Here are the UX activities I have assigned to the task analysis grouping, including my definitions for them:

(Uiv) User interviews are conducted to understand needs. This broad area includes: understanding a specific user’s needs, understanding a group of user’s needs, and understanding a whole sector of society. Identifying the goal of the interview is primary. This will help you devise an appropriate method and format for conducting the interviews.

(Us) User stories tell the story of jobs that need to be accomplished by whom and why. Each user story will be finite in detail so that no two people can understand it differently. User stories can be contextual to the business rules a product might require as well as detail each step in a user flow path the product needs to support.

(Upa) User patterns identify how group sets perform certain functions so that products can reflect those patterns in their design. Specificity of patterns can be translated into effective information architecture patterns as well as interaction design patterns.

(Upr) User personas are composites of who a real user might be. They should avoid artificiality and convey depth of character. User personas are used to create experiences for a set of people that the persona represents.

(Mm) Mental models are tools used to group activities within modes of thinking in order to design methods of helping users focus on specific jobs. They provide insight into the separations between tasks and their embedded subtasks.

There are more UX activities that can be assigned to the task analysis grouping. This is just where I stopped doing the analysis for this group. Your help in adding more UX activities would be appreciated.

Back to what makes sense. Each of these UX activities don’t have deliverables that present what the product might look like. Instead, they shape the product by guiding the continuing work in a direction that makes sense in light of the task analysis data.

For example:

  • (Uiv) User interviews guide further work in creating user stories, user patterns, user personas, and mental models.
  • (Us) User stories guide us in creating user patterns, user personas, and mental models.
  • (Upa) User patterns guide us in creating user stories, user personas, and mental models.
  • (Upr) User personas guide us in creating user stories, deeper user patterns, and mental models.

That’s not to say that one couldn’t go directly from any one of these task analysis UX activities into UX activities that do present what the product might look like. In fact, you’ll go back and forth from one UX discipline to another in the process of creation.  I’ve moved UX activities that present what the product might look like into information architecture–where we begin to put together organization and structure.

Here, I’ve pointed out that UX activities in task analysis are meant to help us understand what makes sense in terms of a product. The goal is to remember that when you’re wearing your Task Analyst hat, you are not working towards what the product looks like, you are identifying directions the product can take based on what makes sense–because the task analysis data tells you.

In the next post I will discuss circumstance analysis and how it works hand-in-hand with task analysis to bring your product down to earth. Thank you for your participation and input.