Top Tasks vs Jobs to be Done (pt 1/n)
Weeknotes #27: Nov 23–27, 2020
As I mentioned last week, I recently started talking to my manager about an ongoing monitoring and measurement project for Top Tasks. On one hand, it’s a bit daunting because I’m still new at CRA, but on the other, this is a wonderful way for me to dig and and familiarize myself with things.
Organizing web content by Top Tasks is an approach championed by Gerry McGovern, and the canada.ca webteam has worked directly with Gerry to structure our web content. This week I picked up his book to help ensure I was clear on the approach and rationale. It was kinda fun to read through the testimonials in the preface and see this: (Jonathan is my manager):
As part of setting up this project, I got a chance to connect with stakeholders from different teams. While we had a list of Top Tasks as identified through surveys with site visitors, looking at the list was a starting point for some very juicy conversations.
I’ll admit, I’ve heard people speak of “Top Tasks” before, and I was not sure how closely that tied to peoples’ Jobs to be Done.
“A task is whatever your customer wants to do”
— Gerry McGovern
When initially identifying Top Tasks, Gerry advises to be as open as possible. You don’t want to focus on your own offerings “when coming to our website, what…”. Rather, you want to welcome people to suggest things that you may currently NOT be offering. This aligns well with my Jobs-to-be-Done lens, where ‘the customer doesn’t care about your product, they care about getting things done’. So far, so good.
Yet as I read further, my brow started to furrow a bit. Tasks are things people do. So this paragraph gave me pause:
Use a noun to describe a task unless it’s absolutely essential to use a verb in order to create clarity. For example, avoid writing “Get Pricing” — writing “Pricing” on its own is much better. (Or use “Prices”.)
Pricing is not something a person is trying to get done.
Pricing is not something a person is trying to get done.
Top Tasks are about Navigation and Information Architecture
If it wasn’t clear by my two last statements above, this idea of dropping verbs and focusing on nouns for tasks really threw me for a loop. I’d been trying to make Top Tasks fit my mental model for Jobs to be Done, and the two didn’t quite fit.
Jobs to be Done is about understanding what people are trying to get done, and help them do that quicker, with fewer errors, and better quality of output. In contrast, “Top Tasks is not some add-on to the existing navigation. It is the entire navigation.”
So I’m starting to think of it like this: Top Tasks is a way to help users get the Job Done of accessing answers on your website. We measure the success of that through time-on-task (quicker), task success (with fewer errors and better quality of output).
Seeing Top Tasks as primarily being related to navigation structure and labelling helps me in some ways, but I certainly find it limiting. We had a good internal conversation about whether we needed to dig deeper to ensure our content was clear (I initially wrote comprehensible and then realized that sort of word is exactly the opposite of plain language!), rather than just focusing on whether users were able to navigate to where the content was.
Another issue that bubbled up the fact that there’s generic information related to taxes, credits and benefits on the CRA website (canada.ca pages), but details related to your personal tax situation can only be accessed behind login. When someone comes to our website to find out when they’ll get their tax refund, they are looking for information related to their specific case. We can provide a navigational structure that directs them to a service standard or tells them to log in, but the canada.ca website doesn’t actually have the answers people are looking for. How do you reconcile what people are looking for versus what you can realistically provide?
One approach is to take a (granted, large) step back, ignore the boundaries between sites and platforms and really examine the end-to-end service. Rather than limiting yourself to “can the user find the page where they would log on” (optimizing a small piece of the larger objective), you could examine the possible fault points that frustrate users, especially at those point where we are crossing channels (sending a user a letter with a passcode, for example).
But — I don’t think that’s Top Tasks, as Gerry McGovern intended. It’s obviously important, but as we expand our scope outside what we can reasonably control, things get much more complicated!
For the purpose of the monitoring and reporting project, I think we are just going to have to be explicit about the scope, and identify that even if we dramatically improve the navigation and retrieval of generic information on our website, there are many other opportunities for improvement in delivering services to Canadians.
