Come dice il nome, il need finding è l'attività della Human-Computer Interaction (HCI) finalizzata alla conoscenza dei bisogni dell'utente.

Il need finding è fondamentale, perché ci permette di individuare esattamente:

  • Problemi dell'utente;
  • Le sue frustrazioni;
  • Il modo di fare;
  • Necessità;
  • Obiettivi.

Il need finding, quindi, ci consente di pensare e progettare un prodotto orientato ai bisogni di chi lo utilizzerà.

Esistono diversi metodi (che qualcuno chiama query techniques) per acquisire le informazioni sui bisogni degli utenti, tra cui interviste e questionari. Prima di vederli, è importante fissare a mente che durante il need finding:

  • Dobbiamo essere aperti a scoperte impreviste;
  • Dobbiamo considerare il contesto: l'ambiente in cui conduciamo il need finding, il tipo di utente, le sue abilità, etc;
  • Dobbiamo notare differenze e similarità tra le persone;
  • Dobbiamo cercare di non influenzare i test;
  • Dobbiamo fare attenzione alla percezione dell'utente.

Prima di andare avanti, facciamo una pausetta con questa frase:

Le soluzioni anticipate limitano le possibilità di capire il problema e le sue possibili soluzioni.

Carina, vero?

Query Techniques: come fare il need finding

Abbiamo cinque modi di raccogliere informazioni:

Interviste

Prendiamo una persona in target, e conduciamo una breve intervista finalizzata a capirne i need.
Alcuni preferiscono prepararsi una scaletta di domande, altri invece una scaletta di argomenti, da modulare in base al carattere di chi abbiamo davanti e a come procede l'intervista.

A ogni modo è importante essere preparati per evitare di far perdere tempo alla gente.

Stephen Colbert - gotta go

Ci sono delle domande — o meglio, delle formulazioni di domande — che andrebbero evitate, perché possono darci delle informazioni sbagliate, imprecise, esagerate, o comunque poco utili. Queste riguardano:

  • Scenari ipotetici: le persone tendono ad affrontare queste domande in modo aspirativo, cioè rispondendo nel modo che loro credono ci si aspetti da loro. Invece dovremmo prima capire qual è il modo di fare dell'utente, le sue abitudini, e come ha affrontato alcuni problemi simili.
  • Domande che contengono una risposta: "quindi non hai avuto problemi con x?". È facile fare questo errore in certi momenti del laddering (che vedremo tra poco). È meglio evitare di dare alle persone dei mezzi suggerimenti a cui sicuramente si aggrapperanno.
  • Domande troppo generiche: se non approfondite, si rivelano perdite di tempo.
  • Domande con risposta scontata: tollerabili solo per capire se l'intervistato è distratto, pazzo, o ci sta prendendo in giro.
  • Richiesta di consigli o suggerimenti di design: cosa facciamo a fare un corso di HCI se poi facciamo disegnare l'app a un tizio a caso in mezzo alla strada?
  • Frequenze di eventi: "quante volte mangi la pizza in una settimana?". Il problema di queste domande è che richiedono alla gente di fare una stima abbastanza complicata, a mente e senza preparazione. A una domanda del genere io non saprei rispondere, a meno che non mangiassi la pizza esattamente n volte a settimana. In caso contrario, dovrei stimare una frequenza basandomi su ciò che ricordo. Invece conviene chiedere "ricordi l'ultima volta che hai mangiato la pizza?", e la risposta già ci da una migliore inquadratura.

Utenti notevoli

Abbiamo tre categorie di utenti che possono darci informazioni utili durante il need finding:

  • Lead user - gli early adopters dei prodotti:
    • Autonomi;
    • Abbastanza competenti;
    • Beneficiano delle innovazioni;
    • Tirano fuori dei nuovi need.
  • Extreme users - usano servizi con assiduità (es. per lavoro):
    • Hanno i need amplificati;
    • Anche loro sono competenti e autonomi.
  • Esperti del dominio:
    • Hanno conoscenze astratte;
    • Hanno dati aggregati utili;
    • Hanno qualche studio utile.

Prima di andare avanti, tira fuori un paio di esempi per le prime due categorie.
Domanda: se uso IFTTT ed ho almeno una applet che mi collega l'email a qualcosa, posso dire di essere un extreme user dell'email?

Modalità di conduzione delle interviste

Abbiamo cinque tecniche cumulabili e personalizzabili: con una spesa minima di €99

  • Laddering: approfondire in profondità, ad esempio chiedendo di continuo "perché?";
  • Cultural context: domande finalizzate a capire il contesto;
  • Intercepts: una sola domanda secca;
  • Process mapping: farsi descrivere un processo;
  • History: capire il comportamento facendosi descrivere sequenze di eventi.

Riassumendo:

  • Ci sono alcune domande da evitare;
  • Ci sono 3 utenti notevoli;
  • Ci sono 5 tecniche per condurre le interviste;
  • Extra: ovviamente dobbiamo prendere appunti;
  • Extra: se siamo in due è più comodo (uno parla, l'altro scrive);
  • Extra: possiamo registrare l'audio (chiedendo il permesso);
  • Bonus: se questa persona è molto interessata al progetto, magari ci facciamo dare un indirizzo email per ricontattarla in futuro.

Questionari

A differenza delle interviste, i questionari sono orientati all'analisi e ci danno più dati in meno tempo. Anche per i questionari valgono le considerazioni riguardo formulazioni da evitare.

I questionari possono sia essere cartacei che elettronici, ed esistono diversi servizi per crearli (es. Google Forms).

In giro ci sono tantissimi questionari fatti male, ed è facilissimo fare di meglio. In un buon questionario dovremmo:

Evitare errori grammaticali: banale, lo so.

Usare un linguaggio opportuno: se il questionario è rivolto a medici, è meglio dare del lei; se è rivolto a studenti universitari, conviene rilassare i toni e non annoiare.

Forzare l'utente a sbilanciarsi: ad esempio impostando un numero pari risposte alle domande a scelta multipla, in modo che l'utente non possa selezionare la risposta neutrale.

Impedire all'utente di fare scelte incoerenti: quante volte abbiamo visto domande fatte così?

Quali app di messaggistica usi?

  • [ ] WhatsApp;
  • [ ] Telegram;
  • [ ] Slack;
  • [ ] Nessuna di queste.

Cosa succede se io seleziono anche l'ultima opzione?

Questo punto infatti si riduce all'utilizzo di controlli/widget adatti alla domanda (radio buttons, checkboxes, risposta libera, scala, etc).

Utilizzare la logica condizionale: supponiamo di voler mostrare un set di domande diverso, a seconda dell'app di messaggistica che l'utente usa. I servizi di creazione di questionari generalmente permettono di creare roba come (ma anche più complessa di):

  • Se l'utente risponde --> mandalo alla sezione X;
  • Se risponde No --> fai finire il questionario.

Questo ti consente anche di rafforzare il punto precedente.

Come capiamo se il questionario é funzionante e scritto bene? Test pilota: osserviamo una persona mentre risponde al questionario, e prendiamo nota di incomprensioni, problemi, o in generale di cose migliorabili; dopo ogni test sistemiamo il questionario.

In genere bastano 3-5 persone per trovare l'80% dei problemi.

Riassumendo:

  • I questionari ci danno dati quantitativi;
  • Fare un questionario migliore dei 90% che circolano è facile;
  • Richiedono un test pilota.

Diari

Questa query technique prevede la raccolta di informazioni per tempi prolungati.

Camera studies

Qui registriamo a video gli utenti nel contesto, e cerchiamo di capire i loro need dai comportamenti.

Pager studies

Domande precise ad un momento preciso (es. voto alla qualità della videochiamata).


Task e Storyboard

Dal need finding produciamo un elenco di need.
Di questi need tiriamone fuori alcuni più interessanti, da cui deriveremo dei task.

Un task è un obiettivo dell'utente per soddisfare un suo need.

Per esempio in un'app di messaggistica, alcuni task possono essere:

  • Creazione di una nuova chat;
  • Creazione di un nuovo gruppo;
  • Invio di un allegato.

Per ogni task ci interessa uno scenario, cioè:

  • Problema alla base e azione da compiere;
  • Contesto;
  • Utenti e ruoli coinvolti;
  • Ruolo dell'interfaccia;
  • Contesto dopo l'esecuzione del task.

Possiamo rappresentare graficamente queste informazioni con uno storyboard, cioè un disegnino stupido che descrive l'idea generale del task.

Uno storyobard molto semplice

Gli storyboard devono essere:

  • Disegnati su carta;
  • A mano libera;
  • Veloci;
  • Facili da leggere;
  • Poveri di testo;
  • Privi di UI.

Perché? Perché non vogliamo perderci tempo.

In conclusione

In questo articolo abbiamo visto che esiste il need finding, e sappiamo perché è importante. Abbiamo visto alcune tecniche per farlo, ed approfondito interviste e questionari. Poi abbiamo visto che dall'analisi dei need possiamo trovare dei task, che confluiscono negli storyboard.

Adesso possiamo andare avanti col prototyping, in cui realizziamo e testiamo pezzi di interfaccia.

Se vuoi essere avvisato quando uscirà il prossimo articolo, lascia la tua email qui sotto ;)