Most product failures don't die in a lab. They die in the gap between what teams believe and what users actually do. That's why usability testing matters: it is the practice of watching real people try to use your product, so you can see where they get stuck before the costly mistakes are baked in. For a primer, see Jakob Nielsen's introduction to usability at NN/g.
Almost seven years ago, we brought Usability Testessen to Berlin. A group of volunteers simply did it back then – without any intention of making a profit and without knowing whether it would work in Berlin. Since then, we have successfully brought together creators of exciting products (from websites and apps to new toothpaste) with people who want pizza and cold drinks (or just want to see cool new things).
Just like us back then, people with exciting projects of all sizes come to the free events every time to find out whether their hypotheses work – or not.
Interestingly, however, I have the feeling that the dynamic of 'just doing it' is no longer so self-evident today. People ask us what we get out of organising this in our free time. With tight budgets, creators don't dare to let real users try out their products – for fear of finding out that their idea doesn't work (which leads to much more expensive failures). Product ideas are filtered for a viable business model right from the start (which is totally justified in the long run, but can nip innovation in the bud too early).
After the last Usability Testessen event, one participant wrote to us afterwards that he had received 'brutally honest feedback' – but also that it was 'painful but necessary' in order to further develop his product. Great.
I am in favour of simply trying out more ideas again. Of doing more things again because we simply feel like it. Theoretical foundations, experience and security are important – but to really get ahead, speed and passion sometimes beat security. And when in doubt, getting early feedback can minimise the fall or help steer the product in the right direction, so what do we have to lose?
Let's get back to 'doing' more. Both at work and in our private lives. I believe that the innovation landscape and the meetup scene can benefit from this.
What would you like to try if you weren't afraid of failure?
Read next:
- Stop Wasting Money on Unused Digital Products — why early testing and a clear purpose are the antidote to dead apps
- The Accessibility Strengthening Act is live — what the BFSG means for digital products in Europe
- Diversity of Perspective Drives Better Design — why moving across domains beats specialising in one
FAQ
What is usability testing?
Usability testing is a user research method in which real people try to use a product, website, or app while observers watch, listen, and take notes. The goal is to identify where users get stuck, hesitate, misunderstand, or give up, so the team can fix those problems before launch. It works best with small samples (often five participants is enough to surface the majority of usability issues) and is most valuable when done early, on prototypes rather than only on finished products.
How is usability testing different from user research or market research?
User research is the broad umbrella covering every method for understanding people: interviews, surveys, field studies, diary studies, and more. Market research focuses on the audience, demand, pricing, and competitive positioning. Usability testing sits inside user research but has a narrower job: it evaluates a specific product with specific users, measuring whether the thing you built actually works for them. If you want to know "should we build this?", user and market research come first. If you want to know "does this work once we have built it?", that is usability testing.
Why does usability testing matter for small teams and indie makers?
Small teams and indie makers cannot afford to ship something nobody can figure out. The cost of fixing a usability problem after launch is usually ten to a hundred times higher than fixing it during design. A single round of usability testing on a rough prototype can surface the most painful friction points in an afternoon, which is exactly the kind of input a one-person team can act on. That is why grassroots formats like Usability Testessen work: they lower the cost to almost zero by pairing curious volunteers with makers who just need to watch someone use what they built.
How many users do you need for a usability test?
For most product teams, five users per user group is enough to surface roughly 85 percent of usability problems, according to research by Jakob Nielsen that has held up for decades. You do not test more users to find more problems in the same design, you run another round after fixing what you found, then test again. The mistake is treating usability testing as a one-off event with a large sample. Treat it as a tight feedback loop: small rounds, fast fixes, repeat.
When in the product process should you start usability testing?
As early as you have something a person can react to, even a paper sketch, a clickable wireframe, or a no-code facade. The earlier you test, the cheaper the changes. Teams that wait for a finished product before showing it to anyone are paying for the privilege of discovering obvious problems very late. Aim to run a usability test before any major design or build decision is locked in, and again after each meaningful change.