User Stories | What
Le User Stories sono un tool di design semplice, ma estremamente potente, da applicare all’inizio dei progetti. Un metodo che esalta la collaborazione tra tutti gli stakeholder di progetto che permette di comprendere meglio l’utente medio che si appresta a utilizzare un servizio/prodotto/sito/app.
I quesiti fondamentali da porsi prima di avviare un progetto si possono così riassumere:
- Perchè lo facciamo?
- Chi sono gli utenti?
- Che problemi risolve la nostra soluzione?
- Chi sono i competitor?
- Come misuro il successo del mio progetto?
Inserite all’interno del flusso dell’user centered design, che enfatizza l’importanza della creazione di un prodotto che tenga conto in maniera primaria dell’utente e di tutto il suo environment, le User Stories rappresentano piccole istanze nella quotidianità di una persona, che permettono di capire la prospettiva da cui l’utente guarda il prodotto in questione.
Una user story è corta, specifica e goal-oriented. Uno statement che si può racchiudere in una frase dalla struttura specifica:
Si affiancano al metodo delle user personas, altrettanto importante per inquadrare l’utenza di un prodotto.
User Stories | Why
Tali strumenti permettono di creare empatia con l’utente, facendogli comprendere aspetti del progetto che dapprima venivano ignorati, così come i suoi bisogni, che verranno poi tradotti in feature.
Tale Reality Check permette di dar vita una discussione volta a creare un flusso creativo e di problem-solving (che potremmo qui definire come scomposizione di un problema primario in tanti piccole istanze) tramite una visuale di quello che deve essere portato a termine prima della release del prodotto.
Costituendo un ponte tra il cliente e il team (development + UX/UI), le User Stories permettono di evitare la situazione di seguito raffigurata:
Riassumendo, le User Stories:
- Sono semplici e veloci da comprendere
- Permettono ai programmatori di implementare velocemente
- Non necessitano manutenzione
- Permette di dividere il progetto in milestone più piccole
- Facilitano la cooperazione.
User stories | How
Esistono alcuni determinati Acceptance Criteria che devono rispondere alle seguenti domande:
- Quali sono i possibili input dell’utente?
(es:le opzioni di pagamento sono Visa, Mastercard,…)
- Come reagisce il sistema agli input? Sotto che condizioni? (es: quando il cliente sbaglia codice, appare un errore)
Solitamente vengono fatte attraverso post-it, per rendere ancora più visibile il flusso creativo.
Cosi facendo poi è più immediato raggrupparli in macro-aree.
Gherkin Syntax (“cetriolino”)
E’ una sintassi che permette di “catturare”, in maniera rigorosa e facilmente interpretabile sia da un essere umano che da una macchina, una “user story”:
GIVEN <…>
WHEN <…>
THEN <…>
Se la sintassi usata per descrivere le user stories è definita e non ambigua, allora possiamo utilizzarla per:
- Implementare gli acceptance tests
- (potenzialmente) Implementare la business logic
COME?
Mappando le porzioni che la compongono, scritte in linguaggio naturale, in blocchi di codice applicativo scritte nel nostro linguaggio di sviluppo.
Cucumber (“cetriolo”)
- Permette di “mappare” delle features definite in sintassi Gherkin con il codice di test corrispondente per il linguaggio in uso.
- Supporta moltissimi linguaggio, compresi JS e PHP.
- Supporta implicitamente tutte le lingue (compreso l’italiano)
