Testing is fantastic. Trust me, I can still remember a time when we designed things that were never put in front of the people who would use them until it was live.
The problem we seem to be having at the moment is that the desire to put something in front of people has become a tick box exercise.
If something has had eyes on it, it means you’ve done UCD.
Which is where the problem of validation comes into play.
The problem with validation
I hear far too frequently that “we’re going to validate it” or “once its validated”.
This is HUGELY problematic.
Validation is a done deal.
When you test something, you should be asking if the outcome is validated or disproven.
If you say you’re going to validate it, you’re assuming that it’s not going to fail.
Which, means you’ve just biased the whole process.
Testing should be an open ended question. One that we use to explore the success and failure of something.
If that all sounds blunt. It was meant to be.
Validation = bias.
The mess it’s created
We’re in such a rush to prove something works, we no longer accommodate failure.
Failure in design processes is good though.
Fail fast, fail often. Is what the Eric Ries says in The Lean Startup.
That’s what the design process is there for.
When we use testing methodologies like card sorting or tree testing to validate the labelling or structure it’s a shot in the foot.
The mess it’s creating is that it says you’ve ticked the testing box, but you haven’t learned about what the failures are.
The next time you plan on testing something, please just say you’re going to test it.
See where your mind goes with that.
Ask yourself, what are you going to learn?
See if you can spot where things fail and where they succeed.
With an open minded view of testing, you’re able to get a greater picture of how the different types of methodologies hook together.
Validation is not testing. Validation is one of two possible outcomes.