it-swarm-pt.tech

Como extrair requisitos mais detalhados de UX do usuário

Fazemos lançamentos iterativos e, portanto, vejo um bom número de requisitos de UI/UX de usuário. O que é ótimo para que possamos nos concentrar nas principais áreas.

Naturalmente, essas solicitações estão no formato "O sistema deve ter um botão no lugar Y que faz X" . Ocasionalmente, isso ocorre no local, mas muitas vezes a sugestão seria uma maneira ruim de alcançar seu objetivo real.

Atualmente, resolvo isso com uma conversa em que falo com o usuário por meio de contexto e objetivos. Isso funciona, mas tem dois problemas: primeiro, "desenrolar" o usuário da ideia fixa "Mas EU QUERO UM BOTÃO" e, em segundo lugar, eles estão sendo solicitados a pense no local sobre algo que está fora do contexto atual que é naturalmente propenso a erros e também pense abstratamente, o que deixa algumas pessoas um pouco desconfortáveis.

Uma pesquisa não encontrou nenhuma pergunta recomendada. Ainda não tentei um formato ainda, mas quero começar com um conjunto de qualidade razoavelmente alta.

Portanto, a questão é saber qual é um formato eficaz conhecido para solicitar aos usuários solicitações mais detalhadas sobre os requisitos de UX.

Estou assumindo que, para afetar as alterações desejadas, preciso solicitá-las quando estiverem fazendo o relatório inicial. Nossa base de usuários atual é formada por trabalhadores de escritório de colarinho branco razoavelmente bem-educados.

Algumas idéias de log de problemas são formuladas com as quais eles iniciariam uma solicitação de aprimoramento da interface do usuário com:

Perguntas ou Parágrafo

Q. What Goal do you need to achieve?

Q. How are you currently reaching this goal?

Q. How frequently do you do this job?

Q. What change would help you achieve your goal?

Q. Describe impact the change make to you and others?

vs.

Hi, to help us make the best possible UI for you, please take 
a moment to tell us about the Goal you need to achieve. Describe 
what it is, and how you are achieving it today.  What is the 
impact of the current UI on your daily work.

Esclarecimento : Obrigado pelas respostas genuinamente úteis em ter essa conversa "desenrolando e analisando". Vai usá-los.

No entanto, o que estou tentando incentivar é bastante restrito, ou seja, fazer o usuário pensar de forma mais abrangente e abstrata sobre seus objetivos no primeiro relatório que eles registram, antes de eu entrar em contato com eles (lendo entre as linhas podem ser irreais)

15
Jason A.

Eu tentei resolver essa mesma pergunta no passado. Aqui está a minha solução.

Mantenha breve. Direcione-os para as atividades.

  1. Concentre o problema com uma opção:
    "Estou tentando fazer algo que atualmente não é possível"
    OU "Estou fazendo algo e o aplicativo não está fazendo o que eu esperava"
  2. Pergunte sobre as atividades:
    "O que você estava tentando fazer quando as coisas deram errado?"
    Isso muda com base no primeiro ponto e no tom do seu aplicativo, mas você entendeu.
  3. Pergunte sobre as expectativas:
    "O que você deseja que o aplicativo faça por você?"
    As mesmas ressalvas que acima.

Por exemplo …

enter image description here

9
plainclothes

Resolver o obstáculo comportamental

Você faz uma observação importante de que é difícil fazer com que os usuários retornem a partir de uma sugestão específica ("Eu quero este botão!") Em que eles estão psicologicamente ancorados.

Concordo. Você pode usar a razão e o charme para desviar o usuário de uma sugestão específica de UX, mas o esforço envolvido para fazer isso pode resultar em fadiga emocional, perda de confiança ou, na pior das hipóteses, em conflito com você como designer e ódio pelo produto se o processo sair pela culatra.

Como podemos evitar isso?

  • Uma observação simples é que, para cada problema e sua solução ideal, existem muitas LOTES de sugestões possíveis: enter image description here
  • Portanto, é mais simples evite começar com sugestões/requisitos e, em vez disso inicie o envolvimento do usuário diretamente em torno de problemas e metas.

    • Começar com sugestões/requisitos significa que você precisa voltar atrás dos usuários (da direita para a esquerda) de volta ao problema antes de avançar com eles em direção a uma solução, o que é psicologicamente pouco intuitivo para os trabalhadores de colarinho branco, porque seu instinto razoável é avançar em direção a uma solução , não para trás em direção a um problema.

    enter image description here

  • Isso é verdade , mesmo que você esteja procurando sugestões de usuários , porque se você conseguir iniciar usuários com um problema ou uma meta primeiro, a qualidade de seus as sugestões resultantes serão melhores.

Que perguntas fornecem esse ponto de partida?

Aqui estão alguns que eu usei no passado:

  • Essa interface ajuda você a trabalhar mais devagar ou mais rápido? Com mais precisão ou mais erros? Com mais frustração ou menos frustração?
  • Onde você está perdendo mais tempo com o sistema?
  • Onde você acidentalmente está criando mais erros?
  • O que você mais odeia nessa interface?
  • O que você mais gosta nessa interface?
  • Que processo você deseja que redesenhamos para torná-lo [mais rápido/menos doloroso/menos propenso a erros]?

Há muitas perguntas em potencial aqui, mas espero que o modelo comportamental possa ajudá-lo a adaptar um conjunto adequado à sua situação.

13
tohster

Isso não responderá totalmente à sua pergunta, pois você já incluiu parte da resposta na sua pergunta :)

Para a parte em que o usuário (ou o cliente em alguns casos) insiste em "Mas EU QUERO UM BOTÃO", tenho algumas técnicas úteis:

  • Confirmo novamente o problema do usuário/cliente. Eu o desloquei da proposta de solução para a identificação do problema. Isso pode exigir muito por que para alcançar o problema original.
  • Lembro ao usuário/cliente que sou totalmente responsável pela solução de design (afinal, estudei design há 5 anos para ser capaz de fazer isso. Às vezes eu dizia essas palavras para ele/ela).
  • Por fim, lembro ao usuário/cliente que projetei para diferentes tipos de usuários com diferentes necessidades. Não posso satisfazer todas as necessidades e isso estragará todo o design (se você criar personas, poderá mostrar a ele como as personas farão com que você se concentre nos recursos necessários). Garanta a ele que você resolverá o problema dele, independentemente do tipo e aparência da solução.

Nota: você sempre pode redesenhar o que parece ser um grande erro no seu design :)

9
Abdalrahman Shatou

Tenho certeza que isso vai incomodar várias pessoas, mas aqui vai.

Pessoalmente, acredito que este não é um problema do usuário. Um usuário não terá requisitos perspicazes de UX e é por isso que é necessário seus conhecimentos .

Mesmo as pessoas mais instruídas, que usam computadores há mais de 20 anos, lutam com os computadores e a Internet como um todo, por isso é um grande primeiro passo para enviar uma solicitação a você.

Quando o usuário médio do computador levanta uma questão ou um problema, , você precisa ser capaz de segurar a mão e observar o que está tentando realizar. Faça com que revelem o problema em vez da solução percebida e, em seguida, você pode dizer com calma "deixe-me ver o que posso fazer". Você está experimentando essencialmente um Problema XY iniciado pelo usuário.

Sim, eu sei que você é incrível no que faz do ponto de vista técnico, mas se você quer ter um desempenho caseiro, precisará promover o relacionamento com seu cliente/usuário.

2
MonkeyZeus

Há duas questões aqui a serem abordadas: obter um entendimento adequado do que a mudança sugerida deve realizar e evitar resistência ou frustração do cliente porque "por que você está me perguntando sobre o problema, quando eu já lhe disse o que você precisa? fazer para consertar isso? ".

Na minha experiência, é extremamente difícil resolver isso bem por e-mail. Uma reunião presencial é muito mais eficaz para esses tipos de discussões, mas uma chamada ainda é melhor do que a comunicação assíncrona por email.

Minha abordagem geral para ambos os aspectos é enquadrá-lo como "Estou procurando esclarecer o contexto dessa solicitação, para que eu acerte".

Durante a conversa, se estiver bem claro o que o usuário acha que isso vai conseguir, começo com: "Para ter certeza de que entendi, acho que o problema que isso resolveria é ... insira meu palpite ... e você está tentando tentar corrigi-lo ... fazendo algo que pode funcionar, mas que pode não ser a melhor maneira de realizá-lo. Está certo? "

Isso convida à discussão e freqüentemente resulta em uma conversa mais natural sobre o assunto.

Tente evitar discutir a solução proposta e mantenha a conversa focada no problema. Certifique-se de entender o que está solicitando a solicitação e como ela está impactando negativamente o trabalho deles. Evite discutir como você vai abordá-lo, a menos que você possa encontrar algo no local que ache que possa trazer benefícios imediatos e óbvios ao usuário sobre a solução proposta (por exemplo, "Um pensamento me ocorreu ... I sei que estamos falando sobre adicionar um botão 'desativar isso' para que você possa evitar [situação que causa um problema], mas se eu pudesse desativar automaticamente o widget para que você não precisasse clicar, isso funcionaria também? "). Você ainda pode receber um "não", mas as chances são muito maiores de obter uma explicação detalhada de por que que não funcionará e, portanto, ganhará mais contexto.

Após a ligação, decida como você acha que a solução deve ser abordada. Se você decidiu que tem uma maneira melhor do que a proposta do cliente, você (ou o gerente de projeto) deve elaborar uma breve explicação sobre o que planeja fazer, com uma lista dos motivos pelos quais você escolheu sua solução. a proposta do cliente.

Não garante que o cliente não volte e diga "não, faça do meu jeito", mas diminua significativamente as chances disso (especialmente se o cliente que propõe a solução não for a palavra final na pergunta do cliente). processo de tomada de decisão).

2
Beofett

Concordo plenamente com tohster nesta questão. Que ótima resposta. Eu postaria isso como um comentário, mas ainda não tenho reputação suficiente.

Eu usei a abordagem " S-T-P ", que vejo como o núcleo da solução do tohster.

Ou seja, Situação Alvo Proposta

Situação Comece com a situação atual. O que você está fazendo hoje? Como você está fazendo isso? O que funciona bem que não queremos perder? Quais problemas são causados ​​e quais são as consequências?

Alvo Como é o sucesso? Se fizermos tudo certo, como será o processo quando terminarmos? Nosso sistema oferece aos usuários autonomia e feedback instantâneo? Como os erros são capturados e identificados? Quais são os cenários de dia ensolarado e dia chuvoso?

Proposta Isso vem por último e, se os dois primeiros forem concluídos, isso deve ser mais fácil. Geralmente o mais difícil dos três. A priorização acontece aqui. A análise e discussão do Risk Reward também acontecem aqui.

Dê uma olhada neste artigo: http://dailykaizen.org/2007/06/19/situation-target-proposal-stp/

1
Shmoken

Há uma variedade de técnicas de entrevista do usuário para extrair requisitos mais perspicazes.

Sou um grande fã de Consulta contextual na minha opinião, essa é uma ótima maneira de extrair requisitos e insights sobre as necessidades dos usuários que você talvez não obtenha de um sessão de perguntas e respostas típica.

A premissa básica da pesquisa contextual é muito simples: vá para onde o cliente trabalha, observe o cliente como ele trabalha e converse com ele sobre o trabalho. Faça isso e não poderá deixar de entender melhor seu cliente. Você pode ler mais sobre isso neste livro de Design Contextual

Um conceito-chave é criar relacionamento com os usuários . Aqui estão algumas maneiras de fazer isso.

  • Informe os usuários desde o início que todos os dados coletados são desidentificados e são 100% anônimos.
  • Diga a eles que eles verão todos os dados que você pode publicar
  • Vá para o ambiente de trabalho do dia-a-dia (não os faça ir ao seu laboratório ou sair da zona de conforto)
  • Convença-os de que eles são especialistas e você está procurando aprender como os fluxos de trabalho ocorrem. Eu gosto de dizer que é como um relacionamento de Mestre Aprendiz
  • Remova a ausência de forma, ou seja, não há revisões formais que você está apenas observando e deixando que conversem enquanto executam as ações que estão realizando atualmente, ou descreva o que elas gostariam que pudessem fazer, mas que atualmente não podem.
  • Existem diferentes maneiras de observar: Você pode tentar realmente executar a tarefa com eles (eles ensinam você a ver se você entende o que eles estão fazendo e o que eles desejam que eles façam), ou você pode sentar passivamente e apenas observá-los e faça anotações. Certos são mais aplicáveis ​​para diferentes situações.
  • Veja se você não consegue observar diferenças no que as pessoas dizem e no que elas realmente fazem para encontrar requisitos ocultos.
  • Tente limitá-lo a 2 horas ou mais. Isso o torna menos formal e eles geralmente serão menos protegidos.
  • Seja gentil, agradeça a eles por seu tempo, agradeça mesmo que pudesse ter sido melhor

Depois de ter requisitos

  • Faça um diagrama de fluxo ou sequência. Conecte as peças na ordem do fluxo de trabalho.
  • Se parece haver uma lacuna, veja se você perdeu alguma coisa, você pode obter um oh sim, temos que fazer xyzzy, mas eu esqueci de mencionar, porque é muito tedioso

Pegadinhas com os requisitos do usuário

  • Esteja ciente de que quando eles descrevem isso é o que fazemos, em oposição a isso é o que normalmente fazemos. Mesmo que algo faça parte do processo geral, eles normalmente seguem todas as peças ou faltam peças que não estão descrevendo.

Essa é uma maneira poderosa de extrair os requisitos do usuário, mas definitivamente é preciso um pouco de esforço para dominar, otimizar e aperfeiçoar. Por último, consulte este artigo do uxmatters.com sobre as dificuldades das entrevistas contextuais.

0
Frank Visaggio

(o que pedir para obter as necessidades?): Como alguns outros especialistas discutiram anteriormente, também acredito em perguntar 'por que'. Isso não é exclusivo do UX e foi usado décadas atrás na solução de problemas em geral. Os livros de requisitos também destacam isso e incentivam os profissionais a perguntar pelo menos cinco porquês para chegar às raízes do problema (para o qual o cliente sugeriu uma solução de ter um botão). Isso ajuda você a entender melhor as necessidades/requisitos e oferece ao cliente/usuário a chance de perceber a necessidade real por trás do que ele está sugerindo.

(da solução potencial ao problema): técnicas genéricas de solução de problemas, como A3, também enfatizam a necessidade de entender o problema em profundidade antes de sugerir quaisquer soluções, que vejo na resposta de Tohster. Aqui, o usuário/cliente está focado na solução, mas precisa ser guiado de volta à área do problema, a fim de tornar possíveis soluções de design mais criativas e potencialmente melhores.

(questionário/entrevistas/observações: abordagens de coleta de dados): Pessoalmente, sou fã de observações e entrevistas abertas, nas quais posso explorar melhor a visão dos usuários/clientes. Acredito que mantê-lo como um diálogo ajudará ambas as partes a ter uma melhor comunicação e evite mal-entendidos. Além disso, não sugiro o uso de termos abstratos e de alto nível, como 'objetivos', em tais entrevistas ou perguntas. Pode ser difícil de digerir para algumas pessoas e impedir uma discussão proveitosa. Em vez disso, eu perguntava 'por que você acha que precisa de um botão aqui?'
Se você for forçado a usar questionários, sugiro usar perguntas da escala Likert junto com perguntas abertas para fazer com que os usuários pensem sobre o que sentem sobre o sistema agora. Por exemplo, o sistema me apoia na execução de todas as tarefas que preciso executar todos os dias: discordo totalmente -> concordo totalmente que isso pode ser seguido por uma pergunta em aberto.

(de quem é a responsabilidade?): Concordo que esse é o trabalho do especialista em UX de segurar as mãos do cliente/usuário e ajudá-lo a explorar suas necessidades, em vez de querer que eles apresentem 'necessidades' em vez de 'soluções'.

0
Pariya Kashfi