Processo de design
Um bê-a-bá ou quase isso
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 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.
Esse processo é legal por que trás o conceito de divergir e convergir. Divergir é quando a gente abre, e convergir é quando a gente fecha.
Vamos detalhar o que é esperado em cada etapa.
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 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 ou 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.
Se você trabalha em um time B2C, sua solução deve ser mobile-first.
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.
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 estejam representados.
Use a função de auto-layout do Figma para acelerar seu processo. Se nunca usou, confira esse tutorial.
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 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
Esta etapa é obrigatória antes que qualquer artefato de design seja levado para um refinement/planning.
Como você verá melhor nos próximos capítulos, 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.
É 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.
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:
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.
Do
Encaixar a tarefa em um período de tempo. Exemplo: Vou matar essa Landing Page hoje à tarde. Se precisar, melhoro depois.
Don't
Não definir o tempo de uma tarefa. Exemplo: Vou ir fazendo essa landing até ficar perfeita.
Last updated
