Portare un migliore processo di progettazione alla tua organizzazione

In qualità di designer e ricercatori dell'esperienza utente (UX), la lamentela più comune che sentiamo dagli utenti è:

"Perché non pensano a ciò di cui ho bisogno?"

In effetti, molte organizzazioni hanno team dedicati a fornire ciò di cui utenti e clienti hanno bisogno. Sempre più sviluppatori di software sono ansiosi di lavorare con i progettisti UX per codificare interfacce che i clienti utilizzeranno e capiranno. Il problema è che i progetti software complessi possono facilmente impantanarsi in priorità contrastanti e confusione su cosa fare dopo.

Il risultato è un design scadente che ostacola la produttività. Ad esempio, l'efficienza nel settore sanitario è ostacolata dalle cartelle cliniche elettroniche (EMR). I reclami su questi sistemi software sono innumerevoli. Il dottor Steven Ugent, un dermatologo con sede a Boston e alunno della Yale Medical School, non fa eccezione.

Dal 2010, il Dr. Ugent ha utilizzato due sistemi EMR: prima del 2010, ha terminato il lavoro prontamente alle 5:15 ogni giorno. Da quando lui e i suoi colleghi hanno iniziato a usare gli EMR, in genere lavora da mezz'ora in più a 1 ora e mezza la sera. “Non conosco nessun medico che sia soddisfatto del proprio sistema di cartelle cliniche. La cosa pazzesca è che ero molto più efficiente quando usavo carta e penna”.

I sistemi EMR sono goffi, rigidi e difficili da personalizzare. Ugent, ad esempio, non può incorporare foto direttamente nelle sue note del grafico. Invece, deve aprire la cartella con la foto della talpa e poi aprire una cartella diversa per vedere il testo. Questa configurazione è particolarmente ingombrante per i dermatologi che fanno molto affidamento sulle foto durante il trattamento dei pazienti.

Ugent riassume sinteticamente il problema con gli EMR:

“Le persone che lo progettano [il sistema EMR] non capiscono il mio flusso di lavoro. Se lo facessero, progetterebbero un sistema diverso”.

I medici non sono soli nella loro frustrazione per il software goffo. Consumatori e professionisti di tutto il mondo presentano reclami simili:

"Perché non riesco a trovare quello che mi serve?"

"Perché lo rendono così difficile?"

“Perché devo creare un login quando voglio semplicemente acquistare questo prodotto. Sto dando loro dei soldi. Non è abbastanza?”

Un importante contributo al software goffo sono i processi di progettazione imperfetti. In questo articolo, illustreremo quattro problemi del processo di progettazione e spiegheremo come affrontarli.

1. Complessità
2. Sindrome da rilascio successivo
3. Tempo insufficiente per le iterazioni di progettazione
4. Cedere il controllo a fornitori esterni

1. Complessità

La scalabilità, le molteplici parti interessate e la necessità di un codice sofisticato sono tra i molti fattori che contribuiscono alla complessità dei grandi progetti software.

A volte, tuttavia, vengono trascurate leggi e regolamenti complessi. Ad esempio, l'assicurazione è fortemente regolamentata a livello statale, aggiungendo un livello di complessità per le compagnie assicurative che operano in più stati. Le banche e le cooperative di credito sono soggette a regolamentazione mentre le utility devono rispettare le leggi ambientali statali e federali.

I prodotti sanitari e il software soggetti alle normative FDA rappresentano una sfida ancora più grande. Il problema non è che i regolamenti siano irragionevoli. La sicurezza è fondamentale. I problemi sono il tempo, il budget e la pianificazione necessaria per soddisfare i requisiti della FDA.

Come spiega Jeff Horvath, Ph.D., un consulente UX con una vasta esperienza nel settore sanitario: “Questi requisiti aggiungono un paio di ordini di grandezza al rigore per la scrittura di protocolli di test, configurazione dei test, raccolta di dati, analisi, controlli di qualità e ottenere l'approvazione per condurre la ricerca in primo luogo. Ad esempio, un singolo ciclo di test di usabilità passa da sei settimane (un periodo di tempo ragionevole per un test di usabilità standard) a sei mesi. E questo con un unico ciclo di test di usabilità . Spesso sono necessari due o più cicli di test.

Questo livello di rigore è un campanello d'allarme per le aziende che non hanno mai lavorato con la FDA. Più di una volta, Horvath ha affrontato dure conversazioni con clienti impreparati alle tempistiche estese e al budget aggiuntivo necessario per soddisfare i requisiti della FDA. È difficile, ma necessario. "Paga essere scrupolosi", afferma Horvath. Nel 2018 la FDA ha approvato solo l'11% delle richieste pre-commercializzazione.

Le richieste di ricercatori, progettisti e sviluppatori sono più elevate per i software sanitari che richiedono la conformità FDA rispetto ai prodotti software tradizionali. Per esempio:

• Un ricercatore UX può condurre solo una o due sessioni di test di usabilità al giorno rispetto alle più comuni da cinque a sei sessioni al giorno per il software standard.
• I designer di UX devono rimanere iper-attenti a ogni aspetto dell'interazione dell'utente con il software. Anche un'interazione confusa potrebbe indurre un medico a commettere un errore che potrebbe mettere a repentaglio la salute di un paziente. Per lo stesso motivo, i progettisti dell'interfaccia utente devono disegnare interfacce che rimangano fedeli a ogni interazione.
• Un lasso di tempo più lungo per i test di progettazione e usabilità significa che gli sforzi di codifica dello sviluppatore devono essere pianificati con attenzione. Gli sviluppatori esperti e ben intenzionati sono spesso desiderosi di modificare il codice non appena diventano disponibili nuove informazioni. Sebbene questo approccio possa funzionare in organizzazioni ben praticate nell'iterazione rapida, comporta dei rischi durante la progettazione e la codifica di sistemi complessi.

La mancata gestione della complessità può avere conseguenze fatali come è successo quando Danielle McCray è stata ricoverata al Tallahassee Memorial Hospital mentre stava per partorire. Per alleviare il suo disagio, gli operatori sanitari l'hanno collegata a una macchina per l'analgesia controllata dal paziente, una pompa per infusione programmabile.

Otto ore dopo McCray è stato dichiarato morto per overdose di morfina. Un fattore importante in questa tragedia è stato il design imperfetto della pompa di infusione utilizzata per somministrare i farmaci. La pompa ha richiesto 27 fasi di programmazione. L'incapacità di affrontare tale complessità progettando un'interfaccia utente più intuitiva ha contribuito a una morte non necessaria.

Soluzione

La soluzione è riconoscere e affrontare la complessità Questo punto suona logico. Tuttavia, come spiegato sopra, le complicate normative della FDA spesso sorprendono i leader delle aziende. La negazione non funziona. La mancata pianificazione significa che la tua organizzazione probabilmente rientrerà nell'89% delle richieste pre-commercializzazione respinte dalla FDA nel 2018.

Quando conducono i test di usabilità, i ricercatori dell'esperienza utente devono intraprendere tre passaggi per gestire la complessità associata alle normative FDA:

1. Il moderatore (la persona che esegue il test di usabilità) deve essere iper-attento. Ad esempio, se una scansione MRI richiede che un tecnico segua una rigorosa sequenza di passaggi durante l'utilizzo del software associato, il moderatore deve osservare attentamente per determinare se il partecipante segue le istruzioni alla lettera. In caso contrario, l'attività viene valutata come un errore, il che significa che sia il design dell'interfaccia che la documentazione associata richiederanno modifiche;
2. Il moderatore deve anche tenere traccia delle chiamate chiuse. Ad esempio, un partecipante potrebbe inizialmente eseguire i passaggi fuori ordine, scoprire l'errore e recuperare seguendo la sequenza corretta. La FDA considera questo un quasi incidente e il moderatore deve segnalarlo come tale;
3. Il moderatore deve anche valutare le conoscenze del partecipante. Crede di aver seguito la sequenza corretta? Questa convinzione è corretta?

2. Sindrome del rilascio successivo

Un fattore nel mancato riconoscimento della complessità è una mentalità da aggiustare dopo che chiamiamo sindrome del rilascio successivo. I bug del software non sono un problema perché "lo risolveremo nella prossima versione". L'enfasi sulla velocità rispetto alla qualità e alla sicurezza rende fin troppo facile rimandare la risoluzione dei problemi difficili.

Chiunque sia coinvolto nella progettazione e nello sviluppo del prodotto deve affrontare la sindrome della prossima versione. Due esempi chiariscono il punto:

• Abbiamo scoperto gravi difetti di progettazione con il software di monitoraggio sanitario di un cliente. L'azienda ha scelto di rilasciare il software senza affrontare questi problemi. Non sorprende che i clienti fossero insoddisfatti.
• Abbiamo condotto test di usabilità per una grande unione di credito con sede negli Stati Uniti. I partecipanti erano esperti consulenti finanziari. I test hanno rivelato gravi difetti di progettazione, tra cui icone di stato confuse, pulsanti con uno scopo poco chiaro e un collegamento quasi nascosto che impediva ai partecipanti di visualizzare dati importanti. Ricorda, se l'utente non lo vede, non è lì. Quando abbiamo riportato i risultati, la risposta è stata: "Lo sistemeremo nella prossima versione". Come previsto, l'applicazione web non è stata ben accolta. Le risposte degli utenti includevano: "Perché ci hai chiesto di rivedere l'app se non avevi intenzione di apportare modifiche?"

Soluzione: rifiuta la mentalità del fix-it-Next-time

La soluzione è affrontare ora seri problemi di progettazione. Sembra semplice. Ma come convincere i decisori a cambiare la radicata mentalità del "correggerlo dopo"?

La chiave è spostare la conversazione sui risultati dalla consegna del prodotto al valore creato. Ad esempio, è probabile che i team che si prendono il tempo per rivedere un design sulla base della ricerca degli utenti vedano migliori reazioni dei clienti e, nel tempo, una maggiore fedeltà dei clienti.

Rafforzare il caso utilizzando dati quantitativi per mostrare ai responsabili delle decisioni la connessione diretta tra la ricerca degli utenti e l'aumento delle entrate e un'esperienza positiva del cliente.

La ridefinizione del valore è, in effetti, un miglioramento del processo perché stabilisce una nuova serie di priorità che servono meglio i clienti e gli interessi a lungo termine della tua azienda. Come riporta McKinsey in The Business Value of Design: “Le aziende top-quartile abbracciano l'esperienza utente completa; abbattono le barriere interne tra la progettazione fisica, digitale e dei servizi”.

3. Tempo insufficiente per le iterazioni di progettazione

In relazione alla sindrome della prossima versione, il tempo non è sufficiente per iterare il design sulla base dei risultati della ricerca o dei requisiti aziendali in evoluzione. "Non abbiamo tempo per questo", è il ritornello comune di sviluppatori e proprietari di prodotti. I designer che lavorano in ambienti Agile sono spesso costretti a evitare di "trattenere" il team di sviluppo.

Lo sviluppo accelera e il software viene rilasciato. Abbiamo tutti visto i risultati di app telefoniche confuse, software di cartelle cliniche goffo, interfaccia utente ingombrante per i consulenti finanziari di cui sopra.

Soluzione: picchi di progettazione

Una soluzione viene dal mondo della codifica. Nel suo articolo "Fitting Big-Picture UX Into Agile Development", Damon Dimmick offre l'idea di picchi di progettazione, "bolle di tempo che consentono ai designer di concentrarsi su problemi complessi di UX". Si inseriscono nel framework Scrum sostituendo temporaneamente uno sprint regolare.

Le punte di design offrono diversi vantaggi:

• Consentono ai team UX di concentrarsi su problemi olistici ed evitare di impantanarsi in problemi di progettazione granulari che a volte vengono enfatizzati all'interno di un singolo sprint;
• Offrono l'opportunità di esplorare complesse domande UX di alto livello. Se necessario, il team di progettazione UX può anche impegnarsi in un pensiero incentrato sul design in qualsiasi momento per risolvere sfide UX più grandi;
• Adottando i picchi di progettazione, i team UX possono sfruttare la stessa flessibilità utilizzata dai team di sviluppo nel processo agile e dedicare il tempo necessario per concentrarsi su problemi di progettazione che non sempre si adattano bene a uno sprint di Scrum standard;
• È improbabile che lo sviluppo venga influenzato dalle decisioni di progettazione può procedere.

Naturalmente, le iterazioni di progettazione spesso influiscono su alcune parti del codice di un sito, un'app o un prodotto software. Per questo motivo, durante i picchi di progettazione, qualsiasi codice che sarà probabilmente interessato dal picco di progettazione non può andare avanti. Ma, come afferma chiaramente Dimmick, questo "ritardo" probabilmente farà risparmiare tempo evitando la rilavorazione. Semplicemente non ha senso scrivere il codice ora e poi riscriverlo alcune settimane dopo che il team ha concordato un progetto rivisto. In breve, posticipare un po' di programmazione fa risparmiare tempo e budget.

4. Fare troppo affidamento sui fornitori

Affrontare la complessità, resistere alla sindrome della prossima versione e concedere il tempo per l'iterazione sono essenziali per un processo di progettazione efficace. Per molte aziende, un'altra considerazione è il loro rapporto con i fornitori di software. Questi fornitori svolgono un ruolo importante, persino critico, nello sviluppo. Tuttavia, concedere loro troppa leva rende difficile controllare il proprio prodotto.

Certamente, dovremmo trattare colleghi e fornitori con rispetto e fare richieste ragionevoli. Ciò non significa, tuttavia, che sia necessario rinunciare a tutta la leva finanziaria come è successo durante il mio mandato in una grande società finanziaria.

Mentre lavoravo in questa azienda come designer UX, mi sono imbattuto spesso in questa dinamica:

Manager : “Ehi, Eric, puoi valutare questo software per reclami che stiamo pensando di acquistare? Vogliamo solo assicurarci che funzioni come previsto".

Io : "Certo, ti invierò i miei risultati preliminari entro la fine della settimana."

Gestore : “Ottimo”

La prossima settimana:

Gestore : “Grazie per la recensione. Vedo che hai riscontrato tre problemi seri: difficile trovare il numero di una richiesta esistente, schermate con troppo testo difficile da leggere e difficoltà di tornare a una schermata precedente durante l'elaborazione di una nuova richiesta. Questo è preoccupante. Pensi che questi problemi ostacoleranno la produttività?"

Io : "Sì, penso che questi problemi aumenteranno lo stress e i tempi di elaborazione nel Centro reclami. Sono piuttosto preoccupato perché il mio precedente lavoro con il team di Janet ha dimostrato che i rappresentanti del Centro reclami sono già molto stressati".

Manager : “Bello a sapersi. Ho appena inviato l'assegno. Chiederò al venditore di risolvere i problemi prima della spedizione".

Io (urlando dentro): "Nooooooooooooo!"

Questo manager ben intenzionato ha fatto esattamente la cosa sbagliata. Ha chiesto modifiche dopo aver inviato l'assegno. Non sorprende che il fornitore non abbia mai apportato le modifiche richieste. Perché dovrebbero? Avevano i loro soldi.

Non solo questo scenario si è ripetuto ripetutamente in quell'azienda, ma l'ho assistito durante tutta la mia carriera nell'esperienza utente.

Soluzione

La soluzione è chiara. Se il prodotto del fornitore non soddisfa le esigenze del cliente e dell'azienda e le modifiche richieste rientrano nell'ambito, non pagare finché il fornitore non apporta le modifiche. E 'davvero così semplice.

Conclusione

In questo pezzo, abbiamo identificato quattro ostacoli comuni al design di qualità e alle soluzioni corrispondenti:

1. Regolamenti e standard complessi
   La soluzione è riconoscere e affrontare la complessità ideando scadenze realistiche e budget sufficiente per la ricerca e la progettazione iterativa.
2. Spedizione di software con bug con la promessa di risolverli in seguito
   La soluzione è evitare la sindrome del rilascio successivo e affrontare problemi seri ora. Convinci i decisori ridefinendo il significato di valore all'interno della tua organizzazione.
3. Tempo insufficiente per le iterazioni di progettazione
   La soluzione è includere i picchi di progettazione nel processo di sviluppo agile. Queste bolle temporali prendono temporaneamente il posto di uno sprint e consentono ai designer di concentrarsi su complessi problemi di UX.
4. Fare troppo affidamento sui fornitori
   La soluzione è mantenere la leva trattenendo il pagamento finale fino a quando il fornitore non apporta le modifiche richieste, purché queste rientrino nell'ambito del progetto originale.

La quarta soluzione è semplice. Anche se i primi tre non sono facili, sono concreti perché possono essere applicati direttamente ai processi di progettazione esistenti. La loro implementazione non richiede una massiccia riorganizzazione o milioni di dollari. Richiede semplicemente l'impegno a fornire un'esperienza migliore.