Design for the Edges: Part 3

by Luke Wroblewski June 30, 2007

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

Micah Alpern When faced with a new design problem: Step 1: Make a very small number of canonical designs that represent the major use cases Step 2: Review, iterate, get buyoff on the fundamental design direction Step 3: Once the general direction is reasonbly solid and agreed on start to consider the edge cases.
That's not to say that edge cases aren't important. Usage data with existing or analogous systems help you validate your assumptions. Sometimes you're expectations are wrong and something that you thought was an "edge case" is much more common. I see this often with designers who don't understand the technology well enough. They assume the technology will "just work" and they won't have to deal with use cases where the interface must clarify, deal with errors, dependencies, or request additional info.

Bruno Figueiredo My approach is to draw a rough sketch of the core functionality first and then consider how edge cases can influence the core. If they indeed affect core functionality then revise it to accommodate the changes. Sometimes edge cases make sense as part of core, but usually they’re only side functionality (used only by a small set of end users), so I tend to draw them out of the core functionality on separate screens or panels. That’s also more flexible.

Uday Gajendar Here are some quick pointers I've learned. The basic overall premise is that the designer is there to help ship a product to users, given time/resource constraints.


  • Gather all the pertinent info about the case: the main context, primary trigger, consequences if not resolved, level of impact/severity on user's productivity and goal/task-completion
  • Ask: does this happen once, twice, or more? Be sure to ask BOTH the PM and the Dev Lead or QA--you'll likely get different answers, which will force a much-needed but often neglected conversation among key stakeholders about the app's utility in "real situations" and what's really important in terms of the product strategy/direction.
  • Upon resolution of the frequency...
  • If it happens just once, shelve it as a bug for now to be addressed "if there's time"; so just have QA file a formal bug and move on to other high priority design tasks
  • If it's a few times, explore a few design alternatives but set a firm timeline. If the situation is not resolved by then, have QA file a bug and move on
  • If it's everywhere, or warrants major impact due to PM/customer request priority or executive fiat (as is often the case), then certainly get this design tasked and prioritized and crank on it!

Another thing to consider all the while is the adage "don't break 80% of the app, just to fix something used by 20% of the users". Holding to that ideal can be difficult when facing a QA nagging you in your face (or filling up your inbox with lovely screenshots). Just remember to verify the frequency, priority, and fit within the overall design strategy. The QA's job is to find those crazy weird edge cases and dutifully report and file them for handling per their bug filing systems (clearquest, etc.)--so you should simply recognize that, and don't let it get in your way as a designer. You're not beholden to fix every single problem encountered; you're paid to help deliver the best possible solution for your users/customers given the constraints of the situation.

Design for the Edges

More perspectives about Managing Edge Cases: