Ah yes, edge cases. AKA designing for the exception. I think we’ve all been there, right?
So, your project team has come up with simple, elegant design to – oh, I don’t know – make a payment of some sort. And now you’re presenting it to your client; or the higher ups; or your peers in IT, QA, legal, or what-have-you.
Holy cow! The things they come up with. What if it’s a bank holiday? What if the dollar amount goes into 12 figures? What if the user has more than 20 accounts to pay from? What if it’s a full moon in a month with an “r” in it and Mercury’s in retrograde?
But that’s their job, isn’t it? Business analysts, QA types, developers, and others are typically focused on the far parameters of a system – how long should the field be, what if the user enters a date in the past, how many of this should we allow users to set up, how much of that do we need to say to be within the law?
Your job is to allow them to do what they do, but to be sure that the team also keeps the normal, the average, the expected in mind. Yes, what they’re concerned about will come up. They need to realize, though, that it will come up a lot less than they think it will.
They also need to realize that their edge cases do not need to drive the design. In particular, they need to be aware that, if they do insist on doing that, there will be consequences. Adding things in for once-in-a-blue-moon occurrences do not come free of charge.
That little change of theirs may, in fact, trip up all the other users who it actually doesn’t apply to. Those users may wonder why that part’s there, or if applies to them, or why you’re so bent on throwing all this extra stuff at them. In fact, those little changes may add up, and have a much larger impact, on a much larger group of people, than leaving all those edge cases out entirely.
So, how to solve for this? Well, just having these folk’s consciousness raised is sometimes all that’s needed. Pretty much everyone’s familiar with the old 90/10 rule, so I’ve found it’s always helpful to invoke that in these situations.
Another thing that I swear by is progressive disclosure. And all that means is that the user doesn’t have to see everything at once. You could, for example, hide the details behind links, or not show something until the user gets to a particular point.
Once again, though, just getting your team to realize that adding all those exceptions in does come at a price may be all that it takes to make them stop and think a little.