Archivi categoria: Product Design e UX

Non solo user stories nel product backlog

Il backlog racconta il nostro prodotto da diverse prospettive.
Sappiamo che finché esiste il prodotto esiste un backlog e che questo è principalmente costituito da user stories, ma non tutto ciò che è contenuto nel backlog deve necessariamente essere una storia.
Lo scopo di questo artefatto è condividere cos’è il prodotto che stiamo realizzando con chi lo deve implementare, validare, utilizzare e – in generale – con tutti coloro che ne sono interessati.
In quest’ottica le user stories potrebbero non essere esaustive.

Come descrivo un’interazione complessa? E l’esperienza utente? Dove condivido i dettagli delle interfacce? Come posso dettagliare gli aspetti di performance e scalabilità del software?
Le user stories a volte non bastano. In generale tutto ciò che può aiutare ad aumentare la comprensione del prodotto e a descriverne l’utilizzo da parte dell’utente finale è un elemento utile.

Nella mia esperienza un buon backlog finisce per contenere tutti questi elementi:
user stories
interazioni
visual design
requisiti non funzionali

Non mi soffermo sulle user stories, di cui abbiamo già parlato a lungo, e che hanno lo scopo di descrivere le funzionalità del prodotto.

Interazioni

A volte le funzionalità che vogliamo realizzare comportano un’interazione complessa.
Sono i casi in cui l’utente deve ad esempio compiere più step per portare a termine un’operazione o casi in cui una singola azione provoca più effetti in diversi punti del sistema.
Pensiamo alle esperienze di acquisto, alle registrazioni mediante social, alla gestione delle proprie mail nella casella di posta.
In questo caso oltre alle user stories sulle singole funzionalità è necessario dettagliare il percorso che dovrà seguire l’utente.
A questo scopo ci vengono in aiuto i diagrammi di flusso, gli scenari e le storyboard.
Mediante questi strumenti possiamo descrivere visivamente i singoli passaggi attraverso cui transita l’utente, verificare di non avere omesso degli step fondamentali e calarci nel suo percorso per verificarne la logica ancora prima di aver dettagliato l’interfaccia.
Con l’interaction design rispondiamo alle domande: come si muoverà l’utente? che cosa potrà fare nel nostro servizio?

Visual Design

Il design è un componente essenziale del successo di un prodotto ed un aspetto sempre più rilevante nei criteri di scelta da parte dell’utente finale.
Nel mondo digitale ci sono aziende di successo che hanno fatto di questa caratteristica il proprio elemento distintivo (pensate a Apple!).
Per comunicare questo tipo di caratteristiche possiamo utilizzare svariati tool: mock-up, sketch e wireframes che emulano la navigazione e le principali interazioni dell’utente finale.
Il ventaglio delle possibilità è ampio, si va dal semplicissimo disegno dell’interfaccia a matita su un foglio di carta al .psd dell’art director definito al pixel (anche se questo livello di dettaglio è eccessivo e controproducente).
Con il visual design rispondiamo alla domanda: cosa vedrà l’utente in ogni singolo step?

Requisiti non funzionali

Definiscono le proprietà e i vincoli di un sistema.
Sono gli aspetti che riguardano – ad esempio – l’usabilità, la scalabilità, le performance di un prodotto, i tempi di risposta.
Sono spesso elementi essenziali per la soddisfazione degli utenti, a volte poco tangibili ma trasversali all’intero servizio e critici per il suo corretto funzionamento.
Sono di solito problemi non indirizzati a livello di MVP (minimum viabile product)  ed anche i primi aspetti che “saltano” quando il time to market è fondamentale nella strategia di prodotto.
Pur essendo così bistrattati sono tuttavia quelle caratteristiche che rendono solido e flessibile un prodotto nel tempo.
Ecco perché prima o poi vi ritroverete a fare i conti con i requisiti non funzionali.
Possono richiedere tempi di implementazione più lunghi rispetto alle funzionalità del servizio ed è opportuno definirli il prima possibile nel corso dello sviluppo in modo tale compiere scelte tecniche e di prodotto in linea con i vincoli che caratterizzeranno il sistema.
Solitamente i requisiti non funzionali non vengono espressi mediante la formula classica delle storie (attore, funzionalità, beneficio), bensì mediante enunciati.
Qualche esempio:
– l’acquisto dei prodotti mediante carrello deve essere disponibile anche  su browser Opera
– il caricamento della pagina di risultati di ricerca deve essere inferiore a 1,5 secondi
– l’area personale deve essere consultabile in mobilità da device Android vers. 4 e superiori
Con i requisiti non funzionali rispondiamo alla domanda: di quali vincoli deve tenere conto lo sviluppo del nostro prodotto?

In sintesi il mio consiglio è questo: non forzate all’interno di user stories qualsiasi tipo di dettaglio di prodotto.
Se avete difficoltà a descrivere una caratteristica mediante la formula who/what/why provate a chiedervi se non avete forse a che fare con requisiti non funzionali, interazioni o aspetti di visual design.
Tutti questi sono elementi determinanti della user experience finale e hanno la dignità di trovare posto nel product backlog.
Più in generale non esitate ad avvalervi di qualsiasi strumento possa generare maggiore chiarezza.
Sperimentate e divertitevi a farlo!

Fallisci presto, impara in fretta: sii Lean!

Build, measure, learn

Il Lean è una cultura orientata a comprendere le esigenze del cliente, ridurre gli sprechi e ottimizzare i processi, una filosofia che potremmo riassumere nel motto “massimo risultato con il minimo sforzo”.

E’ una teoria di organizzazione aziendale che integra al suo interno varie metodologie gestionali.
Obiettivo del Lean è produrre di più con un minor consumo di risorse.
Il termine “lean production” – produzione snella – è stato coniato in riferimento al sistema Toyota, l’azienda automobilistica giapponese caratterizzata da processi industriali ad altissima efficienza rispetto ai principali produttori mondiali di automobili.

Tra i concetti chiave del Lean c’è l’idea del miglioramento continuo (“Kaizen”) perseguito mediante l’applicazione di un processo ciclico in 3 fasi: sperimentazione, misurazione dei risultati e apprendimento (build, measure, learn).

Nel famoso libro di Eric Ries “Lean Start-up” viene più volte ribadito che l’acquisizione di conoscenza è cruciale per il successo di un’iniziativa imprenditoriale:

“Questo è il modo giusto di pensare alla produttività in una start up: non in termini di quanta roba stiamo producendo, ma di quanto apprendimento validato stiamo incamerando per i nostri sforzi.
Ogni bit di conoscenza che raggiungiamo ci suggerisce nuovi esperimenti da fare che muovono le nostre metriche più vicine ai nostri obiettivi.”

Un processo Lean prevede i seguenti step:

  1. Identificare cio’ che vale per gli utenti 
(per cosa sono disposti a pagare un prezzo?)
  2. Identificare il flusso del valore
    definire la sequenza ottimale delle attività per creare valore
  3. Far scorrere il flusso del valore
    eseguire le attività di valore senza inutili interruzioni
  4. “Pull” e non “push”

    fare scorrere il flusso del valore in base alla domanda, non all’offerta
  5. Puntare alla perfezione come punto di riferimento in un contesto di miglioramento continuo

Se applichiamo i principi Lean al mondo del software e in generale della progettazione ritroviamo gli step ciclici di build, measure, learn.

Dobbiamo identificare un problema o un’opportunità di sviluppo e verificare che abbia davvero valore per gli utenti (per questo è necessario acquisire conoscenza dei loro bisogni e e necessità).
Modifichiamo il nostro punto di vista e proviamo a ridefinire il problema dal punto di vista degli utenti. Mettiamoci “nei loro panni”.
Solo a questo punto – quando siamo stati in grado di avere empatia nei confronti di coloro per cui stiamo progettando – siamo in grado di fare brainstorming in maniera proficua e portare soluzioni creative.

Una volta definite la nostra idea ne verifichiamo le assunzioni (cosa stiamo dando per scontato senza averne alcuna prova?) conducendo degli esperimenti.
Possiamo creare un prototipo – il più “lean” possibile – per mettere alla prova l’idea in poco tempo e con il minimo delle risorse per testare la soluzione sul campo e raccogliere feedback quanto prima.

Il confronto reale con i propri utenti ci permette di validare l’idea iniziale raffinandola ulteriormente, di aggiustare il tiro o – in alternativa – di non proseguire oltre.
Anche una soluzione che si rivela totalmente sbagliata è un insegnamento di successo: ci evita lo spreco di realizzare un prodotto/servizio che non ha valore per l’utente finale e ci offre l’opportunità di investire meglio le nostre risorse.

A conti fatti se non puoi fallire, non puoi imparare.

Build, measure, learn