We’ve reached the part of the four phases of navigation design testing where we’re looking at how we test something tangible.
Which is where we hit a small problem.
The problem with navigation design testing is the risk of the false positive or the false negative.
How do you test something that’s invisible?
I’ve talked about the need for navigation to be invisible.
Every single person who interacts with your digital product or service will come into contact with your navigation.
The navigation, however is not what they are there to experience, so it needs to become invisible.
If people are experiencing your navigation, you’re doing it wrong.
So how do you test something that needs to be invisible?
Quite simply, you can’t explicitly test it.
Make them find the thing you want to test
I’m going to caveat that someone I work with at the mo articulated this in a much better way than I was trying to.
To give you a bit of a back story (which I promise to write more about), I’m developing a navigation framework that product teams can use and iterate on.
I said, we can’t just create a navigation design system and test it alone. We won’t get the results we need from it.
My lovely boss said, “so instead of starting testing at the thing we want to test, we make them find the thing we want to test”.
And he nailed it.
Why this nails the brief
When you’re asking someone to find the thing you want to test you’re doing the following:
- Testing the labelling and structure (aka the taxonomy)
- Testing the navigation UI
- Testing the journey.
Consistency wins
The way you get to know if your navigation is awesome or it sucks is to carve out a consistent space for it in every single test.
Which is why the above works so well.
Here are the steps I’m working on as part of the navigation framework I’m building, or the NOW framework, as I’m calling it.
- Navigation - how well did they navigate to the thing you asked them to.
- Orientate - when they found the thing you asked them to find, how easy was it for them to orientate themselves to it?
- Wayfinding - how easy was it for them to work through the journey?
Don’t worry, I’ve got more content planed on the NOW framework.
The thing here to remember is by checking these three things a part of every test you do, you can compare and contrast.
If you only test the navigation, and only test it once, how do you build a realistic picture of navigation performance? spoiler alert, you can’t!
In person testing
Remote testing means you have a higher probability of getting people to take part in testing. Which is BRILLIANT.
However, when it comes to testing navigation, you’re going to need to get people to test your product or service on mobile devices.
I’m sorry, there’s really no getting away from it.
If you can legit see someone who does not speak “design” trying to work out where your menu is, because it’s behind a burger menu icon, you’ll understand why they need to go.
Give the person doing the testing a device they are familiar with using and watch them go.
Beware of search
I’m not gonna lie, you’re going to see a lot of people will just trigger the search box as their first interaction.
Don’t panic.
More and more people are relying on search to find things.
This can be a consequence of one of two scenarios.
The first, they just prefer to search. If this is the case, dive in and ask them why they prefer this - it helps you to define how your search should work.
The second, they have a problem with the navigation. When this happens, ask more to understand what the problem is.
Testing shows problems
If you’re testing hypothesis rather than trying to validate things, seeing problems shouldn’t be seen as something negative.
The point of testing is to find issues and fix them before you put something live.
If you’re only budgeting for one round of testing so you can say you’ve tested it you might as well not bother.
If you expect the unexpected you’ll see so much more.
Signs you’ve buggered up your testing
You’ve done some testing. YAY! and everything seems hunky dory, so you launch your product or service.
But once live weird crap is happening.
- You have a high bounce rate. When you investigate you find people are bouncing back and forth between Google and your site.
- Search is being used for things that are in the navigation.
- Your engagement rate tanks.
- More people are using navigation on your desktop vs mobile (or vice versa).
- High volume, low quality customer service requests
When you see stuff like this happening, you are most certainly likely to have a navigation problem.
If this is happening, read this post again and ask yourself if you’ve made testing something consistent or if you’ve cut corners.
The wrap-up
The best way to test navigation is to make it part of every test you do and don’t start the test from the thing you want to test.
Consistency is key!
