A designer walks through finding edge cases early using low-fidelity flows and diagrams, then building reusable patterns for error states and notifications. Document these patterns in a design system before development starts, or you'll be scrambling to fix them mid-sprint.
Chapters
How do you approach designing for edge cases? First step is identifying which edge cases you need to design for. I start off very, very low fidelity in terms of drawings. I even start earlier than that where I do user flows, I do information architecture, and it usually is just all words and boxes. Like, it's not even drawings or UI yet. And that'll identify, like, which edge cases we need to have. And then depending on that, ideally we have some kind of patterns. So say, like, there's an error state. Well, we've identified that pattern. There'll be a notification that that highlights what the error is. There will also be some helper text, things like that. And if there's not, then I will design them, document them, add them to a design system or some kind of documentation for patterns to do this in the future. You know, I think after you've identified them, then you have to do it. And ideally you're identifying them earlier than later because you don't want them to get all the way to dev and you miss an edge case and then you have to bring it in, plan it, and do it during the current sprint.
