Usability Testing with Wireframes

One of the most important benefits of creating prototypes is that they allow you to gather feedback quickly on the earliest incarnations of your ideas. While there is a benefit to taking some time to let your creative juices come to a full simmer, when you’re beholden to a deadline, a client, or an audience – you can’t in good conscience delay the point of feedback longer than is absolutely necessary.


Usability testing with wireframes is an especially quick, convenient and effective way of getting early-stage feedback from people outside of your development and design  team – if you approach it with a two simple guidelines in mind:

  • Choose participants who are not privy to your internal discussions; ideally these will be people completely outside your company or organization, but you can suffice with people who simply don’t have any “inside information” about the project you’re working on.
  • Focus on asking questions that are relevant to the fidelity of the wireframe you’re testing (more on this below). Focus on suitability first (are you including the right kinds of features and content), and usability later.


What’s the earliest point at which you can solicit audience feedback on a wireframe or prototype and still expect to learn something useful? Let’s take a fictional client, ExoSweaters, a new startup in the red-hot insect apparel category.


Before getting too deep into the development of their website, I put together this simple wireframe which, though minimal, can still elicit useful feedback:



That’s not a placeholder. That’s an actual wireframe, executed in text, and containing enough information to elicit interesting feedback from customers if you ask the right questions, in the right way.


Therein lies the rub: the fidelity of your wireframes has to be matched with the right depth and style of question. With something this low-fi, you need to ask open-ended questions that allow people to talk about their needs, their expectations, their hopes, and their beliefs. You’re not going to get a lot of useful quantitative usability data back with a wireframe like this, but you can get a wealth of interesting, useful and even surprising feedback. Ask questions like:

  • what kind of information about our products is missing here?
  • how many kinds of products does it seem like we offer?
  • if you were describing THIS product to a friend, what would you say?
  • what information would you need to see in order to determine whether our product would be appropriate for your pet insect?
  • if you were on our competitors’ sites, what would you see about their products that’s missing from here?
  • if you had a question about a product, would you be able to figure out the answer?


These questions will allow your audience to talk openly about how well the concept of your design maps to their expectations. You’ll learn whether or not your site is speaking to the right needs, accommodating the right kinds of information, and scoped to include the right depth of functionality. You’ll hear whether or not your competitors are doing a better job of speaking to those needs, or have solved a design problem that you are working on. Don’t think you have to solve every design or experience challenge in a vacuum! Figure out what already works, and pinpoint where your competition is failing (and giving you a chance to gain an edge.)


As it turns out, our first group of pet insect owners needed a piece of information we hadn’t thought of yet: reviews from other owners.


Here are some questions that you definitely don’t want to ask:

  • where would you click to add this product to your cart?
  • how would you log into this site?
  • where would you go to get back to a list of all of our products?


While these questions technically have “correct” answers embedded within that low-fi wireframe, finding out if your audience can get those answers correct won’t give you any useful, actionable data. The wireframe isn’t intended to represent a model of how the system might be used, but rather a concept of what purpose(s) that system might serve. To begin to get answers to those questions, you’d need a wireframe that looked a bit more like this:




As wireframes go, this one is still pretty basic. A bare minimum of color, but enough organization and layout to elicit some feedback about usability. A wireframe like this lends itself to tasks like:

  • Can you purchase a sweater for less than $88?
  • Which sweater seems to be the most popular?
  • How would you find other styles of sweaters for crickets?


Though it took less than 10 minutes to create, this more detailed wireframe allows you to use evaluative testing to determine if your design approach, information prioritization, and content hierarchy are matching to your audience’s expectations. But if you wait until you’re even this far into the process before you begin testing, you’ll have missed an a vital opportunity to determine if the very concept you’re developing is filling an identifiable need.


The advantage of planning on testing with low-fi wireframes is that it conditions your team early on to listen to customer feedback. The longer you wait to get that feedback, the more invested you may become in a concept of what your digital experience or website should be. It’s very easy to build a “sacred idea” that’s immune to criticism. Don’t fall into that trap! As I often tell my clients: you *will always* test your ideas, whether you want to or not; either you’ll test them early on when feedback can help you course-correct with minimal cost, or you’ll test at launch – when negative feedback will be fatal.



  • no wireframe is too low-fi to test.
  • focus on questions that are scoped inversely to the fidelity of those wireframes: low-fi, open-ended; high-fi, closed tasks.
  • test early, often, and with an open mind. All feedback is data, but you can’t know if it’s reliable without having multiple samples to compare.



Next Up: Two ridiculously simple and cheap ways to test with 10 users on a moment’s notice.


Ben Levin

Ben Levin is a UX writer and content strategist at HotGloo. He’s    been building and leading UX and Design teams for the last 15 years – including 2 long stints at interactive agencies.
You can find Ben on Twitter.

Author: Ben Levin

Ben is building and leading UX and Design teams for the last 15 years. Over the last 3 years he's been doing hands-on UX, user research, and collaborative design work with a great team at a large bank in Virgina, both in person and remote.