Cambiare la traiettoria della ricerca sanitaria

I possibili usi per questi set di dati sono infiniti, ma l'interfaccia deve essere mirata. Per chiarire ciò che il prodotto deve realizzare, abbiamo organizzato una fase di scoperta di due settimane che si è concentrata sulla ricerca degli utenti.

Ci siamo rivolti a persone dei due pubblici di riferimento: accademici ed esperti dell'industria sanitaria. Abbiamo organizzato interviste e focus group sia con scienziati di dati esperti che con persone che non avevano mai lavorato prima con i big data, i cosiddetti 'citizen scientists'.

In definitiva, abbiamo usato un mix di diversi metodi di ricerca degli utenti per rivelare le sfumature di ciò che gli utenti si aspettavano e di cui avevano bisogno dal prodotto.

La ricerca UX produce diversi pezzi unici di informazioni. Al fine di prevedere ciò di cui gli utenti hanno bisogno durante ogni fase del processo, i risultati devono essere integrati in un insieme coerente.

Analizzando, confrontando e contrastando tutti questi insight, abbiamo scoperto dei modelli generali. Questi modelli ci permettono di capire gli outlier come i metodi miscellanei che le persone usano per raggiungere i loro obiettivi.

Il modello mostra anche le differenze in ciò di cui gli utenti hanno bisogno. Per esempio, i ricercatori universitari sono tenuti a passare attraverso un lungo processo di approvazione prima che possano anche solo iniziare a impegnarsi con i set di dati. Al contrario, i ricercatori delle aziende farmaceutiche iniziano presto a sperimentare con i dataset, ma incontrano più tardi le limitazioni normative.

Abbiamo testato nove strumenti di interrogazione dei dati che sono comuni nel settore sanitario. Lo scopo del benchmarking è quello di aiutarci ad acquisire una comprensione approfondita delle sfide che si manifestano negli strumenti di big data per l'assistenza sanitaria.

Abbiamo identificato i design pattern che gli utenti potrebbero aspettarsi, così come le interazioni uniche che sono idee brillanti o tentativi falliti di risolvere un problema.

Grazie a questo sforzo, possiamo evitare i percorsi morti che altri hanno provato e risparmiare tempo durante il processo di progettazione. Ma c'è anche un altro grande vantaggio: l'esperienza utente che creiamo è destinata a integrarsi nello spazio generale delle applicazioni sanitarie e a spingersi oltre.

L'esperienza utente è progettata per far fronte a una vasta gamma di complessità delle query: dalle semplici query a due fattori, fino alle query a più fattori su 8 livelli di profondità.

Abbiamo disegnato 5 modelli di costruttori di query basati su 3 diversi presupposti e li abbiamo trasformati in prototipi interattivi attraverso un design UX iterativo. I prototipi cliccabili ci hanno permesso di analizzare i pro e i contro di ogni modello attraverso il test utente.

Abbiamo usato un processo evolutivo in cui le varianti si sono evolute in parallelo fino a quando alcune di esse si sono fuse in un modello vincente. Questo processo di UX design, che incorpora l'esplorazione e la selezione empirica, alla fine ha portato a uno strumento di interrogazione che supera tutte le versioni originali.

Gli strumenti per l'analisi dei dati sono stati integrati come moduli: statistiche descrittive, funzioni di correlazione e altri. Si inseriscono nell'architettura modulare di questo softcare sanitario come plugin.Lo stesso vale per i moduli di visualizzazione dei dati.

In altri strumenti di analisi dei big data, queste funzioni hanno un'esperienza utente inutilmente complicata, oltre a un look and feel asciutto e tecnico. L'ambizione per questi moduli di analisi dei dati era di adattare il design UX agli utenti che non sono scienziati dei dati.

I ricercatori Healtchare lavorano in team. Un individuo può far parte di molti team diversi. In termini di ciò che rappresenta una sfida UX, questa sezione admin sembra banale, ma è in realtà un fattore critico per il successo degli utenti. Per assicurarci che i moduli di amministrazione non finiscano per essere una fonte di frustrazione, abbiamo investito altrettanto lavoro meticoloso, cura e test per modellare la loro esperienza utente.

Abbiamo usato colori neutri per le schermate in cui gli utenti si concentrano principalmente sui dati grezzi, e tonalità elettriche di blu, viola, verde e rosso per i moduli di analisi dei dati. Le illustrazioni sono state usate con parsimonia, per aggiungere brevi momenti di piacere nei passaggi chiave del flusso degli utenti.

Il sistema di progettazione mira a sostenere gli sforzi di sviluppo sia durante l'implementazione del nostro progetto che in futuro. Gli sviluppatori hanno una libreria di componenti che possono usare per rilasciare le funzionalità previste per i prossimi due anni.

Il team di sviluppo è stato invitato a partecipare ai nostri workshop fin dall'inizio. Per noi, gli sviluppatori sono importanti stakeholder del progetto, la cui esperienza tecnica aiuta a guidare certe decisioni di design.

Durante i workshop di design, volevamo assicurarci che le interazioni dell'utente che stavamo prototipando fossero realizzabili da un punto di vista tecnico. Per il team di sviluppo, essere coinvolti fin dall'inizio significava avere la possibilità di scegliere le tecnologie di backend ottimali, così come un passo verso una stima accurata dello sforzo.

Man mano che la progettazione si avvicinava alla fine, il nostro ruolo nella collaborazione con il team di sviluppo si è spostato su uno di supporto. Abbiamo partecipato a riunioni regolari per informarli in preparazione dei loro sprint e abbiamo fornito supporto live su Slack e Zeplin nel corso dell'intera implementazione.