Thursday, June 28, 2007

Design for the Edges: Part 2

Part two of Design for the Edges ...

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."    (Continued via Functioning Form)    [Usability Resources]


Post a Comment

<< Home

<< Home