shelidonOctober 6, 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ì).

1.4. Prototype (giovedì)

On Thursday, you’ll build a realistic prototype of the solutions in your storyboard
so you can simulate a finished product for your customers.
Design Sprint prototyping is all about a “fake it till you make it” philosophy:
with a realistic-looking prototype, you’ll get the best possible data from Friday’s test,
and you’ll learn whether you’re on the right track.

Se ricordate, lo storyboard 2.0 era il prodotto con cui ci eravamo lasciati nella giornata precedente, al termine del flusso decisionale che ha portato a definire al massimo 3 idee. Se queste idee erano integrabili all’interno di una singola mappa, di un singolo flusso, avremo una sola storyboard. Se invece le idee non sono integrabili, siamo in presenza di quella che viene chiamata rumble, ovvero lo sviluppo parallelo di diversi prototipi.

L’idea di costruire un prototipo in un solo giorno è ambiziosa, ma si basa su tre presupposti:

1. Tutte le decisioni importanti sono già state prese nelle giornate precedenti, tutte le soluzioni proponibili sono già state proposte, il tempo di discutere e integrare è finito: ciò che il team ha per le mani è ciò che deve essere tradotto nel concreto, nulla di più e nulla di meno;
2. il team può dividere la storyboard in diverse scene e suddividersi i compiti: se la storyboard prevede l’uso di diversi prodotti in diverse fasi del processo, ha senso che siano gruppi diversi ad occuparsi di ogni fase;
3. la suddivisione del lavoro dovrebbe fare in modo di far leva su tutte le predisposizioni, i talenti e le capacità del team.

1.4.1. Scegliere lo strumento

Lo strumento utilizzato per sviluppare il prototipo è fondamentale. Spesso non si tratta di uno strumento per il lavoro quotidiano: si tratta di strumenti, per usare le parole di questo articolo, ottimizzati per la qualità. In questa fase, è necessario usare strumenti che consentano rapide iterazioni, per quanto possano sembrare meno raffinati.
Gli strumenti suggeriti da Jake Knapp e la sua squadra in questa fase sono strumenti come Marvel, InVision, Figma, Keynote, Keynotopia. Si tratta tuttavia di strumenti che prevedono attività specifiche, spesso nell’ambito della User Experience.

Marvel e Figma consentono di lavorare in modo collaborativo su interfacce che possono essere ottimizzate per desktop o per mobile: non è il nostro caso, a meno che il prototipo non sia effettivamente l’interfaccia di ricerca – ad esempio – per un Add-on. In questo caso, o per coprire questa eventualità, si consiglia di aver preparato delle basi che comprendano l’interfaccia base del vostro software di authoring di riferimento: farà risparmiare molto tempo al team.

Trovo InVision leggermente più interessante, perché parte dalla possibilità di affrontare il problema da diverse angolazioni a seconda del proprio ruolo (come si vedrà in seguito, l’assegnazione di ruoli nella fase di prototipazione è uno strumento molto potente per far leva sulle diverse attitudini delle persone nel gruppo). Raccoglie su un’unica piattaforma sia gli elementi di design che i documenti di specifiche.

Keynote è assolutamente inadatto al nostro scopo, tanto quanto lo sarebbe Prezi, e non capirò mai la popolarità di cui gode tra gli accoliti di Apple: è un software per fare presentazioni. Keynotopia è poco più di un power-up.

Nel nostro caso, gli strumenti da esplorare possono chiaramente essere di natura assai differente. Dynamo è una buona sandbox per prototipare il flusso di un add-on, prima di spostarsi in ambienti più seri per l’effettivo sviluppo. Se si tratta di Forge, abbiamo avuto l’occasione di vedere alcuni modi di testare funzioni richiamandole in Postman. Per la prototipazione di un oggetto parametrico tipologico, se di questo ci stiamo occupando, sarebbe paradossalmente possibile utilizzare altri strumenti di authoring. Ricordiamoci che l’obiettivo di questa fase non è realizzare un primo oggetto funzionante, ma realizzare una mock-up di oggetto per testarne il funzionamento. Se obiettivo del testing è verificare la leggibilità di una certa nomenclatura per i parametri, non è completamente folle l’idea di sviluppare il prototipo con un altro strumento. Se chiaramente oggetto della prototipazione è la possibilità effettiva di parametrizzare un oggetto, viceversa, strumenti differenti gestiscono le geometrie in modo differente e quindi si tratterebbe di una cattiva idea.

1.4.2. Assegnare i ruoli

Dopo aver suddiviso la storyboard in parti, se necessario, vengono assegnati i ruoli:

• Maker: incaricato di produrre i componenti del prototipo, solitamente è un progettista o uno sviluppatore (ma nel nostro caso potrebbe anche trattarsi di un esperto di modellazione);
• Stitcher: il ruolo più importante, almeno secondo questo articolo, ovvero quello di chi si occupa di prendere le varie parti e assemblarle nella piattaforma scelta per questo scopo (lo Scrum master è tipicamente un ottimo stitcher, quindi nel nostro caso potrebbe trattarsi di un BIM Coordinator, a meno che non sia già occupato come Maker nel ruolo di power user o come Writer per le specifiche);
• Writer: si occupa di curare il contenuto del prototipo e normalmente si tratta di una persona nel marketing o di un business developer, ma nel nostro caso la situazione è più complessa (potrebbe trattarsi ad esempio del responsabile qualità o di un esperto nella redazione delle specifiche tecniche, dato che nel caso di un prototipo connesso alla libreria buona parte delle sue energie andranno nell’allineamento di concetti e termini, nella nomenclatura degli attributi, nella costruzione di tassonomie, categorie e sottocategorie);
• Asset Collector: è colui che si occupa di raccogliere “asset”, ovvero sottocomponenti da utilizzare nel prototipo. Se il prototipo è ad esempio un flusso di automazione, e per la fase di prototipo si sta utilizzando Dynamo cone Sandbox, il maker si starà preoccupando di sviluppare nodi personalizzati con Dynamo, mentre l’asset collector potrebbe avere l’incarico di trovare librerie con altre funzioni già precompilate, e chiaramente lo stitcher ha il compito di comporre il tutto in uno script. Se viceversa si tratta di un oggetto, l’asset collector potrebbe occuparsi di raccogliere sottocomponenti non direttamente oggetto della prototipazione. Non trasformate l’asset collector in un altro ricercatore di soluzioni: la ricerca delle soluzioni ha già trovato spazio nella seconda giornata.
• Interviewer: parte cruciale nella fase di testing sarà sviluppare un’intervista di efficacia e usabilità, e l’intervistatore ha il compito di iniziare a stilare questa intervista.

Per ulteriori approfondimenti sui ruoli, consiglio questo articolo.

1.4.3. Costruzione del prototipo e testing

Durante la costruzione del prototipo, durante la quale ciascun membro del team porta avanti il proprio ruolo e lo stitcher funge da supervisore per tenere le fila, non bisogna dimenticarsi di svolgere un breve test di fronte al decisore, normalmente svolto intorno alle 15:00.

You can prototype anything.
Prototypes are disposable.
Build just enough to learn, but not more.
The prototype must appear real.

Per ulteriori approfondimenti sulla giornata, consiglio questo articolo.