Errori da evitare

  1. usare controlli GUI non standard. Per l'utente comune i widget classici (button, checkbox, radio button,scrollbar, ecc.), che costituiscono l'interfaccia di un programma, sono ormai diventati delle unità lessicali che non possono essere stravolte nel comportamento. Usare dei radio button che non funzionano come tali, o pulsanti che non innescano azioni, portano ad un'inutile disorientamento dell'utente.
  1. Inconsistenza. Se all'interno del programma si usano differenti parole per descrivere le medesime azioni o la stessa terminologia per azioni differenti, si viola una sorta di inerzia di visualizzazione.
  1. Non far percepire la funzionalità di un oggetto. Gli inglesi la chiamano perceived affordance e rappresenta la chiave intuitiva per sapersi muovere all'interno di una qualsiasi interfaccia utente. Avere degli oggetti che non innescano questa associazione mentale, porta l'utente a rischiose sperimentazioni sul campo.
  1. Mancanza di feedback. Se l'utente non capisce cosa sta succedendo o come i suoi comandi sono stati interpretati, significa che l'interfaccia non sta facendo il suo dovere. Ed allora tirare ad indovinare può essere un'azione pericolosa come, ad esempio, quando manca la barra di progressione per mostrare lo stato di avanzamento di una elaborazione.
  1. Usare pessimi messaggi di errore. I messaggi di errore sono dei particolari feedback, che segnalano all'utente che qualcosa è andato storto. Sebbene da oltre trent'anni si parli sempre delle stesse linee guida da adottare, le applicazioni che continuano a violarle non tendono mai a diminuire.
  1. Far chiedere la stessa informazione due volte. Visto che i computer hanno una certa predisposizione nel ricordare le cose, la pigrizia del programmatore non deve trasformare l'utente in un "fattorino" di informazioni da una parte all'altra del programma.
  1. Non usare valori di default. Questi aiutano l'utente non esperto ad accelerare l'interazione col programma e gli insegnagno immediatamente un metro da adottare per possibili variazioni.
  1. Catapultare l'utente dentro l'applicazione. Se è vero che la maggior parte delle persone non presta attenzione alle istruzioni che gli vengono proposte, un conto è lavorare con quelle che vengono definite applicazioni effimere e un altro con le cosiddette mission-critical. Per questo visto che l'utente non può conoscere i concetti base che stanno dietro all'applicativo, ha bisogno di un approccio graduale fatto di immagini o di elenchi puntati, che ne sintetizzino la visione d'insieme.
  1. Non indicare come le informazioni verranno usate. Anche in questo caso un pessimo feedback con l'utente può provocare l'inserimento di dati non appropriati rispetto allo scopo dell'applicazione. L'esempio classico è quello della richiesta di un nickname per un forum. Qualcuno potrebbe non realizzare immediatamente che quel dato verrà poi usato per identificarlo pubblicamente.
  1. Usare caratteristiche sistema-centriche. Troppe applicazioni mostrano i propri "panni sporchi" offrendo funzionalità che riflettono più la visione interna dei dati del sistema piuttosto che facilitare l'approccio dell'utente. L'ideale sarebbe quello di creare delle progressive disclosure per rivelare funzioni avanzate ai soli utenti esperti che ne fanno espressa richiesta.
  1. Error Message Guidelines

Summary: Established wisdom holds that good error messages are polite, precise, and constructive. The Web brings a few new guidelines: Make error messages clearly visible, reduce the work required to fix the problem, and educate users along the way.

The guidelines for creating effective error messages have been the same for 20 years. Good error message should include:

  1. Explicit indication that something has gone wrong. The very worst error messages are those that don't exist. When users make mistakes and get no feedback, they're completely lost. Email, for example, offers several situations where explicit indication would be useful. Such as: When you send a message that gets eaten by the system and never reaches the recipient. Another good example? When you state in an email that you'll include an attachment, but forget to do so. Finally a job for that annoying paperclip: "You seem to want to attach a file to this message, but you have not done so. Would you like to attach one now?"
  2. Human-readable language, instead of obscure codes or abbreviations such as "an error of type 2 has occurred."
  3. Polite phrasing that doesn't blame users or imply that they are either stupid or doing something wrong, as in "illegal command."
  4. Precise descriptions of exact problems, rather than vague generalities such as "syntax error."
  5. Constructive advice on how to fix the problem. For example, instead of saying "out of stock," your error message should either tell users when the product will be available or provide a way for users to ask to be notified when the product is restocked.

The Web's most common error message, 404, violates most of these guidelines. I recommend that you write a custom 404 error message instead of relying on the server's built-in "page not found" message. New Guidelines The complexity of Web pages has introduced the need for a guideline that wasn't required in the old days. With a DOS interface, users type a command and the error message is displayed on the next line of the TTY. In modern GUIs, users click a command and the error message is displayed in a big dialog box in the middle of the screen, and it doesn't go away until users acknowledge it. On the Web, however, error messages are often hidden as modest text on an overloaded page, leading to a new guideline: Error messages should be

  1. Visible and highly noticeable, both in terms of the message itself and how it indicates which dialogue element users must repair.

I have frequently observed users make a mistake in a Web form, only to get exactly the same form back from the server with no visible indication of what went wrong. Often, a small error message appeared on the top of the page, but since users look at the page's actionable part first (i.e., the area with the form fields), they don't typically notice the error.

A related design flaw is to indicate an error state solely by turning the field label red. This violates one of the oldest and simplest rules for making technology accessible to users with disabilities: Never use color as the only encoding mechanism; always include redundant cues that color-blind users can see.

Two other guidelines can make the error situation less unpleasant for users:

  1. Preserve as much as the user's work as possible. Let users correct errors by editing their original action instead of having to do everything over again. For example, in presenting search results, show a search box with the user's original query terms to facilitate revisions. If no hits were found, let users search a wider scope with a single click.
  2. Reduce the work of correcting the error. If possible, guess the correct action and let users pick it from a small list of fixes. For example, instead of just saying "city and zip code don't match," let users click on a button for the city that matches the zip code they entered.

Opportunity to Educate Users Finally, you probably already know Nielsen's First Law of Computer Documentation: people don't read it. This finding is even stronger for websites, where users truly shy away from any reading that is not essential to their task. Click on Help? Never.

Users read system documentation only when they are in trouble (that's the Second Law). They are particularly attentive when they want to recover from an error. Given this, you can use error messages as an educational resource to impart a small amount of knowledge to users. Of course, error messages should be brief and to the point, as should all Web content. However, error messages can still teach users a bit about how the system works and give them information they need to use it better. To further that end, the Web's underlying technology makes another guideline possible:

  1. Hypertext links can be used to connect a concise error message to a page with additional background material or an explanation of the problem. (Don't overdo this, though.)

linee guida UI

Consistency in interaction: make users learn once, consistency solidifies learning. Users will expect interaction elements to look, behave and be found in the same way throughout the site. If consistency is taken away, the user is forced to learn something again making your site that much harder to use. Making things inconsistent has value only when you want to get things noticed. With great power comes great responsibility: break only when it makes sense to do so.

Another means of getting things noticed is contrast. Use color to favor your design and communication strategy.

Go for convention. Semiotics (the study of creating meaning in communication) explains how conventions are established socially as a tacit agreement to decypher the code that communication builds upon. Straying from convention means your user will have difficulty in understanding your message, which could lead to drop offs.

For example: the color red is associated with danger and prohibition as established by social convention. Talking about the environment in red colors will confuse users and distract from the message trying to be communicated.

Strip down forms to the absolute bare minimum. If you have optional fields don't include them in a signup form, set them aside for a later step within your app. Each field you ask for runs the risk of making your visitors turn around and give up. Sign ups should be as frictionless as possible.

Repeat info if the user has already input it earlier with smart defaults. By no means should the user have to repeat themselves (unless it's a matter of security, like passwords or credit card numbers).

Fast loading and reacting times: help users with a loading icon or a task that'll keep their mind off of the loading screen. Feedback is important even while the screen is loading.

Use animations and transitions instead of showing changes instantly. As elements respond to a user's interactions, it might be easier for them to understand what just happened if the element transitions into view with time. Feedback is just as important when calling out a menu, bringing out a pop up, shifting and moving elements around, etc. A built in intentional delay in the form of an animation helps understand changes.

Extra padding instead of overcrowding elements.

Not necessarily UI but general advice: say no to stock photos. People smiling for no obvious reason undermine trust. Don't fake it. Also, stock photos give the impression that the photographic choice was made in a hurry and without much care. Bespoke photography and better, more realistic shots will connect with your users in a much more intimate way and create a feeling of trust and proximity.

10 Usability Heuristics for User Interface Design

https://www.nngroup.com/articles/ten-usability-heuristics/

Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

(Read full article on preventing user errors.)

Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

(Read full article on recognition vs. recall in UX.)

Flexibility and efficiency of use Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue 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.

Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

aesthetic-usability effect

Attractive Things Work Better The aesthetic-usability effect refers to users’ tendency to perceive attractive products as more usable. People tend to believe that things that look better will work better — even if they aren’t actually more effective or efficient.