Safra Design System framework
Unificando padrões e processos para consistência, agilidade e identidade nos produtos digitais do Safra
Serviço
Cliente
Design System, Ui
Banco Safra
Ano
2022
O Design System é um conjunto de padrões interligados e práticas compartilhadas organizadas de forma coerente para atingir o objetivo dos produtos digitais.
Os padrões repetem os elementos que combinamos para criar uma interface: elementos como fluxos de usuário, interações, botões, campos de texto, ícones, cores, tipografia, microcopy. O Design system é um ambiente onde escolhemos criar, capturar, compartilhar e usar esses padrões, especialmente quando trabalhamos em equipe.
Nosso objetivo é criar um documento com elementos consistentes de de fácil uso, com foco na autonomia de cada equipe do Safra, visando reduzir ruídos e acelerar processos.
1. Preparação
Antes de atuar efetivamente no documento, é importante entender a cultura, reais necessidades, pontos fortes e fracos de tudo o que orbita o nosso Design system.
Essa fase também consiste na compilação de dados essenciais que nos ajuda a tomada de decisões futuras.
Primeiro mapeamos todas as principais frontes atuantes dentro do Safra, cada uma com suas particularidades, regras de negócio, visual design elementos de ui, e principalmente, cada um com sua equipe
O que percebemos?
Percebemos de dentre tantas inconsistências de componentes de interface dentro do Safra, visualmente eles se agrupavam em duas linhas: uma tinha uma identidade elegante e minimalista e outro uma identidade mais varejista
Encontrar apenas dois padrões visuais dentro de tantos produtos e interfaces é uma ótima notícia nosso mapeamento já nos trouxe uma resposta de como iremos atuar nos desdobramentos de componentes.
Apesar de conseguimos afunilar as abordagens visuais, encontramos também uma grande variedade inconsistente de cores onde vamos precisar criar um estudo mais aprofundado sobre o propósito de cada uma.
2. Metodologia
No Safra, foram mapeados cerca de 40 produtos. Todos com o seu próprio padrão de componentes.
Para implementar o Design System, trazer autonomia, velocidade e homogeneidade em cada produto sem perder sua identidade visual própria, adotamos o conceito Design System Core.
O Design System Core funciona como um guarda-chuva para outras bibliotecas que podem surgir no futuro.
A partir do Safra PF criaremos uma biblioteca-mãe com regras e instruções estruturadas, com diretrizes para a criação e modificação de componentes dentro e fora do Core.
Tokens
Design tokens são atributos de um componente. São padrões de design mais descritivos e menos tangíveis, como estilos ou cores de iconografia e tipografia, geralmente usados para criar um certo tipo de estética e fortalecer uma conexão emocional com um produto.
Tokens estão no core do design system - São os estilos que mantém o design system escalável e consistente, além disso, usamos esses atributos para dar a identidade do safra para todos os seus produtos.
Os itens dentro do token são:
-
Marca (safra)
-
Cores
-
Fontes
-
Grid
-
Spacing
-
Iconografia
-
Imagens
-
Sombras
-
Ilustrações
-
Tom de voz & microcopy
Base components
São padrões funcionais, blocos de construção tangíveis da interface. Seu objetivo é permitir ou encorajar certos comportamentos do usuário.
Os componentes são construídos usando tokens e seguem os padrões e diretrizes definidos por eles. importante ressaltar que os componentes que cabem aqui não são complexos e como cards e, footers e modais e sim botões, listas tooltips e etc.
Aqui estão estipuladas regras mínimas para cada elemento, mas visando a independência e identidade de cada produto os componentes podem ser estilizados caso haja necessidade.
Os itens dentro do token são:
-
Botões
-
Tooltips
-
Inputs
-
Datepicker
-
Data table
-
Accordion
-
Badges
-
Bottons Sheet
-
Filtros
-
List
-
Loading
-
Navbar
-
Paginator
-
Indicator
-
Selections Controls
-
Tabs
-
Stepper
-
Switches
-
Dotnav / Slider
Team components
Tem componentes são subprodutos do design system. São bibliotecas que comportam todos os elementos e tokens com pequenas modificações a fim de atender a necessidade individual daquele produto.
Aqui também encontramos os componentes complexos como Card, Banner, Modal, Header, Footer e etc.
Existe apenas um núcleo de token e apenas um base componentes mas quando falamos em team components, essa bibliotecas podem existir simultaneamente cada uma atendendo o seu produto.
Not in DS
Componentes de uso pontual.
Aqui entramos no âmbito das exceções, é importante ter uma visão dinâmica e realista do Design System, sempre teremos componentes a serem criados e modificados , mas, existem ocasiões onde o componente é construído com uma única funcionalidade e para um único produto.
Entender que teremos exceções é construir um cenário saudável para adesão e um ambiente organizado onde podemos inclusive gerar dados de quais produtos não estão caminhando com o Design System.
3. Processos
Um pouco dos nossos processos de trabalho, ferramentas e esquemas que precisamos manter alinhados durante o projeto.
Discovery
O discovery esclarece o potencial e a relevância de um novo recurso e, nessa etapa, decidirmos se devemos ou não aderi-lo.
Essa atividade pode ser realizada por qualquer pessoa da equipe, designer, desenvolvedor front-end ou gerente de produto. Aqui são feitas pesquisas, triagem de solicitações, entrevistas, produtos e análise de sistema, discussões com parceiros influentes na equipe.
Design
O design finaliza uma gama de variações, estados e outras dimensões em alta fidelidade para que o Build possa ser concluído, seja para estilo visual (por exemplo, ícones), Componentes de IU (como um botão) ou exibições de documentação (como uma página colorida amostras).
Aqui criamos o componente em si e todas suas possíveis variações. Nessa fase é importante testar o componente em vários possíveis contextos.
Homologação e handoff
Aqui temos a validação e discussão da equipe, é feita uma avaliação sobre componente, o que foi construído e se falta algo. Caso o que foi feito não atenda a demanda voltamos para design ou até mesmo discovery.
Documentação Design
Focado em comunicar não o que construir, mas sim o que é construído e como usar. Documentação é uma tarefa separada para que nossos autores se concentrem na qualidade e na profundidade para que nossos componentes atendam seus usuários. Essa tarefa é atribuída ao designer. O desenvolvedor também terá seu papel na construção do documento só que não neste momento, o papel dele nessa fase é dar suporte ao designer na compilação de informações.
Aqui é compilado, além de diretrizes claras de uso, informações relevantes, esclarecimento de linha de raciocínio(que foi construída desde o discovery) e tomadas de decisões. Também compilamos informações técnicas e exemplos de uso e variações. Tudo o que for relevante e complementar para o documento deve ser registrado aqui.
Build
Resultados na codificação de HTML, CSS, JavaScript e outros códigos. Essa tarefa é atribuída a um desenvolvedor front-end. Código e ativos, git para gerenciar dentro dos ramos prescritos e puxar solicitações para comentários e correções de tarefas. Definição de Concluído: para mesclar o recurso em uma versão
QA
Nessa etapa, o objetivo é garantir que o componente funcione corretamente, siga o design aprovado e esteja livre de erros visuais ou técnicos. A verificação inclui testes de funcionamento (interações, cliques, navegação), conferência de layout (cores, tamanhos, espaçamentos, tipografia) e compatibilidade com diferentes dispositivos e navegadores. Essa análise assegura que o componente esteja pronto para ser integrado ao produto final sem impactar negativamente a experiência do usuário.
Documentação Dev
A documentação para desenvolvedores de um componente de Design System inclui informações técnicas que a documentação feita por designers normalmente não traz, como exemplos de código, lista de propriedades e valores aceitos, estrutura de arquivos, dependências, orientações de acessibilidade em código, eventos e métodos disponíveis, instruções de integração, compatibilidade com navegadores e frameworks, além de detalhes sobre testes e validações necessárias.
Publicação
Assim que a documentação estiver completa, ela deve ser migrada para a plataforma de publicação para lançamento. Essa tarefa é atribuída ao desenvolvedor front-end ou designer capaz de trabalhar em código. Atividades: Aqui é migramos toda a documentação e componentes deitos e construídos para a plataforma de publicação. Upload de ativos como imagens, modelos de design e demos interativos. Finalizando o código e demonstrações de exemplo.
4 Versões
O Design System será criado inicialmente baseado no Safra pessoa física como marca global. Na sequência serão adicionadas as necessidades específicas de cada produto filho dessa marca.
Cada caso terá os desdobramentos de versões necessárias, conforme esquema ao lado.
As versões a serem criadas serão para desktop / mobile, estilo varejo / refinado e claro / escuro.
Nomenclatura
Para ser suficientemente descritiva, uma linguagem tokenizada que incorpora taxonomia e tipologia precisa de muitos níveis. Níveis suficientes para organizá-los em grupos e atender todas os produtos envolvidos nesse projeto.
Sistemas diferentes aplicam níveis de maneiras diferentes.
Pela complexidade e importância das nomenclaturas para o sucesso do processo é crucial que o esquema decidido seja uma decisão tomada em conjunto entre o time de design e desenvolvimento.
Design principle pyramid
O Design Principles Pyramid é um Canvas para auxiliar na definição dos princípios do nosso Design System. É uma ferramenta onde podemos organizar o alinhamento entre equipes sobre o que é o Design System e parâmetros para o sucesso do componentes.
13 participantes
3 horas de WS
200 post-its
Design System Workflow
Épico Persistente
A categoria persistente representa o trabalho que estamos sempre fazendo:
Estilo visual, incluindo cor, tipo, espaço, tamanho, iconografia e muito mais.
Componentes de IU para corrigir, aprimorar, descontinuar ou adicionar.
Arquitetura técnica para melhorar os testes, ferramentas de construção, integração de aplicativos e outras partes técnicas além do código-fonte da própria biblioteca.
Operações para executar o programa e refinar como ele é executado.
Épico Formativo
Ao iniciar um sistema de design, grandes investimentos são necessários, mesmo se eles eventualmente se transformarem em negócios normais, como de costume. Como resultado, um período formativo também pode entregar épicos como:
Estratégia, apresentações, alinhamento multifuncional, solicitação de capacitação de equipe e assim por diante.
Coordenação dos primeiros usuários para descobrir, alinhar, colaborar e experimentar como o DS funciona.
Documentação para construir recursos para hospedar, modelar e renderizar diretrizes de design, exemplos de código e outras exibições.
Épico de crescimento e mudança
Esse épico, diferente dos outros, é voltado para mudar tópicos existentes.
Categorias de recursos emergentes, como Gráficos, Padrões de UX, Editorial como pares para estilo visual e componentes de IU.
Iniciativas principais para aumentar uma categoria existente, como uma expansão notável de componente de IU para navegação ou uma atualização de formulários.
Mudanças de design ou tecnologia que exigem estratégia, experimentos e gerenciamento de mudança, como no Figma ou componentes que já estão no ar.
Conclusao
O trabalho de implementação do Design System no Safra parte de um diagnóstico detalhado das inconsistências e padrões existentes para estabelecer uma base sólida e centralizada — o Design System Core — que sirva como referência para todas as equipes e produtos. Essa estrutura busca equilibrar autonomia e padronização, acelerando processos e garantindo consistência visual, sem abrir mão das identidades próprias de cada solução. Com diretrizes claras, bibliotecas bem definidas e alinhamento entre design e desenvolvimento, o objetivo é criar um ecossistema coeso que otimize a colaboração e fortaleça a experiência do usuário em todos os pontos de contato.
