33 cut-out-and-keep usability requirements for your product

I strongly believe that all software companies should have a manifesto or a set of guidelines which set out in practical terms how they will ensure that their products are intuitive for the types of user for which they’re intended.

Good Design Quote courtesy of inspireUX

For product managers, even if your company or Development team doesn’t “get” usability, you can build these into your product requirements and use your Quality Assurance team to check the requirements have been delivered.

Here’s a list of my top 33 (a pleasing number), divided up in to categories:

  • Context – avoiding the “Help! I’m lost” feeling users can get during an unfamiliar process
  • Intuition – making users feel like they already understand exactly how everything works on first go
  • Declutter – an ordered UI is the sign of an ordered mind (and it’s easier to understand)
  • Feedback – ensuring users know what’s just happened or currently happening
  • Localisation – taking into consideration that English may not be the user’s first language
  • Common Sense – it’s difficult to design for anyone other than oneself when in a vacuum.  What may seem obvious to your developers probably won’t to a user (unless they’re also a developer)

Context #

  1. Users should be able to see an overview of the process by which they achieve a particular task at the outset of the workflow
  2. Users should always know where they are currently in a workflow, what they’ve just done and what they need to do next

Intuition #

  1. Users do not read inline text before attempting to use a web application – make the desired actions obvious
  2. Graphics should be used in preference to words to explain or illustrate concepts
  3. If something is meant to be clickable, it must look like it is clickable
  4. All icons must provide a tooltip to explain what they represent
  5. UI widgets that look the same must behave the same regardless of the context in which they’re used
  6. If a UI widget needs to behave differently, it must look different
  7. Any “show me how” videos should be available to walk a user through how to achieve a specific task
  8. “Show me how” videos within a product should be picked up a YouTube channel to allow new content to be added without necessitating a new product release, and to allow the tech support site to provide the same content
  9. Avoid company or technology jargon, acronyms and other terminology meaningless to the intended user

Declutter #

  1. Within a workflow step, mandatory configuration or very frequently-used optional configuration should be presented first to the user
  2. Within a workflow step, optional configuration should be presented second to the user and hidden by default to avoid clutter

Feedback #

  1. All input needing validation should be validated immediately inline
  2. All errors should be displayed where they occurred and should explain why the error was triggered
  3. If something is working in the background or foreground, the user should know this is the case
  4. Actions taking longer than a few seconds to complete should provide progress reporting to the user
  5. Successful actions should be confirmed visually
  6. Unsuccessful actions should also be flagged visually and should direct the user on how to resolve the problem

Localisation #

  1. Design as if the product already exists in 5 different languages: make every user-facing piece of text a label which draws on a local language resource
  2. Images with embedded text are a poor idea if you’re planning to translate the UI: it’s going to mean a lot of extra work to redo every image
  3. Pixel-perfect UI layout that relies on the length of words will break down if the words get a lot longer in other languages (German, for instance)

Common Sense #

  1. Users should achieve a reasonable result by accepting suggested defaults
  2. All product configuration should be possible in the UI without having to manually edit configuration files
  3. Avoid technology-driven constraints on user-specified labels: users won’t understand or care why certain characters are not permitted, and it’s not your job to teach them that a ‘[‘ is not valid in SQL table names
  4. Autodetect settings or information wherever possible, but allow a user to override the settings detected if required
  5. When a users specifies a setting, remember it until the user changes it
  6. Dangerous actions should be double-checked with the user, with the default action being not to do the action
  7. Using browser forward and back buttons should not break a workflow or lose page state
  8. Lengthy or complicated workflows should autosave settings so far on behalf of the user in case of unexpected interruption
  9. Common tasks should be more readily accessible
  10. Pop-ups and pop-unders should not be used, workflows should proceed in a single browser window
  11. Tooltips must be concise

Agree? Disagree? Join the conversation: