One more time about task analysis and why you should master it

Published in

UX Collective

11 min readJul 12, 2019

In my first article, I reflected on the topic of why should we test design artifacts in between stages of the process and slightly touched the subject of Tasks analysis. But today we’ll explore technic step by step and cover some unusual findings that you can get after. You’ve probably heard of Task analysis and most likely used in your projects. There are a variety of articles about it, one of my favorites that well explains a concept is Niall’s O’Connor “How to build an experience map.” However, I would like to share with you my take on Task analysis and how to maximize value from the research stage.

Place of Task analysis in the Design process

When it comes to the design process, we all know that there is no such thing like one size fits all. And it is real, needless to adopt process from a to z because not everything makes sense in your environment. Perhaps, you should be selective on what to incorporate to be efficient. Use just what necessary to succeed. Otherwise, you at risk to simply go through some steps in the sake of a process itself. Cliche phrase “less is more” suits here perfectly.

An excellent starting point for any project that doesn’t have a UX strategy

Every project has few things in common — start, end, and something in between. Right? Well, all jokes aside, Task analysis is an excellent start for almost any kind of project. If you work on an enterprise product, you should know how new projects emerge out of the blue and how little details about a user needs you could get from stakeholders at the beginning. Sounds familiar? For me too. That happens mostly because of projects driven primarily by business objectives, which stakeholders address well. Unfortunately, I can’t tell the same about coverage of user perspective. So it is your responsibility to discover user goals and align findings with business objectives with the help of the product team. So regardless of a project type, Task analysis will bring clarity of what actually being done by the user and priority of those tasks to help make decisions on where to start.

One of the essential parts of the UX strategy

UX strategy is a massive topic by its importance and deserves a separate article dedicated to that. So we’ll just touch the surface here. When I mention the UX strategy, I mean a framework that includes:

Understanding the current state of UX, which consists of a clear picture of end user, business partners, other beneficiaries, and their needs, goals, and pain points. Especially pain points.
UX vision and principles that applies to every aspect of the product.
Road map on how to get there. Btw it doesn’t need to be precise, especially on long perspective. Generally, it gives direction and the big picture. Also helps to align different projects on a timeline. Specific should be few next steps to work on. During the execution of that strategy, you’ll review and adjust further plan if needed.
Metrics, targets, etc.

Work on the framework never ends, you always learn from customers and users, regularly updates documents and revise vision, etc. When a new project emerges from nowhere, you simply refer to UX strategy to get needed materials, and almost immediately ready to jump into action. Well, almost… Some project still requires research, but even though you already have a foundation that gives you an impulse. The impulse that we all need when facing unknown. That was some thoughts on why your team should invest in UX strategy.

So here a few things on how Task analysis could help with it.

Get priorities from first hands. That easy to say, but in a typical enterprise product, a team should deal with expectations from multiple sides — company, business partners, customers, and end-users. Alignment of a business part of that priorities is a product manager responsibility. However, it is your up to you as a UX designer to get priorities from end-user to avoid Chinese whispers situation and align that with a business perspective, so the project could succeed. And don’t forget about 80/20 rule, that’s how you can make a decision about what is 20% is essential for end-user.

Make a step toward the understanding of the actual user. It is vital to know and understand end-user to produce an exceptional product.

It is not about to know what they want, but about to extract what they truly need, align that with business goals, and deliver value in time.

Input for Value proposition design. No doubt that we all familiar with Value proposition design book from Alexander Osterwalder. One of the activities in a process is the mapping of a Value proposition with Customer segments to evaluate its fit. Value proposition considered to be somehow satisfactory only when it addresses essential jobs, needs, and gains. That’s where Tasks analysis could be advantageous, instead of guessing ranks just conduct technic with end-user to accurately identify those priorities. Furthermore, if your team invested in UX strategy, you just can get that input straight from artifacts.

Task analysis step by step

It is a straight forward one-on-one question and answer exercise. Few base questions that give an overview of how the product is being used. Before you start, explain interviewee in a nutshell what that exercise about. Make a clear statement that it is not an evaluation of their work or knowledge of the system in any sense, but the research that design team conducts to improve the product. Make a remark that users input is crucial for you. With that in mind, let’s begin.

Task. What actually user tries to achieve? Pretty simple. Right? Don’t confuse the goal with a task, and explain to an interviewee what the difference. Use examples to help be more specific. The task should be simple and if you think that it is too big, try to break down for a few smaller.

Priority from first hands. Let interviewee knows that estimation doesn’t need to be precise. Engage them to share their opinion about the priority of a task. You could have an average ranking from a few interviewees and then compare with a product management perspective.

Trigger. What is it that makes a user start a task? Basically, this is an attempt to understand what was before and how that impacts workflow. It is crucial to know if a task was triggered by daily routine prestart check or by the equipment breakdown. These small details change a lot about how we make design decisions later in the process. Also, context is vital for a big picture.

A sequence of actions. How user tries to achieve a particular task? Ask to be as specific as possible and keep it simple. Also, it is excellent opportunities to ask follow-up questions to reveal collateral details and fill up gape in domain knowledge.

The focal point. What will tell that the task is 100% finished? You’ll get information on how they evaluate the process. What criteria used to know when to stop activities and switch to another task.

Pain points. The actual pain of task execution. Personally, for me, it is the most essential part. Because in the next stages of the design process, you’re going to try to eliminate pain points according to severity and feasibility. Along with product management input on how it is aligned with a road map and developers input on how feasible is a solution for a problem. All that information helps to make the right decisions.

Next steps. What user’s doing after task completed? Given information provides a bit of big picture and how tasks linked between — you know how it started and where it goes. After task analysis, you can make high fidelity task flow.

Information that the user needs.

What do they know? What information does the user have when they execute the task? This is a chance to get details on what information provided by the product itself and what they need to get somewhere else.

What should they know? What additional knowledge will the user require to reach the focal point? You could find that user scrambles important information from other sources to make decisions during execution. That indication of the opportunities to add information to a product, of course, if feasible.

(Optional) What do they use? What tools, processes, functional components, features, etc. the user utilizes during the execution of the task? That question is not always applicable, so it’s up to you to decide. When suitable, it gives an overview of the tools used, and you can extract ranking from several sessions.

Bonus questions are great to get a sense of what is the best and what is the worst functions of your current product from a user point of view:

If you could add only one thing to the product — what it would be?
Imaging that all features will be removed, but you could leave only one feature as it is now — what it would be?

But don’t jump into conclusion right after you heard that some feature is not ok. It is not always entirely true, but rather an opinion that needs to be evaluated and considered. Align with product management and technical points of view before you make decisions and move forward.

Pitfall you can avoid with Task analysis.

There is an opportunity to break down the existing component to make it simpler.

There are good chances that your product needs architectural improvements if the number of tasks that could be done within one component is too high. It is not a call to action, but mostly a warning. Perhaps simplification of that component could give you a chance to provide better UX to your users.

Who’s a voice is stronger?

Imagine a situation where it is so difficult to convince stakeholders to make hard decisions. Easy to imagine, right? Fortunately, after you master Task analysis technic, you will have that necessary data to prove your points and make that kind of conversation more straightforward. That doesn’t guaranty 100% success every time, so you should take this one with a grain of salt.

Bring stakeholder on the same page.

Deal with misalignment and controversial assumptions using conclusions from the research. No need to guess anymore, only priorities and data from first hand. Decision-making process has never been more natural. Only that point is well worth on investing time on mastering Task analysis.

Note and vote as a convincing tool.

Still couldn’t align, try Note and Vote exercises to set priorities and brainstorm issues and solution without conversation. It also called Lightning Decision Jam, and in my next articles, I’ll share with you my take that exercise and some tips on how to increase value.

Avoid mistakes with MVP scope selection.

This is an intriguing topic because as appears to be not everybody clearly understands the conceptual purpose of MVP. It is odd to see how people use that term to justify their bad decisions or absence of will to do the right thing. Basically, instead of saying we don’t have resources and time to find a better solution, they usually say, “It will be an MVP.” So that term becomes another fancy word for “quick and dirty” solution that will definitely cause a lot of problem in the future, but nobody cares about that now. Fortunately, we have some tools that could help us not to derail from the right course. Task analysis perfect nominee on the role of fundamental tool to compose bulletproof scope for MVP to validate an idea and later based on feedback and conclusions define a path to an actual product. In my previous article, I shared the 80/20 rule, so the framework is based on that rule.

Let’s talk through steps quickly.

First of all, after product definition stages passed, conduct a Task analysis with target users of your future product. Tip: Be wise on selecting a good portion of users from different trusted customers that have experience in the area that your product belongs to, and you’ll have decent average priorities.
Align priorities with a product team to have everybody on the same page. A difficult thing to do, but possible.
Based on that, you’ll have an idea of what could be essential functionality that needs to be in MVP.
After that, you’ll be ready to talk about the feasibility of delivery within the accepted timeline. Tip: The essential functionality after Task analysis is a direction is not rule, because in enterprise products users not always could reflect all complexity of business peculiarities. When it is not clear about the legitimacy of requirements, refer to Task analysis artifacts.

Conclusion

Task analysis is a brilliant exercise that moderately cheap to conduct and could provide much more than just a list of tasks. Add goal as a parent for tasks, put all that in chronological order and you’ll get decent Experience map. Trigger and next step parts give you a chance to compose high fidelity Task flow with cross-references to get in-depth details of any item and overview of related tasks. The list could go on and on, so when you don’t know how to start your next project, simply start with Task analysis. It’ll give you that feeling of profound joy when uncertainties are slightly diminished and clarity already noticeable on a horizon. Feeling of confidence. That is priceless.

Maybe not everybody agrees that end-user important for enterprise product because of business requirements almost always a driver and product management focused on how to satisfy customer needs which is different from end-user. However, my belief that helping end-user be efficient at the workplace is the most significant help to a business. And the design team could successfully address that. Nevertheless, focusing on the alignment of business with end-user helps to achieve balance and deliver an outstanding quality product.

You can print the image below and use as handover for your team for on-site research. That will be great for field notes and cheat list with tips and questions sequence. Especially helpful when you don’t have much time for onboarding of a new team member. Few minutes brief and you ready to go!