Copiar pra que? Se podemos construir um processo de design de forma colaborativa.

Melhorando o engajamento, comunicação, organização e a escalabilidade do time.

Illustrative photo by Windows on Unsplash

Este artigo expõe a experiência de construir um processo de trabalho junto ao time de Product Design da empresa RD Station. Para isso, passo por fatos que ocorreram em meados de 2019, quando o time precisou adaptar-se ao crescimento acelerado da empresa e à necessidade de trazer resultados de negócio, além das melhorias na experiência do produto.

A história é antiga, mas os aprendizados, processo de construção e resultados obtidos são perenes e podem ajudar no amadurecimento de qualquer empresa ou time de designers que precisa crescer de forma consistente.

Nossos principais problemas na época

No início de 2019 tivemos muitas baixas no time e ficamos com pouca estrutura para acompanhar o cenário de grande crescimento da empresa. Estávamos sem liderança em design, espalhados por vários times e atendendo múltiplos projetos.

Com a entrada de uma nova direção de produto, que demonstrou acreditar no potencial do design como diferencial nos resultados, iniciamos um processo de protagonismo e autonomia nas decisões do time. Nos foi dada toda a responsabilidade sobre nossa própria existência.

Uma série de provocações feitas por essa liderança fizeram o time refletir sobre como o trabalho era feito e quais responsabilidades dentro do produto o time realmente estava assumindo.

Não lembro com exatidão quais foram as perguntas, mas compartilho exemplos que contém a ideia das provocações realizadas na época:

Qual é o papel de vocês no time de produto?

Qual é a influência esperada do trabalho de vocês no negócio da empresa?

Qual é o impacto que vocês esperam gerar nos clientes?

São perguntas relativamente fáceis de responder, pois fazem parte do roteiro que qualquer time de designers usaria para expor os possíveis impactos positivos que poderia fazer no negócio, ambiente e clientes. Mas não aguardávamos as perguntas que viriam a seguir:

Esse papel está sendo exercido conforme vocês estão descrevendo?

Vocês estão conseguindo influenciar o negócio da empresa?

Vocês estão conseguindo impactar os clientes da forma como esperam?

Vocês estão agindo juntos de forma concisa e consistente?

Claramente boa parte do time ficou desconfortável com as últimas perguntas, pois evidenciou que não estávamos tendo êxito no que acreditávamos ser o ideal de resultado para nosso time, não estávamos conseguindo trabalhar de forma consistente com nossos propósitos e crenças.

Com essas provocações, tivemos a oportunidade de identificar diversos problemas. Alguns deles nos levaram a definir um processo de trabalho como solução. Abaixo, listo alguns comentários associados a esse tema. Acredito que você pode vir a se identificar com algum deles:

“Sinto falta de sintonia entre times, iniciativas, gerentes de produtos, engenheiros e os próprios designers." Caroline Guilherme;

“Temos problemas de comunicação, colaboração, passagem de bastão e organização dos projetos. É um caos quando pessoas saem da empresa, é difícil encontrar as coisas e saber em que etapa pararam.” rodrigo quaresma;

“Não conseguimos saber onde melhorar e nem como ajudar o outro a melhorar. Não é claro em que etapa cada um está, dificultando as críticas e apoios.” Fabiano Meneghetti

“Quando alguém entra na equipe, não temos um onboarding que ajude no início de sua jornada dela como designer na empresa. Deixamos a pessoa perdida perdido e provavelmente insegura para mostrar sua capacidade de ajudar o time.” Luiz Felipe Jr (Sorriso)

"Usamos ferramentas diferentes como, sketch, adobe xd, bootstrap studio etc. Isso atrapalhava os fronts no handoff pois cada time recebe os artefatos de uma maneira diferente." Raphael Faria

Resumidamente, os problemas que tínhamos não necessariamente estavam ligados à falta de um processo de trabalho, mas à falta de algo que conseguisse criar uma conexão entre os envolvidos na construção do produto. E foi a solução que encontramos para este problema que vou expor ao longo do texto.

Como encontramos uma solução para nossas dores

Reconhecendo que, entre outros problemas, o mais urgente era estabelecer um processo de comunicação com toda a equipe, era necessário deixar claro quais eram as etapas do nosso trabalho e como deixar todos cientes do que estava sendo feito, além dos resultados esperados.

Com isso em mente e orientação do diretor de produto, Jorge Tung, iniciamos um levantamento de como cada designer trabalha e quais etapas eram necessárias para chegar a um resultado.

1º Identificação dos processos pessoais de cada designer.

Em uma reunião com os designers, começamos a compartilhar nossos processos pessoais os escrevendo no quadro, detalhando cada etapa e quais evidências eram geradas na conclusão delas.

Para isso funcionar, foi necessário gerar um ambiente seguro e sem julgamento. Assim, todos puderam expor seus processos pessoais, pois o principal objetivo era construir, juntos, algo melhor. Não importava o quão completo ou simples era o processo individualmente.

Algumas regras que sugiro para esse momento:

• Deixar claro que não é uma avaliação dos processos individuais.
• Não existe certo ou errado. Cada um tem um contexto de atuação e uma forma de trabalhar.
• Não é permitido fazer julgamentos, apenas tirar dúvidas sobre as etapas e contribuir com sugestões caso seja solicitado.
• Estamos todos em busca de melhorar o que fazemos. Aceitar contribuições irá enriquecer e fortalecer todos os pontos.

Um dos processos individuais que foi compartilhado com o time

2º Quais eram os pontos em comum entre os processos.

Após as apresentações, explicações e compartilhamentos, partimos para a identificação dos pontos em comum entre os processos, as compreensões e definições usadas.

Esse exercício foi fundamental para levantarmos o que acreditávamos ser relevante para as propostas de etapas do trabalho de um designer dentro da empresa RD Station.

Momento onde estávamos definindo algumas etapas

Aspectos mais importantes que levamos em consideração:

• Levantar similaridades entre os processos;
• Criar grupos, definições e nomes para as etapas;
• Retirar etapas repetidas e agrupar as similares;
• Debater sobre os principais conceitos; e
• Deixar claro o objetivo de cada etapa.

Foto ilustrativa com parte da equipe que participou do processo de alguma forma: Da esquerda para a direita temos ao fundo Diego Pereira, Wesley Rocha, Fabiano Meneghetti, Glauco C, Caroline Guilherme, Aline Driemeyer e, de costas, o excelentíssimo Tiago Luiz

3º Formulação da proposta das etapas do processo

Com todas as informações expostas, discutidas e acordadas com a equipe, chegou a hora de entender exatamente o que acontece em cada etapa. Montamos uma matriz bem marota para ajudar a levantar todas as ações, métodos, técnicas e interações usadas para concluir uma determinada parte do processo.

Conseguimos levantar uma enorme quantidade de coisas, pessoas e ferramentas que eram necessárias para uma etapa ser executada. Isso nos deu uma visão de onde estavam os excessos, burocracias e possíveis problemas que desperdiçavam nossa energia.

Foto de exemplo da matriz

Essa matriz foi detalhada contendo os seguintes itens:

• Etapa;
• Objetivo da etapa;
• Saída esperada;
• Ferramentas de apoio;
• Possíveis artefatos e documentos;
• Possíveis envolvidos na etapa;
• Material de apoio como manuais, modelos e apresentações.

Ao preencher todos os itens de cada etapa, tínhamos um processo único de design em uma planilha bem robusta, com uma visão bem clara do que poderia ser feito em cada momento.

Posteriormente, associamos os princípios de design e nosso manifesto a cada etapa, com a intenção de enriquecer as informações compartilhadas naquele momento. (Podem ficar tranquilos que ainda vamos falar dos princípios e do manifesto em outro momento).

Foto da planilha com as etapas e o que poderia ser necessário observar em cada uma delas

Resumindo, retirando alguns detalhes que podem ser vistos na planilha “Exemplo de matriz — Design Resultados Digitais”, o processo ficou basicamente da seguinte forma:

Problema: Entender as dores do cliente, problemas de negócio e limitações de engenharia.

• Kick-off: Alinhar informações sobre o problema com o time;
• Priorização: Em que ordem as oportunidade serão atacadas;
• Imersão: Esclarecer pontos de dúvidas com pessoas usuárias e stakeholders caso precise de mais contexto;
• Compartilhamento: Falar sobre as descobertas, dúvidas e certezas com o time e demais envolvidos no processo.

Solução: Criar possíveis soluções para o problema e testar com a pessoa usuária.

• Esboço de solução: Pode ser um rascunho ou delírios em um quadro. De preferência com pessoas usuárias ou alguém próximo a elas;
• Alinhamento: Envolvimento da parte operacional do time para descobrir custo, esforço e demais informações relacionadas às possíveis hipóteses;
• Refinamento: Aprimorar a qualidade da solução escolhida para eliminar ruídos de comunicação não tratados nos rascunhos;
• Testes: Validação da solução com pessoas usuárias, várias e várias vezes se necessário.

Entrega: Realizar os ajustes necessários e definir o que será feito.

• Construção: fechar os assets, protótipos e specs para o time de desenvolvimento;
• Entrega: Definição de pronto para cada interação esperada.

Lançamento / Acompanhamento: Planejar e acompanhar as entregas iterativas até todos os clientes receberem o produto.

• Pré-lançamento: Validar a implementação, realizar testes em produção com clientes reais e fazer ajustes e melhorias;
• Lançamento: Liberação da solução para todas a pessoas usuárias, caso necessário realizar plano de divulgação;
• Pós Lançamento: Monitoramento e acompanhamento de métricas para avaliar o sucesso e encontrar novas oportunidades de melhoria.

Inicialmente, todos ficamos preocupados com a quantidade de detalhes para seguir ou avaliar. Isso gerou certo desconforto, pois tínhamos situações e projetos bem distintos que poderiam precisar de toda essa robustez ou simplesmente quase nada do que estava escrito.

É normal surgirem essas questões, era apenas a primeira versão. Mas, de qualquer forma, o trabalho para chegar nesse processo não deveria ser ignorado. Era necessário botar em prática o que tínhamos acordado antes de qualquer refinamento, pois só assim conseguiríamos levantar um debate rico para posteriores evoluções.

4º Usando, aprendendo e melhorando nosso fluxo de trabalho

Para realmente validar o que definimos como proposta inicial, nada mais natural que o time se comprometa a usar o processo de forma a identificar o que estava ou não funcionando.

Como objeto de estudo, algumas premissas foram definidas na intenção de dar liberdade para o time decidir como usar o processo:

• Não era obrigatório passar por todas as etapas: O mais importante era saber os motivos de pular determinada etapa, deixar os envolvidos cientes disso e incluir as ressalvas dos possíveis impactos de optar não passar por aquele ponto.
• Todos deveriam colocar datas de início e término de cada etapa: Não era para microgerenciar projetos, mas para identificar gargalos, pausas e possíveis dependências de uma etapa para a outra, pois os projetos costumavam ter uma vala entre a etapa de solução e lançamento (depois da solução projetada, demorava muito tempo para ir ao ar).

O controle e compartilhamento de cada projeto foi feito em uma planilha (custo baixo e rápido de ser atualizado por todos os participantes). Na planilha tinha as seguintes informações:

• Nas colunas estavam as etapas do nosso processo;
• Cada linha seria um projeto;
• Um designer poderia colocar mais de um projeto que estivesse trabalhando;
• Em cada etapa de um projeto seria colocado a data de início e fim;
• Em caso da etapa não se aplicar ao projeto, isso seria identificado junto com o motivo da não aplicação.

Óbvio que realizar esse tipo de controle é chato, mas firmamos esse acordo e, durante um bom tempo, acompanhamos 22 projetos. Com isso, tivemos uma visão muito mais clara de quais eram os pontos que nós, designers, precisávamos fortalecer no time, projetos e processo.

Ficou evidente que boa parte da definição das entregas e resultados esperados era um exercício de decisão do time de produto como um todo. Agora, com a clareza de como isso pode ser feito, nós, designers, passamos a participar desses momentos com mais frequência, conseguindo ajudar o time nas decisões e acordos para definição das entregas.

Ficaram evidentes os problemas de comunicação e participação no desenvolvimento do produto. Dessa forma, passamos a atuar em cada etapa com as seguintes abordagens:

• Na etapa do problema, era comum recebermos o briefing e sermos apenas responsabilizados por entregar uma solução. Não éramos envolvidos no contexto desde o início, prejudicando o entendimento do problema por parte dos designers. Com a aplicação do processo conseguimos evidências que o problema tem múltiplas visões e o envolvimento de engenharia e design fazia parte dessa construção. Passamos a colaborar mais, enriquecendo os estudos de Product Managers e melhorando a priorização das tarefas que envolvem a experiência do cliente.
• Na definição da solução, tínhamos muitas idas e vindas até entender os números e questões de negócio trazidas pelos Product Managers, bem como as limitações levantadas pela engenharia. Agora, levando todo o time para a cocriação, definimos juntos as melhores apostas, saindo das reuniões alinhados e confiantes com a escolha da solução.
• Na entrega, quando quebramos o épico em pequenos pedaços com valor para o cliente, alguns detalhes relacionados à experiência estavam sendo deixados de lado e ficavam esquecidos no tempo. O foco, basicamente, era resolver uma demanda específica de negócio ou debito de engenharia. Hoje, ajudamos nas quebras de forma a equilibrar cada entrega, levando em consideração negócio, engenharia e design (experiência da pessoa usuária).
• No lançamento, começamos a acompanhar os impactos em vez de esperar os Products Managers trazerem números sobre os resultados. Nos colocamos como responsáveis por olhar as interações e feedbacks, além de conversarmos com as pessoas usuárias para retroalimentar o ciclo de entrega com as melhorias qualitativas percebidas durante o processo.

Tivemos muitos aprendizados, mas o melhor foi perceber que o nosso fluxo atendeu basicamente todos os cenários. Poderíamos resumir ele em uma espécie de guia, mostrando apenas as principais fases do processo. Assim surgiu nosso framework de design / discovery, que facilitou o entendimento do trabalho com os designers de forma simples e objetiva.

5º Consolidação do Design Workflow do time de Produto da RD

Devido ao entendimento que a palavra processo remete a algo rígido e engessado, resolvemos chamá-lo de Design Workflow, retirando um pouco da carga mais burocrática que tem na palavra processo.

Para ajudar na promoção desse fluxo de trabalho, propusemos as seguintes premissas para sua utilização:

1. As pessoas não são obrigadas a seguir esse fluxo. Ele não é uma verdade absoluta para o processo de design. Ele é mais um guia, uma boa prática para ajudar a definir em que etapa o projeto está e o que se espera dele;
2. Não existe uma ordem ou um ponto de partida para iniciar o fluxo. O mais importante é ter clara a etapa em que se está trabalhando, o que puxou sua execução e o resultado esperado;
3. Apesar de chamar esse fluxo de Design Workflow, notoriamente ele se aplica a qualquer fluxo de trabalho, tanto de Product Managers como de Engenheiros. Então, vale compartilhar e usar envolvendo toda a equipe.

Depois dessas definições, fechamos o desenho do diagrama junto com um documento de guia para qualquer projeto.

RD Design Workflow

Alguns bons resultados depois de 2 anos com um fluxo de trabalho definido

O principal objetivo desse projeto era encontrar formas de escalar nossa atuação no time de Engenharia e Produto, com uma boa comunicação e interação com os envolvidos.

1. Deixar nosso papel mais claro;
2. Ajudar a influenciar nas decisões do time;
3. Gerar impacto positivo na relação dos clientes com a plataforma RD Station.

Hoje, possuímos uma rotina mais consistente que possibilita a ampliação do time, não só em número de colaboradores especializados em UX, mas na criação de uma estrutura mais robusta, que vem atendendo outras necessidades dentro da empresa.

Em nosso time, temos as seguintes posições:

• Head of Designers / Design Manager;
• Designers Lead
• Product designers / UX Specialist;
• UI Specialist Designer;
• Design Research;
• UX Writer Designer.

"Por falar nisso, nosso time está crescendo na mesma medida que os nossos desafios. Confira nossas vagas abertas aqui"

É claro que todo esse resultado não veio única e exclusivamente da criação de um framework ou processo de trabalho, mas foi uma das primeiras iniciativas adotadas pelo time, sendo complementada pelos princípios e valores que nos regem.

Outros desdobramentos dessa estratégia que ajudaram a alavancar o time.

1. Reduzimos o número de ferramentas que o time utilizava, diminuindo o custo da empresa e dando mais foco ao que realmente precisávamos. Adotamos uma ferramenta para cocriação chamada Miro e outra para prototipação chamada Figma. Ambas tinham que ser multiplataforma, colaborativa e possibilitar controle de versão e componentização.
2. Definimos algumas cerimônias para garantir nosso alinhamento com a diretoria, times e os próprios designers:
   - Quick Sync Design: Quinzenalmente;
   - Design Lab: Semanalmente;
   - Boto fé: Canal de conversas e encontros só entre os designers sem a gestão. Nesse canal rolam os melhores memes da empresa :-P.
3. Passamos a ajudar no processo de onboarding de novos colaboradores apresentando o framework de trabalho e criando um novo papel: o "sombra" (mentor que ajuda os novatos).
4. Adotamos como boa prática colocar etapas do Design Workflow no Kanban dos times, além de alguns checklists para lembrar de alguma etapa durante a execução dos épicos.

Principais aprendizados

São inúmeros os aprendizados, mas vou resumir em alguns poucos mais relevantes para este artigo:

• Ter um processo claro realmente ajuda na comunicação e influência dos designers nas tarefas e rumo do projeto. Ele mantém as ideias organizadas, encadeadas e de fácil recuperação para qualquer debate ou apreciação.
• Não é necessário ter um lugar onde as pessoas compartilhem o processo. Depois de algum tempo, os times interiorizam o funcionamento e passam a aplicar ele quase que naturalmente em seu Kanban, usando recursos mais simples para compartilhar os resultados de cada etapa.
• O processo é apenas um guia, cada time fez sua adaptação, retirando ou colocando etapas. Mas, no final, os grandes outputs mantiveram-se estáveis.
  - Problem definition;
  - Solution hypothesis;
  - Solution delivery;
  - Monitoring & Learning.
• Realmente ajuda a acelerar o onboarding de novos colaboradores tanto em projetos em andamento como nos novos.

O que esperamos para o futuro?

Esse projeto está em constante evolução e precisa ter mais rodadas de avaliação e cocriação. Cada etapa já possui inúmeras variações que precisam ser evidenciadas e agregadas ao framework não como novas etapas, mas como exemplos que podem ser consultados e utilizados.

Conceitualmente eu acredito que precisamos evoluir mais a parte anterior ao problema ou, pelo menos, tornar isso visível no framework. Afinal, um problema só tem valor mediante um objetivo associado a ele. Não adianta amar problemas que não estão ligados ao objetivo que queremos atingir.

Existe a possibilidade de tornar ele mais aplicável entre as disciplinas de engenharia e negócio, mas para isso é necessário um mergulho nos desafios dessas áreas para levantar quais outputs podem ser associados ao framework e se eles fazem sentido nesse fluxo. Ou seja, uma validação para não forçar a barra.

Concluindo essa gigantesca história, agradeço quem conseguiu chegar até aqui nessa odisseia. Convido você a dar sua opinião, comentar, compartilhar e trocar experiências sobre seu processo. Vamos cocriar?

No mais, o que foi apresentado é criação da equipe de designers da RD para o contexto da RD. Não necessariamente vai funcionar para você.

No entanto, a forma como concebemos pode ajudar seu time a passar por uma experiência de autoconhecimento, empoderamento e amadurecimento significativo. Mesmo que no final não tenha o resultado esperado, o importante é o processo. O resto é consequência do caminho escolhido.

Obrigado pela leitura.

Agradecimento a todos os envolvidos e, em especial, a essas pessoas maravilhosas que compartilharam seu tempo e conhecimento para tornar isso possível.

Raphael Faria, Caroline Guilherme, Tiago Muraro, Luiz Felipe Jr (Sorriso), Bruno Silva, Josias Oliveira, rodrigo quaresma e Jorge Tung.