Como você descobrir o que os usuários realmente querem? [fechadas]

https://stackoverflow.com/questions/415260

user-experience

03-07-2019
|

Pergunta

Eu li em algum lugar (I esquecer a fonte, desculpe? - Eu acho que o blog do desenvolvedor MS Office), que quando você faz uma pesquisa com usuários pedindo-lhes sobre o que caracteriza que eles gostariam de ver no seu software / website, eles vão mais frequentemente do que não dizer que eles querem cada pequena coisa, enquanto métricas coletadas mostram que, no final, a maioria das pessoas não usam 99% desses recursos. A mensagem geral do post foi que você não deve perguntar às pessoas o que eles usam, você deve segui-lo para si mesmo.

Isto leva a uma situação de galinha e do ovo infeliz ao tentar descobrir o novo recurso para adicionar ao lado. Sem o recurso já no lugar, eu não posso medir o quanto ele está realmente sendo usado. Com finitos (e severamente esticados) recursos, eu também não pode dar ao luxo de adicionar todos os recursos e, em seguida, remover os não utilizados.

Como você descobrir o que será útil para os usuários Se uma pesquisa é a única opção, você tem de estruturar suas perguntas em determinadas maneiras (por exemplo:? Não mostram uma lista de possíveis recursos, uma vez que seria levando-on)?

Solução

Ao contrário da crença popular, você não perguntar-lhes. Bem, você não ouvi-los quando eles dizer o que eles querem. Você vê-los enquanto eles usam o que eles têm agora. Se eles não têm nada, você ouvi-los o suficiente para dar-lhes um protótipo, então você vê-los usar isso. Como uma pessoa realmente usos software lhe diz muito mais do que o que eles realmente dizem que querem. Veja o que eles fazem para descobrir o que eles realmente precisam.

Outras dicas

dar-lhes opções e tê-los organizá-los em ordem de importância. Como você disse, os usuários vão querer tudo, mas isso permitirá que você para dizer o que eles querem mais.

Você dizer-lhes. Em seguida, ambos de vocês sabem.

(Não, seus usuários não vão dizer o que eles querem. Isso de trabalho. Se os usuários queriam mais trabalho a fazer, eles não estariam procurando software para fazer o seu trabalho para eles.)

Uma anedota de uma vida anterior:

Nós planejamento para um novo lançamento e queria adicionar alguns novos recursos para o aplicativo. Temos os usuários juntos e pensaram em como as coisas que eles queriam ver no sistema, colocando cada "recurso" em uma pegajosa amarela em um quadro branco. Em seguida, agrupados pedidos semelhantes juntos e eliminou duplicatas ou perto dups.

Em seguida, pôs cada pegajosa sobre uma mesa com um copo na frente dele. Cada usuário tem 10 centavos para "voto" sobre as características que eles queriam. Eles poderiam colocar como muitos tostões em cada copo como eles queriam, até todos os seus tostões em um copo, se assim o desejar. Em seguida, contou o número de moedas de um centavo em cada copo e escolheu para implementar as top 5 votados, a fim de votos.

Foi surpreendente ver pessoas que estavam apaixonados um recurso enquanto o brainstorming e por sua vez categorização redor e não voto para essa característica (ou voto levemente para ele).

É claro, uma técnica como esta só irá funcionar se você tem acesso imediato a sua base de usuários (isto era para um sistema corporativo que desenvolvemos internamente).

Você perguntar-lhes.

(Não, você não sabe o que seus usuários querem melhor do que eles. Sim, você vai ter um monte de respostas estúpidas. Evite levantamentos de múltipla escolha e, em vez optar por rever de forma livre respostas. A informação que coletamos vontade ser inestimável.)

Claro - você sempre pode permitir que os usuários voto em que as características que mais gosta ...

usuários saber o que eles não querem melhor do que eles sabem o que querem.

Nós tinha trazido uma equipe faço uma implementação Oracle eBusiness Suite. Eles tomaram uma abordagem interessante que tinha trabalhado muito bem para eles no passado. Mas foi fenomenal em nosso ambiente.

Tivemos problemas culturais que significava que nenhum dos usuários estavam indo para furar o pescoço para fora para dizer o que eles queriam. Eu tinha história com os usuários do passado. Tentando conseguir obter requisitos fora deles era como tentar tirar sangue de uma pedra. Mas uma vez que você entrou no ar a putaria iria começar.

De qualquer forma a equipe de implementação instalado o Oracle eBusiness Suite em linha reta fora da caixa. Dar aos usuários o treinamento básico. Em seguida, a cada 4 semanas para os próximos 6 meses, eles personalizado a instalação da base para acomodar as queixas.

Eu recomendaria contra mostrando-lhes opções; como você aponta, se estiver disponível, então as pessoas vão querer que apenas por uma questão de tê-lo. Muitas vezes, os usuários não estão cientes dos custos adicionais de desenvolver uma característica particular, e só quer porque você mencionou a possibilidade de tê-lo.

A outra opção é para mostrar uma lista de todas as características que você poderia adicionar e, em seguida, anexar um preço para cada um, e, em seguida, pedir aos usuários, seria de US $ X para ter recurso Y, ou, quanto extra você estaria disposto a pagar por recurso Y?

Coma seu próprio alimento de cão

Tente usar o aplicativo que você escreve-se tanto quanto possível. Então você vai saber como você pode melhorar a sua aplicação.

De acordo com a 37 Signals - Obtendo livro real , você não fizer nada, você não até mesmo gravar o que eles querem, você só mails de exclusão após um ler sem qualquer ação.

Quando se trata de implementar / fix coisas que você vai se lembrar das coisas mais importantes que seus usuários querem de topo de sua cabeça. Obviamente, isso requer uma base de usuários bit.

Você precisa amarrar recursos para o custo. Todo mundo quer características, mas não todas as características vale a pena pagar. Pergunte quais recursos são mais importantes, o que os usuários estão dispostos a pagar para? Desenvolver recursos com base nas prioridades fornecidos por usuários e parar quando eles não estão dispostos a pagar por mais nada. Obter o produto em suas mãos o mais rápido possível para que você possa obter feedback real sobre o que não funciona e o que precisa ser adicionado. Quando os usuários têm acesso a software real, você fica muito melhor informação. Isso funciona melhor quando você está desenvolvendo especificamente para um determinado cliente. Se você não tem acesso a clientes reais, considere semear o seu produto com as pessoas (você pode dizer, beta pública?) Livre, a fim de obter melhor feedback.

Os usuários não sabem quais as características que eles querem. Você não sabe quais as características que poderiam ser oferecidos. "Características" não fazer nada média, exceto como eles ajudá-los a realizar tarefas e atingir metas. E é aí que você deve começar, porque eles vão ter uma compreensão muito imperfeita como eles se relacionam.

Há uma coisa que sei, talvez, muito melhor do que você. E é assim que para fazer seus trabalhos.

Assim que o computador / conceitos de software e terminologia começar a vazar para a discussão entre os usuários e designers, você está fora dos trilhos.

Então, muitas vezes os usuários vão concentrar as suas necessidades em termos do que é errado com, ou poderia ser melhorado sobre o software que eles usam atualmente. Ao longo do tempo, mesmo que eles perdem a distinção entre os seus empregos, e o software que eles usam para fazer seus trabalhos.

É, um problema muito difícil criticamente importante para você resolver isso.

A única maneira de saber o que os usuários "realmente" necessidade é a de "ser" o usuário. Seu nível de faixa preta de programação kung fu.

"Seja como a água fazendo o seu caminho através de rachaduras. Não ser assertivo, mas ajustar-se ao objeto, e você deve encontrar uma forma redonda ou através dele. Se nada dentro de você permanece rígida, as coisas externas, irão disponibilizar-se. Esvazie a sua mente, ser sem forma. Disforme, água como. Se você colocar água em um copo, ela se torna o copo. Você coloca água em uma garrafa e ela se torna a garrafa. Você colocá-lo em um bule de chá, torna-se o bule. Agora, a água pode fluir ou pode falhar. Seja água meu amigo. "

Quando você ser a água / cliente, você agora.

Eu acho que Bruce Lee seria um bom programador.

Im muito sério. Esta é a minha maneira de trabalhar. Eu não posso fazer coisas que eu não entendo, então eu tenho que entender antes de eu fazer as coisas. Quando eu entendo, e meus costomers sabe que eu entendo, então eu posso fazer um bom trabalho. Sem compreender haverá missunderstandings. Você é a única pessoa que sabe quando você tem o nível correto de compreensão, você também é a pessoa que é responsável para obter esse conhecimento.

O Oráculo de Delfos

Pros: a precisão é excelente Contras: se você pode interpretar as mensagens, o que muitas pessoas não conseguem fazer (muitas vezes ver o que eles querem ver). Também requer súplica, que pode ficar confuso (ao contrário da opinião popular, a sua necessidade hecatombe não ser 100 do mesmo tipo de gado).
Psychics

Prós:. Precisão de um ponto

Contras: raro. Propenso a instabilidade mental, altamente vulneráveis ??aos seres sobrenaturais, e pode atrair atenção indesejada a partir deles. Além disso, é preciso experiência para classificar através do mistério que é a mente humana para obter a informação desejada. E às vezes você ainda precisa investigar assuntos enquanto eles estão realmente fazendo a coisa que eles precisam de ajuda com, desde que os usuários se encontram.
Plante uma toupeira

Pros: Novos gadgets. New venenos! Planos dentro de planos dentro de planos. Bebê é um show de horrores. Você pode aprender todos os tipos de coisas fascinantes para além da informação que você precisa para ajudar o usuário.

Contras: Caro. Chances permanecer que o agente vai se transformar em você, ou não conseguem aprender qualquer coisa que você não poderia aprender de forma mais simples. Se descoberto, a organização provavelmente vai virar ou liquidar o ativo, o que representa um enorme investimento de recursos. Organização pode retribuir.
Guess

Pros: Pegue um grupo de pessoas com médio para grande imaginação e habilidades para resolver problemas, dar-lhes alguma bebida e inspirá-los com algumas citações de Ghostbusters, Big Trouble in Little China, ou The Big Lewbowski. Quem sabe para onde vai, mas vai ser divertido e eles podem produzir algo interessante / útil.

Contras: Chances de necessidades do usuário reunião são mais elevados do que você pensa, mas não que boa
Peça ao usuário

Prós:. Usuários sentem habilitados como parte do processo

cons: até que eles tem que decidir sobre qualquer coisa, em que ponto você está no seu próprio país. A menos que o usuário é um usuário muito experiente, caso em que eles provavelmente têm uma boa idéia do que o desejo. Há apenas como 4 usuários experientes do planeta, porém, e ninguém nunca sabe qualquer um que consegue fazer um trabalho para eles. Eles podem ser bestas míticas.
Finja que você se importa e pedir ao usuário (mesmo que você realmente não), e depois observá-los fazer o que for chave de fluxo de trabalho / processo / etc está envolvido e prestar atenção ao que eles fazem.

Pros: você enganar os usuários a pensar suas questões de opinião, que capacita-los, mas não entregar qualquer outra bagagem. Desde usuários mentir - não intencionalmente ou maliciosamente mente - você realmente começar a vê-los em ação e obter uma melhor compreensão de qual é o problema, dando-lhe uma base melhor para a construção de uma solução. Além disso, você evita a rota psíquica, e, assim, evitar uma estrada longa e sinuosa que começa com promessa, mas termina com você e ser psíquico comido por alguns monstruoso, coisa indescritível, que não é deste mundo. Observando o processo é como totalmente Zen, que é bom para o seu desenvolvedor Mystique.

Contras: Nenhuma viagem estrada para o Oracle (que seria EPIC). Spies são muito mais sexy; os pintainhos escavam espiões. Ghostbusters | Big Trouble in Little China | The Big Lewboski provavelmente não está envolvido. Parece mais trabalho do que o resto das opções.

pedindo aos usuários sobre os recursos vai levá-los a falar com você sobre os recursos.

Se você quiser saber o que os usuários realmente quer, então você está falando sobre a compreensão de seus objetivos e motivações. Eu encontrei a maneira mais fácil de começar a fazer isso é entrevistas de usuários, e não sobre recursos, mas sobre como os usuários usam o produto e produtos como ele, por que eles estão a usá-lo e como ele se encaixa com a sua vida.

Depois de construir um entendimento de que os usuários estão tentando fazer com o seu produto e por que eles querem fazê-lo você está em uma posição para fazer um julgamento informado sobre se a pessoas solicitados características são o que eles realmente precisam.

Idealmente, eu acho que o problema é sobre os usuários compreensão em vez de apenas ouvir os seus pedidos.

Esta é uma questão de idade com um monte de boas respostas já, mas eu pensei que eu tinha acabado de adicionar um pouco de experiência pessoal para o bem de pessoas que acabam aqui no futuro através de uma pesquisa como eu fiz.

Se o seu projeto não precisa para ganhar um público tão rapidamente quanto possível, a fim de ter sucesso (como um webapp) se for mais de um projeto interno ou produto a ser vendido para um cliente fixo, ou o tipo de cliente, então eu acredita que sua melhor aposta é ir a 37signals maneira: dar aos seus usuários o mínimo absoluto que eles precisam, a fim de realizar as tarefas mais básicas do ciclo mais básico de trabalho no início, em seguida, ouvir o que eles dizem é objetivamente faltando para que eles façam seu trabalho corretamente. Não o que eles deseja ou gostaria que ele tem, mas o que eles realmente necessidade . E a única maneira de saber ao certo o que você realmente precisa é quando você não tem isso.

Eu trabalhava como designer na equipe de desenvolvimento de um aplicativo baseado na intranet "coração-of-the-empresa" que se seguiu essa estratégia, e os resultados foram maravilhosos. Primeira semana: todo mundo estava chateado. Quando acabou, + 90% de aprovação, eo aplicativo ainda era simples e bonito. E a maioria das pessoas que não foram inteiramente satisfeito parecia entender por que ele não poderia ser como eles queriam, e a principal solicitação de quase todos era, tudo o que fizemos, mantenha a simples aplicação.

Novamente, se você está trabalhando em um produto ou site que precisa atrair pessoas em primeiro lugar, que pode não ser viável ou atrasar as coisas muito. Mas se você tem algum controle ou margem de manobra sobre a base de usuários, eu definitivamente recomendo esta abordagem.

Você não pode pedir para os recursos. Você pedir problemas. Pontos de dor. Descubra o que eles odeiam sobre a sua solução atual. Descubra o que come no seu tempo.

Quando você sabe o que eles não gostam, então você construir a solução para esses problemas.

Quando você resolver problemas reais, então você está criando produtos reais que as pessoas terão prazer em dar-lhe dinheiro para.

Mas o que é igualmente importante é respeitá-los durante a sua fase de pesquisa. Pesquisas ainda são grandes para fazer a pesquisa, mas se você perguntar-lhes uma dúzia de perguntas, eles vão te odiar. Você precisa respeitar o seu tempo e usar uma pesquisa ferramenta que os envolva e deixa uma grande impressão.

É um fato comprovado que os usuários não sabem o que querem. O que você precisa perguntar-lhes o que está errado com o que existe agora - quais os problemas que estão tendo com o seu software? porque eles não estão usando x recurso e controle y? porque interação x trabalhou para eles, enquanto interação y fez tentar avaliar seus olhos para fora?

Claro que para ser capaz de fazer essas perguntas, você precisa fazer alguma pesquisa de campo e ver quais recursos são utilizados, quais os padrões de seus usuários expor e analisar esses dados. Essa análise vai lhe dar a base para questões muito mais específicas que os usuários são capazes de responder de forma decisiva e precisa.

Se você é sério, você videotape-los em seu trabalho, e então você quebrar o que eles estão tentando realizar e como seu produto pode ajudá-los. Isso faz parte de uma disciplina inteira chamada engenharia de usabilidade. Uma boa introdução à técnica é o livro de Jakob Nielsen Engenharia de Usabilidade . Voltar antes de se tornar um vendedor ambulante sem vergonha, Jakob era um bom cientista e ele aprendeu muito sobre maneiras baratas de descobrir o que os usuários precisam. Especialmente bom se você estiver em um orçamento. O que mais me impressionou foi usando protótipos de papel ; esta é uma ótima maneira de zombar de software que ainda não construído e ajuda a responder a sua pergunta sobre o que construir ao lado. Até que eu vi esta técnica em ação Eu não podia acreditar o quão eficaz pode ser.

P.S. Um exemplo do que acontece se você só perguntar Pessoas: 90% das solicitações de recursos para Microsoft Office 2007 foram para os recursos que já estavam no Microsoft Office 2003. Nesse caso, o que os usuários precisavam eram melhores maneiras de encontrar o que já estava lá. Eu gostaria de poder encontrar onde eu li sobre isso ... desculpa para não ter uma referência.

Estou assumindo com base no seu texto que você está construindo um produto para vender, e não construir algo a ordem para um cliente específico.

Nesse contexto, eu diria que você deve começar por se tornar um usuário a si mesmo e construir as características que você precisa na maneira que você quiser. À medida que evolui o produto, você vai precisar de comentários de outros usuários, mas isso, pelo menos esta é uma introdução e quebra o ciclo de galinha-ovo.

Como para medir o uso real de recursos, você pode criar um fórum de discussão para obter feedback sobre as características que você adicionou ... você não precisa de nada muito complicado se você estiver com falta de tempo.

Eu, pessoalmente, como as mãos fora abordagem dos clientes. Eles dão-lhe requisitos de alto nível e você fornecer a implementação. Sua equipe de software / empresa / divisão deveriam ser os especialistas. Claro que você vai cometer alguns erros, se a sua horrível o tubo vontade do cliente e você vai corrigi-lo, mas geralmente tendo a implementação até você e seus desenvolvedores é um dilema divertido para resolver.

A investigação, pesquisa, investigação. Aprender com os outros projetos, em seguida, fazer seu próprio projeto kickass. Não é fácil, mas, novamente eles não pagam desenvolvedores as quantias chorudas para nada.

Essa é uma boa pergunta.

Se você está construindo um jogo FPS, você realmente precisa saber para si mesmo que deve ser incluído, porque 99% de seus usuários nunca entrará em contato para dizer "Desejo o seu jogo só tinha X". Uma equipe de testes beta experiente pode ajudar aqui.

Se você estiver escrevendo uma aplicação de contabilidade, você precisa entender a indústria e que os usuários estão tentando realizar quando eles usam seu produto, e tentar focar sua conjunto de recursos em torno desses objetivos.

Se você estiver escrevendo um aplicativo personalizado para 100 usuários em um negócio, você poderia ter uma conversa para as dezenas de usuários de modo mais ávidos do software. Eles são os únicos que sabem todas as formas back-to-frontal, descobriu todas as teclas de atalho sem documentos, e também descobriram como contornar muitas das suas regras de validação de dados.

Imagine que você é deles

Use Cases.

O que será que eles do com essa característica?

Ele funciona assim.

As pessoas tomam ações. Nós construímos software para ajudá-los tomar medidas
A fim de tomar uma ação, uma pessoa deve tomar uma decisão. Nós construímos software para ajudá-los a tomar decisões.
A fim de tomar uma decisão a tomar uma ação, uma pessoa precisa de informações. Nós construímos software para coletar e apresentar informações.

Cada recurso deve ser uma ação, uma decisão ou informação. E a conexão melhor que seja direta. Informações que não conduza a uma decisão ou uma ação não é mesmo "bom ter". - É junk

Os usuários dizem um monte de coisas. O que eles do ? O que é decisões é que fazem? O informações que eles precisam?

Editar

Note que nem todo mundo é bom em descrever os casos de uso. Algumas pessoas não têm visão e simplesmente dizer o que eles fazem hoje sem entender como eles estão criando negócios (ou pessoal) valor. Eles podem não saber realmente o que decisões eles deveriam estar fazendo, e são vagos sobre a informação de que necessitam.

Outros usuários sabem o valor que eles criam, e porquê, e pode discutir bem os casos de uso. Eles podem vislumbrar formas alternativas para criar valor; eles podem articular opções para suas ações. As decisões não têm um monte de implementações alternativas (as pessoas tomam decisões, não de software) e as informações necessárias não muda muito, também.

Watch-los.
Identificar os gargalos em seu trabalho
Criar algo que resolve esse gargalo de uma forma elegante
Deixe-os usá-lo
Repita até que todos estejam felizes

Com base nos princípios:

Os usuários sabem o que querem, mas eles não sei o que eles realmente necessidade .
Você É NUNCA vai acertar na primeira vez.

Parece que um problema da galinha e do ovo. Muito parecido com computação PageRank. page rank de uma página é dependente do PageRank de outras páginas com links para essa página. Uma forma de calcular PageRank é por iteração.

A iteração é a chave!

A. Votação

Reunir uma lista biiiig de recursos a todos os usuários querem (torná-los enumerar cada recurso que eles querem).
Então eles têm que rever a lista e permitir-lhes votação sobre recursos. Digamos, dar em 100 pontos para distribuir em recursos. Eles podem dar mais de 1 ponto para um recurso.

B. Análise

Analisar o modelo de negócio, lista as características que você acha que é necessário. Isso é necessário porque:

os usuários às vezes não recebem o grande imagem
você tem este realmente grande ideia de que os usuários não vão pensar de em um anos bajillion.

C. Implementar

lista de A e B, merge Analisar, remova alguns, melhorar algum. Implementar.

D. Teste

Test-lo sobre os usuários. Ouvir suas queixas. Olhe para - características que eles usam frequentemente - coisas que eles ficam presos em - etc etc etc

E. Iterate

Normalmente, os usuários nem sempre sabem o que querem e se eles querem alguma coisa. Em nossas vendas da empresa as pessoas vão para os clientes existentes e potenciais, mostrar-lhes o nosso produto e explicar-lhes por que eles querem desesperadamente disso.

No meu tempo na universidade nos foi ensinado algo chamado "desenvolvimento orientado a userp toda". Aqui você realmente tem que ir para o cliente, observador como as pessoas lá de trabalho, o que as ferramentas que eles usam, e tentar descobrir o que poderia facilitar a sua vida. Você, então, criar um mock-up, vá para o cliente novamente, apresentá-lo para os usuários, obter seus comentários e depois prosseguir para melhorar o seu mock-up. Quando todos mais ou menos igual ao curso de ação, você faz a implementação, mostrando regularmente ao cliente o que você tentar obter feedback de correção o mais cedo possível.

Importante não é para falar com os gerentes que querem o produto, mas para os usuários que irão utilizar o produto. Caso contrário, todo o jogo vai lhe trazer nada.

P.S. Pedindo-lhes diretamente "O que você quer?" poderia ser uma questão perigosa ... Babylon 5 -? O que você quer

É chamado de Pesquisa de Mercado.

Não, isso não era uma escavação na cara, isso é realmente do que se trata. Claro, há um monte de técnicas que UCD as pessoas usam no campo para obter as necessidades dos utilizadores, mas eles são exatamente as mesmas ferramentas utilizadas por pesquisadores de mercado. Card Sorting, listas prioritárias e assim por diante são todos os termos de pesquisa de mercado.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow