Há alguns meses venho sentindo essa pulsão criativa. Essa vontade de fazer arte real, de escapar do jeito como a tecnologia funciona hoje.

Sinto uma necessidade real de não burlar qualquer passo do processo. Sinto que vivo e só faço o que eu acredito. Do contrário, eu seria simplesmente “poser”.

Criei na minha cabeça uma nostalgia pura do que já me fez muito feliz, um espaço que eu ocupava e pertencia. Eu podia ser quem eu era naquele momento e eu estava ali. A tecnologia era feita pra ajudar, e não pra te supervigiar.

A internet era quebrada e a gente gostava mesmo assim. Bugs viravam features em cada lugar, e exigia de pensamento crítico e criativo, tanto pra quem usava quanto pra quem criava.

Os emoticons, por exemplo, representavam algo: você, ou algo ou alguém. Decorava-se os que mais se usavam. Havia intenção de procurar como representar as coisas com caracteres especiais.

Enfim, tô falando tudo isso no auge do meu privilégio, com um saudosismo que vai além de uma nostalgia burra. Ele percorre desde o desespero de não estar aguentando mais até a vontade de tentar trazer o sossego de volta.

E não é só saudade. Tem gente sofrendo de verdade com o rumo que essa tecnologia tomou. Como casos extremos onde a inteligência artificial pode ser responsabilizada pelo suicídio, desde adolescentes a adultos.

Não foi pra isso que jurei usar meu conhecimento pro bem da sociedade lá na faculdade de Ciência da Computação quando me formei, e eu real tô aqui é pra ajudar.

Não que alguém precise desse tipo de ajuda, quanto mais a minha, mas decidi fazer algo com todo esse desconforto, e que quero contar neste texto.

­

O movimento

Juntei tudo que sei, pesquisei sobre os temas do meu interesse, aprendi várias coisas novas, listei o que mais quero aprender, anotei e redigi minhas reflexões e textos, joguei tudo numa sopa e criei o Yorgute. Você pode ver mais detalhes do projeto no meu portfólio.

Hoje o Yorgute é meu ponto de partida da nostalgia da internet como memória que quero trazer de volta pra mais gente além de mim.

­

O processo

Uma coisa que eu não queria era que isso virasse só nostalgia bonita de gente que acha que “antigamente era melhor”. Então li um tiquin.

Fui atrás da Raquel Recuero que estudou o Orkut, weblogs e fotologs lá atrás, quando ninguém ainda tratava rede social como objeto sério. Encontrei ela numa pesquisa sobre rede social desde lá atrás até hoje em dia. Ela não sabe, mas me ajudou a entender que o que eu sentia falta tinha nome: laços e pertencimento.

Não era só a interface que fazia a gente feliz, era o tipo de vínculo que ela permitia. E a limitação gerava mais pertencimento, porque o controle tava na sua mão de toda forma.

Li o livro Nexus, do Harari, pra entender como a informação vira poder e como os sistemas que a gente cria acabam nos moldando de volta. Li sobre os ladrões de atenção da vida moderna, esse projeto todo de te aprisionar na tela o máximo de tempo possível.

Li também coisas mais duras: estudos sobre o impacto das redes sociais na saúde mental de adolescentes. Não dá pra fingir que isso não existe. É parte de por que o Yorgute precisa ser diferente.

E teve um caminho mais esperançoso: as redes comunitárias — essa ideia de que dá pra construir internet de baixo pra cima, com a gente mesmo, sem depender das plataformas gigantes de bilionário que você já sabe quem é, e isso me deu muito gás.

Não tô falando tudo isso pra parecer inteligente ou me gabar de alguma coisa (sou muito preguiçosa!). Tô citando porque cada leitura dessas foi um “ah, então não sou só eu”.

Cada uma virou um pedaço aqui no Yorgute: sem algoritmo manipulador, sem feed infinito; texto e memória primeiro, e uma linguagem que é a nossa mesmo, brasileira 🇧🇷. Não ficou só na ideia e no desconforto.

­

O que construí até aqui

Em poucos meses, o Yorgute saiu do papel e virou uma rede social viva, que muda quase toda semana (sim, eu tô “onfire”).

Cada versão foi uma escolha pequena de como essa internet deveria ser, no meu achismo. E agora fica um resumo do caminho:

­

Os primeiros espaços vivos (versão beta em maio)

Os Espaços (que são nossas “comunidades”) e a Boca do Povo (que é nosso “xwitter”), o coração social do Yorgute, ganharam vida. Entrar numa conversa, seja num espaço ou na sua região, ficou simples: digita, aparece, responde.

Darkmode em junho (e versão oficial saindo do beta)

Foram duas semanas intensas! Aproveitei as férias pra trazer melhorias pra plataforma. Chegou o Darkmode (você escolhe, o Yorgute lembra), um calendário de atividades que é quase um diário de participação (igual no GitHub, sabe?), o perfil repaginado, a busca em qualquer página com filtros mais inteligentes, e esta própria página de Novidades, feita pra contar tudo que muda por aqui sem linguagem técnica.

­

Cole um link e ele vira anexo

Vídeo do YouTube, faixa do Spotify, imagens, link de qualquer site, GIFs do Giphy e outros. É só colar no comentário que o Yorgute reconhece e monta a prévia, tocando ali mesmo. Até quatro coisas lado a lado, na Boca do Povo e nos fóruns também.

Parece pouca coisa, mas pra mim, sozinha, foi um avanço danado!

Mais rápido e mais resistente

Troquei toda a base de dados por baixo dos panos. Foi o maior ganho até agora, na minha opinião! Carrega mais depressa e não cai mais nos picos de acesso, tipo quando rola uma campanha.

­

Notificações mais claras e o caderninho

Ao abrir as notificações, você vê só o que é novo, separado do que já viu por dia. E chegou o Caderninho, um baralho de palavras nossas de cada dia: iogurte virou yorgute, e ainda tem trabaiá, uai, pobrema, mortandela.

Compartilhamento pra outras redes sociais

O botão de compartilhar perfil e espaços ocupados, e a página inicial ganharam abas de Atualizações. Você escolhe o que quer ver: o que tá rolando, o que suas amizades publicaram, o que mexeu com você. Tudo em ordem do mais recente. Sem algoritmo.

Entrar ficou fácil e os Espaços mais organizados

Dá pra entrar com o Google agora (tamo ficando xike) e pra quem já é de casa, aparece aquele “toque pra entrar” rapidinho. A busca de localização virou instantânea, já sugerindo os lugares mais populares enquanto você digita. E os Espaços foram repaginados com abas, filtros e ordenações. Por baixo dos panos, as fotos passaram a morar no lugar certo, deixando tudo mais leve.

E muito mais! Tem coisa que nem cabe aqui: paginação numeradinha no lugar do “carregar mais” (eliminando infinity scroll), uns ajustes de contraste no escuro, correção daqui, mais velocidade dali. Todo dia vem uma ideia nova!

Sem algoritmo. Sem briga por quem aparece mais. Sem anúncio e propaganda. Cada uma dessas linhas foi construída por pouquíssimas mãos, e é fácil dar manutenção nelas hoje (a gatah coda y coda).

E isso me leva à parte que talvez você tenha curiosidade pra saber.

­

E a inteligência artificial?

Uma parte de mim, querendo usufruir dos mesmos meios das grandes empresas de tecnologia tenebrosas, me fez querer usar ferramentas de IA pra me ajudarem na minha rede social. Hoje posso dizer, sem me sentir hipócrita, que utilizei um pouco de Codex no início e hoje trabalho utilizando Claude como ferramenta, e não substituto do meu trabalho (ou Cláudia, como apelidei carinhosamente).

O Yorgute não é um “não às ferramentas de tecnologia”, mas um “vamos tomar os meios de produção” e usar essas ferramentas pra criar algo que não nos destrua, um lugar calmo pra descansar.

Do front ao back-end, do banco de dados às ferramentas de produção e manutenção. Do que vi na teoria na faculdade há anos atrás, às experiências como desenvolvedora por anos.

Com ferramentas como a Cláudia (hahaha), consigo validar e consolidar tudo isso, com as minhas ideias, disposição e vontade de fazer algo legal pra todo mundo. Foi um grande ganho de tempo, no fim, pra criar algo que eu sempre quis. Acho que aprendi a usar essa coisa de alguma forma.

Qualquer idiota faria isso, mas eu fui a idiota que fui lá e fiz.

— Kaweski, Natasha 2026

Vamos recriar essa internet sem algoritmos de manipulação, sem essa briga por quem aparece mais, sem anúncios e propagandas.

Leveza, é isso. Seja bem-vinde à minha rede social :)

Se você está passando por um momento difícil ou pensando em se machucar, você não está sozinhe. No Brasil, o CVV (Centro de Valorização da Vida) atende 24h pelo telefone 188, ou pelo chat em cvv.org.br.

O que li pelo caminho

Se você quiser entrar nessa comigo, aqui está o que me fez movimentar pra entender melhor do tema. Não precisa ler tudo, mas se bater a curiosidade, é por aqui que eu caminhe:

• Raquel Recuero — Considerações sobre o Orkut, os Weblogs e os Fotologs (2014)
• Raquel Recuero — Redes sociais na internet: considerações iniciais (2005)
• Yuval Noah Harari — Nexus (2024)
• Joyce Rodrigues Alves e Ana Carolina de Gouvêa Dantas Motta — Os ladrões de atenção da vida moderna (2026)
• Karlla Souza e Mônica Ximenes Carneiro da Cunha — Impactos do uso das redes sociais virtuais na saúde mental dos adolescentes (2019)
• Vagner Figuerêdo de Santana e Diego Samir Melo-Solarte — Redes sociais online: desafios e possibilidades para o contexto brasileiro (2009)
• Mark S. Mizruchi — Análise de redes sociais: avanços recentes e controvérsias atuais (2006)
• NIC.br / CGI.br — Redes comunitária de Internet no Brasil (2022)
• Luna Maurer & Roel Wouters — Designing Friction

E, claro, a memória afetiva do Orkut. Essa não tem citação, mas foi ponto de partida como qualquer uma das outras.

Yorgute, um manifesto was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como trabalhar com Design System e não perder as estribeiras.

Neste artigo trago algumas experiências minhas estando no mercado de trabalho com foco nessa área que doa altruistamente suporte a todas as áreas.

Observação: Como o foco desse artigo é Design System, usarei a palavra abreviada “DS” para simplificar o texto.

Altruísta é a pessoa que age de forma preocupada com o bem-estar dos outros, sem esperar nada em troca.

Queremos ver as pessoas utilizando nosso DS, se deliciando com os componentes maravilhosos e inteligentes que criamos, que leiam a documentação, que nos procurem na dúvida e na sugestão, que nos envolvam. Somos um suporte para outras pessoas, queremos ajudar!

Mas a realidade é que não somos tão altruístas assim. Digamos que queremos ver resultados e também avançar e escalar cada vez mais nosso sistema, que a empresa veja o valor de um bom DS e do que o time está fazendo:

• Organização
• Documentação
• Gerenciamento de criação e manutenção
• alinhamento de processos
• Gerenciamento de tarefas
• Organização de conceitos e linguagem
• Desenvolvimento e validação, e o principal
• Design.

Acredito que muito dessa minha descrença vem da falta de conhecimento de contratantes do que é design e quais são suas variadas áreas. Quais profissionais uma empresa precisa contratar para o que deseja produzir? Os vários estudos e especificações de design não estão atingindo quem contrata e isso gera uma escassez de organização, tanto para a pessoa designer quanto para a pessoa contratante.

Um artigo publicado no UX Collective destaca que a formação de designers muitas vezes carece de clareza em relação às competências desenvolvidas, o que impacta diretamente na contratação desses profissionais. A ausência de uma definição precisa das habilidades esperadas pode levar a processos seletivos confusos e desalinhados com as reais necessidades do mercado.

Outro ponto relevante é a interdisciplinaridade do design, que pode causar confusão e, consequentemente, falta de demanda em algumas especificidades da área.

Como no caso do DS, isso ocorre porque muitas vezes, os contratantes não têm uma compreensão clara sobre as competências de um DS e o papel do designer dessa área, o que dificulta a definição de perfis adequados durante a contratação.

Portanto, a falta de conhecimento específico sobre as áreas de design por parte dos recrutadores e gestores pode resultar em processos de contratação mal direcionados, afetando tanto as empresas quanto os profissionais da área. Além disso, gera uma necessidade diária de provar seu trabalho, e como venho falar de DS, cria uma necessidade de provar o valor de um DS para a empresa e pessoas envolvidas a todo momento.

Esse designer de DS na realidade está alinhado com outros clientes: as outras pessoas que trabalham na empresa. Já pensou que louco criar um produto para outras pessoas, que vão utilizá-lo para criar outros produtos?

­

Dá licença?

Se tudo fosse cheiroso e belo, a gente chegaria numa mesa com todos os sócios, designers, pessoas desenvolvedoras e donas de produto, e toda a gama de stakeholders possíveis numa empresa e iria aplicar DS em todo canto. Mas não é bem simples.

Tem um conceito que aprendi assistindo à série da Marie Kondo — A Magia da Organização na Netflix há alguns anos. Em todos os episódios existe alguma situação complicada na vida de alguma pessoa quanto à sua organização, e a Marie Kondo ajuda essas pessoas, mas ela sempre segue um roteiro: ela pede licença pra casa!

Sim, a diva se senta e fecha os olhos, coloca as mãos sobre o colo e pede licença para a casa com uma reverência, porque a casa não tem nada a ver com aquela desorganização que tá acontecendo ali.

Acredito que, para iniciar uma nova jornada, numa empresa, time e DS novos, a gente tem que pedir licença. Aquilo já começou a acontecer ali, ele pode só estar um pouco desorganizado.

Respeitar o DS como um produto que precisa ser lapidado, organizado, que exige manutenção, que precisa de um cuidado exclusivo e dedicado a ele, gera consistência em todos os lados e não só visual, porque a gente olha pra raiz do problema e tentamos ajustar, e é a desorganização que queremos eliminar.

Seria um problema de virginianos ou de compulsivos por organização?

­

A saga comum de designers de DS

Quando a gente ingressa num novo time de DS numa empresa nova, a gente já começa com a ansiedade fazendo morada, querendo ver o que tem ali no Figma (ou em outra plataforma de criação).

1. Abre todos os arquivos do Figma
2. Fuça todos os projetos de outros designers
3. Começa a anotar o que tá fora do lugar e desajustado
4. Lista todos os componentes já criados
5. Gera pesquisas de melhorias e novas necessidades
6. Gerencia as tarefas que precisam ser atacadas para ajustar o “irreajustável” e vem a pergunta…

Por que não criar um DS novo?

Ah, o ledo engano! Quando cai nessa ideia já se começa a fantasiar uso, novas propostas, novo design, tentamos até fazer a cabeça de outros pra criarmos uma nova marca pra adaptar ao DS que estamos pensando.

Mas não é bem assim que as coisas precisam acontecer tá? Respira fundo. Anota tudo num papel, vai lá, seja feliz. Essas ideias tu pode usar pra criar algo próprio depois. #dicaDePortfolio

Pra não cair no conto do vigário acima de criar um novo DS, vamos pensar no DS atual que estamos trabalhando como um produto.

­

DS como produto

Costumo fazer isso em todo lugar que trabalho e com a ajuda do Design Thinking consegui chegar a algum lugar.

Pesquisa de componentes

Como um produto que gera outros produtos o ideal é verificar de perto o uso de cada componente, por isso sugiro que faça uma pesquisa que pode até demorar num primeiro instante, mas depois vai ficar fácil de continuar atuando.

Tire print — isso mesmo, facilita na agilidade dessa etapa — de todos os componentes utilizados nos projetos. Separe cada componente por página, cole em cada página todos que encontrar. Assim você tem um estudo de uso recorrente de vários cenários agrupados num único arquivo, o que facilita na identificação de inconsistências entre várias telas.

­

De ideias para tarefas

Anote tudo que verificar ser necessário e vá direcionando as demandas que forem surgindo conforme a matriz de priorização com quatro quadrantes organizados por custo — exemplo abaixo — facilitando na identificação de tarefas imediatas que precisam de mais urgência para serem resolvidas.

Atomicidade de componentes

Gosto de chamar assim uma tabela gigante que possui todos os componentes necessários para um DS. A medida que for adicionando componentes, selecione quais outros são necessários para construí-los. Isso facilita na priorização de componentes interligados, evitando mexer em algo que vá reverberar em muitos outros componentes.

Importante aqui ter a ideia de Design Atômico: por exemplo, vamos pensar num componente-molécula simples: um botão. Ele precisa de texto, cor, cantos arredondados, espaçamento, etc.

Na tabela de atomicidade são selecionados todos esses átomos, já que ele é feito de tudo isso. Se em algum momento der na telha de alterar o botão, precisamos nos atentar para todos esses outros componentes em questão.

Gerar essa tabela pode facilitar na tomada de decisão para manutenção, criação ou despriorização de componentes, e ajuda a não alterar coisas desnecessárias que poderiam ser evitadas se estivessem mais evidentes — como na tabela.

­

Pesquisas com usuários de DS

E vamos pra parte mais interessante do DS, o seu uso.

• Como outras pessoas veem seu produto?
• Como outras pessoas o consomem?
• Existe algum gap de informação?
• O que mais elas gostariam e do que elas sentem falta?
• O que poderia melhorar?

Colha informações, metrifique, brinque com os números, suponha cenários e teste. Acho que o que mais gostei de fazer foi de testar, errar, testar de novo… e acertar!

Em vários cenários o que mais prejudicava não era o design em si, mas a comunicação. Mas antes de falar algo, ouça.

• Participe de critiques e testes de usabilidade com outros designers para colher feedbacks e fazer uma validação mais assertiva.
• Deixe a janela de comunicação sempre aberta, as pessoas querem falar com você.

Rode algumas pesquisas qualitativas com pessoas desenvolvedoras, designers, stakeholders e outras pessoas envolvidas. Isso abre espaço para as pessoas verem você com mais respeito dentro da sua área, o que facilita mostrar com mais acuracidade a necessidade de um DS mais robusto e como fazer isso, atendendo às expectativas e necessidades dos seus usuários.

O que colher dessas pesquisas, volta-se para a etapa “Das ideias para tarefas” onde você organiza em tarefas o que precisa ser feito — ou não.

Depois você pode organizar suas ideias e tentar trazer algumas formas de disseminar o conhecimento em DS:

• Criação de workshops ensinando o uso do DS.
• Gravação de onboardings por todo o projeto disponibilizado para novos funcionários que necessitem saber dessa informação.
• Criação de workshops de Figma. No meu caso já ensinei bastante gente a usar o Figma antes mesmo de explicar o uso do DS em si.
• Criação de documentação detalhada com especificações, conceito, como usar e não usar, anatomia, etc.

Por fim, todo esse trajeto se resume em você mostrar o seu serviço e cobrar que os outros usem seu serviço também — ora, por que não? — , porém muitas vezes somos vistos somente como um suporte que não tem autonomia para cobrar o outro.

Seria altruísta mesmo? Ou ditatorial? Policial de Figma?

­

(Des)usando um DS

Sabe quando aquele designer te manda uma mensagem dizendo que não sabe usar o autolayout do Figma, ou que não consegue trocar um componente por outro e precisou dar “detach component”?

Acho que esse é um dos principais problemas que temos hoje como designers de DS, o desuso, o descaso. É aqui que piadinhas e comentários tristes vão encontrar espaço pra matutar na nossa cabeça.

"Ah dei detach, a Natasha vai me matar!"

"Não usei o componente do DS e fiz um novo, se for passar pelo time de DS vai demorar."

"O time de DS faz publicação no Figma o dia todo, odeio ter que atualizar meus projetos."

“DS não é uma prioridade pra gente agora, precisamos de tela do produto.”

Tudo bem, o DS está aí pra uso de quem pode e quer usar.

Essa ideia de padronização para escalabilidade tem que partir de quem te contratou, pois partindo da raiz as coisas se adequam de forma mais orgânica.

Se não o é, é preciso mais uma vez validar o projeto e defendê-lo para continuar existindo, e é aqui que o designer arca com uma batalha homérica com todo mundo, e onde começa a preferir estar na solitude.

É ingrato porque a partir desse ponto as coisas podem melhorar ou partir dessa para uma pior, e não estamos falando de demissão.

­

É hora de arregaçar as mangas e ir pra batalha

Na realidade essa batalha vai ser com você mesmo. Para não enlouquecer, desistir ou o pior: criar um novo DS.

Realmente criar um novo DS às vezes não é o melhor cenário a não ser que esse seja o intuito da empresa em ter te contratado.

É aqui que entra a defesa do DS como um produto e onde você precisa mostrar conhecimento no quesito design e organização para tentar emplacar com uma ideia que pode dar muito sucesso: o seu DS.

• Mostre para stakeholders outros casos de sucesso que aplicaram DS em seus processos de design (como Airbnb, Uber, Duolingo, etc).
• Crie ritos para tirar dúvidas para que nenhuma pessoa fique desamparada no uso do seu DS. Participe de critiques, abra agendas no seu calendário para ficar de plantão.
• Comunique toda e qualquer atualização do DS e não deixe ninguém com medo de atualizar a biblioteca importada do Figma.
• Versione seus updates no Figma com Version History.
• Aproveite a ideia de estar num DS e crie novas aplicações utilizando o DS que você está dando manutenção. No meu período no banco Inter incentivei criando aplicações fictícias (Inter Movies, Inter Donation, Inter Music, entre outros) no único intuito de mostrar valor no uso real.
• Dê alguns passos pra trás e olhe para as tarefas reais do seu backlog, não fantasie, olhe o real. Olhar pro real te dá segurança do que está no seu controle e do que não está.
• Consuma artigos, tutoriais, livros de arte e design. O conhecimento nessa área nunca é demais para aperfeiçoar seu processo de trabalho.

Por fim, fica uma mensagem encorajadora para você que como eu está numa luta diária como designer de DS: se manter no mercado ainda com brilho nos olhos, atuando e aprendendo coisas novas para aprimorar e escalar seu trabalho.

O design precisa de um pouco de regras, e a gente está aqui pra fazer essa ponte entre o subjetivo e o tecniquês. Lembre que seu papel é dar suporte, ser ponte e ajudar outras pessoas. O DS mais do que tudo é um auxílio para criação de novas peças, por isso precisa de regras.

Embora todo processo pareça meio subjugado por outros, isso se limita até colocarmos pra nós que é uma escolha estar onde estamos, e que temos liberdade de nos expressarmos da forma que a gente achar melhor. Daí fica a escolha: de atuar de forma mais organizada em outro lugar, ou de bancar essa escolha e tentar fazer mais uma vez algo legal.

Acredito que esse texto não é só para designers de DS, mas para pessoas que trabalham com organização no geral, porque no final de tudo vejo DS como potes de canetas, lápis e pincéis, em como posso categorizar alguns agrupamentos, seja por tamanho, tipos, cor, formatos, etc.

Essa forma de pensar é única, intrínseca e inerente do que você faz como trabalho, e independentemente do Design System que esteja trabalhando, a forma de pensar é a que mais vai validar a forma que você precisa organizar seu trabalho, por isso consumir cada vez mais tipos de conteúdos abrangentes é importante pra continuar expandindo as várias formas de organizar as coisas.

Se mantenha ativo na arte, se inspire, entre em contato com coisas que te deixam feliz só de ver, a arte é subjetiva.

Talvez disso tudo você consiga tirar proveito e fazer o seu trabalho de forma legal pra você! Criando o seu canto, conhecendo a sua forma de pensar, alinhando o seu processo de trabalho. Conheça o que gosta e aplique isso. Estude e se questione o tempo todo.

Fica firme, vai dar tudo certo!

Referências

• Atomic Design Metodology, por Brad Frost.
• Quem somos nós: uma lupa sobre as competências em design, por Igor Casenote.
• Dica de ferramenta do Figma: Version History.
• Foto de Marie Kondo por Revista Haus.
• Cases de design de sucesso: Airbnb, Uber, Duolingo.
• Projetos de adaptação do Orange DS do banco Inter: Inter Movies, Inter Donation, Inter Music.
• Design Thinking, por Wikipedia.

Trabalhar com Design System é muito ingrato — ou não was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Essas pessoas consomem seu produto estando em qualquer estado: se ele possui somente uma documentação simples no Figma, se ele possui apenas componentes, ou se ele já está implementado centralizadamente numa equipe de Design System com as habilidades necessárias para se criar componentes tanto em design quanto em desenvolvimento.

É válido ressaltar que essa é a minha opinião, já que um Design System sofre evolução constante e nenhum projeto em andamento tem realmente um final. Um DS está sempre em sendo reinventado, mantenido.

Isso dito, eu gostaria de trazer minhas experiências trabalhando com meu segundo Design System, na Hotmart, onde aprendi com meus usuários — pessoas de tecnologia em geral — tendo também bagagem de necessidades que já observava no outro DS que tinha trabalhado.

Discovery Component

Quando troquei de empresa a primeira coisa que eu fiz foi estudar o Design System do qual iria trabalhar, lógico. Mas eu não só abri as bibliotecas, vi os componentes no Figma ou no GitHub, uma das tarefas que eu realizei foi tirar print de tela por tela de Product Designers dos outros times.

"Como esse cara usa esse Input Text?"
"E essa aqui, como que ela ta usando o mesmo componente?"

Essas indagações viraram um projeto de estudo do qual chamei “Discovery Components” com todas as formas de disposição dos componentes na plataforma.

❗️ Problema:
De alguma forma dava pra perceber que alguns Product Designers usavam alguns componentes de forma inconsistente, seja por não tirarem dúvidas ou adaptavam da melhor forma que se encaixava no projeto, e sabemos que infelizmente isso gera uma inconsistência absurda entre os projetos.

💡 Solução:
Minha parte prática a partir disso, foi gerar uma planilha com as dependências de cada componente. Por exemplo:

Componente de Input Text precisa desses componentes adicionais:
- Label (texto e cor);
- Caixa de entrada (cores, bordas e espaçamentos);
- Texto de ajuda (ícone, texto, cor e espaçamentos).
Inclusive: em breve quero disponibilizar no Notion uma planilha para auxiliar como check list de Design System.

Tendo isso em mente eu consegui criar uma priorização de componentes menores (a partir do conceito de Design Atômico do Brad Frost). Pesquisava no Discovery Component como Product Designers estavam fazendo cada componente. No nosso exemplo do Input Text, ele precisava de "componentes menores" de texto, cor, borda, espaçamento, ícone, entre outros.

Na criação de uma nova biblioteca fui puxando esses insights e formas de disponibilizar o melhor UI/UX possível de cada componente, respeitando as etapas de cada processo como Ideação e UI, Teste de Usabilidade, Handoff com Desenvolvedores e enfim o tão esperado Done/Release, para que enfim todos pudessem usufruir do componente.

Foi assim que surgiram minhas ideias de disponibilização dos componentes de forma que a gente pudesse obter o máximo de consulta da documentação e menos gargalos esperando soluções a partir do contato com o time de DS.

E é a partir daqui que vira uma "aulinha", um "how to do your DS". 🤓

Variações inteligentes

Sabe quanto você tem uma ideia de disposição de um componente que poderia fazer um milhão de coisas em um cenário e mais simples em outro cenário? Pois é, isso acontecia bastante.

São os famosos "Moléculas" ou até "Organismos" no conceito de Design Atômico. Minha primeira versão foi disponibilizar o que chamava de "minhocão", um componente com todos os componentes internos possíveis para cada necessidade. Para cada uso do componente o Product Designer deveria copiar o componente raiz (com tudo dentro visível) e ir ocultando as camadas que não precisava.

❗️ Problema: os usuários efetuavam muitos cliques até encontrar a camada que gostaria de editar/ocultar; se o componente sofresse atualizações isso reverberava no import do Product Designer e atrapalhava todo seu projeto, pois o componente também atualizava textos e adaptações; e o Figma com muitos componentes importados e ficando lento.

💡 Solução: Criar vários componentes adicionais separados, como no caso do Input Text, cria-se um componente do Label, outro para o Input e outro para o texto de ajuda. Mais tarde com um update do Figma foi possível criar Variações Aninhadas (Nested Instances), que permite exibir o painel de Variants para cada componente interno, eliminando os problemas que foram citados acima. 🥳

Documentação

Apesar de ser uma pessoa comunicativa também gosto de trabalhar no meu cantinho, portanto, como reduzir esse contato para que eu consiga focar e realizar meu trabalho? Como evitar contato desnecessário com algo que eu sei como resolver e outras pessoas também querem saber como resolver sem precisarem tirar dúvidas o tempo todo?

Simples: escrevendo! ✍️

Escrever como algo funciona, mesmo que você não tenha o "dom da escrita", é importante e nos dá uma convicção do real funcionamento do que estamos desenvolvendo. Para dentro do Design System isso é imprescindível e é uma das coisas que eu mais faço questão que um DS realmente tenha, ele precisa ser descritivo.

Questões como:

1. Como esse componente se comporta?
2. Quais variações ele possui?
3. Em quais casos eu não posso usar esse componente?
4. Quais variáveis estão disponíveis?
5. O que posso alterar do componente para se adaptar no meu projeto?
6. Quais contextos utilizar?
7. Existe algum cenário excludente?

Eu sei que as vezes parece ser muito longo ter que ler a documentação de todos os componentes, mas na necessidade do dia-a-dia você só precisaria ler sobre o que você está usando ali naquele momento.

PORÉM… Mesmo sabendo disso eu quis facilitar ainda mais o processo para meus usuários, trazer de forma visual as opções e variações daquele componente. Levei uma documentação visual para que a pessoa que lesse/visse pudesse bater o olho e saber como seria o funcionamento daquele componente (eu sei, eu sou especial demais! 💁‍♀️).

Anatomia

Quando o componente passou por todos os passos do processo de construção, eu costumo puxar as variações mais discrepantes e vou desenhando em cima do componente.

Pera, vou desenhar pra você entender:

Mas no Figma não tem a aba Inspect? Sim, mas como eu disse: disponibilizar visualmente a solução é muito melhor do que ler a documentação. O mais simples que pudermos deixar para quem for consumir precisar somente bater o olho e entender o que precisa ser feito, melhor.

Do's & Don'ts

Foi disponibilizada várias formas visuais de como um componente pode ser utilizado e como ele não pode ser utilizado. Variações simples e que eu precisei pensar como Product Designer e a partir do Discovery Component em como construir esses exemplos visuais utilizando o componente em questão.

Diferente do que encontramos em muitas documentações publicadas, eu tentei trazer pra realidade do PD como o componente deveria ser comportar em seu projeto. Isso também auxilia os desenvolvedores a entenderem a lógica do comportamento do componente.

Interaction Design

No Figma, depois do Auto Layout o Prototype é minha ferramenta preferida, porque é com ela que a gente faz a mágica acontecer.

Sobre o usuário, como ele vai se sentir quando interagir com meu componente? O que ela está pensando? Será que isso aqui vai facilitar a vida da pessoa? Tirando as questões de regras de negócios (onde não tem espaço dentro do Design System), isso atende ao usuário?

Não é segredo nenhum que uma Pessoa Designer empática tem uma grande virtude, portanto, é criando a interação do componente que entendemos como nosso usuário vai interagir com aquele componente.

É muito importante mostrar o funcionamento do componente, com cliques simples e com o básico é possível trazer clareza para o funcionamento de tudo.

Releases & Branches no Figma

Na minha primeira experiência com Design System eu sempre tinha problemas com os Product Designers que reclamavam que o DS sofria alterações o tempo todo.

Não façam isso! 🚨

Aprendi com a experiência que isso não é de todo agradável. Além do Figma notificar cada publicação nova da biblioteca, dependendo da alteração faz o projeto "se quebrar todo".

Passando por várias situações como essas, eu identifiquei que precisava focar num componente completo, trazendo-o mais inteligente possível e que não precisasse de manutenção tão cedo. Isso faz com que hoje eu consiga evitar alterar um componente já construído e em produção, evitando futuros reajustes de quem esteja utilizando uma específica versão.

Válido ressaltar que estipulando metas e definindo bem as sprints eu sabia quantos componentes eu precisaria desenvolver num período de tempo. Como trabalhar com isso na prática? Vamos ao Figma:

1. Cria-se um arquivo onde se coloca os componentes ainda não prontos, que estão “estacionados” (gosto de chamar de Parking Lot);
2. No desenvolvimento dos componentes em Parking Lot, após passar por todos os processos de aprovação, costumo “taggear” os componentes com um ícone de “Done” pra facilitar a transferência pra biblioteca: ✅.
3. Cria-se uma branch da biblioteca core (pode ser com o nome da versão da release, tipo v1.0-Pitanga) — lembrando que Branches só estão disponível para Organizations;
4. Na branch nova criada se coloca ali os componentes com a tag “Done”;
5. No final do período essa branch é “mergeada” na branch “master” da biblioteca core, e o componente fica disponível para uso dos PDs depois da publicação e propagação da Biblioteca Core.

Pair Design

E pra finalizar com chave de ouro, o mais importante como Designer de Design System: ver o usuário do seu produto utilizando o seu produto pra construir algo incrível. Tomei a liberdade de chamar de Pair Design porque é bem semelhante ao Pair Programming que a área de desenvolvimento tem, é realmente fazer uma funcionalidade usando seu DS com o conceito e necessidade junto com outro PD.

O passo mais importante, as vezes um pouco maçante pelo tempo e pelo empenho num só componente, mas muito importante pra entender como as pessoas estão se comportando utilizando algo que você construiu.

Além de ajudar a pessoa Product Designer a utilizar o seu produto, você também mantém a consistência do seu produto, tendo o Design System atuando desde a prototipação de uma funcionalidade, no uso correto do Design System e entendendo ali na íntegra quais as dores e soluções tem a pessoa que está usufruindo do seu Design System, te dando feedbacks ao vivo de como ela vai trabalhar com o que você produziu.

É muito importante manter essa consistência de Pair Design, porque é nesse processo que mantenedor e ajudador conseguem fazer os projetos se adaptarem ao Design System.

Acredito que é tudo isso, galera! Continuo aprendendo cada vez mais sobre os processos de mantenedora e owner de um Design System tão robusto quanto o que trabalho hoje. E esperem que trarei mais conteúdo por aqui.

Ah! Segue link do site novo: https://kawe.ski, é meu cantinho na internet onde quero postar minhas mil coisinhas que gosto de fazer.

[]’

Estão vamos lá!

Capítulo um: 6+ anos na programação

Tudo começou em meados de 2012 quando comecei com meu primeiro emprego como Web Designer sem mesmo ter um diploma na mão e muito menos pensar em fazer uma faculdade. Minha atuação na época era somente com desenvolvimento em HTML, CSS e criação de layouts com Photoshop. Dali eu peguei gosto pela coisa e comecei a aprimorar as inúmeras decorebas que são as tags de HTML e propriedades de CSS. Um tempo depois troquei de agência e fui trabalhar como Front-end Developer pela primeira vez.

Foi nessa agência que conheci uma das minhas melhores amigas hoje, a Beta Girão, que me auxiliou a aprimorar cada vez mais meu olhar crítico pra design pixel a pixel. Gosto de dizer isso pois foi com ela que eu tive uma das melhores gestões que tive na vida, e quem me auxiliou a ter o olhar perfeccionista que tenho hoje. Obrigada por toda ajuda Beta! 💙

Se eu puder aconselhar alguém, aprimore seu olhar crítico pra design na hora de programar. Isso faz muita diferença na hora de utilizar o produto pronto.

Além dessa super gestão que tive da Beta e de aprender a ser crítica com o que eu programada quanto ao design, foi quando eu entendi a necessidade de fazer a faculdade. Já havia tentado uma vez pra Design Gráfico mas não tinha dado certo, foi quando tive coragem de prestar vestibular novamente e dessa vez para a área que já estava trabalhando. Escolhi uma universidade particular com financiamento do FIES, que era perto do trabalho e que eu pudesse estudar a noite pra trabalhar de dia. Pesquisei por dias o curso certo e achei que o curso de Ciência da Computação seria mais adequado ao que queria naquele momento.

Capítulo dois: ingressando na faculdade

Já no início do curso eu percebi que estava fazendo o curso que eu queria, mesmo sendo difícil pra caramba e tendo que me desdobrar pra fazer tudo e dar conta de tudo. Bem no ínicio já começaram a aparecer novas oportunidades de trabalho, foi quando comecei a fazer estágio em outra agência e ainda como Front-end Developer. Meu trabalho ainda era mais focado em HTML, CSS e no saudoso JQuery, comecei a entender de fato linguagem de programação e já começava a fazer blogs completos e grandes com Wordpress em uma semana.

Ali eu considero que comecei a ter vislumbres de padronização, eu criava classes no CSS que seriam reutilizadas por todos os os projetos, talvez um design system já começava a brotar na minha cabeça.

O networking começou a se expandir e comecei a ser abordada por empresas maiores e com projetos mais rentáveis. Foi quando troquei de empresa novamente, fui trabalhar numa corretora de investimentos onde aprendi de fato a trabalhar com um produto robusto. Aprendi a programar em AngularJS, Angular 2+ e pensar em componentização e escalabilidade. Nessa corretora trabalhei com Caio Gomes e Charles Assunção, dos quais sou eternamente grata pela melhor equipe que pudemos ter, mais pra frente foram ingressando novos colaboradores dos quais eu aprendi muito com eles também além de termos gerado uma amizade forte e duradoura. ️💜

Nesse período estávamos para lançar a corretora e eu acabei focando mais no trabalho do que na faculdade e acabei perdendo meu financiamento da faculdade, o que me fez precisar trancar a faculdade por um período. Logo após esse tempo de lançamento da corretora eu consegui um mérito para conseguir bancar meu curso e voltar para a faculdade, foi quando recomecei meu estudo e dessa vez para formar (famoso “agora vai!” e de fato “foi!”).

Houveram algumas matérias que eu identifico hoje como gatilho do meu interesse pela área de UX/UI, por exemplo Interface Homem-Máquina. Lembro que foi uma matéria que eu me dediquei muito para identificar o que poderia ser melhorado nos sites que o professor dava como exercícios para analisarmos, estava muito engajada com todos os trabalhos, e essa matéria eu dediquei interamente sozinha justamente pela minha desenvoltura e pela independência no assunto. Logo após um tempo eu tive a oportunidade de trabalhar ainda com Front-end Development no banco Inter.

Mais pro final do meu curso da Computação eu tive uma matéria ministrada pelo professor Fernando Parreiras, com o nome de Métodos Ágeis e DevOps. Nessa matéria estudamos experiência de usuário, pesquisa, priorização de tarefas, aplicação de Scrum e outras metodologias ágeis para pequenas e grandes equipes, e isso tudo já me fez olhar diferente pra área de UX/UI Design. Ao fim da matéria apresentei um pitch juntamente com outro colega de turma sobre um produto que desenvolveríamos (como material acadêmico), e foi onde eu comecei a brincar no Figma com prototipação e criação de interfaces. Obrigada pelas fagulhas, Parreiras! 💙

Além dessas pinceladas na faculdade, eu ainda me incomodava muito com o meu trabalho e comecei a me perguntar se estava realmente trabalhava com o que eu realmente gostava, foi quando fiz um curso no Skillshare que me deu um direcionamento pelo menos do que eu mais gostava, e programar definitivamente não estava na lista.

Capítulo três: encerrando um período

Foi quando comecei a fazer cerca de 6 meses trabalhando como Front-end Developer no Inter que mencionei que queria trabalhar como designer no time de Product Design para meu gestor. Ele se disponibilizou para me trocar tranquilamente na época mas eu quis aprimorar melhor minhas skills antes de migrar de carreira, então comecei a desenhar e rabiscar algumas telas do produto que estava desenvolvendo na época, o Internet Banking de Pessoa Jurídica do banco Inter.

No desenvolvimento de algumas telas e dando pitacos de design com alguns designers , comecei a estudar um pouco mais de UX/UI na Alura, comprei alguns cursos na Udemy e Skillshare também, e aprendi de fato a trabalhar com desenvoltura no Figma, nossa principal ferramenta de Design hoje no banco.

Lista de estudos para minha preparação:

• Fundamentos de UX, UX Strategy, UX Usability e UX Product na Alura.
• Creative layouts for Web and UI Designers no Skillshare.
• Fiz também um workshop de criatividade com o Marcus Mota da Quartel Design, que me deu insights relevantes sobre um trabalho diferente sempre dos demais.
• Figma: Design colaborativo do básico ao protótipo responsivo, na Udemy por UX Unicórnio (um dos meus cursos mais importantes na carreira).
• Formação Online em Design System & Ops pela Meiuca. O curso foi refatorado e hoje eles contam com uma formação de Design System Specialist.

Hoje sou vista no time como referência de Figma no Inter, e inclusive já apresentei alguns workshops da ferramenta ensinando a utilização principalmente das ferramentas de smart layout. Se dediquem com a ferramenta com que trabalham, isso da bastante visibilidade e protagonismo na área.

Fiz esse período de estudo por mais ou menos 6 meses, e depois desse período eu pedi pra migrar de time como Designer de Produto, e foi no final do ano de 2020 que comecei a trabalhar como UX/UI Designer no time de Product Design do Inter. Enfim, encerrei um período como desenvolvedora com muito carinho e muita gratidão por tudo que passei até ali. 🤗

O mais engraçado é que no mesmo período eu me graduava como Cientista da Computação, hoje vejo como uma possibilidade de ter dois empregos: tanto como programadora quanto como designer, tendo a opção de escolher em períodos diferentes da vida com o que eu quero trabalhar mais.

Capítulo quatro: o início de um sonho

Entrando no time de Product Design de tive a chance de conhecer pessoas incríveis no time que me deram muito insumo como a nova designer que estava me tornando. Insumo de pesquisa, de escrita, de visual e entre outros. Sou grata a todas essas pessoas que conheci.

Além de ter percebido que eu tinha feito a escolha certa, eu estava enfim trabalhando com o que eu mais gostava — eu sempre gostei mais da parte visual da coisa, do HTML e CSS escrito e reescrito, da padronização, componentização, da parte que escalonava e da parte que eu podia ficar escovando pixel pra deixar tudo perfeito.

Entrei já direto no Design System, conhecendo de primeira como era o trabalho do designer de Design System. Imediatamente já comecei a fazer pesquisar como melhorar o que já estava sendo evoluido dentro do Inter, que na época se chamava Inter UI, atual Orange DS (menciono ele aqui neste post). Na época tínhamos algumas rotatividades de novos entrantes em outros times, fiquei um tempo em Investimentos mas logo voltei pro Design System de novo, mesmo porque era uma área que tinha tudo haver com o meu background de desenvolvedora.

Capítulo cinco: deu tudo certo!

E foi nesse espacinho de céu que eu fiquei e identifiquei onde consigo realizar meu trabalho com brilho nos olhos, claro que trilhando aos poucos cada etapa mas que eu tenho orgulho e zelo por cada passo tomado.

O trabalho de um novo designer no Design System é algo que ainda estou descobrindo aos poucos como fazer, tentando evoluir cada dia mais o Design System que estou trabalhando, e amadurecendo meu pensamento e meu trabalho a partir de novos aprendizados.

Uma coisa que acredito ser um passo dado e certeiro é aprofundar no uso da ferramenta que utilizamos hoje: Figma. Isso trouxe caminhos e portas abertas para vários outros caminhos, e aconselho a estudarem bastante as ferramentas facilitadoras nativas do próprio Figma.

Listinha básica de estudos interativos do Figma pra você ficar bonzão:

• Auto layout: playground interativo.
• Interactive components: Playground interativo.
• Variants: Playground interativo.
• Copy & Past, playground interativo. Por último mas não menos importante (ensina a facilitar e agilizar o trabalho do simples Ctrl+C e Ctrl+V).

Minha migração de carreira ocorreu dessa forma: aos poucos, e veio ocorrendo a partir de vislumbres de interesse mais pela área de design do que por programação. Acredito que com essas dosagens de cada especialidade a gente consegue perceber o que a gente realmente quer fazer na nossa vida, no meu caso eu percebi que queria atuar mais na área de design.

E você, tá satisfeito com o trabalho que você vem fazendo? Conta um pouquinho pra mim, eu gosto muito de descobrir como as pessoas chegaram onde estão em suas carreiras.

[]’

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.

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!

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.

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.

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.

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.

Orange DS, como surgiu meu primeiro Design System was originally published in Equipe Inter UX on Medium, where people are continuing the conversation by highlighting and responding to this story.