Design System — Arrumar as peças de Lego
Um design system é um sistema de agregação, catalogação e documentação de componentes. Visa servir toda uma organização com o objectivo de melhorar a consistência, a comunicação e o tempo de desenvolvimento dos projectos. Isto não só permite uma grande melhoria de desempenho das equipas como abre espaço para maior foco naquilo que realmente importa para os produtos digitais, serem úteis e fáceis de utilizar.
Como frequentemente mencionado, os design systems são muitas vezes equiparados a peças de lego. Isto deve-se ao seu carácter modular, que permite construir toda a forma de conteúdos (tal como as peças de Lego).
Vimos no meu último artigo uma descrição pormenorizada sobre o que é um design system. Nele esclareci alguns termos que poderiam causar alguma confusão e ainda as razões porque é importante a sua implementação. Desta vez, vou falar sobre como, de facto, levar a cabo esta implementação. O que é necessário fazer para começarmos a trabalhar? Para isso, vou-me socorrer do Brad Frost e da Nielsen Norman Group para sintetizar num único artigo tudo o que é necessário para arrancar com este projecto.
Por onde começar?
Existem três formas possíveis de abordar a adopção de um design system:
- Adoptar um já existente
- Adaptar um já existente
- Criar um próprio de raíz
Cada uma das opções tem as suas qualidades e limitações. No entanto, de uma forma geral quanto mais personalizado um design system é, mais tempo e dinheiro será necessário para o implementar. Esta opção é mais interessante se a organização tiver necessidades específicas que não podem ser correspondidas por design systems open source. Adaptações e personalizações a um design system já existente vão acabar por comprometer a poupança que se possa conseguir ao usar um pré-feito.
Não esquecer que um design system completo não irá gerar o ROI desejado no curto prazo. Uma vez que a principal mais valia deste sistema é a sua capacidade de replicar trabalho já feito, os ganhos daí inerentes só serão perceptíveis no médio e no longo prazo. Este não deve ser visto como um portfolio de trabalhos feitos mas sim como uma ferramenta de aceleração do trabalho dos designers e developers.
Em caso de dúvida sobre a implementação de um design system, pode ser útil considerar o intervalo de tempo em que este será utilizado. Os design systems funcionam melhor quando as empresas prevêem a necessidade de componentes replicáveis ao longo de anos.
Auditoria Visual
Fazer uma auditoria visual dos produtos já existentes é um passo crucial. A ideia aqui é termos um inventário dos conteúdos do nosso produto/plataforma. No fundo é um aprofundado compêndio de todas as peças que compõem um interfaces.
De acordo com Brad Frost, podemos decompor a auditoria visual em 4 fases:
1. Reunir uma equipa multidisciplinar
Reunir numa sala Designers, Developers, Project Managers, Business Owners, Quality Assurance, etc., no fundo qualquer pessoa que tenha contacto com a experiência. Serão estas as pessoas que irão conduzir esta auditoria. No fim de contas, um dos principais resultados deste exercício é o de estabelecer um vocabulário partilhado por todos na organização. Isto só se consegue com a participação de todos os responsáveis por essa comunicação.
2. Preparar os screenshots
Este é um exercício que recorre fortemente a screenshots. É irrelevante a ferramenta que se use desde que se convencione uma plataforma comum para colocar as imagens. Ferramentas de whiteboarding são particularmente úteis para este exercício. Algumas das mais populares são:
3. Capturar e organizar screenshots
Esta é a fase em que vamos documentar, nomear e categorizar todos os componentes e padrões em toda a plataforma.
Deve-se começar por tirar screenshots de todos os componentes existentes. Títulos, blocos de texto, radio buttons, carousels, accordions, tabs, imagens, icones, video players, infografia, etc., mesmo tudo. De notar que a ideia não é inventariar todas as instâncias dos componentes mas sim aqueles em que existem variações.
Pode ser boa ideia separar as pessoas em pares e atribuir-lhes categorias de componentes. Outra sugestão a de definir limites de tempo para a tarefa, 30 a 90 minutos deverá ser suficiente.
Rapidamente tornar-se-á evidente que existem muitos conjuntos de componentes que ou não têm nomes ou têm nomes que entram em conflito uns com os outros.
Sugestões de categorizações
Ainda que possam variar muito de experiência para experiência, Brad Frost faz algumas sugestões:
- GLOBAIS
Coisas comuns a toda a plataforma, tal como headers e footers. - NAVEGAÇÃO
Tudo aquilo que, na plataforma, seja usado pelo user para navegar na página. Estamos a falar de navbar, paginação, breadcrumbs, navegação no footer, etc. - TIPOS DE IMAGENS
Qualquer tipo de pattern único que contenha imagens. Logos, imagens de hero, avatars, thumbnails, backgrounds, etc. - ÍCONES
Um tipo especial de imagem que, devido ao facto de, normalmente, ser uma biblioteca de grandes dimensões, vamos considerar aqui em separado dos restantes tipos de imagens. - FORMULÁRIOS
Todos os componentes integrantes de um formulário web. Input fields, text areas, menus de seleção, checkboxes, toggle buttons, radion buttons, sliders, etc. - BOTÕES
O componente mais comum e básico de um design. Registar todos os botões nos seus diversos estados e tamanhos. - HEADINGS
Esta é uma categoria desafiante. Queremos registar todos os títulos (h1, h2, h3, h4, h5, h6) existentes mas a distinção entre títulos e destaques, por vezes, esvanece-se. - TEXT BLOCKS
Pensemos nisto como um organismo. De acordo com o conceito de Atomic Design, um organismo é composto por títulos, imagens e/ou texto. Ao possuirmos organismos pré-feitos com estes blocos conseguimos poupar muitas linhas de código. - LISTAS
Qualquer coleção de elementos organizados na forma de lista. - COMPONENTES INTERATIVOS
Accordions, tabs, carousels e qualquer outro módulo que requeira interações semelhantes. - MEDIA
Players de vídeo, som ou elementos de rich media. - TERCEIROS
Tudo aquilo que não esteja alojado no domínio do site. Widgets, iframes, botões sociais, etc. - PUBLICIDADE
Uma categoria especial de elementos terceiros que inclui todos os formatos de anúncios. - MENSAGENS
Mensagens de alerta, sucesso, erro, avisos, validação, progresso, popups, tooltips, 404, etc. Todas as mensagens direcionadas ao utilizador. Isto pode ser desafiante uma vez que requer considerável interação com o site. Isto pode levar a que, por exemplo, seja necessário provocar erros deliberadamente para conseguir aceder a determinados tipos componentes. - CORES
Capturar todas as cores existentes na plataforma. Ferramentas como CSS Stats e Stylify Me podem ser muito úteis para esta tarefa. - ANIMAÇÕES
Esta categoria é especial uma vez que não se conjuga com a captura de uma imagem estática. No entanto, existem várias opções gratuitas online para fazer este tipo de capturas.
De recordar que estas categorias não estão fechadas e podem ser adaptadas conforme a necessidade e métodos de organização.
No final, todos estes registos são passados para uma ferramenta de whiteboarding e agrupadas em clusters. O objectivo é ser possível ver todas as versões de cada componente lado-a-lado.
Feito isso, chega a hora de dar nome a estes grupos. Rapidamente tornar-se-á evidente que existem muitos conjuntos de componentes que ou não têm nomes ou têm nomes que entram em conflito uns com os outro. O desafio será trazer ordem a esse caos.
4. Findings
O processo de capturar e categorizar screenshots pode ser exaustivo e cansativo, pelo que esta será uma boa altura para fazer uma pausa antes de avançar.
Depois de regressados da pausa, entramos na fase do cruzamento e apresentação do trabalho dos pares. 10–15 min por categoria deverá ser um período razoável para apresentar as conclusões e as decisões tomadas ao grupo. É nesta fase que a equipa pode começar a discutir as convenções dos nomes. É também aqui que se nota uma maior diferença dos modelos mentais entre designers, developers e product owners. Estes tendem a dar nomes diferentes para as mesmas coisas.
No final o orientador do exercício ficará encarregue de juntar e organizar todo o material produzido num único documento.
Porquê todo este processo de descontruir e catalogar toda uma interface? Os beneficios são vários:
- Cria boas bases para um bom design system
- Demonstra visualmente a necessidade de um design system
- Promove a consistência
- Garante que todos os componentes são contabilizados
- Maior facilidade em adaptar os componentes para serem responsive
O documento resultante deste exercício pode ser partilhado dentro da organização. Em particular, pode funcionar como forma de sensibilizar os stakeholders para a necessidade de investir num design system. Já que, ao tornar tão evidentes as disparidades e inconsistências, torna-se mais percetível essa necessidade.
A imagem a baixo demonstra o nível de inconsistências que pode existir entre botões com as mesmas funções. Tudo isto advém do facto de, nesta empresa de exemplo, todos os botões terem de ser reconstruídos a cada utilização.
Começar a construir o Design System
Feita a auditoria visual e garantido o apoio dos stakeholders, o restante processo torna-se mais simples uma vez verá menor resistência dentro da organização.
Criar uma Linguagem Visual de Design
A linguagem visual de design é algo nuclear de um design system. Estamos a falar da informação que geralmente se encontra na área de fundamentals de um design system. São aquilo a que Brad Frost chama de ‘átomos’ no seu livro Atomic Design. Quando falamos em linguagem visual de design, normalmente referimo-nos a:
- Cores
- Tipografia
- Medidas e espaçamentos
- Imagens
- Tom de voz
- etc.
Criar uma Biblioteca de Componentes
Ao contrário da auditoria visual, a qual olhou para as qualidades dos elementos, este passo visa olhar para todos os componentes atualmente em produção. O objectivo é juntá-los todos e descartar os desnecessários. Aqui o critério importante é ter o menor número de variações possíveis por componente e que cada variação tenha uma sólida razão de existir.
Uma rápida pesquisa online por alguns dos principais design systems, permite-nos encontrar alguma inspiração sobre como organizar esta biblioteca. Deixo aqui alguns exemplos:
- Material Design — Google
- Carbon Design System — IBM
- Spectrum — Adobe
- Atlassian Design System
- Lightning Design System — Salesforce
- Polaris — Shopify
- Fluent — Microsoft
- Swarm Design System — Meetup
- GEL — BBC
Documentar Cada Componente
Este passo é particularmente importante já que esta é uma das principais valências de um design system. É importante documentar o que cada componente é, como o utilizar e como não o utilizar. Poderá também ser útil mostrar exemplos de como é aplicado. No fundo, a ideia é ter uma espécie de manual de instruções para cada componente.
De uma forma geral, a documentação de cada componente costuma possuir as seguintes informações:
- Overview
O que é o componente e para que serve - Quando usar
- Quando não usar
- Anatomia
Quais são as áreas que constituem o componente e como se chamam. - Medidas e espaçamentos
Todas as medidas necessárias para construir o componente. Qual a sua altura e largura, qual o valor das margens e paddings, a que distância deve ficar dos componentes circundantes, etc. - Variações
Os componentes podem ter diversas variações. Um botão pode ter uma apresentação para a cor primária, secundária, terciária, para casos de erro, etc. É aqui que se apresentam todas essas variações, se lhes dá um nome e se explica para que serve e quando cada uma deve ser usada. - Estados
É comum os componentes possuirem diversos estados diferentes consoante a interação de que estão a ser alvo. Os links, por exemplo podem possuir cinco estados diferentes:
• Ativo – Pronto a ser utilizado
• Hover – Quando o cursor do rato lhe passa por cima
• Focus – Quando o utilizador clicou no botão do rato mas ainda não o largou
• Visitado – Depois de o link ter sido utilizado
• Disabled – O link existe mas não está acessível de momento - Comportamento
Uma descrição dos comportamentos permitidos e não permitidos, como é que o componente reage quando determinadas condições lhe são impostas (por exemplo, até que largura é que um botão pode crescer e qual é a sua largura mínima) - Live-Demo
Muitos design systems apresentam uma versão interativa do componente onde podem ser observadas as animações e como se dá a interação. No entanto, design systems mais simples e limitados podem apresentar apenas uma imagem estática. - Exemplos de utilizações
Alguns exemplos comparativos de situações em que é previsível que possam existir erros. Como por exemplo, demonstrar que um botão só pode existir isolado ou agrupado lado-a-lado mas que não deve ser usado empilhados em colunas. Ou então que determinadas cores não devem ser utilizadas. - Considerações de acessibilidade
Quais os cuidados a ter ao nível da acessibilidade. Isto geralmente costuma debruçar-se sobre as medidas do objecto, cores e considerações ao nível do código. - Snippets de Código
Cada componente deve ser sempre acompanhado da sua respectiva versão em código. Uma vez que esta informação é do interesse dos developers, é também importante fazer-lhes saber em que frameworks está o componente desenvolvido e oferecer os respectivos snippets de código para cada framework.
Tratar o Design System como um produto
E pronto, este é o método recomendado por Ben Frost e Nilesen Norman Group para dar os primeiros paços na construção de um design system.
Importa recordar que construir um design system é um processo de médio prazo e que, como tal, deve ser encarado como se de um produto se tratasse. Como tal, o design system necessita de um gestor de produto (geralmente um design lead ou um UX lead dentro da organização), necessita de um backlog, um road map e de ser mantido.
Design systems que não são tratados como produtos, em ultima instância, vão acabar como produtos descontinuados. Tornar-se-ão estagnados, datados, deixarão de incluir as melhores práticas e deixarão de acompanhar com os standards da indústria.
Paulo Dias
Designer UX/UI
pdias@innovagency.com
LinkedIn: https://www.linkedin.com/in/pauloshdias
INNOVAGENCY
Living the digital world
www.innovagency.com
