Melhorias no processo de discovery

O problema estava no processo, não no produto

Na Fraktal, cada product designer era responsável pelo produto, do briefing ao protótipo e à entrega final. O processo de discovery já tinha uma estrutura, e nosso time de designers estava sempre buscando formas de melhorá-lo. Passando por projetos diferentes, comecei a notar problemas que se repetiam em todos, independentemente do cliente. Em vez de resolvê-los caso a caso, transformei cada um em uma ferramenta do processo.

Cinco problemas recorrentes, cinco iniciativas

1. 1

   Ideias boas que surgiam no meio do projeto iam para um quadro de post-its e se perdiam. A V2 começava do zero.

   Estacionamento de ideias
2. 2

   Integrações só eram mapeadas no desenvolvimento. Cadastros demorados, como o das lojas de apps, atrasavam a entrega.

   Tabela de integrações
3. 3

   O cliente precisava aprovar uma estrutura sem visual e não conseguia entendê-la. Estados de erro eram esquecidos.

   Userflow por módulo
4. 4

   Muitos produtos tinham mais de um público, com acessos diferentes. Sem uma visão única, surgiam brechas e retrabalho.

   Matriz de permissões
5. 5

   Em produtos por assinatura, o que cada plano libera ficava implícito até o desenvolvimento.

   Planos e acessos

Onde cada uma entra no processo

Dizer “agora não” sem dizer “não”

Em projetos rápidos, as ideias não param de surgir: do cliente, do time e do próprio discovery. Se tudo entra, o MVP não termina em 90 dias. Se nada é registrado, a próxima versão começa do zero. O time já tinha um estacionamento de ideias, mas era só um quadro de post-its: as ideias ficavam ali, sem critério, e quase nunca voltavam à mesa. Reestruturei esse quadro para que ele pudesse ser explorado, priorizado e mensurado, e virasse a base da V2.

Como construí

1. A cor diz que tipo de ideia é

   Defini cinco tipos, para que o time leia o quadro de longe e entenda a natureza do que está parado ali.

   • RiscoAlgo que pode comprometer o produto e precisa de atenção
   • HipóteseAlgo que precisa ser testado antes de virar funcionalidade
   • RefatoraçãoMelhoria em algo que já existe
   • AutomaçãoTarefa manual que pode ser automatizada
   • EvoluçãoUma funcionalidade nova

2. A posição diz a prioridade

   Cada ideia é posicionada numa matriz de impacto e esforço. Os quadrantes têm nomes que já dizem o que fazer com o que está neles.

   Ganhos rápidosAlto valor, baixo esforço

   Grandes apostasAlto valor, alto esforço

   Baixa prioridadeBaixo valor, baixo esforço

   Questionar ou reavaliarBaixo valor, alto esforço

3. Uma área só para o cliente

   Algumas ideias não avançam sem uma definição do cliente. Separei essas pendências numa área própria, que vira a pauta das reuniões de validação.

   Decisões a validar com o cliente

   O que o time pode decidir fica na matrizO que depende do cliente fica aqui

Por que ele importa

Descobrir dependências antes do código

Muitas integrações só eram mapeadas na hora do desenvolvimento. Algumas exigem cadastro, aprovação ou contrato com terceiros, como a publicação nas lojas da Apple e do Google, que leva dias. Quando isso aparece no fim, a entrega atrasa por um motivo que não é de design nem de código.

Tornar visível o que não tem tela

Entre o fluxograma de módulos e o detalhamento das telas havia um vazio: as decisões, os erros e os caminhos alternativos não apareciam em lugar nenhum. O cliente não conseguia validar uma estrutura sem visual, e os estados de erro acabavam esquecidos até o desenvolvimento. Implementei o userflow como uma etapa do processo para tornar essa parte visível.

As regras que defini para usar

• Só onde há ramificação realUm userflow por módulo com decisão condicional, como autenticação ou checkout. Não precisa em todo módulo.
• Depois da arquitetura, antes das telasEle nasce do fluxograma de ambientes e módulos e vem antes do detalhamento de funcionalidades.
• Validado com o clienteO cliente aprova os caminhos antes de as telas serem detalhadas, o que evita correções depois.
• Base para a especificaçãoCada losango vira uma regra e cada círculo vermelho vira um estado de erro em Funcionalidades e Critérios de aceite.

Quem pode o quê, e em qual escopo

Em muitos projetos, o mesmo produto atendia mais de um público em ambientes diferentes. Sem uma visão única, as permissões ficavam espalhadas pelas telas, e o resultado eram brechas de acesso e retrabalho no desenvolvimento. Criei uma matriz que cruza cada ação com cada papel, ambiente por ambiente.

O detalhe que faz diferença

A regra da assinatura, módulo por módulo

Em produtos por assinatura, como o Spotify, cada plano libera um conjunto diferente de funcionalidades. Quando isso fica implícito, o dev precisa deduzir e o cliente só descobre a regra no protótipo. Criei uma tabela que mostra, para cada módulo, o que cada plano libera, inclusive os limites parciais.

Como saber se o processo melhorou

Estas iniciativas foram criadas para o processo do time, então ainda não há números para mostrar. Estes são os indicadores que eu usaria para acompanhá-las:

O que estas iniciativas me ensinaram

• Um problema que se repete em todo projeto é um problema de processo. Resolver uma vez ajuda o time inteiro.
• Uma boa ferramenta de processo é um template simples, com instruções curtas, que qualquer designer do time consegue usar sem precisar de explicação.
• O que não aparece na tela também é design: fluxos, regras, acessos e prioridades são decisões de produto tanto quanto o layout.

• Design de processo
• Discovery
• Priorização
• Gestão de escopo
• Especificação para dev
• Regras de negócio