If you stick your finger in an electric socket and get a shock, the problem is you’re an idiot and you forgot to turn off the mains power.
Design is no different.
Imagine designing a product just because you wanted to. You might laugh, but I can guarantee you’ve used a product or service that was not designed around a problem that humans experience.
So your mantra, if it wasn’t already, should now be “what is the problem we’re trying to solve?”
Understanding the navigation design problem
Understanding a design problem is one thing, but understanding that it’s specifically a navigation design problem is something completely different.
Navigation design problems can be a bit wooly or hard to define.
They’re also better solved incrementally, and with live interaction data. But for the purposes of this we’ll assume the navigation design problems are significant ones.
There is also a difference between knowing you have a problem and knowing what it is.
How do you know you’ve got a problem?
There are a few key places that will give you a red flag there’s a problem.
Some of the most common are:
- Analytics, for example Google analytics or Adobe Analytics
- Search traffic data, this can be internal search analytics if you have a platform that supports it, or SEO data
- Screen capture sessions, for example Hot Jar or CrazyEgg
- Usability testing sessions or qualitative interviews
- Volume and type of contact requests
- Net Promoter Score (NPS)
Problems identified in analytics
These are some common issues I’ve identified in analytics that directly indicate a problem with navigation.
- People arrive on your site from Google, stay for one page, go back to Google and come back again, aka using Google as your navigation method
- Your bounce rate is high despite having navigation
- People are dropping out of a well defined flow
- You get a lot of customer service requests despite having the info on the website
Search traffic data indicating a problem
I’m going to talk about onsite search rather than SEO indicating a problem (as the first bullet point in the last section covers the biggest red flag).
Your onsite search data might show the following (if you can get the data from it)
- Searches for primary or secondary navigation labels
- People are using search by default (unless your site is centred around search)
- Attempts to use search to find things in page
Screen capture
If you’re using a platform like Crazyegg or Hotjar you can see immediately what interaction looks like.
The problems with navigation will show as:
- Hesitancy
- Scrolling up and down a page rapidly and repeatedly
- Scrolling to the top of a page then immediately to the bottom to use navigation
Usability testing or qualitative interviews
These are considered the gold standard of research as it’s likely to show a problem immediately and you can dive in and ask what the person is struggling with.
However, be warned. With the rise of people using mobile devices be sure the person you’re testing with has familiarity withe device you’re testing with.
For example:
If your main device type is a desktop, you should test on a desktop environment. However, if the participant mainly uses a mobile or doesn’t own a desktop they will struggle with navigation.
This doesn’t mean there’s a problem with your navigation, it’s a problem with your recruitment brief.
Contact requests
If you get a high proportion of contact requests, whether they’re help or customer support you could have a problem.
Ideally any human interaction that you have with people should be qualitative.
This means if you’re getting repeated requests for information you know you have on a website there’s a problem.
Net Promoter Score (NPS) flags a problem
I’m going to put my hand up and say, like may others, I hate this metric. It’s a vanity metric and for the most part it’s bloody useless in determining usability of something.
However, if the NPS measurement asks visitors to a site if they found what they were looking for, it’s something we can work with.
If you have a low findability score, you have a problem.
I will caveat this by saying, all you have is a percentage score. If you don’t then follow up and ask what they were looking for you’ve just got a number.
Whether or not someone would recommend something is a useless score to identify if you’ve got a navigation problem so I’m not digging into it.
Defining the problem
Your goal (should you choose to accept it) is to define a problem statement.
Your problem statements help you to consistently bring any further research and ideation back to your problem.
The problem statement needs to encapsulate what your next steps are.
For example you could know that people are struggling with navigation on mobile devices. You might want to dig into exactly what’s causing this, from there you’re able to work out what to do next.
Whether or not you formally document the problem is up to you (or the processes you’re working within).
It’s also probable that the navigation design problems are included in the context of a larger design problem.
The wrap up
Spending time at the start of any project identifying what problem you are trying to solve will set you up for success.
This is part of a series on the Four phases of navigation design testing. You should also check out the language of research and testing
