Dear Peter Evans… This article isn’t clickbait. The content matches the title, and the content stands on its own, there for you to consider with critical thinking. Which you did since you highlighted some of the article.

Task Analysis and JTBD are two different frameworks. You can now be less surprised that I didn’t mention someone who is unrelated to the framework that I use. :)

In short, though there is the long version, task analysis takes a closer look at the qualities and parameters of each step of a task (or job). What does the person do? How do they do it? Other tools (especially outside of our system) that they use. Workarounds they created to try to improve their task success. The knowledge they needed to complete the task successfully, and any knowledge gaps (like we asked their account number and they don’t know it, or the system assumed they remember something they don’t).

It also looks at questions, concerns, and obstacles they faced during that task. We also look at where steps or parts of the task are manually intensive, cognitive demanding, and error-prone.

You map all of these since the opportunity to improve or completely rethink/redesign that task is more than “how do we make this task/job better.” By mapping all of these qualities and parameters, you are more likely to see the insights and opportunities. You will start to know what’s really wrong and how it’s going wrong for users.

Knowing the JTBD is a good start. Knowing everything that is making that task or workflow go well, poorly, better, faster, inefficiently, with frustration, knowledge gaps, etc. sets the project up for more success. We teach this approach (for free) on my Delta CX YouTube channel in the Micro Lessons playlist. It’s been around for decades, but we’re giving it a fresh face. :)