Why Support Websites (Still) Have Room to Grow

When my wonderful design team tackles a new support website project, we need to embrace two challenges:

Challenge #1: Can we distinguish the intent of the user? What is it they want to accomplish?

Challenge #2: How can they accomplish their goals in the quickest, easiest way? What’s the best path for them?

Note that the challenges are significantly more complex than when designing, say, UX for a support tool. For a support tool, intent is easy to figure out: just refer to the case workflow. Users will come in, check their case backlog, grab cases from the queue, work the cases. Paths are also predictable, and can be trained. In fact, many support tools have a poor UX but users have no choice and, from force of habit, become very adept at using even terribly-designed tools.

Going back to support websites, we need to identify and define three things:

• The personas: who is using the site? For instance, you may have end-users of your products, administrators, and partners.
• The tasks: what do they want to do on the site? End-users may be most interested in finding answers to technical issues, administrators may be concerned about managing support cases, and partners want to know the status of their RMAs. (And this is over-simplified: many personas will have an array of tasks they are interested in, with various levels of interest for each task at different points in their interactions with the products. Much analysis is required here.)
• The paths: how users will accomplish their tasks must be extremely easy because many users are not power users of the support website. They may visit only once, or only once in a while, so the website needs to be “obvious”.

So how do we accomplish this magic?

• We dig deep into the personas. For instance, did you recently undergo a merger? Then, you inherited a number of new personas that may have completely different intents from what the site was originally designed for. Or your product line is expanding, which means that new kinds of users are going to be using the site, and they will have specific needs depending on the product they use.
• We separate form from function. We start by designing functionality, which means identifying a hierarchy. If a user can do 25 things on the site, we don’t want an old-style list of 25 links! Instead, we want to identify a handful of common tasks and highlight those–and personalize the experience if we have lots of returning users. Only then do we refine the hierarchy with branding, images, color, and other visual cues to guide the paths.
• We conduct user tests. Yes, the support team members have a pretty good idea of what users want–but they are not the users! It’s common to find that users are actually not that interested in functionality that the support team thought was critical–or cannot understand wording that’s really internal jargon.

One last idea: small vendors can have terrific support websites, even with a low budget, because they have to cater to a single persona, who needs to perform a handful of tasks, using a single back-end tool. With a clear intent (thanks to the homogenous user base) and clear paths (because of limited functionality), success is at hand. Challenges often develop a couple of years down the line as the lineup of personas, tasks, and tools expands.

How would you rate your website? Tell us in the comments.

[We’re here to help! Contact us if you want an assessment of your website, or help realigning personas, tasks, and paths.]