Sulla stessa pagina di Cadulis, due pulsanti avviavano la stessa azione. Non avevano lo stesso nome. Non ce ne eravamo accorti, perché conosciamo il nostro strumento a memoria, ed è proprio questo il problema. L’ergonomia di un software si valuta presso chi lo utilizza.
Da ottobre 2024, l’agenzia di Metz UX-KEY osserva l’uso reale della nostra applicazione e ci invia ogni mese un rapporto. Vi mostriamo come funziona il loro dispositivo e cosa ci ha fatto correggere, prima di concludere con le domande di ergonomia da porre a qualsiasi editore prima di scegliere il vostro software.
Perché l’ergonomia di un software per il field service conta doppio
Uno schermo mal progettato, in ufficio, si tollera. Sul campo, il tecnico tiene il telefono con una mano, a volte con i guanti, spesso tra due interventi e con il cliente che aspetta. Cercare un pulsante, non ha tempo. Nemmeno per ripetere un inserimento sbagliato.
E poi c’è tutto ciò che l’ufficio non vede: lo schermo sotto il sole su un tetto, la rete che si indebolisce in cantina, un telefono personale non proprio nuovo con i caratteri ingranditi.
Resta la ripetizione. Tre secondi persi a ogni chiusura di intervento, venti volte al giorno, moltiplicati per una squadra e per un anno, alla fine pesano.
Quando lo strumento irrita, viene aggirato. Il tecnico prende appunti su un taccuino, richiama l’ufficio, invia una foto via SMS. Il software è installato, ma non viene più usato. Ne parlavamo nel nostro articolo sulla digitalizzazione delle squadre sul campo e la resistenza al cambiamento; una buona parte di questa resistenza deriva da dettagli di ergonomia software che nessuno ha mai preso il tempo di osservare.
Il problema è che un editore è poco adatto a notarli. Sa dove si trova ogni funzione, non sbaglia mai pulsante. Da qui l’interesse di uno sguardo esterno, che parte dai dati di utilizzo.
Come funziona l’audit UX di UX-KEY
UX-KEY è un’agenzia di Metz, fondata nel 2019, specializzata nell’esperienza utente dei software online per le aziende (CRM, ERP, strumenti HR).
Uno script che osserva l’uso reale
Uno script di raccolta viene installato sull’applicazione. Registra i dati di interazione per tracciare la navigazione degli utenti. Secondo UX-KEY, raccoglie solo dati di carattere non personale, e l’agenzia pubblica le proprie carte di conformità al GDPR e al regolamento europeo sull’IA.
Il brevetto della loro tecnologia di analisi dei percorsi, depositato nel 2020, riguarda il monitoraggio in tempo reale dei cambiamenti di struttura delle pagine. Questo aspetto è importante per uno strumento come il nostro, dove le schermate si ricompongono continuamente (un planning che si ricarica, una scheda di intervento che si apre sopra). Il risultato assume, tra l’altro, la forma di mappe di calore, che mostrano dove gli utenti cliccano.
Un’analisi assistita, conclusioni umane
Un’IA aiuta a ordinare questi dati. Ma l’audit vero e proprio viene svolto dai designer UX dell’agenzia, che interpretano i comportamenti e redigono le raccomandazioni.
Un rapporto al mese, un tema per rapporto
Ogni mese riceviamo un rapporto dedicato a un solo argomento, ad esempio l’ergonomia di un percorso, l’accessibilità, la visualizzazione su mobile o la redazione delle etichette. I punti di attrito vengono elencati e le raccomandazioni sono prioritarizzate.
Un audit unico spesso finisce in un cassetto. Questo ritorna sul tavolo ogni mese, e bisogna decidere (correggere, pianificare, o assumersi la responsabilità di lasciare così com’è).
Non siamo gli unici software per il field service in questa situazione. UX-KEY racconta ad esempio come ha reso più intuitivo il monitoraggio dei cantieri e dei ticket di manutenzione di DriveIM, una piattaforma di gestione tecnica per il settore immobiliare.
Cosa ha corretto l’audit nell’ergonomia del nostro software
Niente di spettacolare, solo difetti che ormai nessuno di noi notava più.
Due pulsanti, due nomi, una sola azione
Su alcune pagine, due pulsanti avviavano la stessa azione con due etichette diverse. Noi lo sapevamo. Un utente, invece, vede due nomi e cerca due funzioni: si chiede quale scegliere, esita, o peggio, pensa che gli manchi una fase.
Le regole di accessibilità del web stabiliscono lo stesso principio a livello di sito. Il criterio 3.2.4 delle WCAG 2.2 richiede che i componenti che hanno la stessa funzione siano identificati in modo coerente. Abbiamo armonizzato le etichette.
Pulsanti troppo vicini
Altrove, i pulsanti erano posizionati così vicini tra loro che un clic poteva cadere su quello accanto. Con il mouse, può andare. Con il pollice, in una tromba delle scale poco illuminata, a volte si attiva un’azione indesiderata.
La norma fornisce anche qui un riferimento. Il criterio 2.5.8 delle WCAG 2.2, di livello AA, stabilisce un target di almeno 24 pixel CSS per lato, o uno spazio sufficiente tra due target più piccoli. Abbiamo rivisto la spaziatura dei pulsanti interessati.
Perché nessuno ce lo aveva segnalato
Non si chiama il proprio editore per dire che si è esitato due secondi davanti a un pulsante, o che si è cliccato accidentalmente una volta nella settimana. Si brontola, si riprova, e ci si abitua. Questo tipo di attrito si legge soprattutto nei dati d’uso, quando qualcuno si prende il tempo di guardarli.
Cosa non sostituisce un audit UX
Un audit di ergonomia software ha i suoi limiti. Mostra dove gli utenti si bloccano; non dice sempre perché, né di cosa avrebbero bisogno e che ancora non esiste.
I feedback diretti restano quindi insostituibili. Un tecnico che spiega che inserisce le ore la sera perché non ha tempo sul posto insegna qualcosa all’editore che nessuna mappa di calore potrà mai mostrare. Anche la formazione mantiene il suo ruolo, anche con uno strumento ben progettato.
Resta da decidere. Correggere un difetto di ergonomia costa tempo di sviluppo, che non andrà altrove. Il rapporto dà le priorità, il team decide.
Cinque domande di ergonomia da porre prima di scegliere il vostro software
Non serve essere designer per valutare l’ergonomia di un software per interventi. Durante una dimostrazione o una prova, queste cinque domande bastano per fare la differenza.
- Un'azione ha lo stesso nome ovunque? Scorrete tre o quattro schermate. Se "Convalidare", "Salvare" e "Terminare" sembrano fare la stessa cosa, i vostri tecnici esiteranno.
- I pulsanti sono facilmente selezionabili con il dito? Fate la demo su uno smartphone, non sul computer dell’editore. Provate con il pollice, usando una sola mano.
- Quante schermate sono necessarie per chiudere un intervento? Contatele. Ogni schermata in più sarà vissuta cento volte a settimana.
- Cosa succede in caso di errore? Un’azione distruttiva deve richiedere conferma, ed un errore di inserimento deve poter essere corretto senza dover ricominciare da capo.
- Come fa l’editore a sapere cosa infastidisce i suoi utenti? È la domanda più rivelatrice. Una risposta vaga ("i nostri clienti sono soddisfatti") vale meno di un metodo: feedback degli utenti, dati di utilizzo, audit esterno.
Un consiglio in più. Fate testare lo strumento da uno dei vostri tecnici, non solo dalla persona che firmerà il contratto. In dieci minuti di prova, individuerà ciò che la dimostrazione meglio preparata non mostra, e saprete se lo utilizzerà davvero una volta sul campo.
Siete voi stessi editori di un software? La guida all’UX design delle interfacce SaaS pubblicata da UX-KEY dettaglia il percorso, dalla ricerca utente ai test.
Per il resto della scelta (funzionalità, prezzo, impegno), la nostra guida su come scegliere il miglior software di gestione degli interventi passa in rassegna gli altri criteri.
Ergonomia del software: un cantiere permanente
Ogni nuova funzione aggiunge un pulsante, una schermata, un’etichetta, e quindi un’occasione per confondere ciò che era chiaro. Il rimedio si riassume in poche parole: osservare regolarmente come lo strumento viene realmente utilizzato, e correggere le piccole cose prima che diventino abitudini di aggiramento.
Noi lo facciamo con UX-KEY, un report al mese. E se volete giudicare voi stessi, chiedeteci una dimostrazione su smartphone, con i vostri stessi interventi.
