Archivi categoria: usabilità

Incredibile Trenitalia

Attenzione alle esigenze e ai requisiti degli utenti? Usabilità dei sistemi?

Un caso da manuale: Trenitalia.

Non voglio parlare del servizio agli utenti sui treni, inqualificabile (e non certo per colpa del personale viaggiante, poveretti).

Neppure del rinnovo delle stazioni, con il peggioramento delle condizioni per i viaggiatori (sempre meno posti a sedere, sparizione delle fontanelle, continui bombardamenti pubblicitari dai monitor, a fronte di poche e tardive segnalazioni utili).

Ciò che trovo davvero incredibile è il nuovo sistema di consultazione dell’orario e di prenotazione via internet.

Non è più possibile vedere il percorso di viaggio con le fermate intermedie.

Non è più possibile sapere se è permesso il trasporto biciclette.

Non è più possibile sapere se è previsto il trasporto di persone con handicap fisici.

Anzi, sì, è possibile. Ma solo sul sito (in italiano) delle ferrovie tedesche:
http://www.bahn.com/i/view/ITA/it/index.shtml

L’ho scoperto grazie a questo articolo.


Aggiornamento. Trenitalia torna al vecchio orario. Naturalmente, non un cenno di comunicazione agli utenti del servizio.


Motori di risposta

I motori di ricerca sono usati da molte persone come l’unico strumento in grado di fornire risposta alle proprie esigenze informative, trascurando altri metodi più efficaci. Sono generalmente usati in modo elementare, senza sfruttarne le caratteristiche più avanzate. E come se fossero LA fonte di risposta alle proprie domande.
Lo sostiene Jacob Nielsen, che evidenzia i rischi di questo approccio nell’affrontare i problemi, portando come esempio l’uso pericoloso dei motori di ricerca per ottenere informazioni sulle malattie e sui sintomi.

Nielsen, esperto di usabilità, conclude il proprio articolo con un giudizio disarmante: “For today’s Web design projects, we must design for the way the world is, not the way we wish it were. This means accepting search dominance, and trying to help users with poor research skills. […] In the long term, we should try to improve the world rather than design to suit its shortcomings.”

Bisogna progettare meglio i siti per renderli più usabili, certo, ma non basta. Diventa necessario lavorare sulla formazione delle persone, insegnando ad usare efficacemente la rete per le proprie ricerche.

Efficacia formativa dei test di apprendimento

Quanto ci ricordiamo una settimana dopo aver letto un testo scientifico?

Uno studio ha confrontato i ricordi di gruppi diversi di studenti. Un primo gruppo aveva semplicemente letto una volta il testo, un secondo gruppo lo aveva letto 4 volte, un terzo gruppo lo aveva letto 2 volte, ma dopo ognuna delle due letture aveva affrontato un test di apprendimento sugli argomenti trattati dal testo.

Gli studenti che avevano letto 4 volte ricordavano il 64% in più rispetto agli studenti che avevano letto una sola volta. Ma gli studenti che avevano sostenuto i test ricordavano il 145% in più rispetto agli studenti che avevano semplicemente letto una volta.

Lo studio, di Jeffrey D. Karpicke e Janell R. Blunt della Purdue University, è pubblicato su Science.
Sull’argomento, una nota interessante di Jakob Nielsen.

Automation Paradox

“when a Metro subway train rammed into another train in Washington, D.C. last June, designers had to confront the unpleasant reality that automation may have been the cause.
The accident, which killed nine people and injured 80, may have been rooted in a computer malfunction and the operator’s inability to manually apply the brakes quickly enough.
The Metro train accident lies at the heart of what human factors experts refer to as the “automation paradox.” As automated systems become increasingly reliable and efficient, the more likely it is that human operators will mentally “switch off” and rely upon the automated system. And as the automated system becomes more complex, the odds of an accident or mishap may
diminish, but the severity of a failure is often amplified.”

Making Automation Work“, di Samuel Greengard, in Communications of the ACM, dicembre 2009

Usabilità, requisiti e progetti agili

Jakob Nielsen è un esperto di usabilità. Nella sua newsletter Alertbox parla del rapporto tra usabilità e approcci agili. L’argomentazione di Nielsen prende l’avvio dai requisiti:

“Requirement specifications are always wrong.

At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
‘representatives’ who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it’s long been a primary usability
guideline to watch what users do, rather than listen to what they say”.

Lo saprò quando lo vedrò

Barry Boehm – Making a Difference in the Software Century

Un eccellente articolo su IEEE Computer, marzo 2008 (in realtà, si tratta di un estratto della introduzione scritta da Boehm per l’antologia dei propri scritti, pubblicata nel 2007 da IEEE CS Press-John Wiley & Sons ).


Riporto un paio di passi.

Il primo, sulla difficoltà per gli utenti di chiarire i requisiti in anticipo :

“Spesso, quando si chiede agli utenti di specificare come vorrebbero interagire con una nuova applicazione, essi rispondono “Lo saprò quando la vedrò” (IKIWISI – I’ll Know It When I See It). In questi casi, usare un modello a cascata sequenziale, specificare-prima-i-requisiti, diventa di solito la ricetta per un sistema inefficace e per un mucchio di costosi rifacimenti”.


Il secondo, sul conflitto tra punti di vista ed interessi tra gli stakeholder di progetto:

“Il fatto che ci siano molti conflitti potenziali tra i principali stakeholder significa che il progetto può entrare in situazioni in cui uno vince e un altro perde. E una situazione del genere di solito diventa una situazione in cui perdono tutti.

In situazioni simili è importante gestire le aspettative degli stakeholder, lavorare di più per assicurare che la soluzione proposta sia fattibile e adeguata agli interessi di tutti, e negoziare un insieme globalmente soddisfacente e vantaggioso di specifiche, piani e risorse, prima di procedere con lo sviluppo. Quando si negoziano i requisiti, nei momenti iniziali è meglio sostituire termini che possono essere interpretati come non negoziabili, ad esempio il termine ‘requisiti’ (cose richieste con autorità e diritto) con parole come ‘obiettivi’ e ‘scopi’.”