Microsoft’s Office support pages were so thorough, answering every obscure question, that it was hard to find the answers to the most common questions.
After bringing in usability expert Gerry McGovern, it turned out that this thoroughness was also the downfall. Microsoft was so focused on answering every question, no matter how obscure, that it was making it impossibly hard for people to find the answers to the most common questions.
The curse of the edge case
This is a problem I encounter all of the time. Clients become obsessed with edge cases. They are always saying what if a user wants to do this or let’s put this piece of content online because somebody might find it useful. This is the curse of the edge case.
Every time you accommodate an edge case, it comes at a cost. It adds complexity to your site, making it just that little bit harder for the majority of your users to find the answers they want. It’s like adding another piece of straw to the preverbial haystack in which the needle is hiding.
Recognising an edge case
The first step to dealing with edge cases is to identify them. To look at things another way; you need to know what your core tasks and activities are. Once you have done that, you know everything else is an edge case.
There are a lot of ways of identifying your core activities. Some start with personas, others with user stories, while Gerry McGovern (who I mentioned earlier) begins by identifying Top Tasks.
Essentially Gerry draws up a list of every conceivable task that could be completed on the site and presents that to sample groups of users. He then asks them to prioritise the tasks that are most important to them.
At first glance this seems ridiculous as the list can run to well over one hundred tasks. However, the sheer number of tasks is what forces users to prioritise on an almost instinctive basis.
Whatever your approach it is absolutely crucial to identify what core activities you want to support so that you have a clear picture of what lies outside of that core.
Dealing with edge cases
With your top tasks identified, you now need a way of dealing with edge cases. Instead of just ignoring them, I recommend a three stage approach based on John Maeda’s book, Laws of Simplicity.
In his book Maeda suggests that the way to keep any product simple is to either remove elements, hide elements or shrink elements. With that in mind, this is how I deal with edge cases.
1. Can this be removed?
Step one is to ask if this edge case can be entirely removed from the website? Is this such an edge case that it can be completely ignored? To make this decision, look at the edge case in the context of the top tasks for the site.
Ask yourself the following question: is it a reasonable tradeoff to make the top tasks just that little bit harder to find in order to accommodate this edge case? If the answer is no, then you should remove the edge case from the site entirely.
If on the other hand the answer turns out to be yes, then we move to the next option.
2. Can we hide this edge case?
If an edge case has to be accommodated on the site in someway, the answer is often to hide it. Hiding it can mean a variety of things. Typically it might mean pushing it lower in the information architecture, removing it from the main navigation entirely (making it only available through search) or isolating the information so that it is only available via direct linking.
This ensures that the content is still available to those who need it and know where to look, but it doesn’t make it harder to find the top tasks.
Of course sometimes the edge case cannot be hidden. This might be because it is more common, or it is just politically unacceptable to hide it. In such scenarios consider Maeda’s third option.
3. If all else fails, shrink
We have all been there. The managing director of the company wants a link to a welcome letter from him on the homepage of the site. If ever there was an edge case this was it. Nobody is interested in the letter but he insists that it is there.
In a perfect world you would show him the error of his ways and it would be removed, but we don’t live in a perfect world. Even hiding the letter away is not an option. This just leaves shrinking it.
Essentially Maeda’s third law is about creating a visual hierarchy. If you have to feature edge cases make sure they are visually less eye catching than top tasks. It’s not ideal, but if all else fails it is a fallback you can use.
Death by a thousand cuts
The problem with edge cases is that from the outside you can look petty. It’s not unusual to hear comments like it’s only one little link. The problem is that it is death by a thousand cuts. It’s not just one little link, it’s one more little link and over time these links build up into a massive haystack that makes the needle impossible to find. On top of that, users are rarely willing to search for the needle in the first place.
You can quote statistics about user attention until you are blue in the face, but to each person pushing an edge case they are only asking for one tiny change. The only way to solve the problem is to get all of these people into a room together so they can see the scope of the problem – but that is another post entirely.
“Needle in a Haystack” image courtesy of Bigstock.com
Comments