Don’t conflate audience segments with use cases

I see this all the time in higher ed. A mobile site offers links to content aimed at prospects and also throws in “mobile” functionality like maps and directions. Who are the mobile tools intended for? Prospects are not in need of maps or directions- they’re not on campus. Yes, they are on campus during a visit, but with decision making processes lasting months if not  years, it amounts to a rare occurrence (and you shouldn’t design interfaces for the exception to the rule- offer access to the functionality, but don’t make it a focus). Like any other project, you need to settle on who you’re building your project for OR for what purpose (i.e. use case), but not both. It doesn’t make sense to offer tools that are really meant to fulfill particular use cases alongside content meant to fulfill audience segment needs (unless they’re the same thing in which case we’re only talking semantics). Divide an conquer. Create a single .edu experience with focus and intent. Don’t get mesmerized by “mobile” functionality unless it supports the bigger plan.

Use cases might point you towards an app

If research suggests that maps or other kinds of functionality are needed, don’t be so quick to throw them in alongside the content intended for an audience segment. Instead, be ruthless in your curation and editing of the interface and user flow. Let the focus of your strategy be your guide and allow it to simplify your decisions. If your intent is to primarily reach prospects via mobile, then do so. Take the research finding that don’t fit well (like maps) and set them aside. Once you have the segment’s experience honed, then take all the leftover stuff and ask why it was left out. I think in the case of maps, it will be left out because it’s not directed toward prospects. It’s really intended for an on-campus use case which might mean it’s relevant to a prospect when visiting, but more apt for the people who are always on campus- students, employees. The use case cuts across traditional audiences and presents an opportunity to create a second experience, this time centered around the I’m-on-campus use case.

That use case might best be addressed through a dedicated app. Why? Because mobile doesn’t necessarily mean walking on campus. You can just as easily be sitting at home surfing on your phone. This fact suggests that the mobile site should actually be the same as the desktop site, or, in other words, there should only be one universal .edu experience whether it is seen on a phone, an iPad, a desktop or anything else. This is the responsive web design idea that’s gaining so much attention (and deservedly so). So, if all devices point to the same experience and that experience is determined to primarily be centered around prospects, then where should this use case approach apply? I say an app. It can include links to the intranet, Blackboard (or whichever LMS your institution uses), shuttle service, dining hall push notifications, etc.- anything that matches the use case.

Quick examples

Harvard has done an excellent job of providing focus to their mobile experience. You can tell by the content offered that it’s squarely directed to on-campus use. There is nothing extraneous to that purpose which brings it focus, clarity and cohesiveness. Their website, on the other hand, is squarely directed at prospects. There are ways to get to content that isn’t specifically geared to prospects, but those access points are secondary to the main show which is for prospects. Roanoke’s mobile site, in contrast, has less focus. You might think they follow an on-campus use case strategy too, but then you see that they include links for admissions and majors- content meant for prospects. They also have a link labelled alumni which is yet another audience segment, this time literally called out. In contrast to Harvard, Roanoke’s palette of content is much less coherent burdening the user to figure out whether or not the site is of use to them or not. Placement of the links is also a problem. Josh Clark teaches us that the audience specific links are located at the most accessible link target areas of the screen. That further adds usability confusion to the site.

1. Most obvious, is that there is no obvious way to report a problem when you’re in the maps area. It’s an outlier use case, I’ll grant you that, but still, it’s not carte blanche to hide it. The most logical place to go then is the help link.
2. The help article has a “how do I report a problem” toggle. Perfect! This is exactly what I need. Wel,, hangon a second. It mentions a “report a problem” link, but fail to actually provide the link. They instead choose to talk about it. Hello? This is the web, right?
3. Given the above oversight, I decide to open the “where can I find the report a problem link” toggle (which wouldn’t be necessary if they simple gave the link in question). It instructs to click “more” from the info window. What’s the window info, you ask? Who the hell knows? Figure it out for yourself.
4. As I ponder what they might mean by info window, I see a “more” link in the top black bar- maybe that’s what they mean by the info window? Doesn’t seem like an info window, but OK, I’ll try it. Nope. That only shows all the various Google product links, no “report a problem” to be found there.
5. OK, the info window must be within Google maps then. Ha! Silly me, of course! I should have looked in the maps area all along. User error, my bad. I go back to the problematic map and bingo, I spot the more link right there in the left sidebar, er… info window. Why is the left column called an info window? That’s not my definition of a window, nor anyone else’s I suspect, but hey, details. Why quibble now, I’m so close to successfully achieving my issue submittal.
6. I open the “more” pulldown menu, but alas, the report a problem link is greyed out. What gives? Why show functionality when you can’t actually use it? At this point, I’m thinking to myself “Holy crap! I have got to blog about this.”
7. My last ditch effort is to click on the offending liquor-store-in-the-middle-of-campus pop-up  to see if I can report the problem there (maybe that’s what they mean by an info window?). Indeed, the pop-up also has a more pulldown with a functioning report a problem link.
8. The problem report asks me some questions in order to route and solve the issue, but the last bit of information they ask for is to let them know the correct market placement for the liquor store. I was nice in my reply since I’d like the problem corrected, but seriously, they want help in placing the marker correctly? How about using the address they already have listed for the store which is in a different city altogether? It boggles the mind.

User tests show that students have consistent informational needs when deciding which university to attend:

1. Do you have a program of study that interests me?
2. Can I afford that program?
3. Does the school’s culture/vibe feel right (will I fit in)?
4. Grad level students’s needs will lean more towards faculty, their interests and research opportunities away from cultural fit on a social level (grads don’t usually live on campus so the social component isn’t as important)

This basic set of questions all revolve around degree programs, not the broader departments within which they exist. Because of this level of specificity, departments should take a secondary role in how a higher ed site is structured. Degree programs should instead be the central organizing framework.

I see too many university sites where I can find a program of study through the top level pages only to be taken to a departmental site’s homepage where I have to find the same degree information I thought I was originally linking to all over again.

With a shift in how higher ed sites are organized, other pieces begin to fall into place: building communities around logical points of interest, presenting appropriate content (research, faculty, pricing, culture, etc.) within context and, importantly, filtering out a lot of stuff that’s not relevant because it has nothing to do with a student’s preferred degree program.

My bias is toward a balance between marketing and usability, but the bias gives more initial credence to usability than to marketing. Why? Because you can market the hell out of a site, a subsection or page, but if people don’t know it exists, then it doesn’t matter. That’s my main criticism of the DU homepage- It looks great (which is valuable in and of itself), but it comes at the expense of visitors (prospective students) getting their tasks completed slower and more inefficiently. The most powerful way to manage this tension is to 1) ensure your basic usability requirements are met and 2) make that basic usable framework as beautiful as possible.

If we look at the Apple and Google examples on this page (you can click them to access full size versions), you see this 1-2 approach put into practice. Google is a usable site. It gives visitors a short overview of the conference, easy to find/use links to additional information and a big button to join. But is it beautiful? Has it leveraged good marketing principles? Well, it does provide user generated content to breathe some life into the page, but I would argue that it’s not an engaging presence. It has leaned too far toward usability by disregarding the power good marketing would provide.

Apple’s page also provides basic information on the conference, links to additional information and a big button to join. The difference is that Apple takes that basic usable form and packages it with more marketing muscle. The page is beautiful. It’s engaging, active and makes me want to go in order to be a part of the energy depicted. This is a page that has found a good balance between marketing an usability.

Both conferences, being as high profile as they are, will undoubtedly sell out (Google’s already has as of this writing) so you could make a counter argument that Google’s lack of marketing didn’t hinder them. In fact, they likely saved money and time by avoiding the marketing point of view. True enough. But which conference do you want to be a part of?

Before we dive into the details, we need to define marketing and usability. By “marketing” I mean a perspective that exults the intangible- largely subjective areas like branding and visual aesthetics. By “usability” I mean a perspective that exults the tangible- things that are perceived to be objective through testing and measurement like navigation and functionality controls, categorization and flow of information. I realize you may disagree on my definitions, but for the sake of argument, I’m not here to say one is better than the other so feel free to change the definitions in your own mind. I support both as I’ve defined them. You should ensure that your visitors are represented through testing and measurement, but you also need to be a leader sometimes and do what you feel is necessary even if it’s contrary to user’s wishes. The two can work in tandem, but so often fail to do so. However, that is not a recipe for disaster in and of itself.

A higher ed site could go in either direction. DU’s homepage is squarely in the marketing corner while the task of finding degree information is squarely in the usability corner, yet neither truly works as intended for me, not to disrespect Nick’s conclusions. The homepage does indeed have impact and bucks the usual higher ed trend, but does it work? It does if you want to grab attention and differentiate yourself from the pack (I’ll assume a prospective undergrad student audience). But do students want different or do they want ease of use or a sense of what life at DU is like or something else? Is the leadership inherent in publishing such a bold homepage good or bad? I’d argue that the homepage misses the mark.

I don’t see any reason to be bold here when so much of our own research and those of DU’s consultants over the years points to the fact that people researching what college to attend are more interested in getting the four big questions answered as opposed to being “marketed” to:

1. Does the school offer the degree I’m interested in?
2. Am I qualified to attend this school?
3. Will I fit in socially/do I see myself being happy at this school?
4. Can I (and/or my folks) afford it?

How many of these does the DU homepage answer (or how many of these questions can you easily get to if you make your way to an internal page within the DU site)? To varying degrees, there are links and clues for each of them, but they’re overwhelmed by the gigantic photo and audience links. This page is more about DU than it is about DU’s customers.

UPDATE 4/29/2010: I decided to expand on this idea using a non-higher ed example.

Since title tags are an exercise in telling people what they’ll find behind a link before they actually go there, the act of writing it requires you to justify the relevance of the link in the first place. If you’re at Apple’s website on the Macbook page, you might see a link to their Macbook Pro page. Makes logical sense, right? If you’re interested in a Macbook, you might be interested in stepping up to a Pro model. A title tag might say “Step up to a Macbook Pro for added performance, storage, memory and more.” The sentence establishes relevance and a reason why you should click or not click. Job done, move on.

Let’s take another example, however. Let’s say you’re on a university’s annual report site, on any page. There’s a global link to the chancellor’s site. You write a link title that says… what? “Go to the website for Chancellor so and so.” No, that’s too obvious. “Get information about Chancellor so and so.” No, that’s not relevant to the annual report as a whole. “Get Chancellor so and so’s impressions on the year’s events.” No, if that information existed, it would be part of the annual report site itself.

The above reasoning hints at the utility of link titles. Writing them forces you to double check your architecture. Why does a link exist on this particular page or in the global nav? Is it relevant to include here versus over there? How does the inclusion of this link in this area on this page help the visitor accomplish their goals or further their aims?

All of these questions should have been asked early in the process, but things slip through or circumstances change. Writing link titles help verify that your user experience goals are kept intact and on track. Try it, it works.

So where does decentralization make sense? The obvious answer is content. Higher ed sites are large, if not huge, relative to many websites and the thought of centralizing that amount of content into a few hands doesn’t seem practical. The sheer workload would jeopardize the distribution of time sensitive information. Plus, no content person wants to work in a sweat shop environment were quality takes a backseat to simply getting the work out. And beyond even those practical concerns, will a content person be as passionate about every subject that comes across their desk as the people who live and breathe it?For those reasons, content ought to be unleashed.

This isn’t anything new Mike

OK, so a decentralized content scheme isn’t a new idea, but my point is that simply because it’s smart to decentralize content creation doesn’t mean ALL aspects of the web effort should go along with it. This includes strategy, information architecture, visual design and functionality. There’s no credible reason that I’m aware of that would cause me to believe that every dean, vice chancellor, and director at the university should control how their part of the website works or functions. That’s not to say they shouldn’t be at the table to discuss matters that affect them, but neither should they be allowed to dictate needs on a per site section basis either. This is how workloads get out of hand.

Give me an example

If group A wants to promote news, group B wants to promote events and group C wants to promote both, what happens in a decentralized world? The web team gives each group exactly what they want. But if information architecture is centralized, then you would look at all groups in totality. You would take all wants and needs into consideration en masse. Only then can you create a solution that can be sustained over the long haul in an efficient manner. In our example, you might come to the conclusion that lots of groups across campus will want to promote news and/or events. So instead of building standalone news and event solutions plus one that handles both, you could merge news and events into a single steam called what’s happening. Any group on campus could then tap into this single solution. Group A doesn’t have events? No problem, no events populate their content, but the “what’s happening” label still makes sense. Same goes for group B in reverse.

Technology folks will of course try to build solutions with modularity in mind, but this only goes so far. News and events is an easy example since we all know those ideas will port across many departments. But what about requests that have limited universal appeal or practicality? Do you build it? The answer lies in your overall strategy. 

You may not have a global strategy precisely because of the decentralized environment. But once centralization occurs, that all changes. You should have a basic understanding of what your site is supposed to achieve and for whom. In that light, a request for a specific feature that is only useful to a certain group or for a particular, somewhat rare occasion should be looked at suspiciously. If your site is supposed to communicate with prospective students and entice them to apply, then there may not be a good case, for example, in building a Blackboard login function. I’m not saying Blackboard doesn’t have utility, but not for your prospective student audience nor to achieve your goal to drive applications . The correct answer in this case would be a polite “no.”

Instead, I see many sites, our own included, take on projects to fulfill any and all requests without much critical thought as to their strategic value. So more projects enter the queue, timelines stretch out, both clients and customers get frustrated over the slow progress, staff morale suffers and the website becomes ever more confused. I would imagine that if you looked at your institution’s workload, you’d find a significant amount to be, at best, tangential to your main goals and, at worst, unrelated at all. Kill those projects and focus. Centralize the high level, strategic functions your group provides while you decentralize the ground level content that gives visitors localized flavor.

My issue with that argument is that, taken to its logical conclusion, every single department at the university essentially gets a different website. House them all under the www.yourUniversity.edu umbrella and you get the mess that is the modern higher ed website of today. Upper management is glad to see that every department gets individualized marketing attention and department personnel feel good that they have the ability to communicate uniquely.

Of course, in none of this acclaim and back slapping has the customer — students — had a voice. From their point of view, they experience a hodgepodge of loosely associated websites all claiming to be the same university. They struggle to find information because there’s no single underlying structure. They’re frustrated, but have no recourse because there’s only one university site to go to (it’s not like they can click to a competitor school’s site to get the information they need- they’re a captive audience in this respect). 

A centralized approach to higher ed sites does take away the ability to have unique designs for every department, but I will argue that this is a minor inconvenience at most and a complete red herring at least. A single “look and feel” doesn’t equate to an inability to be unique. All you have to do is look to the Obama presidential campaign to see this in practice (hat tip to the Higher Ed Marketing Blog for the link).

Obama, running for president of the United States, arguably has to speak to many more diverse audiences than does a university. Yet, all of his communications, all of his messages and all of his marketing materials down to the fonts and color palette are all the same regardless of whether he’s talking to a group of senior citizens at a nursing home or to college students at a campus rally.

Any well planned strategy will transcend low level squabbles about “our students are special, give us a custom website.” It doesn’t matter that anthropology students as a group are different from math students. What is important is that they all share the same kinds of needs in terms of wanting academic program information, tuition and financial aid information, social activity information, sports and athletic program information, and so on as your research indicates. Those commonalities should direct how and why your website is the way it is. Obama successfully communicated a single brand to a giant melting pot of diverse people on a national scale. It can surely be done at a university.

1. Approach site decisions with visitors in mind instead of the institution. A simple, but powerful stance. This single approach to web building will do wonders for you. For me, it called into question how higher ed sites work — how they reflect the institution’s org chart through their navigation and global structure. You know what I mean, its all of those individual sites for your academic departments, administrative units, colleges, schools, etc. that are loosely associated with one another. Each time you visit one, the design changes, functionality changes, navigation changes, etc. If this is the case with your university, I’d guess you suffer from inefficiency issues brought upon by teh need to maintain all of those standalone sites. You MUST put your visitors at the center of your decision making in order to sidestep all of this additional work. How? Read on…
2. Build sites around audience groups. Higher ed web teams tend to be small compared to the size of the sites they manage. This creates bottlenecks longer than necessary turnaround times. Organizing around your school’s org chart creates this problem. If you can accomplish step one and put visitors at the top of your priority list, then think of your site in terms of the much smaller number of audience groups your visitors fall into. You’ll go from dozens upon dozens of org chart oriented  mini sites to only a handful of audience specific sites. All the discovery, research, architecture, design, content, code and testing work you currently do for all those standalone sites will be (almost) vanish when you only have to deal with a few sites tailored to each audience group. For us, we’ve currently defined a total of six audiences. That’s a much smaller and easier number of sites for our staff to handle and it allows for efficiencies of scale.
3. Fulfill each audience’s basic needs. Before you venture off into social networking and introducing blogs, wikis, tags and other such tools, take care of the basics first. Your first task is to provide the most needed, relevant information for each audience built upon an information architecture foundation that’s flexible enough to accommodate future growth. Once you accomplish that, then add in all the other “cool” stuff. For example, your research may uncover that prospective students want to know the following: does your school offer the program they are interested in learning and does it have information on applying, cost and the social scene. Once you know that, make sure that information is readily available. This is really simple, but we don’t do a good job of it at DU yet. Our research tells us that prospective students (specifically undergraduates) don’t know nor think in terms of academic departments, schools and colleges. So, in our new site (to launch in January 2009), we won’t force prospects to navigate through a series of hierarchies based on the university’s org chart. Instead, they’ll navigate by subject matter, a concept they’re already familiar with from high school.
4. Extend the visitor experience. Once basic needs are met and proven to work through testing, then introduce social networking and other tools. With your visitors in mind (as always), ensure that the new functionality supports their wishes and needs and doesn’t become a distraction. You want to continually judge decisions about visitor experience in terms of your customers, not what the chancellor thinks is cool or what your competition is doing. Those are irrelevant issues (and yes, I realize there are politics involved, but still). It’s not about the chancellor or third parties. It’s about always meeting and eclipsing the expectations of your visitors.
5. Become more sophisticated. Step 3 will take a good amount of time, but along the way, you’ll begin to find that audience specific sites have their limit. I’ll write more on this topic, but suffice it to say for now that in the long term, defining mutually exclusive audience groups is limiting. Categorization is porous as people go in and out of various audience groups. I work at DU, for example, but I’m also a student and will be an alumni after graduation. How should I be treated? Prospective students become current students once they accept an offer. Does that mean their experience of the site should be turned on a dime as the transition occurs? These are important questions and demand a more sophisticated approach. I’ll write about that in the future. In the short term, however, building sites around audiences is beneficial to everyone involved even with the issues I’ve just pointed out. Audience specific sites will allow your team to rally around a central concept, give it direction and provide upper management and decision makers outside your team a point of reference. Armed with this game plan (all tailored to your specific circumstances as research uncovers, of course), decision makers will be hard pressed to create hurdles and obstacles because the strategy will be based on facts, not on people’s subjective opinions.