it-swarm-eu.dev

Quando utilizzare le persone basate sui dati e quando crearle?

Sto studiando HCI e l'attenzione per la creazione di persona nel mio corso è decisamente che le persone dovrebbero essere derivate dai dati di ricerca degli utenti. L'anno scorso ho anche partecipato all'intensivo percorso adattivo e anche la giornata di ricerca degli utenti è stata in questo campo. Tuttavia, recentemente ho avuto alcune conversazioni con persone che sembrano suggerire che va bene "inventarle".

Qualcuno ha qualche indizio su quando è meglio andare con qualsiasi tecnica - o si riduce semplicemente a budget e costrizioni temporali?

8
alison

IMHO La linea di fondo è che tutte le persone dovrebbero essere guidate dai dati, dopo tutto sono uno strumento per rappresentare l'utente nel processo di progettazione/sviluppo e come tali dovrebbero essere create con gli attributi dell'utente di destinazione.

Tuttavia, tutte le persone dovrebbero essere create con dati "specifici del cliente"? Pragmaticamente non la penso così. Esistono dati sufficienti per supportare personaggi comuni per prodotti comuni. Che a volte può essere sufficiente, soprattutto perché UCD non è ancora pervasivo nel ciclo di vita di progettazione/sviluppo.

Ad esempio: un sito Web per la gravidanza avrebbe diverse persone:

  • Donna incinta
  • nuova madre
  • eccetera.

Immagino che ci siano abbastanza dati sul web che consentirebbero alcune persone convincenti basate su dati rilevanti.

Dove puoi impazzire, è nella narrazione. Adoro abbellire, renderli reali. Uso diverse immagini, immagino una famiglia e tendo a chiamarle come persone del mio programma TV preferito.

HTH

Opaco

post scriptum durante la creazione di persone, ti preghiamo di non dimenticare l'anti-persona per cui non stai creando il design.

7
Matt Goddard

Penso che tutte le persone dovrebbero essere guidate dai dati.

Se insisti a costruire personaggi in base ai tuoi sentimenti o alle tue ipotesi, fai attenzione alla trappola dell '"utente elastico".

Ecco le mie citazioni preferite su "l'utente elastico" da " I detenuti gestiscono l'asilo" di Alan Cooper:

Ogni volta che sento la frase "l'utente", mi sembra "l'utente elastico". L'utente elastico deve piegarsi, allungarsi e adattarsi alle esigenze del momento. Tuttavia, il nostro obiettivo è progettare software che si pieghi, si allunghi e si adatti le esigenze dell'utente. I programmatori hanno scritto innumerevoli programmi per questo mitico consumatore elastico, ma semplicemente non esiste .

Quando il programmatore trova conveniente scaricare l'utente nel file system di Windows per trovare le informazioni di cui ha bisogno, definisce l'utente elastico come un computer accomodante -literare l'utente esperto. Altre volte, quando il programmatore trova conveniente guidare l'utente attraverso un processo difficile con un mago senza cervello, definisce l'utente elastico come un ingenuo, ingenuo , primo utente.

L'utente elastico, utente elastico, concede semplicemente al progettista/ingegnere la licenza di fare ciò che vuole senza studio da parte dell'utente e creando la facciata del centralità dell'utente.

Assicurati che i tuoi personaggi siano basati su ricerche sull'uso reale.

A proposito, penso che Steve Portigal abbia una forte opinione su questo argomento: niente più personaggi.
Persona Non Grata

7
asker

Nella mia esperienza, le persone "supposte" cadono rapidamente in disuso perché il team di sviluppo non ci crede. Abbiamo una lista di controllo di 7 articoli con cui controlliamo i nostri personaggi prima di inviarli a un cliente:

  1. La persona si basa su interviste contestuali con clienti reali?
  2. La persona evoca empatia includendo un nome, una fotografia e una narrativa rilevante per il prodotto?
  3. La persona appare realistica alle persone che hanno a che fare con i clienti tutti i giorni?
  4. Ogni persona è unica, avendo poco in comune con le altre persone?
  5. La persona include obiettivi di alto livello attinenti al prodotto e include una citazione che indica l'obiettivo chiave?
  6. Il numero di persone è abbastanza piccolo da consentire al team di progettazione di ricordare il nome di ciascuna, con una delle persone identificata come primaria?
  7. Il team di sviluppo può utilizzare la persona come strumento pratico per prendere decisioni di progettazione?
6
David Travis

Potresti non trovare questo metodo utile quando sei a scuola, ma una volta che lavori, questo può essere un modo per ottenere qualcosa di cui hai bisogno e un'opportunità per educare sul valore della ricerca degli utenti.

Quando non sono disponibili ricerche, ma si desidera utilizzare "personas" come metodo per aiutare a dirigere la progettazione, creo quelli che io chiamo "profili" dell'utente.

Il contenuto non viene mai inventato, invece, deriva dagli input del team aziendale (questo potrebbe includere qualcuno delle vendite, dell'assistenza clienti, del call center ecc.).

È chiarito molto al team di business/agli stakeholder che questo è inferiore a una persona reale e che una persona si basa sempre e solo sulla ricerca dell'utente. Sottolineo anche i rischi e sottolineo che il contenuto proviene dai loro input, non da una fabbricazione da parte del team di progettazione.

Ciò può spesso incoraggiare il team aziendale a consentire all'utente di convalidare i profili con utenti reali per trasformarli in personaggi. I "profili" hanno anche una fedeltà inferiore con meno contenuti, perché senza input da parte degli utenti reali il contenuto sarebbe limitato. Ciò può anche aiutare il team aziendale a vedere dove ci sono lacune nelle proprie conoscenze sui propri utenti.

Per fare questo, conduco un seminario con il team aziendale come gruppo. Questo è fondamentale per sensibilizzare l'opinione pubblica su dove si trovano come gruppo nelle loro conoscenze.

I profili vuoti vengono pubblicati sul muro (ad es. Immagini di silhouette, non volti/titoli di base), il resto è vuoto.

Vengono fornite istruzioni, un campione e una panoramica del tipo di informazioni attese e del tipo di domande che dovrebbero porre.

Ognuno è dotato di una serie di note adesive e un pennarello.

Il gruppo è suddiviso in numero di profili.

A seconda delle dimensioni del gruppo, vengono dati 4 - 10 minuti per scrivere tutto ciò che sanno su un determinato utente e pubblicarlo. Quindi ciascun gruppo ruota per altri 4 - 10 minuti ecc. Fino a quando ciascun gruppo ha avuto input su ciascun profilo.

Quindi il facilitatore fa una passeggiata attraverso ciascun profilo per chiarire eventuali note appiccicose vaghe o confuse.

Il team di progettazione prende gli input, fa un modello di affinità (raggruppa le note adesive in base a ciò che hanno in comune) crea riassunti del contenuto sotto forma di una persona semplice (quello che chiamo profilo) che include una "storia" di un paragrafo e informazioni sull'utente "nuvole" (pensa alle nuvole di tag, ma per un riepilogo dei risultati degli utenti) ad es "l'efficienza è la chiave" "tempo limitato" "brand driven" ecc.

Quindi incontra nuovamente il team aziendale e presenta i risultati per un'ulteriore convalida. Questa è l'occasione per dimostrare eventuali lacune e incoraggiare il team aziendale a consentire al team di progettazione di convalidare le informazioni con gli utenti finali.

Nel peggiore dei casi, fornisce al team di progettazione una certa direzione fornendo al team aziendale informazioni dettagliate sul perché la ricerca degli utenti è fondamentale.

3
Jenni Walker

Anche se sono d'accordo sul fatto che le persone guidate dai dati siano più affidabili, ci sono situazioni in cui possono beneficiare di input più soggettivi.

Ad esempio, quando il tuo cliente ha accesso a una banca di dipendenti con il contatto quotidiano dell'utente finale (come gli operatori del call center). In questo caso, penso che sia utile ascoltare le opinioni del personale con questo tipo di conoscenza dell'utente finale, e può valere la pena organizzare "seminari sulla persona" per ottenere le informazioni.

2
Ali

Di recente ho visto il seminario virtuale UIE su Ad Hoc Personas di Tamara Adlin. Sono stati discussi due tipi di persona con due scopi molto diversi. (Vedi http://www.uie.com/events/virtual_seminars/ad_hoc_personas/ - è disponibile un video di anteprima.)

1) Le persone basate sui dati sono più uno strumento di progettazione del prodotto e si basano su dati utente/di utilizzo effettivi.

2) I personaggi ad hoc vengono creati utilizzando le informazioni che l'organizzazione ha già a portata di mano. Sono uno strumento di comunicazione per concetti e possono aiutare a mantenere concentrati un team o le parti interessate. Possono anche essere utilizzati come fase di preparazione (un'ipotesi verificabile) per le persone basate sui dati.

Il fatto è che la maggior parte delle aziende ha già "personas" - idee su chi sia la loro base di utenti. A volte questo si basa sui dati e a volte questo è un mito aziendale. Adlin afferma che "I personaggi nascosti possono provocare danni ai prodotti" e sono d'accordo. Quindi è meglio avere un'idea condivisa di personaggi.

Il webinar è stato buono e ha avuto alcune idee creative per riproporre la tecnica della persona e fare davvero delle persone ad hoc. Lo consiglierei per espandere il tuo concetto di persona.

2
UXtina

Sono d'accordo che deve essere basato sulla ricerca.

Se sei interessato all'argomento, suggerirei che l'Utente ha sempre ragione da Steve Mulder e Ziv Yaar, che è un ottimo libro.

Lo puoi trovare su Google Libri o Amazon .

1
Zoltán Gócza