On a recent project, we built a bespoke platform with particularly complex requirements. Traditional scripted testing was carried out, and here's a good example of what that surfaced: a user logged a bug saying they couldn't reset their password. The functionality worked fine - the real issue was that the "reset your password" link wasn't the expected blue hyperlink colour, so the user had simply missed it. Scripted testing recorded this as passed, as the functionality worked, but intuitive testing identified it for what it actually was: a visibility problem.
Throw away the script: Why your testing needs "intuitive testing"
This year, Ellie is encouraging charities to throw away (some) test scripts
When charities launch a new digital system, there’s rarely much breathing room.
Teams are already stretched, and training time is limited. Everyone’s trying to keep services running while learning something new at the same time.
So when support tickets start flooding in after launch, it can feel frustrating and confusing for everyone involved.
“How did nobody spot this before we went live?”
Something we’ve noticed on projects is that traditional User Acceptance Testing (UAT) doesn’t always answer the question people think it does.
Often what's being tested isn't whether the system feels intuitive to real users - it's whether someone can successfully follow instructions.
Traditional (scripted) testing and intuitive testing each surface different things. Here's how they compare:
Scripted testing asks:
“Can someone complete the task?”
- Follow these steps
- Click this button
- Enter this specific information
- Confirm it worked
Intuitive testing asks:
“Can someone work out what to do?”
- What do they click first?
- Where do they hesitate?
- What feels unclear?
- What assumptions are they making?
The problem with scripted testing
Most UAT processes follow a similar structure. A tester receives a step-by-step script:
- Click here
- Enter this
- Open that
- Confirm this worked
The script gets completed, boxes get ticked and the project moves forward.
And to be clear, there’s nothing wrong with that approach. Structured testing is important, especially for governance, compliance and making sure agreed functionality works properly.
But real users do not experience systems through a test script.
The difference with intuitive testing
Intuitive testing is deliberately simple.
You give someone a goal, without giving them instructions, and observe what happens.
For example:
- “Can you make a donation?”
- “Can you reset your password?”
- “Can you update your details?”
Then you watch.
Where do they hesitate? What assumptions do they make? What do they completely miss?
The interesting part is usually not whether they eventually succeed. It’s how much friction they experience getting there.
What we found when we tested both approaches
On one recent project, I ran both traditional scripted testing and intuitive testing against the same system and the results were surprisingly different.
The scripted testing passed successfully. Users could complete the required actions when following the defined steps.
But intuitive testing surfaced completely different issues:
- Users skipped over a button that developers thought was clearly labelled
- Parts of the content didn’t make sense within the actual flow of the system
- Users were confused by elements of the system that we thought were easy to understand
None of these were technical failures but they were the kinds of issues that create confusion, frustration and additional support work once a system goes live.
In one case, a small wording change completely altered how confidently users moved through the process. That sort of thing rarely appears in a scripted UAT checklist.
A real life example
Why this matters for charities specifically
For charities, these issues often have a bigger operational impact than people expect.
- One confusing workflow can generate dozens of support emails.
- A login journey that feels obvious internally can become a daily frustration for frontline staff, volunteers, or supporters
- Unlike large commercial organisations, many charities don’t have spare capacity sitting behind a support desk ready to absorb that pressure.
That’s why intuitive testing is valuable. It catches the moments where real human behaviour collides with assumptions made during delivery.
How to introduce this internally
One of the reasons scripted UAT feels safer is because it’s easy to document.
You can clearly evidence:
- what was tested
- who tested it
- whether it passed
Intuitive testing can feel less structured by comparison.
But it doesn’t need to replace formal UAT.
The two approaches answer different questions, which is why they work well together.
A simple way to start
You do not need a huge testing programme to do this well.
A few practical principles go a long way:
- Use people unfamiliar with the system
- Give goals instead of instructions
- Observe hesitation and confusion carefully
- Pay attention to the language users naturally use
If someone repeatedly asks:
“How do I?”
That’s worth paying attention to.
Final thoughts
Software that technically works is only half the job.
If people struggle to understand how to use it, the cost usually appears later through support pressure, frustration, and reduced confidence in the system itself.
Intuitive testing helps surface those issues earlier, while there’s still time to fix them calmly. It's a great way to build confidence internally and with your external users too!
