Onde tudo começou

Como designer de produto dentro da tribo de Logística, é parte do meu cotidiano participar de alguns rituais de alinhamento e compartilhamento de ideias/projetos. Em um desses rituais, carinhosamente chamado de sync [I wonder why ????], é nosso costume debater um artigo lido durante a semana… e é justamente aí que a história começa de fato.

No início deste ano, especificamente no mês de março, conversamos sobre um artigo cujo assunto era organização do Figma. Quanto mais avançávamos na discussão, mais claro ficava o fato de que precisávamos urgentemente padronizar nossa forma de organizar os nossos arquivos.

Saindo da reunião, fui conversar com designers de outras tribos do iFood para ver como a organização era tratada dentro de cada contexto e, incrivelmente, o assunto foi evoluindo, mais e mais pessoas foram se envolvendo, ele virou um projeto e, o que era pra ser focado apenas na nossa tribo de Logística, ganhou proporções iFood.

Após 2 meses e meio de trabalho, 8 encontros e muitas horas de debates, pesquisas e testes com possíveis layouts, chegamos aos resultados finais.

Mas antes… Discovery neles!

Como todo bom processo de descobertas, iniciamos o nosso com… pesquisa! Dado o contexto de que o Figma é acessado/usado por designers, ilustradores, desenvolvedores, revisores de texto, PMs e muitos outros profissionais, soltamos uma survey que ficou circulando por 2 semanas em cada contexto/tribo do iFood e, em complemento, conversamos pontualmente com mais profundidade com alguns desses profissionais já mencionados acima (PMs, devs e designers, researchers, etc).

Com os resultados tabulados previamente por cada representante das tribos, seguimos com a clusterização geral e levantamento de insights a partir dessas informações. Essa tarefa se mostrou algo relativamente fácil, visto que de uma forma geral, o padrão de resposta se mostrou bastante consistente. Os problemas eram recorrentes em todos os contextos.

Aqui eu paro um momento para contemplar a beleza do trabalho em equipe que a imagem a seguir expressa:

Os principais clusters encontrados foram:

1. Eventos // manutenção de eventos
2. Regras de negócio
3. Localizar um arquivo
4. Componentização
5. Comentários no Figma
6. Material design
7. Benchmarks e referências a outros lugares
8. Protótipo
9. Versionamento
10. Problemas/dificuldades no Figma como ferramenta
11. Especificações para o desenvolvimento

A partir destes clusters, levantamos os principais insights que consideramos relevantes para destacar e trabalhar como pontos de melhoria:

1. Com a crescente demanda de trabalhos cross, a diferente organização entre as tribos (e, às vezes, variações de designer para designer) se mostra ainda mais problemática, dificultando o processo de acesso aos trabalhos como um todo.
2. Muitas pessoas se baseiam no Figma para saber o que está ou não em produção ou pronto para desenvolvimento. Como garantir que cada projeto tenha as informações e status atualizados?
3. Há uma dificuldade latente para encontrar projetos. Uma mesma feature pode ser designada por 2 ou até 3 nomes diferentes, sem contar com a mistura de inglês e português.
4. E quando há necessidade de falar com os envolvidos em um projeto? Se você não tem um contexto prévio, será um trabalho a mais, principalmente em projetos mais antigos.
5. Design no Figma não está isolado do resto do mundo [risos], outros processos de discovery, protótipos, produto e desenvolvimento também fazem parte do ciclo de vida do produto como um todo. Como garantir que haja conexão entre todas as pontas?

Nem preciso dizer que o escopo do projeto de organização tinha ganhado corpo.

A próxima etapa foi definir quais ações poderíamos tomar apenas com organização, para contemplar os pontos acima destacados. Quatro pontos principais surgiram:

1. Capa principal
2. Nomenclatura de arquivos
3. Layers internos
4. Capa interna

Desenhos e testes

1. Capa principal

Justamente por ser a “cara” de um projeto dentro do Figma, este layout deveria conter informações essenciais para um bom reconhecimento e conexão do que se está buscando com o arquivo em questão. Dessa forma, definimos os seguintes dados essenciais:

• Nome do projeto/fluxo — Nome do projeto seguido do nome em inglês
• Breve descrição do projeto — Overview do que tem no projeto
• Tribo e contexto da tribo — Representado pela cor de fundo da capa e texto
• Envolvidos no projeto — Cargo, foto e slack dos envolvidos no projeto/feature
• Status do projeto (opcional) — Indicação textual sobre o andamento do projeto
• Barra de progresso (opcional) — Indicação gráfica do status do projeto
• Discovery
• WIIP/Design
• Validation
• Ready to dev
• Prod

Sete desenhos depois e alguns (muitos) ajustes, chegamos na seguinte capa:

2. Nomenclatura de arquivos

Encontrar arquivos dentro do Figma pode se mostrar uma tarefa um pouco exaustiva, caso o nome que está procurando não seja exatamente o mesmo usado na hora de salvar o projeto. Para evitar a fadiga, o sistema deve ser:

[ nome da tribo • squad ] título do projeto/fluxo — status — [ palavras-chave ]

• Tudo em letras minúsculas;
• O status do projeto é opcional e será utilizado apenas caso a tribo escolher segmentar o projeto (um arquivo ready to dev e outro design, por ex);
• Inserir palavras chaves no final é essencial para a busca posterior.

3. Layers internos

A organização interna dependerá de dois elementos: estrutura interna de layers e capa interna. A primeira deverá acompanhar a seguinte estrutura:

1. Ready to dev
2. Discovery
3. Design
4. Protótipo
5. Versões
6. Negócios

Títulos sempre em letras maiúsculas e subitens apenas com a inicial maiúscula

ex.:

4. Capa interna

Por fim, decidimos incluir uma capa interna para abranger informações importantes, mas que nem sempre podem ser contempladas na capa principal. As capas internas serão ideais para identificar fluxos secundários contidos dentro de um fluxo principal. Como o Figma permite a customização da cor principal do background do canvas, desenhamos duas versões: uma light e outra dark que diferem entre si apenas na cor. Ambas deverão seguir a seguinte estrutura:

1. Nome do fluxo em questão e nome do fluxo/feature pai
2. Objetivo do projeto/feature
3. Tribo — representada pela faixa de cor inferior
4. Envolvidos no projeto — cargo, foto e slack
5. Links importantes do projeto — documentações de discovery/produto e design, dashboard de dados e histórias no jira.

Por fim, o iFood hoje é uma empresa enorme com muitas iniciativas sendo tocadas e surgindo a todo momento. As áreas de atuação não poderiam deixar de ser extremamente únicas, cada uma com sua peculiaridade. Sendo assim, ao final deste projeto, saímos com um escopo ideado para funcionar como um modelo — pequenas mudanças e adaptações serão necessárias justamente para se encaixarem em cada cenário, afinal, trabalhamos em um organismo vivo e estamos sempre sujeitos a mudanças (ainda bem)!

Não poderia finalizar este artigo sem agradecer imensamente a todos os envolvidos pelo gás e disposição, por todas as discussões, risadas e sextas-feiras cheias de filtros no Hangouts, Laura Bertazzi, Roberto Lima, Mariana Louro, Carol Seixas, Nayara Rodrigues, Eduarda Takami, Mateus Pienta, Erika Bordoni, Clara Carneiro, Tillie Naomi e Marcus Amendola, vocês foram incríveis!

Obrigada 🙂

Escrito por