Veja neste artigo uma maneira de descobrir o seu verdadeiro público-alvo, e aprenda também a contar estórias de usuários através de um método muito eficaz. Personas e User Story Mapping são muito utilizados no design centrado no usuário, essas técnicas poderão ajudá-lo a evitar problemas comuns nos projetos, e também a descobrir novas oportunidades de negócio.Vamos iniciar este artigo levantando um questionamento.
Como você tem organizado e priorizado os requisitos de um novo produto ou serviços interativos como softwares web, desktop, aplicativos mobile, entre outros?
Sabemos que a prática do trabalho de levantamento, organização e priorização de requisitos não é uma tarefa simples e requer sempre muita determinação de todo o time de product owners, analistas de negócios, usuários especialistas, programadores, designers, entre outros.
Requisitos são necessidades que expressam o que os produtos devem ter para serem bem sucedidos, portanto, devemos realizar algumas perguntas sobre o planejamento de requisitos para um melhor entendimento do projeto e para orientação de etapas posteriores:
- Quem são os stakeholders?
- Quais são os objetivos do projeto?
- Quais problemas estão envolvidos, e que devem ser resolvidos?
- Quem são os consumidores, e quem são os usuários do produto?
- Quais são os comportamentos, desejos e necessidades dos consumidores e usuários do produto?
- Qual é a visão do cliente?
- Qual é a visão do time do projeto, e quais as tecnologias estão envolvidas?
- Qual é a situação atual do mercado? Existem produtos concorrentes diretos e indiretos?
- Qual será a principal solução para o projeto? Será inovar, ou renovar?
- Qual será a duração do projeto?
- Qual será a verba investida no projeto?
- Quais são os fatores de risco do negócio?
Pense em direcionamentos e metas dos usuários, metas do consumidor e metas do negócio. Um fator de extrema importância é sempre pensar no ponto de vista dos usuários. Utilize pesquisas com usuários através de estudos qualitativos e quantitativos, com seus tipos fundamentais. Por exemplo, diversas técnicas de pesquisas podem ser utilizadas neste processo inicial como o uso de Personas; Benchmarking; Análise métrica; Mapas mentais; Etnografia rápida; Pesquisa contextual; Entrevista em profundidade; Metas dos usuários; Grupos focais, Questionários, entre outros.
Iniciando o trabalho com o uso de Personas - Saiba o que são e porque utilizá-las nos seus projetos?
Personas são personagens fictícios, modelos descritivos criados para representar a definição do cliente típico. Existem tipos de usuários dentro de um alvo demográfico, com comportamentos e atitudes definidos, e que podem utilizar essas informações de uma forma produtiva para que toda ação e tomada de decisão sejam direcionadas àquele perfil quando em se trata de um site, uma marca ou produto de um modo similar. Personas são úteis para identificar características comuns entre os potenciais usuários, ajudando a selecionar e definir o perfil comportamental dos consumidores.
Normalmente pensamos sempre no público-alvo nos projetos, mas o conceito de personas vai muito além daquilo que conhecemos como públicos A, B, C, etc. Com o uso de personas, conseguimos personalizar os indivíduos com uma maior riqueza de detalhes. Veremos abaixo um exemplo prático das diferenças entre público-alvo e personas.
- Público-Alvo: Mulher, idade entre os 30 e os 40 anos. Formada em cursos relacionados à área de Sistema de Informação, com pós-graduação em áreas relacionadas à sua própria formação. Residente em Belo Horizonte, casada e com dois filhos.
- Personas: Maria Eduarda, tem 37 anos e é formada em Ciências da Computação com pós-graduação em Arquitetura de Software. Ela é fã de novas tecnologias e produtos inovadores. Tem uma vida bastante corrida, pois, além de trabalhar em período integral em uma multinacional da área de tecnologia como Analista de Negócios Sênior, também é sócia diretora em uma Editora de Revistas Digitais com o seu marido. Ela é responsável pela área de planejamento e novos negócios da empresa, e trabalha sempre para encontrar as melhores tecnologias e soluções para serem utilizadas nos projetos. Ela ama dedicar parte do seu tempo em projetos de inovação na área da educação. É uma mulher comunicativa, empreendedora e está sempre antenada para as novas tendências e oportunidades do mercado.
Maria Eduarda está casada há 13 anos e tem dois filhos, sendo que um deles está com 10 anos de idade, e o outro filho com 4 anos. Todos os dois estudam em horário integral, em uma escola tradicional da região onde mora.
Maria Eduarda também é uma mulher religiosa e frequenta a igreja uma vez por semana (aos domingos com sua família). Aos finais de semana, Maria Eduarda e sua família sempre busca almoçar fora de casa, se possível é claro em um bom restaurante da zona sul de Belo Horizonte.
Maria Eduarda reside no bairro Belvedere em um apartamento de luxo com cobertura, com uma bela vista para a cidade.
Ela gosta sempre de acompanhar as novidades da moda. Frequenta o cabeleireiro no mínimo a cada quinze dias, e ama cores vivas, além de sapatos elegantes. Ela está sempre bem vestida e mantém a forma com bons hábitos alimentares.
Fala inglês fluentemente, mas pretende estudar e aprimorar mais o seu espanhol, que ainda está no nível intermediário. Italiano também é uma língua que ela pretende estudar no futuro.
Tem como maior ambição, neste momento, abrir uma filial da sua empresa nos Estados Unidos. Local onde há dois anos passa férias com a sua família, e tem aproveitado o momento de descanso também para conhecer melhor o mercado exterior. Ela está disposta a deixar a multinacional muito em breve para se dedicar exclusivamente para sua empresa.
Apesar de nos últimos dois anos ter viajado e passado férias nos Estados Unidos, Maria Eduarda ama viajar para países mais distantes; mais recentemente em um feriado prolongado, ela e sua família fizeram uma viagem para o Japão, e aproveitaram para conhecer rapidamente a cidade de Pequim, na China.
Portanto, podemos concluir que: o uso de personas é bastante útil e importante para uma melhor compreensão do comportamento do usuário. Como pensam, o que desejam, quais serviços precisam, quais são suas aspirações, como preferem ser atendidos, que tipo de relação esperam, por quais valores estão dispostos a pagar, e como é o seu comportamento digital. Estas são algumas definições que conseguimos identificar com o uso de personas. Modelamos personas para determinar os requisitos do produto, para comunicar a documentação com a equipe envolvida, e para validar as ideias medindo a efetividade do design.
Procure sempre listar características de cada tipo de persona, criando-as a partir de um nome e foto que represente este grupo de usuários, frase ou slogan que capture a sua personalidade, dados demográficos, dados tecnológicos, nível de educação, perfil profissional, histórico pessoal, estilo de vida, objetivos, valores e atitudes, necessidades, motivação, desejos, expectativas, conhecimento na área, contexto de utilização do produto, frequência de uso, entre outros.
Veja na Figura 1 um exemplo prático de uma construção de um grupo de personas.
User Story Mapping – Aprenda a criar mapa de estórias de usuários
Após o uso de personas nos seus projetos, aprenda a utilizar outra técnica muito eficaz no design centrado nos usuários. Esta metodologia foi criada em 2005 por Jeff Patton e é chamada de User Story Mapping (Mapa de Estórias de Usuários). A estória do usuário é uma forma de facilitar a comunicação e entendimento, e merece todo o destaque por sua característica colaborativa e que propicia uma discussão entre a equipe e os stakeholders sobre os aspectos mais relevantes da experiência do usuário. Jeff Patton define que: “Story Mapping é uma técnica colaborativa, que auxilia na priorização e planejamento de releases de produtos interativos”.
Pense que você precisa desenvolver um novo produto, e como em quase todos os projetos, existem problemas de comunicação. Normalmente estes problemas acontecem pelo fato dos clientes não saberem exatamente o que querem, ou porque encontram dificuldades em transmitir de forma clara e objetiva as suas necessidades e desejos. Existe também o fato dos profissionais envolvidos no projeto quase sempre não atenderem as demandas do negócio, e não conseguirem se comunicar e entender as necessidades dos clientes. Isso é quase sempre comum de acontecer, e o resultado disso tudo são mudanças constantes no escopo e nos requisitos durante o desenvolvimento ou na fase final quando o produto é entregue. Veja na Figura 2 o que constantemente acontece no desenvolvimento de um novo produto.
Prejuízo, retrabalho, e insucesso acontecem muitas vezes por falhas que estão relacionadas aos requisitos. Para uma boa prática de comunicação é preciso definir uma linguagem comum, ser objetivo e ter simplicidade na busca de melhorias na comunicação e no entendimento do projeto. A utilização das User Stories Mapping poderá lhe ajudar a encontrar as melhores práticas de experiências com os usuários.
Essa técnica é utilizada na definição do backlog. No Scrum, por exemplo, o backlog consiste em uma lista simples, enumerada de cima para baixo, das funcionalidades com maior prioridade para as de menor prioridade. Portanto, o product backlog é uma lista de todas as funcionalidades desejáveis num sistema, com uma ordem de prioridade. E esta forma “linear” de organização contém alguns problemas na visão de Jeff Patton, como por exemplo, a dificuldade de compreensão e comunicação na “visão do todo” do produto para os stakeholders. Já na questão da priorização, acontece na maioria dos casos uma contemplação apenas do ponto de vista do negócio e não da utilidade do ponto de vista dos usuários. Veja na Figura 3 onde devemos aplicar essa técnica chamada user stories mapping.
O backlog proposto por Jeff Patton não é uma lista, mas sim um mapa das user stories. A sugestão de Patton é que a aplicação do método seja feita em grupo, onde todos os envolvidos (analista de negócios, analista de marketing, analista desenvolvedores, designers, clientes, usuários, entre outros), possam dar sua contribuição. Veja na Figura 4 um exemplo de backlog proposto por Jeff Patton.
Veja a seguir o material e pré-requisitos necessários para se criar uma User Story Mapping na prática:
- Parede, mesa ou flipchart (conhecido como tripé ou cavalete, é um tipo de quadro com vários blocos de papéis);
- Post-its;
- Canetas;
- Time multidisciplinar (como citado acima, inclui, por exemplo: stakeholders, analistas de negócios, analistas de marketing, analistas desenvolvedores, designers UX, designers UI, clientes, usuários, entre outros);
- Quatro a oito pessoas participantes;
- Preparar um bom lanche para os participantes, e que seja um momento divertido e proveitoso.
As fases do método
O método é aplicado nas fases iniciais do ciclo de vida dos produtos, na etapa de geração de ideias, de concepção e estratégia do produto, fase em que são mapeadas as necessidades dos usuários e funcionalidades do projeto. Jeff Patton orienta e instrui com uma lista das principais etapas da aplicação. Veja esta lista abaixo:
- Listar as user stories (lista de funcionalidades do produto/projeto):
Neste momento é recomendado realizar um brainstorm em conjunto com toda a equipe presente, deve-se levantar uma lista de funcionalidades do produto e pensar em conjunto: “Quais são as funcionalidades que o usuário poderá executar com este sistema?”. Mantenha sempre o ponto de vista do usuário ao responder essa pergunta, focando nas tarefas dos usuários sem entrar em detalhes de implementação. É sugerido levantar uma lista com cada item, e que comece com um verbo, lembre-se sempre de pensar no ponto de vista dos usuários (Exemplo: Selecionar um produto, Escolher a forma de pagamento, Pagar pelo produto, Escrever um comentário, Publicar nas redes sociais, entre outros).
- Escrever as user stories em cartões de estórias:
Depois de um levantamento inicial de funcionalidades, é necessário escrever em um cartão diferente cada item proposto, a forma de escrita nos cartões deverá ter três detalhes de priorização e planejamento dos releases, que são eles: o usuário, a frequência de uso daquela funcionalidade e o valor de negócio que ela tem. O usuário poderá ser representado pela sua profissão ou pelo papel que desempenha (exemplo: "Administrador" ou “Comprador/Vendedor”). A frequência de uso pode ser mais precisa (exemplo: diariamente, semanalmente, quinzenalmente, entre outros) ou até mais subjetivas (exemplo: muito, pouco, raro), mas neste caso irá depender do nível de conhecimento que a equipe tem a respeito dos hábitos e características de seus usuários. Já o valor para o negócio, deve-se utilizar (exemplo: baixo, médio ou alto). Veja na Figura 5 um exemplo de uma user story escrita em cartões.
![Exemplo de uma user story escrita em cartões]()
Figura 5. Exemplo de uma user story escrita em cartões - Ordenar em um fluxo de tarefas:
Para o próximo passo, é necessário ordenar os cartões em uma sequência lógica de tarefas com o objetivo de contar uma estória de como o sistema funciona (Exemplo: inicialmente o usuário escolhe um produto, depois ele define os detalhes do produto, e depois ele realiza a compra do produto, e no final compartilha a sua compra nas redes sociais com seus amigos). O objetivo é contar uma estória de como o sistema funciona e também é sugerido sobrepor os cartões que aconteçam ao mesmo tempo. Veja na Figura 6 um exemplo de uma sequência de fluxo de tarefa com cartões sobrepostos.
![Exemplo de uma sequência de fluxo de tarefa com cartões sobrepostos]()
Figura 6. Exemplo de uma sequência de fluxo de tarefa com cartões sobrepostos - Priorizar e organizar verticalmente (conforme criticidade):
Após definir a ordem dos cartões em um fluxo de tarefas que faça sentido para a equipe, e pensando sempre na melhor experiência dos usuários, o próximo passo é priorizar e organizar verticalmente as tarefas. Esta é a etapa em que se devem ajustar os cartões conforme a criticidade (verticalmente). Conforme as user stories se tornem mais importantes e mais críticas, a ordem ficará mais no topo do fluxo. As user stories que estavam inicialmente sobrepostas e que aconteciam no mesmo momento que outras tarefas, devem ser priorizadas, nunca se esquecendo de levar em consideração sua importância para usuário. Portanto, devem-se colocar acima as tarefas mais importantes como, por exemplo, as que tenham alta frequência e alto valor para o negócio. Também é importante discutir com toda equipe neste momento a criticidade de cada funcionalidade para o negócio. Veja na Figura 7 um exemplo de priorização e organização vertical (conforme criticidade).
![Exemplo de uma organização e priorização vertical (conforme criticidade), de acordo com a frequência de uso e valor]()
Figura 7. Exemplo de uma organização e priorização vertical (conforme criticidade), de acordo com a frequência de uso e valor - Agrupar por atividades macros:
Neste momento o backlog é um mapa de user stories, onde a identificação de cada cartão é na verdade uma atividade de agrupamento das tarefas em segmentos ou grupos representados pelos usuários no sistema/produto. Torna-se necessário segundo Jeff Patton, uma quebra no fluxo das tarefas pelo fato de poder acontecer mudanças de usuários, regras de negócio e processos. Portanto, traçam-se linhas verticais identificando cada fluxo, e dando nomes a eles. Veja na Figura 8 um exemplo de agrupamento por atividades macro e conjunto de tarefas.
![Exemplo de agrupamento por atividades macro e conjunto de tarefas]()
Figura 8. Exemplo de agrupamento por atividades macro e conjunto de tarefas - Selecionar o primeiro release:
Selecione o menor número e mais conciso de funcionalidades, e que torne o primeiro release minimamente útil (MVP – Produto Viável Mínimo) para o usuário e para o contexto do negócio. Marque no mapa o primeiro release, este normalmente será a primeira linha de estórias do mapa em que o usuário conseguirá utilizar o sistema. Jeff Patton utiliza o termo release span para definir o que seria o primeiro release, mas que não é necessariamente o primeiro a se tornar público do sistema. Veja na Figura 9 um exemplo do que chamamos de primeiro release, e que possibilita a entrega de um produto mínimo viável, o MVP que é a versão mais simples e com valor suficiente para ser lançada, onde as pessoas possam começar a utilizar o sistema/produto.
![Exemplo da separação do primeiro release minimamente usável]()
Figura 9. Exemplo da separação do primeiro release minimamente usável
Uma das coisas mais interessantes em se utilizar as user stories mapping é o fato de este método ter uma característica colaborativa, e que estimula a participação e discussão entre a equipe, sob é claro, o ponto de vista dos usuários. Através deste diálogo, é possível estimar o esforço total necessário para execução do primeiro release do sistema/produto. Ou seja, após a identificação do primeiro release, a marcação e programação dos próximos releases poderão continuar com a realização de novas estimativas, e também realizando o levantamento de quais funcionalidades estarão contidas em cada cartão. Este é mais um momento importante do uso deste método, pois, cada membro da equipe (e stakeholders) poderão trazer sua visão e experiência do negócio, em conjunto com uma abordagem ágil para evitar que funcionalidades desnecessárias sejam criadas e desenvolvidas durante as próximas fases do projeto. Veja na Figura 10 um exemplo prático do uso de personas e user story mapping.
Com isso, vimos neste artigo como trabalhar com personas e user story mapping, aprendemos que estas técnicas são muito úteis no design centrado no usuário. Através delas você conseguirá identificar de forma mais precisa o seu público-alvo, e irá contar estórias para facilitar toda a comunicação com o time envolvido, além de obter uma “visão do todo” do projeto criando um mapa de ações dos usuários.
