Manual de criação de componentes

🔸 = Obrigatório

Necessidade

  1. Identifique quais informações serão necessárias o máximo possível no processo de wireframe (e guarde para apresentar ao time); 🔸

Wireframe é muito importante para filtrar todas dúvidas sobre a estrutura do componente e do projeto. Lembre-se que o objetivo do componente é servir ao projeto e ao Kósmos. E que um componente já documentado tem um motivo para ser como ele é.

  1. Busque dentre os componentes atuais, quais tem o contexto e estrutura que permitem ser utilizados para encaixar as informações; 🔸

  • Caso não encontre nenhum componente que a estrutura funcione com as informações necessárias, siga diretamente para o passo 5;

  • Em caso de documentação de componentes já existentes para o “Kósmos - UI Kit”, procurar ao máximo unificar em um único componente aqueles que tem uma estrutura exatamente igual.

  1. Teste aplicar as informações no componente escolhido (e guarde para apresentar ao time). A partir do teste:

  • Caso o componente funcione com as informações necessárias em uma estrutura coerente, não haverá necessidade de modificações, siga em frente com o projeto;

  • Caso o componente funcione em partes, mas necessite de modificações, siga em frente com o manual.

  1. Tente identificar no mínimo 3 casos de uso em que ele é aplicado em layouts e guarde para apresentar ao time; 🔸

  • Guarde em que layouts esses componentes são aplicados para serem atualizados ao final do processo do componente.

  1. Para cada componente que necessitar criar/modificar, crie um post no fórum no discord de “Kósmos Request” contendo as seguintes informações:

  • Título:

    • 🌱 Novo componente (Atualizar o título com o nome do componente quando definir nos steps posteriores)

    • ⚠️ Modificação <Nome do componente>

    • 🗂️ Documentação <Nome do componente>

  • Adicione ao post a tag de 🔍 Necessidade;

  • Explique ao máximo o seu objetivo com o componente e marque a tag @Designers/Produto;

  • Explique de onde se originou essa demanda;

  • Explique quais informações você necessita colocar no componente;

  • Mostre o planejamento de estrutura feito em um wireframe;

  • Mostre quais são os componente mais próximos atualmente;

    • Mostre como ficaram os testes com esses componentes;

  • Mostre em quais contextos de layout esses componentes são aplicados atualmente, em caso de modificação de um componente já existente;

  • Mande o link do arquivo Draft no Figma em que você junto as informações para melhor entendimento;

  • Deixe disponível emojis (✅ e ❌) selecionados no post para voting*;

    • Sempre que possível, sugira outra solução (Deixe disponível emojis (✅ e ❌) selecionados no post para voting.);

      • Caso você seja uma das pessoas que não aprovou no voting, argumente obrigatoriamente sempre o porque;

    • Seja atencioso e tente entender os argumentos contrários;

    • Os demais integrantes do time devem ficar atentos as novas soluções sugeridas para mudar o voto caso concordem com a nova solução.

A resposta de todos do time é obrigatória durante o horário de trabalho

  1. Caso haja concordância da maioria do time, e com base em tudo selecionado até o momento no processo de Necessidade (Wireframe, Componentes semelhantes, locais de aplicação, etc), prossiga para o processo de Criação;

Criação

Adicione a tag de 🛠️ Criação no post desse componente no "Kósmos Request” e comente “Componente passou para o step de Criação”; 🔸

  1. Em caso do componente já existente estar sofrendo uma modificação, copie o componente do arquivo "Kósmos - UI Kit” para o seu arquivo Draft; 🔸

Dica!

Neste step de Criação, não há a necessidade de focar nas nomenclaturas, layers, propriedades, etc. Estes pontos serão vistos no step de Validação. O foco nesses pontos deve existir após a aprovação do projeto, para que não ocorra retrabalho caso a solução apresentada não seja aprovada.

  1. Identifique dentre quais Skins e Interaction states se aplicariam a este componente;

  2. Identifique as variantes necessárias do componente, pelo processo de wireframe principalmente, para uma construção separada das mesmas; 🔸

  • Utilize componentes para as partes internas que se repetem, criando ou reutilizando já existentes. Isso ajuda na performance, não necessita recriar o código no desenvolvimento e garante padronização visual. Caso crie um componente de uma parte interna, lembre-se q ele é um componente e deve passar por todo esse processo das regras;

  • Para casos de uso que necessitem de regras e/ou estruturas próprias, crie variantes.

  1. Construa sempre o componente em autolayout; 🔸

  • Essa feature nos permite ter componentes agnósticos e responsivos;

  • Essa feature é bom próxima da forma em que o componente é codado.

  1. Construa o componente sempre na forma mais agnóstica o possível; 🔸

  • Isso permite uma reutilização do componente em diferentes casos de uso, evitando criação de vários outros componentes e garantindo uma maior padronização.

  1. Mantenha-se alinhado com os times de desenvolvimento sobre o componente. É de extrema importância confirmar com o time de desenvolvimento se o componente pode ser produzido, como está sendo a estrutura e qual a dificuldade técnica, evitando:

  • um excesso de trabalho para um projeto considerado urgente;

  • componentes que tem um dificuldade técnica grande;

Grandes feedbacks do desenvolvimento deverão ser alinhados ao design antes do step de Validação e Documentação para evitar retrabalho.

  1. Faça uma Critique;

  • Analise quem você pretende chamar para a reunião e a partir disso escolha se irá fazer uma critique junto ao projeto ou separado;

    • Se você necessita de pessoas específicas para a critique do projeto (CEO, Product Manager, Gerencia, Designers que participaram do projeto anteriormente, etc) faça uma critique do componente separada ao projeto;

    • Se acontecer de ter uma critique separada do componente, certifique-se de realiza-la antes da critique do projeto.

  • Nessa critique o foco é somente no que será necessário para a entrega do projeto, a User Interface; Neste step de Criação, não há a necessidade de focar nas nomenclaturas, layers, propriedades, etc. Estes pontos serão vistos no step de Validação.

  1. Atualize e depois aprove com o restante do time comentando no post deste componente no forum do discord "Kósmos Request”: 🔸

  • Mostre os casos de uso e as propriedades do componente;

  • Deixe o link do arquivo para que o restante do time possa deixar comentários adicionais;

  • Deixe disponível um emoji de check (✅) para que o time possa selecionar e indicar que está ciente que o componente está sendo criado;

Sempre que o componente for modificado durante esse processo, peça novos feedbacks (Critiques, Design Reviews e atualizações no post do Discord) e mantenha o time atualizado.

  1. Caso haja concordância da maioria do time e o componente esteja alinhado com os objetivos do produto, prossiga para a entrega do projeto, ou para o processo de Validação se o projeto for focado no componente. 🔸

  • A partir da entrega do projeto:

  • Caso o componente seja substituído ou modificado, retorne aos processos anteriores de Necessidade ou Criação;

  • Caso o projeto seja aprovado, sem nenhuma modificação requerida para esse componente, avance para o step de Validação;

Validação

Adicione a tag de 💬 Validação no post desse componente no "Kósmos Request” e comente “Componente passou para o step de Validação”; 🔸

  1. Verifique e organize a Estrutura do componente; 🔸

  • Autolayout - Siga o manual de boas práticas;

  • Layers - Siga o manual de boas práticas.

    • Nos demais componentes (Instance Components) que estão dentro do "Main Component", modifique a nomenclatura das layers desse componentes de acordo com situação:

      1. Quando o componente interno faz parte de uma função do "Main Component" e tem um nome muito específico, modifique a nomenclatura do componente de acordo com a sua função. Por exemplo, um ícone de placeholder teria originalmente o nome de "Placeholder Icon" e no Button Component a layer poderia ser mudada para "Left Icon";

      2. Quando o componente interno já tem um nome que não muda de acordo com a sua ação no "Main Component", deve-se manter a nomenclatura do componente.

  1. Verifique e organize as Nomenclaturas sobre componente; 🔸

  • Nomenclatura das Layers - Siga o manual de boas práticas.

  • Nomenclatura das Properties - Siga o manual de boas práticas;

  • Token do componente - Siga o manual de regras;

  • Nomenclatura do Componente - Siga o manual de regras;

  1. Se achar necessário, confira o componente em uma Design Feedback;

  2. Faça no mínimo uma Review exclusiva do componente antes da Review final do projeto; 🔸

  • Chame 2 ou mais Designers para Review do componente;

  • Nessa review o foco é na Estrutura, Nomenclaturas e Propriedades de UI.

  1. Atualize e depois aprove com o restante do time comentando no post deste componente no forum do discord "Kósmos Request”: 🔸

  • Descreva que o projeto e a solução para o componente foram aprovados;

  • Mostre o componente;

  • Mostre as propriedades do componente;

  • Deixe disponível um emoji de check (✅) para que o time possa selecionar e indicar que está ciente que o componente está sendo criado;

  • Deixe o link do arquivo para que o restante do time possa deixar comentários adicionais.

Ao disponibilizar o link do arquivo para comentários adicionais do time, deixe claro sempre que o foco deverá ser na padronização de Estrutura, Nomenclaturas e Propriedades de UI. Qualquer sugestão de mudanças deve ser feita no step anterior de Criação.

  1. Marque uma validação e apresente o componente aos times de desenvolvimento da plataforma em que o componente é utilizado;

  • Selecione para a reunião o gerente do time de desenvolvimento e ele irá escolher quem do time irá participar;

  • Explique ao desenvolvedor todos os motivos que lhe levaram a criar, ou modificar um componente, identificados no processo de Necessidade;

  • Apresente ao desenvolvedor como ficou todos os pontos relacionados as Estruturas, Nomenclaturas e Propriedades de UI do componente, mostrando o componente nas versões Master e Main.

  • Boas práticas

    Em casos de modificações requisitadas pelo desenvolvedor, tente sempre entender os motivos e argumentos da solicitação para avaliar a necessidade de uma modificação.

  1. Caso haja um alinhamento geral do time de Design e com os times de Desenvolvimento, prossiga para o processo de Handoff.

  • Caso não haja concordância, integre mais uma pessoa na decisão. Gerente de Design ou de Desenvolvimento (Caso o desenvolvedor da reunião não seja o gerente).

Handoff

Adicione a tag de 🗂️ Handoff no post desse componente no "Kósmos Request” e comente “Componente passou para o step de Handoff”; 🔸

Figma

  1. Realize a documentação/atualização do componente criado no draft para o arquivo Figma “UI Kit”;

Se você não encontrar uma página que faça sentido, alinhe com o time pelo Kósmos Request para descobrir em qual página podemos usar ou criar.

  1. Para atualizar um componente já existente/documentado no Kósmos UI Kit, em relação ao componente criado no draft, e sincronizar arquivos handoff com as mudanças, siga um dos dois caminhos: 🔸

  • Em caso de modificações leves (com modificações em espaçamento, radius, border, tamanho de fonte, etc), modifique/atualize a estrutura no componente já existente e documentado no “Kósmos - UI Kit”;

  • Em casos de modificações grandes, como uma nova estrutura completamente diferente ou a unificação de todas plataformas em um só, documente o componente como se fosse um novo. Isso demandará aplicá-lo novamente em todos outros componentes e arquivos de layout/handoff em que ele é utilizado.

  1. Organize as "Variants" e "Properties" de acordo com as regras documentadas no nosso manual;

  2. Construa/atualize as imagens de ilustração de regras, documentadas juntas ao componente no arquivo Figma “UI Kit”, para serem utilizadas depois na documentação do componente no Supernova;

  • Siga o template pré-estabelecido de imagens localizado nas nossas toolkits. (Puxe a estrutura componentizada e dê detach para modificação.);

  • Utilize outros componentes já documentados, e o Material Design, como base para a criação dessas imagens;

  • Utilize sempre a versão instance component, e não o componente principal, para que as imagens sempre fiquem atualizadas.

Not found

  1. Após finalizar de documentar o componente e as imagens, atualize e depois aprove com o time no "Kósmos Request” antes de publicá-lo;

  2. O publish do componente deve descrever:

  • Em formato de tag se ele é novo, se é apenas uma documentação ou um existente que foi modificado;

    • [Novo Componente]

    • [Documentação de Componente]

    • [Atualização de Componente]

  • Nome do componente;

  • O que foi feito no componente e porque;

Exemplo:

  1. Nos casos de atualização do componente em layout pós publicação:

  • Se a tarefa/issue estiver focada na construção/atualização de um componente, por exemplo criar uma nova versão do card de curso, o designer deve identificar e atualizar os layouts em que o componente é aplicado.

  • Se o projeto abranger fluxos, telas e outros elementos, além de um componente, quem entrar em um arquivo de handoff posteriormente e realizar o update do componente, ficará responsável por verificar se o layout foi alterado ou não. Se foi alterado, procure corrigir o alinhamento, os espaçamentos e qualquer outro erro que a atualização possa causar.

  1. No componente no Figma adicione uma descrição breve e resumida no campo de "Description”, contendo:

  • O que ele é e o que ele faz;

  • Informações de uso (Quando extremamente necessário);

  • Do's & Don'ts (Quando extremamente necessário);

  • Palavras-chave no campo de descrição do componente que também o identifiquem, para tornar mais fácil a busca nos assets no Figma.

  1. Atualize o time de design no nosso canal/fórum “Kósmos Request” de que o componente foi publicado e mande os links dos arquivos em que o componente foi atualizado.

GitBook

  1. Escolha um dos caminhos caso o componente seja novo ou uma modificação:

Não realize mudanças diretamente no Gitbook do Kósmos! Crie uma branch e valide as alterações com o time antes de publicar.

  1. Caso o componente seja novo e suas informações não estejam documentadas no Gitbook, utilize o modelo de documentação como base para construir o manual do componente do zero. Todos os pontos marcados com asterisco (obrigatórios) devem ser preenchidos;

Em caso de novos componentes, ou documentação, crie uma nova página para documentar o componente quando for passar as informações para o Gitbook. Não mude o que está documentado na página “Modelo de documentação”.

  1. Caso o componente esteja recebendo uma atualização e já esteja documentado no Gitbook do Kósmos, utilize o modelo de documentação como base para identificar quais pontos necessitam ser modificados a partir da atualização do componente.

  2. Atualize e depois aprove com o restante do time a proposta de documentação escrita para o Notion do Kósmos, comentando no post deste componente no fórum do discord "Kósmos request”;

  3. Substitua/adicione as imagens no Gitbook;

  4. Adicione ou edite a data de atualização do componente na página do componente e no Histórico de atualizações;

  5. Ao finalizar, atualize e depois aprove com o time enviando o link da documentação final;

GitHub

  1. Para finalizar o processo de Handoff do componente, documente tudo o que foi feito até o momento em uma issue no repositório "Kósmos” do GitHub;

Deverá ser aberto uma issue separadamente para cada componente modificado ou criado

  1. Nessa issue deve conter:

  • Uma descrição resumida com pelo menos três tópicos explicando quais foram os motivos para o componente necessitar aquela modificação ou ser criado;

  • Link para documentação dele no Figma;

  • Link para documentação dele no Supernova;

  • Sempre linkar o "Milestone” referente ao componente;

  • Marcar os gerentes de desenvolvimento com "@”.

Histórico de Atualizações

Figma
Gitbook
Android
iOS
Web

N/A

11/11/1111

N/A

N/A

N/A

Percebeu um erro, ficou com dúvida ou tem uma sugestão?

Contribua com o Kósmos preenchendo nosso formulário de contribuição — sua colaboração ajuda a tornar o Design System mais claro, útil e evolutivo para todo o time.

AnteriorAsset linkPróximoManual de criação de assets

Atualizado