Escalando o design em um cenário de consultoria para produtos digitais (em atualização)
O design tem exercido cada vez mais um papel importante dentro das organizações, mas isso não significa que a jornada de construir a "área ideal" seja fácil. É claro que ter um time bom em pesquisa e visual é importante, mas o desafio vai muito além disso.
Uma área só faz sentido existir dentro de uma empresa se for capaz de atingir objetivos de negócio, ou seja, trazer dinheiro. Quando olhamos para design precisa ser uma área capaz de direcionar, influenciar e engajar.
Neste artigo eu vou compartilhar com você os cinco aspectos que julguei importante para construir o “time ideal” quando atuei como Head de Design em uma empresa de consultoria para produtos digitais onde o meu time assumia os desafios de design de clientes como Linx, Claro, B2W, Banco BS2 e Mercedes Benz.
1- Contexto
Em 2017 assumi um dos maiores desafios da minha carreira, construir uma área de design dentro de uma consultoria de desenvolvimento do zero. Na época poucas pessoas sabiam o que esta área poderia fazer, mas sabiam do potencial e apostaram no meu conhecimento para isso.
Como uma boa designer, é óbvio que a minha estratégia foi utilizar das técnicas de design para definir o melhor formato. Assim, iniciei um processo de imersão nos processos que já existentes na empresa e através dele fui identificando das dores e necessidades da época para os projetos de consultoria, onde os times assumiam os produtos de algumas empresas.
Nesta imersão percebi que:
- Já era existente na empresa como um todo a cultura de colaboração, onde as pessoas costumavam pensar em soluções de modo conjunto e trabalhavam em pares. Esses pares eram dinâmicos, ou seja, trocados de tempos em tempos conforme a tarefa a ser desenvolvidas e misturavam profissionais com níveis diferentes de conhecimento;
- As squads utilizavam uma “mistura” de metodologias ágeis, sendo o kanban a mais forte delas;
- Existiam cerimônias já conhecidas como daily meeting, retrospetivas e workshops;
- Os próprios desenvolvedores tentavam fazer o papel do designer, chegavam a desenhar wireframes, layouts e até mesmo ícones (daquele jeito…);
- Era comum os clientes reclamarem da usabilidade dos sistemas. Alguns até davam dicas de como melhorar e outros cobravam por essa evolução;
- Os sistemas eram complexos e cheio de regras de negócios, em sua maioria voltamos ao ramo financeiro e gestão de atividades;
- A área comercial percebeu que havia uma oportunidade de negócio, na qual o Design poderia ser um diferencial, mas ainda muito voltado a estética dos sistemas;
- A gestão e diretoria estava apostando na criação desta área pois acreditavam que seria enriquecedor para o processo, mas não tinham ideia de como fazer isso dar certo.
Com base nessas primeiras descobertas tracei algumas pequenas ações que envolviam workshop sobre “o que é UX”, projetos com maior espaço para o “teste” de atuação, inclusão dos Designers nas cerimônias das squads atuantes e a utilização pura do double diamond para evangelizar e entender tanto a aderência ao processo quanto os problemas no dia a dia.
Diante de um time muito técnico, provar que o design estava ali para facilitar e não para ser mais um complicador ou mais uma burocracia, a disseminação de pilares de experiência foi muito importante. Assim não trabalhavamos com aquela sensação de que as soluções precisam ser apenas bonitas, mas factíveis e viáveis.
O sonho de todo time de design é que esses três pilares tivessem pesos equilibrados em todas as squads, mas percebemos que essa não era e não seria uma realidade em todos projetos. Na verdade, dificilmente esse equilíbrio será sempre presente em qualquer projeto. Então, entender que peso dariamos a cada pilar ajudava a equalizar expectativas e sim, em alguns momentos o peso maior estaja nas dores e necessidades do usuários, mas em outros a tecnologia é quem ditava as regras do jogo e outros momentos o negócio dava o ritmo. E, sinceramente, tudo bem. Faz parte do nosso papel “equilibrar os pratos” e proporcionar para nossos usuários a melhor experiência possível dada as limitações do produto.
Abaixo você confere um comparativo dos pilares em duas squads que estavam sendo trabalhadas simultaneamente em clientes diferentes.
Com essa visibilidade da cultura empresarial, características dos desafios que iríamos encontrar e que poderíamos conquistar, foi possível dar maturidade para a área olhando para perfis, processo e padrões.
Isso tudo pode parecer óbvio ou até mesmo “bobo”, mas a jornada foi grande e só fez sentido depois de passar por sucessos e perrengues. Essa área começou com uma EUquipe, com projetos em que eu mesma era a líder, a product designer, a writer, etc. e depois depois cresceu. Ou seja, não tem fórmula mágica, não tem livro que descreva a melhor jornada a ser seguida, existe o que faz sentido para cada realidade e você vai precisar por a mão na massa.
2- Pessoas
Com o contexto em mãos definir os perfis profissionais serão necessários para atender os desafios fica muito mais fácil. É importante lembrar que em uma consultoria além de qualidade técnica as pessoas precisam ter uma boa desenvoltura comunicativa tanto para alinhar prioridades e escopo das demandas, quanto para cobrar visibilidade e contextualização, cavar problemas, encontrar pessoas que são de outra empresa, ou seja, um perfil bastante adaptativo pois cada empresa tem sua cultura e modo de operar. Não vale a pena contratar pessoas com foco em apenas um projeto ou cliente, é necessário expandir a visão para que se tenha pessoas "curingas" que possam sair e entrar dos desafios sem perder qualidade e mantendo a sustentabilidade do time em casos de finalizações contratuais.
Agora, focando em habilidades técnicas para executar o trabalho do dia a dia, minimamente deve-se ter profissionais focados nos papéis de:
- Product designer
Responsável por entender a necessidade de negócio e do usuário, assim como garantir a viabilidade técnica para então definir fluxos, microinterações, estrutura de telas, etc. Em um cenários de consultoria, por ser um perfil mais generalista, eles serão as pessoas alocadas nos clientes, estarão ali fazendo a frente das demandas e poderão ter o suporte de outros perfis em momentos mais estratégicos. - UI designer
Responsável pelo estilo visual por meio da definição de ilustrações, tipografia, componentes, etc. Esse é um perfil que não será necessário alocar por cliente, mas pode utilizado para qualificar as entregas dos product designers auxiliando com visuais mais elaborados e criando padrões de interface a serem seguidos. Ou seja, podem atuar de maneira estratégica em momentos-chave do projeto. - UX researcher
Responsável por alimentar o time com informações sobre os usuários buscando padrões de comportamento através de pesquisas, workshops, testes de usabilidade, etc. Esse também é um perfil que não será necessário alocar por cliente, mas pode utilizado para atuar com demandas mais complexas ou até mesmo paralela as entregas do dia a dia com o objetivo de encontrar oportunidades e até mesmo testas soluções. Ou seja, novamente podem atuar de maneira estratégica em momentos-chave do projeto. - UX writer
Responsável por definir a estratégia de conteúdo através da escolha da linguagem mais adequada para o perfil de usuário em questão. Mais um perfil que não será necessário alocar por cliente, mas pode ser utilizado qualificar as entregas dos product designers auxiliando com revisões textuais e criando padrões a serem seguidos. Ou seja, novamente podem atuar de maneira estratégica em momentos-chave do projeto.
Tangibilizando a ideia um pouco mais para você entender…
Na época que trabalhei como Head de design da consultoria a minha estrutura-alvo era termos squads por projeto ou cliente com product designers e um estrutura de DesignOps ou, como chamam mais atualmente, de Design Cross. As squads também possuiam líderes de design que poderiam atuar com N clientes ou projetos, essa alocação era definida conforme a complexidade do desafio, assim todos os profissionais possuiam apoio técnico e de carreira constantemente. Ou seja, isso nunca seria de responsabilidade do cliente, a ele cabia apenas trazer os desafios.
Com isso, a estrutura-alvo ficou da seguinte forma:
Ainda é importante entender que níveis de conhecimento o time deve abrir espaço. Afinal, um time só com profissionais sêniores se torna muito caro e, sinceramente, desnecessário pois causa um desequilíbrio nas alocações e muitas vezes a colaboração se torna mais uma competição.
O time do exemplo ali de cima tinha uma miscelânea de níveis e, iniciantes na área costumam ficar responsáveis pelas tarefas mais operacionais. Já o pessoal em um nível intermediário começa com as tarefas táticas. E os mais experiências com as estratégicas e mentoria, muitas vezes eram eles que faziam à frente com os clientes. Não significa que um sênior nunca mais fará algo operacional e nem que o júnior nunca estará envolvido em coisas estratégicas, o mesmo para o pleno, mas assim todos consguiam evoluir.
É importante que a estratégia de atuação seja aberta para o cliente, ou seja, alinhar que existirá uma squad core com profissionais de apoio, com liderança responsável pela qualidade das entregas e carreira desses profissionais e que o nível de seneriodaide será definido pela consultoria assim como a escolha dos perfis. Muitas vezes o cliente quer ter o controle de quem vai atuar com eles, vale negociar, vale ouvir opiniões, mas o profissional é da consultoria e ela precisa ter responsabilidade sobre ele em todos os aspectos.
3- Ferramentas
O segundo aspecto é proporcionar ao time as ferramentas adequadas. Quanto maior o time, maior é a importância de escolher ferramentas capazes de proporcionar a colaboração e deixar disponível o máximo possível de insumos para consulta de qualquer pessoa e também do cliente, afinal, o que for produzido é dele.
Utilizar drivers em nuvem costumam ser a melhor opção. Na época testamos diversas possibilidades, fizemos análise das ferramentas distribuídas por cada fase do nosso processo de design e qual o propósito que elas precisariam atender, com isso foi possível identificar qual delas nos atenderiam com eficiência e também facilitou a decisão de escolha focada em não gerar custos desnecessários para a área. Consideramos também o que era mais comuns clientes que já possuíam times de design utilizar e como poderíamos garantir o compartilhamento de arquivos até mesmo com aquelas empresas mais burocráticas.
Abaixo exemplos do que utilizavamos:
Dentro de cada uma dessas ferramentas também existiam formatos para organização que contemplavam como dividir os materiais das squads, nomenclatura de arquivos, owner dos arquivos, como compartilhar com pessoas externas, etc. Tudo para facilitar a busca de informações, garantir a segurança das informações, que nada seja perdido no caso da saída de algum membro do time e, principalmente, segurança da informação.
4- Processos
Um time pequeno talvez não precise de processos tão bem estruturados, mas a medida que ele começa a crescer é importante criar uma organização mínima de modo que também promova a independência das pessoas. Em um contexto de consultoria, os processos ajudam a garantir qualidade nas entregas e padronização na hora de vender o time, sim, é preciso vender o time (depois posso te conto mais sobre).
É importante criar cerimônias externas (com o cliente) e internas (apenas com o time), isso porque cada fórum tem um objetivo diferente, é como se você estivesse em uma empresa de produto que existem as cerimônias do time a dos stakeholders. Ou seja, nada mais natural. Com o time o líder se aprofunda em detalhes técnicos, como o cliente em detalhes de negócios.
As cerimônias com o time podem ser:
- Weeklys
Espaço para que todos os designers possam contar como está sendo atuar em sua squad e compartilhar seu trabalho. Assim, mesmo pessoas que não estão na mesma squad acabam tendo um contexto mínimo do que acontece na outra, e é um espaço para trocar ideias. - Workshops
Espaço para um membro do time compartilhar um conhecimento específico que seja de interesse coletivo ou para realizar alguma dinâmica que auxilie a evoluir o processo de designe ou entregáveis. - Acompanhamento da squad
Momento em que os designers de cada squad se reúnem com o seu líder e head da área para planejar ações e estratégias de atuação com o cliente. - Health check
Momento para medir a satisfação do time como um todo com os projetos, processos, ferramentas, etc. (olha só como é feito o nosso aqui)
As cerimônias como cliente irão depender da necessidade, o que sugiro é alinhar diretamente com os envolvidos, alguns exemplo:
- Weeklys
Espaço para os designers e pessoas da área demandante discutirem de forma colaborativa as soluções ainda em momento de construção. - Acompanhamento de projeto
Momento entre lideranças para acompanhamento das entregas, negocição de prioridades, discussão sobre problemas, etc.
As cerimônias são um ótimo momento para o cliente ter proximidade da consultoria, é claro que esses momentos não precisam ser restritos a formalidades, pode-se criar algum formato async como grupos no Slack. Ou seja, a ideia não é isolar as pessoas e ter alguém para filtrar a comunicação, isso na verdade pode prejudicar a relação entre as partes e até mesmo a qualidade da entrega.
Uma outra de dar e ter visibilidade sobre alocações e desenvolvimento das demandas, é utilizar um quadro kanban qu epode ser criado no Jira, Trello ou qualquer outra ferramenta que seja fácil pra sua empresa. Essa é uma outra técnica que auxilia a implementar uma metodologia de trabalho e também para que o cliente saiba como o time trabalha.
Na imagem abaixo você confere como era o quadro kanban que meu time utilizava naquela época e neste artigo você não só conhece os detalhes de como chegamos até essa estrutura, como poderá aprender a como construir um para o seu time.
5- Padrões de entrega
Por fim chegamos aos padrões de entrega. Eles são importantes para:
- Otimizar a atuação do designer
Se a cada novo projeto você precisar definir um novo padrão existirá uma perda tempo que poderia ser utilizado para pegar contexto, o que é muito mais importante. Padrões facilitam a vida das pessoas e elas têm tempo para ficar focadas no que mais é importante. - Material de consulta para o time técnico
Tudo o que é gerado por um time de design em algum momento chega até as mãos do time técnico. Como em um cenário de consultoria cada squad possui um time técnico diferente e a troca de contexto é algo relativamente comum, imagine precisar aprender como utilizar cada novo padrão tanto para o designer quanto para o desenvolvedor? Não que adaptações não possam ser feitas, mas a lógica sendo a mesma se estabelece uma comunicação comum à todos os projetos. - Transmissão de conhecimento para o cliente
Todas as análises, definições e materiais gerados são por direito do cliente. Em um cenário de consultoria onde hoje somos nós atuamos com o produto, mas amanhã pode ser outra empresa, garantir que o conhecimento não seja perdido é essencial e facilitada a imersão da próxima empresa no projeto. Já entrei em muitos projetos de outras empresas (inclusive de empresas grandes e famosas) que ignoravam a documentação, por isso vai por mim… deixe um material de apoio organizado e não só facilite a vida do seu próprio time quando recebe uma nova pessoa para fazer onboarding, mas também seja um exemplo para a próxima empresa.
Pensando nesses motivos que representam também o público-alvo, tinhamos os seguintes padrões de entrega:
Análise de UX
O objetivo era registrar todo o entendimento de uma demanda, decisões realizadas e experimentos com foco nas fases de discovery e ideação do nosso processo, serve principalmente para as defesas das ideias com stakeholders e time técnico. O template ficava no Google Slides com diversas dicas e exemplos de documentação.
Protótipo
Serve como base para que os stakeholders e time técnico possam validar a interface, fluxos e cenários. Após a aprovação serve como guia para a implementação da solução final a ser publicada.
Tinhamos então boas práticas para utilização de componentes, nomenclaturas, uso de imagens, grids, etc. que são aplicadas no Figma que também sempre utilizamos a master components para cada projeto a qual pode ser criada pelos nossos próprios designers ou utilizada a do cliente caso ele tenha.
Handoff
É uma documentação complementar ao protótipo no qual o desenvolvedor e tester irão consultar todos os detalhes de comportamentos bem como a indicação de templates e componentes do Design System de cada projeto.
O handoff era criado dentro do próprio Figma e disponibilizavamos para os designers uma master com diversos elementos padrões a serem aplicados.
UX review
É um documento gerado apenas quando a validação da implementação apresenta inconformidades com o protótipo e documentação de handoff. Nele devem ser indicados todos os detalhes através de prints e textos que irão direcionar os ajustes necessários os quais separados em obrigatórios e recomendados.
Tinhamos um template no Google Docs com diversas dicas e exemplos.
Vendendo o trabalho
Se você é Head de design em uma consultoria vai enfrentar o desafio de vender o serviço prestado pelo seu time. Existem N formatos e se o seu objetivo é ter um time estratégico, te aconselho a se envolver nesse processo. Eu me envolvia, em partes porque o a própria empresa estava buscando um formato ideal de consultoria e também para poder influenciar no momento de entender o escopo do trabalho. Participei de diversos processos de concorrência e imersões em projetos, ter uma metodologia e as organizações do time facilitou muito a construção de cases e a termos clientes mais satisfeitos com a transparência na atuação e compartilhamento de conhecimento.
Nestes momentos não fale sobre números de projetos ou pessoas na área, fale sobre resultados e impactos gerados. Se o seu cliente estiver preocupado com processo, ferramentas, etc. significa que tem algo errado, significa que ele não está convencido do potencial de entrega do seu time.
Ao longo do projeto além das cerimônias do dia a dia, tenha com seu cliente a prática de comemorar as vitórias que conquistaram juntos, tenha momentos de reflexão sobre o quanto essa parceria está sendo produtiva para ambos os lados, você como líder precisa construir relações mais políticas para conquistar cada vez mais espaço.
Indo além
Eu estive como Head de design nessa consultoria por quase cinco anos, lá eu aprendi muita coisa de diversas maneiras. Na tentativa e erro. No sonho e na frustração. Na certeza que devia ser de um jeito e na hora de defender perceber que não era aquele o melhor jeito. E outras… mas o maior aprendizado que tive, sem dúvidas foi que:
Mais importante do que planejar o futuro de uma área é entender o contexto que ela está enfrentando agora e, principalmente, o momento que a empresa está e onde ela quer chegar. A partir disso é que você conseguirá planejar o futuro, mas cuidado!
Para facilitar a visibilidade de como o meu time atuava e planejar quais ações eram necesárias para que pudessemos evoluir e conquistar projetos cada vez mais estratégicos e menos operacionais, construir um board com diversas métricas de produtividade, alocação, satisfação dos designers, satisfações dos clientes e maturidade de design (por squad e geral). Esse board era utilizado em conversas com o CEO da empresa onde eu consegui por diversas vezes apoio para dar um próximo passo, com o CTO da área de tecnologia para aprovações diversas, também em impulsionar o time comercial a mudar o seu discurso de vendas e na hora de contratar uma pessoa, era a realidade do board que nós davámos transparência. Aliás, todos os membros do time tinham acesso a essas informações e todas as ações que eu realizava para conquistamos o próximo passo.
(em breve imagens do board)
Visões de longo prazo tendem a ser desperdício de energia e um prato cheio para frustrações.
Foque no contexto de agora e crie uma visão de curto, no máximo médio prazo com steps e sinais que evidenciem que o time chegou lá e que é a hora de investir no próximo. Não crie nada rígido. Ser flexível é muito importante em um cenário volátil de mercado que estamos vivendo hoje.
Inspire-se em equipes de outras empresas, mas não encare nada como verdade absoluta pois cada cenário tem suas próprias particularidades 😉.
