shelidonOctober 8, 2020Leave a Comment

Il Design Sprint è un framework per affrontare un problema complesso e proporre costruttivamente soluzioni verificate e approvate: sto provando ad applicarlo alla creazione di una parte della libreria BIM aziendale e in questo articolo vi porto alla quarta giornata, il giovedì, ovvero la giornata della prototipazione.

The big idea with the Design Sprint is to build and test a prototype in just five days. You’ll take a small team, clear the schedule for a week, and rapidly progress from problem to tested solution using a proven step-by-step checklist. It’s like fast-forwarding into the future so you can see how customers react before you invest all the time and expense of building a real product.

Parte 1 (preparazione e mapping, lunedì);
Parte 2 (sketch, martedì);
Parte 3 (decide, mercoledì);
Parte 4 (prototype, giovedì).

1.5. Test (venerdì)

It’s time to put that prototype to the test!
On Friday, you’ll show your prototype to five customers in five separate, 1:1 interviews.
Instead of waiting for a launch to get perfect data,
you’ll quick-and-dirty answers to your most pressing questions right away.

Esattamente come è necessario avere degli esperti da consultare nella giornata di martedì, è necessario avere degli utenti da mobilitare nella giornata di venerdì. Gli utenti devono essere all’interno della target audience individuata lunedì dal decisore.

1.5.1. Makeshift Research Lab

Come nel caso della War Room, di cui si è parlato in relazione alle fasi preparatorie dell’intero sprint, nella giornata di testing il set-up dello spazio fisico è un momento importantissimo. Questo spazio viene chiamato Makeshift Research Lab, laddove makeshift è sinonimo di impromptu, “improvvisato”, nel senso più artistico e meno precario del termine.

Lo spazio viene generalmente suddiviso in due stanze: una stanza in cui viene svolto il test con le relative interviste ed un’altra stanza in cui il team assiste, in diretta, al feed delle interviste.

1.5.2. Interviste

Il numero di persone con cui effettuare il test viene individuato intorno ai cinque, sufficienti per individuare pattern nelle loro reazioni e nei loro feedback.

Le fasi dell’intervista sono generalmente cinque:

1. Benvenuto, in cui l’intervistato viene messo a proprio agio e si mette in chiaro che si sta cercando un feedback onesto;
2. Domande di contesto, in cui si cerca di capire l’approccio, il livello e l’esperienza generale dell’utente rispetto alla questione nel cui contesto si inserisce il prototipo;
3. Introduzione del prototipo, in cui si presenta il prototipo: il prototipo non dovrebbe essere presentato se non nel suo contesto generale, per non falsare l’esperienza spontanea dell’utente, ma questa è la fase in cui si ricorda che si tratta – per l’appunto – di un prototipo, che alcune cose potrebbero non funzionare, e si richiede all’utente di pensare ad alta voce durante la sua esperienza diretta con il prodotto;
4. “Tasks and nudges”: durante l’esperienza diretta del prototipo, l’obiettivo principale è che l’utente comprenda il funzionamento del prototipo in autonomia, ma può essere guidato e “pascolato” da quelli che vengono chiamati nudge o chiedendogli nello specifico di portare avanti specifici task, specialmente lasciato passare un certo lasso di tempo nell’esperienza libera del prototipo;
5. Debrief, in cui vengono poste domande di sintesi e di riassunto.

Nell’altra stanza, il team prende appunti e individua i pattern comuni tra le risposte e nelle esperienze degli utenti.

1.5.3. Wrap up

La conclusione della giornata prevede che l’esperienza degli utenti con il prototipo venga confrontata con l’obiettivo a lungo termine e le domande, i propositi sviluppati tra la prima e la seconda giornata. L’ultimo momento è quella che si potrebbe definire una retrospettiva circa quanto fatto e i risultati ottenuti. Si conclude decidendo quali saranno i prossimi passaggi a seguito dello sprint, per eventuali ulteriori iterazioni del prototipo e per la sua implementazione.

La fase veniva anche chiamata fase di validazione, in precedenti versioni del framework. Trovate alcune informazioni qui.

Per un’alternativa al metodo generale, consiglio anche di dare un’occhiata qui.