Design for the Edges: Managing Edge Cases

by June 25, 2007

When designing product experiences, most designers focus exclusively on the core interactions that uniquely define a product. But infrequent edge cases can contribute significantly to the overall user experience and ultimately user loyalty for a product. Yet accounting for these edge cases often rests in the hands of developers not designers.

Jed Wood recently encountered this situation in a big way (see below) which prompted me to tap a panel of designers versed in edge case management for their best practices and thoughts on designing for the edges. What I got back was a wealth of insights and perspectives that I’ll share on Functioning Form in a series of articles.

Jed Wood Before I tackled the design of a multimedia management system for automobiles, all of the projects I worked on were applications not complete systems. I was presented with a level of complexity that I wasn’t accustomed to handling. Not only did each screen need to account for unexpected user behavior, it also had to account for events coming from other parts of the system.

Our design team went to great lengths to cover as many edge cases as they could imagine, but the developers still bombarded us with questions like: “What should we display if the user ejects a disc while they’re backing-up but they’re also on a phone call, and then we lose GPS signal strength?” The number of possible combinations of events and interactions seemed endless.

Having focused on rapid prototyping for most of my career, my temptation was to aggressively apply the Pareto principle; focus on the core interactions and leave the edge cases to chance, or let the developers decide what to do. But this was a system that was going to be used time and again so the accumulation of edge cases had the potential to really impact overall user experience. Also we wanted to make a product that was well thought out. Those are the products I love to use.

Jamie Hoover I have few tips to minimize unintentional disconnects during a software session:

  • Code. Drawing pretty pictures only scratches the surface of the whole system. Coding reveals the architecture of the system, giving you access to how things flow and where they disconnect. An architect must understand the fundamentals of building construction, before they can shape a real structure toward a vision.
  • Test your own product. Take every path, make every choice. Understand your software as your customers do.
  • Make your software as simple as possible. Less complexity decreases the possibility of edge cases in the first place.

Jim Leftwich My experience is largely informed by device and system projects, but I think there are parallels in a wide variety of interface domains. How one defines or approaches the issue of "edge cases" is going to depend on many things, including what domain one is designing in, associated organizational issues, legacy constraints, depth to which one is driving development, scope of overall effort etc..

Edge cases themselves come in many forms. Sometimes they represent important, but rare needs or goals. Sometimes they're edge cases only because of the way the enabling technology or interface penalizes non-common activities or fails to provide multiple and/or syntacticallly logical interaction pathways to users' goals. And in still other cases, they represent truly unique activities completely beyond or fundamentally different from the most typical activities and needs, and require an individualized, special, or unique solution.

The process I and my teams use to develop a flexible and accomodating interface begins with assembling and brainstorming as many potential use cases and interactional sequences, and from as many sources and observations as possible. These are sorted and compared in order to discern interrrelationships and common patterns among them. Then the design process proceeds to iteratively developing a simple interactional syntax of interface elements, their function, and their interrelated syntactical behavior. Success of this interactional architecture will be determined by how well it can efficiently and intutitively support an anticipated or greater range of potential interactions/functions/usages patterns. The greater range of use cases and needs that a syntax can efficiently and flexibly support, the greater the chance it will be able to accomodate a wider range of known and potential edge cases.

Syntactical interaction architectures support more modular, flexible, and intuitive usage interaction, and thus are able to accommodate a greater range of at least certain types of edge cases.

Design for the Edges

More perspectives about Managing Edge Cases: