Este artigo foi traduzido por máquina.
Não Me faça começar
O paciente sabe o que está errado com ele
Eu ouço a mesma queixa em todas as classes de interface do usuário que leciono: "Os usuários não sabem o que querem. Como podemos construir isso para eles se eles não nos dizem?"
Este não é um problema novo. No meu primeiro emprego, meu chefe entregado ao redor de um poema intitulado "T'was Nite antes da execução" (bit.ly/189U65). Ele acabou com as linhas:
E o usuário exclamou com um enredo e um insulto,
"É apenas o que eu pedi, mas não o que eu quero!"
Isso foi há 30 anos e duvido que o poema era novo, então.
Os usuários têm informações valiosas para nós. Sua satisfação é nossa métrica de qualidade final. Mas os usuários não sabem projetar interfaces de usuário, da mesma forma que os pacientes não sabem como diagnosticar suas próprias doenças. Eles podem dizer você se algo parece bom ou ruim depois de você perguntar-lhes. Mas puxar o diagnóstico correto fora o vazio não é o seu problema. É nosso, profissionais treinados que pretendemos ser.
Pense nisso. Quando um paciente vai ao médico, ele geralmente não diz, "Eu acho que eu tenho tipo c fulminante hanseníase, Kaminski variação." N. º Ele diz algo como, "Ow, meu cotovelo dói." É o trabalho do médico para descobrir se o cotovelo do paciente dói porque câncer é corroer seus ossos, sua esposa do traindo ele e ele está deslocando ansiedade ou talvez ele só bateu em algo. É uma habilidade difícil de aprender, e médicos que podem fazê-lo bem são bons médicos.
Meu pai, um médico aposentado, vem da antiga Faculdade de medicina, que assina essa crença: As informações que você precisa para fazer o diagnóstico são a cabeça do paciente. Mas o paciente não sabe que partes são importantes, ou como se relacionar com uma peça para outra. É dever do médico fazer as perguntas certas: "Quando o cotovelo começou doendo? O outro cotovelo dói muito? Dói quando eu dobrá-lo desta forma? Dessa forma?" Testes de laboratório e de imagem podem confirmá-la, mas todos diagnóstico decorre de entrevistar e examinar o paciente.
Da mesma forma, é nosso trabalho para fazer as perguntas certas, extrair os dados relevantes de cabeças de nossos usuários e usá-lo para construir uma boa UX. Precisamos aprender a entrevistar nossos usuários alvo e observá-los no trabalho. UX designers que podem fazer o que bem são bons designers.
Também é importante distinguir entre sintoma e causa. Meu pai diz a seguinte história sobre um dos primeiros pacientes que nunca tratou. A tinta não era mesmo seca no doutorado. diploma que ele começou seu primeiro trabalho na clínica hospitalar. (Novos médicos foram chamados estagiários naquela época, antes de Bill e Monica deram esse termo um significado diferente.)
Um paciente entrou reclamando, "Eu não tive um movimento intestinal em uma semana." "OK," pensei que meu pai. "Movimento de entranhas. Não há problema. Quatro anos de faculdade de medicina; Eu posso lidar com isso." Ele prescreveu um laxante suave; não aconteceu nada. Tentei uma mais forte; ainda nada. Ficando um pouco frustrado, ele tentou um enema. Nada novamente. Um ultra-som foi negativo, um MRI não mostra nada, e o trabalho do sangue foi normal.
Ficando desesperado, ele tomou o paciente até a sala de cirurgia e fiz uma laparotomia; cortado aberto seu abdômen para olhar ao redor. Não havia nada para ver — o paciente tinha uma barriga completamente normal. Finalmente, ele fez o que ele deveria ter feito em primeiro lugar: teve uma história completa, durante o curso que ele perguntou ao paciente o que ele fez para viver. O paciente disse, "Eu sou um músico". Finalmente, a lâmpada acendeu. "Ah! É claro!", exclamou: meu pai. "Olha, aqui é de 10 dólares. Ir comprar algo para comer."
Assim é com nossa população de usuários. Eles têm alguma noção do que dói: "Trabalhou durante três horas, então se veio essa caixa estúpida, dizendo: 'O Microsoft Word encontrou um erro e precisa ser fechado', e todo o meu trabalho se foi." Não é o seu trabalho para dizer, "puxa, eu gostaria de algum personagem animado com sobrancelhas grossas seria pop up and say, ' parece que você está prestes a cair. Você não acha que você deve salvar seu trabalho?'" É nosso trabalho para descobrir o que realmente é feri-los, assim que nós podemos fazer isso parar.
David S. Platt ensina programação .net na escola de extensão da Universidade de Harvard e em empresas em todo o mundo. É autor de 11 livros de programação, incluindo o "Por que Software Sucks" (Addison-Wesley Professional, 2006) e "Introducing Microsoft.NET" (Microsoft Press, 2002). Microsoft nomeou uma legenda de Software em 2002. Ele se pergunta se ele deve fita para baixo dois dos dedos de sua filha para que ela aprende como contar octal. Você pode contatá-lo em rollthunder.com.