Aprenda como utilizar o design system no Figma.

Figma

Uma vez dentro do ambiente **olist** no Figma, siga os próximos passos. Se você não tem acesso ao Figma, confira o [tutorial](https://app.callrox.com/playbook/27819).

Habilite as bibliotecas do Design System em seu arquivo por meio das bibliotecas da equipe.

Modal de ativação das bibliotecas compartilhadas no Figma.

**habilitando bibliotecas**

Os nomes das bibliotecas do exemplo podem estar defasados.

thumbnail_step_1.png

step_1.png

Para usar o Design System, comece com cores, textos, grids e sombras no painel de estilos e, a seguir, adicione um componente por meio da guia "assets".

Vídeo da interface do Figma criando uma página a partir da configuração dos estilos de texto, cor e adicionando componentes da biblioteca.

components.gif

O design system **olist** pode ser aplicado com diferentes temas. No Figma, é possível fazer mudança de tema automática para as propriedades de cor, sombras e texto. Outras mudanças são feitas nos próprios componentes utilizando bibliotecas locais. 

Faça download do plugin ”themer” na área de comunidade do Figma.

Vídeo tutorial para instalação do plugin themer no Figma. Inicia na página de comunidade, depois é feita a busca e o plugin é localizado na aba de plugins.

instaling themer.gif

Abra o plugin e adicione as configurações de API e Bin URL encontradas no Keeper em "Figma – Registro de bibliotecas", dentro da pasta "Product and Design Team". Se você não sabe acessar o cofre de senhas, confira a documentação: [acessar cofre de senhas](https://jira-olist.atlassian.net/wiki/spaces/DX/pages/2575532033/Uso+do+Password+Manager).

Vídeo da configuração do plugin. Usa-se o botão direito abrir o plugin. Depois, é inserido inserir a API Key e Bin URL nos campos de texto e salva-se as configurações.

setting.gif

Crie sua interface com os componentes das bibliotecas. Após isso, selecione a página e abra o plugin ”themer”. Escolha o tema desejado e aplique na tela.

No vídeo, duas telas do Figma são selecionadas. Abre-se o plugin "themer" e o tema venda base é selecionado. As telas mudam de cor.

using themer.gif

nome

O Design System **olist** é um produto ainda em desenvolvimento, gerenciado pela equipe de Plataforma Front-End para criar experiências multi plataformas incríveis e consistentes.

Visão Geral

A equipe é formada por designers e desenvolvedores dedicados a criar estilos, componentes, processos e documentação para o Design System. Para trocar uma ideia com a equipe, fale com a gente pelo canal #su-design-system no slack.

Empoderar os Olisters para criar experiências universais de maneira mais rápida, escalável e consistente.



Ter uma experiência coesa entre todos os produtos **olist** através do uso do Design System.

O Design é composto por 4 camadas principais de elementos:

- *Core Concepts* (conceitos base)
- *Foundations* (fundações)
- *Components* (componentes)
- *Experiences* (experiências)

Os *core concepts* são a base que norteia nosso Design System. Eles são nossa missão, visão e princípios, entre outros. Os *foundations* são os padrões agnósticos à tecnologia que nos ajudam a criar consistência em experiências multi plataforma , como tokens, *grids* e padrões de escrita. *Components* são elementos compostos por *foundations*, mas específicos por tecnologia. Por exemplo, botões, menus e campos de texto. Por fim, *experiences* são acordos que nos orientam a criar experiências incríveis e consistentes em todos os produtos.

Hoje, contemplamos apenas design tokens no novo Design System. Enquanto o novo Design System ainda está em construção, você pode usar a **[biblioteca united](https://united.olist.io/)** para construir novos produtos.

Gráfico composto por 4 círculos azuis que representam a estrutura dos elementos do design system. Na parte superior, um símbolo de coração dentro do círculo e a legenda “conceitos centrais” na lateral. Abaixo está um livro com a legenda “fundações”, depois uma caixa e a legenda “componente” e por fim um troféu com a legenda “experiências”.

**estrutura dos elementos do design system**

design_tokens_elements_structure.png

Você está em dúvida entre usar um componente do Design System ou um componente local? Elaboramos um fluxograma para ajudá-lo a decidir quando usar cada um.

Fluxograma sobre quando usar o Design System. A primeira pergunta é "A necessidade pode ser atendida por um componente do sistema de design?" em caso afirmativo, a resposta aponta para "Use o Design System", se não, a próxima pergunta é "Adicionar um recurso a um componente existente atenderia à sua necessidade?", em caso afirmativo, a resposta é "Peça esta melhoria" em caso contrário, vá para a próxima pergunta. ”O Componente pode ser reutilizado para outros produtos, se sim,” Solicite o novo componente ”, se não” Criar um componente local ”.

**fluxograma do processo de uso do Design System**

design_tokens_flowchart.png

Novas solicitações para o Design System devem ser feitas por meio **[deste formulário](https://forms.gle/GNzRitGh1XhyUEeh7)**. Se sua equipe desejar, pode contribuir com o Design System, seguindo os passos informados no formulário. Caso a equipe não consiga criar o componente, este será colocado no backlog do Design System e priorizado de acordo com as demais demandas da equipe.

Se o componente necessário não atender aos pré-requisitos do Design System, você pode criar um componente local em seu projeto. No Figma, copie o template da biblioteca de componentes locais chamado “[LC] Team Name”  da equipe olisteam e crie o seu componente. O desenvolvedor da sua equipe também criará esse componente na biblioteca local em desenvolvimento.

Para ajudar a orientar nossas decisões, usamos os princípios de design **olist** para criar premissas aplicadas ao time de Design System.

Princípios de design

O bom design é invisível. Certifique-se de enfatizar todas as possibilidades e tornar tudo tão fácil e simples a ponto de todos pensarem que é a solução óbvia para o problema. Tudo que você cria deve ser fácil de usar, aprender e encontrar. Em vez de "WOW", vá para "é claro". Como o aplicamos:

- Não nos prendemos à  criação de componentes totalmente sob medida. Preferimos que as pessoas identifiquem instantaneamente sua função.


Ainda melhor do que boas mensagens de erro é um design cuidadoso que evita a ocorrência de um problema. Elimine as condições sujeitas a erros ou verifique-as e apresente aos usuários uma opção de confirmação antes de se comprometerem com a ação. Como o aplicamos:

- Evitamos erros do usuário.

Ao projetar experiências, você deve considerar o contexto em que as pessoas estão. Que dispositivo elas estão usando? De qual lugar eles estão trabalhando? Quanto tempo eles têm para realizar esta tarefa? Projetar ótimas experiências vai muito além do digital. Como o aplicamos:

- Os componentes não precisam ser iguais em todas as plataformas, eles precisam apenas ser coesos para que possamos oferecer a melhor experiência mantendo a identidade da marca.
- Tornamos possível a experiência em todos dispositivos, independentemente de quão antigo, pequeno ou da velocidade da internet.

Consistência implica estabilidade. Cada decisão tomada no design deve ser previsível e confiável. Quando as coisas não combinam entre várias áreas, a experiência pode parecer desconexa, confusa e desconfortável. Como o aplicamos:

- Siga sempre as foundations de design e pense nos componentes como um todo.

Não há lugar para o ego. Um ótimo design só é possível quando toda a equipe faz parte do processo. Use suas habilidades de design para facilitar a criação de novas idéias e para criar um entendimento compartilhado em torno do problema. Uma colaboração próxima sempre trás a ótimos resultados. Como o aplicamos:

- Nosso processo deve ser transparente e colaborativo. Nós nos comunicamos para evitar retrabalho.

Design é sobre pessoas e trabalho em grupo

Não há necessidade de refletir para os usuários a complexidade de nossa operação. Mostre apenas as informações necessárias em nossos fluxos e mensagens, elimine ambiguidades e use um vocabulário acessível. Como o aplicamos:

- Queremos tornar a jornada do usuário mais fácil, não importa o cliente.
- Documentamos para as pessoas.
- Visamos uma comunicação simples e clara.

Tomamos decisões com base em dados. Embora entendemos os problemas e complexidades, não somos os usuários reais. Dados qualitativos e quantitativos estão disponíveis para apoiar decisões importantes. Como o aplicamos:

- Use dados para justificar decisões de design.

Acessibilidade é sobre criar experiências que possam ser utilizadas por todos, com boa usabilidade. Como o aplicamos:

- Seguimos WCAG para criar experiências acessíveis.
- Priorizamos a usabilidade para todos antes de novos recursos para alguns.
- Tornamos a experiência possível em todos os idiomas.

Torne universal (específico do Design System)

Princípios de Design

Acompanhe os últimos lançamentos do Design System e mantenha seu projeto sempre atualizado.

Novidades

Últimas modificações feitas no Design System. Todas nossas bibliotecas seguem o mesmo número de versão, mesmo que algumas entregas não sejam pareadas. 

Para acompanhar o planejamento do time, confira nosso [roadmap](https://jira-olist.atlassian.net/jira/software/c/projects/FEP/boards/639/roadmap).

About

Aprenda a instalar design tokens no seu projeto.

Design Tokens

Para instalar nossos tokens de design, você só precisa executar em seu projeto:

código para instalar o pacote de tokens do design system olist

Usamos tokens em vez de valores codificados para garantir uma melhor consistência da interface do usuário e para tornar uma experiência perfeita para nossos lojistas em todos os diferentes produtos e plataformas. 
Temos três camadas de tokens, sendo elas:

1. Base tokens 
2. Theme tokens 
3. Component tokens

Você pode importar todas as camadas de nossos tokens de design do módulo npm:

*os component tokens fazem parte do objeto `themes`.*

código para importar tokens do pacote design system olist javascript

Basta importar o `.scss` da camada de token desejada e ele trará um conjunto de variáveis ​​sass para estilizar seus elementos.

código para importar tokens do pacote design system olist sass

exemplo de variável de token sass aplicada a um código sass

Código para importar o pacote de tokens de tema sass olist design system

exemplo de variável de token de tema sass aplicada a um código sass

Todos os *component-tokens* estão incluídos nos arquivos de tema, por isso, importe um arquivo de tema para poder utilizá-los.

Você pode encontrar os *component-tokens* disponíveis dentro da página do componente correspondente, na seção "componentes" no menu de navegação. No caso dos *component-tokens* de texto, eles estão na seção "tipografia" dentro de "fundamentos"

exemplo de variável de component tokens aplicada a um código sass

Design tokens

Getting Started

Cores

Espaçamento

Sombras

Texto

border radius

opacidade

Foundations

visão geral

Default

Large

Typography

Nossos ícones visam ajudar encontrar a informações na interface e realizar tarefas.

iconografia

Ícones são uma representação gráfica de objetos ou ações.

No olist, utilizamos o tamanho padrão de 24px os ícones, que podem ser escalados para adequar melhor na interface. Eles devem seguir uma grid padrão, encontrada na biblioteca do Figma, e utilizar espessura de 2px.

Ícone de editar. No fundo, a grid usada para criar o ícone. Destaque na espessura de 2px do ícone.

**formatação dos ícones**

Ícone utilizando a grid padrão e com espessura de 2px.

icons_formating.png

O ícone deve ser usado como elemento auxiliar a interface na maior parte das vezes, para facilitar o reconhecimento das funções. Somente alguns ícones podem ser usados sem o auxilio de texto, estes estão classificados como ícones ”conhecidos”.
\
\
Caso o ícone seja usado sem o texto auxiliar, esse ícone deve possuir descrição para leitor de tela.

Use o theme provider para compartilhar configurações globais de temas em todos os componentes.

Theme Provider

Primeiramente, importe o componente `ThemeProvider` e envolva toda sua aplicação:

código importante o ThemeProvider do pacote olist design system

A partir de agora você pode utilizar qualquer um de nossos componentes ou propriedade do tema na sua aplicação.


Utilizando o `ThemeProvider` é possível acessar a propriedade `theme` que é injetada em qualquer *styled component* e também é possível utilizar com o [hoc "withTheme" do styled-components](https://styled-components.com/docs/advanced#via-withtheme-higherorder-component) ou através do [hook "useContext" do react](https://styled-components.com/docs/advanced#via-usecontext-react-hook) Dessa forma, você consegue utilizar fora de um *styled-component*.

Uma coisa importante para se notar é a presença da palavra-chave "olist" antes das propriedades do objeto `theme`. Para evitar conflitos com outros temas ou `ThemeProviders` que você possa estar utilizando na sua aplicação, nós prefixamos nosso tema com a palavra `olist`. Então, confira se está acessando essa palavra-chave antes de acessar qualquer propriedade do tema.

utilizando o theme dentro de um styled-component

exemplo utilizando o tema com o hoc withTheme

Utilizando o tema com o hook `useContext`:

exemplo utilizando o tema com o hook useContext

Você pode encontrar todas as propriedades disponíveis no objeto `theme` em sua respectiva página dentro da seção "fundamentos". Na página de "cor" você irá encontrar todos o detalhes, como usar e as definições de _tokens_ e tema, por exemplo.

Button é um elemento usado para indicar uma possível ação na interface.

button

Botão cinza com cantos arredondados. Sobre o texto está destacado o item 1 e sobre o ícone está destacado o item 2.

1. **Label:** pequeno texto que indica a ação executada pelo botão.
2. **Icon:** ícone que auxilia na identificação da função do botão.

label_button.png

Botões são usados para indicar uma possível ação na interface, como completar um formulário, deletar um item ou completar uma compra. 

variações

estilos

Na web, deve-se utilizar a combinação texto e ícone na maior parte das vezes, ajudando assim a identificação da ação. O uso e posicionamento dos ícones é indicado na tabela a seguir:

- A distância horizontal entre botões deve usar o token $spacing-inline-small e a distância vertical deve usar o token $spacing-stack-1xsmall.
- A margem mínima dos botões para outros elementos deve ser de 16px.
- O botão fica posicionado ao final do conteúdo da página.  
- Botões de navegação devem ficar alinhados à direita, com excessão dos botões de voltar ou cancelar que devem ficar a esquerda.

- Utilizar verbo no infinitivo.
- Deixar claro a ação (”Como usuário, eu quero ").
- Utilizar todas letras em caixa baixa.
- Consistente com o título e a descrição da ação.
- Evitar artigos.
- Evitar uso de palavras em inglês.
- Ser direto e evitar quebra de linha.

Modal é uma janela que aparece por cima da tela principal para prover uma informação importante no fluxo.

modal

1. Header: representa o topo da modal, contendo título, subtitulo (opcional) e botão para fechar a modal.
2. Content: é a parte interna da modal. O conteúdo desta parte pode variar conforme a necessidade de cada time.
3. Footer: é a base da modal, onde estão localizados os botões de ação.

modal_formating.png

A modal é usada contextualmente, após uma interação na interface (como acionar um botão), para dar foco a uma informação ou ação que precisa ser realizada naquele momento.

tamanho

A modal deve ser alinhada no centro da página até atingir sua altura máxima (80% resolução da tela), quando passa a ter rolagem no conteúdo interno. 

modal_group_alignment.png

- O conteúdo da modal deve ser sucinto e propositivo, pois o uso da modal interrompe o fluxo principal da aplicação.
- Não deve ser mostrada para indicar erro ou sucesso.
- Na variação large, intercale o uso de texto com outros componentes para facilitar a leitura.
- Não abra uma modal por cima de outra. 

Components

Você precisa de ajuda da equipe do Design System ou encontrou algum erro? Entre em contato.

Suporte

O Design System ainda está em construção e entendemos que algumas funcionalidades podem ainda não estar prontas e que podem apresentar alguns erros. Portanto, ficamos felizes que seja reportado qualquer problema que surgir. Nesse caso, escreva-nos através do canal ```#su-design-system ``` ou ```#su-front-end-platform``` que iremos adicionar a demanda ao backlog (bug sempre são priorizados em nossa sprint).


Se existir necessidade de novos componentes que não estão priorizados em nosso backlog, é possível criá-los localmente nos projetos utilizando nossos design tokens. Esses componentes também devem ser mapeados nas bibliotecas locais dos times no Figma.

Para mais detalhes sobre como utilizar componentes locais, leia a documentação: [componentes locais](https://jira-olist.atlassian.net/wiki/spaces/DX/pages/2810707972/Solicita+es+externas).

Figma

índice

bibliotecas de equipe

passo 1

passo 2

temas

Passo 1

passo 2

passo 3