»
S
I
D
E
B
A
R
«
Como saber o que o cliente quer?
Aug 23rd, 2010 by Joca

No meu último post em que falei sobre as lições de gestão de produtos do fim do Google Wave comentei algumas vezes sobre a importância de conhecermos o cliente, de sabermos se nossa idéia de produto resolve um problema desse cliente e se o cliente está disposto a nos pagar por essa solução.

Mas como saber o que o cliente quer? Como saber se nossa idéia de produto resolve um problema? Como saber se ele está disposto a pagar por essa solução?

Bom, sendo bem direto: pare de perguntar!

Stop asking questions

Stop asking questions


Perguntar diretamente para o cliente o que ele quer pode não trazer bons resultados. Existe aquela frase famosa atribuída ao Henry Ford que se ele fosse perguntar o que os clientes querem, os clientes iam responder “um cavalo mais rápido”…

Existe também a primeira lei da usabilidade do Jakob Nielsen:

Não ouça os usuários.

What he says and what he really means

What he says and what he really means

What she says and what she really means

What she says and what she really means

Exageros à parte, o que frases como pare de perguntar e não ouça os usuário querem dizer é que mais importante do que ouvir o que o usuário ou cliente ou futuro cliente diz que quer é entender o que ele realmente precisa.

Os testes de usabilidade fazem uso desse conceito. Num teste de usabilidade é pedido que um usuário execute uma determinada tarefa com o produto e observa-se se o usuário consegue fazer essa tarefa e quais as dificuldades ele encontrou durante a execução. Se perguntássemos ao usuário se é fácil usar o produto para fazer a tarefa, as chances de a resposta não corresponder à realidade são grandes.

Outro exemplo interessante é assistir a um usuário 3 minutos antes e 3 minutos depois de ele fazer uso de nosso produto. É provável que ele tenha feito algo para se preparar para usar nosso produto ou algo logo após seu uso que indiquem alguma possibilidade de novo produto ou de nova funcionalidade. Se perguntássemos diretamente ao usuário o que ele faz antes e depois de usar o produto talvez não obtivéssemos uma resposta precisa pois as tarefas podem estar tão inseridas no cotidiano do usuário que nem seriam percebidas como oportunidades de melhoria.

Mas e se ainda não tivermos um produto? Simples, basta usarmos um protótipo! 🙂

Resumindo

  • Só perguntar e ouvir o cliente não é o suficiente para para saber o que ele quer.
  • Temos que sair do escritório e ir até o cliente, conversar com ele, assistir ele usando o produto em seu “habitat natural”.
  • Se ainda não tivermos um produto para mostrar, devemos mostrar um protótipo.
2 people like this post.

Google Wave sunset provides some interesting product management lessons
Aug 9th, 2010 by Joca

Last week Google’s announcement about the end of Google Wave made me review and rethink about some product manangement lessons.


Google Wave

Google Wave


Product discovery

Marty Cagan, former eBay Product Management VP and currently product management consultant, uses to say that all product management processes must start with a “product discovery” phase where we need to find out:

  • if there are customers interested in our product idea,
  • what’s the customer problem that our product idea intend to solve, and
  • if our product idea is the best solution for the customer problem.

Customer development

For Steve Blank, a retired serial entrepeneuer who started 8 technology companies, knowing the customer is so important that is not enough for the companies to have a product development process. They must have a “customer development” process prior to the product development, where customer demands and problems are the main focus.

More startups fail from lack of customers than from fail of product development.

Steve Blank

Featuritis

In a 2005 post at her “Creating Passionate Users” blog, Kathy Sierra shows happiness as a function of the number of product features. The chart is quite self explanatory:

Featuritis

Featuritis


As it is Google Wave screen. There are so many things one can do with Google Wave…

Google Wave

Google Wave


Useful, usable and desirable

Every product must be:

  • useful: how much do people need this product? It does what needs to be done.
  • usable: how easy is the product? Easy to understand. Easy to master.
  • desirable: how much do people want this product? They and their friends want the product. The product is worth the time and money investment.

We must always remember:

Tricycle

Tricycle


Source: http://flickr.com/photos/jevolella/437838621/

If ease of use were the only requirement, we would all be riding tricycles.

Douglas Engelbart, mouse inventor

Summary

  • Creating a product just because a new technology is available is shooting in the dark.
  • If a product doesn’t solve a real customer problem the chances of success of this product are nil.
Be the first to like.

Google Wave é uma aula de gestão de produtos
Aug 8th, 2010 by Joca

O anunciado fim do Google Wave na última semana é uma verdadeira aula de gestão de produtos e eu não pude deixar a oportunidade passar. Por isso vou dar uma pausa no tema gestão de projetos para falar sobre algumas lições de gestão de produtos que o fim do Google Wave nos faz relembrar.


Google Wave

Google Wave


Descobrindo produtos

Marty Cagan, ex-VP de Produtos do eBay que atualmente faz consultoria de gestão de produtos, costuma dizer que todo processo de desenvolvimento de produtos deve começar com uma fase de “descobrimento de produtos” onde se deve descobrir:

  • se existem clientes interessados em sua idéia de produto
  • qual é o problema do cliente que sua idéia de produto se propõe a resolver e
  • se sua idéia de produto é a melhor solução para o problema do cliente.

Desenvolvimento de clientes

Já para Steve Blank, um empreendedor em série que já fundou 8 empresas de tecnologia, a importância de se conhecer o cliente é tão grande que não basta as empresas terem um processo de desenvolvimento de produtos, elas devem ter um processo anterior chamado de “desenvolvimento de clientes”, onde se busca entender o cliente e suas necessidades para só depois pensar em desenvolver uma solução para essas necessidades.

Mais startups fracassam por falta de clientes do que por não saber como desenvolver um produto.

Steve Blank, fundador de 8 empresas de tecnologia

Featuritis

Em um artigo de 2005 em seu blog “Creating Passionate Users”, Kathy Sierra mostra a felicidade do usuário como função do número de features de um produto. O gráfico é auto-explicativo:

Featuritis

Featuritis


Assim como o é a tela do Google Wave. São tantas coisas que se pode fazer com o Google Wave…

Google Wave

Google Wave


Útil, usável e desejável

Todo produto precisa ser:

  • útil: quanto as pessoas precisam desse produto? Ele faz o que precisa ser feito.
  • usável: quão simples é o produto? Simples de entender, simples de mexer ao ponto de facilmente o usuário se tornar um expert no produto.
  • desejável: quanto as pessoas querem o produto? Elas querem esse produto. Seus amigos também querem esse produto. Ele vale o tempo investido.

Lembrando que:

Triciclo

Triciclo


Fonte: http://flickr.com/photos/jevolella/437838621/

Se facilidade de uso fosse o único requisito, estaríamos todos usando triciclos.

Douglas Engelbart, inventor do mouse

Resumindo

  • Criar produtos somente porque uma uma nova tecnologia está disponível é um tiro no escuro.
  • Se o produto não resolve um problema real de seus possíveis clientes, as chances desse produto ser um sucesso são nulas.
2 people like this post.

Protótipos de baixa fidelidade, croquis, simplicidade, Gantt e burnup
Jul 26th, 2010 by Joca

Essa semana tive a oportunidade de conversar com Gil Barros, um profissional muito experiente de design de interação e de arquitetura da informação, que está fazendo doutorado na FAU-USP sobre prototipação e o uso de croquis.

…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia…

O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.

fonte: http://pt.wikipedia.org/wiki/Croquis

Ele comentou que vê pouca gente se valendo do desenho feito à mão para mostrar ideias e que, por achar essa opção como uma das formas mais ágeis de comunicacão, resolveu dedicar seu doutorado a esse tema.

Eu já havia comentado sobre a importância dos rascunhos, ou protótipos feitos à mão, no post “Protótipo: primeira impressão” e no post “Mais um exemplo de protótipo de baixa fidelidade“.

O que me atrai nos protótipos de baixa fidelidade e em croquis de forma geral é sua simplicidade inerente. Quem me conhece sabe que sou fã da simplicidade, tanto que já escrevi sobre o tema no post “Simplicidade” e em um outro post onde comento sobre um site de 1 única página.

Semana passada, quando escrevi sobre as vantagens do uso dos gráficos de burnup como opção aos Gantt Charts para acompanhamento do andamento de projetos, acabei não comentando de uma das vantagens mais óbvias do burnup: o burnup é mais simples que o Gantt Chart pelo simples fato de que burnups podem ser feitos à mão. Já o Gantt Chart é muito difícil de ser feito à mão.

A prova disso é a busca de imagens do Google. Experimente pesquisar por Gantt Chart e por burnup chart.

Logo na primeira página da pesquisa por imagens de burnup chart são 4 gráficos feitos à mão. Já na pesquisa por Gantt Chart, não encontrei nenhum…

Burnup

Burnup feito à mão

Outro exemplo de burnup

Outro exemplo de burnup feito à mão

Burn down que aparece na busca por imagens de burnup

Burn down feito à mão que aparece na busca por imagens de burnup

Mais um exemplo de burnup

Mais um exemplo de burnup feito à mão


Be the first to like.

9 de cada 10 novos produtos falham
Jul 5th, 2010 by Joca

O processo de desenvolvimento de um novo produto em uma empresa já estabelecida tem semelhanças e diferenças com o processo de criação de uma nova empresa, ou uma startup como são chamadas as novas empresas nos EUA.

As principais diferenças são:

  • Numa empresa já estabelecida há todo o suporte tanto financeiro quanto de pessoas da empresa para desenvolvimento de um novo produto enquanto numa startup é necessário encontrar o dinheiro e pessoas dispostas participar da nova empresa com todos os riscos envolvidos.
  • Por outro lado, como a empresa já está estabelecida, a prioridade é, ou pelo menos deveria ser, o cliente e o produto existentes, que é o que garante a sobrevivência da empresa, já numa startup o foco é o novo produto já que a empresa não tem nada.

Já a semelhança está no processo em si:

Desenvolvimento de produtos

Desenvolvimento de produtos

Acabo de encontrar uma apresentação de Steve Blank, um empreendedor em série do Silicon Valley que fundou 8 empresas de tecnologia em 21 anos e hoje é consultor, professor e escritor sobre empreendedorismo.

Nessa apresentação ele começa apresentando um estatística que, na minha opinião, é mais forte semelhança entre o processo de desenvolvimento de um novo produto em uma empresa já estabelecida e o processo de criação de uma startup:

Mais startups falham por falta de clientes do que por falha no desenvolvimento do produto.

No seu blog ele comenta que 9 de cada 10 startups falham o que me parece ser uma estatística válida também para novos produtos desenvolvidos em empresas já estabelecidas.

E por que isso acontece? Porque o foco do processo de desenvolvimento de produtos tradicional está voltado o lançamento do produto, deixando de lado o que Steve chama de Processo de Desenvolvimento de Cliente, ou seja, descobrir se esse produto que está sendo desenvolvido atende uma necessidade real do cliente. É o que Marty Cagan, ex-VP de Produtos do eBay e atualmente consultor de gestão de produtos, chama de Product Discovery.

Na apresentação abaixo, Steve Blank mostra como é o Processo de Desenvolvimento de Cliente e como ele se encaixa no desenvolvimento ágil de software.

Vale a pena ver também uma série de 9 vídeos de uma aula do Steve em Stanford. O 7º vídeo da série ilustra bem o Processo de Desenvolvimento de Cliente:

Por isso, se você não quer que seu produto falhe, quer você seja parte de uma startup ou de uma empresa já estabelecida, vá pra rua e teste suas idéias com clientes reais. Só assim seu produto poderá deixar de ser parte dessa triste estatística.

Be the first to like.

How should we draft an information architecture?
Sep 13th, 2009 by Joca

Actually, it’s quite simple, as Donna Spencer points out:

Just make it up.

Wait? Is it that simple? But in order to make it up you just ned one thing: information.

You need to understand what you are trying to achieve, what users of the service need and know, and you need to know the content well. If you don’t have these things, it will be hard. But if you do have them, pulling them together into a first draft is surprisingly easy.

Be the first to like.

Which one is the right product to invest?
Sep 6th, 2009 by Joca

Which one is the right product to invest?

Ice Cream Glove:

Snuggie:

Answer: there’s no way to know if you base your answer on opinions. The only way to be sure which one is the right investment is:

getting “out of the building” and testing ideas against reality, to find out what creates value for customers before spending all of our resources building it.

For those curious to know which of these products is a good product development investment and want to read more about how important it is to do customer research:

http://radar.oreilly.com/2009/09/is-your-product-an-ice-cream-g.html

Be the first to like.

Interfaces de usuário sensíveis a contexto
Jan 1st, 2009 by Joca

Uma tendência interessante é a de interfaces de usuário sensíveis a contexto. Além dos exemplos citados nesse link, outros bons exemplos são o Basecamp:

basecamp1

Ao passar o mouse sobre o primeiro item aparecem as ações que podem ser feitas nesse item:

basecamp2

Isso deixa a interface mais leve e, ao mesmo tempo, permite invocar as ações quando necessário.

A versão 2.7 do WordPress implementou esse conceito. Vejam a lista de posts:

wordpress1

E, ao passar o mouse sobre um título de post:

wordpress2

Be the first to like.

Protótipo: primeira impressão
Dec 28th, 2008 by Joca

A palavra protótipo vem do grego protos (primeiro) + typos (impressão) e é importante que usemos os protótipos de UX como primeira impressão de nossos produtos e sistemas, como sugere a origem da palavra.

If I can’t picture it, I can’t understand it

Albert Einstein

Na maioria das vezes que pensamos em protótipos de sistemas web, pensamos em protótipos que tenham alguma fidelidade ao produto final e que, se possível, sejam interativos para que possam ser usados em testes de usabilidade.

Existem várias ferramentas para se fazer protótipos. Algumas das mais conhecidas são:

Mas antes de se fazer um protótipo interativo fiel ao produto final, podemos fazer um rascunho de protótipo, algo sirva como ferramenta para discussão sobre o sistema. E para fazer esse tipo de protótipo não há ferramenta melhor do que lápis e papel! É barato, rápido e muito fácil de usar!!!

Termino esse post com alguns exemplos de protótipos rascunhados no papel, para dar idéia de quão poderosa é essa ferramenta.


1 person likes this post.

UX ágil
Dec 26th, 2008 by Joca

Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.

Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:

Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.

Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:

Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).

Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?

Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.

Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:

  1. Feedback: imagine que você tem em sua aplicação uma determinada função que não é executada na hora e que pode levar até 2 horas para acontecer. Na interface você implementa o comendo que executa essa função só que não informa o prazo. O usuário certamente vai se perguntar o que aconteceu, se a função foi de fato executada. Um solução é avisá-lo desse prazo logo após o comando ser invocado. O ideal é avisar antes mesmo de ele invocar o comando que executa a função.
  2. Opções: imagine que você está desenvolvendo um formulário de pagamento com opções de pagamento por cartão de crédito. Você recebe o protótipo com um select que permite escolher entre Amex, VISA e Mastercard. Você implementa esse protótipo. Na hora de colocar em produção você recebe a informação de que inicialmente o sistema só irá aceitar Mastercard. Você edita o select e remove as outras opções. A sua interface vai ficar com um select de uma opção só! O correto aqui seria remover o select enquanto houver uma opção só.

Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!

Be the first to like.

»  Substance: WordPress   »  Style: Ahren Ahimsa