Design System por um desenvolvedor front-end, parte 1

Algumas reflexões sobre o início de um Design System do lado da Engenharia

Design systems são produtos que impactam diversas áreas em uma empresa de tecnologia. Talvez seja por carregar o termo “Design”, mas a verdade é que é um pouco raro encontrarmos o ponto de vista dos próprios desenvolvedores sobre o assunto, vinculando artigos sobre o assunto sempre aos designers.

Decidi contribuir com a lista de pontos de vista da Engenharia. Tenho experiência há algum tempo com design system e hoje atuo como front-end developer, trabalhando exclusivamente com o Zilla, o Design System aqui da Quero Educação.

A lista abaixo não deve ser encarada como um guia de sucesso, mas sim reflexões de quem — assim como um design system — segue evoluindo como profissional que trabalha diretamente com o produto.

1 — Não se engane pelo termo "Design"

Reforce isso toda vez que for falar sobre Design System: Design System, não é só sobre Design.

Já falei isso em uma palestra que dei em Fortaleza, o nome “Design System”, na minha opinião, não é dos melhores para tratar de algo que envolve áreas distintas e, sim, correlacionadas em um produto.

O nome acaba levando muitas vezes a uma conclusão equivocada, de que a responsabilidade do Design System é somente do time de Design.

Design System não é responsabilidade somente do time de Design.

Isso faz com que o time todo tenha menos força ao tentar levar para a empresa a importância do Design System e os papéis que diferentes pessoas de diferentes áreas teriam que ter — além de sobrecarregar o time de Design com as decisões e evolução.

Se você acredita que a sua empresa irá se confundir com o que é e os benefícios, ao invés de chegar e dizer “Precisamos criar um Design System”, tente começar explicando o problema que o Design System irá resolver, que muitas vezes pode ser resumido em:

falta de padronização que leva a um aumento no tempo de desenvolvimento de tarefas repetitivas de interface, tanto do time de Design quanto de Engenharia.

Comece explicando o caminho que deverá ser seguido e os benefícios que esperam colher e defina um objetivo palpável a ser alcançado.

Somente no final chame de Design System. Dessa forma, talvez você consiga se blindar de conceitos errôneos e opiniões enviesadas.

2 — Design System é um produto, não um projeto.

Design System não tem fim. Novos componentes surgem, componentes existentes são modificados, mais ferramentas são criadas para melhorar o uso do seu Design System pelos desenvolvedores, enfim.

Haverá muitas versões baseadas em rebranding da marca, que impactarão toda a empresa, além de versões com breaking changes. E seu time terá que fazer com que isso impacte o mínimo possível para as outras squads, que já têm prazos e metas diferentes. Muito provavelmente seu time terá um backlog específico de features request e bug fixes.

Tratar um Design System com começo, meio e fim, pode ser um equívoco. Você tem sim entregáveis, mas o Design System é um organismo vivo e quanto mais cedo a empresa entender isso, melhor.

Um Design System é um produto que serve outros produtos. Um exemplo é o Design System do Spotify.

3 — Não comece um Design System sem ter um Design System.

Se você lida com DS, já deve ter ouvido alguém se questionar:

Quando criar um Design System? No início de um produto ou quando o produto estiver mais tempo de vida?

Particularmente acredito que um Design System só possa ser criado de forma madura, quando o produto em questão já tem tempo e estatísticas suficientes para que o time possa entender o ciclo de vida das interfaces do seu produto.

Começar um Design System sem saber se o componente de Table realmente é algo que seu produto precisa. Isso vai fazer com que seu time gaste esforço e energia em algo que não terá valor para você e para o cliente final.

Eles poderiam estar usando essa energia para criar features mais relevantes para o usuário, que possibilite que o produto amadureça e crave sua marca no mercado.

Isso não quer dizer criar um produto sem padrão e de qualquer jeito. Mas aproveitar o que já tenha no mercado e que seja de fácil customização no começo.

O modelo de negócios e brand do produto precisam estar estáveis e maduros, para que se possa criar um Design System de confiança. Não significa que um Design System não possa sofrer modificações drásticas e rebranding ao longo do caminho. Mas, na minha opinião, quanto mais instável seu produto e modelo de negócios, mais instável será o valor entregue por um Design System.

Agora, independente de ser criado em um produto inicial ou em um já estabilizado, é possível a empresa achar que é factível construir um Design System, sem ter as definições de Design prontas ou pelo menos as bases iniciadas.

Nesse ponto, é preciso saber explicar que é crucial o trabalho em equipe entre Design e Engenharia e que um dos primeiros passos deveria ser identificar os componentes que o seu produto precisa.

Depois e somente depois, o time de Design conseguirá atuar de maneira mais assertiva e entregar ao time de Engenharia os primeiros componentes a serem desenvolvidos.

Não existe nenhuma regra acima ou algo intocável que se acontecer está tudo fadado ao fracasso, mas, de forma alguma, comece um Design System sem que os componentes estejam minimamente definidos em Design.

Se a empresa insistir por esse caminho, acredite, talvez a sua empresa não esteja pronta para criar um Design System e o melhor seria usar Bootstrap e customizar conforme a necessidade de branding da empresa.

4 — First things, first.

Acho que a primeira coisa que todo desenvolvedor Front-End pensa, quando começa a trabalhar em um Design System, é:

Ok, vou começar pelo Button aqui então …

Fuja disso!

Primeiro, tenha em mente verificar com o time de Design se os seguintes itens estão validados:

• Grids
• Breakpoints
• Tokens de Spacing / Size
• Tokens de Shadow
• Tokens Border
• Tokens de Typography
• Tokens de Acessibilidade
• Paleta de Cores
• Temas

Talvez seu Design System não precise de todos os itens acima, talvez precise de mais. Mas é um bom ponto de partida. Refine todos esses itens com o time de Design e o seu time de Engenharia.

Só os itens acima já geram bastante trabalho, imagine ter que refatorar todos eles com o DS já sendo utilizado. Pois é, valide-os o mais cedo possível.

Não se esqueça de definir qual o padrão de nomenclatura irá seguir. O mais difundido é o Atomic Design do Brad Frost, mas existem outros:

• Elements, Modules, Prototype
• Elements, Components, Modules

Independente de qual padrão de nomenclatura você seguir, é importante que tanto o time de Design quanto o time de Engenharia falem a mesma língua. Pense nisso como um DDD.

Será muito confusa a comunicação se o time de Design chamar de Atoms o que o time de Engenharia chama de Elements. Escolham um padrão e siga ele.

5 — Baseado em framework específico ou agnóstico?

A única resposta coerente para essa pergunta é: Depende.

Num contexto geral, não existe certo ou errado aqui.

Se o know-how do seu time, se o produto, se os profissionais do mercado na sua região usam fortemente Backbone, sem problemas! Crie seus componentes com Backbone.

Algo que poderia ajudar muito aqui, é pedir ao time de Design que faça um estudo de personas do Design System. Dessa forma vocês vão conseguir identificar os diferentes perfis de usuários.

Lembrando que os usuários aqui não são o cliente final, mas, sim, os desenvolvedores da empresa.

Específico ou agnóstico, as duas abordagens tem prós e contras. O mais importante é que seja uma decisão alinhada com os demais desenvolvedores e líderes técnicos.

Se seguir para uma biblioteca de componentes baseadas em um framework específico, tenha em mente que dificilmente será reaproveitado caso surja algum outro projeto / produto em outro framework. A não ser que siga o caminho de desacoplar o CSS (falarei disso no próximo artigo). Isso evita uma parte do retrabalho.

Caso vá para o caminho de criar algo mais agnóstico, provavelmente irá usar Web Components, talvez até um Stencil. Com isso você ganha todos os benefícios e malefícios das WC, como por exemplo, ter um trabalhinho a mais caso SEO seja importante para o seu produto.

Particularmente, eu prefiro ir pelo caminho de usar o framework da stack do time. Mesmo que na stack existam mais de um framework padrão. Digo isso, pois ouço e estudo sobre web components desde meados de 2010 e entra ano, sai ano a história é a mesma:

Esse é o ano das web components!

De fato, cresceu mais nos últimos dois anos do que em todos os demais anos. Mas ainda assim, talvez seja uma briga que seu time precisa decidir se entrará, afinal serão dois desafios: web components e design system.

Para saber do resto das reflexões, leia Design System por um desenvolvedor front-end, parte 2.

Esse é só o começo…

Se quiser saber mais sobre Design System na perspectiva de um desenvolvedor front-end, acompanhe a segunda parte deste artigo.

E não se esqueça de ler também:

• Design system: conectando desenvolvedores e designers, por Ney Pimenta.
• Design System: da confusão à construção de um produto, por Jan Klever.

Quer fazer parte deste desafio e de muitos outros? Estamos com vagas abertas.