Thinking
Progettare un'esperienza per Internet of Things: che cosa abbiamo imparato
“Sto portando avanti un progetto startup, IOOOTA. Da circa un mese abbiamo deciso di fare seriamente, siamo completamente focus su questo e ci piacerebbe avere il vostro supporto: c'è una parte importante legata ad app mobile e ad una serie di prodotti fisici con cui interfacciarsi. Credi vi possa interessare?” A scrivercelo è Luca Degli Esposti di Iooota, poco meno di un anno fa. Dopo qualche settimana di confronto, abbiamo formulato un’ipotesi di lavoro su quella che poi sarebbe diventata la prima versione compiuta di quell’idea, Jarvis.
La nostra roadmap prevedeva che affiancassimo Iooota nella progettazione di questo primo prototipo, rispettando le milestone e gli accordi presi con gli investitori. In aggiunta a questo, volevamo mettere sotto torchio il prototipo e consentire a Iooota di misurarsi con gli utilizzatori finali.
Il prodotto digitale, in poche righe.
Jarvis è una piattaforma tecnologica che ha un corpo fisico e un’anima digitale.
Il suo corpo fisico è fatto da un hub, cioè un cervellone connesso via cavo o wifi a una rete. Questo cervellone sa gestire e controllare una lunga serie di smart objects, cioè di oggetti di varie marche (spie, sensori, lampadine, prese, ecc…) con cui è in grado di comunicare.
L’anima digitale di Jarvis è la piattaforma software rivolta a due attori principali: l’intermediario (cioè chi ha deciso di portare Jarvis ai suoi Clienti con l’obiettivo di migliorare o integrare l’esperienza con il proprio servizio) e l’utilizzatore finale (cioè i Clienti degli intermediari che installeranno hub e oggetti nelle proprie case o ambienti di lavoro).
Per l’utilizzatore finale, Jarvis è d'aiuto nel gestire e controllare gli oggetti e nel creare automatismi. Jarvis apprende dal comportamento, integra servizi esterni e, in breve, aiuta ad amministrare e controllare l’ambiente, sia in rete che in cloud, sia via app che via webapp.
Per l’intermediario, Jarvis raccoglie dati e informazioni sull’utilizzo degli oggetti, degli automatismi e delle API esterne, impattando così sul servizio che le aziende possono modulare per i loro Clienti.
Luca Degli Esposti, CEO di Iooota, presenta Jarvis in questo post su Medium.
Dal dire al fare.
Se stai leggendo questo post e lavori nel campo del design o dello sviluppo software, non avrai fatto fatica a convertire le poche righe con cui abbiamo descritto Jarvis in un progetto esecutivo, a prefigurarti la mole di lavoro (business, design e sviluppo) e il tempo che occorre per realizzare un’idea di questa portata.
Ci siamo confrontati per circa un mese con il team di Iooota. Volevamo capire bene la loro visione sul lungo termine, in modo da aiutarli a fare i passi giusti nei primi 6 / 12 mesi. Così abbiamo definito la visione di prodotto, evidenziato gli aspetti critici e nebulosi e definito il Minimum Viable Product (MVP) che avremmo dovuto realizzare entro 6 mesi.
Jarvis è stato un progetto per noi davvero molto nuovo e sfidante.
In questi mesi siamo entrati nella complessità del mondo dell’Internet of Things, i suoi pattern ibridi e le sue regole al confine tra fisico e digitale sono stati come un braccio di ferro per il nostro processo di design. Abbiamo imparato moltissimo e ringraziamo il team di Iooota per averci permesso di pubblicare le importanti lezioni che abbiamo imparato e che vogliamo condividere in questo post.
Lezione 1:
Fare ricerca subito. Ma subito subito.
In fase di accordo iniziale, avevamo ipotizzato di lavorare su una roadmap per noi standard: setup, research, design&build, QA e test. Avevamo a disposizione qualche oggetto, un prototipo molto rudimentale dell’hub e uno dell’app. Davanti a noi il lavoro che ci aspettava sembrava essere davvero molto impegnativo. Non riuscivamo a trovare un accordo sulle assunzioni da validare, né a capire che tipo di risposte avrebbe potuto dare il prototipo. Temevamo che il suo aspetto troppo primordiale avrebbe influenzato le impressioni degli utenti. Soprattutto, il mindset del team rispetto a un confronto con gli utenti sembrava non essere quello adatto, non per via dei classici pregiudizi verso la ricerca con gli utenti, ma perché non c’era ancora la giusta percezione di quanto sforzo sarebbe costato sviluppare il prodotto. Senza questa consapevolezza, sarebbe stato difficile leggere e capire il peso delle indicazioni e delle suggestioni che avremmo ricevuto dagli utenti intervistati. Per questo abbiamo preferito iniziare a lavorare sull’MVP, con l’obiettivo di testarlo appena pronto.
Se potessimo tornare indietro, cercheremmo in tutti modi di iniziare con una o due giornate di interviste con gli utenti nelle loro case o nei loro uffici.
Nella fase di followup della ricerca avremmo tenuto una luce costantemente accesa sulla nostra capacità di giudizio rispetto agli sforzi di design e sviluppo.
Questa lezione l’abbiamo imparata con il benedetto senno di poi.
Al primo momento della verità ci siamo arrivati appunto a 6 mesi dall'inizio del progetto, in occasione dei primi due alfa-test predisposti a casa di due giovani famiglie (la prima è una coppia con bimbo e vive in affitto, l’altra è una coppia che vive in casa di proprietà distribuita su tre livelli, con giardino e parenti vicini).
L’alfa-test è stato preparato suddividendolo in queste fasi: prima installazione in presenza, utilizzo di 4 oggetti con assistenza da remoto, disinstallazione in presenza. Durante il primo incontro per l’installazione abbiamo consegnato il kit di oggetti e invitato le due famiglie a raccontarci che cosa capivano e che cosa si aspettavano dal prodotto, in più abbiamo visto i dubbi e le difficoltà ambientali nel finalizzare il primo setup e la distribuzione degli oggetti. In breve, in 4 ore di incontro abbiamo ottenuto una marea di informazioni vitali per il prodotto e abbiamo sottoposto a stress test sia l’ecosistema che il team di sviluppo. Se avessimo avuto queste informazioni a inizio progetto, la roadmap successiva ne avrebbe beneficiato moltissimo.
Lezione 2:
Far funzionare un oggetto alla volta e testarlo con gli utenti subito.
La prima versione minima del prodotto avrebbe dovuto contenere non solo un certo numero di oggetti smart, ma anche alcune funzionalità (che all’epoca ci sembravano di base) per farli interagire "automagicamente" tra loro.
Se potessimo tornare indietro al momento in cui abbiamo costruito la roadmap di progetto, oggi faremmo di tutto per guidare il team a mettere una milestone a 3 mesi: entro 3 mesi, il primo oggetto avrebbe dovuto funzionare e avremmo dovuto vederlo in azione a casa di un alfa-tester.
Perché non lo abbiamo fatto?
Perché pensavamo che fare un giro di test con un solo oggetto non avrebbe dato risposte particolarmente importanti visto che l’idea è che il vero cuore del prodotto stia nell’automagia che è possibile creare quando gli oggetti sono tanti.
Perché oggi faremmo di tutto per guidare il team a mettere una milestone a 3 mesi?
Per due motivi principali:
- Ogni oggetto è peculiare, ogni persona/famiglia/ambiente (casa ufficio) lo interpreta a modo suo e lo usa in luoghi, contesti e momenti che non possiamo immaginare finché non iniziamo a capirlo vedendolo con i nostri occhi. Se non comprendiamo queste cose a fondo, progetteremo un’esperienza incompleta e il prodotto risulterà inusabile.
Un esempio: un sensore in grado di rilevare se due oggetti sono vicini o distanti tra loro (comunemente noto come sensore porta / finestra o sensore intrusioni) verrà probabilmente applicato agli infissi o ai mobili di casa, ma non è detto.
Come si deve applicare alla superficie?
Danneggerà l’infisso?
E se la superficie è curva?
E quando la batteria si esaurisce?
Tutto ‘sto sbattimento per attaccare questo oggetto da qualche parte in casa che beneficio può portare? Sarebbe molto meglio saperlo prima, altrimenti il momento in cui l’oggetto viene installato in casa sarà vissuto con incertezza e nessuna motivazione. - Per arrivare al momento in cui una persona potrà finalmente interagire con il suo oggetto smart tramite app, i passaggi che deve fare sono questi:
(1) unboxing,
(2) comprensione di ciò che sa fare l’oggetto ed eventuale decisione su dove usarlo,
(3) installazione e primo setup dell’hub,
(4) registrazione profilo utente, obbligatoria per chi vuole usare l’app o la webapp anche da remoto,
(5) pairing, cioè l’accoppiamento di un oggetto fisico smart con un ecosistema digitale che quindi sarà in grado di controllarlo,
(6) configurazione di un oggetto,
(7) personalizzazione,
(8) utilizzo e allarmi,
(9) eventuale creazione di regole e automagia.
Dicevamo che il punto 9 era quello considerato di valore per il prodotto, e su questo eravamo e siamo tutti d’accordo. Il fatto però è che per arrivare al punto 9 l’utente deve per forza passare gli altri 8.
8 passaggi, mica 2.
Creare un MVP funzionante di questi 8 passaggi entro i primi 3 mesi sarebbe stato davvero prezioso, non solo per il prodotto in sé ma anche per il team, che avrebbe avuto modo e occasione di fare un reality check su ognuno di essi.
Per reality check intendiamo che dallo sviluppo “in vitro” alla prima installazione in una vera casa, quanti problemi saltano fuori? Quanti imprevisti? Come si può organizzare il team per raccogliere le informazioni, gestire l’apprendimento e affrontare il prossimo step?
Lezione 3:
Progettare e sviluppare pensando alla fiducia da costruire.
I 7 principi di design individuati da Donald Norman sono Affordance (mondo fisico) / Signifiers (mondo digitale), Feedback, Constraints, Visibility, Mapping, Consistency. In un progetto web applicare questi principi significa farlo in modo bidimensionale, perché ciò che succede avviene tra l’utente e ciò che vede o sente dal suo device (di solito è un pc, uno smartphone o un tablet). Su un progetto di Internet of Things, i principi si applicano in modo tridimensionale. Questo significa, per esempio, che quando progettiamo il feedback verso un utente, non dobbiamo pensarlo solo per ciò che si vede dal device, ma anche per ciò che accade all’oggetto smart, all’hub e al resto dell’ambiente su cui non abbiamo alcun controllo. Dobbiamo quindi uscire dallo schermo ed entrare nello spazio fisico, aprendo una diga di possibilità di interazione che su web non esistono.
Saltare o sottostimare questo aspetto della progettazione significa offrire un servizio parzialmente sordo e cieco al mondo reale che circonda l’utente, lasciando per strada un mare di opportunità dal punto di vista dell’esperienza che l’utente potrebbe fare.
Uno dei punti più critici, se non forse il più critico, dell’esperienza è proprio quello di costruzione della fiducia da parte dell’utente.
Immaginate di avere davanti a voi degli oggetti che non avete mai visto prima: per esempio una piccola sfera, una scatoletta, due rettangoli piatti e così via.
Ora immaginatevi che questi oggetti vi vengano in qualche modo proposti come spie rilevatrici di intrusioni, allagamenti, movimento, fumo, incendio e altre sventure.
Immaginatevi poi il momento in cui distribuite questi oggetti in casa. Ecco, questo è il momento in cui state iniziando a delegare la vostra fiducia su questi oggetti. Che cosa avete bisogno di sapere e di capire? Che cosa vi preoccupa? Perché?
Infine immaginatevi di essere lontano da casa: se uno di questi oggetti fosse una persona che ha tutta la vostra fiducia, come si comporterebbe in base a ciò che rileva in casa?
Entrare nei luoghi fisici abitati dalle persone con oggetti smart ai quali si dovrebbe delegare il controllo di qualcosa è come ottenere le chiavi di casa da un amico che si fida di noi.
Durante le prime sessioni di co-design la nostra attenzione si è focalizzata sul tono di voce e sulla personalità di Jarvis. Ci domandavamo che aspetto avrebbe avuto e in che modo avrebbe guidato gli utenti nell’utilizzo dell’app soprattutto nei passaggi più tecnici: quello di installazione dell’hub e il pairing degli oggetti. Dopo un confronto con Luca, insieme al nostro Paolo abbiamo iniziato ad immaginarci un robottino fluttuante nelle vesti di un maggiordomo, con tanto di papillon, che si rivolge ai suoi utenti attraverso messaggi comprensibili ed efficaci utilizzando toni educati e nello stesso tempo “friendly”.
"Do great things with personality."
dice Deborah Harrison, writer di Cortana. Durante il suo talk presentato in occasione della The Conference 2016, a cui ha partecipato il nostro Nicolò, ha parlato dell’importanza della personalità nel mondo dell’AI (Artificial Intelligence) perché crea connessione, familiarità e fiducia degli utenti non solo nel prodotto o servizio ma anche nel brand. Secondo Deborah, per costruire la giusta personalità bisogna prima di tutto capire chi è il nostro audience. E dunque, tornando a noi, chi userà Jarvis? Cosa proveranno gli utenti quando cercheranno di comunicare con gli oggetti? Come si aspettano di comunicare con Jarvis? Chi NON lo userà? Come si comporteranno nei momenti di difficoltà? Sono tutte domande che noi ci siamo posti sin dall’inizio, non trascurando mai l’empatia che ci ha aiutato nelle nostre scelte durante tutto il processo di design.
L’empatia gioca un ruolo fondamentale nella progettazione dei prodotti o servizi digitali, soprattutto se si parla di internet fo things. Gli utenti avranno a che fare tutti i giorni con questi oggetti che entreranno nelle loro case, ed è necessario prendere in considerazione tutti gli aspetti dell’esperienza che può comprendere anche i momenti più problematici in cui l’utente avrà bisogno di aiuto. Per questo motivo per noi era importante che Jarvis parlasse ai propri utenti in maniera adeguata alle loro aspettative e che prevedesse i problemi creando un contesto di empatia, fiducia e di facile comprensione.
George Orwell, in Down and Out in Paris and London 1933 spiega l'empatia così: "If you see somebody begging under a bridge you might feel sorry for them or toss them a coin, but that’s not empathy, it’s sympathy or pity. Empathy is when you have a conversation with them, try to understand how they feel about life, what it’s like sleeping outside on a cold winter’s night." Considerare sempre questi aspetti nell’iterazione tra uomo e device, macchina o intelligenza artificiale, porterà ad avere in futuro tecnologie e oggetti smart con un approccio empatico e sempre di più costruiti intorno alle persone e ai loro bisogni.
Questo punto ci ha portato inevitabilmente ad apprendere la quarta e la quinta lezione.
Lezione 4:
Accordarsi su che cosa renda l’ecosistema davvero intelligente.
Durante il primo mese di lavoro abbiamo sfoltito la lunga lista di idee e funzionalità che si stavano ipotizzando per il prodotto. Riguardando oggi la quantità di cose progettate e contenute nel primo MVP non riusciamo a non vedere quanto fosse sproporzionato rispetto a quello che sarebbe davvero servito (questa lezione è figlia della lezione 2).
Il fatto che sia tecnologicamente possibile collegare molti oggetti tra loro e farli funzionare da soli, non significa che siano di per sé intelligenti e che lo sia per osmosi anche l’ecosistema. Da questo punto di vista, la parola “smart” applicata a un oggetto solo perché è in grado di essere connesso ed essere controllato via internet è eccessiva, crea false aspettative negli utenti.
Un oggetto può diventare smart se l’ecosistema che lo fa funzionare è smart, diversamente è solo un oggetto in grado di farsi vedere e controllare via internet.
Come si può introdurre l’automagia in modo che un utente ne veda e apprezzi davvero il beneficio? Consentire ad un utente di creare una regola che metta in relazione due oggetti è solo l’inizio. L’automagia arriva quando l’ecosistema inizia a leggere da solo la situazione e a suggerire da solo automatismi preziosi o addirittura inaspettati e sorprendenti per gli utenti.
Ci sono oggetti adatti a creare atmosfere e ambienti, altri oggetti in grado di controllare i consumi, altri oggetti che sono di fatto spie rilevatrici e così via. Da ognuno di essi, l’utente si aspetta un grado minimo di magia e di informazioni, ottenendo così un minimo servizio. Aggiungere funzionalità ad oggetti di categorie diverse non è la strada giusta per rendere il servizio migliore e dare l’impressione che l’ecosistema sia davvero intelligente.
Ma allora qual è la strada giusta?
La definizione di intelligenza in un progetto di Internet of Things è un faro che deve guidare tutte le scelte di design, sviluppo e servizio. Ed è forse la prima grossa ipotesi / assunzione da validare pensando in termini di processo lean.
Lezione 5:
Fare experience design per un progetto di Internet of Things significa fare service design.
Un progetto di Internet of Things è intrinsicamente un progetto di service design, lo abbiamo imparato in particolare con la terza lezione. Non è possibile progettare per questo tipo di esperienza digitale senza tenere conto di ciò che accade nel mondo fisico e del servizio sotterraneo che serve per garantire che tutto quanto stia in piedi e funzioni in modo fluido e sicuro per l’utente finale.
Operativamente parlando,
per quanta progettazione facciamo per il canale digitale, altrettanta dovremmo farne per immaginare ciò che può accadere nel mondo fisico. In questo modo, le soluzioni progettate avrebbero un impatto sull’intero ecosistema, non solo sulla sua porzione digitale.
All’inizio del progetto sentivamo il bisogno di vedere questi oggetti, di toccarli con le nostre mani e di capire come avrebbero comunicato tra loro, con l’hub e con l’utente. È stata “naturale” l’esigenza di recuperare diversi oggetti in ufficio e far finta che fossero gli oggetti smart del kit: il protagonista, l’hub, era interpretato da una scatoletta di metallo; gli oggetti invece, erano dei bicchieri di plastica sui quali abbiamo scritto il nome del sensore che rappresentavano. Dopo aver disposto i nostri finti oggetti in ufficio abbiamo iniziato a simulare l’installazione e il pairing di ogni sensore, appuntandoci i momenti critici e quelle che potevano essere delle idee o delle opportunità. All’inizio lo abbiamo fatto da sole, successivamente abbiamo replicato coinvolgendo il team Iooota. Questo approccio è stato davvero illuminante per tutti e ci ha aiutato ad avere una visione olistica dell’esperienza.
Successivamente ci siamo rese conto di avere utilizzato inconsapevolmente uno strumento che appartiene al mondo del Service Design, nello specifico il service storming mescolato all’interaction relabeling, strumento di prototipazione veloce.
In cosa consistono nello specifico?
Il service storming è un’attività collaborativa incentrata sull’esplorazione di nuovo servizio attraverso la recitazione. È molto utile per testare in prima persona l’esperienza, generando ipotesi e validando assunzioni velocemente. Soprattutto, ti permette di pensare “out of the box”. E poi è molto divertente :)
L’interaction relabeling consiste nella reinterpretazione degli oggetti. È anche questa un’attività di gruppo durante la quale i partecipanti prendendo oggetti esistenti utilizzandoli facendo finta che siano il prodotto/i che si sta progettando.
Entrambi gli strumenti sono stati introdotti da Anna e Marianna dopo quattro giorni di UX Intensive a Copenhagen. Se non lo avete ancora letto, in questo post abbiamo raccolto il diario di quell'esperienza.
Il service design è l’altro lato dell’experience design.
Osserviamo gli ultimi progetti su cui abbiamo lavorato negli ultimi due anni e notiamo che ormai il service design è semplicemente l’altro lato dell’experience design. Per noi è giunta l’ora di esplorare a fondo questo territorio e aumentare il valore che il design può esprimere guardando insieme i due lati della medaglia.
