Sobre Design System
Uma exploração teórica sobre design systems.
O bom design é um ato de comunicação entre o designer e o usuário.
Don Norman
A ideia geradora do Design System, de componentes que otimizam o desenvolvimento, foi apresentada por Douglas McIlroy nos anos 1960. O matemático propôs o desenvolvimento baseado em componentes para solucionar a crise dos softwares, conceito que foi posteriormente desenvolvido por Brad Cox nos anos 1990, propondo os componentes de software modernos (Bose) A ideia central é otimizar a programação de softwares pelo uso de códigos reutilizáveis, facilitando a escalabilidade de produtos, diminuindo o esforço e aumentando a velocidade do desenvolvimento (designbetter.co).
Hoje, com o aumento da demanda por design no desenvolvimento de produtos digitais, essas mesmas necessidades — rapidez e escalabilidade — se mostram essenciais para os esforços em design. Isso porque, como coloca Anne, design ainda é feito sob medida, soluções específicas para problemas individuais. “Mesmo com mais mãos trabalhando mais rápido, a realidade é que o design sob medida simplesmente não é escalável […] é lento, inconsistente e cada vez mais difícil de manter ao longo do tempo” (designbetter.co).
É cada vez maior o investimento em design, pelo reconhecimento de que a “experiência do usuário […] oferece vantagem competitiva, atrai e retém clientes, e reduz custos com suporte” (designbetter.co). Em função dessa demanda, é proposta a adaptação do sistema modular às necessidades de design, o Design System. Este é “um conjunto de padrões para gerenciar o design em escala, reduzindo a redundância e criando uma linguagem compartilhada e consistência visual em diferentes páginas e canais” (nngoup.com).
Design system é “um conjunto de padrões para gerenciar o design em escala, reduzindo a redundância e criando uma linguagem compartilhada e consistência visual em diferentes páginas e canais” (nngoup.com)
A proposta traz componentes e padrões de design reutilizáveis que possibilitam práticas escaláveis, garantindo a padronização de projetos. Componentes, nesse contexto, são “porções de código reutilizável […] que servem como blocos de construção da interface de aplicativos […] [variando] em complexidade” (designbetter.co). E quanto mais reutilizáveis forem, mais fácil sua manutenção.
Componentes padronizados, ao serem usados de maneira consistente e recorrente, criam aplicativos previsíveis e de mais fácil compreensão. Também, por se tratar de blocos reutilizáveis, designers podem focar na experiência do usuário, ao invés de pensar repetidamente estilos, espaçamentos, etc. E, adicionalmente, como resultado da otimização do tempo, é possível a construção de diversos protótipos e variantes, possibilitando a experimentação e agilizando a ideação e, em consequência, o ganho de dados e insights.
Apesar de existirem boas razões para não fazer uso de um DS, entre elas o fato de que criar e manter um é atividade demorada que requer uma equipe dedicada; de que leva tempo para ensinar os outros como usar; além da possível percepção de que os projetos são criações estáticas e pontuais, que geralmente não requerem componentes reutilizáveis. No entanto, há também boas razões para se aplicar um DS:
· O trabalho de design (e desenvolvimento) pode ser criado e replicado rapidamente e em escala.
· Alivia a pressão sobre os recursos de design para se concentrar em problemas maiores e mais complexos.
· Cria uma linguagem unificada dentro e entre equipes multifuncionais.
· Cria consistência visual entre produtos, canais e departamentos (potencialmente isolados).
· Pode servir como uma ferramenta educacional e referência para designers de nível júnior e contribuidores de conteúdo.
Para que o DS seja útil e utilizado, é importante criar alinhamento entre times. Isso é alcançado pelo compartilhamento de uma fonte de verdade — uma referência oficial de padrões e estilos. Por se tratar de um documento vivo, que é atualizado com frequência e precisa necessariamente ser acessado por várias pessoas com facilidade, é costumeiro utilizar o formato hipertexto para publicá-lo. Esses sites de DS documentam todos os aspectos do sistema, incluindo componentes, regras e melhores práticas de UX. É fundamental que esteja sempre atualizado.
O uso de DS auxilia também na fase de desenvolvimento. Em função da consistência que ele possibilita, diminui-se também o número de elementos únicos a serem codados. Assim, evita-se o desenvolvimento de CSS e JavaScripts conflitantes, o que não só pode levar a quebras no app, mas também potencialmente aumenta o peso de páginas e a carga cognitiva, o que afeta diretamente o usuário. Ao construir uma biblioteca de componentes, a consistência é garantida e, em consequência, horas perdidas em controle de qualidade, revisões e refações (designbetter.co).
São três as possíveis abordagens à adoção de DS: 1) adotar ou 2) adaptar um DS existente, ou até mesmo 3) criar um próprio. A escolha depende de quanto tempo e recursos se tem para investir. É possível, também, passar de um modelo ao outro, de forma progressiva. Basta saber que esta é uma solução comprovada e confiável.
Essa é uma breve revisão de literatura sobre Design System. Como o próprio DS, é um documento vivo, que pode ser atualizado a qualquer momento. Colaborações são bem vindas.
