Designing for the Edges

"Explore your edge cases for the sake of innovation."

Nick Finck is just one of the prominent designers who see the value in edge cases. On the other hand, the casually dismissive "Oh, it's just an edge case!" is all too commonly heard. Before tossing out your edge cases altogether, ask these questions:

• Is the case a user goal believed to be shared by only a few users?
• Is the case created when technical limits prevent the application from fulfilling a user goal?
• Is the case created when users interact with the application in unexpected ways?

If the answer is "Yes," the edge case indicates the opportunity to introduce delighters/exciters, usability improvements, technical innovation, or trend-anticipating product innovation. Capture this information somewhere for follow up if you must drop the case from your current design effort.

I saw these factors in action some time ago when I was designing a new, much-requested, feature. One customer had what some believed to be a novel requirement. The requirement seemed to make business sense. The solution would extend an existing feature and require the addition of a minor option to the feature I was designing. Even so, my business stakeholders asserted this customer's request was wholly unique. They were sure no other customer would use the new option because, the stakeholders believed, none of them used our application the way this customer did.

I decided to inquire further. After all, these same people had asked us to invest a significant part of the project budget to design a different capability targeted at the very use pattern they now were sure was used by only one customer. It didn't add up.

Sure enough, there were customers who had asked for something similar. Engineering had not anticipated their requirement in their original design. Later, engineering removed a configuration option from a related feature. Without the configuration option, the first feature was unusable.

Someone had figured out a hack that mimicked the desired behavior, a hack that was subsequently employed for other customers. The hack was "good enough" - until a customer needed both the original feature and the flawed related feature. The workaround obscured an underlying limitation in our application that could have been easily remedied at any time.

This "edge case" qualified on all three criteria: people believed the request was idiosyncratic, a technical limitation prevented solving a customer's business problem, and the need to solve the business problem was unexpected. By repairing the flawed feature we could serve the insistent customer to their satisfaction, and deeper-than-face-value analysis revealed prospective customers would likely appreciate the feature, too.

Read the 4-part series Designing for the Edges at Functioning Form, where Luke Wroblewski collected a number of perspectives on the value of edge cases.