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 ?
É 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.
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.
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.
Por isso, disponibilizamos alguns conteúdos mais completos que falam sobre gestão pública. Deixe o seu melhor e-mail para recebê-los!
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.
Existem 2 “linhas de frente” na criação de um design system, sendo elas:
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.
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:
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.
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 é 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).
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
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?
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.
Existem 2 “linhas de frente” na criação de um design system, sendo elas:
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.
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:
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.
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 é 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).
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
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?
