Uno degli esempi mostrati ieri al seminario Formez all’Università di Bari sulla qualità dei servizi web illustra bene un problema di molti servizi progettati e programmati in fretta e furia: etichette verbali ridondanti, ambigue e incomprensibili, che rendono difficile per l’utente capire da dove cominciare, cosa si può fare e come farlo.
L’applicativo online cui si riferisce la schermata qui sopra ripete un numero di volte eccessivo anche per un profano il termine “fattura” nei propri menu. Lo ripete varie volte anche nelle altre schermate, anche mettendolo come titolo di una nuova pagina. Un po’ come per rassicurarci che l’applicativo serve proprio a fare la fattura. D’altra parte lo abbiamo acquistato per quello.
E’ davvero necessario?
Il problema però non è la ridondanza: è che questa ridondanza è confondente. Ostacola la comprensione invece di – come suppone forse il progettista – facilitarla.
D’accordo, per fare la fattura c’è una procedura guidata. Ma a che servono allora tutte le altre voci? Esiste anche una procedura non guidata, da menu? Sono quindic’anni che faccio fatture: devo essere considerato uno che va guidato, o posso rivolgermi al menu in alto?
Rendere la pagina di atterraggio direttamente operativa
Meglio ancora: non si poteva dedicare meno spazio alle informazioni, poche e poco rilevanti, e far iniziare direttamente la fattura in pagina, offrendo un boxino con link alle ultime fatture fatte?
Questo avrebbe aumentato l’efficienza e la comprensibilità, riducendo enormemente la necessità stessa di ricorrere ai menu. Sappiamo che non è questo il modo in cui i programmatori vengono istruiti a pensare: poiché le procedure sono rigidamente separate dal punto di vista del codice, è logico per loro presentarle su pagine separate, raggiungibili da inutili (per l’utente) pagine hub come questa.
Applicativi come WordPress dovrebbero aver insegnato che la pagina d’atterraggio dovrebbe già essere operativa. Ma, certo, quello è stato il risultato di test di usabilità…
A ogni etichetta il suo scopo
Una delle cose sicure che sappiamo dalla ricerca cognitiva è che le etichette verbali competono fra loro per la scelta dell’utente, e in particolare competono in relazione all’obiettivo che l’utente persegue in quel momento. Almeno due modelli cognitivi, il Cognitive Walkthrough for the Web e l’Information Foraging, sottolineano questo genere di problemi, offrendo motori di “stima semantica” per scegliere meglio le label. In ogni caso concludono che le label devono essere chiaramente distinte fra loro. Il che significa una cosa sicura:
Non usate la stessa radice semantica per label diverse.
E’ uno dei motivi per cui i puffi non sono mai stati chiamati a progettare interfacce, e vivono ancora nei boschi. Magari piacerebbe anche a noi, ma per il momento, qui siamo chiamati a stare. Teniamone conto.
Estendere queste conoscenze ai servizi web
Nell’organizzazione dei siti informativi, a forza di ripeterlo, questo aspetto comincia a essere considerato. Le applicazioni e i gestionali web che servono a consentire transazioni hanno problemi più simili ai software che ai siti informativi: ma questo problema rimane, declinato in modo differente. Le etichette devono segnalare oggetti o azioni. E devono essere scelti non sulla base di ciò che in quel momento sembra logico al progettista (di solito in realtà un programmatore che ha scadenze strette e nessun incentivo a perder tempo su tali questioni), ma di ciò che risulta comprensibile a chi lo utilizza. Evitando voci potenzialmente troppo simili.
Il solito problema: il processo
Questo apre un altro problema, il solito: quale spazio di progettazione hanno avuto questi gestionali? Quali processi hanno seguito, quali dovrebbero seguire? Quali verifiche? Argomenti già trattati, ma su cui pufferò in futur… pardon… tornerò in futuro.