Design systems na prática — Desafios, limitações e a evolução das nossas ferramentas.
Estamos vivenciando uma crescente disputa entre ferramentas de design digital. Pra quem cresceu profissionalmente em um universo onde você não tinha outra escolha a não ser usar produtos da Adobe (e Corel), hoje contamos com muitos players em potencial como o Sketch, Figma, Adobe Xd, InVision Studio, Subform, Phase, e boatos que até o Dropbox está com planos de lançar sua própria ferramenta para design de interfaces.
Apesar de existir uma competição muito grande em torno de qual ferramenta vai ganhar essa briga, nossas ferramentas evoluiram muito pouco nos últimos 30 anos. De lá pra cá ainda estamos gastando nosso precioso tempo entregando imagens estáticas ou protótipos navegáveis.
“Digital product design tools have traditionally represented design as a series of pixels and rectangles — things that look like the desired outcome, but are actually static images of what an interface will eventually become…”
— Jon Gold
There's no silver bullet
Nós designers estamos em uma busca constante por ferramentas que nos atendam integralmente, possibilitando organizar nossos arquivos e componentes de uma maneira mais rápida e eficaz. Mas a dura realidade é que não importa qual ferramenta estamos utilizando e quão organizado nossos arquivos estão, o elo mais fraco do nosso processo ainda é a conexão entre design e desenvolvimento, é nesse ponto onde a situação acaba saindo do controle com o tempo.
Um dos principais motivos dessa ruptura no processo entre design e desenvolvimento se deve a um ponto que eu citei em textos anteriores: "Designers e engenheiros ainda não falam a mesma língua". Por não falar a mesma lingua, eu quero dizer que falta muito vocabulário em comum para ambos os lados se entenderem e trabalhar melhor em conjunto.
Por esses motivos que o foco de um design system deve estar em não só prover mais consistência e velocidade para designers, mas também estreitar a relação e entendimento da equipe toda sobre o produto e diminuir a distância entre protótipos e o que será efetivamente implementado no código, porque é no código onde todas as decisões tomadas (e as que foram negligenciadas) estarão efetivamente formalizadas.
Quando você olha esse problema por esse ponto de vista, faz muito sentido a movimentação (ainda que experimental) do airbnb ao criar o react-sketch e o protótipo de usar machine learning para transformar wireframes em componentes production-ready. Esse tipo de experimento só é possível com um design system mais maduro, com todos os pontos críticos dos componentes resolvidos e documentados para que todos envolvidos no processo tenham a clareza de quais ferramentas utilizar para resolver seus problemas.
Existem também algumas iniciativas muito interessantes que também focam em estreitar essa distância entre design e código, como o Compositor Lab, onde você consegue gerenciar seu design system através de componentes React que podem ser utilizados em produção, além de muitos outros na mesma linha.
A grande questão aqui é evitar desperdícios de tempo e canalizar esforços onde realmente é essencial para o negócio e conseguir entregar valor o mais rápido possível, mas sem perder qualidade. Assim você e sua equipe podem investir mais tempo para solucionar problemas maiores e estar mais em contato com seus usuários.
Desafios na criação de um design system
Para garantir o sucesso do design system é preciso trata-lo como um produto que tem suas próprias necessidades e estratégias muito bem definidas. Para isso, inevitavelmente você irá passar por essas etapas:
- Criação
Construção e definição dos princípios e padrões que sustentam o sistema. - Adoção
Tornar a utilização do sistema prática no workflow da sua equipe. - Educação
Documentar constantemente e educar todos a utilizar corretamente. - Manutenção
Manter e evoluir padrões em conjunto com o produto.
É muito comum ver histórias de iniciativas de design system cairem em desuso e ficarem ultrapassadas por falta de adoção dos times. Muitas pessoas se sentem limitadas na criação das interfaces e acabam não aderindo completamente a utilização dos padrões estabelecidos ou acabam não tendo tempo para documentar suas decisões por falhas no processo. Para garantir que isso não aconteça é necessário explicar bem o racional e as decisões de design por trás dos padrões e garantir que a utilização no dia a dia da sua equipe seja o mais fluida possível e não seja um gargalo no seu processo.
Um excelente exemplo de como se integrar no workflow natural da sua equipe é o trabalho que o Facebook tem feito com design systems.
Closing the gap
Um lançamento recente que me deixa muito otimista com melhores workflows e melhores integrações com nosso dia a dia é o lançamento da API pública do Figma, que embora ainda seja um release read-only, ou seja, você só consegue ler informações dos seus documentos do Figma. Esse release já apresenta um grande potencial para estimular o desenvolvimento de novas ferramentas para se integrar no nosso workflow, como o experimento do airbnb que está desenvolvendo um linter para garantir que os documentos do Figma estão dentro das diretrizes do design system da marca, evitando que membros da equipe percam tempo revisando detalhes que podem ser automatizados.
Esse conceito de "linting" que já é extremamente difundido no mundo do desenvolvimento ainda está começando a dar seus primeiros passos no design com essa evolução das nossas ferramentas.
Isso mostra que estamos no início de uma nova era de ferramentas onde design e desenvolvimento estarão cada vez mais próximos e, com sorte, perderemos bem menos tempo nesse ping pong entre design e desenvolvimento e muito mais entregando produtos relevantes.
Este post faz parte de uma série de posts sobre design systems. Você pode ver os outros posts aqui:
- Parte 1: https://brasil.uxdesign.cc/o-estado-atual-do-%C3%A1rduo-processo-design-de-produtos-digitais-268fa088c55f
- Parte 2: https://brasil.uxdesign.cc/design-systems-na-pr%C3%A1tica-preparando-o-terreno-cfd5c29d2ae
👋
