Este artigo tem por objetivo ajudar a esclarecer o handoff ou a “passagem de bastão” entre as pessoas de produto e as pessoas designers.Antes que você pergunte: não, não é um processo em cascata.É um processo dinâmico e iterativo, com o objetivo de alinhar a comunicação sobre “o que” deve ser feito, com o “como” isso deve ser feito sob a ótica de design.Ter um processo visível para todos, reforça o comprometimento e gera confiança entre as pessoas durante o processo de criação de um produto digital.Público-alvo: Product Managers, Product Leaders, Product Owners e designers em geral.
⚠️ Desejável mas não obrigatório: 1. Desenhar para ajudar a entender, rabisco frames ou wireframes muito simples.2. Caso de uso associado à sugestão de uso de determinado componente do Design System. Exemplo: se o componente sugerido é uma timeline de cliente ou uma lista de clientes.
O que é esperado das pessoas de produto?
É um trabalho de pares, então são pessoas que estão pareando junto com o time de desenvolvimento para construir o produto e entregar os épicos ou projetos. Nem designers nem product managers estão acima ou abaixo um do outro. São trabalhos que andam lado a lado.Antes do processo iniciar, é esperado que a pessoa de produto reuna todos os artefatos possíveis para ajudar a pessoa designer a desenvolver o seu trabalho. E também é importante estar disponível durante esse período para dúvidas, validações, negociações de entregas, etc.
Reunião Kickoff
Nessa etapa a pessoa de produto deve fazer um levantamento com os stakeholders e responder algumas perguntas que são essências para um entendimento do problema que estamos resolvendo.- Comece pelo problema que estamos resolvendo. Entenda o objetivo. Por quê, como e o quê.
- Qual é o resultado esperado Jobs to be done
- Persona: Para quem estamos fazendo
- Jornada dessa persona ou jornada de usuário
Criação dos épicos
Um épico é uma história de usuário maior que contém várias histórias em diferentes sprints. Na metodologia ágil, todos os requisitos do cliente são desenvolvidos em uma história de usuário e são armazenados no backlog.💡 Resumindo: É a jornada que vai ser desenvolvida declarada em alto nível.Criação das histórias dos usuários
Uma história do usuário é uma explicação informal e geral sobre um recurso de software escrita a partir da perspectiva do usuário final ou cliente. O objetivo de uma história de usuário é articular como uma única tarefa pode oferecer um determinado valor ao cliente.- Criação das histórias
- Quais histórias iremos abordar
- Priorização/ em qual ordem
Criação dos critérios de aceitação
Os critérios de aceitação são aqueles critérios, incluindo requisitos de desempenho e as condições essenciais, que devem ser atendidas antes do entregas do projeto ser aceito. Eles determinam as circunstâncias específicas sob as quais o cliente aceitará o resultado final do projeto.✅ Exemplo de critérios de aceitaçãoDADO que eu sou um cliente da [EMPRESA] QUANDO eu clico no relatório E tenho uma visualização dos dados que preciso analisar ENTÃO consigo filtrar pelos dados desejados QUANDO eu tenho a visualização desejada na tela ENTÃO eu consigo exportar um PDF.Definition of ready para fazer o handoff para Designers
💡 Resumindo: O entregável prático é um card ou uma documentação mínima (e simples) contendo a tarefa de design com os seguintes itens abaixo:- O problema que estamos buscando resolver (Épico/ Projeto)
- Resultado esperado (Outcome)
- Histórias de usuário que contemplam neste card
- Critérios de aceitação: o que é esperado que a pessoa designer contemple na solução (Ex: é esperado que com essa aplicação a pessoa usuária possa começar um teste A/B, definir um experimento vencedor e analisar os resultados).
⚠️ Desejável mas não obrigatório: 1. Desenhar para ajudar a entender, rabisco frames ou wireframes muito simples.2. Caso de uso associado à sugestão de uso de determinado componente do Design System. Exemplo: se o componente sugerido é uma timeline de cliente ou uma lista de clientes. 
