I am talking about those gnarly edge cases where you realize that your neat solution doesn't apply to some use case and you have to make significant changes to your design. For me, most often, these edge cases come up in design review sessions. I was thinking that pro-actively seeking edge cases early on with the help of other team members, especially engineers, might be a better approach. But I was wondering if there are other approaches that have worked for you.
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. :-)
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.
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)
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.
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?
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.
Whew, good question. They come up pretty naturally at different points of the process, all the way through launch and a bit beyond, so you always have to be ready for them. When they do come up, we typically will use potential severity as a means of determining priority. That's a dialogue that sometimes happens internally only, sometimes with the client, sometimes both. At some point you make a call on whether or not you're going to deal with it, and if so, how. But figuring it out always starts from what the impact might be, and potential frequency is further down the list but usually a factor, as well.
From personal experience... If you address every edge case from the start, you will have an unworkable and unmanageable product. Edge cases will break existing workflows, consistency, and add unneeded complexity to a product. Making a headache for editors, devs, and to the user.
Granted if your dribbble pretty design doesn't meet your users/business needs... well that should come out of user testing and data, and you should iterate your design. End of the day, just say "Show me the data for this edge case".
Most of the time these edge cases I experience
Someones unverified scenario (What if...)
False user perceptions that stakeholders have (I think and I believe that...)
Someone complained X years ago, so we need to have it this way.