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

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.

.Il mio ruolo

Lead product designer responsabile della riprogettazione, UX e content strategy

— I-Care SAAS platform UX (re)design
— Prevention Suite brand consolidation strategy
— Usability reviews
— Companion e utility apps (I-Care mobile experience)
— Gestione backlog e feature definition cycles
— Content strategy
— Architettura informatica del servizio checkup e platform

FASE 1

Individuazione UTENTI

Kickoff, product vision, brand e users discovery sessions

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).

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 che i farmacisti si rifiutavano di completare il proprio profilo autonomamente e ciò risultava in continue telefonate all’assistenza.

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.

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 ho in seguito organizzato le user stories in un modello utile a capire le 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à.

FASE 2

Definizione del PROBLEMA

Come creare un’immediata connessione tra utente finale e Totem I-Care, e rendere il flusso prenotazione checkup veloce ed intuitivo per il farmacista

.Brainstorming e sketching

La fase dello sketching ci è servita per esplorare potenziali soluzioni ai problemi di design in maniera veloce.
Durante la progettazione pre-lockdown ho usufruito spesso di questa tecnica, soprattuto degli esercizi di sketching legati ai design sprint (Crazy 8s).

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)

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?
  • 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).

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

.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à “I-Care Home” 

DOPO - Versione Home nuova

Schermata di benvenuto I-Care dopo la riprogettazione

PRIMA - Versione Home (obsoleta)

Schermata di benvenuto I-Care prima della 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

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 3

Ideazione e PROTOTIPAZIONE

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

.Flussi “task based” prototipati

Prototipo flusso booking checkup FA1

Questo è uno dei primi flussi da testare I-Care. I percorsi d’interazione sono multipli attraverso questi artboards ma in questo esempio abbiamo ipotizzato uno scenario in cui:

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

User task da testare

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

Prototipo flusso configurazione account farmacista FB1

Flusso task-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”

Ipotesi di riferimento

1. Utente ha già i logins account

2. Sceglierà di configurare dalla wizard incentivato dalla barra di progresso

User task da testare

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

.Altri flussi d’esperienza “task based”

Prototipo flusso Body Checkup FC2

Flusso legato ai checkup I-Care (in questo caso Body Check). Tutti i checkup hanno struttura che cambia in base alla tipologia delle domande, steps, substeps, necessità di dare istruzioni, ecc.

Ipotesi di riferimento

1. Utente ha già configurato i settings di navigazione checkup

2. Ha lasciato selezionata l’opzione che automatizza lo scorrere delle domande senza bisogno di cliccare “AVANTI”

User task da testare

User deve passare da uno step all’altro del checkup senza essere sopraffatto dalle molte sub-steps

Risultati 

.Conclusioni post rilascio vs 1

Il primo challenge della progettazione (creare un’immediata connessione tra utente finale e Totem I-Care, e rendere il flusso prenotazione checkup veloce ed intuitivo per il farmacista)) è stato risolto ed è in fase di testing e iterazione.

Grazie a Figma ho creato un prototipo high-fidelity delle soluzioni da testare e con il team abbiamo potuto coinvolgere fin da subito tutti gli attori coinvolti nel progetto. Questo ci ha consentito anche di individuare e risolvere problemi di usabilità che non erano stati evidenti nelle fasi precedenti.

\

New I-Care is being launched on the international market

f

User profile configuration can now be managed autonomously

Companion apps available for download from stores

End users can book themselves independently

Thousands of I-Care activations booked in Italy and Spain

Most internal I-Care processes have been automated

.Next steps

Nel frattempo che  la fase di user testing e iterazione va avanti, con il team ci occuperemo di programmare il nuovo backlog per per i prossimi sprint in cui verranno realizzati man mano tutti i flussi critici per un’esperienza utente ottimale (utilizzando lo stesso metodo visto finora)