Prototype testing has always been one of the most common and reliable ways of validating designs through real-world users before starting off with the development stage.<\/p>\n\n\n\n
Developers work relentlessly on creating new and better products and brushing off any prototyping mistakes in the initial stages of development. <\/p>\n\n\n\n
But before the designs become a reality, a lot of feedback is needed from the users to ensure that no imperfections seep into the design.<\/p>\n\n\n\n
There’s real flexibility in how you approach prototype testing, and every designer brings their own style and standards to it. <\/p>\n\n\n\n
That said, flexibility isn’t the same as anything goes. Poor task design, biased moderation, sloppy recruiting, or unclear objectives can quietly compromise your findings, no matter how fluid or rigid your overall approach is. <\/p>\n\n\n\n
The nine mistakes below are the parts worth getting right regardless of your personal testing style.<\/p>\n\n\n\n
Every designer approaches the development in a different way and has their own set of standards and expectations for the final mock-up of the prototypes. They can be as fluid and explorative or as rigid as the designer wants.\u00a0\u00a0<\/p>\n\n\n\n
It\u2019s surely important how you test prototype, but more importantly, how you validate your designs, fix existing mistakes and perfect them round after round. <\/p>\n\n\n\n
A prototype may be a little rough around the edges, but your final product should always deliver on the expectation and drop any liabilities. <\/p>\n\n\n\n
To help you with this, we have carefully compiled a list of 9 mistakes in prototype testing and how to avoid them. <\/p>\n\n\n\n
Let\u2019s begin with the most basic one that could derail things right at the beginning.<\/p>\n\n\n\n
If there\u2019s nothing else that you take away from this article, be sure to avoid this #1 prototyping mistake. Testing without goals is like embarking on a treasure hunt without a map. <\/p>\n\n\n\n
What are you working towards? <\/p>\n\n\n\n
How can you make sure you get to that golden pot of user insights?<\/p>\n\n\n\n
Setting goals will give your user tests a purpose instead of just being a standard procedure. Without intentional goals, you may be ticking off the testing box on your to-do list, but you won\u2019t be able to tell if what you\u2019re doing has any value or solves user needs. <\/p>\n\n\n\n
What to do instead: Decide what your goal\/research question is <\/strong><\/p>\n\n\n\n We\u2019re fans of the reliable SMART goals framework<\/a>. SMART goals are Specific,<\/strong> Measurable<\/strong>, Achievable<\/strong>, Relevant,<\/strong> and Time-sensitive.<\/strong><\/p>\n\n\n\n Let\u2019s walk through a more concrete example of what this can look like with prototype testing by looking at a possible goal.<\/p>\n\n\n\n Goal: I want to uncover whether or not users can find the feature that they are looking for within the prototype. <\/em><\/strong><\/p>\n\n\n\n You are specifically<\/strong> trying to understand the usability and navigation of your SaaS tool.<\/p>\n\n\n\n It\u2019s measurable<\/strong> because, in the end, the user either did or didn\u2019t find it. <\/p>\n\n\n\n The goal is achievable<\/strong> because it has clear and realistic outcomes. <\/p>\n\n\n\n You aren\u2019t saying \u2013 I want every user to be able to find the feature. <\/em>That would be setting yourself up for failure. Instead, you\u2019re trying to learn what\u2019s working and where you can improve the user experience. <\/p>\n\n\n\n Is it relevant<\/strong>? Well, if you just finished redesigning your flow, then yes, this goal is totally relevant. <\/p>\n\n\n\n But let\u2019s say you just redesigned the landing page\u2026product navigation might be a secondary goal to concept validation and figuring out whether or not the landing page is easy for visitors to quickly understand what your company does.<\/p>\n\n\n\n Make sure you have enough time<\/strong> to do user testing on this question. <\/p>\n\n\n\n This way goal setting can help you avoid a number of prototyping mistakes.<\/p>\n\n\n\n As a general rule of thumb, testing prototypes<\/a> at a lower fidelity stage is a smart move. Your mockups don\u2019t need to be perfect in order for you to understand how users will react to the product. <\/p>\n\n\n\n However, there\u2019s a balance to strike. You don\u2019t want something that\u2019s so lo-fi it doesn\u2019t resemble the final product closely enough. If it\u2019s too hi-fi, you may be wasting time on perfecting one version instead of getting feedback as soon as possible. <\/p>\n\n\n\n If it looks too polished, they might be more concerned about how direct their feedback can be if it appears someone has spent a lot of time on it. <\/p>\n\n\n\n Put together a few rough versions at the same fidelity, not too low and not too high. Having only one prototype might make people less likely to give you more open and critical feedback that you need to actually push the product forward. <\/p>\n\n\n\n Having a few versions can allow you to see which version best helps users to achieve their goals. If you don\u2019t have time to let users test different versions, consider doing a side-by-side comparison of the different options you\u2019re exploring to see which they find most intuitive. <\/p>\n\n\n\n If users don\u2019t have clear instructions that they can review before the test, they might feel lost before they\u2019ve even begun interacting with your product. <\/p>\n\n\n\n Instructions should include context on the prototype. Outline any upfront limitations that they might experience with this current iteration so that hiccups in the prototype feel expected and not distracting. <\/p>\n\n\n\n Most importantly, though, your instructions should include a list of tasks that you want users to perform during testing. <\/p>\n\n\n\n Writing instructions doesn\u2019t have to be some kind of long and tedious task. In fact, the shorter and more straightforward your instructions are, the better. <\/p>\n\n\n\n In Steve Krug\u2019s book Don\u2019t Make Me Think<\/em><\/a>, one of the guiding principles is to \u201comit needless words\u201d. He actually uses instructions as an example for when to do so. \u201cWhen instructions are absolutely necessary, cut them back to the bare minimum.\u201d <\/p>\n\n\n\n Since you need some signposting and guidelines for user testing, this is a case where they are absolutely necessary but don\u2019t have to drag on. <\/p>\n\n\n\n All you need to say is something like: <\/p>\n\n\n\n Again, if need be, mention any details here about the prototype\u2019s fidelity that the user should be aware of. <\/p>\n\n\n\n As someone who interacts with the product on a daily basis, you\u2019re probably used to all the acronyms and jargon and unique features that come with your product. <\/p>\n\n\n\n However, your users are not. <\/p>\n\n\n\n Assigning bad tasks that ask users to try out specific features is like asking someone to taste ingredients from a recipe instead of making an actual meal. <\/p>\n\n\n\n When straightforward tasks are provided that tell a user exactly what to do, you aren\u2019t going to capture what it would be like for your user to interact with the product in their own day-to-day life. And what you really want is for the testing to feel as seamless and organic as possible. <\/p>\n\n\n\n Similarly, avoid guiding your testers through specific user journeys or site flows that you have in mind. Sending your users down one journey might result in confirmation bias where the assumptions you\u2019ve made about user flow can\u2019t actually be challenged.<\/p>\n\n\n\n Again, users are motivated by actual goals. You should be too. No matter what your company does, you have to step outside of the research box and imagine real-world scenarios where a user or customer will actually be looking for a product like yours. <\/p>\n\n\n\n For example, in our work with Belron (read case study<\/a> here), Customer Journey Improvement Manager Stephen Payne explained what he calls grudge purchases. Belron sells windshields under the U.S. brand Safelite. <\/p>\n\n\n\n Payne shared that most people don\u2019t necessarily wake up thinking about a new windshield. You make grudge purchases only \u201cif you have damage and need it fixed immediately.\u201d So let\u2019s adapt this for the context of prototype testing. <\/p>\n\n\n\n Poor task: <\/strong><\/p>\n\n\n\n Find information about our glass recycling program.<\/p>\n\n\n\n Their information on glass recycling is interesting and differentiates them as industry leaders, but not realistic to what a potential site visitor would do when first arriving on the site.<\/p>\n\n\n\n Okay task:<\/strong><\/p>\n\n\n\n Book an appointment to have your windshield replaced. <\/p>\n\n\n\n Telling users just to book an appointment is giving them too many clues and not allowing users to have a bit of roaming room. <\/p>\n\n\n\n Best way: Task scenario<\/strong><\/p>\n\n\n\n While you were driving to work this morning, you drove by a golf course <\/p>\n\n\n\n and a stray ball flew at your window, leaving a big crack. <\/p>\n\n\n\n Find a way to get your windshield replaced. <\/p>\n\n\n\n This scenario feels realistic and actually might include more than one task. <\/p>\n\n\n\n Testers might read about other services offered, explore locations near them or even read reviews before scheduling the end appointment. In this way, scenarios allow you to learn more <\/a>than simple tasks would, and creating the right ones can help you avoid many prototyping mistakes.<\/p>\n\n\n\n One related note:<\/strong> if you prepare a moderator guide that maps the expected flow through the prototype, keep it for your own reference during the session. It’s a tool for noticing when a tester goes off the expected path, not a script to walk them through it. Sharing that path with users directly would undercut the realistic, unguided scenario you just built.<\/p>\n\n\n\n This all goes back to goal setting and tasks.<\/p>\n\n\n\n Let\u2019s go back to the treasure hunt comparison for prototype testing. If having a map is like having a goal and user insights are the treasure chest, then questions are your directions. <\/p>\n\n\n\n Asking the right questions can guide you to the right information and user feedback that will be most constructive towards making better design decisions. <\/p>\n\n\n\n The solution here is simple: ask yourself if the questions you\u2019re asking will give you more insight into your end research goal or if they can tell you more about how users were able to complete tasks. <\/p>\n\n\n\n Okay, we know we just got on a soapbox about how questions are basically the rainbow that leads you to a pot of gold. But all good things in moderation, right?<\/p>\n\n\n\n If you ask too many questions, you run the risk of annoying your users and causing survey fatigue and this is one of the most common prototyping mistakes committed by many.<\/p>\n\n\n\n Annoying your users can negatively bias their feedback against your mockup. Meanwhile, survey fatigue or tiredness that comes with answering too many survey questions will result in lower quality data towards the end of testing. <\/p>\n\n\n\n Try 1-2 follow-up questions after each task with 3 questions at the end of the test. If you\u2019re looking for concrete examples of what you can ask, review Step 4 of our guide to testing prototypes here<\/a>. <\/p>\n\n\n\n If you come up with a list of questions and find yourself with too many, just ask yourself if the question will provide you with an answer that serves your ultimate research question and goal. If it doesn\u2019t, eliminate it. <\/p>\n\n\n\n Another major prototyping mistake is made while choosing who to research with. <\/p>\n\n\n\n One of the most common reasons people skip over user research during the early phase is that they feel they need to gain insights only from their target persona. <\/p>\n\n\n\n On the other end of the spectrum, some teams feel that they need to test a statistically significant number of users for their results to count. <\/p>\n\n\n\n Whether you\u2019re going too narrow or aiming for too large a group of testers, you\u2019re missing one of the key points of user testing. Get your product in the hands of real people for an outside perspective. <\/p>\n\n\n\n UX thought leader and author Steve Krug writes<\/a> that conducting user research with just about anybody can be very useful. As he puts it, we should all \u201crecruit loosely and grade on a curve\u201d when it comes to choosing user research participants. <\/p>\n\n\n\n Krug\u2019s point is that you can identify usability issues with pretty much any<\/em> user research testers, not just those who may fit the profile of your ideal customer to a T.<\/p>\n\n\n\n Unless your tool is intended for such a niche group that only a very specific subset of people can use or understand it, you really don\u2019t need to obsess over recruiting only folks who fit neatly into your target audience.<\/p>\n\n\n\n On that note, don\u2019t fret too much over having a large number of user research participants either because you can still get very valuable insights from just a few participants. <\/p>\n\n\n\n Also, qualitative user research doesn\u2019t confine you due to the need for a representative sample. In fact, if you\u2019re interested in user testing, Jakob Nielsen<\/a> argues<\/a> that \u201cthe best results come from testing no more than 5 users and running as many small tests as you can afford.\u201d\u00a0<\/p>\n\n\n\n Worth noting this guidance applies to qualitative usability testing aimed at finding problems, not to research where you need statistically reliable numbers, like comparing conversion rates between two design variants. <\/p>\n\n\n\n For that kind of quantitative comparison, five users won’t give you a reliable answer, and you’d want a larger sample or an A\/B test instead.<\/p>\n\n\n\n When the statistical barriers that come with quantitative research are removed, you can conduct user research more frequently and also stretch your research budget further.<\/p>\n\n\n\n Whether your test is moderated, unmoderated, remote, or in-person, you need to have the tools that will help you collect feedback ready to go on the day of testing. Without a system for gathering feedback, the valuable time you just spent on testing sessions will go wasted. <\/p>\n\n\n\n If your feedback is disorganized, it will take longer to sort. If it\u2019s not accurately captured and instead relies on the moderator\u2019s memory in some way, it will be prone to so many errors as to become unusable. <\/p>\n\n\n\n The way you collect feedback will mostly depend on the type of prototype you\u2019re using. <\/p>\n\n\n\n If you\u2019re testing with paper prototypes, then a paper survey might be the best route. Remember that paper surveys will require extra time later for manual data entry and response coding.<\/p>\n\n\n\n If you\u2019re testing with digital prototypes, you may consider a usability testing tool like lookback.io<\/strong> <\/a>or in-app testing tools like Qualaroo<\/strong><\/a>, which let you collect responses right within mockups<\/strong><\/a> to help you avoid making prototyping mistakes.<\/p>\n\n\n\n There are several prototyping mistakes that you need to avoid making on the day the testing takes place. Here are some of the most common ones:<\/p>\n\n\n\n If you plan to collect any type of personal information and use testers\u2019 responses or record sessions for further analysis, you should be getting written and signed consent first. If there\u2019s any possibility that your testers are located in the EU, you\u2019ll have to be mindful of GDPR<\/a>. In California, there\u2019s the CCPA<\/a> to take note of. <\/p>\n\n\n\n The language you use to describe your prototype needs to be neutral when you\u2019re describing it. But if we\u2019re being honest, you probably shouldn\u2019t be describing it at all. It\u2019s the old show-don\u2019t tell rule. Let them discover the product themselves rather than tell them about every feature. <\/p>\n\n\n\n Additionally, if you\u2019re a designer and you\u2019re participating in the research process, don\u2019t let users know that you made the prototype, even if you did. The goal is to eliminate as much room as possible for bias, especially since you may be testing with a smaller size of respondents.<\/p>\n\n\n\n Collecting feedback well, per Mistake #8, only pays off if what happens next is just as structured. A few steps worth building into your process:<\/p>\n\n\n\n Code your observations.<\/strong> Go through your notes and recordings and tag each observation with a short label, “couldn’t find X,” “misread the icon for Y,” “expected a confirmation step.” This turns a pile of session notes into something you can actually count and compare.<\/p>\n\n\n\n Group into themes.<\/strong> Once coded, cluster similar observations together. If three out of five testers struggled with the same step, that’s a theme worth acting on. A single tester’s one-off comment is worth noting but shouldn’t carry the same weight.<\/p>\n\n\n\n Separate usability issues from preferences.<\/strong> “I couldn’t complete the task” is a usability issue. “I’d prefer a different color” is a preference. Both are useful, but they call for different responses, a preference is a data point to weigh, a usability issue is often something to fix before launch regardless of how few testers hit it, especially if it blocks task completion.<\/p>\n\n\n\n Assign severity.<\/strong> Not every finding deserves the same urgency. A quick framework: does this issue block the task entirely, slow it down significantly, or just create minor friction or confusion? Prioritize fixes in that order, weighted by how many testers hit each one and how central that flow is to your product.<\/p>\n\n\n\n Skipping this step is how teams end up with a stack of session recordings and sticky notes that never turns into an actual design decision.<\/p>\n\n\n\n Mistake #1 touched on measuring whether a user found a feature or not, but a binary success\/failure read leaves useful detail on the table. A few additional metrics worth capturing during testing:<\/p>\n\n\n\n You don’t need all of these for every test. For a quick five-user round, task success plus an SEQ rating after each task is often enough. Save the fuller metric set for higher-stakes rounds where you’re comparing multiple design directions.<\/p>\n\n\n\n If you\u2019ve been with us to this point, you\u2019d be very well aware of what prototype testing is and what are the most common prototype testing mistakes that you would come across while doing so. <\/p>\n\n\n\n Now, let\u2019s quickly go through some of the tips that you can easily implement to avoid mistakes during prototyping.<\/p>\n\n\n\n Prototype testing is all about freedom: freedom to be creative, make prototyping mistakes and eventually create something amazing. <\/p>\n\n\n\n There are plenty of pitfalls throughout the prototype testing process, but most of them are avoidable once you’re deliberate about goals, tasks, recruiting, and consent going in, and just as deliberate about coding, theming, and prioritizing what you find once testing wraps.<\/p>\n\n\n\n Thankfully, we are fortunate enough to have plenty of tools like Qualaroo<\/strong><\/a> to help us avoid such prototyping mistakes altogether and create promising designs by leveraging contextual feedback. <\/p>\n\n\n\n<\/span>Mistake #2: Testing a Prototype That\u2019s Unfinished or Too Polished<\/span><\/h2>\n\n\n\n
What to do instead: Test a few versions at the right fidelity<\/h4>\n\n\n\n
<\/span>Mistake #3: Being Underprepared<\/span><\/h2>\n\n\n\n
What to do instead: Provide simple instructions.<\/h4>\n\n\n\n
<\/span>Mistake #4: Assigning Bad Tasks <\/span><\/h2>\n\n\n\n
What to do instead: Create task scenarios <\/h4>\n\n\n\n
<\/span>Mistake #5: Asking the Wrong Questions<\/span><\/h2>\n\n\n\n
What to do instead: Write questions that will give you results. <\/h4>\n\n\n\n
<\/span>Mistake #6: Asking Too Many Questions <\/span><\/h2>\n\n\n\n
What to do instead: Choose your questions carefully <\/h4>\n\n\n\n
<\/span> Mistake #7: Recruiting Too Strictly! <\/span><\/h2>\n\n\n\n
What to do instead: \u2018Recruit Loosely and Grade on a Curve\u2019 <\/h4>\n\n\n\n
<\/span>Mistake #8: Not Having a System to Collect Feedback<\/span><\/h2>\n\n\n\n
What to do instead: Pick the method that works for you. <\/h4>\n\n\n\n
<\/span>Mistake #9: Forgetting Best Practices on the Day of Testing<\/span><\/h2>\n\n\n\n
Testing without consent to collect information<\/h4>\n\n\n\n
Not using neutral language with participants <\/h4>\n\n\n\n
<\/span>What to Do With Your Findings After Testing Wraps<\/span><\/h2>\n\n\n\n
Metrics Worth Tracking Beyond Simple Task Success<\/h3>\n\n\n\n
<\/span>Quick Tips to Avoid Prototyping Mistakes<\/span><\/h2>\n\n\n\n
<\/span>Test Prototypes With Confidence<\/span><\/h2>\n\n\n\n