Documentação, Handoff e QA: Comunicação em Product Design
O que estou compartilhando aqui são métodos que deram certo pra mim, deixando a relação com os stakeholders (PO/PM, Dev, QA, CS, etc) mais tranquila, diminuindo estresse e atrito, facilitando a colaboração e ajudando diferentes áreas a se entenderem melhor. A maior parte do contexto que apresento aqui ocorre dentro de uma estrutura corporativa e com métodos ágeis, mas é importante ressaltar que essa recomendação é aplicável a outras configurações.
Durante minha jornada como designer enfrentei problemas com falta de documentação de processos, produtos, features, alterações etc. Outra questão é o frequente enrosco entre designers e desenvolvedores. Provavelmente você também já passou por isso em algum grau.
Se você ainda não teve experiência em uma empresa ou não está familiarizado com o uso de um Design System, aviso que utilizarei termos relacionados. Não se desespere; este é um convite para explorar novos conceitos e desafios.
Como designer, especialmente em níveis júnior e possivelmente intermediário, muitas vezes aceitamos o processo estabelecido pela empresa, com espaço para sugestões, mas sem necessariamente ditar as regras. Este é um aspecto natural do desenvolvimento profissional. Além disso, é válido mencionar que quanto maior o nível de maturidade do design na empresa, mais fluido pode ser o processo de documentação e handoff, e nosso papel é aprimorá-lo.
Skills importantes: saber comunicar e colaborar. Sem desenvolver essas habilidades, você vai nadar e morrer na praia.
Prepare-se para explorar este método de handoff, descobrindo como a documentação eficiente não apenas facilita o processo, mas também eleva a colaboração entre design e desenvolvimento.
Antes de tudo, 2 mantras:
- Organize seu arquivo!!!!!!! A seção é sua melhor amiga, use um sumário e cuidado para não ter muitas páginas no Figma. Se você precisar de um local para referências, testar possibilidades etc, agrupe tudo isso em uma página ou sessão e deixe claro o que é. Não deixe as outras pessoas perdidas.
- Documentação deve ser detalhada. Peque pelo excesso. Melhor ser redundante do que ter informação de menos.
📙 Documentação: Comunicar para o futuro, para todos
Invariavelmente você não será a primeira, nem a última pessoa a trabalhar em um produto. É complicado não saber porque uma decisão foi tomada de uma forma e não de outra, ou como deveria ser o comportamento de um componente, por exemplo.
Uma documentação é um organismo vivo, serve para todos da empresa que possam vir a ter contato com o produto, e deve ser construído em colaboração. Parte do nosso trabalho (dividido com outros stakeholders, mas principalmente PM/PO) é manter um histórico atualizado do que foi, é e será o produto. Documentação é para colocar todo mundo na mesma página do que está acontecendo. Deve ser confiável.
Dependendo do projeto (se haverá um discovery muito amplo, se é um novo produto, se são features menores etc), você já terá algumas definições antes de iniciar qualquer coisa. Anote tudo. Todas as dúvidas, insights, questionamentos, ideias. Isso já é documentação. Esses dados servem para nós mesmos (a memória é uma coisa interessante, mas falha) e quem vem depois precisa entender como as decisões foram tomadas. Pense no curto, médio e longo prazo.
Imersão/Discovery e Definição
Tenha um board (Miro, Mural, Figjam, etc) para reunir todas as informações de contexto, pesquisa, referências, etc. Eu prefiro, em relação a um documento apenas escrito, pois permite ver tudo de uma vez só e nos dá mais liberdade de interagir com o conteúdo que está ali.
O melhor cenário é o que toda a documentação está em apenas um lugar, mas esse tipo de arquivo nem sempre funciona para todo mundo e possivelmente há um local (colaborativo, online) onde é feita a documentação técnica, com regras de negócio, descrições, tabelas e outras informações (Notion, Confluence, Get Outline, etc). É para esse repositório que o link desse board deve ir, de modo que as informações fiquem sempre atualizadas. Lembre-se de também incluir o link da documentação no board, assim quem chega em um consegue ir para o outro facilmente.
No Figma quase tudo pode. Mas é importante entender a viabilidade técnica do que vai pro ar com antecedência e não sair criando mil coisas que não podem ser implementadas, ou que demandam muito esforço.
Envolva uma pessoa desenvolvedora desde o início. Se você não sabe quem ficará responsável pelo desenvolvimento, puxe alguém para tirar dúvidas e ficar a par do que pode vir a ser feito. Não precisa, e talvez não haja tempo para que vocês fiquem pareados até o fim da entrega, mas é legal ter um ponto focal pra conversar. Isso é mútuo: dúvidas e questionamentos suas sobre desenvolvimento e da pessoa desenvolvedora sobre design.
Desenvolvimento (de Design)
Nessa fase, as orientações anteriores não mudam (anote tudo, cuide do seu dev). Talvez aqui já exista uma melhor definição sobre quem vai codar. Mantenha um ponto focal pra dúvidas mesmo assim (se você já souber quem vai desenvolver, passa a ser essa pessoa) e continue anotando tudo.
Tudo que pode ser um componente ou um elemento reutilizável, deve ser. Inicialmente pode parecer mais trabalho, mas é um investimento no médio/longo prazo para todo mundo. Economiza tempo na documentação e handoff atual, além de usos futuros e manutenção.
Especificações de Design
Tudo. Tamanho, distância, espaçamentos, cores, tipografia, tokens etc. Existem plugins que ajudam nessa especificação. Eu uso esse, mas tem outros. Se já houver um Design System desenvolvido, facilita porque não precisa fazer dos componentes, apenas das páginas. Quanto mais avançado o produto, menos disso vai ficando para o dia a dia.
Com o advento do Dev Mode no Figma, isso tudo foi facilitado. As Variáveis também ajudam muito, mas está disponível apenas no plano pago. Não vou me alongar nisso, apenas aponto que existem essas possibilidades. Se o seu contexto abraça essa funcionalidade, use também.
Fluxos
Pode ser wireflow, sitegrama, userflow, sitemap, blueprint resumido do serviço, validação condicional, etc. O software pouco importa (Figma, Figjam, Excel, Flowchart, PowerPoint, etc). O importante é ter a documentação do fluxo que foi projetado além das telas e das interações no protótipo.
Muitos detalhes são mapeados nesses fluxos. Tenha mais de um se for preciso.
Descrição das telas e comportamento de cada elemento
É importante ter definição e descrição detalhada sobre interações, microinterações, comportamentos e diferentes status. Saiba como a sua equipe identifica os componentes, alguns tem mais de um nome técnico (ex: input field, textbox, texfield).
Mapeie o máximo de status possíveis no discovery e ao longo do seu desenvolvimento (use seus stakeholders pra isso), inclua imagens de como um determinado componente deve funcionar.
A 1ª das imagens abaixo é como eu prefiro fazer essa documentação: título da tela/fluxo, o rótulo, qual o tipo do componente e seu comportamento, além de informações de status e outros comentários necessários; quando há alteração de algo que já foi desenvolvido, descrevo e incluo o link da tarefa em que a mudança foi feita. Evito usar prints de todas as telas ineiras pois é muito fácil ficar desatualizado, é mais chato alterar, então prefiro apenas utilizar o link do figma.
Essa etapa é muito importante para todos. PM/PO usa pra descrever tarefa, Dev tem certeza do que está desenvol vendo, QA tem mais segurança no teste.
Ok. Temos um produto validado e documentação escrita. E agora?
👐 Handoff: Comunicar para o presente, para o time
Nas minhas experiências, não trabalhei com ferramentas de handoff (Invision, Zeplin, etc), então compartilho outras informações. Meu foco aqui é no que geralmente passa batido: conversa e alinhamento. Não é de hoje que existe rixa entre desenvolvedores e designers, um rosnando de cada lado, e também não é hoje que ela vai sumir. Mas podemos tentar diminuir esse atrito e evitar retrabalho (de todos).
Em alguns contextos, há uma etapa de refinamento com os devs antes da entrega oficial. Gosto muito, nos permite mapear possíveis pontas soltas que podem ter ficado pelo caminho. Isso também ocorre na planning.
De qualquer forma, deve haver uma reunião. De nada adianta desenvolver um protótipo lindão que não vai ser implementado. Lembre-se do que eu falei no lá no início: saiba se comunicar. Agora é a hora de apresentar o case, mostrar a sua expertise e defender o que você fez.
- Se reúna com quem está envolvido nesse delivery
- Compartilhe a sua tela
- Dê um overview sobre a dor, quais foram as descobertas principais e como isso se relaciona com a saída (o produto em si).
- Explique o fluxo
- Converse. Anote. Se alinhem 🌟 🪐
🧐 Design QA: Comunicar qualidade, para o usuário
Certo. Nós criamos, outras pessoas desenvolveram. Mas como ter certeza que está funcionando como deveria? Esse processo é o Quality Assurance (Garantia de Qualidade), em que alguém vai testar todo o produto desenvolvido antes de liberar para o usuário. Design QA também é uma etapa do processo até a entrega e deve ser feita para garantir consistência e qualidade visual do que foi desenvolvido.
Normalmente, há uma pessoa (ou um time) de tecnologia para fazer essa verificação, porém assim como o desenvolvedor, o QA provavelmente não sabe sobre Design como nós (e não é uma obrigação, está tudo bem). O QA tem uma infinidade de cenários pra verificar e nós, Designers, já sabemos o que foi alterado e como a especificação de Design deve funcionar. Facilite. Faça você a validação de Design.
Lembre-se: não dá pra ter tudo sempre. Concessões (de todos os lados) podem ser necessárias em todas as etapas.
🌷 E depois?
No fim das contas, o nosso papel é também assegurar que a empresa enxergue o valor do Design, e essas ferramentas são importantes pra isso. Se temos um produto rodando, mas uma documentação desatualizada, incompleta ou que ninguém lê, morremos na praia de novo (só que com um pouco mais de areia no ouvido).
Mantenha tudo atualizado quando houver alterações e um histórico do que havia ali antes (não apague, apenas separe e diferencie). Também indico uma timeline no repositório da documentação técnica com as descrições:
- 00/00/00: Descrição do que foi alterado. Link da tarefa. Link do novo mockup/arquivo do Figma.
Uma fonte única de verdade é o cenário ideal, mas o nosso público alvo envolve pessoas que não tem acesso à todas as ferramentas, então é melhor que essa informação conste em mais de um lugar, mas não muito mais do que isso (sob risco de haver muitos lugares para manter atualizados). O segredo do processo é encontrar o equilíbro, e isso só se define com tentativa e erro.
Uma documentação bem escrita e um handoff bem feito é crucial para o sucesso do produto. Qualidade afeta o time todo (e o usuário). É importante que todos saibam como as coisas funcionam, e qual foi o processo de tomada de decisão, evitar retrabalho ou também possibilitar reavaliações posteriores.
Por fim:
Não existe “by-the-book”: Agora, saia para o mundo. Esse é um guia com dicas. Use, pivote, modifique, adapte, vire do avesso: nada disso é escrito em pedra.
Referências e Links Extras
Articulando Decisões de Design (livro)
Dicas sobre descrição de tarefas
33 / A característica perdida em designers
Onde está sua documentação de UX, jovem? (vídeo)
Que design você está deixando para o futuro? (vídeo)
Seja um bom ancestral! Dicas práticas para sustentar a visão de design na sua empresa (vídeo)
A Designer’s Guide to Documenting Accessibility & User Interactions by Stéphanie Walter
