{"id":54,"date":"2007-06-20T10:41:00","date_gmt":"2007-06-20T17:41:00","guid":{"rendered":"http:\/\/www.ghostinthepixel.com\/archives\/54"},"modified":"2007-12-31T22:52:53","modified_gmt":"2008-01-01T05:52:53","slug":"dealing-with-edge-cases","status":"publish","type":"post","link":"https:\/\/www.ghostinthepixel.com\/?p=54","title":{"rendered":"Dealing with edge cases"},"content":{"rendered":"

One of the challenges of working with inter-disciplinary software teams involves incessant yet valuable inputs from QA engineers, who earnestly point out situations not necessarily covered by the MRD or UI spec, aka “edge cases”.<\/p>\n

These cases typically impact perhaps 5 – 10 % of the target user audience, if not less. But as the leade designer for an ambitious re-design, and as a consultant guiding the client on doing what’s right for the user, how do you handle these requests without dismissing them rudely or acquiescing to every single request (and thus caught stuck in the quicksand of pointless iterations)?<\/p>\n

Here are some quick pointers I’ve learned from Andrei\/Involution. The basic overall premise is that the designer is there to help ship a product to users, given time\/resource constraints.<\/p>\n

    \n
  1. 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<\/li>\n
  2. 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.<\/li>\n<\/ol>\n

    Upon resolution of the frequency…<\/p>\n