10 Commandments for UI Design

The year is approximately 1,300 BC when Moses received the 10 UI design commandments from the almighty design gods. The list was comprised of best practices that only the most enlightened designers would be aware of.

1. Empty States

Thou shalt make blank states more than just an empty display

A display that would typically be populated with user input is blank because the user has opened your product for the first time.

This could be a list of books, projects, to-dos, customers, or songs — but since they haven’t added anything yet, it’s empty.

Leaving a blank slate where the content would be is a missed opportunity for you to provide guidance and information about what your software can do.

You should use your empty state to orient users.

You can use empty states as an opportunity to provide advice, guidance, an overview of possible actions, or simply replace the empty state with a screen allowing users to input the missing information.

Whatever you decide to do, make sure you don’t just say, “There’s nothing here yet…”

2. Sliders

Thou shalt not use sliders for quantifiable values

Ever get frustrated at a slider because you want to set it to 6, but it keeps landing on either 5 or 7? This isn’t your fault — it’s the designer’s.

Sliders are great for qualitative values like brightness, volume, color pickers, and so on.

You should never use sliders for selecting specific numerical values — in these cases, sliders are frustrating and ineffective.

3. Dropdown Menus

Thou shalt only use a dropdown menu if there are many options

When there are several options, like choosing your country or favorite Pokemon, then a dropdown is the perfect component to use as long as you follow the rules for dropdowns to improve their usability.

However, if you only have a handful of options, then consider using radio buttons or sliders instead.

If you have a very long dropdown with many options, then consider adding a mini search or filter so the user can quickly get to the option they need.

4. Targets

Thou shalt make controls large enough for human fingers

If your interface is used by touch, then give an adequate size to tappable elements.

Having to avoid one item to select another is frustrating, and it doesn’t provide a pleasant experience if they choose an option they didn’t intend to.

2mm padding between elements is a good rule of thumb to prevent mis-taps.

Apple’s iPhone Human Interface Guidelines recommends a minimum target size of 44 pixels wide 44 pixels tall.

Microsoft’s Windows Phone UI Design and Interaction Guide suggests a touch target size of 34px with a minimum touch target size of 26px.

5. Infinite Scroll

Thou shalt use infinite scroll for feed style content only

Infinite scroll is what all the social media apps are using. No need to click to the next page, the content loads asynchronously as the user scrolls.

This works great in a newsfeed, but if applied to messages, emails, to-do items, search, and so on then, the user won’t be able to determine where the beginning, middle, and end is.

When a user can see that there are 945 pages in a list, they can decide whether to narrow the list down with search, sort, or filter. They can’t make that decision if they have no idea how many items there are in the list.

6. Pagination

Thou shalt use pagination for content that has a beginning, middle, and end

Pagination may seem outdated, but it has several benefits:

• It allows the user to orient themselves instead of feeling as though they’re searching through an endless list.
• It remembers the user’s position and displays the current page to them.
• It makes it clear where the beginning, middle, and end of the content is.
• Users can reach the footer if they need to since the page has an end.
• It makes it easy for the user to narrow down their results.

7. Show don’t tell

Thou shalt not require laborious reading to understand how a program works

The expression “show don’t tell” is often attributed to playwright Anton Chekhov, the technique of allowing the reader to experience the story through senses and feelings rather than the author’s description.

Users don’t want to read to understand — instead, show them the situation and allow them to experience it visually.

Showing users how to use your product is always better than telling them.

Video demos are ideal for complex software and interfaces, but if a video isn’t possible, then onscreen tips are a great starting point. Be sure, though, to make the tips visually appealing and dismissable.

8. Labels

Thou shalt give descriptive labels to icons

Mystery icons without descriptive labels are useless and consistently perform terribly in user tests.

The icon serves to provide a quick visual reference by which the user can instantly recognize a control. However, until the function is discovered and understood, the label explains its purpose.

Some icons can get away with not having labels, like bold, italics, underline, and so on. However, icons in a menu or toolbar need descriptive text to explain their meaning.

Icons are misused so frequently that it’s difficult to point to one single meaning for most icons. Different designers use various icons to explain the same thing or the same icon to describe different actions.

A magnifying glass, for example, may mean “search” in one interface and “zoom” in another.

9. Native Components

Thou shalt use device native interface components where possible

By leveraging components already built into products, we can provide users with a familiar experience and avoid input errors.

Regardless of how good of a designer you are, you can’t justify designing a calendar date picker from scratch. Even if yours is objectively better, the user still has to learn a new component when there’s a perfectly fine one built into their device.

Native components are a no-brainer — use them to save time and effort for your team and reduce friction for your users.

10. Loading

Thou shalt use a spinner if the task will take an uncertain amount of time

Using a spinner tells the user that something is happening, but it doesn’t indicate how long a process will take.

If you know precisely how long a process will take, a download or upload, for example, then a progress bar is perfect.

Showing a progress indicator with a percentage of time until completion is ideal, but if you can’t determine how long a process will take, then use a spinner.

If something goes wrong or an error occurs, make sure your spinner stops and alerts the user of the issue. If not, then your user will just continue waiting — meanwhile, nothing is happening behind the scenes.