Design for the Edges: Part 4

by Luke Wroblewski July 2, 2007

Part four of Design for the Edges: a series of designer best practices and perspectives on managing edges cases during the product design process.

Dan Saffer Depending on the type of product, you can design directly for the edge cases and edge users, because you know that if you accommodate for them, you will likely accommodate for the non-edge users. For example, I'm working on a project right now looking at a particular medical condition. Most people manage it sufficiently, but some others on the edge do not. If we can make this management system work for the edge users, it will also work for those with less trouble.

Of course, there are edge cases that are disruptive to the product you are making as well. Sometimes you have to throw those out in order to focus on the core of the product. Sometimes those edge cases are those that warrant their own product, but often they simply muddle the clarity of the product, forcing you to fit in all this special stuff in. You can end up with MS Word 2003 that way.

One exception to everything I just said is errors. Products need what system designers call requisite variety--the ability to survive under varied conditions. A user should ideally never be able to accidentally break a product, because doing so is a complete disruption of the experience. It's the designer's job to catch those errors and solve them, either by designing the system so it is impossible for the error to occur (the Poka Yoke Principle) or, if an error is unavoidable (such as from a part of the system the designer doesn't control), provide a means for the user to understand what they did to cause the error and, ideally, be able to fix the error.

Nick Finck It is very common to consolodate personas when planning a strategy for a web site or web application. What is critical to this process is understanding the significance of edge cases. Sometimes seemingly insignificant edge cases could open new doors for a web site, web application, or perhaps even a business. Never underestimate the power of one-off randomness. Take LudiCorp and it's small exploration into photo tools as part of it's Game Neverending which was, at that time, the business's. This small edge case went on to become what we know today as Flickr and now part of Yahoo. Consolidate your personas for the sake of simplicity but explore your edge cases for the sake of innovation.

Frank Ramirez How I deal edge cases...


  1. understand what success means
  2. ignore edge cases until the core flow feels right
  3. keep track of edge cases as they pop up (issues list)
  4. once the core tasks are good, solicit detailed technical input
  5. draft a complete list of scenarios and document UI behavior for all cases
  6. check off the issues
  7. hand off UED spec to dev
  8. during dev, minor (unforseen) edge cases will pop up. In a healthy environment, UED will be looped-in before any behavior-changing mods are made. UED spec is updated accordingly.
  9. yawn.

Eugene Chen Some different challenges that fall under the label of Edge Cases:

Infrequent Cases get lower accomodation in the interace. While frequent needs can be preset as defaults or handled in the primary window, less frequent cases are addressed by menus and secondary dialogs, adjustable in preferences, and finally explained in help. Preferences are a useful tool that tend to be underused on the web. These don't have to be a random selection of leftover decisions that designers force on users. A well organized and consolidated set of preferences can help to communicate 1) an application's scope of support and possibility 2) explain and justify the program's normal behavior 3) suggest the possible--what some people find useful to alter. Preferences can handle a wealth of edge cases in a package that is safely tucked away, yet relatively easy to understand, with plenty of room for explanation.

Ambiguous Cases are nerves of steel. For example, a recent project involved backup software. If the user moves a folder that was selected for backup to a new location, does it stay selected for backup or should we remove it from the backup set? This depends on our interpretation of ambiguous behavior. We're they deliberately moving the folder to take it out of their backup area (for privacy concerns) or were they reorganizing their folders without being conscious of how this might affect their backup plans? A lot of ambiguous cases are damned if you do, damned if you don't. Even if you guesstimate that 70% of the people fall under one case, that still leaves 30% in the cold. Here it helps if the software fits a consistent theme, style, or brand so the user can build expectations.

Unexpected Cases. These involve interactions with items beyond our control such as other applications, legacy file formats, rare errors etc. Unexpected cases require designers to put on their engineer hat. If you are managing a team, you may find certain designers more rigorous and patient with this sort of precise, analytical thinking.

Design for the Edges

More perspectives about Managing Edge Cases: