In life, the only things we can be sure will certainly happen are death, taxes and website and software performance pain points.
If you rely on tools to test your website or application, you may never find what confused your users. Tools can show where problems are found within the code. Tools can look for specific pages and provide insights into how long users remain on a page and where they go next. They don’t have any idea why humans make the choices they do.
SEO tools, page speed tools, mobile emulation software, and accessibility testing tools are not programmed to know what to do on a bad day when the car breaks down on the way to work and the driver must search for a local automotive service business. If you’re the owner of an automotive service station website, you need more than a website brochure to generate a satisfying user experience.
Somewhere in the data of that website is an out of town salesperson who one day stood in the pouring rain on the side of a busy road popping the hood of their rental car, only to find a serious problem. They become frustrated, upset at being late for an appointment, start digging for the rental car paperwork and dialing up places for help in an unfamiliar town. What does that look like in your data?
Do you see that story? Can you tell from the data whether your website had what that person needed? Did they have trouble locating a phone number? Did the pages load quickly? Could they read the content? Was your website the one designed to help the person who needed help in an emergency? Was there enough information provided for that person to remember your business name when they clicked away by accident because they were in a stressful situation?
When putting together a plan for developing a website or application, the user experience is often left out. I know this because I’m hired after projects are launched to figure out why they’re not meeting business, performance or conversions expectations. Their data from Google Analytics are a horror movie. Stakeholders are bug eyed crazy, seeking someone to blame. Most certainly they will not find fault with the marketing department. They will blame the SEO who didn’t get it ranked correctly, or the programmer who didn’t code it to load fast enough. Or the user interface designer who didn’t make it accessible. Anything but what was needed the most before it met the public.
An untested design will not generate revenue.
Looking at it another way, when we want to buy a new car or blender or lawn mower, we typically will research it first. We compare products, read reviews, look for consumer reports data and check for safety ratings. In other words, we’re more willing to choose a tested and customer-valued product.
So why do we expect website visitors to use untested websites?
What is a Pain Point?
We experience them every time we go on the web in search of something we want. Say, for example, that you and a friend want to search for and join a local yoga or fitness center, so you can be workout buddies. If you were to ask your friend to describe their web journey, you might share similar habits and follow similar steps but what positively bothers you may not annoy them. What you consider broken or confusing may not be broken or confusing for them.
We do have an idea, however, for what drives users crazy because there are people studying how we use websites, search engines, software and hardware. Patterns appear. User testing provides personalized feedback. Planned experiments gather data that is later analyzed for case studies.
Some design fads, for instance, cause us to become angry because they prevent us from completing a task. That’s a pain point. After a while, enough data is collected from user and usability testing to finally convince the design world that what they believe is a creative design element is infuriating to users.
For example, gray colored text on blue colored background or light gray text anywhere, especially in a small font size, is a fad and a pain point because the gray color prevents many users from seeing the content they need.
Another pain point is redundant links on a page that go to the same page, but the link text is changed to be optimized for SEO reasons or because the designer has no faith that anyone will click on the first link to the page, so they pop it in again and again. Forcing users to go in circles is a pain point.
The mobile menu hamburger symbol could be considered a pain point for some people because it contains no useful content and must be activated to get to the site’s navigation. People are lazy. For years we had only to glance at the desktop header to figure out what the site offered and how to find what we need within it.
One example of a pain point that can depend on the user’s experience with technology and computer devices is a link that opens a new window when clicked. On a mobile device, new windows are something that requires learning how the OS handles that event and then remembering how to use it and then figuring out how to get back to the previous page without accidentally clicking the wrong window. Or some version of this. New windows sometimes present an entirely new page layout or take users off-site or are closed by accident. Some users just hate them.
A common pain point is a poorly structured information architecture with navigation that does not contain breadcrumb navigation. That breadcrumb navigation is the most valuable content on a webpage because it shows the user where they are within the house, the room they came from, and how to get back to the main dining hall. Not providing directions in a clearly visible area is a pain point.
Forms that are not designed for mobile transactions, complicated apps that throw errors when really the fault is the app’s design, not the user’s confusion, sliders and videos set to run automatically and hidden links that must be activated with a mouse to be seen are pain points. Touch screens and voice search are part of the user experience but may not be included in testing before launch.
Playing Detective
The most valuable lesson I’ve learned from usability testing is to put myself in the role of users. As a detective in search of clues, I play many roles. I create characters and perform tasks based on the company’s business requirements and target market data, and interact with each page, form or application while in character, just like an actor would.
I need to know my characters. This requires a great deal of research into user behavior, human factors, and neuroscience. I comb through research papers and studies to get the most updated findings looking for ways to learn how people think, purchase, search, read, share, subscribe, and what they consider pain points.
Manual testing methodologies like content mapping, journey mapping, user testing, and cognitive walkthroughs dig up facts and findings that may be analyzed along with data gathered from other resources and tools.
Performance pain points tend to be hidden or don’t appear until activated by people. When we see and understand web site pain points we can make repairs and enhancements to the user experience based on real situations and user stories. Take the time to listen and watch and add those observations to your data. Keep testing and tracking the results. Signs of healing will appear in your data, increased sales and improved conversions.
