Come scopri cosa vogliono veramente gli utenti? [chiuso]

https://stackoverflow.com/questions/415260

user-experience

03-07-2019
|

Domanda

Ho letto da qualche parte (ho dimenticato la fonte, scusate, penso che il blog dello sviluppatore di MS Office?), che quando fate un sondaggio tra gli utenti chiedendo loro quali funzionalità vorrebbero vedere nel vostro software / sito Web, il più delle volte diranno che vogliono tutto, mentre le metriche raccolte mostrano che alla fine la maggior parte delle persone non usa il 99% di queste funzionalità. Il messaggio generale dal post sul blog era che non dovresti chiedere alle persone cosa usano, dovresti seguirlo da solo.

Questo porta a una sfortunata situazione di pollo e uova quando si cerca di capire quale nuova funzione aggiungere dopo. Senza la funzione già attiva, non riesco a misurare quanto viene effettivamente utilizzato. Con risorse limitate (e gravemente allungate), non posso nemmeno permettermi di aggiungere tutte le funzionalità e quindi rimuovere quelle non utilizzate.

Come scopri cosa sarà utile ai tuoi utenti? Se un sondaggio è l'unica opzione, devi strutturare le tue domande in determinati modi (es: non mostrare un elenco di possibili funzionalità, dal momento che li porterebbe avanti)?

Soluzione

Contrariamente alla credenza popolare, non chiedi loro. Bene, non li ascolti quando ti dicono ciò che vogliono. Li guardi mentre usano quello che hanno adesso. Se non hanno nulla, li ascolti abbastanza da dare loro un prototipo, quindi li guardi usarlo. Il modo in cui una persona utilizza il software ti dice molto di più di quello che dice effettivamente di voler. Guarda cosa fanno per scoprire di cosa hanno davvero bisogno.

Altri suggerimenti

Offri loro le opzioni e disponile in ordine di importanza. Come hai detto, gli utenti vorranno tutto, ma ciò ti consentirà di dire ciò che desiderano di più.

Diglielo. Allora lo saprete entrambi.

(No, i tuoi utenti non ti diranno cosa vogliono. Funziona. Se gli utenti volessero più lavoro da fare, non sarebbero alla ricerca di software per fare il loro lavoro per loro.)

Un aneddoto di una vita precedente:

Stavamo pianificando una nuova versione e volevamo aggiungere alcune nuove funzionalità all'applicazione. Abbiamo riunito gli utenti e abbiamo fatto il brainstorming di ciò che volevano vedere nel sistema, posizionando ciascuna "funzione". su un giallo appiccicoso su una lavagna bianca. Abbiamo quindi raggruppato richieste simili ed eliminato duplicati o quasi duplicati.

Abbiamo quindi posato ciascuno appiccicoso su un tavolo con una tazza di fronte. Ogni utente ha ricevuto 10 penny per "votare" sulle caratteristiche che volevano. Potevano mettere tutti i penny in ogni tazza che volevano, fino a tutti i penny in una tazza se lo desideravano. Abbiamo quindi contato il numero di centesimi in ogni tazza e abbiamo scelto di implementare i primi 5 vincitori di voti, in ordine di voti.

È stato sorprendente vedere persone appassionate di una caratteristica mentre il brainstorming e la categorizzazione si voltano e non votano per quella caratteristica (o votano leggermente per essa).

Ovviamente, una tecnica come questa funzionerà solo se si ha accesso immediato alla propria base di utenti (questo era per un sistema aziendale sviluppato internamente).

Glielo chiedi.

(No, non sai cosa vogliono i tuoi utenti meglio di loro. Sì, otterrai molte risposte stupide. Evita sondaggi a scelta multipla e opta invece di rivedere le risposte in formato libero. Le informazioni che raccoglierai essere prezioso.)

Ovviamente, puoi sempre consentire ai tuoi utenti di votare su quali funzioni preferiscono ...

Gli utenti sanno cosa non vogliono meglio di quanto sanno cosa vogliono.

Avevamo portato un team a fare un'implementazione di Oracle eBusiness Suite. Hanno adottato un approccio interessante che aveva funzionato molto bene per loro in passato. Ma è stato fenomenale nel nostro ambiente.

Avevamo problemi culturali, il che significava che nessuno degli utenti avrebbe tirato fuori il collo per dire quello che voleva. Ho avuto una storia con gli utenti del passato. Cercare di ottenere requisiti da loro era come cercare di ottenere sangue da una pietra. Ma una volta che sei andato in diretta, la stronza avrebbe avuto inizio.

Il team di implementazione ha comunque installato Oracle eBusiness Suite immediatamente. Fornire agli utenti la formazione di base. Quindi circa ogni 4 settimane per i successivi 6 mesi hanno personalizzato l'installazione di base per soddisfare i reclami.

Vorrei raccomandare di non mostrare loro le opzioni; come fai notare, se è disponibile, le persone lo vorranno solo per il gusto di averlo. Spesso gli utenti non sono consapevoli dei costi aggiuntivi per lo sviluppo di una particolare funzione e la vogliono semplicemente perché hai menzionato la possibilità di averla.

L'altra opzione è quella di mostrare un elenco di tutte le funzionalità che potresti eventualmente aggiungere, quindi allegare un prezzo a ognuna e quindi chiedere agli utenti, varrebbe la pena $ X per avere la funzione Y o, quanto extra saresti disposto a pagare per la funzione Y?

Mangia il tuo cibo per cani

Prova a utilizzare l'applicazione che ti scrivi il più possibile. Quindi saprai come migliorare la tua applicazione.

Secondo il 37 Signals - Getting Real libro, non fai nulla, non lo fai anche registrare ciò che vogliono, basta eliminare i messaggi dopo una lettura senza alcuna azione.

Quando si tratta di implementare / riparare cose, ricorderete le cose più importanti che i vostri utenti desiderano dalla testa. Ovviamente questo richiede un po 'di utenti.

Devi abbinare le funzionalità al costo. Tutti vogliono funzionalità, ma non tutte le funzionalità meritano di essere pagate. Chiedi quali sono le funzionalità più importanti, per quali sarebbero disposti a pagare i tuoi utenti? Sviluppa le funzionalità in base alle priorità fornite dagli utenti e fermati quando non sono più disposti a pagare. Metti il ??prodotto nelle loro mani il più rapidamente possibile in modo da ottenere un feedback reale su ciò che non funziona e ciò che deve essere aggiunto. Quando gli utenti hanno accesso a software reali, ottieni informazioni molto migliori. Funziona meglio quando si sta sviluppando specificamente per un particolare cliente. Se non hai accesso a clienti reali, prendi in considerazione l'idea di seminare il tuo prodotto con persone (puoi dire beta pubblica?) Gratis per ottenere un feedback migliore.

Gli utenti non sanno quali funzionalità desiderano. Non sai quali funzionalità potrebbero essere offerte. & Quot; Caratteristiche " non significano nulla se non perché li aiutano a svolgere compiti e raggiungere obiettivi. Ed è qui che dovresti iniziare, perché avranno una comprensione molto imperfetta su come si collegano.

C'è una cosa che sanno, forse, molto meglio di te. Ed è così che il loro lavoro viene svolto.

Non appena i concetti e la terminologia di computer / software iniziano a penetrare nella discussione tra utenti e progettisti, sei fuori dai binari.

Tante volte gli utenti focalizzeranno i loro requisiti in termini di cosa c'è di sbagliato o potrebbero essere migliorati sul software che usano attualmente. Nel tempo, anche loro perdono la distinzione tra i loro lavori e il software che usano per fare i loro lavori.

È un problema molto difficile e di fondamentale importanza per te risolverlo.

L'unico modo per sapere cosa sono veramente gli utenti " è necessario " essere " l'utente. Il suo livello di cintura nera di programmazione kung fu.

" Sii come l'acqua che si fa strada attraverso le crepe. Non essere assertivo, ma adattati all'oggetto e troverai un modo per aggirare o attraversarlo. Se nulla dentro di te rimane rigido, le cose esteriori si riveleranno da sole. Svuota la tua mente, sii informe. Senza forma, come l'acqua. Se metti dell'acqua in una tazza, questa diventa la tazza. Metti l'acqua in una bottiglia e diventa la bottiglia. Lo metti in una teiera diventa la teiera. Ora, l'acqua può fluire o può schiantarsi. Sii acqua amico mio. & Quot;

Quando sarai il cliente / acqua, ora lo farai.

Penso che Bruce Lee sarebbe un buon programmatore.

Sono molto serio. Questo è il modo in cui lavoro. Non posso fare cose che non capisco, quindi devo capire prima di fare le cose. Quando capisco, e i miei clienti sanno che capisco, allora posso fare un buon lavoro. Senza capire ci saranno equivoci. Sei l'unica persona che sa quando hai il giusto livello di comprensione, sei anche la persona responsabile di ottenere quella conoscenza.

L'oracolo di Delfi

Pro: la precisione è eccezionale Contro: se riesci a interpretare i messaggi, che molte persone non riescono a fare (vedendo spesso ciò che vogliono vedere). Richiede anche supplica, che può diventare confusa (contrariamente all'opinione popolare, la tua hecatomb non deve necessariamente essere 100 dello stesso tipo di bestiame).
Legale

Pro: preciso fino a un certo punto.

Contro: raro. Tendente all'instabilità mentale, altamente vulnerabile agli esseri disonesti, e potrebbe attirare da loro l'attenzione indesiderata. Inoltre, ci vuole esperienza per risolvere il mistero che è la mente umana per ottenere le informazioni desiderate. E a volte hai ancora bisogno di sondare i soggetti mentre stanno effettivamente facendo ciò di cui hanno bisogno di aiuto, poiché gli utenti mentono.
Pianta una talpa

Pro: nuovi gadget. Nuovi veleni! Piani all'interno di piani all'interno di piani. Baby è uno spettacolo strano. Potresti imparare ogni sorta di cose affascinanti oltre alle informazioni di cui hai bisogno per aiutare l'utente.

Contro: costoso. È probabile che l'agente si rivolga a te o non riesca a imparare qualcosa che non potresti imparare più semplicemente. Se scoperto, l'organizzazione probabilmente trasformerà o liquiderà l'attività, il che rappresenta un enorme investimento di risorse. L'organizzazione potrebbe ricambiare.
Indovinate

Pro: prendi un gruppo di persone con immaginazioni medio-grandi e capacità di risoluzione dei problemi, dai loro un po 'di alcol e ispirali con alcune citazioni di Ghostbusters, Big Trouble in Little China o The Big Lewbowski. Chissà dove andrà, ma sarà divertente e potrebbero produrre qualcosa di interessante / utile.

Contro: le possibilità di soddisfare le esigenze degli utenti sono più alte di quanto si pensi, ma non così buone.
Chiedi all'utente

Pro: gli utenti si sentono abilitati come parte del processo.

contro: fino a quando non devono decidere qualcosa, a che punto sei da solo. A meno che l'utente non sia un utente molto esperto, nel qual caso probabilmente hanno una buona idea di ciò che desidera. Tuttavia, ci sono solo 4 utenti esperti sul pianeta e nessuno conosce mai nessuno che riesca a fare un lavoro per loro. Possono essere bestie mitiche.
Fingi di preoccuparti e chiedi all'utente (anche se non lo fai davvero), quindi osservali mentre fanno qualsiasi flusso di lavoro / processo / ecc. chiave e presta attenzione a ciò che fanno.

Pro: induci gli utenti a pensare che la loro opinione sia importante, il che li autorizza ma non consegna altri bagagli. Dal momento che gli utenti mentono - nessuna mente intenzionalmente o maliziosamente - puoi effettivamente vederli in azione e ottenere una migliore comprensione di quale sia il problema, offrendo così una base migliore per la costruzione di una soluzione. Inoltre, eviti la via psichica, e quindi eviti una strada lunga e tortuosa che inizia con la promessa, ma termina con te e lo psichico che viene mangiato da qualcosa di mostruoso e indicibile che non è di questo mondo. Osservare il processo è come totalmente Zen, il che è positivo per il tuo sviluppatore Mystique.

Contro: nessun viaggio sull'oracolo (che sarebbe EPIC). Le spie sono molto più sexy; i pulcini scavano le spie. Ghostbusters | Big Trouble in Little China | I Big Lewboski probabilmente non sono coinvolti. Sembra più un lavoro che il resto delle opzioni.

Chiedere agli utenti le funzionalità richiederà loro di parlarti delle funzionalità.

Se vuoi scoprire cosa vogliono gli utenti veramente , stai parlando della comprensione dei loro obiettivi e motivazioni. Ho trovato il modo più semplice per iniziare a fare questo sono le interviste agli utenti, non sulle funzionalità ma su come gli utenti utilizzano il tuo prodotto e prodotti simili, perché lo stanno usando e come si adatta alla loro vita.

Una volta che hai capito cosa stanno cercando di fare i tuoi utenti con il tuo prodotto e perché vogliono farlo, sei in grado di dare un giudizio informato sul fatto che le funzionalità richieste dalle persone siano ciò di cui hanno veramente bisogno.

Idealmente, penso che il tuo problema riguardi la comprensione degli utenti piuttosto che l'ascolto delle loro richieste.

Questa è una vecchia domanda con già molte buone risposte, ma ho pensato di aggiungere solo un po 'di esperienza personale per il bene delle persone che finiranno qui in futuro attraverso una ricerca come ho fatto io.

Se il tuo progetto non ha bisogno di guadagnare un pubblico il più rapidamente possibile per avere successo (come una webapp) se si tratta più di un progetto interno o di un prodotto da vendere per un cliente fisso o tipo di cliente, allora io credi che la tua scommessa migliore sia quella di seguire la strada dei 37 segnali: dai ai tuoi utenti il ?? minimo assoluto di cui hanno bisogno per svolgere inizialmente i compiti più elementari del ciclo di lavoro più elementare, quindi ascolta quello che dicono è oggettivamente mancante per consentire loro di svolgere correttamente il proprio lavoro. Non quello che vogliono o vorrebbero , ma ciò di cui hanno bisogno . E l'unico modo per sapere con certezza ciò di cui hai veramente bisogno è quando non ce l'hai.

Ho lavorato come designer nel team di sviluppo di un "cuore dell'azienda" basato su intranet app che ha seguito quella strategia e i risultati sono stati meravigliosi. Prima settimana: tutti erano incazzati. Al termine, il 90% + di approvazione e l'app era ancora semplice e bella. E la maggior parte delle persone che non erano completamente soddisfatte sembravano capire perché non poteva essere come volevano, e la richiesta principale di quasi tutti era, qualunque cosa facessimo, rendere semplice l'app.

Ancora una volta, se stai lavorando su un prodotto o sito Web che deve prima attrarre le persone, potrebbe non essere fattibile o ritardare molto le cose. Ma se hai un certo controllo o margine di manovra sulla base di utenti, consiglio vivamente questo approccio.

Non si richiedono funzionalità. Chiedete problemi. Punti di dolore. Scopri cosa odiano della loro soluzione attuale. Scopri cosa si nutre del loro tempo.

Quando sai cosa non gli piace, allora crei la soluzione a questi problemi.

Quando risolvi problemi reali, stai creando prodotti reali per cui le persone ti daranno volentieri soldi.

Ma l'importante è rispettarli durante la fase di ricerca. I sondaggi sono ancora ottimi per fare ricerche, ma se fai loro una dozzina di domande, ti odieranno. Devi rispettare il loro tempo e utilizzare uno strumento di sondaggio che li coinvolge e lascia una grande impressione.

È un dato di fatto che gli utenti non sanno cosa vogliono. Quello che devi chiedere loro è cosa c'è che non va in quello che c'è adesso - quali problemi stanno avendo con il tuo software? perché non usano la funzione xe il controllo y? perché l'interazione x ha funzionato per loro mentre l'interazione y li ha fatti provare a distogliere lo sguardo?

Naturalmente per essere in grado di porre queste domande, è necessario fare alcuni studi sul campo e vedere quali funzionalità vengono utilizzate, quali modelli i tuoi utenti esibiscono e analizzano quei dati. Tale analisi fornirà la base per domande molto più specifiche a cui gli utenti sono in grado di rispondere in modo deciso e preciso.

Se sei serio, li registrerai sul loro lavoro e poi analizzerai ciò che stanno cercando di realizzare e come il tuo prodotto può aiutarli. Questo fa parte di un'intera disciplina chiamata ingegneria dell'usabilità. Una buona introduzione alla tecnica è il libro di Jakob Nielsen Usability Engineering . Prima di diventare un imbroglione spudorato, Jakob era un ottimo scienziato e ha imparato molto sui modi economici per capire di cosa hanno bisogno gli utenti. Particolarmente buono se hai un budget limitato. Ciò che mi ha colpito di più è stato l'utilizzo di prototipi di carta ; questo è un ottimo modo per simulare software che non hai ancora creato e aiuta a rispondere alla tua domanda su cosa costruire successivamente. Fino a quando non ho visto questa tecnica in azione, non potevo credere quanto potesse essere efficace.

P.S. Un esempio di ciò che accade se si chiede alle persone: il 90% delle richieste di funzionalità per Microsoft Office 2007 riguardava funzionalità già presenti in Microsoft Office 2003. In quel caso ciò di cui gli utenti avevano bisogno erano modi migliori per trovare quello che era già lì. Vorrei poter trovare dove ho letto su questo ... mi dispiace non avere un riferimento.

Suppongo in base alla tua formulazione che stai costruendo un prodotto da vendere e non costruendo qualcosa da ordinare per un cliente specifico.

In quel contesto, direi che dovresti iniziare diventando tu stesso un utente e costruendo le funzionalità di cui hai bisogno nel modo che preferisci. Man mano che evolvi il prodotto, avrai bisogno di feedback da altri utenti, ma questo almeno questo ti avvia e interrompe il ciclo delle uova di gallina.

Per quanto riguarda la misurazione dell'utilizzo effettivo delle funzionalità, puoi creare un forum di discussione per ottenere un feedback sulle funzionalità che hai aggiunto ... non hai bisogno di nulla di troppo complicato se sei a corto di tempo.

Personalmente mi piace l'approccio senza mani dei clienti. Ti danno requisiti di alto livello e tu fornisci l'implementazione. Il tuo team di software / società / divisione dovrebbero essere gli esperti. Sicuramente commetterai degli errori, se è orribile il cliente eseguirà il pipe e lo risolverai, ma in genere avere l'implementazione a te e ai tuoi sviluppatori è un dilemma divertente da risolvere.

Ricerca, ricerca, ricerca. Impara dagli altri design, quindi crea il tuo design kickass. Non è facile, ma di nuovo non pagano nulla agli sviluppatori.

Questa è una buona domanda.

Se stai costruendo un gioco FPS, devi davvero sapere da solo cosa dovrebbe essere incluso, perché il 99% dei tuoi utenti non ti contatterà mai per dire "Vorrei che il tuo gioco avesse solo X". Un team esperto di beta test può aiutarti qui.

Se stai scrivendo un'applicazione di contabilità, devi capire il settore e ciò che gli utenti stanno cercando di realizzare quando usano il tuo prodotto e cercare di focalizzare il tuo set di funzionalità attorno a quegli obiettivi.

Se stai scrivendo un'app personalizzata per 100 utenti in un'azienda, potresti chattare con la dozzina di utenti più avidi del software. Sono quelli che conoscono tutti i moduli frontalmente, hanno scoperto tutti i tasti di scelta rapida non documentati e hanno anche capito come aggirare molte delle tue regole di convalida dei dati.

Immagina di essere loro

Usa casi.

Che cosa faranno con quella funzione?

Funziona così.

Le persone intraprendono azioni. Sviluppiamo software per aiutarli a compiere azioni
Per intraprendere un'azione una persona deve prendere una decisione. Sviluppiamo software per aiutarli a prendere decisioni.
Per prendere una decisione di agire, una persona ha bisogno di informazioni. Sviluppiamo software per raccogliere e presentare informazioni.

Ogni funzione deve essere un'azione, una decisione o un'informazione. E la connessione dovrebbe essere diretta. Le informazioni che non portano a una decisione o un'azione non sono nemmeno "belle da avere". - è spazzatura.

Gli utenti dicono molte cose. Che cosa fanno ? Quali decisioni prendono? Di quali informazioni hanno bisogno?

Modifica

Nota che non tutti sono bravi a descrivere i casi d'uso. Alcune persone non hanno visione e ti diranno semplicemente cosa fanno oggi senza capire come stanno creando valore aziendale (o personale). Potrebbero davvero non sapere quali decisioni dovrebbero prendere e sono vaghe sulle informazioni di cui hanno bisogno.

Altri utenti sanno quale valore creano e perché, e possono discutere bene dei casi d'uso. Possono immaginare modi alternativi per creare valore; possono articolare opzioni per le loro azioni. Le decisioni non hanno molte implementazioni alternative (le persone prendono decisioni, non il software) e neanche le informazioni richieste non cambiano molto.

Guardali.
Identifica i colli di bottiglia nel loro lavoro
Crea qualcosa che risolva questo collo di bottiglia in modo elegante
Lasciatelo usare
Ripeti fino a quando tutti sono felici

Basato sui principi:

Gli utenti sanno cosa vogliono, ma loro non so di cosa hanno veramente bisogno .
SEI MAI andando a fare la cosa giusta prima volta.

Sembra un problema con pollo e uova. Proprio come il PageRank di calcolo. Il ranking di una pagina dipende dal PageRank di altre pagine che si collegano a quella pagina. Un modo di calcolare PageRank è tramite iterazione.

L'iterazione è la chiave!

A. Votare

Raccogli un elenco biiiig di funzionalità che tutti gli utenti desiderano (rendile loro elencare ogni funzione che desiderano).
Quindi invitali a rivedere l'elenco e consentire loro di votare le funzionalità. Dì, dai loro 100 punti da distribuire sulle funzionalità. Possono dare più di 1 punto a una funzione.

B. Analisi

Analizza il modello di business, elenca le funzionalità che ritieni necessarie. Ciò è necessario perché:

gli utenti a volte non ottengono il massimo foto
hai questo DAVVERO fantastico idea che gli utenti non penseranno in a bajillion anni.

C. Implementare

Analizza l'elenco da A e B, unisci, rimuovi alcuni, migliora alcuni. Implementare.

D. Prova

Provalo sugli utenti. Ascolta le loro lamentele. Guarda a - funzionalità che usano spesso - cose su cui rimangono bloccati - etc etc etc

E. Iterate

Di solito, gli utenti non sanno sempre cosa vogliono e se vogliono qualcosa. Nella nostra azienda i venditori vanno ai clienti esistenti e potenziali, mostrano loro il nostro prodotto e spiegano loro perché lo desiderano disperatamente.

Nel mio periodo universitario ci hanno insegnato qualcosa chiamato "sviluppo guidato dall'utente". Qui devi davvero andare dal cliente, osservare come lavorano le persone lì, quali strumenti usano e provare a scoprire cosa potrebbe facilitare la loro vita. Quindi creare un mock-up, andare di nuovo al cliente, presentarlo agli utenti, ottenere il loro feedback e quindi procedere per migliorare il proprio mock-up. Quando tutti più o meno accettano la linea di condotta, esegui l'implementazione, mostrando regolarmente al cliente cosa stai cercando di ottenere il feedback di correzione il più presto possibile.

Importante non è parlare con i gestori che desiderano il prodotto, ma con gli utenti che useranno il prodotto. Altrimenti l'intero gioco non ti porterà nulla.

P.S. Chiedere loro direttamente " Cosa vuoi? & Quot; potrebbe essere una domanda pericolosa ... Babylon 5 - Cosa vuoi?

Si chiama Ricerche di mercato.

No, questo non è stato uno scavo per il ragazzo, è davvero di questo che si tratta. Certo, ci sono un sacco di tecniche che le persone UCD usano sul campo per ottenere i requisiti degli utenti, ma sono esattamente gli stessi strumenti utilizzati dai ricercatori di mercato. Ordinamento delle carte, elenchi di priorità e così via sono tutti termini di ricerca di mercato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow