Melhor documentação e comunicação da equipe com documentos de design de produto

O processo típico para trabalhar como designer de produto em uma empresa ou startup pode ser familiar para você: um novo produto está sendo desenvolvido para fornecer uma solução de design. Em seguida, você trabalha em algumas propostas de design e as lança na frente de 1 a 3 pessoas para obter feedback.

Às vezes, esse processo funciona bem, mas outras vezes não. Por exemplo, algumas pessoas estão ocupadas prestando atenção para terminar suas próprias tarefas e não gastam tempo suficiente para fornecer feedback claro e conciso para sua proposta de design.

Também pode acontecer que, mesmo que seu processo seja bom, você ainda queira formalizar o processo anotando as decisões, acompanhando as iterações e o processo de design em geral, especialmente nos tempos atuais em que nos encontramos trabalhando remotamente devido ao COVID19.

Documentar o processo tem muitos benefícios. Por exemplo, torna seu trabalho mais visível, cria oportunidades para obter feedback de muito mais pessoas, melhora a comunicação geral e fornece uma imagem clara de como um recurso foi projetado com todo o contexto e considerações ao redor.

A Queda do Herói Designer

Por volta de 2018, estava trabalhando como Product Designer remoto de Madrid em uma empresa que atua na América Latina, envolvendo nesse processo outras equipes do México e São Paulo, Brasil.

Antes de começar a trabalhar nesta empresa, tive muitas experiências diferentes em minha carreira trabalhando em ambientes de pequeno e grande porte de diversos setores, como mídia de notícias, estúdios de design, uma rede social, um sistema operacional móvel, fundei uma startup de e-grocery , e até fez alguns shows freelance com outras pequenas startups.

Durante esses anos, eu vinha seguindo a mesma abordagem, você coloca algumas pessoas sentadas na mesma sala, lança sua solução, fornece algumas telas, fluxos, obtém algum feedback e a apresenta novamente. Após algumas iterações, seu trabalho estará pronto para chegar à fase de desenvolvimento.

No entanto, essa mesma abordagem parou de funcionar. Pouco depois de ingressar na equipe, percebi que apenas lançar meus designs em uma videochamada não era suficiente. Eu estava criando muitas propostas, mas não consegui a aprovação final dos meus stakeholders e colegas de equipe. Eu estava confuso e ficava me perguntando: O que estava acontecendo? Eu não estava projetando a melhor solução possível? Eu não estava entregando um trabalho de boa qualidade? Cada uma dessas perguntas estava me fazendo perder a confiança em mim mesma. O problema era que eu precisava adaptar meu processo a esse ambiente.

Assim que percebi que meu processo não estava dando certo, comecei a ler muitos artigos sobre como trabalhar como designer remotamente, o efeito gaivota (quando alguém entra no seu trabalho, critica duramente e depois voa para longe), como outras empresas estavam abordando a colaboração remota e como formalizaram seu processo escrevendo-o. Depois de ler todo esse material, me perguntei como os desenvolvedores estavam enfrentando esse mesmo problema? Como eles colaboram em ambientes remotos de maneira quase assíncrona? Como eles chegam a acordos finais? Descobri que, de fato, a comunidade de desenvolvedores já tem um processo que funciona muito bem para eles: chama-se pull requests.

As solicitações pull permitem que você introduza alterações em uma base de código maior, documentando-as e validando suas decisões com o feedback de outras pessoas. Dessa forma, as mudanças que você introduz combinam perfeitamente com todos os padrões e conexões que o código já possui. Isso é exatamente o que eu precisava alcançar, mas é claro que em uma abordagem de design de moda. Deixe-me apresentá-lo ao Documento de Design de Produto.

O Documento de Design de Produto

Um Product Design Doc (PDD) é um documento que converte os problemas que você deseja resolver, o contexto e a solução final em uma iteração ou abordagem baseada em estágios.

Isso significa que você pode documentar todo o seu processo de design em um único documento que pode ser compartilhado com qualquer pessoa em sua empresa e ele funcionará como uma base de conhecimento para as decisões de produto que você tomar. Parece legal, hein? Vamos nos aprofundar nos detalhes.

Conceitos Gerais

Um PDD pode ser descrito em 4 conceitos principais: Metadados, Contexto, Estágios e Feedback .

• Metadados são apenas informações úteis sobre o documento, como título, data, status e assim por diante.

  

• Contexto é o que outras pessoas precisam ler, para entender as propostas de design que você faz, pense sobre isso como a descrição, problema, resumo ou objetivos do que você precisa alcançar.

• Os estágios são as diferentes iterações do seu design, geralmente começando com foco na solução mais ampla e em cada estágio focando em detalhes mais específicos. Cada etapa é baseada na anterior e aborda o feedback recebido. Esta é uma maneira estruturada de chegar a um ponto final em que os problemas resolvidos não podem aparecer novamente.

• Feedback refere-se a todas as opiniões, comentários, solicitações e recomendações que você coleta de outras pessoas. Você pode coletar feedback de suas partes interessadas ou membros da equipe.

Com esses quatro conceitos, você pode criar diferentes variações de PDD para atender às suas necessidades, cada empresa/projeto é diferente e o que funcionou para mim, não precisa funcionar da mesma forma para você. Mas se você cobrir esses 4 conceitos principais em seu PDD, provavelmente funcionará em quase todas as situações.

Estrutura de exemplo

Depois de entender os principais conceitos, vou compartilhar com vocês a estrutura que venho utilizando durante meu tempo nessa empresa. Possui as seguintes seções:

• O título deve ser conciso, claro e facilmente distinguido de outros títulos de PDD que você já possui.
• O Status indica em qual estágio seu documento está agora:
• Esboço, projeto
  Ainda trabalhando na definição do Contexto. Não está pronto para feedback.
• S30, S60, S90
  Os diferentes estágios (30%, 60%, 90%) da sua solução (mais detalhes sobre os estágios posteriormente).
• Completo
  Todos os comentários foram abordados e não há pontos ausentes. O PDD está concluído.
• O Resumo é a descrição do problema para o qual você precisa projetar, geralmente vinculando-se a outras leituras relacionadas úteis que você possa ter.
• As metas são os pontos-chave em que sua solução precisa se concentrar, esta é uma lista de verificação que você revisará constantemente para ter certeza de que está no caminho certo.
• S30 (ou Stage 30% ) é a primeira proposta que você faz com base no resumo e nos objetivos, focando na solução mais ampla ao invés dos detalhes, talvez fornecendo um wireframe de baixa fidelidade ou técnica similar. Este é o estágio em que a solução proposta pode ter uma abordagem totalmente diferente e espera-se que ocorra um grande feedback.
• S60 (ou Stage 60% ) é a sua solução com 60% de completude e aplica o feedback do S30. Tem menos detalhes que S90, mas indica claramente a intenção de sua solução. Você fornece um wireframe de alta fidelidade com mais casos envolvidos e algumas definições de fluxo. Você pode receber algum tipo de feedback principalmente com foco em casos perdidos e pequenos cenários inesperados.
• S90 (ou Estágio 90% ) é o estágio que tem a solução com 90% de completude e aplica o feedback do S60. Esta etapa é focada nos detalhes mais finos do seu projeto, incluindo todos os diferentes cenários, casos de canto, design visual e até protótipos. Espera-se que tenha algum tipo de feedback menor.

Você pode estar se perguntando, eu preciso seguir a mesma convenção de nomenclatura de ordem e estágios? Bem, não, você não. Você pode renomear o estágio de S30, S60 e S90 para apenas: Exploração, Proposta, Solução.

Você também pode alterar a ordem para que o trabalho mais refinado (S90, Solução) fique no topo do documento e o fluxo de leitura vá do estágio final para o inicial (S30, Exploração).

Modelos

Comece rapidamente com um dos modelos fornecidos para as plataformas de escrita mais comuns. Lembre-se: As convenções de nomenclatura das seções são totalmente personalizáveis. Se você não gosta de Abstract , basta usar Brief , About ou qualquer coisa que se adapte às suas necessidades. O conceito principal que você precisará manter é sobre a criação de diferentes iterações para focar em cada estágio, você pode apenas renomear S30 por Exploração, S60 por Proposta e S90 por Solução.

• Papel
• Noção
• documentos Google
• Exemplo da vida real

Principais benefícios do uso do PDD

1. Cada decisão é documentada.
   Ou seja, mesmo quando você sair da sua empresa/projeto (e isso acontecerá mais cedo ou mais tarde), todo o conhecimento gerado ficará na empresa para sempre, para que outras pessoas possam olhar para ele e iterar de onde você saiu.

2. Melhora a comunicação.
   Colocar pessoas diferentes de sua equipe no PDD para fornecer feedback ajuda todos a permanecerem na mesma página e cientes das decisões tomadas.

3. Limita as mudanças infinitas das partes interessadas.
   Cada estágio se concentra em um ângulo diferente do problema, indo de soluções mais amplas a soluções mais restritas. Isso permite que as pessoas se concentrem em um único problema de cada vez, ajudando-as nos estágios finais.

4. O produto é construído de forma colaborativa.
   Em vez de as partes interessadas definirem soluções específicas, deixamos as equipes de engenharia, design e outras se envolverem com a solução, tornando-as parte dela.

Notas Finais

Fechando a história sobre essa empresa remota, consegui trabalhar lá por mais alguns meses e consegui implementar os Product Design Docs em pelo menos 5 projetos diferentes. Minha frustração foi muito reduzida e consegui chegar a um consenso sobre minhas propostas de design para que o produto continuasse a evoluir. Desde então, a empresa cresceu muito e alguns dos trabalhos que fiz durante o meu tempo ainda estão sendo usados.

PS: Comecei a escrever este artigo em 2019, então em 2021 vi que o Abstract estava criando um produto para documentar o processo de design, então decidi voltar aos trilhos e finalizá-lo. Parece que ainda é um tema bastante relevante.

Bibliografia

• Como executar exercícios de design em uma equipe remota por Hannah Hearth
• Evite o efeito gaivota: a estrutura 30/60/90 para feedback por Lauren Moon
• Como você projeta um documento de design? por John Saito
• O poder do documento de design de Brendan Fagan
• Apresentando Notebooks por Matt Colyer