In questo articolo affronteremo un argomento spesso controverso: quando un'applicazione software è buona? O per dirla in un altro modo: cosa fa un buon software? Con una formulazione un po' casuale, si potrebbe dire che un'applicazione "è buona quando è utile e può fare bene ciò per cui è stata fatta". Più formalmente, l'applicazione dovrebbe avere un alto grado di facilità d'uso o usabilità. Per semplicità, useremo il termine inglese usability per discutere questi concetti.

Hmm, cos'è esattamente l'usabilità?

Il termine usability non è sempre chiaramente definito ed è certamente interpretato in modo diverso da persone diverse. Una semplice ricerca su Internet produce una moltitudine di definizioni non sempre congruenti. L'usabilità può naturalmente essere applicata a qualsiasi oggetto fatto dall'uomo (non solo al software), ma non tratteremo qui questo argomento. Spesso ci si imbatte nel termine ergonomia del software. Quello che è certo è che l'usabilità non è misurabile su una scala assoluta ed è proprio per questo che spesso è vittima di percezioni soggettive. Ne consegue poi una serie di discussioni su chi ha ragione con la sua valutazione del software.

In questo articolo cerchiamo di andare al fondo del termine usabilità e in particolare di dare uno sguardo più da vicino alla misurabilità. Ci proveremo in modo molto semplice e distingueremo solo i seguenti tre aspetti in relazione all'usabilità di un'applicazione software:

• Ambito funzionale (cosa può fare l'utente con l'applicazione?)
• Concetto operativo (Come può l'utente fare qualcosa?)
• Tempo di risposta (Quanto velocemente l'applicazione risponde all'input dell'utente?)

Facciamo un po' di luce su questi termini qui sotto e diamo un'occhiata più da vicino a ciascuno di essi.

La gamma di funzionalità: cosa può fare la mia applicazione?

L'ambito funzionale di un'applicazione è spesso sovraccarico e non copre realmente ciò di cui l'utente ha bisogno. A cosa serve un'applicazione se non ho bisogno dell'80% delle funzioni offerte per il mio lavoro? Questa zavorra di solito non è solo da qualche parte sullo sfondo e mi è costata molto nell'acquisto .Non solo, può anche ostacolarmi nell'uso del 20% veramente utile delle funzioni. Si dice che applicazioni ben note come i prodotti Office soffrano di questa malattia: non è facile trovare statistiche concrete e corroborate, e quelle che si trovano sono certamente da prendere con le pinze. Tuttavia, si possono facilmente trovare decine di post sul web ("I 50 consigli per Word", "Impostazioni nascoste in Microsoft Office", "10 consigli pratici per Word" ecc.) i quali suggeriscono che il tipico utente di Office ovviamente lavora solo con una piccola parte delle funzioni disponibili e non conosce affatto il resto.

Una buona applicazione ha quindi il maggior numero possibile di funzioni che l'utente si aspetta e usa quotidianamente. Il termine "esattamente queste funzioni" è naturalmente definito in modo un po' diverso a seconda dell'utente, ma se immaginiamo un'applicazione aziendale che viene utilizzata da un gran numero di dipendenti nella stessa organizzazione o anche all'interno di uno steso settore aziendale, allora un denominatore comune tra loro può certamente essere identificato. Una tale applicazione aziendale deve offrire quindi quelle funzioni che supportano in modo ottimale i tipici processi aziendali. E se il prezzo è giusto, molte organizzazioni sono anche disposte ad adattare i loro processi a un prodotto standard per le poche deviazioni dall'applicazione desiderata.

Il concetto operativo: Come faccio ora di nuovo a...?

Il concetto operativo di un'applicazione determina quanto velocemente un utente può trovare e usare la funzione di cui ha bisogno per un compito. Si parla spesso dell'intuizione dell'utente o che "l'applicazione può essere azionata intuitivamente". Naturalmente, anche qui si applica il principio della soggettività: ciò che è intuitivo per una persona è complicato ed incomprensibile per un'altra, ma dopo tutto questo parametro è misurabile. La semplicità d'uso può essere misurata e valutata su un gruppo più ampio di utenti. Alle persone in prova viene semplicemente dato un compito da risolvere con l'applicazione e viene misurato quanto velocemente queste riescano a svolgerlo. In questo modo, diverse applicazioni costruite per lo stesso scopo possono anche essere confrontate tra loro quantitativamente e confrontate in qualche modo oggettivamente (poichè statisticamente). In pratica, diversi prodotti competitivi devono semplicemente affrontare il mercato. Un'operazione pilota che può essere impostata rapidamente ed è sufficientemente lunga può sicuramente aiutare.

Un buon concetto operativo è sempre coerente, cioè il più coerente possibile in tutte le funzioni: le stesse azioni sono eseguite nello stesso modo. Cercare gli oggetti, impostare le visualizzazioni, aprire e modificare elementi di dati, cancellare oggetti,... Tutto funziona sempre secondo un principio uniforme. È proprio quando si valuta il concetto operativo che diventa chiaro se gli sviluppatori dell'applicazione hanno perseguito un approccio genericamente applicabile fin dall'inizio, o se l'applicazione è semplicemente diventata un po' più grande nel corso del tempo e le funzionalità devono essere richiamate in modo diverso ancora e ancora perché semplicemente non c'è un filo comune che attraversa l'applicazione.

Il tempo di risposta: quanto tempo ci vuole ancora?

Ultimo ma non meno importante è il tempo di risposta. L'applicazione più appropriata (set di funzionalità) e intuitiva (funzionamento) perde una quantità enorme di valore e di accettazione da parte degli utenti se è lenta, e non ci vuole molto per essere considerati lenti. Almeno dal punto di vista di utenti spesso molto esigenti. Il tempo è denaro, e nessuno ha voglia di passare un sacco di tempo ad aspettare ogni giorno davanti al proprio schermo finché i dati attesi non appaiono. Alcuni secondi sono già troppo quando si tratta di una funzione che l'utente richiama ogni pochi istanti. La performance inesistente di un'applicazione è spesso la morte nelle vendite. "Per fortuna", potreste ancora dirvi, "anche il prodotto concorrente non è più veloce". Ma al giorno d'oggi, quando le nuove tecnologie si sostituiscono quasi ogni anno, le larghezze di banda sulle reti e soprattutto su Internet sono sempre migliori e le prestazioni dei computer raddoppiano circa ogni due anni (secondo Moore), non ci sono più scuse per le scarse prestazioni.

Come fa un'applicazione software a raggiungere un'alta usabilità?

Si parla spesso di progettazione centrata sull'utente o, in inglese, user-centered design (UCD). Con questo intendiamo l'inclusione del futuro utente nell'intero processo di sviluppo. Idealmente, questo inizia con la prima descrizione dell'applicazione futura, cioè nell'ingegneria dei requisiti: cosa dovrebbe essere in grado di fare l'applicazione (ambito funzionale)? Dalla nostra esperienza, una descrizione puramente testuale di questi requisiti è di scarsa utilità. Per quanto riguarda le formulazioni in prosa i partecipanti al progetto sono rapidamente d'accordo, ma il nocciolo della questione risiede nel design della schermata. Questo è il momento in cui l'utente si siede effettivamente davanti allo schermo e fa ciò per cui l'applicazione è stata costruita. Il modo migliore per iniziare è con semplici schizzi su una lavagna bianca o in un programma di disegno adatto. All'occorrenza, anche PowerPoint va bene. In seguito, questi disegni di schermate devono essere fusi in mock-up cliccabili, in modo che gli utenti possano giocarci e sviluppare la sensazione di usabilità. Solo in una fase successiva del progetto può iniziare la costruzione di un prototipo: qui è dove la performance, cioè il tempo di reazione dell'applicazione, entra in gioco per la prima volta. Naturalmente, questo diventa veramente evidente (o no) solo quando viene simulata la struttura quantitativa finale (numero maggiore di utenti, stock di dati realistici, latenza di rete reale, ecc.

C'è abbastanza letteratura sul processo di sviluppo di un'applicazione software e l'inclusione degli utenti. In questo caso, ci asteniamo persino dal cominciare con una lista di riferimenti. Tuttavia, torneremo volentieri sulle buone metodologie possibili e processi di sviluppo in un futuro articolo. Restate sintonizzati.