Part two of Design for the Edges: a series of designer best practices and perspectives on managing edges cases during the product design process.
Eugene Chen Although core cases are the main goal, edge cases can easily consume a large amount of developer effort and design discussion. Managing edge cases is an important component of managing cost.
Usability testing is not particularly helpful in revealing edge cases as users are often instructed roughly what to do and given little time to experiment. A lot of edge case resolution is driven by developers who have no choice but to articulate (through coding) design solutions with greater precision and comprehensiveness than the design documentation we give them. It's important to review designs from the start developers to flush these out and avoid territory that would create more potential edge cases.
There are two basic approaches for handling edge cases: either you prevent it or you support it. Given the choice, I still like to prevent the edge case - it keeps the design optimized and less generic and reduces engineering effort. However, there are times that you can't prevent what the user will try to do with your system.
Google and many Web2.0 sites are doing a great job with setting expectations up front (compared to say desktop apps). Frank intro pages with economical bullets save users' time and frustration and get to the point. These pages tell users what the app is for and what it is not for.
When edge cases are preventable, encountering one can be an opportunity for learning for the user. The education can be shifted to just-in-time at the critical moment, rather than up front as defensive design. As a simple example, if an input box expects a certain type of input, the design could either say so up front in the instructional prompts, or not mention it, assuming that the majority of users will do something acceptable. Then, when a user does enter something unaccceptable, a message can tell them about the rules as well as expanding on why or giving other tips. This shifting of information from before-attempt to after-attempt is particularly helpful in space-limited situations like mobile design.
While it is an absolute necessity to consider edge cases, the key is to not to let their solution drive the core design. Edge cases should be handled, but their influence needs to be metered proportionally. It's also important that design not be overly accomodating and become a least-common denominator design. Better for the design to serve a few core cases well and create a buzz among those users. I think it is important to distinguish between uses that the design is intended to support well (thus expanding the potential audience) and edge cases for which there may be no or sub-optimal support.
Luke Kowalski Instead of answering how the edge cases are managed, I would rather flip this one first and talk about how they are accommodated. Both words could mean the same thing, but it does put this extra functionality in a more positive light. After all, the common adage is probably true: What can be an edge case to the designer could also very well be "mission critical" to a particular segment of users.
Edge cases in enterprise software are often created by implementers and customers. We will often deliver a given design that meets most customers' needs, and a vendor (Accenture, etc) or a customer will customize the forms to suit the particular business needs, often adding fields, sections, or even tweaking the flow. We take the pride in the fact that our forms are "extensible", so we do not perceive this as a deterioration (in original design fidelity). We also demo the enterprise applications in a mode, where it is possible to add edge case fields and layouts that are important to a given customer (substance volatility field in a materials requisition for the chemical industry demo, f.e). Furthermore.... enterprise applications also have the ability to display 10 fields if you are in a user subgroup A, but only 7 fields if you are in B (based on your login credentials and profile). Business logic there can get pretty extensive, and this automatic customization nicely complements the self service type of personalization often available in the form to the end user.
While the former example illustrates how we account for edge cases after the core layout has been delivered, we also use common methods to design in secondary functionality into the forms from the get-go. We often fork the UI into two, or several paths. One example is procurement, where the end user can pick a basic flow with just the basic items to put into the cart, and the shipping/billing train stops in the wizard. We would also utilize the second, or advanced option, where the wizard includes sub-steps, branching dialogues, so that the user can break down the lines in the purchase order and assign them to different cost centers, etc. One other design adaptation for edge use cases includes real time (ajax-y) hide and show regions (think mac chicklet). A user can expand a region with "edge case" or optional fields.
Lastly, developers will often add edge cases to a form, but they will not do it to spite the designers. It is simply a response to a particular beta customer, or a sales situation. In the end it all comes down to your data, and how you gathered your info about what is the 80 percent use case. It will be different if it came from a survey, an ethnographic study, and of course, depending the audience (purchasing agents, end users, trade show attendees, existing vs. new customers). Getting that balance right will get at the most efficient form design, while the ability to accommodate extensions will solve any other issues down the road.
Design for the Edges
More perspectives about Managing Edge Cases:
- Design for the Edges: Part 1 with Jed Wood, Jamie Hoover, and Jim Leftwich
- Design for the Edges: Part 2 with Eugene Chen and Luke Kowalski
- Design for the Edges: Part 3 with Micah Alpern, Bruno Figueiredo and Uday Gajendar
- Design for the Edges: Part 4 with Dan Saffer, Nick Finck, Frank Ramirez and Eugene Chen