Designers, engineers, and edge cases

Over the last 6 or so years I’ve worked closely with designers on a variety of projects. A pattern that I’ve seen across designers and projects is that designers tend to think about the ideal case: how will it look if the images are all the same size and shape, if there are enough data items that the layout is perfectly symmetrical, if the machine learning (or other probabilistic approach) works exactly as desired. And I understand that approach: when you’re proposing a design, you want to show how good it could be.

But across those same projects I’ve noticed that I tend to think more about the edge cases: where will the design break down? What happens if you have thumbnails with different aspect ratios? What happens you only have enough data items to partially fill a column? What does the design look and feel when the probabilistic algorithm screws up, and how do user notice and recover?

I suspect that some of the difference in approaches is based on experience: I know a system won’t always meet the ideal, so I know you need to account for how it behaves in those other situations. But I suspect it’s also a matter of training (and possibly temperament). Writing software forces you to spend a lot of time thinking about edge cases: if you need to describe how a system works, you need to cover as many possible situations as possible. Design proposals for a system, by contrast, tend to focus on pitching that ideal case. And when you’re trying to pitch the best case, having to also lay out the edge cases really rains on your parade.

And there is often value in emphasizing the best case(s). Because developers have to think through the edge cases, they often attach more importance to them then they might otherwise merit. In code, edge cases often get equal weighting with the best case(s), but in the real world they may only occur in a small percentage of usage. The challenge, then, is to make sure to consider edge cases in the design, but to assign them importance based on their likelihood of occurrence. Of course, estimating that occurrence is often a challenge…