As 5 etapas de um processo de solução

Problema — Benchmark — Hipóteses — Validação — Lançamento

No cenário atual existem diversos perfis de designers, alguns com maior conhecimento de um produto e maior experiência em suas carreiras e outros com menor conhecimento de um produto e menor experiência.

Para garantir um nivelamento das soluções e dar mais transparência as atividades que competem a um designer, independente do conhecimento do produto ou sua experiência, seguir um processo de solução sempre ajuda no desenvolvimento de um produto e atualmente o processo que tenho seguido é composto por 5 etapas:

Problema — Benchmark — Hipóteses — Validação — Lançamento

1 — Problema

Nesta etapa busco identificar e entender as principais dores de nossos usuários.

E para entendermos melhor os problemas procuro analisá-los em 3 esferas complementares que são, o problema na visão do sistema, o problema na visão do usuário e quanto isto está alinhado com a visão do negócio.

Existem várias técnicas para conseguirmos obter essas respostas, e duas delas são:

Análise quantitativa

Tem como objetivo embasar os problemas numericamente, cruzando informações como Volume de dados (quantidade, período) VS Dados do cliente (segmento, estágio da jornada de sucesso), esse cruzamento nos trás uma visão detalhada de quantas vezes o problema está ocorrendo e qual é o grau de dificuldade enfrentado pelo usuário.

E gera insumos para a análise qualitativa.

Análise qualitativa

Essa análise tem como objetivo entender as principais dificuldades do ponto de vista do usuário, coletando suas percepções, as percepções dos stakeholders e de todos os envolvidos no processo, através de entrevistas, criação de personas, brainstorms, ou seja, o intuito aqui é envolver o usuário desde o primeiro momento do processo e garantir que o que vai ser desenvolvido atenda as suas necessidades e realmente entregue valor.

2 — Benchmark

O benchmark serve como inspiração e gera metas específicas, além de estabelecer o ponto de partida usado para comparar como nossas iterações estão afetando a experiência dos usuários.

Principais players

Seguindo a análise comparativa a primeira ação é conhecer quem são nossos principais concorrentes e analisar como eles solucionaram ou estão solucionando os mesmos problemas enfrentados por nós.

Principais características

Na sequência levanto as principais características e as comparo com as dos concorrentes, fazendo isso gero um arsenal de ideias que mais tarde colaborarão para o desenvolvimento de uma solução ainda melhor do que as existentes no mercado.

Quadro comparativo

E para sintetizar tudo isto, monto um quadro comparativo com as características que desejamos alterar e as comparar com as de nossos concorrentes, isso possibilita uma visão abrangente de como o produto está em relação ao dos concorrentes e quais são os pontos que podem ser melhorados.

3 — Hipóteses

Com os principais problemas mapeados e uma visão do que os concorrentes estão fazendo parto para a geração de hipóteses.

Com os principais problemas mapeados e uma visão do que os concorrentes estão fazendo parto para a geração de hipóteses.

Alinhamento entre problema e benchmarking

A relação entre o problema e o benchmarking possibilita a geração de hipóteses consistentes e que realmente sejam efetivas na resolução dos problemas.

Defender o plano junto aos stakeholders

Depois de gerar as hipóteses para serem trabalhadas o designer tem o compromisso de apresentar uma proposta de solução a sua equipe e assim defender o porque ela deve se concentrar em resolver aqueles problemas.

Entregas incrementais

Feita a apresentação e o alinhamento necessário, o designer quebra os problemas em estórias independentes que possam gerar valor o mais rápido possível e assim realizar entregas incrementais no produto.

Vale ressaltar ainda que a geração de hipóteses muda a percepção que a equipe tem sobre design, porque o design passa a ser visto como uma ferramenta para validar ou invalidar hipóteses que estão bem embasadas.

4 — Validação

Depois de definidas quais as hipóteses serão atacadas é hora de estressa-las e validá-las antes de serem lançadas para os usuários.

Validar de forma objetiva

A validação compreende a construção de protótipos que podem ser de baixa, média e alta fidelidade.

A questão principal aqui é identificar aquele protótipo que consegue validar de forma objetiva a solução, e ainda prever os diferentes cenários e ao mesmo tempo ter o menor esforço possível. E esse esforço é medido entre o tempo de trabalho versus o custo de desenvolvimento.

Necessidade VS Complexidade

Não existe um protótipo certo ou errado, o designer deve ser coerente em suas decisões fazendo uma relação entre o momento e necessidade do projeto com a complexidade do problema que esta procurando resolver.

Testes de usabilidade

Com o protótipo em mãos é hora de envolver os usuários para validá-lo e assim recolher insights que ajudarão a melhorar a proposta de solução.

Para validar os protótipos são realizados testes de usabilidade remotos, pois além de os usuários estarem em seu local de trabalho se torna muito mais rápido e mais barato do que testes em campo.

Mesmo em um teste de usabilidade remoto que é mais limitado que o teste presencial consigo captar o “estado de espírito” do usuário por meio da fala, e apesar de não ser algo que é medido, dá uma percepção de que se o que estou entregando faz sentido ou não para os usuários.

Além de validar o que estou propondo como possível solução, um dos principais objetivos em realizar testes de usabilidade é tornar o software cada vez mais fácil de usar, e com os testes remotos consigo medir a eficiência e a eficácia dos usuários ao realizar determinadas tarefas.

Ciclo de aprendizagem

Depois de aplicados os testes de usabilidade e recolhidos os principais insights o Designer aplica melhorias no protótipo tornando-o ainda mais consistente, criando um ciclo de aprendizado que basicamente é Aprender — com a geração de hipóteses, Construir — um MVP o mais rápido possível e Medir — com dados reais, disseminando a cultura ágil dentro de sua equipe.

5 — Lançamento

Com a solução validada e testada é hora de fazer o seu lançamento.

Rollout controlado

E para isso separo uma base de clientes, um grupo controlado que receberá a nova versão. Dessa forma garanto que as modificações sejam realizadas gradativamente e consiga analisar se o que estou entregando obtém os resultados esperados.

Critérios de sucesso

Um dos grandes segredos da fase de lançamento é ter os critérios de sucesso da nova funcionalidade bem definidos e ter em mente as estratégias e ações claras para atingir estes critérios.

Comunicação

Nessa etapa é feita toda a comunicação para os usuários, tanto internamente através de notificações, in-apps e links que levam para materiais educativos na central de ajuda, como externamente através de post’s e emails enviados para a base de clientes.

Isso garante que os usuários não sejam pegos de surpresa ao acessarem a feature que passou pela reformulação, assim procuro suavizar o máximo possível o primeiro contato com as novas modificações.

Essas são as 5 etapas do processo que utilizo atualmente no desenvolvimento de soluções.

Um processo de solução bem estruturado e flexível além de auxiliar o designer no seu dia a dia permite a ele:

• Aplicar as melhores técnicas em cada uma das etapas do processo
• Preservar recursos como tempo e dinheiro
• Chegar a resultados ainda mais consistentes.

Este post tem como objetivo dar uma visão global sobre o processo, ele é o primeiro de uma série de artigos onde irei abordar cada uma das 5 fases do processo de solução.

E você? Usa algum tipo de processo? Deixe seu comentário…