Every new website, product, workshop, service, or exhibition faces the same challenge: the people who made it are too close to it to know if it works for anyone else. In a perfect world, we’d know before launch whether people actually wanted it, understood it, and could use it. Most of us find out the hard way. User testing is what closes that gap, and it doesn’t need to be expensive or complicated to be useful.
The closer you are to something you’ve created, the harder it is to see it as a stranger would. You know how it works, where everything is, what each step means. Your audience is starting from zero every time.
Research first
Before testing anything, it’s worth properly researching with your core user base to ensure that what you’re spending time on has real value. There are a range of research methods available, from interviews and surveys to observation and immersion, and both qualitative and quantitative approaches have a role to play. Quantitative analytics can tell you what a problem might be, but not why it’s occurring. You might notice from your website analytics that sales of a certain product have suddenly dropped off, but it’s going to be very difficult to undstand why that’s happened without delving into some qualitative research and actually talking to people. Understanding the why is what makes the difference between guessing at a fix and actually solving the right problem. That foundation matters before you test anything.
A good example of what happens when that research is missing: hospital CT scanners were designed by people who understood the technology intimately but had never observed a child experiencing one. The noise, the enclosed space, the cold clinical environment. When designers finally did that observational research, the problem became obvious. The GE Healthcare Adventure Series reframed the same machines as pirate ships and space expeditions, and children went from terrified to excited. Nothing technical about the scanner changed. What changed was everything around it: the room, the surfaces, the equipment, and the way operators spoke to patients. The research just revealed who was actually using it and what that experience felt like for them.
For smaller projects, a full set of personas can often be more overhead than it’s worth. What matters more is being clear on the goals, motivations, and frustrations of the people you’re creating for. Who are they, what do they need, and what’s currently stopping them from getting it?
Prototyping: test before you create
Once you have research insights, resist the urge to go straight into creating. Testing whether what you’re imagining actually works is far cheaper than fixing it after the fact, and this applies whether you’re designing a website, a physical product, a workshop, a retail experience, a service flow, or almost anything else.
People are also far more likely to tell you something isn’t working when it’s clearly rough. Show someone a polished, finished thing and they’ll hesitate to criticise it. Show them a sketch and they’ll tell you exactly what’s wrong.
A low-fidelity prototype can be as simple as a sketch on the back of an envelope, a cardboard mock-up, or a one-page outline. For a website, that might be a wireframe, which is a basic skeletal layout showing structure and flow before any design decisions are made.
When we’re developing a new Meeum workshop, we test the outline and basic content ideas with a small group from the target audience before spending weeks writing and finalising the full series. That early conversation regularly changes the shape of what gets built, and it costs nothing but time.
This kind of early testing also reveals assumptions you didn’t know you were making. A workflow that seems obvious from the inside can be completely opaque to someone experiencing it for the first time. The gap between “we assumed people would do X” and “they actually did Y” is exactly where the most useful learning lives, and a rough sketch or outline surfaces it far more cheaply than a finished product does.
From a rough sketch you might move to something slightly more constructed: an architect’s sketch, a printed mock-up, a physical model, a pilot session with a small group, or a simple clickable prototype built in Figma for anything digital. These mid-fidelity prototypes let you test more specific questions. Can people follow the flow? Does the sequence make sense? Are the right things getting attention?
Higher-fidelity prototypes look and feel closer to the finished thing. A near-final workshop run with a test group. A physical product tested in context. A service walkthrough with a real participant. At this level you’re testing finer details: whether the pacing works, whether instructions land, whether the experience delivers what you intended. Test before you create, not after. The earlier you put something in front of real people, the cheaper and easier it is to change.
Running a budget user test
There are a handful of practical methods that cost very little and consistently produce useful results. The right combination depends on what you’re testing, but most of the methods below can be adapted to almost any context.
Recruit from your network
Start with people who fit your target audience and are already in your network: past customers, participants, audience members, followers, friends of friends. Offer a small thank you, a coffee, a gift card, a discount on your services. Five to eight participants is enough for a single round. Avoid anyone already too familiar with what you’re testing. Someone who helped create it is not a useful test participant.
Give tasks, not instructions
Give participants realistic tasks rather than guided instructions. Rather than walking them through how something works, give them a goal and watch how they pursue it. For a workshop, that might mean handing someone the agenda and asking what they’d expect to get out of it. For a product, it might mean asking them to figure out how to use it without guidance. For a service or retail experience, let them move through it as a real customer would. Then watch. Don’t explain. Take notes.
Use the think-aloud method
Ask participants to narrate their thoughts as they go. For a physical product or space: “I’d expect this to open here… I’m not sure what this part does… I’d probably ask someone at this point.” For a service or workshop: “I’m not sure what’s expected of me here… this part felt rushed… I didn’t know this was coming.”
This matters because people’s stated reasons for their behaviour and their actual behaviour are frequently different things. Someone might tell you they’d read the instructions carefully. Watch them, and they won’t. The think-aloud method captures what’s really happening in the moment. Capturing these observations in a notebook works well, or if you’re testing something on a screen, Loom records screen and audio simultaneously and the free plan covers most needs.
Don’t overlook your edges or your complaints
The most useful insights often come from the extremes of your audience: the first-timer who reveals friction your regulars have long adapted to, and the deeply experienced participant who surfaces limitations others never push far enough to find. Fixes from edge-case testing almost always improve the experience for everyone in between.
One-star reviews, complaint emails, and frustrated feedback are also research data. People who are dissatisfied tend to be precise about why. Patterns in that feedback are hypotheses waiting to be tested.
For digital products: testing tools
Microsoft Clarity is completely free and offers session recordings and heatmaps with no participant limit. Hotjar has a free plan with similar capabilities and is equally accessible for anyone new to behavioural data.
Lyssna (formerly UsabilityHub) has a free plan for first-click tests, five-second tests, and prototype tests with your own recruited participants, useful for testing designs and wireframes before they’re built. Maze integrates directly with Figma for unmoderated prototype testing and works best for teams already running a Figma-based design process.
Keep sessions short
Thirty to forty-five minutes per participant is enough. After a few sessions, patterns emerge: people stumble at the same point, miss the same element, or misinterpret the same instruction. Prioritise findings by frequency and impact. The moments that surprised you are usually where your assumptions turned out to be wrong.
What this looks like in practice
When rebuilding Arts Law’s website, a user experience-first approach grounded in understanding how users actually navigated the site produced a 97% increase in engagement on the Contract Templates page, a 358% increase in Information Sheets engagement, and an 87% drop in cart bounce rates.
When Regional Arts WA needed a new public-facing digital home, the process started with understanding users, what they needed to find, how they navigated, and what barriers existed, before any design decisions were made. The same principle shaped the Regional Arts Network intranet: we spoke with every member organisation around their requirements and workflows, and a working prototype was presented to the full membership before anything was built. What members flagged in those workshops directly shaped the final product. Features were refined, others scaled back, and the prototype became the foundation for the full build.
When doing research for a prominent Australian arts organisation, we interviewed and ran workshops with teachers who had used the organisation’s digital learning platform as well as teachers who hadn’t. The gap between what the organisation assumed teachers wanted and what the research actually revealed was stark enough to reshape the entire strategic direction of the program. Neither group of teachers had been asked before. The assumptions had simply accumulated, untested, over years.
On a separate project with young participants at a children’s arts organisation, attitudes toward digital engagement for kids were equally unexpected.
In both cases, the research and testing didn’t confirm what the organisations expected to find, and that’s exactly why it was so useful.
Getting started this week
Pick one question you’d like to answer about something you’re working on. Find five people who match your target audience and ask each of them to spend twenty minutes with it while you observe. Take notes. Look for patterns. Make one or two changes based on what you learn. Then do it again.
Many of the most useful improvements that come out of testing are small. Clearer navigation, better contrast, stronger calls to action on a website. Better sequencing, clearer instructions, a more considered entry point for a workshop or service.
Test, learn, improve. Repeat.
Now a digital veteran, Sam Hemphill initially trained as a drummer and high school teacher and spent 10 years as a touring musician and tour manager.
During that time, he ...