Entrevista semi-estruturada com usuários experts

Wood (1997) em seu artigo “Semi-structured Interviewing for User-Centered Design“, traz orientações interessantes para quem quer otimizar a prática de entrevistas com usuários. Organizado de forma pragmática e bastante didático, ele sugere uma série de questões que podem ser feitas no momento da entrevista, para se obter o máximo de conhecimento dos usuários sendo entrevistados.

Todo mundo que, alguma vez, experimentou entrevistar usuários, afim de investigar suas tarefas, contexto de uso, etc, já se deparou com, pelo menos uma dessas dificuldades: manter o foco, fazer as perguntas relevantes, não tendenciar respostas, usar os termos usados pelos próprios participantes, dentre outros desafios.

Acho que muitos já são conscientes disso, mas não custa dizer que entender as tarefas, o fluxo de trabalho e o contexto em que as tarefas são realizadas por usuários é um ponto crucial para qualquer projeto que se pretenda ser centrado nas pessoas. Este entendimento sobre as tarefas dos usuários é, normalmente, realizado no início do ciclo de desenvolvimento de um produto interativo (prefencialmente no ciclo zero, se você conhece o desenvolvimento ágil) e vai orientar as fases seguintes de desenvolvimento (construção de protótipos, criação de cenários de testes, etc).

O autor apresenta, portanto, neste artigo, um framework com sugestões de perguntas para orientar a condução de uma entrevista com usuários. A técnica é adaptada de métodos usados por etnógrafos e cientistas cognitivos e em trabalhos prévios do próprio autor. Importante dizer que a técnica é orientada, especialmente, para entrevistas realizadas com usuários experts.

Segundo o artigo, usuários experts possuem 3 características, sequintes:

1. Conhecimento organizado hierarquicamente. Possuem organização elevada do conhecimento, tanto em nível macro (categorias e sub-categorias) quanto ao nível micro (reconhecimento de padrões que acionam formas específicas de resolução de problemas)
2. Conhecimento tácito. Forma de conhecimento automática, de difícil acesso e é adquirido pelo uso extensivo durante o tempo (exemplo: aprender a nadar, aprender um esporte, etc). Embora este conhecimento não tenha sido “esquecido”, o expert sente dificuldade em expressar, articular ou racionalizar este tipo de conhecimento. Para tentar suprimir este problema, o analista (pesquisador) pode observar o usuário engajado em uma tarefa real, para contrastar com as informações dadas pelo usuário, oralmente.
3. Tendência em “traduzir” sua visão quando explicando uma tarefa para uma outra pessoa. Uma forma, sugerida, para minimizar este problema é a do pesquisador tentar usar terminologias e conceitos empregados pelo usuário, afim de minimizar a tendência do usuário traduzir os conceitos para que o entrevistador “entenda o que ele está dizendo”.

O que é entrevista semi-estruturada?

É  uma abordagem de entrevista em que se tem objetivo de elicitar ao máximo as teminologias usadas pelo usuário em seu trabalho, de maneira, menos tendenciosa possível. Ao contrário de formular previamente um conjunto de perguntas e seguir a risca, o pesquisador/analista tem uma séria de perguntas em suas mãos que podem ser usadas da maneira mais oportuna, dependendo da necessidade e do rumo da entrevista.

As orientações

Em resumo, as orientações sugeridas no artigo, podem ser resumidas nas seguintes atividades:

1. Primeiro, conhecer os artefatos, conceitos e terminologias empregadas pelos usuários (conhecimento do objeto) e
2. Segundo, usar as terminogias e o conhecimento adquirido sobre os artefatos para formular perguntas para elicitar as relações entre os artefatos, sequência de tarefas e estratégias de resolução de problema (conhecimento do processo).
   

Exemplos de perguntas para elicitar o primeiro iten (conhecimento do objeto):

TOUR NO SISTEMA:

• Você poderia me mostrar os principais passos que você faz para [relizar a tarefa x]?
• Você poderia me contar como é, normalmente, feito a [tarefa x], no dia-a-dia?

LINGUA NATIVA:

• Como você costuma chamar este botão [de fazer tal coisa]?
• Como você descreveria este passo [da tarefa x]?
• Para que serve a [funcionalidade x]?

Dica: Em todas estas perguntas a atenção deve estar voltada aos conceitos e terminoligas empregadas pelos usuários. De preferência, entreviste-0s em seu local natural de trabalho.

RELAÇÃO ENTRE OS ARTEFATOS

• Quais são os outros usos diferentes deste [nome do artefato]?
• Quais são os outros produtos [ou funcionalidades] que tem este mesmo uso?

Dica: Procure pela relação entre os artefatos, procure pelas categorias e sub-categorias do objeto de estudo.

Exemplos de perguntas para elicitar o segundo iten (conhecimento do processo):

A técnica sugerida para ajudar a entender o processo (e tarefas) é o “Think Aloud“. Técnica que consiste em pedir para o usuário “pensar em voz alta” enquanto está realizando uma tarefa específica. Enquanto o usuário faz isto, o moderador pode fazer perguntas para incentivar a fala ou elicitar questões específicas. Exemplos de roteiro:

• Tente falar em voz alta enquanto realiza [a tarefa x]. Não se preocupe em falar frases completas ou em fazer sentido.
• Iremos revisar o video da sua tarefa que acabou de realizar, tente lembrar e nos diga o que você estava pensando. Pare ou recomece o video quanto quiser.
• Exemplo de questões específicas: Como você se decidiu por [esta ou aquela opção]? [Este exemplo ajuda a elicitar o conhecimento tácito, aquele de difícil acesso, e a estratégia de tomada de decisão daquela pessoa]

O próximo passo, a partir das entrevistas, é modelar o conhecimento adquirido sobre os usuários.  Além disso, o modelo criado pode ser validado pelos próprios usuários. No artigo, o autor conta que esta modelagem é feita de forma iterativa, ou seja, ele reliza entrevistas > cria um modelo simples > valida antes de começar nova entrevista, revisando o modelo criado com os participantes. Existem diversas ferramentas e formas de se fazer a modelagem da tarefa. Uma consulta rápida no google e você vê uma diversidade de exemplos.

Leia mais:

Livro “User and Task Analysis for Interface Design

Views and Forms: Principles of Task Flow for Web Applications Part 1

Interaction modeling

REFERÊNCIA

• Wood, L. E. Semi-structured interviewing for user centered design. Interactions, March + April 1997, 48 – 61.

Análise Heurística de um serviço de gráfica rápida

Hoje darei um exemplo de uma análise heurística que fiz em cima de uma experiência real que tive a poucos dias em uma gráfica daqui de Belo Horizonte (melhor não citar o nome, EXATAmente…)… Por quê análise heurística? Porque as heurísticas se encaixaram perfeitamente neste caso…No final, criei as minhas próprias. Acompanhe…

As 4 abordagens do design

Qual é a sua abordagem de design? Se você mora no Brasil e assim como eu é formado em design em uma faculdade tradicional de design do país, você provavelmente exerce ou já exerceu a abordagem do Genius Design…

O que é o Genius Design? Segundo Dan Saffer existem 4 abordagens para o processo de design de qualquer tipo de produto: O Design Centrado no Usuário, o Design centrado na atividade, o Systems Design e o Genius Design. (Veja tabela comparativa abaixo).

Prototipando um sistema do tipo surface em papel. Dá certo?

Usuário interagindo com uma surface

O pessoal que lê meu blog ou que passa por aqui já deve ter percebido que gosto bastante de falar do processo de design em si mais até do que o produto final. E outro dia, o Daniel Orlandini, fez uma pergunta na lista de discussão que achei bem legal, sobre prototipação de um sistema Surface (ou similar) usando o papel. Acredito que seja uma dúvida recorrente para quem começa a testar seus projetos em protótipos e envolvendo os usuários. Era apenas um trabalho acadêmico, mas assim como ele, eu também já tive muitas dúvidas parecidas…

A questão dele era a seguinte:

Definição de DCU pelo cliente

Outro dia ouvi:

“Cara, vocês conseguiram transformar a bagunça, e aquele monte de idéias em algo totalmente entendível, incrível”

Quando a gente pensa que já encontrou uma boa definição para o que é Design centrado no usuário, vem o cliente e supera

Modelo “Funil” de design de interação

Modelo de ciclo de vida Funil

Pensando esses dias sobre os projetos e o processo de design de interação que temos feito aqui na empresa, percebo um grande amadurecimento no processo, principalmente com relação à flexibilidade na forma de planejar um projeto de DI e de escolher processos alternativos que melhor encaixam em cada projeto. Temos conseguido viabilizar projetos de usabilidade e design de interação bem diferenciados.

Mesmo em projetos com pouco tempo disponível, ou verba, temos aplicado algumas técnicas de forma a melhorar interfaces de forma bastante satisfatória. Temos aplicado algo parecido e alinhado com os conceitos do Agile development (nomeamos livremente de “Agile UX design”) que, basicamente, consistem em iterar o mais rápido possível, identificar os erros rapidamente, concentrar no essencial, manter o simples, rabiscar idéias no papel, evitar documentações desnecessárias… (Este artigo aqui, inclusive, é muito bom para quem quiser saber mais).

Observando o andar dos últimos projetos (principalmente os de criação de um produto novo), consegui identificar alguns padrões e rabisquei um modelo de ciclo de vida em formato “funil”, pois é esse modelo mental que me vem a mente quando vivencio um turbilhão de idéias, dúvidas e opiniões abstratas acerca de um produto sendo transformados em algo concreto, um produto fruto de um projeto de design.

Ponto de Partida

Para começar, um ponto de vista “síntese” sobre de onde partem os novos produtos: (Direto da primeira página do meu caderno do curso de design de interação).

Esboçado, estava mais ou menos assim: um produto novo pode partir de três pontos: ou vem da tecnologia ou da

atividade ou das necessidades das pessoas.

1) Tecnologia

Quando um produto parte da descoberta ou desenvolvimento de uma tecnologia nova. É o caso da maioria das empresas de tecnologia, que investem em um novo produto a partir da tecnologia desenvolvida. Ex.: Celulares e Indústria de Jogos.

2) Atividades

Quando um produto é pensado para suportar uma atividade já realizada pelas pessoas antes da tecnologia específica. Exemplo: Softwares de comunicação instânea, como Skype e MSN. Estes sistemas possibilitaram que as pessoas

realizassem a mesma atividade de comunicação de uma outra forma.

Nesses casos as pessoas é que se adaptam às atividades.

3) Pessoas

Quando um produto é pensado através do estudo das necessidades e características das pessoas, podendo estar até mesmo relacionado à uma atividade nunca antes realizada. Ex: Flickr, que suporta uma neccessidade básica do ser humano: a socialização.

É neste cenário que se encontra o Design centrado no usuário > Entender necessidades reais para projetar produtos, experiências e serviços mais adequados à estas pessoas.

Aula do Prf. Marcos Kutova