# Processo de design ![](https://3964539261-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZZdfaW29jJwq55yaxn%2F-M_VrtlCyOVQzO3oEkEI%2F-M_VsFl44ZD2iEHCWHsD%2Fprocesso%20de%20design.png?alt=media\&token=ffc11746-c74c-4f00-a99c-649315fd1c5c) ## Introdução Ter um processo claro de design nos ajuda a dar visibilidade e garantir consistência entre os diferentes níveis de entrega.\ \ Garantir essa previsibilidade não é positiva apenas pra nós, como também para os times que trabalham próximos: growth, tech e produto. ### Então, todo mundo tem que trabalhar igual? Não. No fundo, cada um tem o seu jeitão de fazer design. E essa que é a graça.\ \ O processo não precisa ser sempre seguido ao pé-da-letra, mas continua sendo importante pra termos visão e expectativas alinhadas. Aliás, bem sabemos que o processo de design de produtos digitais não é linear. Aqui tem [um texto bem legal](https://cwodtke.medium.com/designs-unsexy-middle-bits-a8cc17f0246d) que explica isso melhor. ## Diamante duplo O Double Diamond é um processo de design criado em 2005 pelo British Design Council, instituição sem fins lucrativos do Reino Unido que trabalha desenvolvendo programas e pesquisas que abrangem o design do setor público, na inovação social, e nos negócios. Usaremos ele como base para documentar e detalhar o nosso processo. {% hint style="info" %} Esse processo é legal por que trás o conceito de divergir e convergir. Divergir é quando a gente abre, e convergir é quando a gente fecha. {% endhint %} Vamos detalhar o que é esperado em cada etapa. ![As quatro etapas do diamante duplo: descobrir, definir, desenvolver, entregar](https://3964539261-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZZdfaW29jJwq55yaxn%2F-M_CHkbTI5s8nSorEJUt%2F-M_CJFoNNs9eph-ZRZLq%2Fimage.png?alt=media\&token=6ed89772-4002-4eb8-a676-33742b526c88) ![Nossa versão do diamante duplo.](https://3964539261-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZZdfaW29jJwq55yaxn%2F-M_CHkbTI5s8nSorEJUt%2F-M_CTBg_mkzfC08Pl1Tv%2Fimage.png?alt=media\&token=444bbae8-c297-4b63-b012-10fd62a695ca) ## 1. Descobrir A etapa inicial, onde divergimos em cima de qual problema vamos resolver, e suas possíveis soluções. É um momento mais exploratório. Porém, pode ser contra-produtivo começarmos já explorando. Precisamos definir melhor o problem space. ### 1.1 Definição de escopo Nessa etapa, alinhamos com a pessoa de produto do time, para que esteja bem claro qual problema vamos resolver. Por isso, não avance enquanto não [documentar](https://revelo.gitbook.io/playbook/introducao/configuracao-de-experimentos) sua hipótese. ### 1.2 Conteúdo e referências Aqui, vamos definir, em baixa fidelidade, que conteúdo vai em cada tela. Você pode fazer um wireframe, ou fluxograma, pra exemplificar melhor. Essa também é a etapa em que fazemos **Benchmarking**, não só de ferramentas do mercado, mas de fluxos e soluções análogas. Não precisamos reinventar a roda. > "Bons artistas copiam. Grandes artistas roubam."\ > Pablo Picasso Nesta etapa, usamos o [Whimsical](http://whimsical.com) ou [FigJam](https://www.figma.com/figjam/) para prototipar. O fato de eles terem opções bem limitadas nos ajuda a pensar em qual é a essência da história que vamos contar. {% hint style="info" %} Se você trabalha em um time B2C, sua solução deve ser mobile-first. {% endhint %} {% hint style="info" %} Evite pular direto pro Figma e prototipar por lá, mesmo lo-fi. O Figma tem outro nível de abstração, o que faz com que a gente se preocupe com as coisas erradas, antes da hora. Não é o momento de pensar em componente, cores, diagramação e afins. {% endhint %} ![Exemplo de prototipação lo-fi.](https://3964539261-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZZdfaW29jJwq55yaxn%2F-M_CHkbTI5s8nSorEJUt%2F-M_CLtiV2yYDph0s45Lb%2Fimage.png?alt=media\&token=1dd19424-f37d-4a87-abba-d16b5a76f1be) Explore opções e abordagens diferentes de conteúdo. É legal ir alinhando com PM, para os poucos começarmos a convergir em um fluxo final. ### 1.3 Prototipação no Figma Agora que você definiu uma linha mestra, podemos começar a pensar na interface. Esperamos que você estresse bastante a solução, de forma que os [Princípios de Design](https://revelo.gitbook.io/playbook/design/untitled-2) estejam representados. {% hint style="info" %} Use a função de auto-layout do Figma para acelerar seu processo. \ Se nunca usou, [confira esse tutorial](https://www.youtube.com/watch?v=PNJxeD29ZTg). {% endhint %} ![Estresse bem a solução antes de convergir.](https://3964539261-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZZdfaW29jJwq55yaxn%2F-M_CHkbTI5s8nSorEJUt%2F-M_CQ8fQJowFh3oXWTmR%2Fimage.png?alt=media\&token=4b676e57-d8e0-49f3-8c4a-6c0bfb4a102f) ## 2. Definir ### 2.1 Fechar um protótipo navegável Defina com PM qual dos caminhos vocês vão seguir. Se quiser, pode envolver a pessoa tech lead da squad nessa conversa também, para cortar caminho e entender o que é viável tecnicamente. ### 2.2 Testar Testar com uma pessoa é melhor do que com nenhuma. Só não vale testar com colega do squad, geralmente essa pessoa já tem muito contexto. É possível entrevistar pessoas de dentro da Revelo. Conte com os times de SDR, Sales, CS e CX nessas horas. Se for entrevistar pessoas de fora, é só informar na [Weekly](https://revelo.gitbook.io/playbook/cerimonias-1/cerimonias#weekly-design-chapter) e o time de Design OPS te dá uma força no recrutamento. ## 3. Desenvolver Depois de testar e fazer os devidos ajustes, é hora de começar a preparar o arquivo para o time de tech. ### 3.1 Design Review {% hint style="warning" %} Esta etapa é obrigatória antes que qualquer artefato de design seja levado para um refinement/planning. {% endhint %} Como você verá melhor nos próximos capítulos, [Design Review](https://revelo.gitbook.io/playbook/cerimonias-1/cerimonias#design-review) é o momento onde criticamos a solução como time. Ela é feita sob-demanda. Se precisar de uma DR, só chamar o time no canal e quem puder participar, participa. Aliás, você pode pedir uma design review em qualquer etapa do processo. Ela só é obrigatória antes de levarmos pra tech, mesmo. ## 4. Entregar ### 4.1 Refinement/planning Agora sim é o momento de levarmos a solução pro time de tecnologia dar sugestões e feedbacks. Participe desses papos de coração aberto e não espere que as pessoas entendam de design tão profundamente quanto você. É por isso que você está no time! Então traduza seus conceitos e evite falar "designês". Se você seguir esse processo, sem dúvida vai chegar nessa etapa com bastante segurança de qual deve ser o caminho a ser seguido. {% hint style="warning" %} É normal que as pessoas do time às vezes "emburaquem" em discussões muito específicas, e às vezes não tão relevantes. Você pode levantar essa bandeira sobre discutir esse detalhe depois em um quórum menor. {% endhint %} ### 4.2 Preparar para tech Etapa final. Após fazer os ajustes necessários, nós preparamos o arquivo para o time de tech. Evite entregar apenas o "caminho feliz". Este fluxo final deve ser inserido no arquivo de Specs, que fica no Figma do seu time. Ele é a fonte da verdade para o time de tech. Pense também nos seguintes cenários: * [x] Nenhum conteúdo (blank state) * [x] Pouco conteúdo * [x] Muito conteúdo (paginação, scroll, etc) * [x] Componentes prontos/atualizados no Figma * [x] Permitir que se crie, leia, atualiza e delete informações (CRUD) * [x] Versão mobile (principalmente em times b2c) * [x] Protótipo está dentro do grid * [x] Mensagens de erro e sucesso * [x] Acessibilidade (contraste, descrição das imagens, etc) ## Um diamante por semana Qualquer atividade criativa pode ser estendida indefinidamente. Sabe aqueles projetos que nunca acabam? Então. Afinal, a gente é de humanas, né? Tudo vai depender do seu nível de senioridade, mas via de regra, tente passar por todo esse fluxo em no máximo duas semanas. Isso vai te ajudar a dar ritmo para o trabalho. {% hint style="success" %} **Do** Encaixar a tarefa em um período de tempo. \ Exemplo: Vou matar essa Landing Page hoje à tarde. Se precisar, melhoro depois. {% endhint %} {% hint style="danger" %} **Don't** Não definir o tempo de uma tarefa.\ Exemplo: Vou *ir fazendo* essa landing até ficar perfeita. {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://revelo.gitbook.io/playbook/design/processo-de-design.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.