100%
14.10.2020

Design systems: Motivação, relevância e uso no Colab

Você sabe o que é um design system? Para quê ele serve? O Gabriel Eloy explica tudo sobre o assunto neste artigo, além de contar como nós do Colab utilizamos esta ferramenta.

Já reparou que quando tratamos dos produtos digitais de algumas marcas, reconhecemos a quem esses produtos pertencem só de olhar para eles ?

Observe as duas imagens a seguir:


Mesmo que o conteúdo das páginas seja tremendamente diferente, ao analisar ambas, é possível inferir que essas 2 páginas estão relacionadas de alguma maneira. Mas por que isso acontece ?

#Linguagem Visual

É extremamente benéfico para uma marca possuir uma linguagem visual e de funcionamento, já que elas servem ao propósito de criar padrões de uso para os produtos dessa organização. O que significa que

Na prática, quanto mais uma pessoa usa um determinado produto de uma marca, mais intuitivo será para ela usar não só a ferramenta na qual está inserida, como todos os demais produtos pertencentes à mesma marca.

E isso é importante devido a um conceito chamado reserva de boa vontade, explicado no excelente livro Não me faça pensar, de Steve Krug.

De maneira extremamente simplificada, a reserva de boa vontade pode ser definida como quanta paciência o usuário de uma aplicação tem para consumar seu objetivo nela. Quanto mais complicada e confusa for a jornada do usuário, mais a reserva de boa vontade do usuário vai se esvair, e maior a chance de que ele deixe a sua aplicação.

Um dos principais objetivos de um design system é tornar toda a experiência do usuário mais intuitiva e coerente, estabelecendo regras simples para os produto da marca e respeitando-as, criando assim uma padronização, que facilita o uso e entendimento de todas as aplicações lançadas por ela.

Um dos principais objetivos de um design system é tornar toda a experiência do usuário mais intuitiva e coerente, estabelecendo regras simples para os produtos da marca e respeitando-as, criando assim uma padronização, que facilita o uso e entendimento de todas as aplicações lançadas por ela.

Como dito por Karin Saarinen, em seu artigo Building a Visual Language - Behind the scenes of our new design system:

“O design sempre foi principalmente sobre sistemas e como criar produtos de forma escalável e repetível. De cores Pantone a parafusos Philips, esses sistemas nos permitem gerenciar o caos e criar produtos melhores. Os produtos digitais são talvez o terreno mais fértil para a implementação desses sistemas e, no entanto, nem sempre são considerados uma prioridade.”

E assim como nas cores Pantone, ou nos parafusos philips, os benefícios de um design system não estão apenas na praticidade para o cliente final, mas também no barateamento da produção de produtos.

#Como um design system pode baratear uma aplicação ?

Certa vez eu ouvi a seguinte frase:

“Entre brincar com código no seu computador, e trabalhar numa aplicação comercial, existe uma diferença de complexidade gigantesca“

E eu não poderia concordar mais. Quando tratamos de aplicações comerciais, onde qualquer detalhe impacta diretamente nos resultados do serviço oferecido (quer você perceba ou não) o grau de cuidado que tem de ser tomado em toda e qualquer decisão é muito maior.

  • É importante que a aplicação seja acessível, e isso levanta questões do gênero: Como uma pessoa daltônica vai interagir com o que eu estou construindo? Como uma pessoa cega vai interagir com o que eu estou construindo?;
  • É importante que a aplicação seja responsiva, e para isso devemos pensar no funcionamento da aplicação em celulares e computadores;
  • A aplicação deve ser veloz, e deve existir uma preocupação em garantir que ela funcione bem em conexões de baixa velocidade (como redes móveis, por exemplo);
  • Entre outros diversos cuidados que devem ser tomados.

E essa complexidade deixa a construção de todos os componentes de um sistema muito mais custosa do que ela pode parecer de fora, tornando assim o processo de desenvolvimento caro, especialmente em caso de organizações que, assim como o Colab, possuem diversas aplicações, já que sem um sistema inteligente de regras para a reutilização de esforços, pode-se cair na armadilha de resolver o mesmo problema várias vezes.

Também é importante considerar que como o design de software tem poucas restrições físicas em comparação com muitas outras disciplinas. Isso faz com que a variedade de soluções possíveis para qualquer desafio sejam abundantes, o que pode gerar experiências de uso desconexas entre aplicações de uma mesma marca. Além disso, ao ter a mesma solução recriada várias vezes por pessoas diferentes, aumentamos o risco de que algumas dessas implementações possuam defeitos, o que pode fazer com que a mesma solução funcione melhor em alguns lugares do que em outros.

Por exemplo, digamos que dentre todas as aplicações de uma organização, tenhamos 6 tipos de botões, distribuídos em 6 aplicações diferentes. Se o botão da aplicação 1 apresenta um determinado defeito, teremos de testar os botões das outras 5 aplicações em busca do mesmo erro, e corrigi-los individualmente.

Com a ajuda de um design system (equipado com as ferramentas corretas) é possível evitar esse problema, unificando e centralizando as diferentes partes que compõe o sistema em um único lugar.

Isso não só torna muito mais fácil rastrear e localizar problemas, já que tendo um único botão que é utilizado em 6 componentes diferentes, só temos que nos preocupar em corrigir o problema, mas também evita o trabalho de construir os mesmos componentes básicos várias vezes para cada aplicação nova.


Aqui no Colab adoramos inovar na gestão pública!

Por isso, disponibilizamos alguns conteúdos mais completos que falam sobre gestão pública. Deixe o seu melhor e-mail para recebê-los!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

#Mas o que é um design system ?

Até esse momento o termo design system foi muito utilizado neste artigo, mas afinal de contas, qual é a definição desse termo?

Embora as definições tendam a variar dependendo de quem está dando essa resposta, a minha definição favorita foi dada por Emma Wedekind , na palestra Foundations of Design Systems, em 2019, na qual ela prega que um design system é constituído de 4 elementos principais:

Vamos abordar cada um deles brevemente.

#Linguagem de design (Design language)

  • Basicamente, compreende os fatores de linguagem visual de uma marca, como tipografia, relação de escalas entre os componentes visuais  etc. Mas também vai além disso, abrangendo Padrões de animação e comportamento da página.

#UI Kit

  • Um UI kit (sigla em inglês para “kit de interface do usuário” ou, User Interface kit, em inglês) é uma coleção de componentes e recursos gráficos que são usados dentro de uma aplicação. Exemplo: Quais os tipos de botões e as suas variações que são usadas na aplicação?

#Biblioteca de componentes (Component Library)

  • Similar ao UI Kit, com a diferença que ao invés de recursos gráficos, a biblioteca de componentes é constituída de códigos que podem ser facilmente reutilizados.

#Guia de estilo (Style guide)

  • Um guia de estilo é um documento que fornece diretrizes para a forma como sua marca deve ser apresentada de uma perspectiva gráfica e de linguagem. Então, além de compreender alguns fatores já explicados pelos itens anteriores, um guia de estilo também define como uma marca se porta e se comunica com os seus clientes, detalhando qual o padrão de vocabulário usado  etc.

#Como Criar um design system ?

Existem 2 “linhas de frente” na criação de um design system, sendo elas:

#Parte Conceitual

A parte conceitual, que engloba o que deve ser feito. Qual será o padrão de comunicação da marca? Como será a aparência dos componentes? Qual o comportamento deles?, entre outras preocupações de design.

Além disso, nessa fase também é importante se preocupar com a parte ferramental da construção dos conceitos definidos.

#Escolha das ferramentas

Embora possa parecer apenas um detalhe, a escolha das ferramentas para a construção de um design system é uma parte fundamental para seu processo de construção. A escolha das ferramentas certas (conjuntamente com outros fatores) torna o projeto fácil de manter e de utilizar. Se o projeto for fácil de utilizar e manter, ele estará resolvendo um problema, logo será utilizado pelos times responsáveis pela construção dos produtos. Caso contrário, ele estará criando mais problemas e mais complexidade, e em pouco tempo o design system provavelmente será abandonado.

Algumas das principais questões que devem ser respondidas para escolher uma ferramenta nesse contexto são:

  • Que vantagens essa ferramenta me traz e quais os custos agregados dessas vantagens?
  • Como essa ferramenta se integra às tecnologias que são utilizadas atualmente nos projetos?
  • Como essa ferramenta se integra às tecnologias que estamos estudando adotar futuramente ?

#O case da colab

Respondendo a todos os questionamentos levantados pelo artigo, afunilamos a escolha das tecnologias que faziam sentido para o nosso case a 2 “competidoras”, que apresento a seguir.

#Storybook

O Storybook é um ferramenta que prepara um ambiente de desenvolvimento para componentes de UI. Ele permite que você desenvolva e projete suas interfaces gráficas de forma rápida, isolada e independente. Além disso, o ambiente isolado de desenvolvimento do Storybook acaba servindo como uma forma de documentação para os componentes desenvolvidos, já que podem ser testados visualmente dentro do ambiente do storybook.

#Bit


Bit é uma ferramenta CLI de código aberto que visa aumentar ao máximo a reutilização de código entre projetos, de maneira que estes são facilmente salvos, importados, editados e sincronizados entre diversos projetos.

Seus componentes bit podem ser hospedados em 2 ambientes diferentes, sendo eles:

Caso você escolha um servidor próprio, o Bit não possui nenhum tipo de interface gráfica, restringindo seu escopo de atuação apenas ao controle dos componentes utilizados como dependência

O servidor padrão do bit, por outro lado possui uma interface muito similar à do Storybook, de maneira que é possível interagir com os componentes, vê-los em ação de maneira isolada, e para completar, ainda possui suporte à markdown, que pode ser usado para documentar o componente.

Como se isso não bastasse, o servidor do bit possui um CI que sobe seus componentes para o npm, de modo que você pode decidir se quer importar os seus componentes bit utilizando a CLI do bit, ou um gerenciador de pacotes (npm,yarn).

#Qual foi a escolha final e por que ela ?

Apesar dessas duas ferramentas poderem ser usadas em conjunto, as vantagens oferecidas pela solução do bit cumprem os 2 requisitos primordiais para o case da Colab. Esses requisitos são

  • Fácil reutilização de componentes entre projeto
  • Esse é a força principal do bit e é uma feature que não está dentro da proposta de projeto do storybook. Isso por si só já seria o suficiente para usarmos o bit, mas se não fosse o próximo item da lista, provavelmente utilizaríamos uma solução híbrida entre ele e o Storybook, e não apenas o bit;
  • Ao utilizar o servidor do bit, a documentação e visualização dos componentes se torna possível
  • Dessa maneira, todos os componentes podem ser vistos, entendidos, documentados e utilizados isoladamente.

E após entender do que se trata o Design Systems e como ele influencia na vida do usuário, conta pra gente: quais são as aplicações você utiliza que são um exemplo de design system bem sucedido?


Gabriel Eloy

Sobre o autor

Desenvolvedor Full stack no Colab, apaixonado por dar vida a produtos que impactem a vida das pessoas e conhecer pessoas incríveis no meio do caminho. Também acredita que "Você é tão grande quanto a sua vontade de mudar o mundo".