Testing to the Usability Standards Our Customers Expect

I work for a company in software quality, and 95 percent of what we distribute are commercial, off-the-shelf solutions to our employees, who are my users or customers. As part of our process for implementing a new solution, we work with our users to develop test plans to ensure the configuration delivered works as planned. I am fortunate to have a team of excellent testers who build and then execute these tests.

Often, I get involved with a user where there is a functional question, and I rely on the configuration requirements to determine whether the configuration works as required. Now, this is when the fun starts.

I am a big believer in usability testing, and I get excited when I see issues where the software has a simple usability flaw. But when we dig into the issue, we discover that this is how the software was delivered from the vendor, not something related to our configuration, so the issue got classified as “Works as designed.” My users look at us like we should not be allowed to walk and chew gum at the same time, as these issues are just dumb mistakes from the software factory.

Having worked for several software development companies, I can tell you they are staffed with really smart people. First, the software designer develops the features and functions to be included in a section of code. Next, this design gets coded and goes through several rounds of testing. At some point in the cycle, the rush to ship allows bugs to creep into the software, and they’re either not fixed or not caught, as there is only time to test critical features.

I would love to be able to say software quality has gotten better over the years, but it has not. In my opinion,the ease of pushing patches has allowed our vendors to get lazy and produce code with known issues, just leaving it to the user to find them.

But it doesn’t have to be this way. We’ll never catch every weird, obscure bug, but there are some design elements where they tend to lurk. By focusing our testing efforts on the following areas—or at least not neglecting them—we can catch more issues before our customers do.

Text Boxes
I have seen this issue too many times to count: a text box that shows room for fifty characters but only has room for twenty-five. When a user sees the field size on the screen and creates a statement in their head that will convey the needed information in the space allowed, it is really annoying to see the text stop halfway through and then get an error.

I even had a cloud-based solution that has more than fifty thousand installations that would let the user enter the whole line of text, but then when you tabbed out, you got an error message that the length exceeded the available space and then it would clear what you just typed! Obviously the designer of the page knew how long the intended length was, but somewhere in development, a design change happened to alter the storable length but the page never got redrawn.

Checkboxes That Act as Radio Buttons
You see a block of text boxes that tells the user they can select zero, one, or more options to filter the data. But then the user is required to select one checkbox, and when they try to select more than one, only the last one selected remains checked. Again, a design change happened in coding and was not fixed in the testing window.

Sorts on Results That Only Look at the Displayed Data
You create a filter that returns four pages of results and you would like to sort based on one of the fields displayed that offers filtering. However, when you try to sort, only the records displayed on the page are sorted, so the sort is pretty useless. This makes users nuts!

Lack of Tab Order Testing
Not all your users use a mouse, so a lack of tab order is a real issue for those using specialized equipment or where a standard mouse is not an option. Think about scanner guns or where your user has a vision issue and uses a Braille monitor. Not only is there a risk for a lawsuit from the ADA, but more importantly, all of your users should have access to the same level of usability.

Where’s the Submit Button This Time?
If you are going to have a submit button, put in the same place on all pages in the application. A lack of consistency shows a lack of a design standard.

Too Many Fields on a Single Page
Your users are probably doing multiple things at once, so if you ask them to enter more than twenty fields before they can save, it is an issue. You should consider a multipage form or a method for the user to save a transaction in a temporary state.

A Long Page with Only One Submit Button
We have all see the long screen with a ton of fields to be entered before you can do the submit action. But if the submit button is at the top of the screen and gets hidden as the user enters the required data and scrolls down the page, help them out and put another submit button at the end of the page.

Typos
I know spellcheck testing is no fun to do, but with all the tools out there today, there is really no excuse for your user to see typos anywhere in the application. It makes your product look lame. This includes help and error messages, too.

No Auto-Scroll Bars
If your user makes your application smaller on the screen than it was designed for, scroll bars should appear. Yes, you are all saying, “Of course,” but I had a fight years back where the vendor said the screen was optimized for XY screen and this was not a bug.

Broken Hyperlinks
This is another easy item that should be tested before it goes out the door. There are automated tools that will verify that all links actually go somewhere.

Help That Does Not Connect to Any Help
If you have a user desperate enough to look for help, make sure they can actually connect to the help content. Again, it is likely that help was created during the design phase. What is lost is the connection to share the help with the user who really needs it.

None of these issues would be scored as a critical bug, but that is not a valid excuse to release solutions with these kinds of basic design flaws. The ownership for these issues is ours as software providers, and we need to raise our standards for these kinds of issue.

What issues have you and your users seen?