By Frank Spillers

usability testing

Summary: Usability testing is usually best conducted early on when you have concepts, wireframes or even static sketches or Photoshop compositions. There are really good reasons for early-on testing, related to the ROI of UX. 

"When should we test?" is probably one of the most commonly asked questions asked about usability testing. It's also one of the most misunderstood topics in UX (user experience). So let's break it down and unpack this question.

So, when should you conduct a usability test?

Usability testing is by nature a tool for refining a design. It is used to validate direction, uncover user expectations and to guide a design to a better place. When something is developed it is more difficult to pivot, period. This is why testing early-on makes the most sense. Usability practitioners and consultants regularly test early-on without question. We call it 'low fidelity" or "paper prototyping". This comes from the fact that we used to test with paper prototypes, yes literally static pieces of paper moving around a table simulating a computer. Since a myriad of UI prototyping tools exist today, our prototypes are typically higher fidelity ie. click-able HTML. Also called "throw-away HTML", smoke-and-mirrors or Wizard of Oz prototypes.
Early on usability testing fits into the Design Thinking and Lean UX approaches respectively: a) Check in with your audience, b) Check in before you commit to a path. The goal of early-on usability testing is to inform your design strategy, not necessarily to generate statistics, as in more formal aka high-fidelity testing.

Wait until you have a solid design right? WRONG!

Waiting until you have a solidified design is like cooking an entire meal with chili powder and then asking guests if they can handle hot food (I've done this a few times, trust me it's embarrassing). It's better to check to see what your guests can handle before you cook the entire meal. When I've tested designs that are complete, I've missed out on these key benefits- uncovered by testing early on:

  • Wizard of Oz prototypes can be ripped apart without any developer or designer's ego bruised.
  • Watching users use "broken" wireframes gives you insight into how they problem solve their way around. Hint: Designs with high ease of use are easy to navigate even when 30% of the design is not functioning.
  • Native expectations of what should be where can be assessed (especially when there are unfinished or placeholder ideas, common in early-on testing). Doesn't make sense I know, but remember we are evaluating expectations not functionality as in quality assurance testing.
  • Changes to navigation or things users miss can be rolled into development faster than if the boundaries and timelines prohibit reacting to change.

At what stage is usability testing a good idea?

Let's quantify early-on...By early-on we are referring to design projects that are redesigns or are new products. Early-on means when you have a wireframe that's usually substantial enough to put in front of a user. This is before Photoshop is even fired up or before a single line of code is written.
One of the best practices in Agile and Lean UX is to break usability testing up into smaller tests, spread out across time (so you get the benefit of early-on AND closer-to-launch user feedback). Early on helps catch defects in the wireframe/comp stage, and later on helps catch the more interactive stuff (as if live)-what the user will actually experience. 

Are there other benefits?

Early-on usability testing is not just a tool for UX designers or developers. Inviting stakeholders to early-on tests is important to help guide decision-making downstream as well as to encourage a culture of UX, of which UI prototyping and testing of prototypes is critical.
Finally the other two big benefits I find is that doing usability testing during the planning phase truly involves users up-front (a goal of UX design).  Getting early-on feedback is of immense value to UX designers trying to find the best way to negotiate complex business requirements or functionality, a typical challenge in enterprise software projects.
Best Wishes,
Frank Spillers
What have been your experiences with usability testing early vs. late on? Please add your comment below...