Desde o começo do projeto entendemos a necessidade de um design system. Acredito que, por mínimo que seja, todo projeto precisa de uma biblioteca de componentes. As bibliotecas de componentes facilitam muito a vida dos desenvolvedores, e para nós (products, ui, ux ou qualquer outra sigla...) nos dá uma boa visão macro do projeto e com um certo viés sistêmico, deixamos de lado a estética e focamos na pura função de um componente.
Não foi fácil.
Nosso primeiro embate foi o próprio projeto. Se você buscar design system no google vai encontrar a seguinte frase: "O design system é um produto que serve outros produtos." mas o que fazer quando o produto a ser servido não se compreende? E quando não temos tempo? E quando nossa prioridade é o discovery, ux e entrega de telas?
De inicio usei o Material Design como base para nosso design system, essa é a abordagem mais inteligente a se fazer quando não temos tempo ou recursos a favor.
Começei com componentes já prontos de uma pequena biblioteca que tínhamos e claro que não fui muito longe. Fazer algo do zero não é fácil, tomar decisões sobre funções que vão atuar em contextos diferentes, preparar um legado para equipes futuras não é apenas uma construção de um projeto, é uma construção de conceito. Antes de falar sobre componentes eu preciso solidificar uma base, como em uma casa, preciso de uma fundação.
Primeiro estipulei os princípios do design system, acho interessante dar uma identidade a ele assim qualquer profissional que entrar no projeto já se situa à sua essência.
E essas são: Metáfora, intuição e Design Pessoal.
"Fun.da.men.to: Conjunto dos trabalhos necessários para assentar solidamente uma construção: começar as fundações de um edifício."
O fundamento é tudo aquilo que serve de base para a cosntrução de um componente.
Veja o exemplos baixo:
Temos dois estados de um mesmo componente, como vou especular esse estado se não atribui nenhuma função as cores? Cores não são componentes, mas em um projeto tem uma função sistêmica e semiótica.
Mapear elementos e não são componentes mas fazem parte essencial deles é como dar um passo pra traz para enquadrar uma foto, o Atomic design explica isso de uma maneira bem elucidada: dentro de um comporte existem moléculas e átomos, aqui chamei essas moléculas de fundamentos.
Sobre processos
Segundo Nathan Curtis, “Um Design System não é um projeto. Ele é um produto que serve a outros produtos" e é assim que deve ser tratado. No começo do projeto, tentamos encaixar a construção dos componentes a nossa rotina de entregas e os frutos foram apenas um compilado com um pouco mais de meia dúzia de componentes sem nenhuma especificação técnica. Quando encaramos o design system como um projeto apartado consegui dedicar tempo para uma pesquisa mais aprofundada e assim, construir um documento muito mais sólido.
Dado inicio a construção do design system as expectativas eram de um processo linear, algo parecido com um esteira de produção clássica: ideação, prototipação, homologação e desenvolvimento mas não é.
Como imaginamos o processo de criação de um componente: um emaranhado de discussões e testes. depois. a entrega para desenvolvimento.
Mas na verdade é assim: o processo criativo de um componente depende de outros componentes, assim como depende dos fundamentos e, ao mesmo tempo, deve ser funcional e consistente. Isso gera um vai e volta natural. É necessário testar pois existe situações onde o componente funcione em um contexto e em outro não.
Estabelecer o processo criativo que não seja uma esteira linear não significa um processo bagunçado, estabeleci um kanban simples para o meu controle pessoal, com alguns tópicos bem úteis assim consegui manter o processo de criação voltado para o ágil e não me perdia nesses vai e voltas do dia a dia.
Mapeamento de componentes: nessa primeira etapa mepeamos todas as telas buscando os componentes a serem feitos, aqui nossa intenção é levantar o não só quanto esse componente é usado mas como ele sofre "quebras", ou seja, quantas vezes ele é (ou pode ser) modificado.
Por exemplo: Quantos títulos temos? Qual a diferença entre eles? Qual a função de cada um?
Pesquisa: Aqui fazemos uma pesquisa profunda sobre esse componente, o que é, qual o uso dele, nomenclaturas e derivações, isso ajuda muito na hora de conseguir uma linguagem universal para design System, trabalhamos com muitos termos em inglês no dia a dia e alguns elementos podem conter nomenclaturas novas ou termos regionais é sempre importante pesquisar.
Discussão do componente: Com essas informações e com os componentes mapeados posso abrir ou não uma discussão com outros designers, isso depende da complexidade do componente e do quanto ele é usado no projeto, em geral discutimos a usabilidade dele, possíveis falhas e desdobramentos.
Refinamento: Aqui são feitos alguns ajustes finos nos componentes, ajustamos ele à biblioteca criamos variações (component state).
Homologação com Devs: Uma validação técnica voltada ao desenvolvimento.
Estrutura de um componente
Um comporte tem como estrutura:
Cor
Tipo
Icone/imagem
Espaçamento
Margem
Forma
Função
Todas esses detalhes devem ser escolhidos muito bem embasados, por eles devem funcionar em aqualquer contexto.
Quando componente está estruturalmente feito, faço um texto explicando o que ele é, por que foi feito daquela maneira e como usá-lo. Também eplicos regras e espaçamentos e margem, exceções e derivações. Assim mantenho o design System independente, qualquer pessoa pode criar um novo componente ou até mesmo modificar um existente.
Fazer um design System não é fácil, requer lidar com a própria noção de ritmo e produtividade, olhar para o macro e o micro simultaneamente, ser flexível e manter o foco. É uma coisa bem maluca, é quase filosófico, sempre que me perguntam o que eu aprendi, acho que a minha resposta não atende as expectativas dos curiosos, minha resposta é sempre a seguinte - "Aprendi a desapegar, nada é perfeito. As vezes a melhor coisa que você tem a fazer é deixar a de ser perfeccionista. Focar na entrega. Essas minucias que nos apegamos são sempre postas à prova uma vez que o Design System está pronto.