Monday, July 02, 2007

Design for the Edges: Part 3

Designing those less used parts of the interface ...

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


Post a Comment

<< Home

<< Home