Usabilità del software aziendale: quando il dipendente è un computer e il mouse una scorciatoia, ma non da tastiera

Uno scenario aziendale molto diffuso

Senza soffermarmi sulla definizione generale di usabilità (basta vedere la voce su Wikipedia per farsi un’idea) voglio discutere di un particolare e preciso ambito dell’usabilità del software: quello aziendale. Di qui in avanti per “usabilità” intenderò solo quella del software.

Quando si parla di usabilità, spesso non lo si fa dal punto di vista delle diverse modalità d’uso. Si possono distinguere le modalità d’uso per frequenza (intensiva o sporadica) e per oggetto d’uso (sistema operativo o applicazione). Ad esempio il sistema operativo del proprio telefono è usato frequentemente. Uno invece usato occasionalmente potrebbe essere quello di un computer portatile preso in prestito che abbia un sistema operativo diverso da quello che si usa di solito. Un’applicazione usata frequentemente potrebbe essere un motore di ricerca su internet o un programma di videoscrittura. Mentre un’applicazione usata occasionalmente potrebbe essere un sito web della pubblica amministrazione per espletare un adempimento una tantum o un software desktop procurato appositamente per risolvere un problema contingente. In ciascuno di questi scenari i progettisti potrebbero aver scelto di dosare opportunamente il tasso usabilità. Chi vende un sistema operativo commerciale ha tutto l’interesse a renderlo molto usabile e quindi attraente. Lo stesso utilitaristico ragionamento dicasi per un’applicazione come un motore di ricerca, un sito di commercio elettronico o un programma di videoscrittura. La pubblica amministrazione potrebbe invece non avere la stessa sensibilità quando rilascia un applicativo a favore della cittadinanza perché non c’è di mezzo un profitto “diretto” e soprattutto perché c’è una sorta di monopolio. A seguire farò dei ragionamenti dai quali escludo le micro aziende, che sono assimilabili al mercato dei “consumatori”. Infatti, dato il limitato giro di affari, non potendosi permettere di fare scelte sconsiderate, ove possibile le micro aziende hanno un occhio di riguardo sull’usabilità dei software ai quali si affidano.

Fatta eccezione per i sistemi operativi e i programmi di “office automation”, che la curano molto per i motivi già enunciati, nell’ambito di aziende da decine di dipendenti in su, l’usabilità viene spesso penalizzata. Talvolta perché ci si imbatte in fornitori di software monopolisti e molto più spesso perché il monopolio lo si crea internamente: una minima parte dell’azienda (i vertici) domina e, di fatto, imbriglia la restante parte con scelte basate su criteri politici che spesso non contemplano aspetti tecnici importanti come l’usabilità.

La circostanza più ovvia accade in regime di monopolio o di quasi-monopolio esterno. Se c’è un fornitore di un software molto specialistico che non ha concorrenti o ne ha, ad esempio, uno solo, a quel punto l’usabilità è lasciata al suo buon cuore o alla fortuna (insieme ad altri aspetti come la sicurezza, ma è un altro discorso). Meno ovvio è che se il software viene commissionato ad una società di fiducia di un dirigente aziendale (in perfetta buona fede perché la fiducia è un criterio di scelta che in genere funziona) o se, ancor meglio, il software è fatto in casa dall’azienda stessa che, tramite un proprio dirigente, lo commissiona al comparto IT interno, allora capita che l’usabilità diventi secondaria.

Ma perché non succede mai una rivolta da parte degli utenti che hanno a che fare con software aziendali poco usabili? I motivi sono principalmente due. Il primo è un motivo politico e giuridico: l’azienda impone l’uso di determinati software, il lavoro in azienda è subordinato e in quanto tale i dipendenti devono usare quei software. Punto e basta. Il secondo è un motivo tecnico, che ha anche pesanti effetti collaterali nel sentire comune sull’usabilità: con l’abitudine e la frequenza d’uso quotidiana ed intensiva, si impara ad usare anche un software non usabile! Quali sono gli effetti collaterali di tutto ciò? L’assuefazione, innanzitutto, che non permette più di distinguere un software non usabile da uno usabile e apprezzare gli innumerevoli vantaggi di quest’ultimo. L’insipienza tecnologica che smorza la consapevolezza delle reali potenzialità di un computer: l’utente si abitua a pensare che non ci sia nulla di strano se per andare dal punto “A” al punto “B” il computer attraversi un groviglio di curve anziché una semplice retta. L’improduttività, poiché un software poco usabile in genere produce meno di quanto potrebbe. Il logorio mentale, perché un software poco usabile richiede più attenzione e concentrazione da parte dell’utente rispetto ad uno usabile, anche se per abitudine l’utente non se ne accorge. Il logorio fisico, perché un software poco usabile potrebbe richiedere molti movimenti degli arti, del capo, degli occhi etc. più del necessario. L’incremento degli errori, poiché un software non usabile demanda all’utente alcuni calcoli che potrebbe fare da solo. Le convinzioni errate, poiché un software non usabile spesso ha schemi operativi non uniformi e omogenei per cui l’utente si potrebbe convincere che una certa operazione “si faccia sempre in quel modo” (magari sbagliato) o che un’altra operazione “non la si possa fare” mentre magari si può (in un modo diverso da come si aspettava). Così via dicendo, per logica si possono enunciare anche molti altri problemi.

Quindi, riassumendo, se si curasse per bene l’usabilità, un’azienda ne beneficerebbe sia direttamente, poiché farebbe leva su risparmi/profitti, sia indirettamente, poiché aiuterebbe a prevenire errori di lavorazione, disservizi ai clienti e ripercussioni negative sulla salute e sull’umore dei lavoratori. Dubbio più diffuso: quanto costa al programmatore implementare bene l’usabilità? Probabilmente un tempo pari o, al peggio, poco superiore. L’usabilità implica la razionalizzazione dei processi: se in fase di analisi occorre impiegare più tempo, in fase di implementazione si recupera tutto e forse se ne guadagna. Ma se anche dovesse volerci molto più tempo e se anche 1 minuto in più di lavoro di un programmatore equivalesse a 1 decimo di secondo in meno di lavoro dell’utente finale ne varrebbe la pena? Per il programmatore 1 minuto è relativo al singolo programma che viene sviluppato una singola volta, quindi vale per sempre 1 minuto in più di lavoro, mentre il decimo di secondo è relativo a tanti giorni di lavoro di tanti utenti, quindi diventa 1, 10, 100, 1000 minuti in meno, a seconda dei casi e, al netto di maggiori costi, il guadagno per l’azienda è sempre notevole.

Ciò premesso, a seguire tratto due aspetti dell’usabilità, tra i tanti possibili, nei quali in ambito aziendale trovo sempre margini sconfinati di miglioramento, con tutti i vantaggi del caso: la prevenzione degli errori e la rapidità d’uso.

Prevenire gli errori e il dipendente-computer

Un mio collega di lavoro mi raccontò un aneddoto emblematico. Decenni fa in un’azienda di medie dimensioni c’era un software che serviva ad effettuare un calcolo di rendicontazione importante e delicato. Tale software era stato sviluppato internamente all’azienda e doveva essere avviato l’ultimo giorno lavorativo di ogni mese, pertanto c’era una procedura che eseguiva la pianificazione dell’avvio chiedendo di inserire la data prestabilita. Per prudenza, veniva richiesto all’utente almeno due volte di confermare la correttezza di tale data prima di andare avanti. Dopo qualche tempo uno dei programmatori pensò di prevenire possibili errori, per cui integrò la procedura di pianificazione con un passaggio finale nel quale, in caso di immissione di una data sbagliata, compariva il messaggio “attenzione l’ultimo giorno lavorativo del mese non è quello che hai inserito ma è quest’altro: xx/xx/xxxx”. Col senno di poi, tanto valeva che la procedura facesse tutto da sola!

Dato un flusso di lavoro, ci sono vari schemi di interazione uomo-macchina con cui si possono gestire gli errori. L’episodio che ho raccontato è ascrivibile allo schema 1-2-2-2 della tabella sotto riportata che, comunque sia, non è il peggiore possibile.

In questa tabella ho selezionato quattro aspetti importanti della gestione degli errori nelle interfacce e, per ciascuno di questi, ho elencato le possibili modalità operative ordinandole dalla peggiore alla migliore. Lo schema peggiore quindi è 1-1-1-1, che non di rado è diffuso presso aziende che mantengono software datati perché considerati robusti e affidabili. Quest’ultimo schema però è deleterio sotto molti aspetti.

1. Richiedere dati non essenziali. Ciò denota pigrizia o incapacità del programmatore ed è la principale causa di esposizione agli errori: i dati non essenziali non devono mai essere richiesti! Quale che sia l’ultimo giorno lavorativo del mese lo si sa già. Se occorre scegliere tra una o più opzioni, non tutte compatibili tra loro, man mano che si selezionano è opportuno disattivare quelle incompatibili tra le rimanenti piuttosto che mostrare un errore finale del tipo “Attenzione, la scelta A è incompatibile con le scelte B e C!”. A meno che non si tratti di un software di quiz, se un dato lo si conosce già lo si va a prendere direttamente dal database, non lo si chiede all’utente, il quale può benissimo sbagliare a inserirlo (ad esempio a partire dal nome di una località, se unico, si può estrapolare univocamente il codice di avviamento postale). E così via con una serie di prassi che sembrano scontate da applicare ma, facendo mente locale, ci si accorge essere disattese piuttosto di frequente.
2. Non prevenire gli errori. Ciò è tra le cause più frequenti di perdita di tempo. Ad esempio ci sono sistemi che lanciano lunghe e complesse elaborazioni dando come unica risposta “elaborazione cominciata”. Sarà poi l’utente a doverne verificare successivamente l’esito, attraverso un’apposita funzionalità di interrogazione. Se l’utente sa che mediamente la procedura impiega venti minuti, questi si traducono in una pari perdita di tempo qualora i parametri iniziali da lui inseriti fossero errati. Ad esempio se tra i parametri della richiesta ci fosse un intervallo di date (da giorno xx/xx/xxxx a giorno yy/yy/yyyy), sarebbe meglio verificare istantaneamente se la data finale sia pari o successiva alla data iniziale ed anche se entrambe le date siano esistenti. Se alcuni dei parametri richiesti fossero derivabili da altri (ad esempio se un utente ha un numero massimo di scelte operabili, si può evitare che vada oltre il limite consentito), è bene che non sia l’uomo a fare i calcoli che dovrebbe fare il computer ma piuttosto che da esso sia guidato e supportato passo dopo passo. Il risultato di una svista iniziale è accorgersi di una fallita elaborazione dopo quei famosi 20 minuti, oramai perduti. Una via di mezzo tra la prevenzione automatica degli errori e la non prevenzione, è la modalità comunicativa cioè quando il programmatore prevede dei meccanismi meramente basati su avvisi e moniti. Ad esempio stampare a video “attenzione, inserire una data corretta nel formato xx/xx/xxxx” ma poi permettere all’utente di scrivere qualsiasi cosa e mandare avanti la richiesta. Naturalmente tutto ciò non ha grande efficacia se non in combinazione con la prevenzione automatica.
3. Non rilevare gli errori. Immaginiamo uno scenario in cui un cliente telefona ad una ditta per conoscere l’esito di un ordine che ha effettuato in precedenza. L’operatore che gli risponde chiede al cliente la data dell’ordine, il cliente non la ricorda con esattezza ma fornisce un intervallo temporale in cui è certo che sia avvenuto. Se l’operatore al telefono inserisce sul computer l’intervallo di date invertendo quella iniziale con quella finale e questo errore non viene mai rilevato, alla fine vedrà comparire “nessun ordine trovato!” e dirà all’utente che purtroppo l’ordine non è mai stato ricevuto. L’utente, a quel punto, potrebbe fare reclamo oppure effettuare un secondo ordine credendo, in fiducia, che il primo non sia andato mai a buon fine. Questo è quel che può accadere se non si rilevano mai gli errori. Se si rilevano alla fine, invece, si ottiene una perdita di tempo più o meno grande (come nel caso dei 20 minuti descritto in precedenza). L’ideale, naturalmente, sarebbe rilevare gli errori passo dopo passo in un contesto interattivo e lasciare alla fine solo quelle rilevazioni che necessitano un’elaborazione complessiva dei dati.
4. Risolvere tutto a mano. Immaginiamo che un’elaborazione, che prevede degli aggiornamenti su database, vada in errore e si blocchi a metà. Se il programmatore non ha previsto il ripristino dello stato iniziale, l’utente è costretto a ricostituirlo da sé o in altri casi, se non è possibile ritornare al punto di partenza, è costretto addirittura a comporre artigianalmente gli aggiornamenti per ottenere lo stato finale. Se invece il programmatore ha previsto il ripristino dello stato iniziale, l’utente potrebbe dover reimmettere da capo tutti i parametri che aveva inserito per eseguire l’elaborazione. L’ideale, naturalmente, sarebbe poter tornare all’inizio, trovando però nello schermo tutti i dati inseriti in precedenza, poterli rettificare se necessario e rilanciare l’elaborazione. Sembra forse la più scontata delle osservazioni ma invece capita spesso, ad esempio nei contesti di “business process management” o di “ticketing”, che una determinata “richiesta”, per la quale magari l’utente ha compilato innumerevoli campi, venga rigettata per un solo campo sbagliato e sia costretto in seguito a digitarla interamente da capo senza poter ripartire dallo stesso contenuto già compilato in precedenza.

Da questo quadro emerge che una cattiva gestione degli errori può causare i problemi più disparati, da perdite di tempo e logorio dei lavoratori fino a danni alla clientela e perdite economiche e reputazionali. Inoltre emerge che il lavoratore deve spesso sostituirsi al computer e per un computer (e anche per un programmatore) non c’è sconfitta e svilimento peggiori di questo.

Una corretta ed oculata gestione degli errori, invece, diventa una scelta strategica per un’azienda, nell’ottica di curare rapidità, profitto, reputazione e clima lavorativo. Senza perdere tempo in circostanze che non dovrebbero neanche esistere, si può così indirizzare e concentrare l’azione dei lavoratori solo sulle fasi di attività che generano valore.

Utenti rapidi, programmatori lenti: usare il mouse con cautela

Le interfacce dei computer nel tempo si sono adattate all’avvento di tanti nuovi dispositivi di immissione dati. Parlando dei più comuni e dei casi più generali (per semplificare il discorso non affronterò tematiche particolari come l’accessibilità), si è passati dall’immissione puramente da tastiera a quella mista tastiera/mouse fino a quella mista tastiera/mouse/schermo tattile (detto “touchscreen”). Lasciando perdere quest’ultima casistica, in ambito aziendale l’accoppiata più largamente diffusa rimane tastiera/mouse. Da quando esiste il mouse, però, questo ha avuto due ruoli, uno positivo e l’altro negativo, rispettivamente: evoluzione e surrogato della tastiera. Nel primo caso, ritengo che nella gestione di software che hanno a che fare con grafica, CAD e multimedialità, nonché più in generale per una rapida gestione di determinate funzionalità visuali, come il ridimensionamento di porzioni di schermo o la selezione di uno o più oggetti grafici tra una miriade presenti in una schermata, il mouse offra vantaggi a non finire. Quando invece viene usato come salvagente da grafici e programmatori software che, grazie a lui, non “perdono tempo” a progettare interfacce usabili, si causano danni inaspettati.

Più volte in passato ho pensato di misurare l’utilizzo del mouse, in termini di quantità di click, quantità di cambi di direzione, lunghezza media dei singoli spostamenti e lunghezza totale del percorso effettuato dal puntatore sullo schermo. Il tutto per poi effettuare la comparazione con l’utilizzo della tastiera e valutare l’alternanza di questa con il mouse: quantità di cambiamenti di dispositivo e tempo medio di utilizzo dopo ogni cambiamento. Non ho mai voluto portare avanti queste misurazioni, però, perché probabilmente gli unici dati significativi che avrei potuto ricavare sarebbero stati inerenti ad aspetti sanitari non di mia competenza né di mio interesse (ad esempio tentare di studiare sollecitazioni e possibili danni ad arti e articolazioni su vari archi temporali). Sul lato invece di efficienza produttiva queste misurazioni sarebbero state superflue in quanto per capire se sia opportuno o meno usare il mouse in un determinato frangente è sufficiente usare un altro approccio, molto lineare, di seguito schematizzato.

1. L’azione da compiere richiede la digitazione di testi scritto? Tastiera.
2. L’azione da compiere richiede manipolazione grafica sullo schermo? Mouse.
3. Altrimenti tutti e due

I primi due punti riguardano gli usi “naturali” di mouse e tastiera. Usi banali come la videoscrittura o la digitazione di dati in campi testuali per la tastiera e spostamento di icone, ingrandimento di finestre, selezione di porzioni di schermo o disegno tecnico per il mouse. Più articolato è il punto 3), il discorso che sta a confine, ossia quando non è così scontato quale sia tra mouse e tastiera il dispositivo più pertinente. In ambito aziendale occorre indurre l’utente a utilizzare più possibile un solo dispositivo - per abitudine ci riuscirà - e, sommando pro e contro, sarebbe meglio fosse la tastiera. L’utente stesso si accorgerà con la frequenza di utilizzo o dai suggerimenti di qualche collega, che lo strumento migliore è la tastiera ma il programmatore di interfacce non deve creare ostacoli in tale direzione. Se posso solo cliccare “ok”, non userò mai il pulsante “invio” della tastiera. Se invece al posto di “ok” trovo “invio” ed ho la possibilità sia di cliccare su “invio” sia, soprattutto, di credere di dover premere “invio” sulla tastiera e poi questo tasto funziona davvero, il gioco è fatto. Nella stragrande maggioranza dei casi, la tastiera batterà il mouse ma purtroppo non è sempre semplice prevedere in quali casi d’uso sia davvero più efficiente la tastiera del mouse. Per questo occorre che si possano usare entrambi indistintamente e senza favoritismi. Questo dei favoritismi è il punto chiave. A tale proposito illustro due esempi:

1. Un elenco di elementi con scelta multipla. Se il programmatore mette a video un elenco di questo genere, dando la possibilità di effettuare le scelte con la tastiera tramite “tab” per scorrere in basso, “shift+tab” per scorrere in alto e “spazio” per selezionare, probabilmente l’utente tenderà ad usare il mouse. Se aggiunge un campo “seleziona tutti”, in molti casi renderà più sbrigativa l’attività sia per la tastiera sia per il mouse. Se aggiunge un motore di ricerca per filtrare gli elementi, renderà meno problematico l’utilizzo della tastiera in quanto l’utente non dovrà fare su e giù a fatica, specialmente in elenchi molto estesi. Se infine mette una barra “selezionatrice” che lampeggia lentamente sul primo elemento dell’elenco e offre la possibilità di scorrere tra gli elementi con i tasti “su” e “giù”, a quel punto la tastiera sarà pienamente equiparata al mouse e, con la pratica, lo supererà in efficienza.
2. Un campo data. Se il programmatore mette a video un campo “data” arrivati al quale (o con mouse o con tastiera) compare un calendarietto dal quale selezionare una data, costringendo l’utente a scorrerlo, probabilmente farà fatica a programmare questo calendarietto affinché sia fruibile facilmente anche da tastiera e l’utente userà il mouse. Se invece prevede che il calendarietto sia apribile a discrezione dell’utente, rendendo direttamente digitabile la data da tastiera, allora creerà un perfetto equilibrio e renderà il calendarietto un’agevolazione in più per gli utenti che non conoscono già la data da immettere ma la devono andare a ricercare in base ai criteri più comuni quali giorno della settimana, festività etc.

In generale, la tecnica per massimizzare l’uso della tastiera è quella di richiamare l’attenzione sull’uso della stessa e schematizzare le opzioni (o renderle facilmente ricercabili/selezionabili). Bisogna progettare a monte un’interfaccia che abbia equità di scelta tra tastiera e mouse e non fare, come tentano molti, a valle un’associazione di tasti di scelta rapida ad un’interfaccia pensata per un utilizzo da mouse.

Richiamare l’attenzione sull’uso della tastiera significa usare tecniche di rappresentazione grafica che rendano gli elementi dello schermo come parte di un grande documento di videoscrittura. Quindi usare costantemente elementi come cursori o barre selezionatrici, entrambi lentamente lampeggianti, per stare ad indicare implicitamente che si può interagire anche con la tastiera e l’utente, con naturalezza, si comporterà di conseguenza.

Schematizzare significa raggruppare logicamente le opzioni e definire i passaggi logici. Tipicamente lo si fa ad albero: si parte da un punto iniziale, detto radice (ma ha più senso che si pensi al tronco), a cui sono attaccati i rami principali: poche opzioni selezionabili, quindi facilmente scorribili da tastiera o con singoli tasti di scelta rapida. Dietro quella opzione si snodano altri rami e così via ramificando. Tipicamente i menù generali di un programma sono fatti in questo modo (ad esempio “File” -> “Nuovo” -> “Documento vuoto”). Se non è possibile raggruppare logicamente le opzioni, come su lunghi elenchi di elementi con scelta multipla, si possono usare quegli accorgimenti che ho precisato nel precedente esempio n.1 (casella di ricerca, tasto per selezione totale, cursori per scorribilità da tastiera con frecce direzionali etc.).

Questi accorgimenti che:

• favoriscono l’uso dell’agilissima tastiera, unitamente allo sfruttamento di abitudinarietà degli utenti
• costringono indirettamente il programmatore a razionalizzare e sintetizzare al massimo gli schemi d’uso e logiche del software

in definitiva creano rapidità!