Design handoff: a importância da boa organização nas entregas
Entenda como é o meu processo de handoff em um dos times de operações da Stone Co.
Handoff é um termo utilizado para se referir ao momento em que uma equipe repassa o trabalho para outra equipe ou pessoa responsável para dar continuidade ao projeto. No contexto do design, o handoff ocorre quando a equipe de design finaliza o trabalho em uma determinada fase do projeto e repassa as especificações, arquivos e informações para a equipe de desenvolvimento implementar o design. O objetivo do handoff é garantir que o trabalho seja entregue com clareza e eficiência, evitando atrasos, problemas de comunicação e retrabalho.
Antes de falar sobre o meu processo de handoff, é importante destacar duas coisas:
- Não existe uma receita de bolo. O handoff varia conforme o contexto que você estará inserido: qual é o produto, a maturidade do time de desenvolvimento, como trabalha em conjunto com outros designers e assim por diante.
- É fundamental trazer o desenvolvedor para o seu processo de handoff. A comunicação eficaz entre todos os stakeholders é importantíssima para que haja um alinhamento de expectativas e de entendimento das atividades a serem priorizadas. O designer e o desenvolvedor devem conversar sobre as tarefas com frequência: o que precisa ter nos arquivos de design para levar mais clareza ao desenvolvedor? Qual seria a melhor forma de organizar os arquivos? Essas e outras perguntas devem ser feitas para o time ter uma melhor sincronia e maior qualidade nas suas entregas.
O meu contexto
Hoje trabalho no time de Operações da Stone em um produto com versões mobile e web e conto com desenvolvedores de níveis pleno a especialista no time, além de dois product managers e uma liderança com forte repertório de tecnologia e produto.
Além disso, conto com um grande time de design na Stone, constituído por product designers, content designers, service designers, interaction designers, UX researchers e design leads distribuídos por capítulos na companhia. Essa estrutura permite que haja muita troca entre designers de toda a Stone Co., mas elas são mais frequentes entre designers do mesmo capítulo.
Beleza! Dito o meu contexto, agora vamos de fato ao processo de handoff que venho utilizando, o qual se inicia desde a organização dos arquivos e das user stories e vai até o acompanhamento de métricas e afins. Friso aqui que todas as informações foram ocultadas ou alteradas por se tratarem de dados sigilosos da empresa.
1. Organização do Figma (mas pode ser outro software também)
Como utilizo o Figma no meu dia a dia, pode ser que haja algumas etapas que não encaixe diretamente com outros softwares. Mas no geral, a lógica de organização vale para todos.
I. Padronize a nomeação dos seus arquivos
Parece bobo, mas o processo de organização dos arquivos é muito importante para que não só você, mas sobretudo outras pessoas consigam acessá-los com mais facilidade e buscar assertivamente aquilo que estão procurando, sem ter a necessidade de entrar em contato com o(a) dono(a) do arquivo.
Pesquisando rápido você achará diversas formas de como organizar seus arquivos. Como o foco do artigo não é nomeação de um arquivo, não vou me estender na justificativa, mas eu geralmente organizo meus arquivos tão simples quanto:
[Projeto] Fluxo ou feature ou épico (Ex: [Stone App] Tela inicial)
II. Paginação no Figma
Um dos motivos de eu não colocar nomes extensos ou super elaborados para o meu arquivo é por conta da paginação do Figma, o que ajuda em não precisar criar vários versões de uma entrega ou poluir a minha área de trabalho.
Na paginação, primeiro crio páginas como “separadores” para organizar as minhas entregas, sobretudo quanto ao status das tarefas.
Observações sobre a minha organização nas páginas:
- Nomeio cada uma dessas tarefas conforme os nomes das tarefas do Jira (falo em breve sobre ele) do meu time, o que facilita o desenvolvedor na identificação da tarefa;
- Coloco a sprint referente à tarefa. Exemplo: “S1 - Tarefa”;
- Coloco um ícone para facilitar a visualização do status de cada entrega — essa visualização é mais importante para o P.O./P.M. do que para o desenvolvedor;
- Quando existe, coloco logo abaixo de “Trabalhos arquivados” os Local Components, Rascunhos e outras páginas que convêm para o arquivo.
III. É importante ter uma capa para o arquivo e é legal ter um overview
A capa complementa o nome do arquivo no Figma, além de ser um elemento visual que você pode achar o arquivo que está procurando só em “bater o olho”. Já o overview é uma forma de listar as pessoas envolvidas no projeto, o que pode ser útil para outras pessoas que estejam acessando seu arquivo.
Importante colocar o frame da capa como a thumbnail do arquivo: clica com o botão direito do mouse no frame e clica em “Set as thumbnail”.
IV. Um design toolkit te ajuda MUITO
As minhas entregas utilizando um product design toolkit são completamente melhores do que sem utilizá-lo. Sério.
Existem toolkits mais robustos que outros, mas para mim o básico precisa ter pelo menos:
- Page subtitles para organização dos fluxos na página;
- Post-its para descrever algo pontual;
- Um componente para colocar o Épico/Feature/User Story referente à entrega do Figma;
- Checklist para as fases de descoberta, criação, handoff e produção.
Nota: existem arquivos desses toolkits prontos na comunidade, mas caso não ache um legal, vale a pena dedicar um tempinho para criar o seu design toolkit. Dá para fazer bem rápido.
Boa! Figma organizado! Mas a gente tem que ficar ligado também na organização do local onde suas tarefas estão documentadas. Geralmente a organização das tarefas do time é de responsabilidade do P.O./P.M. ou da liderança do time. No entanto, também é fundamental que a organização das tarefas atenda às suas necessidades (e de todo o time).
Aqui na Stone usamos o Jira, no entanto, tratarei de forma mais geral essa questão da gestão das tarefas.
2. Boa gestão das tarefas alinhada à organização no Figma
A gestão do time variará conforme a estrutura da empresa e a maturidade dos times de produto, design e tecnologia. No entanto, destaco aqui a importância de ter um local onde as tarefas precisam estar registradas, de preferência um que seja de fácil acesso e que as tarefas estejam com uma boa descrição para que todos do time as compreendam perfeitamente.
Aqui, nós temos um Kanban para todo o squad, o que inclui um designer (eu), um P.M. e alguns desenvolvedores. Nele, temos as seguintes colunas, em suas respectivas ordens: Não iniciado > Discovery > Fazendo > Blocked > Code Review > Alpha > Beta > Waiting Dispach > Smoking test > Concluído.
Como a maioria do time é de desenvolvedores, nosso Kanban é mais voltado à gestão das tarefas de desenvolvimento. Por esse motivo, existem algumas colunas que não fazem tanto sentido para o contexto de design, mas para desenvolvimento faz. Em linhas gerais, eu costumo trabalhar apenas com as colunas:
Não iniciado > Blocked > Discovery > Fazendo (craft) > Design QA > Concluído
Esse é o básico que para mim funciona muito bem. No entanto, pode ser que eu acrescente uma coluna ou outra dependendo do projeto e do time que eu esteja lidando.
Como mencionado no item 1, o Jira tem uma funcionalidade bem bacana que é de dar um código único para cada tarefa criada. Isso é bem comum entre todos esses softwares de gestão e, caso não tenha, é só o time definir um código para as tarefas.
A partir desse código, nós conseguimos filtrar a tarefa rapidamente no Jira e buscar pela tarefa. A fim de facilitar o trabalho dos stakeholders para visualizar as entregas da tarefa no Figma, eu utilizo um componente do meu product design toolkit para fazer essa relação, fazendo toda a entrega logo abaixo dele:
Perceba que até agora nós só falamos de organização, que alinhada com uma comunicação assertiva, formam a base para um ótimo handoff aos seus desenvolvedores. Nesse sentido, o papel do P.O./P.M. é muito importante para que haja sobretudo uma boa gestão das tarefas de forma holística.
Agora que temos tudo organizado, chegou a hora de fazer as tarefas de design!
3. Minhas entregas: referências, rascunhos, materiais de apoio e interfaces na mesma página
Esta etapa depende da forma como você organiza seus arquivos e suas entregas dentro do Figma (ou do software que você usa).
Aqui no squad, eu prefiro ou trabalhar com um arquivo único no Figma ou com poucos arquivos. Dessa forma, cada página do meu arquivo fica direcionada a uma entrega (voltar no item 1.ii), o que me permite maior espaço na área de trabalho para incluir não só as interfaces prototipadas, mas também as referências, especificações e qualquer tipo de estudo acerca daquela entrega.
Prefiro organizar minhas entregas concentrando tudo de uma tarefa numa única página, pois assim tenho uma visibilidade melhor do detalhamento de cada assunto. Caso seja uma entrega maior, talvez faça sentido criar um arquivo específico apenas para essa entrega e, dentro dele, dividir cada item abaixo em páginas, mas essa seria uma exceção.
De maneira geral, de baixo para cima e da esquerda para a direita (como nós ocidentais estamos acostumados a ler), eu me organizo da seguinte forma:
- Telas e fluxos atuais que alteraremos
- Estudos e resultados de pesquisas
- Objetivos e especificações da tarefa
- Benchmarks
- Componentes e/ou tokens a serem utilizados, podendo ser locais ou de alguma biblioteca
- Interfaces prototipadas e seu fluxo evidente (utilizar setas/plugins para evidenciar esses fluxos)
- Protótipos navegáveis
- Explicações detalhadas de cada componente para facilitar o desenvolvimento: anatomia, animações, responsividade, etc
- Rascunhos e descartes (não excluo tudo, pois talvez haja algum aproveitamento de itens dos rascunhos)
Nota: não necessariamente haverá todos esses itens nas entregas e, dependendo da situação, pode haver maiores subdivisões, como: etapas de implementação de cada feature (geralmente para entregas grandes), guias de UX Writing, etc. Além disso, o product design toolkit é fundamental para uma boa organização dessas seções no Figma.
Segue um exemplo dessa organização:
i. Itens 1 ao 4: estudos da tarefa.
Note que também incluo o código do Jira (GMPW-11) e um checklist da etapa de ‘criação’ que devo concluir antes de entregar aos desenvolvedores. Falei sobre eles na seção 2.
ii. Itens 5 ao 8: entregas da tarefa.
iii. Item 9: rascunhos.
Boa! Agora que temos nossas interfaces construídas, é hora de fazer uma validação com os stakeholders envolvidos para, enfim, repassar aos desenvolvedores.
4. Design QA: a etapa de validação daquilo que foi construído (antes de desenvolver e após desenvolver)
É importante haver diversos alinhamentos envolvendo diferentes stakeholders ao longo de todo o processo de construção: critiques e reviews com seus pares de design, alinhamento com P.O./P.M. das features a serem incluídas e assim por diante. No entanto, é importante existir uma revisão final das telas a serem entregues com os principais stakeholders envolvidos, seja o P.O. ou P.M., o tech lead, o design lead e/ou seu líder do squad. Essa seria uma revisão final dos seus protótipos antes de repassar aos desenvolvedores.
O trabalho do designer não termina na entrega dos protótipos no Figma, pois aquilo que foi prototipado pode não conversar com o que foi realmente desenvolvido. Dessa forma, após o desenvolvimento, é importante que o designer seja participativo também na garantia da qualidade (ou Quality Assurance, ou apenas QA) das interfaces entregues pelo desenvolvedor em um ambiente de teste ou homologação. Essa é uma parte chata, sobretudo se for um fluxo longo, mas que não deve ser negligenciada.
Considero a etapa de Design QA como uma parte crucial do projeto, visto que a entrega mal feita, seja do designer ou do desenvolvedor, pode gerar no atraso da entrega. Dessa forma, um Design QA bem feito prevê as correções que devem ser feitas, permitindo que o time seja capaz de “recalcular a rota” do projeto ou da tarefa.
Além disso, os feedbacks que o Design QA provêm ao designer são importantes também para seu desenvolvimento e qualidade de vida, conforme mencionado no livro Flow: A psicologia do alto desempenho e da felicidade, escrito por Mihaly Csikszentmihalyi.
Figma OK, interfaces no ambiente de homologação OK, e agora?
5. O pós handoff
Peter Drucker, uma das pessoas mais respeitados no mundo da administração de empresas, diz que: “O que pode ser medido, pode ser melhorado”. Portanto, seguindo essa lógica, o trabalho do designer segue também no acompanhamento dos resultados da sua entrega: os usuários estão utilizando essa tela? Existem pontos de fricção? É possível melhorar ainda mais ela?
Todas essas perguntas serão respondidas por um processo contínuo de discovery, o que envolve pesquisas com usuários, testes A/B, Analytics (Google, Hotjar, Amplitude, etc) e diversos outros métodos.
Além disso, é de costume aqui no time de fazermos uma sprint review, analisando os pontos positivos e negativos da sprint, avaliando o que devemos continuar fazendo, parar de fazer e o que poderíamos começar a fazer para termos sprints melhores.
Outra prática bem legal que gosto, é de conversar com designers de outros times para entender seus processos de handoff, principalmente com os mais experientes. Sempre tem coisa nova que acabo observando nas entregas da galera, desde coisas mais discretas quanto organizações em níveis maiores.
Para finalizar este texto, volto a falar que tudo o que foi dito aqui é o que sigo para a minha realidade tanto quanto produto, quanto o time que eu trabalho. Cada um de nós terá um processo que atenda a nossa realidade. No entanto, um bom handoff é aquele que seja claro para todos os envolvidos no processo, provendo assim uma melhor experiência possível para o nosso usuário final.
