Design systems na prática — Preparando o terreno.

No meu texto anterior eu dei uma visão geral a respeito das dificuldades que temos com processos e ferramentas que utilizamos no nosso dia a dia concebendo produtos digitais. Agora, a ideia é ir mais a fundo em cada etapa do processo e expor, de maneira mais prática e técnica, meu ponto de vista e experimentos sobre como ter mais velocidade, qualidade e confiança nas entregas do seu produto.

You can’t innovate on products without first innovating the way you build them.

Alex Schleifer, VP of Design — Airbnb

Desde o meu primeiro contato com computadores, eu sempre tive curiosidade de saber como os softwares funcionavam. Olhando em retrospecto vejo que o primeiro estímulo que tive experimentar com interfaces e códigos (mesmo sem saber o que estava fazendo) foi através de skins do WinAmp e fuçando em scripts do mIRC (saudades do Full Throttle e T7DS).

“Winamp, it really whips the llama’s ass”

Desde então design e código sempre seguiram lado a lado na minha evolução profissional. Estou longe de ser um especialista em front end, aprendi apenas o básico para conseguir transformar minhas ideias de interface e interação em código e poder ter um controle maior sobre o que as pessoas efetivamente iriam interagir.

Sempre tento me manter atualizado e acompanhando novidades em processos e ferramentas para diminuir o abismo que existe entre designers e desenvolvedores. Todo designer eventualmente já se deparou com sua interface entrando num limbo e se transformando em um Frankenstein quando sobe para produção, certo?

Isso acontece por inúmeros motivos, mas o principal deles é o fato de que designers e desenvolvedores não falam a mesma linguagem. Designers conhecem muito pouco a respeito das ferramentas e de como os desenvolvedores efetivamente trabalham no dia a dia. Desenvolvedores muitas vezes não entendem alguns fatores que são cruciais para a experiência das pessoas que irão utilizar o produto.

Estamos em um momento onde startups precisam ser cada vez mais agéis em suas entregas para se manterem competitivas. Mas, como bem sabemos, o desenvolvimento de produtos é um processo extremamente complexo, que fica ainda mais complexo a medida que sua equipe vai crescendo.

O objetivo de se estabelecer um design system é justamente estreitar essa relação e criar um idioma em comum para que a equipe se comunique de forma mais clara. De uma maneira ou de outra, se você já construiu e tem um produto "rodando", ele inevitavelmente segue alguma espécie de padrão, seja ele consciente (com style guides e afins) ou inconscientemente (projetando interações com base no seu feeling do que é certo). A ideia de projetar esse idioma no qual sua equipe e produto vão se comunicar é justamente ser mais efetivo e preparar seu produto para crescer de maneira mais organizada e consistente.

Design Systems Are a Language. Product Is a Conversation. Marcin Treder, CEO — UXPin

First things first

É bom deixar claro que um design system vai muito além do que simplesmente sair organizando seus símbolos no Sketch (ou Figma), que é o primeiro impulso de muitos designers. Antes disso é preciso fazer a lição de casa e entender a fundo o objetivo e propósito do seu produto.

Traga toda equipe para a mesma página

Para o processo ser implementado com sucesso, é necessário que as áreas design, engenharia e marketing do seu produto estejam alinhadas nos benefícios que o processo irá trazer. O termo “Design System” muitas vezes pode assustar por ser algo termo relativamente novo e dá uma impressão de que o esforço de implementar será enorme, então é bom esclarecer e tirar uns preconceitos para ter o buy-in de todos.

Product Managers (ou gerentes de projeto) tendem a ficar na defensiva com medo que uma mudança diminua a velocidade de entrega ou perca o foco da sua equipe. É natural que uma mudança na forma como a equipe trabalha seja um processo desconfortável e inevitavelmente mais lento no início, mas é um investimento que "se paga" muito rapidamente com tempo.

A equipe de engenharia pode acabar ficando receosa com bugs e “releases big bang”. É bom sempre deixar claro que implementar um design system em um produto já existente não significa necessariamente um redesign geral da aplicação em um release megalomaníaco. É possível (e extremamente recomendado) fazer uma implementação incremental atendendo normalmente as demandas do seu roadmap. Afinal de contas, o mais importante sempre será entregar valor para seus usuários.

Algumas pessoas acabam achando que todo o esforço é meramente estético, apenas "deixar o produto mais bonito". Apesar de não ser esse o objetivo, ter uma consistência visual por toda aplicação (ou aplicações) tem inúmeros benefícios — Aumenta a presença de marca em escala, diminui a carga/esforço cognitiva e definitivamente acaba proporcionando uma experiência melhor.

É necessário que todos percebam todas vantagens do processo:

1. Mais velocidade do protótipo até a feature efetivamente implementada.
2. Mais agilidade para fazer modificações em features já existentes.
3. Maior consistência de identidade e interface.
4. Melhor trabalho em equipe e colaboração entre as áreas de produto e desenvolvimento.

Saiba seus pontos fortes e fracos

Um fator muito importante é analisar as características da sua equipe. Ter a consciência do poder de execução que você possui é essencial para criar um processo que seja sustentável de manter e escalar no longo prazo. É sempre bom se questionar:

• Como minhas equipes são organizadas? Departamentalizado ou em squads autônomas?
• Quem ficará responsável por documentar e formalizar os componentes e padrões de interação? Algumas pessoas específicas ou terá a responsabilidade compartilhada entre todos designers?
• Minha equipe tem poder de execução para manter o produto no longo prazo com as tecnologias que estamos utilizando?

Ter a certeza desses pontos fazem com que você estruture um processo muito mais pé no chão, que seja compatível com suas limitações. Afinal de contas não é qualquer startup que tem cacife para suportar um "dream team" com todas especialidades e tecnologias da moda. O grande ponto é saber suas limitações. É melhor um processo simples do que nenhum processo.

Conheça a fundo o objetivo da empresa e do seu produto

É muito importante que toda sua equipe esteja alinhada e tenha feito toda lição de casa de validação, imersão com usuários e tenha os objetivos do produto na ponta da lingua. Caso contrário, é muito fácil se perder em modismos e tomar decisões que não fazem sentido na visão de longo prazo do seu produto.

O objetivo da sua empresa e do seu produto irão moldar todas as suas decisões de como seu processo, componentes e padrões irão se comportar.

Próximos passos

Depois de ter toda equipe alinhada nos objetivos e benefícios, é hora de botar a mão na massa. Os próximos passos são:

1. Criar os "Design principles" da sua equipe de produto.
2. Mapear os principais fluxos da sua aplicação e priorizar áreas que necessitam de maior cuidado.
3. Fazer um inventário de elementos e componentes da sua interface atual.
4. Criar, organizar e documentar os padrões visuais da identidade do seu produto.
5. Criar, organizar e documentar padrões de interação e componentes da interface.
6. Implementar ações que estimulem a adoção contínua do design system entre todos os membros da equipe.

Nos próximos posts vou explicar detalhadamente o passo a passo de cada um desses itens e como aplica-los gradualmente em produtos já existentes.

Pra quem não tiver paciência de acompanhar essa série de posts e quiser ler mais sobre design systems por conta, eu recomendo dar um check no livro da Alla Kholmatova e nos posts do Nathan Curtis.

Este post faz parte de uma série de posts sobre design systems. Você pode ver os outros posts aqui:

• Parte 1: O estado atual do ~árduo processo de~ design de produtos digitais.
• Parte 2 (esse post): Design systems na prática — Preparando o terreno.
• Parte 3: Design systems na prática — Desafios, limitações e a evolução das nossas ferramentas.

👋