Dealing with edge cases

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”.

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)?

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.

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
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.

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.