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.
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ção
DADO 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).
⚠️ Importante: vincular neste card todos os documentos que estão associados e que vão ajudar o trabalho da pessoa designer.
⚠️ 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.
Qual o processo mínimo de Design?
Neste momento é esperado que a pessoa designer assuma a liderança do processo, conduzindo as etapas e validando com stakeholders de forma colaborativa. Através de facilitações de dinâmicas e desenvolvimento da proposta de solução para o problema inicialmente apresentado.
Wireframe – Baixa fidelidade
Nenhuma solução de design é feita partindo de alta fidelidade. Comece esboçando as interfaces, é uma etapa ao qual a pessoa designer está explorando formas de resolver o problema de forma rápida, gastando mais tempo na arquitetura da informação e nas interações que precisam ser desenvolvidas, e menos tempo no visual design.
Validação do fluxo com stakeholders
Compartilhe o que foi desenvolvido na etapa de criação de wireframe com os stakeholders envolvidos, dessa forma você pode fazer iterações de uma forma rápida para conseguir seguir para as próximas etapas.
Iteração
Aplique as evoluções e melhorias que foram indicadas pelos stakeholders envolvidos.
Prototipação utilizando o Design System – Alta fidelidade
Já com o wireframe 100% finalizado e aprovado pelos stakeholders envolvidos, passe para a prototipação em alta fidelidade. Sempre que possível utilize como referência o design system se houver.
Validação com stakeholders
Com o protótipo navegável concluído, compartilhe os links para os stakeholders envolvidos avaliarem o resultado final.
Design Review
A cerimônia de Design Review é um encontro que as pessoas designers compartilham o seu trabalho antes de enviar o handoff para o time de desenvolvimento. Nesse encontro, garantimos que o Design System está sendo utilizado da maneira correta, minimizando inconsistências no futuro.
Handoff para o time de engenharia
Após a passagem pela Design System Review e aprovação dos stakeholders, a pessoa designer organiza seu arquivo com todos os fluxos, cenários de erro e especificações de negócio, de uma forma que fique claro para quem está consumindo.
⚠️ Atenção: Algumas dessas etapas podem acontecer de forma simultânea. Principalmente etapas de validações com stakeholders.
EN 
BR