Orange DS

Orange DS, como surgiu meu primeiro Design System

Nat Kaweski
Inter UX Team
10 min readOct 22, 2021

--

Neste post vou trazer minha trajetória dentro do Design System do Inter Product Design, o Orange DS, e como foi minha visão de aprendizado até chegar onde estou hoje.

Spoiler alert: O post sobre migração de carreira ainda não escrevi, mas está pra nascer em breve, e logo coloco o link aqui para quem tiver curiosidade de saber como foi minha trajetória.

Background de Front-end Developer 👩🏼‍💻

Pra quem não me conhece, muito prazer eu sou a Nat Kaweski, sou formada em Ciência da Computação, me formei no final de 2020.

Eu trabalhava há 6 anos já como front-end developer e já tinha um ano como desenvolvedora no Inter no time de internet banking PJ, e foi quando surgiu a ideia de migrar pra área de design.

Mas pra quê isso hein?

Umas das coisas que eu sempre me dediquei muito foi a parte detalhista do front trabalhando especificamente com HTML e CSS. Eu ficava horas penteando layout, escrevendo e reescrevendo meus componentes em React/Angular com olhar muito crítico pro design, e o que milagrosamente sempre fez meu código se destacar aos olhos dos clientes, como algo que era fiel aos layouts propostos pelos designers com quem trabalhava.

A partir disso eu fui estudando Figma e as ferramentas mais complexas dentro dele, como Auto Layout, Variants, Version History, Constraints & Resizing, fui estudando um pouco de visual e prototipação também, me cadastrei em alguns challenges de UI na internet e fiz alguns cursos de design pela internet afora aí, além de ter estudado UX na faculdade e até na Alura no curso de carreira de UX/UI Design.

Primeiro contato com Design System

Com essa trajetória e esse desejo por trabalhar com a parte que me brilhava os olhos, o time de Product Design do Inter me proporcionou uma migração incrível de carreira, e eu me encontro com eles há mais de 1 ano.

Iniciei meu projeto trazendo uma solução legal que pretendo contar depois no post que farei sobre minha migração de carreira. 😊

A partir desse primeiro contato com o time de design, comecei a trabalhar com pessoas incríveis no time, sendo o Fabio Matsuda e o Cassius Fraga quem me proporcionaram essa migração de carreira.

Também fiz um trabalho em conjunto principalmente com o Célio Silva e o Cadu Braga, envolvendo nomenclatura de componentes, adaptação de componentes para uma utilização mais genérica e sempre pensando em organizações inteligentes dentro do Figma, seja em layouts, sortings ou até mesmo nas layers dos componentes.

Nós já tínhamos uma primeira biblioteca quando eu entrei no time, mas começamos a criar uma nova a partir da nova disposição da marca, foi quando realmente começou a nascer um novo Design System no Inter.

Outro passo importante que surgiu com a minha atuação no time de Design System (DS) foi o bloqueio das bibliotecas e liberação de edição somente pelo time de DS, versionamento os arquivos utilizando Version History do próprio Figma, evitando conflitos e alteração de componentes por qualquer pessoa do time de design.

Isso já trouxe qualidade pra dentro do nosso DS e trouxe um controle maior do time de DS sobre as bibliotecas.

Iconografia ✅

Além de todo esse processo inicial de introdução ao DS, foi me mostrada uma forma de criação e visual: a iconografia! Uma forma de ser simples e direta, trazendo para a parte visual o que a mensagem quer dizer a partir de um desenho simples.

Com isso nasceu um novo hobby, e criei toda uma biblioteca de variants com todas as variações possíveis de ícones dentro do nosso DS, a ideia é trazer simplicidade e trazer consistência na utilização dos tamanhos dos ícones.

Variants de ícones

Também foi feito um algoritmo que exporta todos os ícones em SVGs para facilitar o trabalho dos desenvolvedores front-end, que foi iniciado por mim no time de DS e finalizado pelo time de front-ends do Inter.

Organização dos componentes

Hoje a organização do nosso DS é estruturada com design atômico, um termo cunhado por Brad Frost, e que se baseia em pequenas partículas que juntas formam elementos maiores, e as nomenclaturas que utilizamos para nossas bibliotecas inicialmente foram baseadas em quarks, que juntos formam átomos, que por sua vez juntos formam moléculas, que juntas formam organismos vivos, os quais juntos formam fluxos inteiros.

Nos quarks colocamos vários conceitos que faziam sentido e formavam qualquer componente mais complexo dentro do nosso DS, são eles:

  • Espaçamentos múltiplos de 8px;
  • Famílias de fontes;
  • Cores principais e secundárias;
  • Logos do Inter;
  • Detalhes de bordas, ícones e coisas que são indivisíveis dentro da nossa estrutura.

A partir dessa organização, a gente separava entre biblioteca de componentes para Web e App, e lá dentro separávamos entre Átomos, Moléculas e Organismos de cada um.

Mais pra frente percebemos a necessidade de evoluirmos isso, mas vou deixar pra contar mais pra baixo. 🙃

Sobre o trabalho reativo

Um dos meus maiores enfrentamentos foi com a introspecção e timidez, eu tive que fazer encontros diários com os nossos product designers, a partir de calls, design critiques e outros ritos do nosso time.

Com isso pude aperfeiçoar minha comunicação e aprimorar minhas relações interpessoais, identificar o que cada designer precisava que o DS entregasse, e com isso criamos um fluxo de trabalho sob demanda.

Criamos um canal no nosso principal mensageiro, o Microsoft Teams, e centralizamos dúvidas, sugestões, bugs e anúncios do time em relação a DS, todas as demandas de DS dentro de um canal que apelidamos nada mais nada menos do que "Canal do Design System". 😋

A partir desse canal percebi a necessidade de aperfeiçoamento dos nossos componentes também, e a importância de criar componentes que fossem mais genéricos, e não tão elaborados e específicos para cada fluxo, já que hoje somos um Super App e atendemos a várias frentes e avenidas no mercado. Nesse momento eu estava trabalhando em par com o Lucas Reis — um abraço amigo! — e que me ajudou num período de crescimento do nosso Design System, e me deu vários insights de quais pontos precisávamos atacar primeiro antes de evoluir de fato nossas bibliotecas.

Precisávamos de uma capacitação dos nossos designers no uso do Figma e do nosso DS de forma inteligente.

Validação dos fluxos

Como já contei, uma da formas de validação do trabalho dos product designers era o formato de design reviews, onde eu validava o uso correto e esperado do nosso DS. Outros formatos de validação era como review de commits.

Mas do que isso se trata?

Basicamente cada designer precisava informar no nosso Canal de Commits qual projeto estava trabalhando, e como o DS poderia validar o seu fluxo.

E foi nesse momento em que começamos a encontrar um gargalo no time, o uso do Figma como principal ferramenta me fez perceber que precisávamos capacitar urgentemente nossos designers e ensinar no uso das ferramentas mais de smart layout a partir de Workshops, tutoriais e até a partir de links dos playgrounds do próprio Figma.

Foi bem interessante pois foram dados vários Workshops e o time de fato foi aprendendo a usar todos os formatos de organização do Figma, e hoje temos um time mais capacitado que utiliza nosso DS de forma inteligente e que consegue entender a necessidade de termos bibliotecas mais abrangentes e genéricas, além de facilitar o uso entre as várias avenidas, facilita a vida dos desenvolvedores quanto a reutilização de código que precisam implementar em cada fluxo.

Isso trouxe ganho de tempo, consistência nos fluxos, além de trazer mais agilidade e demandas mais robustas quanto ao layout, ao invés de olharmos para detalhes simples, estávamos agora atuando com demandas mais complexas que exigiam mais das nossas skills dentro do time.

Nasce o Orange DS 🍊

Com isso fizemos uma retrospectiva do design system no primeiro semestre e quanto de ganho tivemos no primeiro semestre com a evolução do nosso Design System, e criamos sua primeira versão entregue para toda empresa, e batizamos de Orange DS!

Origem do nome "Orange DS"

Foi um marco para o time de Product Design, ganhamos protagonismo, estávamos sendo mais consistentes nas entregas, e foi um grande upgrade no nosso DS pois, quando se dá nome, se cria, se evolui e se mantém.

Trabalho stand alone por um tempo

Por um bom tempo permaneci sozinha no Design System, nisso eu tentei atacar o máximo de demandas possível até encontrarmos uma equipe legal para adentrar o nosso time de DS.

Foi quando fizemos uma Aceleração de Design com o time da Dio, e a apresentação consistia de como funcionava nosso trabalho dentro do Design System, e além disso: mostramos como é fácil criar telas utilizando um design system robusto e completo, e nosso exemplo foi criar um Spotify utilizando componentes do nosso Orange DS, foi nosso momento mão na massa.

Adaptação do Spotify para um produto fake chamado Inter Music (fins de estudo).

Outra forma de trazer aprimoramento visual pro time foi sugerir uma forma de adaptação das nossas telas para versão Darkmode, esse mesmo estudo que fiz foi implementado por um time de desenvolvedores iOS. Recentemente foi feito um Hackaton dentro do time de T.I. — que consiste de um evento em que tinham 3 stacks a serem desenvolvidas: iOS, Android e Multiplataforma, do qual eu, Adalton Junio e Bruna Fragelli ganhamos o primeiro lugar, mas eu conto sobre esse projeto num outro post — mas o time de iOS adaptou meu estudo de Darkmode para as telas em iOS, e foi um sucesso! Eles ganharam em terceiro lugar, e aguardemos mais resultados dessas adaptações nos futuros projetos. 🙃

O time de Design System também foi responsável pelo refactor do novo Footer do site institucional, e recentemente do novo Header também. Foi feito estudo de análise dos dados coletados, teste de usabilidade, envolvimento das equipes, stakeholders, e todo o processo de descobrimento e criação de fluxo.

Footer do Site Institucional (www.bancointer.com.br)

Outra forma de atuação do Design System nesse meio tempo foi o trabalho em conjunto com outros desenvolvedores, sendo desenvolvedores Front-end, melhorando assim a biblioteca no Storybook, trabalhando com desenvolvedores Android e iOS, fazendo validação de fluxos e agindo na solução de componentes base.

Também estamos atuando com o time de Métricas (juntamente com a Adriana Tamie Akamine), fazendo o tagueamento de componentes base e averiguando os dados coletados a partir das plataformas de análise de dados. O foco desse processo é avaliar a usabilidade e verificar a interação dos usuários com nossos componentes mais básicos.

Fiz também um estudo de cores auxiliares das quais precisávamos para adaptação de fluxos que precisavam de cores além das que tínhamos como primárias e secundárias. Foi quando fiz um cherry pick no Material Design e criamos uma biblioteca auxiliar de cores, perfeitamente apelidadas com nomes de frutas para serem utilizadas dentro do nosso Orange DS.

Biblioteca de cores auxiliares

Entrada de novos colegas no DS! 🥳

Pausei depois de quase dois anos sem descansar e tirei minhas férias.

Foi quando tive minha primeira promoção na vida, dada graças a minha querida Thais Falabella que proporcionou a melhor gestão que já tive, trazendo caminhos incríveis para trilhar e oportunidades únicas que eu me senti realmente protagonista da minha carreira. Falarei melhor dela em outro momento quando for contar da minha trajetória dentro do design.

E enquanto estava de férias, outras duas pessoas ingressavam o time de DS para criarmos juntos o projeto que estamos dando vida hoje, um abraço especial para o Mateus de Paula Tomaz Santos e para o Lucas Castro. ❤️

Os dois têm olhares muito criteriosos pra acessibilidade, visual, ilustração, iconografia, white space, e entre outros, cada um com sua particularidade, e que tem servido de inspiração para deixar meu trabalho cada vez mais incrível quanto o deles.

Documentação

Com a entrada de novos olhares pro estava sendo criado por apenas uma pessoa até então — eu — , percebemos que nossa biblioteca estava excelentemente robusta, mas muito específica por se tratar de um Super App, haviam mais de 1000 componentes e styles nas nossas bibliotecas, o que criava mais gargalo dentro do DS pois estavam sendo utilizados muitos componentes.

Com isso, nós do time do DS resolvemos enxugar nossos componentes, além de simplificar a vida dos nossos product designers e desenvolvedores, e começamos a popular a nossa documentação com:

  • Anatomia dos componentes
    Informando os paddings, margins, spacings, fonte, border radius, etc.
  • O que pode fazer
    Aplicações em conjunto, sozinhos, quais layers poderiam ser ocultas, etc.
  • O que não pode fazer
    O que não poderia ser realizado na adaptação de cada componente, como layers que não poderiam ser ocultas, cores que não poderiam ser utilizadas, troca de fontes, etc.
  • Aplicação em fluxos
    Quais fluxos específicos aqueles componentes estava sendo utilizados, como adaptar no fluxo, como posicionar, etc.

Nova organização do Orange DS

A partir da documentação percebemos também que nossa biblioteca não parava de crescer, e a partir do momento que temos uma lib que já consistia de mais de 1000 componentes, porque continuava crescendo?

Foi quando percebemos que precisávamos criar componentes mais genéricos, mais robustos, que abrangessem todos as avenidas em que eram utilizados, prever utilização de novos componentes sem precisar ser reativo, e sermos mais proativos.

Foi quando adaptamos nosso design atômico para algo sem analogias trazendo a taxonomia de:

Foundation > Base Components > Components > Templates.

Além disso trouxemos bibliotecas que fariam sentido para avenidas que precisassem de bibliotecas "Not in DS", e denominamos como Exceptions & Helpers.

Próximos passos

Enfim, hoje nos encontramos num Design System que precisa de mais olhar crítico para a "robustês", enxugar o que se pode fazer, criando componentes e adaptando os já existentes para simplificação, escalabilidade e adaptação para os mais variados cenários.

O foco hoje do nosso trabalho é ser mais proativo e menos reativo como tava sendo lá no início, com isso evoluímos com um DS mais maduro e que tem acompanhado o time de product designer também.

Também estamos contratando desenvolvedores para nosso time de Design System, hoje contamos com um Front-end Developer, em breve vamos trazer outras stacks como iOS e Android developers, QA e P.O.

E é isso! Espero que esse post seja de grande valia, mas principalmente dizer que um Design System é um produto que está sempre em evolução.

Assim como analogia que utilizamos antes, acredito que o DS é vivo ainda, por isso sofre grandes mudanças constantemente, sempre evoluindo junto com o time, principalmente porque o time também evolui.

Não esquece de dar 👏 pra continuarmos evoluindo e crescendo.

--

--

Nat Kaweski
Inter UX Team

Senior Design System Ops, Visual Designer, Interaction Designer, Front-end Developer, UX/UI Designer https://kawe.ski