Designer News
Where the design community meets.
↵
How and when do you deal with edge cases in your design process?
over 5 years ago from Marco Perez, UX Designer
Jan Zheng, over 5 years ago
This is a good general approach to design problems. The edge cases, of course, are applications that put lives in danger or could affect the quality of life, for example, human factors, comfort, and accessibility. If happy path severely affect those things, and if they are a concern, then you can't ignore them.
Keith F, over 5 years ago Agreed - and not advocating for edge cases to be ignored. But if the "happy path" somehow allows for a life to be put in danger, or comfort to be compromised, then something is wrong because those are basal requirements and really should have been surfaced early on as part of discovery. A table saw that cuts exquisitely but has no safety features suggests that the default scenario wasn't properly understood through a human-centered design approach.
right true, those should all be baked into the core requirements for sure.
But then how do you explain the pervasive lack of accessibility, especially in most awards sites? Many of them push for cool, bleeding-edge "experiences" without considering basic accessibility.
Too many sites and apps have low contrast, tiny text and other things that make the site look and behave "cool" but compromise usability for a large group of users. I'm a culprit as well, but working to change that.
I think what I'm getting to is — some things we consider "edge case" might be the main case for some users. It's a business decision whether to treat those as main cases or not. (also, this DN reply box is very eye-straining)
barry saunders, over 5 years ago
the lack of accessibility on a lot of sites is a huge problem, but I'd avoid framing accessibility as an edge case.
Providing accessibility is about making sure everyone can access the core function of your product (and frequently a legal requirement, too).
Supporting edge cases is about adding to the core function of your product.
Joao Carvalho, over 5 years ago Interesting. But by applying a design push in the beginning and edge cases thinking later, wouldn't you be creating a situation when edges cases comes up, it can create frustration or double the work since they weren't thought since the beginning?
Keith F, over 5 years ago A group of people can brainstorm extreme scenarios from the beginning, but is that really helpful? It distracts the team from focusing on the higher order problem and opportunity.
For example... if I had to make an app for people to share videos, I want to first focus on our target group, their goals, and create strong user scenarios - not chat about out what we're gonna do when the file size is too big or the server is down.
Those cases are important and need to be addressed, but I personally wouldn't dive in to them early on.
My 2 cents. Personally, I try to steer discussion away from edge cases until the happy path scenario is well understood and we have a really strong proposal for it. This is because:
There is momentum at the beginning of a design push. I want to capitalize on that and focus our creative energy towards finding a really solid "happy path" solution. This is the main use case for whatever you're designing, and if it's well-understood in the beginning, an edge case shouldn't necessarily blow it up.
I think that an early hunt for edge cases ends up giving them an outsized influence on the primary workflow. The workflow people will actually use 99% of the time. This can lead to early compromises that disproportionately affect the job to be done by the majority of users most of the time.
Then comes the time to invite discussion of edge cases and find accommodations, having a thick skin. I think detour workflows for edge cases are generally preferable to complicating the primary path... but of course it all depends. :-)