Author: Aaron Rester

The post below is condensed from a presentation I gave at Confab Higher Ed in November, 2017. Most of the ideas below (the good ones, anyway) come from Gerry McGovern’s book The Stranger’s Long Neck. If you haven’t read it yet, go get yourself a copy right now.

Meet Luisa

Luisa is about to start at your university next fall. She’s what we call in higher ed a “first-generation student,” meaning she’s the first in her family to attend college. Luisa was born in the U.S., but her parents came from El Salvador not long before she was born. She did well in high school, but didn’t receive the same kind of college-search support that perhaps her more well-off future classmates might have, but nevertheless she has navigated the complex admission process mostly on her own, and been accepted to your school. As the beginning of the fall semester approaches, she receives an email telling her it’s time to sign up for classes. She goes to the university website, which has an architecture that might look like a way more complex version of something like this:

For many of us in higher ed, this is an all-too-familiar model for how our websites are set up. I call this the “Office of …” model, a model in which every office in department in an institution has its own small section of the web. Usually these start with “Welcome to the Office of … website!” and the proceed to outline the mission of the office, before (perhaps) outlining the responsibilities of the office and the services they provide. The “Office of…” model makes sense from a certain point of view: it’s very easy to maintain permissions in your content management system, and it reflects the mental model that we, as employees, have of the organization. Of course, problems do crop up when there are reorganizations (higher ed’s favorite pastime); these often lead to broken links, bad search results, and inaccurate or outdated information. But usually we just rename the webpages and carry on.

But back to Luisa. She’s gone to the website looking to sign up for classes. With no clear signposts, she starts clicking around to try to figure out how to do so. She guesses it’s probably under “Academics,” but then isn’t quite sure where to go from there. She tries “Catalog” and gets a list of courses, but no way to sign up for them. She looks through the other options… what the heck is a “Registrar”? What on earth is a “Provost”? Annoyed, she goes to the search interface and types in “sign up for classes.” She gets a hundred results, scrolls through the first two pages, and, frustrated, closes her browser, thinking “I’ll come back and do this later.” Unfortunately, first-generation students, who generally don’t have the support systems or inherited knowledge of how to navigate college life of their peers, are prime candidates for “melt.” Luisa may never come back to choosing her classes, and may just never show up to the school she worked so hard to get into.

Meet Todd

Todd is a incoming transfer student from a local community college who has just received his first bill from your school. Now, Todd’s a junior — he’s been around a while, and he knows that higher ed likes to throw around weird jargon and acronyms and antiquated bureaucratic terms. He knows that  when it’s time to pay his bill, he should look for the Office of Student Accounts; after all he’s been doing that for the last two years. So he goes to the website and finds the same information architecture pictured above… and doesn’t see an Office of Student Accounts.

If you’ve been around higher ed a while, you probably know that the Office of the Bursar probably has something to do with collecting tuition and fees, but how on earth would Todd know that? Why are we putting a linguistic barrier between our user and the action he’s trying to take, the action (giving us money) that affects everything from our operating budget to Todd’s ability to register for classes and take books out of the library. Under the “Office of…” model, if students don’t understand what departments do, we’re making it more difficult for them to accomplish what they need to get done, and more difficult for them to complete their educations.

To get around this difficulty that we create for ourselves, we have two options: 1) we can educate students over and over about which departments provide a given service (until, of course, that department is reorganized and the service moves to a new department and we have to start over again) or 2) we can organize our websites around the students’ needs rather than the institution’s.

Enter “top tasks”

At the university where I work, 45% of our students are first-generation, like Luisa. More than 50% are transfer students like Todd. These are real problems with real effects on our institution. So when the stars aligned for a site redesign in late 2015, I wanted to do something to help our students and help our institution get out of this trap we’d created for ourselves. Making the site responsive was the primary driver, but far more than design needed to be addressed. We had very little by way of formal governance in place, and our information architecture was a mess that was very much focused on the needs of institution. So I used this chance to reimagine our information architecture using a methodology created by Gerry McGovern known as “top tasks,” laid out in his book The Stranger’s Long Neck.

At its core, “top tasks” is really just the radical idea that websites exist to help our users get stuff done. It seems obvious when you see it in print, but how often are pages created on your site to house information that someone *thinks* someone, somewhere, *might* need someday?

For me, one of the key quotes in The Stranger’s Long Neck is:

Nobody cares about information for its own sake, except the creators of said information. The customer has a task they want to complete, a problem they want to solve. Information is only useful in the context of the task.

Again, this seems really obvious once you see it in black and white. But if there is one thing that higher ed is incredibly good at, it’s producing information for its own sake. In some ways that’s really our raison d’etre. But if our website is going to be actually useful to our users, we have to fight that impulse at all costs.

Three principles

McGovern spells out three fundamental principles provide the rationale for his methodology.

1. Every website has a small set of tasks that deliver a huge amount of value. In higher ed these are usually things like prospective students submitting applications, students registering for classes, or alumni making donations. These are the actions that keep the organization solvent and functioning.
2. Every website has a large range of tiny tasks with the potential to deliver value, but also potential to destroy value by getting in the way of the top tasks. Less useful content gets in the way of user’s being able to quickly access the useful content. This is most likely that sparsely attended lecture put on by [insert your least favorite department here] that someone inexplicably feels should be on the institution’s home page.
3. Focus relentlessly on helping your customers complete the top tasks as quickly and easily as possible. If you can truly nail the user experience for completing those tasks, you will ensure that your organization is getting the most value out of its website, and that the majority of your users will leave the site happy and satisfied.

“The Pareto Principle, Stretched”

From his observations in working on websites for organizations ranging from multinational corporations to European governments, McGovern posits that a slightly modified version of the Pareto Principle applies to most websites: on average, 25% of a site’s effects will be generated by 5% of causes, and 60% of effect from 20% of causes. That is, 5% of the tasks users come to a website to complete will generate one quarter of its value, and one fifth of tasks will generate 60% of its value. The best user experiences, McGovern argues, will only happen when we concentrate on the “long neck” of tasks rather than the long tail. Particularly in instances where administrative resources are limited (looking at you, higher ed), both our organizations and our users are best served by concentrating our efforts on the long neck.

Three more principles

Once you’ve decided to embrace top tasks as a methodology, McGovern offers three more principles to guide your efforts.

1. Know your user’s long neck. Your opinion of what constitutes the long neck may be radically different than your users’ opinions. You have to do your research.
2. Continuously improve your top tasks. Top tasks is a continuously iterative methodology. McGovern argues that you need to continually measure your users’ task success rate, disaster rate (when users think thy’ve successfully completed a task but haven’t), and completion time. Then you need to make tweaks, measure again, rinse and repeat.
3. Manage with facts, not opinion. This is of course easier said than done; no matter how good your data, it can often be difficult to shake the gut instinct of a HiPPO. But whenever possible, base your arguments on the data available to you.

Establishing possible top tasks

Your first step in moving toward implementing top tasks is to establish the universe of all possible tasks. The goal is to generate a “longlist” of at least 100 tasks. There a few ways you can do this, and I found all of them to be helpful. You can gather qualitative information simply by talking to stakeholders about their own use of the website and their perceptions of their constituents’ use. You can gather survey data directly from your users with a freeform question such as “Why do you most often come to the website?” and use their responses to identify patterns. You can look at your analytics to see the most visited pages on your site, as well as what people are using your internal site search to look for on the site. You can conduct an analysis of your competitors to find out what tasks they appear to have optimized their sites for.

As you assemble your list, try to word the items on it as verbs. For example, “library” might be one of the top searches on your site, but there are any number of tasks that users might be trying to complete with that search: finding out the hours the library is open, looking for research help, renewing a book they’ve checked out, and so on. Also, try to word the tasks in as natural language as possible; avoid the jargon of which higher ed is so fond. You can actually duplicate some tasks on your list using different wording (for example “register for classes” vs. “sign up for classes”) to see which version your users prefer.

Determining which tasks are “top”

Once you have your longlist of possible tasks, the next step is to see which ones your users feel are most important to them. McGovern’s method for this is perhaps a bit surprising, and he spends a fair amount of time in the book effectively saying, “I know this sounds kind of crazy, but believe me, it works.” Essentially, you present your users with your entire longlist of tasks at once, and give them just five minutes to choose their five most important tasks. The task they choose as most important gets five points, the task they choose as second-most important gets four, and so on. This weighted voting method allows you, once you’re looking at the results, to really see items that jump out as most important to your users.

I added an additional layer to this leg of the process. Since higher ed sites have so many different audiences, I had a hunch that different audiences would have different top tasks — after all, the things a prospective student comes to your site for are likely very different than the things an alumna comes to the site for. So the first question on our survey was to establish the respondent’s relationship to the university, and then frame the survey within those terms, e.g. “As a current student, which of the tasks below are most important to you to be able to complete on the Roosevelt website?” If a respondent had multiple relationships to the school (such as being both a staff member and an alumnus), we asked them to fill out the survey multiple times, changing the framing of how the tasks were presented each time.

Implementing your top tasks

Once you’ve established which tasks are the top ones for your audience(s), you need to implement them on your site. Most likely, this will involve organizing your pages around the task that can be accomplished there, rather than the office that provides the service, and reorganizing your information architecture around groups of tasks. For example, we created a “Get Help” section for our current students that included both the Counseling Center and the IT helpdesk; it’s highly unlikely that any “Office of…” model would ever have put those two things together.

As suspected, we found that our different audiences have very different top tasks. This may mean segmenting those audiences into separate sites, or finding some other way to keep one audience’s top tasks from getting in the way of another’s.

Cut pages that do not support top tasks, and be merciless. This is easier said than done. People don’t like to be told their content is useless; data can help, but people get attached to their content. This is part of why we included this change as part of the redesign process; starting from an effectively blank slate can help a great deal, since people will often not even notice (sometimes for months or even years) that their less-than-useful content has disappeared.