July 24, 2020
You’re in a groove, slinging pixels around in Sketch and creating a cool new layout for a page that you really like. Everything fits together in a clear hierarchy, fellow designers give you feedback calling it balanced and harmonious, and it tests well in user sessions.
A few days later you get a message from your developer: “How should these columns layout for tablet screens? Everything looks smooshed, but switching to the phone design leaves a ton of space.” You forgot to consider the weird middle widths! You quickly sketch out an idea for stacking some elements to fit better, but it’s definitely a little funky.
Next week you’re reviewing the implementation so far and even the desktop view looks wacky! Turns out your design only really works with headings that are about four words long. Longer text wraps and pushes some elements way out of alignment, while one or two word headings leave unbalanced blank spots.
As your mind starts spinning with ways to fix this someone else raises their hand and asks: “What happens if you submit this form with the end time set to before the start time? Which field gets the error? Do we label both fields as incorrect, even though only one of them would need to change? Or do we need to show the error at a higher level?” You didn’t even think this form might have unique error states your style guide didn’t already cover!
Today’s products are often complex. They have many different states. People from a continuum of different abilities and goals access them via a wide variety of devices and contexts. It’s easy to focus your design effort on the most common use cases and happy paths. But this leaves many open questions about what the edge case experience will be like.
These open questions will have some answer created for them by the time the product ships, whether you put in the time to craft a compelling solution or not. Something will appear on the screen when a a user enters an unusually long heading or visits a site from an unusual device. If you don’t take ownership of the edge cases these experiences will end up disjointed, kludgy, and detract from your product’s quality.
Alternatively, these edge cases are an opportunity to demonstrate your commitment to product quality. Even if only a few people experience each unusual scenario, the chances are good that most people will encounter one or two edge cases in their interactions with your product. You can surprise users in these moments with either your delightful thoughtfulness or disappointing apathy.
Here are a few frequently overlooked scenarios to consider before calling a design complete:
All responsive sizes (not just phone and desktop)
Different label or paragraph lengths, different word sizes
Unusual states the UI can end up in
This can vary a lot depending on the complexity of the features you’re working on. It may be helpful to work with a developer or QA tester to make a list of various states the design should account for.
Scrolling behavior
Hover states
Animations or transitions
Slower internet connections or slower API endpoints
Affordances for assistive technology
This is a much bigger topic but there are a number of basics worth adding to your regular checklist such as: Heading hierarchy, Focus states and keyboard navigation, Link text, Image alt text, Proper text color contrast, and Screen magnification.
First run, empty, or loading states
Error states and messaging
Check out this twitter thread from Steve Schoger for another list of overlooked topics.
No matter how nice your mockups are, the user ultimately only sees and interacts with the shipped product. Good design requires prioritizing and thoroughly considering the messy and unexpected edge cases a real world experience inevitably includes.
— Parker
Subscribe to posts by RSS.