CODEX
Building a self-suficient UI
A self-sufficient UI doesn’t rely on animations, sound, colors, shortcuts, and help to be understood and used. It doesn’t mean it shouldn’t have them but it shouldn’t depend on them.
Animation
Animations help to reinforce the chosen visual metaphor (e.g. a slide right to express a card removal; a loader to show there’s some background job) and create visual harmony (e.g. to soften transitions). They should be simple, tenuous, and used consistently (e.g. fade in vs fade out to express opposite concepts). Use them in moderation and if they bring value. Animations aren’t supposed to be constantly noticed by users, as they’d be distracting from what matters. They shouldn’t be used just to “make the app cooler”.
Excessive and heavy animations can be really bad, consuming lots of CPU time or being harmful to people with certain disabilities (e.g. epilepsy), so in certain cases, it should be possible to turn them off.
A nice experiment to try is to turn off all the animations and confirm if the UI is still usable (preferably with users). This helps to understand if certain animations are there to camouflage or reinforce bad or good design decisions.
Color
Color, shape, position, contrast, and texture are basic elements of graphical design. We associate colors with moods and emotions that may vary with culture; they can also highlight elements, thus having high expressive power. However, never use color as the single differentiating element. If you have several items that you need to distinguish, color can reinforce it, but it shouldn’t be used alone. The major reason is accessibility (e.g. people with color blindness would have problems using such UIs). On the other hand, you usually don’t know the color limitations of the users’ displays.
The general rule is to use shape to differentiate items and color as an addition. Luminosity itself is also a differentiating element. To know if you pass this “color test”, try to use your interface in shades of gray and see if it needs some fixing.
Don’t communicate only with colors. Can color really be enough to communicate your message? Color can be one element of a much larger picture, but don’t rely on color to serve as the only element of distinction. Colorblind Accessibility Manifesto
Help
A good interface doesn’t require the user to depend on help to perform tasks. This is not to say that the application shouldn’t have a user manual or contextual help. The help must exist and be as contextualized as possible (e.g. well-placed tooltips; contextual links to help); what you should aim for is that the users shouldn’t have to consult it, especially on repeated usage. A good UI should “speak for itself”. For this, a minimalist design, a natural flow of information, a good information architecture, among others contribute a lot.
Avoid instructions; you can do it naturally, transparently, and implicitly. If your UI needs and relies on instructions, “you’re doing it wrong”. Well, not necessarily, but trying to build the UI like that was true.
If users rely too much on help, this may be a symptom that something is wrong with the design or even with the information architecture.
If you find an element of your interface requires instructions, then you need to redesign it. Dan Rubin
Sound
A sound effect at the right time can be helpful. It can be used to draw attention (e.g. new message arrived), to reinforce a concept (e.g. successful operation), and to signal an error, among others.
Like animations, sound must always be used as a complement to the UI and never as a primary form of communication. You should never rely on sound since the user may lack a sound device or have it muted, be in a noisy place, or have some kind of hearing disability.
If adding a certain sound brings value, then it should be used with consideration. Inappropriate use can be annoying and tiring.
Mouse
The dependence on the mouse can also sometimes be harmful. Typical examples are mouse-over and right-mouse-button operations which become unusable on touch-only devices. You can use the right button, but only for the sake of flexibility and speed — and again, an alternative method of interaction. For navigation, consider also keyboard shortcuts.
The same applies to the mouse wheel; there should exist an alternative to its use. Finally, depending solely on the mouse also impacts accessibility.
Keyboard
Keyboard shortcuts (e.g. Ctrl+C to copy, Tab to navigate) aren’t supposed to be the only means of interaction — most are for advanced users. What’s done with a shortcut should be explicitly offered in the UI (hidden under menus or not).
Navigation controls
You shouldn’t expect users to click on the browser ‘refresh’ button to recover from errors or to force data updates. Also, try to avoid depending on the ‘back’ and ‘forward’ buttons to navigate. The software UI should be self-contained in terms of navigation, error recovery, and data update (specially SPAs). In native mobile apps, you can offer an alternative to ‘menu’ and ‘back’ in the app UI itself.
Permissions
In web and native apps, you can ask for hardware and software permissions (e.g. camera, microphone, location, showing notifications) but your app should work without them (e.g. if the user declined permission). If it depends on them to be used, you should explain it to users.
Messages
Don’t assume users read error/warning messages in dialogs. Many times they dismiss them without reading their text. Don’t punish users for missing them. The app should have ways to repeat the message or display it inline (contextually) instead.
Identifiers
Don’t create UI use cases that depend on ids (database identifiers) to be accomplished. For example, why would you show identifiers on a data table? Why would you let the user assign an object to another requesting its id? Friendly titles are for humans; identifiers are for machines.
Conclusion
As a general rule of thumb, try to design each “place in the app” so that the users wouldn’t need to know what they’ve done to get there. They could be forgetful or always interrupted. That said, each place should have the information to be understood by itself, allowing users to resume the task at hand.
When designing UIs, we need to decide what are the means of interaction and divide them into primary and auxiliary. Animation, sounds, color, and help should be seen as an auxiliary — to reinforce or complement the key concepts and ideas. Of course, sometimes they can be of great value (e.g. inline icons to give contextual help, breadcrumbs as shortcuts), but at least you should try to design the UI without depending on them. The general guideline is to turn them all off and test how the UI “behaves”.
In web apps/sites, it’s obvious these days that you should avoid depending on the target audience’s display capabilities, like screen size and resolution, color schema, etc. Embrace responsive and adaptive design. Also, beware and run away from non-standard dependencies like Flash, Java, and Silverlight.
Don’t assume users will see initially hidden information like tooltips, unselected tabs, drop-down options, etc. Bear in mind certain interaction design patterns are inherently an alternative to something (auxiliary), and never the primordial form of interaction. For example, breadcrumbs shouldn’t be the only form of navigation; these are only a shortcut/alternatives to the main navigation.
There are items you want users to see and others they can discover later (depending on task importance). However, you should present items in ways that they wouldn’t need to be instructed beforehand. Design the UI in such a way that it can be self-discoverable. Aim for self-explainable, autonomous, and independent UIs.
Note that the rules above should serve only as a reference, as they may have exceptions (however, to break the rules, you need to know them). Only by testing with users can you be sure that they are met. It’s never enough to repeat that just 5 users are enough to detect most UI problems.