Article summary
On most of our software projects, design time is constrained. The design investment is front loaded to help understand users, set a broad direction, target features, and establish branding. As a consequence, we don’t usually have every possible detail figured out beforehand.
Unfortunately, that means important things can get left off of mockups from time to time. The things I see missing most often are designs for dynamic items. Below are the three I check for, plus some suggestions for what to do when you lack clear design direction.
(This list is pretty heavily skewed towards web work. These are still important items on other platforms, but many native toolkits provide existing conventions, so the design isn’t up to the team.)
Missing Dynamic Items
Whenever I get a style guide or initial comps, it always has basic items like error states for forms. Unfortunately, the more dynamic items are often not specified.
Hover States
In your design, do you indicate hover with drop shadows? Does the text weight change? Does the mouse cursor show the hand? Do you change the background color? None of these are hard questions to answer, but they’re easy to forget.
Also, keep in mind that this isn’t just for buttons; input fields, navigation elements, and just about any interactive part of your site may warrant a hover state.
Loading States
Tools like Suspense can help when a whole section of your app is loading, but they don’t give you an answer when it’s just a part. How does data populate a list? Do you have skeleton components?
How do you indicate saving or working? Do you have a spinner near the save button or an indeterminate horizontal bar across the top of your screen?
Transitions and Updates
When your users shift between modes (such as between editing and viewing), what should that look like? Is the editor being shown in-line where the read view was, or is it a navigation? When new data arrives, what happens to the current data? Do things shift or jump in a jarring way?
Getting Design Guidance
If you’re working on a screen and the mockup doesn’t specify all of the above, where should you look for guidance? In many cases, you’ll have a toolkit (such as Bootstrap) that already implements some things for you. If so, you may not need to do any work to really polish the basic widgets. I’ve also found that Bootstrap provides some really great CSS variables and mixins to help you make your own custom widgets match it.
For fully-custom items, I’d start in the same place. Find a similar widget elsewhere in your design, and make the new screen match the existing one. As a last resort, you can always ask the design team for help. It’s always hard to get their time, but if you handle the easy things yourself, they’ll have more capacity to help you with the tricky ones.
Polish Matters
Take a walk through your app and look at it with an eye to the items described above. You know your app well, but for new users, things like these help them:
- discover what they can do (via copy and hover states).
- understand what the software is doing (loading/progress states).
- track how things relate to each other (transitions).
This is small potatoes stuff — easy to build. But it goes a long way to making an app polished.