top of page

Thinking Design!

Foto do escritor: Bianca GalvãoBianca Galvão
Serendipidade por design é o núcleo cultural de um estúdio de design. Em um estúdio pré-digital, o trabalho de todos é exteriorizado, visível e transparente. Isso significa que as ideias são justapostas propositalmente, passivamente, acidentalmente e serendipitosamente. Essas interações forçadas que dão luz a novas ideias são fundamentais para como o design funciona.

DesignOps Handbook — Invision. By K.Battles, M. Black, D. Malouf, C. Whitehead and G. Bernstein (editor).





 


A origem da cultura de trabalho dos times de design difere muito em relação às empresas de tecnologia. Desde que cursamos nossas faculdades, passamos por matérias de desenvolvimento de projeto (1–6 na minha época), e entendemos que todo o processo criativo dos designers funciona de maneira muito diferente do padrão adotado pela indústria de software.

Designers, por origem, costumam orientar seu trabalho por uma “pegada” muito mais “user centered”, partindo do processo de visão, exploração, desconstrução, pensamento associativo e interrupção. Mesmo apoiados em processos como double diamond, é importante destacar o ciclo rápido de aprendizagem e troca entre eles, e como esse fluxo pode rodar inúmeras vezes para a entrega de uma simples feature de produto, a troca e a interrupção são passos fundamentais para o desenvolvimento e evolução dos entregáveis.

Tendo isso em mente, conseguimos perceber que um dos grandes problemas atuais das empresas de tecnologia gira em torno de tentar realizar a integração do trabalho dos designers de forma sadia e criativa aos ciclos de entrega do time de desenvolvimento. O processo estabelecido pelos times de tecnologia atuais levam os designers a uma desconexão com os seus principais processos de criação, pautando todo o desenvolvimento de software somente no time de engenharia.

Em quase 100% dos casos, ocorre uma subjugação do trabalho dos designers ao processo de tecnologia, fazendo com que as interações dentro dos produtos fiquem cada vez mais desconexas e sem um real propósito para os usuários finais.

Outros problemas cada vez mais presentes nos times de design que também conseguimos perceber são:

  • Designers isolados e não trabalhando próximos aos usuários.

  • Designers com um papel voltado para produção em vez de um papel estratégico, sendo solicitado na maioria das vezes para a realização de uma “limpeza” visual superficial.

  • Práticas de contratação de designers baseadas nas mesmas práticas dos times de engenharia de software.

  • Mapa de carreira de designers traçando um paralelo com o time de engenharia.

  • Ferramentas de design buscando sempre o digital (fim do uso do papel), bem como ferramentas de design que tenham como foco a integração com os times de engenharia ao invés de priorizar as funcionalidades de criação.

  • Ciclos pobres baseados em entregas rápidas, fingindo respeitar o tempo dos designers.

  • Falta de cumprimento e troca em relação a etapas importantes para o time de design.


Em relação aos principais pontos levantados, conseguimos enxergar cada vez mais os times de design bastante desmotivados, e reinventando sempre a sua forma de trabalhar. Porém, essa reinvenção não acontece de forma efetiva, uma vez que a “concorrência” por importância dentro das empresas no Brasil já começa na quantidade de recursos contratados (média de 30 engenheiros para 1 designer).

Por experiência própria, praticamente todas as empresas por onde passei, possuem um abordagem “user centered” só no discurso.



 

Pense diferente

Uma vez que entendemos que o processo que trabalhamos atualmente difere bastante da melhor forma com que os nossos designers trabalham, o que podemos fazer para mudar então? Como construir um time com uma abordagem mais “user centered”?

O primeiro passo para isso acontecer é perguntar! Estar aberto a entender e aceitar o diferente. Falamos muito em inclusão dentro das empresas, porém não aceitamos a abordagem e a forma de pensar diferente entre os times que trabalhamos. Não queremos mudar o que já funciona, certo? Funciona para quem? Será que funciona para todos?

Pessoas que trabalham com tecnologia têm que estar sempre prontas a desafiar o status-quo, a ser realmente “problem driven”, a preparar e liderar times em prol de uma cultura de aprendizado, e não a fazer as coisas do jeito mais fácil.

Segundo o artigo da IDEO, existem 5 comportamentos que devemos prezar na hora de formar e trabalhar um time de design para que o mesmo possa influenciar uma cultura design-driven dentro das nossas organizações, são eles:

  • Cultivar a curiosidade.

  • Experimentar o mais cedo e frequentemente possível.

  • Colaborar através dos silos (pontos para um time de DesignOps, ou uma abordagem de Pool).

  • Compartilhar idéias como um "vírus".

  • Pensar grande e agir rápido para obter o melhor resultado.

Respeitando e fomentando os fatores acima, existe uma grande probabilidade de você estar no caminho certo.



 

Experimente um novo processo

A grande verdade no que diz respeito à formação de times de design é que não existe fórmula mágica para fazer acontecer. No entanto, alguns pontos importantes devem ser observados no seu dia a dia de trabalho como base para a experimentação de novos processos, são eles:

  • A qualidade do que estamos entregando de experiência para o nosso cliente final afeta de forma negativa a performance do nosso produto?

  • Qual a relação designers x engenheiros que possuímos atualmente? Conseguimos suprir todas as squads em relação ao que precisamos entregar?

  • Como anda a satisfação em relação ao nossos designers? Possuímos um problema relacionado a turnover voluntário na nossa equipe?

  • Como estamos trabalhando e entendendo o capacity do nosso time de Design? Quem precisamos contratar?

  • Como estamos evoluindo as pessoas dentro do nosso time? Quais as oportunidades oferecidas?

  • Como podemos melhorar a cultura de design na companhia e entregar um resultado mais consistente?

  • Como manter a velocidade de entrega, mesmo com mudanças cruciais do ponto de vista de negócio?


Se as perguntas acima têm tirado seu sono e feito você pensar em uma melhor forma de atuar, talvez seja a hora de você começar a experimentar novas abordagens para o seu time.



 

Design: squads x pool

Pensando em mudar um pouco o formato Spotify (maldita hora em que esse artigo foi escrito!) de alocação de designers dentro das squads de produto, uma das abordagens que costumo utilizar para responder a essas questões é a da formação de um Pool de Designers.

Entendo de antemão que TODOS os processos possuem falhas, e com isso pontos de melhoria, mas a abordagem de trabalho no formato de um pool de recursos cumpre com quase todos os requisitos da lista de perguntas estipulada acima. Porém, como todo processo, sempre existem tradeoffs a serem trabalhados. Abaixo, fiz uma lista com pontos de vantagem e desvantagem para trabalhar com cada uma das abordagens, incluindo algumas sugestões de como tratar os negativos:

Squads

Pontos fortes:

  • Maior autonomia em relação às entregas individuais das squads.

  • Maior velocidade nas entregas.

  • Menor necessidade de planejamento por parte dos PMs e líderes de engenharia.

  • Maior entendimento do escopo da squad (técnico e estratégico).

  • Maior conexão com os integrantes das squads.


Pontos fracos:

  • Falta de integração a respeito do que é entregue pelas outras squads, o que gera impacto na experiência completa do produto.

Sugestão: Atuação de um time de ops/tematização e research, para guiar a operação e trazer contexto a respeito do “o que”, “como” e “para quem” precisa ser feito.

  • Menos qualidade visando atender os prazos de engenharia e produto.

Sugestão: Criar uma consciência nos desenvolvedores e PMs a respeito da importância dos processos e do tempo de criação do time de design (tri-track?).

  • Menor entendimento do escopo do produto como um todo (não pensamento da jornada por completo).

Sugestão: Ops/tematização e research (guildas ou times). Criação da figura de um designer embaixador por produto.

  • Menor conexão com os designers do seu time.

Sugestão: Ops/tematização e research (guildas ou times). Ritos e acompanhamentos.

  • Problemas em suprir férias e ausência do designer da squad por longos períodos.

Sugestão: Maior número de designers por squad. Mínimo 2, tendo pelo menos a figura de um designer pleno.

  • Escalação de designers seniors para compor o time de forma individual.

Sugestão: Contratação de designers mais experientes para compor as squads. Criação de um “berçário” para o recebimento de novos designers.

  • Desconexão em relação aos processos e metodologias de design, em prol de uma abordagem voltada para as entregas de tecnologia e produto.

Sugestão: Criar uma consciência nos desenvolvedores e PMs a respeito da importância dos processos e do tempo de criação do time de design (tri-track?). Sugestão: Atuação e um time de ops/tematização e research, para guiar a operação e trazer contexto a respeito do “que”, “como” e “para quem” precisa ser feito.

  • Não cumprimento de dinâmicas essenciais do aspecto de design, tendo em vista que algumas delas necessitam da participação de mais de um designer para serem realizadas.

Sugestão: Squads abrindo mão de designers de forma temporária, para a realização de dinâmicas cross-times.

  • Baixa cultura e integração dos designers (impactos gerais na experiência do produto como um todo).

Sugestão: Atuação e um time de ops/tematização e research, para guiar a operação e trazer contexto a respeito do “que”, “como” e “para quem” precisa ser feito. Sugestão: Aumento no número de designers e na experiência dos mesmos, dentro de cada squad.

  • Falta de entendimento a respeito do capacity e da qualidade das entregas dos designers.

Sugestão: Calibração e suporte através de um time de ops para o atendimento do capacity e das necessidades de cada squad.


---

Pool

Pontos fortes:

  • Integração e consistência a respeito do que é entregue pelo time, o que gera impacto direto na experiência dos usuários finais.

  • Prazos orientados pelas dinâmicas de design, priorizando a abordagem user centered.

  • Maior entendimento do produto como um todo (roles de usuários, jornada e personas são peças fundamentais nessa abordagem).

  • Férias, ausências e capacitação do time acontecem de forma a suprir melhor as principais partes envolvidas.

  • Conexão em relação aos processos e metodologias de design (possível ganho em qualidade).

  • Cumprimento e capacidade de realização de todas as dinâmicas relevantes aos entregáveis essenciais para um bom resultado de design.

  • Troca entre especializações distintas (UX, UI, Research, etc). Problemas sendo atacados por profissionais que possuem maior skills na resolução dos mesmos.

  • Alta cultura de integração e desenvolvimento dos designers (Design Principles, Style Guides, Design Systems, etc).

  • Entendimento do capacity do time de design.


Pontos fracos:

  • Menor autonomia em relação às entregas individuais de cada squad.

Sugestão: Divisão percentual em relação ao capacity do time de design por parte das squads.

  • Menor velocidade nas entregas.

Sugestão: Maior planejamento por parte dos PMs, GPMs, Heads e Tech Leaders.

  • Maior necessidade de planejamento por parte dos PMs e Tech Leaders.

Sugestão: Troca efetiva e compartilhamento através de Objetivos, Visão e Roadmaps.

  • Menor entendimento do escopo específico do trabalho de cada Squad.

Sugestão: Embaixadores no time de design para trazer sempre um maior contexto a respeito do que precisa ser feito.

  • Menor conexão com os desenvolvedores e PMs das Squads.

Sugestão: Team building e participação dos eventos realizados em squads e tribos. Reunião e apresentação de cases unificados para trazer contexto para todos.



 

Mas e aí, qual o melhor formato?

Como mencionado anteriormente, não existe fórmula de bolo para trabalhar com times de design. Por experiência própria, tendo sempre a trabalhar no formato de pool, caminhando de acordo com o crescimento/investimento da empresa em relação ao tamanho do time de design. Trabalhando dessa forma, consigo economizar e otimizar recursos em relação à qualidade do trabalho esperado, tendo em vista que a maior parte dos pontos de abordagem em relação aos pontos fracos de um design organizacional voltado à distribuição de designers através de squads envolve um investimento na contratação de mais recursos para o time.

Em prol da evolução e desenvolvimento, trago alguns pontos importantes a serem destacados como evolução de um design organizacional:

  • Momento 1: Time pequeno e uma relação desigual entre designers e engenheiros.

Sugestão: Formação de um pool, que fomente bastante a troca, o entendimento e o aprendizado em relação a tudo que diz respeito à design.

  • Momento 2: Relação designers e engenheiros ainda é bastante desigual, porém existe a oportunidade da divisão entre lideranças e produtos/projetos distintos.

Sugestão: Criação de dois ou mais pools de designers que facilitem as dinâmicas de planning/organização do dia a dia, em prol de uma melhoria na entrega dos objetivos dos produtos. Nesse momento a criação de embaixadores por squads pode fazer sentido.

  • Momento 3: O volume de designers já atende e muito a estrutura das squads. Conseguimos alocar pelo menos 2 designers por squad, sendo um obrigatoriamente pleno ou senior.

Sugestão: Talvez esteja na hora de você começar a pensar em uma estrutura de Ops ou Chapters para a sua equipe. Times de pesquisa e tematização talvez comecem a fazer sentido nesse cenário.

  • Momento 4: Times e estruturas já montadas e bem organizadas.

Sugestão: Pensar fora da caixa! Quais particularidades vão tornar o seu time referência em escala mundial? Como estimular um design experimental e aprender cada vez mais com isso? Como criar conexão e consistência entre as equipes de design que compõem a sua empresa? Como pensar no design de forma global, sem excluir as particularidades que resolvam problemas de usuários locais.



 

Conclusão

Vale destacar que o principal objetivo deste artigo é tentar ajudar líderes e gestores de times de design que sofrem com esse problema atualmente.

Por meio de uma abordagem problem driven, melhore o dia-a-dia de trabalho da sua equipe, e pense fora da caixa! Não deixe que um padrão pré-determinado por pessoas que pouco entendem sobre o trabalho de design moldem o processo e a qualidade do que você entrega.

O ponto fundamental aqui é vencer as barreiras do que existe de forma pré-formatada, sempre buscando a melhor experiência para os usuários.


---


Referências:

DesignOps Handbook — Invision. By K.Battles, M. Black, D. Malouf, C. Whitehead and G. Bernstein (editor).

Comentários


bottom of page