We have no excuse…admit it. UX may brag about intuitive and pretty, but we sure suck at helping people—this one thing that most defines, most embodies great user experience.
Article Continues Below
Throughout history, there’s one recurring theme: people need help. For all we know, the need for assistance might have triggered the development of communication. It could have led to bonding among tribes and our existence today. In the future, it might be the only thing that staves off human extinction and promotes societal evolution.
But if so, that begs the question: why do we find it so difficult to ask for help or offer guidance to one another? Do we prefer to figure things out for ourselves? Are we afraid that any request for assistance would be fraught with obligations to reciprocate? Are we worried that we’ll be rejected? Or that we might not get the help we need?
People do need help. It’s a given—and a problem in the field of UX. We claim to do so much for users, but treat help as an afterthought. How come it isn’t our primary consideration?
A glance at most websites, including those for large and small organizations, suggests that user assistance is treated as a cursory option—often relegated to a question mark symbol tacked onto a corner. The assumptions are:
- Users won’t need help; the design is intuitive.
- If users do want help, they’ll look for it (somewhere).
- Once users figure out where to look, they’ll seek help when they need it.
If the same scenario were layered on real-world interactions, it would be analogous to visiting a large museum, with maps, tours, guides, and program schedules hidden in a locker at some end far off the main entrance.
Why offer help before it’s requested?#section2
Taking the guesswork out of a customer’s experience is beneficial to all involved.
Consider that you’re walking into a new casual diner. Initially you may wonder if everything is self-service, and if you are expected to clear your own table. You could just stare at folks around the room and make your move based on what other diners are doing. Or, the franchisee could help you get up to speed right away. Ikea solves the what-do-I-do problem with a “Why should I clear my own table?” sign right at the center of its popular store restaurant. The sign solves two problems—it gives the customer needed information immediately and it promotes Ikea’s aim to cut costs.
Designers create user interfaces through careful planning, so one popular conclusion is that if a design has been a success, no explanation—no prominent sign—is required.
But help is often sought or needed for a variety of reasons. Help could be required to explain certain fields in a form, to define the meaning of a specific icon, to parse highly technical terms, to identify new features, to illuminate hidden gestures, or to detail policies that are obtuse.
A user may immediately understand that a pencil icon opens an editing pop-up. If he doesn’t, he may well figure it out eventually but only after moments wasted in confusion.
No matter how smart a design is, unless it is customized to every user’s personality, needs, working conditions, device, domain knowledge, technical expertise, and mood, it will need some explaining. A good designer empathizes with unique concerns and takes users as they are, from practiced online mavens to casual browsers. A good design includes user assistance that is given due consideration.
When help goes wrong#section3
Sometimes websites do make dedicated attempts to help. And sometimes those attempts smack of overkill.
There are video tours expertly created to take users through each feature in the product. There are slideshows with custom fonts and colorful characters that highlight everything new and promising in the release. There are translucent overlays of clever pointers to indicate where useful action commands are located.
Analytics and studies show that when presented with any of the above on launch of an application, a user either:
- Rushes through it with no interest in its content, or
- Closes it.
The main issue with providing informational assistance as the first screen is that users do not care yet. They have not seen enough of the product to want to learn about its intricacies.
Users want to get to the product as soon as possible; they’ve already read the marketing material, gone through the registration process, perhaps even read the “Terms and Conditions.” They do not want anything else to lengthen the delay. If forced to read through preliminary content or go through tours, they do so while disengaged and hence, promptly forget all they learned.
Some applications have book-length help manuals. Immense thought and work goes into writing and creating these documents. But they exist in a separate world, removed from the application itself, expecting the user to click away from her task at hand to read and learn. Often, they are poorly designed, making the process of finding information in the “help” website a chore.
Handholding, intrusive help is as frowned upon in the design world as lack of intuitiveness. Examples of this include forcing open an overlay with offers of help while the user is engaged in a task; loading screens full of product descriptions without context; or launching a product tour that must be completed before the user can access the product. This is where the need to understand the goals of the application comes in.
Is this an enterprise application with cloud-based storage, multiple server connections, and sensitive data transfers? In that case, help should become a visible priority. What if it’s an app built with a strong gamification approach? In that case, help can probably take a passive backseat.
Consider user behavior patterns while designing the help function. Some users prefer an uninterrupted reading experience—they like to dive deep into the subject matter, read every instruction, perhaps even download the content for offline reading. They rely on in-depth topic descriptions. On the other end of the spectrum, some users prefer to scan the text. They only seek help after they’ve made a mistake and will rarely go to a dedicated off-context help website. Short bites of support within the application work best for them.
Instructions offered in a non-intrusive manner can enhance an experience, whether real or virtual. Hiking on a trail with clear path markers, distance indicators, wildlife cautions, and plant and foliage descriptions would be safe and informative and hence, helpful. The “x minute read” tag in Medium posts, the Slackbot messenger in Slack, and the delineations of simple steps in Google Apps Learning Center are all examples of help offered to users without distracting fanfare.
Simply ensuring your user assistance function is visible can be enough to provide comfort. In the same way a good interface doesn’t make users think too hard, a good help function should be easy to find and access.
Help can be designed to be contextual or stand-alone (a mix of both works best).
Contextual help is any form of user assistance that is embedded within the product’s screens. It prevents disruption from user’s immediate focus. It is concise and quick to read and access. It is available when the user requests or—even better—expects it.
A few examples:
- Tooltips that appear on hover indicating the name of an icon or button.
- Info-tips that open after clicking an “i” or “?” next to a form or field or any part of UI worth explaining. These should have brief content that explains the purpose/meaning of the relevant element.
- Ghost text that appears within a text field or next to the UI element to help users learn about the element.
- A panel that functions an an overlay within the product screen, providing users with more detailed help information.
- Quick “Getting Started” guides that merge with the interface and take users through the actions flow.
- Tooltips indicating feature upgrades within the UI.
- Hint text that demonstrates search protocols—such as suggested keywords that actually work in the application.
Stand-alone help can take a more detailed approach.
Designing the help center for an application is usually a challenge. Should information architecture match the application’s architecture? How will users approach the content? Would they want every action and interface element documented? If so, how should the content be structured for easy perusal? If they don’t, how do writers prioritize topics? How much is too much?
Effective search functionality can help save users from getting lost in content; a prominent search box makes it simple to locate the right topic before users get overwhelmed. And if the application’s search option is internet friendly, it will appeal even more to those users who prefer using a “real” search engine (like Google or Bing).
Documentation categorized by features or tasks allows users to filter more quickly. It is also important to identify which information warrants greater visibility—help users solve their most pressing concerns, and quickly. Customer feedback, analytics, and user research can help determine which topics your users are looking for most.
The myth of technical proficiency#section6
Enterprise applications as well as consumer applications can benefit from a well thought out help system. It’s poor logic to say that an interface is designed for “technically proficient” users who therefore won’t need any help.
A well-designed help function is more than a set of instructions in an emergency. It is thoughtful, approachable, and considerate. It knows that no quest for assistance is too small, no needed explanation is too big. It’s time we uprooted the precedents of cumbersome or “barely there” help functions. It is time to make Help helpful.
After all, needing help is part of the human condition.
