You are visiting the High Monkey blog archive. Posts prior to 2016 may not meet accessibility standards. Please visit our current blog area at to view accessibility compliant blog posts published since January 1, 2016.

Usability Testing: Why you need it, and when you don't

Written By: Jared Vander Hook
Posted: 2/27/2013

Usability Testing seems more and more commonplace in web projects, yet at the same time when the budget gets tight it is often the first line item to be cut. Why is this? My experience has been that clients love the idea of usability testing, but don't necessarily see it as a critical component. To that I ask (somewhat facetiously), "What is more critical in designing a User Interface (UI) than understanding the users who use it?"  Nobody disagrees that users are important, but something must be missing. I don't think that usability testing is misunderstood as much as its essence is unrealized by many.  To realize the essence usually requires experiencing the process, first hand. Unfortunately the experience is difficult to provide first hand since a client must agree to pay for the testing BEFORE we can do it.

This leaves it up to us, as web consultants to explain the essence of usability testing better. This starts by explaining why you need usability testing, or in other words its purpose. Not just the abstract, conceptual purpose, but the practical purpose. It also means realizing when NOT to conduct usability testing.

Why You Need Usability Testing

Usability Testing can make the difference between a mediocre UI and a great UI. The most likely response to this statement is, "That's great, but how?" Or in other words, "What is the practical purpose of usability testing?" To answer these questions let's first look at your project without usability testing. The decisions, ideas and the overall direction of you UI design must depend on the project's team perception and understanding of the user, not actual users. And the reality is, the project team does not usually have a clear understanding of their users, or at least not clear enough to answer all of the questions that will arise during the design process. This means that there is a need for the project team to establish a better understanding of users. Usability testing not only helps you understand your users, it helps project teams discover issues and opportunities, make better desicions and validate ideas your team has during the process. Here's how...

  1. Understand your users
    Understanding how users find information is what puts the User in User Interface. This is what should guide your team through the entire design process and is essential to creating a successful website or application with exceptional user experience.
  2. Discover issues and opportunities
    Every usability test I've been involved with has uncovered some issue and/or opportunity to improve the UI that would have likely gone unnoticed otherwise. This is how you can turn a good UI into a great one!
  3. Make better decisions
    The opinions of those on a project team can, and often do differ and contradict with each other, but it is very difficult to argue with usability test results.
  4. Validate ideas
    We all have them, but some are better than others. Let the user be the judge!

In addition, usability testing will help you ensure your UI measures up to the 5 quality components of usability; learnability, efficiency, memorability, errors and satisfaction.

When You Don't Need Usability Testing

While I believe that usability testing is a critical component to any web project, timing is of the essence. I bring this up because many tend to think that usability testing doesn't need to happen until the design is complete, or nearly complete. This might makes sense for certain types of testing, but not for usability testing. Waiting until the end of a project will narrow the scope or purpose of your usability testing to only validating ideas. Since all of the decisions have already been made at that point and the design has made its way through the entire design process, it is much more difficult to give practical use to the information uncovered. As a result understanding users, seeing issues and opportunities and making better decisions are no longer add as much real value to the project and a lot of valuable information goes to waste. I have seen this happen on projects more than once. Here is an example of one...

About a year ago I was working on a project to design a brand new website for an organization, and at the start of the project they determined that usability testing would have to be limited due to budget constraints. It was also decided that the limited user testing we would do would happen at the end of the design process, which means it would essentially just be a validation step before the site launches.

The project went through the design process and it was now time to start usability testing. I conducted the testing, did the analysis and my findings included 6 usability issues, which is not out of the ordinary. As usual, I presented these findings to the project team along with a suggested solution for each. The information was well received by the team and everyone seemed excited to have the suggested changes implemented to the design before launch.

With that, I left the meeting feeling good about the outcome and was ready to go back and work with the graphic designer and developer to make these usability enhancements to the design. Before I started any more work, I had to discuss the changes with the PM to get the final green light.  This discussion didn't go as well as I had planned. In fact, before I even made it through everything, the PM was telling me there was not enough budget left in the project to make all of these changes happen. The roadblock was placed in front of me and we were able to squeeze through a couple changes, but nothing more. As you can imagine, this was a frustrating situation for both myself and the client.

This roadblock was a direct result of conducting usability testing too little too late. The situation could have been completely avoided by conducting the usability testing earlier in the design process because it would have caught these issues in the early design stages making the changes easier. Better yet, establishing a basis of understanding of the users during the early design stages would have established an understanding of the user audience that could have better guided the design concepts so changes weren't necessary in the first place.

When You Should Include Usabilty Testing in Your Web Project

Now that you know when NOT to conduct Usability Testing, you probably would like to know when you should. I'll start by saying that usability testing should be tightly interwoven in the project design process. This might be different depending on the design process that is followed, but I will explain how this looks according to the iterative design process that we follow.

There are at least 2 essential iterations of Usability Testing that every web project should absolutely include, but to achieve the greatest user experience I recommend incorporating all 4 of the following iterations.

  1. Baseline Usability Testing
    Only used when a website is being redesigned, baseline testing helps indicate the elements of the existing site that work for users and those that do not.
  2. Wireframe Usability Testing*
    *An essential iteration, wireframe testing validates the initial layout, organization and structure of the site and provides valuable information about users that tend to guide decisions and direct the design concepts.
  3. Beta Usability Testing*
    *An essential iteration, beta testing validates the graphic design components layered onto the structure and organization of the site to ensure that it works in concord with each other. It is also vital to identify any issues or opportunities at this point because it is the last stop before the release design.
  4. Release Usability Testing
    Once the final design has been created it is helpful to validate the final website design and uncover any minor issues or opportunities that could be easily changed in the design before launch.

Chad's Bio Coming Soon!

More About Virgil

Virgil Carroll is the owner and president of High Monkey – based in Minneapolis Minnesota. Virgil also wears the multiple ‘hats’ of Principle Human Solutions Architect and SharePoint Architect.

Virgil is one of those rare individuals who can dive deep into technical topics while speaking clearly to the business owners of a project and never forgetting that the end user experience has the highest priority. He calls it using both sides of his brain. Virgil is passionate about leveraging technologies ‘out of the box’ as much as possible with a focus on the strategic use of content to create websites that deliver the right content to the right audience on the right device at the right time. Virgil brings high energy, an ironic wit, and a sense of grounded perspective whenever he speaks to an audience. Virgil regularly speaks at conferences and user groups throughout the United States and occasionally in Europe.

Posted: 2/27/2013 12:00:00 AM by | with 0 comments
Filed under: