Healthy Websites Address Edge Cases Early On
Are you focusing on edge cases? If so, don’t tell that to Paul Boag because he’ll tell you to stop. If you’re building a reasonably large website there might be hundreds of tasks that a user could be trying to complete. But you cannot, and should not, try to accommodate all of them.
EPIC FAIL: Microsoft support answers every question imaginable
Microsoft built what Boag calls, “one of the most comprehensive Knowledge Bases available online.” It answered so many questions that it actually got terribly low scores in customer satisfaction. Wait, what? But it was so informative.
The problem with Microsoft Office Support Pages was that by answering every question they made it hard to find the answers to common questions. Usability expert Gerry McGovern was the one who figured out that their thoroughness was their failure. This is a primo example of over-accounting for the edge case.
What’s an edge case?
Like many problems, the first step to dealing with it is to identify it. Edge cases are by definition anything that ARE NOT core tasks and activities. That means that instead of identifying each and every edge case, you must do the opposite:
DETERMINE THE PRIORITIES OF YOUR SITE. EVERYTHING ELSE IS AN EDGE CASE.
How do I identify core tasks and activities?
Everyone has an opinion about how to identify edge cases. One way is to build a persona and design the site around their theoretical experience. You can also create user stories (in fact, here are 10 tips for writing good user stories). Or if you want to go the way of Gerry McGovern, you can identify Top Tasks (explained here by McGovern). Essentially, he lists every conceivable task that could be completed on the site. Then he shows these to sample user groups. The various user groups prioritize them. From there it’s up to the web team to synthesize these results and determine a hierarchy of tasks that meets client satisfaction.
Dealing with Edge Cases
Boag explains that once you’ve identified the edge cases, you need to deal with them. He recommends a three-stage approach based on John Maeda’s book, Laws of Simplicity.
Apple’s the most obvious example of Maeda’s claim that simplicity equals sanity. We don’t like complicated technology. We don’t want too many menus. We are never going to read that 75-page software manual. Things like the iPod epitomize the hipness of simplicity. However, this creates what Maeda calls a simplicity paradox: we want simple, easy-to-use things that do every complex thing imaginable.
Boag offers three easy ways to approach this paradox. Designers/web developers, this type of thinking is imperative. But clients, you can benefit from this paradigm, too. Regardless of what side of the table you’re sitting on, Boag’s thought process is worth considering.
Can this be removed?
Okay, so you’ve identified your core tasks. The leftovers are your edge cases. One by one, ask yourself, if my website didn’t accomplish this task, would the experience be ruined? If you feel that, yes, this could jeopardize the site, then ask yourself, is it worth the tradeoff of making the top tasks harder to find? If yes, move on to the next question.
Can we hide this edge case?
Often, the best thing to do is hide an edge case. Usually this means pushing it lower in the information architecture, or making it only available through search. You can also isolate the information so it’s only accessible via a direct link. Now the content‘s available to someone who needs it, but top tasks are not interfered with. But what happens if this edge case is imperative (say perhaps for legal, or moral, reasons)?
If you have to, shrink it
There are cases where the design studio, or client, cannot bend to the unspoken truth: very few people are ever going to need to accomplish this task. In a perfect world, you’d convince whoever is imposing this task to change their tune. But, if that’s not possible, the best option is to shrink it. This becomes an exercise in visual hierarchy. The goal is to make the edge case accessible without distracting users from the top tasks. It’s not ideal, but it’s really your only answer.
Boag’s “death by a thousand cuts”
Boag admits that pushing back against edge cases can look petty. Come on, it’s just one link, one might say. “The problem,” Boag claims, “is that… it’s not just one little link, it’s one more little link and overtime these links build up into a massive haystack that makes the needle impossible to find.” Keep in mind that finding this proverbial needle might not be worth a visitor’s time anymore.
So in an exceedingly complex world, how do we NOT make websites that bleed out? We like Boag’s mantra:
WHEN DEALING WITH EDGE CASES, GET EVERYONE IN THE ROOM TOGETHER
A consensus on edge cases will save you from a sequence of voices, who all might try to sneak in additional tasks. Avoid these potential nicks and agree on edge cases early on. It’s for the wellbeing of your website.