I-Care Platform

Lead Product Designer.Val Mercenaro

Lead Developer.Andrea Carta

Software Engineer.Andrea Introini

Developer.Benito Massidda

DESIGN SPRINT
DESIGN THINKING
UI DESIGN
UX DESIGN
SKETCH & PROTOTYPE
WEB DESIGN
USABILITY REVIEW
SCRUM
INFORMATION ARCHITECTURE
USER RESEARCH

.Introduzione

I-care è una piattaforma con algoritmi proprietari per realizzazione di “dashboard benessere” del cliente finale.
Ad oggi possono essere eseguiti una trentina di checkup ed è integrata ad un alto numero di devices interfacciati grazie a IOT.

I-Care è la SAAS legata alla Prevention Suite, la suite di soluzioni integrate che combinano hardware e software, competenze scientifiche, gestione delle risorse umane e logistica, progettata intorno alle esigenze dei professionisti del Life Science che lavorano nel campo della prevenzione, della salute e del benessere personale.

.Design challenge generale

Migliorare customer experience di I-Care SAAS tramite un’esperienza coesiva tra tutti i touchpoint

Il challenge principale che ha accomunato ogni elemento della suite è stato il riuscire a rendere omogeneo l’ecosistema Prevention Suite partendo dalle esigenze degli operatori stessi della Suite fino a raggiungere con le nuove soluzioni proposte anche l’utente finale (B2C)

La platform ha bisogno di essere riprogettata per connettersi al meglio con il target market, compresa la costruzione di un’architettura delle informazioni più intuitiva e lo sviluppo di un linguaggio visivo coerente.

.Il mio ruolo

Lead product designer responsabile della riprogettazione, UX convergence e content strategy

1. Facilitazione workshops
2. Riprogettazione dei flussi d’esperienza
3. Architettura informativa
4. Rebranding, design system
5. Ottimizzazione per Totem interattivo, dispositivi mobile e desktop
6. Content strategy
7. Progettazione mobile companion app e siti

Fase 1: discovery

Kickoff, product vision, brand e users discovery sessions, user personas

.Il 1° problema da risolvere

I farmacisti trovano complicate la azioni che dovrebbero compiere maggiormente con I-Care (es. prenotazione checkup ideale per sintomi), trascura ogni aspetto di user experience corretta (anche a livello grafico) ed è quindi poco efficace nel raggiungere gli obiettivi a lungo termine dell’azienda (es. fidelizzazione cliente finale, aumento sellout, branding, ecc. ).

CHALLENGE 1: Come creare un’immediata connessione tra utente finale (cioè cliente della farmacia) e Totem I-Care e allo stesso tempo rendere il flusso prenotazione “checkup ideale” il più veloce ed intuitivo possibile per il farmacista?

.Obiettivi ultimi

– Brand consolidation e convergenza UX tra attraverso l’intera product line

– Dare allo user group di riferimento (es. Farmacie) uno strumento efficace per attirare nuova clientela

– Fornire (allo user group di rif) un sistema di fidelizzazione basato sulla prevenzione a 360°

– Aumentare il sellout dello user group grazie ai checkup e consigli mirati sui prodotti (es. della farmacia)

.Definizione user group di riferimento

Nota per il lettore

In principio le soluzioni Prevention Suite proposte erano state declinate nell’ambito btb e btbtc. Uno dei miei challenges consisteva nel creare un sistema che raggiungesse anche l’utente finale (btc).
Grazie alla nuova progettazione I-Care (+ companion apps), e l’assidua collaborazione con il team di sviluppo siamo riusciti a coprire anche l’ultimo miglio e, ad oggi, la Prevention Suite è completa per tutta la filiera.

Utenza primaria: btb

Gruppi di farmacie, farmacie singole, palestre, etc. (focus sulla ricchezza d’integrazione con i loro erp e i devices leader di mercato)

Utenza secondaria: btbtc

Aziende farmaceutiche, aziende di prodotto, aziende di device (focus su completezza della soluzione e implementazione carrier grade personalizzabile)

Utenza interna: btbtc

Operatori professionali (focus sul percorso di formazione certificato – academy – e sul concetto di marketplace/uber degli operatori)

Kickoff meeting e user research co-creation

Durante i primi meeting con il team abbiamo estrapolato e discusso alcune delle domande e risposte dal questionnaire inviato pre-kickoff. In questa prima fase abbiamo creato insieme agli altri stakeholders le prime due user personas di riferimento

Risultati del esercizio tecnico HMW (How Might We…)

Alla fine della fase di ricerca (Discovery), abbiamo riunito il team per discutere le info scoperte con la ricerca e far leva su di esse per inquadrare i principali design challenges attraverso un design thinking workshop (facilitato da me).

.User Stories e Job Stories

Una volta ottenuta un’idea chiara di chi usa la platform, siamo passati al mappare come potrebbero usarla.
Questo ci ha aiutato a progettare il flusso I-Care per essere il più fluido possibile e a individuare le priorità fondamentali su cui focalizzare la progettazione stessa

Per ogni bisogno identificato nella fase precedente quindi ho creato uno scenario ideale per ogni tipo di utenza e servizio.

Onboarding farmacia

Stakeholder lamentava la problematica del dover creare per ognuno dei suoi clienti un profilo utente. I farmacisti si rifiutavano di completare il proprio profilo autonomamente.

Abbiamo cercato di capire quale fosse il vero problema con scenari d’esperienza mirati, user stories e JBD, fino al mappare una possibile soluzione da far testare al cliente durante la prima release.

Ottimizzazione flusso creazione cliente

Stakeholder lamentava la problematica del ricevere troppe richieste d’aiuto da parte del farmacista riguardo la complessità flusso creazione cliente.

Tramite le diverse user stories e job stories abbiamo creato una possibile soluzione testabile che prendesse per mano il cliente in ogni fase della creazione profilo cliente

Attivazione checkup

“Come Farmacista, vorrei avviare il checkup cliente con più facilità, in modo da non dover andare a cercare il checkup tra le decine proposte da iCare”

Grazie a questa user story abbiamo progettato un flusso di attivazione checkup (del giorno) che parte direttamente dal profilo cliente stesso cosi che una volta creato il profilo utente il farmacista possa immediatamente avviare i checkup del giorno/richiesti

.Agile User Story Maps

Con la user story map abbiamo in seguito organizzato le user stories in un modello utile a capire la funzionalità specifiche per ognuna delle soluzioni proposte, identificato buchi e omissioni nel backlog, e pianificato i rilasci che potessero fornire maggior valore agli utenti e al business

User story map di Miro integrata al backlog Jira

Questa user story map rappresenta 4 tipi di azioni a diversa granularità: attività (evento di riferimento), tasks, funzioni e Jira sprint backlog (le azioni più specifiche). Le attività e tasks sono visualizzati orizzontalmente nella parte superiore della mappa, e i dettagli (funzioni e backlog) sono sovrapposti verticalmente sotto i loro rispettivi tasks in ordine di priorità.

.Scenario-based usability reviews

L’aver individuato scenari d’esperienza fondamentali per l’utente I-Care ci ha dato anche modo di portare avanti un usability review basandoci sul critical paths (flussi di esperienza utente cruciali per il successo del sistema stesso)

Definendo ogni scenario abbiamo ripercorso gli steps che il nostro utente (probabilmente) farà per raggiungere il suo obiettivo. Di seguito alcune delle considerazioni che sono state fatte a livello di usabilità platform I-Care

PRIMA - Versione Home (obsoleta)

Schermata di benvenuto I-Care prima della riprogettazione

DOPO - Versione Home nuova

Schermata di benvenuto I-Care dopo la riprogettazione

4
5

La pagina iniziale (come il resto della platform) non forniva un’istantanea chiara né una panoramica del contenuto, delle caratteristiche e delle funzionalità disponibili

I-Care platform era inefficace nell’orientare e dirigere gli utenti verso le informazioni e i task desiderati

Gli utenti non potevano facilmente annullare, tornare indietro, cambiare o cancellare le azioni; non c’era neppure la possibilità di confermare un’azione prima di procedere

Moduli e processi complessi non erano suddivisi in fasi e sezioni facilmente comprensibili.

Veniva omesso il feedback tempestivo e appropriato

Non vi era possibilità di cercare i checkup desiderati (anche in base all’area sintomatica)

Le funzionalità usate di frequente non erano facilmente disponibili (es. non erano accessibili dalla homepage) e poco supportati (es. non venivano forniti shortcuts).

Non vi era possibilità di cercare i checkup desiderati (anche in base all’area sintomatica)

Le Call to action erano poco chiare, mal etichettate e non apparivano cliccabili

Mancavano aiuti e istruzioni (es. info-boxes con esempi, informazioni necessarie a compilare form, ecc)

Gli utenti non erano in grado di recuperare facilmente (cioè dovevano ricominciare da capo) in caso di errori.

Fase 2: Definizione

Dalla ricerca utente ed esplorazione del problema alla definizione delle soluzioni

.Brainstorming e sketching

La fase dello sketching ci è servita per esplorare potenziali soluzioni ai problemi di design in maniera veloce.

Nota per il lettore

Durante la progettazione pre-lockdown ho usufruito spesso di questa tecnica, soprattuto degli esercizi di sketching legati ai design sprint (Crazy 8s).

Dal momento in cui il team ha cominciato a lavorare da remoto, anche questa fase è stata gestita in digitale (quando possibile abbiamo condiviso sketches tramite slack). Lo sketching è stato in ogni caso uno degli skills più importanti ed efficaci che abbia acquisito nei miei 12 anni di UX career.

Flusso di esperienza derivato da How Might We problems

Parte della tecnica degli HMW consiste nel raggruppare i post its in base alla tipologia di problema a cui sono riferiti. In questo caso il problema ha portato a varie alternative di flusso, tra cui quello che vediamo in questo screenshot.

Dal flusso generale all’esperienza dettagliata

Per ognuno degli steps del flusso precedente siamo andati a delineare nel dettaglio gli elementi essenziali per poi seguire con lo storyboard del flusso (foto in basso)

Storyboard flusso booking

Uno dei primi user flows creati durante la progettazione I-Care. Ogni screen rappresenta un’azione che dovrà compiere il nostro utente per arrivare all’ “obiettivo” finale di prenotare il checkup

Nota per il lettore

I dettagli di questi abbozzi di screens non sono altro che “risposte” alle seguenti domande:

  • Quali sono gli obiettivi dello user e del business quando interagisce  con questo screen
  • quali tra i problemi di design individuati durante la fase di definizione sto andando a risolvere
  • quali sono le task principali che deve compire utente quando arriva sulla pagina
  • quali sono le tasks principali che deve compiere l’utente quando arriva sulla pagina?
  • esattamente come possono essere organizzati i contenuti a supporto di questi obiettivi?
  • cosa dovrebbe vedere per primo l’utente quando arriva alla pagina?
  • cosa si aspetta di vedere in alcune aree della pagina?

Le risposte alle domande vengono organizzate sul nostro whiteboard come una lista di riferimento.

Per esempio, se una delle risposte dovesse essere “l’utente ha bisogno di cercare un checkup”, andrò a scrivere la risposta e ad aggiungere a fianco un’indicazione su quale elemento UI potrebbe aiutare l’utente a raggiungere quel obiettivo. In questo caso sarebbe una search bar.

Fase 3: Design solution

Definizione del layout e posizionamento dei contenuti, funzionalità e adattamento ai dispositivi

.Wireframing

Il nostro 1° flusso di interazione (FA1), dopo essere stato discusso e testato viene trasformato in wireframes in modo da poter cominciare la progettazione digitale di questa specifica soluzione

Wireframes del flusso di booking

Una volta sketchate le possibili soluzioni siamo passati alla struttura digitale della platform, prima versione indirizzata al layout, navigazione e funzionalità. In questa foto abbiamo uno dei flussi legati ad uno specifico scenario esperienza dell’utente non loggato.

.Prevention Suite design system

PS Design System è un linguaggio di progettazione che fornisce un framework comune (tra designer e developer) per costruire interfacce all’interno dell’ecosistema di prodotti / servizi Prevention Suite (es. I-Care). È una guida ai fondamenti, ai componenti, ai modelli e ai casi d’uso che fornisce coerenza a questi prodotti e, in definitiva, fornisce un’esperienza soddisfacente e unificata ai suoi utenti.

UI Shell / Layout

A questo stage della progettazione ho creato una style guide per gli sviluppatori e poi trasformata in un design system.
Non solo questo ha migliorato la collaborazione designer-sviluppatore, ma ha reso la piattaforma più coerente ed omogenea.

Nota per il lettore

La piattaforma I-Care è stata progettata per totem verticale (1080×1920 px) e totem orizzontale (1920×1080). Durante l’ultimo periodo di progettazione vi è stata la necessità di ampliare per alcune specifiche viewport (MacBook 1270×780 e 1440×990 ), perciò sono state inserite le indicazioni di layout anche per la nuova tipologia screens

Fase 4: Prototipazione

Sketches, decisioni ed idee confluiscono in prototipi realistici del prodotto finale

Siamo arrivati finalmente al vero e proprio prototipo funzionale interattivo da poter condividere e testare con il team e con i beta testers.
Grazie a strumenti come Figma ho creato un prototipi high-fidelity della soluzione e con il team abbiamo potuto coinvolgere fin da subito tutti gli attori coinvolti nel progetto, dai designer agli sviluppatori, con l’apporto costante e decisivo del committente. Il prototipo ci ha consentito anche di individuare e risolvere eventuali problemi di usabilità che non erano stati evidenti nelle fasi precedenti.

Prototipo flusso booking checkup FA1

Questo è il primo flusso risolutivo del challenge 1 I-Care. I percorsi d’interazione sono multipli attraverso questi artboards ma in questo caso ci siamo basati su uno scenario specifico e ipotesi che vedremo nella prossima fase (5)

.Flusso utente FA1

User task da testare

User con problemi di stress e stanchezza prenota checkup legato alla sua area sintomatica

Ipotesi di riferimento

1. Utente vuole una soluzione per i sintomi causati da “Stress e stanchezza”

2. Sceglierà l’area sintomatica corretta e si fiderà del checkup consigliato una volta letta la pagina informativa

3. Sceglierà il primo evento in palinsesto, l’orario adatto ed inserirà i suoi dettagli cliente

4. In questo scenario non verrà pagato l’evento quindi passerà direttamente alla conferma dati e ricezione SMS

Fase 5: Altri flussi d’esperienza

Flussi d’esperienza “task based”

Il primo challenge della progettazione I-Care è stato risolto ed è in fase di testing e iterazione . Nel frattempo con il team ci occuperemo di programmare il nuovo backlog per il prossimo Sprint in cui verranno realizzati man mano tutti i flussi critici per un’esperienza utente ottimale.

Stiamo avanzando in modalità “Task Based”, nel senso che per ognuna delle user tasks individuate andiamo a creare un flusso UX specifico.

La task che segue per es. è legata alla configurazione account cliente B2B (farmacista)

Prototipo flusso configurazione account Farmacia FB1

Flusso tak-based che parte dal login del farmacista, passa attraverso l’aggiunta dei dati essenziali raccolti con la wizard e chiude la configurazione dando modo al farmacista di passare immediatamente all’aggiunta “profilo cliente”

.Flusso utente FB1

User task da testare

User “farmacista” deve configurare l’account amministrativo generale per la sua farmacia (senza contattare assistenza!)

Ipotesi di riferimento

1. Utente ha già un account

2. Verrà incentivato dalla status bar a completare il profilo