Designing with the User’s Mind in Mind

As many of us know, making user interfaces decisions can be a hard task, something that is especially true for engineers. What seems intuitive for us not always is for someone else, especially someone who is coming into a system for the first time or is not as technically inclined. Having hard data from real user tests is oftentimes the best practice but is not always plausible, especially for smaller, “less risky” changes to the interface. This is where heuristic evaluations come in.

Heuristics are defined as “any approach to problem solving, learning, or discovery that employs a practical methodology not guaranteed to be optimal or perfect, but sufficient for the immediate goals” [Heuristic, Wikipedia]. As far a user experience goes, heuristics are rules of thumb that can guide usability. There are several heuristics to consider but the most popular were defined by Jakob Nielsen of the Nielsen Norman Group. For our purposes I’ve compiled a list of heuristics tailored to the kind of products we build, by mixing Nielsen’s heuristics, usability best practices and personal experience, listed below.
​
Remember that which rules of thumb to abide to depend on the task at hand so they can be mixed and matched depending on which ones apply.

The user should know what is going on with the system at any given time.
Think about:

• If the user walks away from the system and then returned, would they know the state of the system?
• If they are in the middle of a several step process, left the system and then returned, would they know where they left off?

The user should know what the system is capable of doing at any given time.
Think about:

• Can the user tell what to do by looking at the user interface?
• Does the user has to hunt around for functions?

The user should know what was the effect of their actions.
Think about:

• Is the feedback immediate and visible?
• Is the feedback consistent with the user’s actions?

The user should know the relationship between the elements presented on the screen.
Think about:

• Can the user map controls to their respective functions?
• Are the icons appropriate?
• Are the controls positioned such that you can guess their function correctly simply via their position?

Also see: Gestalt Psychology

Use words, phrases and concepts familiar to the user, rather than system oriented terms.
This about:

• Can someone who is NOT A DEVELOPER understand the text presented?

The user should feel on control of the system and able to play around with the functionality with the ability to go recuperate from mistakes.
Think about:

• Clear navigation
• Undo and redo
• Where am I, where can I go

The system presentation should be consistent, similar actions should look and act alike.
Think about:

• Are the same terms or phrases used throughout the system to refer to the same things?
• Are the same or similar icons used throughout the system?

All users have expectations when they come into the system based on their previous experience and knowledge, reduce the learning curve by leveraging that knowledge by adhering to platform standards.
Think about:

• Does the product use conventions common to other applications of a similar domain?

Error messages should only be used as a fallback, even better is having no error occur at all, use constraints to cleverly limit the possibility of mistakes.
Think about:

• Open text fields vs. specific field types for user input.
• Use of constraints.
• Different look for primary vs. secondary actions.
  • For instance the Submit (primary action) and the Cancel button (secondary action) should look different (and probably be far away from each other)

Minimize the user’s memory load by making objects, actions, and options visible rather than having the user remember what should happen.
Think about:

• The user should not have to remember information from one part of a multistep process to another
• Icons should have the respective text next to them, and if they don’t they should have a tooltip that reveals their purpose.

The UI should not contain information which is irrelevant or rarely needed. Every extra unit of information competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors.

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Think about:

• Don’t let developers write messaging.

Users should be able to become experts on the system.
Think about:

• Keyboard shortcuts for experienced users for frequent actions.

Uses should be able to look for documentation to fully understand how the system works.
Think about:

• Pretty much document everything.

---

To finish I’ll add that performing a heuristic evaluation can be a task in and of itself but it doesn’t have to be. They can (and should) be had in mind on any task that affects the user experience by the individual doing the task.