>>
>>
>
>
>
>
>
A equipa de design apresenta uma lista de necessidades do utilizador para o seu produto. A equipe de engenharia vem para a mesa com um conjunto diferente de características. A equipe de gerenciamento só quer os recursos que farão a empresa ganhar dinheiro. A equipe de suporte vê características totalmente diferentes que precisam ser corrigidas. Como é que uma equipa de produto sabe em que direcção seguir?
Como investigadores de design, confiamos no que os clientes dizem e fazem para ler mais profundamente e descobrir o que querem. No entanto, muitos de nós temos muitas vezes lutado com novas formas de quantificar e visualizar essas necessidades de uma forma eficaz para que essas equipes entrem em alinhamento. Os clientes podem certamente votar e classificar características, o que dá uma grande visão geral, mas nem sempre dá uma compreensão mais profunda do que já é esperado.
Introduzir o Modelo Kano.
> >
>
>
O modelo Kano é uma teoria de desenvolvimento de produto e satisfação do cliente desenvolvida nos anos 80 pelo Professor Noriaki Kano, que classifica as preferências do cliente em cinco categorias. Ele fornece técnicas para nos ajudar a entender as perspectivas dos clientes sobre as características do produto, avaliando duas medidas para cada característica: a satisfação e o sentimento. As respostas a essas duas medidas se enquadrarão em uma das cinco categorias: Atrativo, Desempenho, Indiferente, Indesejável, Não desejado.
Como utilizá-lo
Faça um questionário com cada recurso listado separadamente. Para cada recurso, idealmente você demonstra o que o recurso pode fazer através de um protótipo ou wireframe interativo, quando possível. Não gaste muito tempo prototipando para isso: é apenas um protótipo para transmitir a idéia. Algumas pessoas podem ficar realmente atadas aos detalhes mesmo em protótipos, porque podem gostar da idéia, mas não de como ela foi implementada.
>
>>
>
>
>
Se não for possível demonstrar os recursos, uma descrição de texto explicativo também funciona bem.
>
>
Pro-tip: Em discussão com outros pesquisadores da IBM, aqueles que foram mais bem sucedidos testaram 15-20 características. Aqueles que obtiveram menos sucesso nos testes 30-40. Testar mais de 20 recursos foi uma quantidade enorme de dados, tanto para os clientes, quanto para os pesquisadores analisarem.
Após ver cada recurso, os usuários selecionam sua resposta ao questionário Kano:
- Se você tivesse (recurso), como se sente?
- Se você não tivesse (recurso), como se sente?
(Daniel Zacarias tem algumas dicas excelentes sobre como escrever estas questões de uma forma clara)
As respostas padrão do questionário Kano a ambas as questões acima são:
- Eu gosto disso
- Eu espero isso
- Eu sou neutro
- Eu posso tolerar isso
- Eu não gosto disso
Daniel Zacarias também oferece algumas outras opções para as respostas definidas para essas respostas. Basicamente, se você vai tentar o modelo Kano, leia todo o seu artigo. É incrível.
Jan Moorman também recomenda adicionar uma terceira pergunta: Quão importante é esta funcionalidade? Ela recomenda usar uma escala de nove pontos Likert de “Não é nada importante” a “Extremamente importante”. No entanto, ao tentar soletrar os nove pontos na escala Likert para importância, é … um pouco complicado. Parece que a escala de sete pontos de Likert é mais fácil.
>
Após você ter as respostas, há um processo de análise que Daniel Zacarias descreve em grande detalhe. Eu sugiro fortemente que você leia isso.
Uma questão que os pesquisadores da IBM descobriram foi que ter esses números era ótimo, mas os números em si não disseram a ninguém o porquê, a pergunta inevitável que todos nós vamos receber de nossas equipes de gerenciamento. Uma equipe usou o modelo Kano para conduzir cerca de 15 entrevistas qualitativas. Outra equipe realizou 5 entrevistas qualitativas após receber questionários de 40 pessoas. Ambas as equipas recomendaram fortemente a adição de entrevistas qualitativas a este processo, uma vez que acrescentou a narrativa que ajuda a dar aos dados o contexto em falta.
Como NÃO utilizá-lo
Uma das equipas da IBM que utilizou o modelo Kano hesitou em utilizá-lo novamente. Esta equipe configurou o questionário usando cenários que eles acreditavam ser a forma atual como as coisas funcionavam para descrever as características. Entretanto, conforme os testes progrediram, tornou-se óbvio muito rapidamente que os cenários da equipe de projeto não refletiam como os clientes realmente utilizavam o produto, e os testes descarrilaram rapidamente.
A idéia de utilizar cenários para descrever os recursos é boa, mas conforme discutimos sua abordagem, ficou claro que os cenários devem ser validados de antemão. A combinação Kano + cenários seria poderosa após uma pesquisa generativa que estabelecesse a situação atual.
Outro conselho era reduzir o número de recursos sendo testados. A equipe que assumiu uma longa lista de 30-40 características disse que era um pouco intensa demais, e que os clientes ficaram sobrecarregados e desgastados ao final do teste.
Benefícios
O modelo Kano é muito bom em dar prioridade às características. Uma teoria que está subjacente ao modelo Kano é o que Daniel Zacarias chama de “a decadência natural do prazer”. Ideias e produtos inovadores passam de excitantes e novos, no topo da carta de Kano (Atraente) para características esperadas, na parte de baixo (Deve ter na melhor das hipóteses, detratores, na pior).
>
>
Tomar a Internet sem fio como exemplo*. Estamos em 2001, e você está viajando para o trabalho, e tem um laptop topo de linha que tem uma porta ethernet e WiFi. Você está em um hotel, e você aprende que eles têm portas ethernet para que você se conecte à Internet. Eles não têm Internet sem fio incluída na tarifa do seu quarto, mas você pode obter WiFi no centro de negócios deles. Você está entusiasmado! É incrível! Que opções fantásticas!
Reencaminhamento rápido para 2017. Você está viajando para o trabalho e tem um laptop básico que tem WiFi. Você está em um hotel, e você aprende que eles têm portas ethernet para você se conectar à Internet. Eles não têm Internet sem fio incluída na tarifa do seu quarto, mas você pode obter WiFi no centro de negócios deles. Você está furioso! De que planeta é esse hotel que você tem que pagar extra pela Internet?! E quem ainda usa sua porta ethernet para se conectar à Internet?
O que começou como um recurso atraente (portas ethernet no quarto, e WiFi no centro de negócios), 16 anos depois se tornou um recurso indesejado.
Se as equipes não estiverem conectadas ao que os clientes querem, eles podem se concentrar em recursos que são esperados em vez de atraentes. Um dos pesquisadores da IBM que tinha usado o modelo Kano notou isso em sua própria equipe: “Havia alguns recursos que a equipe estava muito animada, e então percebeu que esses eram estacas de mesa”.”
Potencial adicional
Como discutimos o modelo Kano, teorizamos que ele também tem potencial para algumas outras coisas:
>
- Abastecer a profundidade dos pontos de dor
- Características de revestimento ao longo do ciclo de vida do produto para avaliar a decadência natural do prazer ao longo do tempo
Depth of pain points
Este modelo pode ajudar a revelar o quão maus são os pontos de dor existentes. O questionário Kano facilmente se presta a permitir que a pesquisa se aprofunde para aprender mais sobre a razão pela qual os pontos de dor são tão ruins quanto eles são, e por que essas características são tão importantes para os clientes. Ele poderia revelar algumas necessidades não identificadas anteriormente e levar a mais inovações.
Características de Baselining
Discutimos o uso do modelo Kano para avaliar as características de forma regular para observar quais características estavam sendo rebaixadas para categorias inferiores. Este tipo de testes longitudinais, com uma base suficientemente grande de clientes, poderia indicar tendências e expectativas do mercado e ajudar a continuar a provar o valor da pesquisa ao longo do tempo. Também poderia ajudar as equipas a saber quando o seu produto está a começar a atingir o patamar e a precisar de ideias inovadoras para regressar a um estado de definição de tendências.
Pergunta Aberta
Por vezes as equipas de design da IBM actuam como consultores para projectos. Algumas equipes de design na IBM são convidadas a entrar em um projeto para “limpar a usabilidade” e aspergir o pó UX mágico em um produto pouco antes do lançamento. Outras equipes de design estão temporariamente integradas em uma equipe de produto mais ampla.
Ficamos com uma pergunta em aberto no final da nossa discussão: o modelo Kano é útil se você não pode impactar o produto? Você pode não ser capaz de impactar o produto porque ele já está em desenvolvimento, por causa do “pushback” da gerência, porque a equipe de design é apenas temporariamente parte da equipe do produto, etc. O esforço de usar o modelo Kano vale a pena?
Or, talvez ele ainda seja útil mesmo que você não possa impactar o produto?
Poughts?