Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

ottobre: 2019
L M M G V S D
« Ott    
 123456
78910111213
14151617181920
21222324252627
28293031  

Categorie


Client Scenarios e agile UX

AlbertoAlberto

Segnalo un lavoro di Davide Bolchini (ricercatore universitario a Indianapolis) che mi ha sbloccato un problema piuttosto noto che semplifico: come rappresentare le esigenze business del cliente durante la raccolta dei requisiti (o, di solito, durante un brief veloce con i manager)?

In effetti spesso ci troviamo nella situazione in cui gli obiettivi business di un progetto sono completamente diversi da quelli dell’utente. Come risolvere questa contraddizione o, come la chiama Davide, questa tensione tra obiettivi dei clienti e degli utenti?

Nel paper “Exploring the tension between User’s and Main Stakeholder’s goals: the role of Client Scenarios” (pdf) Davide ci propone la sua ricetta:

Client Scenarios […] allow modeling main stakeholder’s goals in relationship to (and not separately from) the requirements for the user experience.
[…] a client scenarios describes what main stakeholders want the user to do on the website.
[…] client scenarios are thus key intruments during analysis that allow stakeholders to project their own goals on the desired user experience, this making these goals much more concrete and visible as requirement-design input.
[…] main stakeholders have their own expectations with respect to the behavior of the user. The want the user to do preferably certain tasks, rather than others, and this is fundamental to meet the communication and business objectives of the main stakeholders.

In pratica si tratta di riuscire a portare il cliente a definire degli scenari che descrivano quello che si vorrebbe che l’utente facesse per soddisfare un obiettivo business.

Esempio: se un cliente ha l’obiettivo di vendere più prodotti per ogni cliente, uno scenario semplificato potrebbe essere “l’utente deve essere invogliato ad acquistare più prodotti” o qualcosa del genere.

Questo approccio non è affatto semplice, perché nella mia esperienza un cliente di solito:

  1. dichiara un obiettivo business (“aumentare le vendite”, “migliorare la percezione del brand”, …)
  2. non ha idea di come immaginare uno scenario utente che porti al raggiungimento dell’obiettivo
  3. si aspetta che designer/web agency/whatever si occupi di far raggiungere l’obiettivo agli utenti.

Riformulo per essere più chiaro: il cliente e/o il manager spesso ha un’obiettivo business in mente e pensa che sia un nostro compito quello di tradurlo in qualcosa che l’utente faccia (la fantomatica “interazione”), salvo poi criticare random le soluzioni proposte. L’idea è di coinvolgerlo in questo processo di “traduzione” degli obiettivi business in un formato user-side, per stabilire un’idea chiara e condivisa su come dovrà funzionare il sistema per l’utente.

Forse l’idea dei client scenarios non è nuova e magari qualche “agile expert” mi dirà che esisteva già uno strumento del genere. Rimane il fatto che solo oggi, dopo anni, mi è chiaro come lavorare per riuscire a tirarli fuori da un meeting iniziale con il cliente.

D’ora in poi quando mi diranno “voglio migliorare la percezione del brand”, la mia risposta sarà: “e come ti immagini uno scenario di un utente che cerca di migliorare la sua percezione del vostro brand?”. La difficoltà sarà di non accettare la risposta “questo dovete dirmelo voi, è per questo che vi paghiamo”: l’obiettivo è definirlo assieme al cliente (ecco è questo il punto a cui volevo arrivare, se ti eri un po’ perso).

Per concludere, questo modello si incastra perfettamente con l’idea agile di spezzettare il progetto in scenari e user stories: i client scenario vengono introdotti e si integrano completamente con gli altri scenari. Da quel momento in poi sono scenari uguali agli altri e il processo di lavorazione rimane lo stesso, però garantisce di essere focalizzati (anche) sui reali obiettivi business del cliente.

Consiglio comunque di leggersi il lavoro di Davide e anche le altre sue ricerche. E ne approfitto per ringraziarlo qui pubblicamente per i contributi di qualità che ci ha messo a disposizione.

ps: qualcosa di molto simile l’ho trattato parlando di come impostare inizialmente un progetto e di come definire le priorità di un progetto. Poi ci sono altri miei post sul tema agile-ux.

Comments 7
  • Cristiano Siri
    Posted on

    Cristiano Siri Cristiano Siri

    Author

    Alberto, ho letto il paper e l’ho trovato molto interessante, però gli ho dato un’interpretazione leggermente diversa.

    Quando tu dici:

    “Da quel momento in poi (i client scenario) sono scenari uguali agli altri e il processo di lavorazione rimane lo stesso, però garantisce di essere focalizzati (anche) sui reali obiettivi business del cliente.”

    io capisco che presi gli scenari utente e quelli client come input vado a progettarne la sintesi dando ad entrambi luguale “peso”.

    Io invece interpreto il paper come: dedotti gli scenari utente dalla ricerca con/sugli utenti posso circoscrivere l’area di quella che Davide indica in figura 2 come “Allowed User Experience”.

    Quindi i client scenario mi saranno da guida in quelle scelte di design che avvengono in quello spazio. Le scelte rimarranno comunque all’interno di quel perimetro definito dalla ricerca sugli utenti (diventando la Desirable User Experience della figura 2).

    Ossia un client scenario non dovrebbe portare a scelte di design fuori dalla Allowed User Experience.

    In sintesi secondo me sono ottimi fari guida, ma la loro luce rimane nel recinto dei bisogni degli utenti. Quindi non sono uguali, ma pesano meno degli scenari utente.

    Sono abbastanza convinto che quando il cliente ci chiede invece di andare fuori dalla Allowed User Experience noi si debba dirgli: se lo facciamo il tuo prodotto sarà meno attrattivo ed efficace.

    Poi se farlo o meno dipende dalla relazione commerciale.


  • Alberto
    Posted on

    Alberto Alberto

    Author

    sì, mi sono resto conto anch’io della questione e forse ho spiegato male cercando di concludere.

    sto leggendo un altro suo paper “Capturing vision and goals to inform communication design” ed è un po’ peggio rispetto a quello che dici tu 😉

    diciamo che, ammesso che questa logica consideri la ricerca con gli utenti (al momento mi sembra non la consideri), in pratica lui dice che bisogna elicitare gli scenari, da cui derivare le motivazioni degli utenti e i loro obiettivi. insomma: in realtà i client scenario delimitano eccome, quindi le storie non si possono “unire”, ma bisogna cercare un’intersezione (o banalmente prendere per buoni quegli scenari utente e derivare le user stories).

    chissà cos’avranno da dire a riguardo Gianandrea e Jacopo, che credo prima o poi leggeranno.


  • Jacopo Romei
    Posted on

    Jacopo Romei Jacopo Romei

    Author

    @Cristiano Perché il concetto di ‘Allowed user experience’ farebbe pesare i client scenario meno degli scenari utente? Non si parlerebbe allora di “Allowed business experience”? Il vincolante regna sul vincolato, giusto?

    In generale, Alberto, mi chiedo: perché ritieni che tutto ciò si leghi così fortemente al tema ‘agile UX’? Chiedo senza una risposta in mente.

    Gianandrea lo aspettiamo al varco. Il Motivational Design suo e di Folletto, agendo sul complesso motivazionale dell’utente, è un approccio che fin dai primi tempi ho sempre pensato adatto a rispondere alla domanda “e come ti immagini uno scenario di un utente che cerca di migliorare la sua percezione del vostro brand?”


  • Cristiano Siri
    Posted on

    Cristiano Siri Cristiano Siri

    Author

    Dottor Romei, potrebbe riformulare la domanda? 🙂


  • Alberto
    Posted on

    Alberto Alberto

    Author

    l’ho legato all’agile ux semplicemente perché è un “filo rosso” qui nel mio blog, ben sapendo che un purista avrebbe storto il naso 😉