The Broken Access Experience

Most people struggle with basic digital product access. Activities that product teams take for granted (e.g., sign-up, log-in, password recovery) confound users. Failure is alarmingly common. To understand the depth of this problem, read our previous post, Digital Product Access: The User Experience Problem of Our Time.

The Problem of Complexity

Unfortunately, granting access to online products is highly complex. It involves security, authentication, roles, and advanced functionality like customization and personalization. Serious stuff. Because of this, the access experience inherently resists simplification. We are not going to change current models anytime soon. The problem is too big. But we can mitigate user pain.

Making the Access Experience Less Painful

You are not powerless in light of this daunting problem. You can take steps to substantially improve your users’ access experience.

First, agree with reality.

Accept the fact that nearly everyone has fundamental problems getting and keeping access to digital products. Assume your products are not immune. Burn this deep into your institutional psyche.

Assess your digital products right now.

Get a specific sense of how your users are gaining and keeping access to your products.

• Talk to your call center. Ask your call center to report on the number and percentage of support calls associated with passwords or log-in issues. Identify the most common complaints. Track this regularly.
• Dig into analytics. Research analytics and/or server logs to identify recurring usage patterns around access. Consider using a third-party tool (e.g., CrazyEgg, Hotjar) to more precisely hone-in on user activity.
• Survey your userbase. Ask people directly about their sign-up, log-in, or password recovery experiences.
• Observe and track user behavior. Observe people dealing with log-in and attempting password recovery. Don’t help. Just watch and learn.
  

Align your team to the problem.

Make the creation of a smooth, easy, courteous access experience a standard practice for everything you make.

• Set responsibility. Give a small team ownership over the access experience. Be sure to include a UX pro (who may be in charge) and a content strategist.
• Make immediate adjustments. Based on your research, start by addressing high-value, easy-to-fix issues. Break the work into small, digestible chunks, something you can turnaround in roughly 1–2 weeks.
• Prioritize bigger fixes. Some issues will take more effort. List them by value and effort. Have your special-purpose team prioritize them. Start a formal project that addresses the top priority.
• Iterate based on research. Make user research and careful consideration of new technical possibilities continuous. There is always more to learn. You can always get better.
  

Think multi-channel.

If I want to get or re-establish access to your product, I will interact with your organization on multiple fronts, possibly using multiple devices. I may begin by visiting your site or app on my desktop. From there, I may transition to email for verification, or to my phone for text authentication. I may return to the desktop to attempt access. If I fail, I may consider other avenues of relief, which could include searching for help, emailing support, chatting, or possibly calling you (shudder).

Access is not a monolithic activity. It’s a collection of different activities done in sequence. My opinion of your organization hinges on how each of these activities work out. If my so-called “user experience” is lacking in any single part of the process, I will blame your whole organization. This means I am more likely to jump ship to a competitor (or never get started with your product in the first place).

Therefore, you must embrace a universal, multi-channel view of access. This means mapping user journeys across disparate channels, devices, and activities. Disparate internal teams (security, IT, user experience, product owners, etc.) must collaborate and insist on a unified approach to access. This is not a problem that can be fixed piecemeal by one isolated group.

Meticulously design for failure.

Screen-based experiences rise or fall based on what happens when things go wrong (which they always do). Quality products help users recover effortlessly when they encounter trouble. And nearly everyone has trouble with access. The entire password recovery process is a massive, cross-channel path rife for failure. You must plan for the inevitable.

• Spend time here. People have terrible trouble understanding and recovering from errors largely because dev teams don’t pay enough attention to these situations. Carve out time on your project schedule to ensure careful modeling and testing of what happens when things don’t go as your users expect.
• Reassess error handling from the ground up. Have your UX lead rethink how and when you display errors, what those errors say, and how users are guided from error to resolution. Do not assume you are already doing this well.
• Test edge cases. Dev teams are practiced at accommodating rare but possible usage scenarios. Build on this by making sure all edge cases are assessed not just for proper function, but also for excellent user experience. Your UX lead can show the way.
• Rethink everything. Immediately have a content strategist assess and rethink every single user-facing word, detail, and interaction associated with log-in failure and password recovery. Speaking of which…

Use simple, plainspoken language.

Don’t speak or write in computer science lingo. It’s obnoxious, yet most dev teams do it. You may understand technical jargon (“query,” “submit,” “invalid,” “fatal error,” “404,” etc.) but your users consider it confusing jibber-jabber.

Instead, write or speak with a basic, down-to-earth voice. Employ words your users reflexively understand. Make every heading, bullet-point, error message, email, text, chat interaction, instruction, and voice prompt the very picture of direct simplicity. Test the clarity of your interface communication with novice users or, if relevant, elderly folks.

Adopt basic UX best practices.

Well-researched and time-tested user experience standards for product access are readily available to your team. A few noteworthy considerations include:

• Follow UX guidelines for forms. Build every form field, element, and action according to UX standards for form interaction. Many books have been written and millions of pixels devoted to defining these guidelines. Start with Web Form Design: Filling in the Blanks by Luke Wroblewski. This will get you started in the right direction. The main thing: Do not assume your forms are already foolproof.
  
• Be wary of out-of-the-box solutions. Pre-made UI solutions, especially ready-to-use forms offered by content management systems, are not known for their UX rigor. Error handling and accessibility are often lacking. Customization (in this case bringing forms up to snuff) is usually difficult and time-consuming. Don’t accept expedient plug-and-play solutions at the cost of usability.
  
• Make your products accessible. Log-in experiences are frustrating enough already. Don’t compound the problem by making things harder on disabled people (a much larger segment of users than you may realize). Ensure everything you make conforms to WCAG AA guidelines. Bonus: By making your product accessible, you’ll fix a host of other usability problems in the process.
  

Avoid common pitfalls with help content.

When we ask users to tackle complex things, our first, and worthy, instinct is to help them. But sometimes the help we provide does not really help at all.

• Ditch “discoverable” tool tips. We’ve all seen little icons next to form fields, perhaps a box with a question mark inside. On click or roll-over these icons expand or pop-up a dialog box to show instructions, definitions, or explanatory content. Unfortunately, these discoverable conventions are seldom found by users. They are rarely accessible and prove especially problematic on mobile devices.
• Be judicious with contextual instructions. If you must offer field-level instructions, position verbiage immediately near relevant form fields, ensure this content is always visible, and have a professional content strategist write every word. Drastically limit word count.
• Do not invest in elaborate Help sections. People generally visit help links as a last resort. They will often call first, even though they dread automated attendants. This should tell you something about their expectations for your glorious online help content. Even when help sections are accessed, content is often not immediately relevant or organized in a way that makes finding a solution easy. Don’t waste money here.
• Avoid long paragraphs. Do not introduce or decorate any form, interaction, or key email with copious text. Get right to the point and stay on the point. These words are nearly always ignored. Even a sentence is often too much. Always use as few words as possible.
• Don’t rely on “Frequently Asked Questions.” FAQ content is ill-suited for solving immediate problems. This sort of content is better for promoting high-level understanding of a product, service, or process.
• Offer step-by-step instructions for novice users. If your product targets a mass audience, step-based instructions (in this case, for logging in and getting access) can help. Put these instructions on a separate screen and follow all content guidelines in this article.
• Make the access process simple in the first place. It’s best not to need instructions or help at all. If your interactions are simple, headings clear, and error messages understandable, your users will have little need for elaborate directions.

Test your access process with users.

User testing is by far the best way to ensure your access experience is the best it can be. You can test online or in-person. Just keep your tests strictly scientific.

• Test prototypes. You can test almost any process early, when work is still low-fidelity (e.g., paper sketches or rough wireframe prototypes). You’ll uncover big problems before you advance your product too far.
• Test the real thing. Nothing stops you from testing your current, live process with real users. You are virtually guaranteed to learn something new and vital.
• Test with disabled users. If you really want to make your products accessible, test them with folks who use screen readers or assistive technology. Just because you comply with WGAG guidelines does not necessarily mean disabled users can easily use your product.
• Invite developers to watch. Always invite the people who write code to witness user tests. Nothing changes the mind or sparks innovation quite like watching people struggle with something you’ve built.
• Make it a habit. User testing works best when you do it continuously, as a standard part of product evolution. Establish a regular schedule and stick to it.

You can improve the access experience.

Digital product access is astonishingly challenging for most people. It is one of the most vexing user experience problems of our time. And it is not going away soon. Someday we’ll look back and shudder at today’s primitive log-in and password practices. Until that day comes, we must do everything in our power to reduce pain and mitigate frustration for our users.

You can do this. Start by aligning your team to the issue, then attack it methodically. If you take the steps we recommend here, you can make even the most complex, infuriating interactions smooth and tolerable, even log-in and password recovery. 

Missed the first article in this series? 
Read Digital Product Access: The User Experience Problem of Our Time