Código, ofício e a criação das pastas aninhadas

Hoje, temos o prazer de apresentar as pastas aninhadas, um recurso muito solicitado que ajuda equipes em crescimento a manter os arquivos organizados enquanto ampliam a escala do conteúdo e enfrentam projetos complexos. As pastas aninhadas podem parecer um aprimoramento simples, mas seu desenvolvimento exigiu reformular do zero todo o modelo de conteúdo e permissões do Figma: do navegador de arquivos e dos controles administrativos ao compartilhamento, às permissões e à infraestrutura central.

Quando iniciamos o projeto, há um ano, seguimos o processo tradicional de desenvolvimento de produto: a área de produto definiu os requisitos, o design mapeou a experiência e a engenharia começou a construir quando o trabalho de concepção parecia concluído. No meio do projeto, o contexto mudou. Por um lado, nossa equipe estava buscando novas funcionalidades nativas de IA que dividiam nossos recursos. Por outro lado, ferramentas como Figma Make, servidor MCP do Figma, habilidades de agente, prototipagem de código e agentes com reconhecimento de contexto agilizavam consideravelmente a transformação de uma ideia em algo tangível. A construção poderia começar em qualquer lugar: um protótipo, código ou até mesmo algo rabiscado no Slack.

Para acompanhar essa evolução e lançar as pastas aninhadas, adotamos uma nova forma de trabalho:

• Liderado por código: com a redução do custo da geração de código, aceleramos o processo criando solicitações de pull (PRs) para testar as ideias em vez de manter longas discussões teóricas.
• Transferência de responsabilidades: trabalhamos com flexibilidade na abordagem de cada problema. Engenheiros tomaram decisões de design, o designer programou e o gerente de produto trocou a execução diária por questões estratégicas maiores.
• Troca de handoffs por conversas: com a sobreposição de funções, passamos a alternar entre aprender e ensinar. O compartilhamento de partes do ofício, que antes considerávamos nossa responsabilidade exclusiva, construiu a confiança que o trabalho precisava.

Foi assim que essas mudanças vieram de três perspectivas diferentes: engenharia, design e produto. Juntas, elas mostram como a equipe encontrou maneiras de aprofundar as relações que apoiam o trabalho, combinou conjuntos de habilidades e manteve o foco na entrega das experiências ou soluções corretas.

Ethan Adams, engenheiro de software: aumentar a velocidade da programação

Poucos meses após o início deste projeto, percebi que o processo típico de desenvolvimento de produtos seria muito demorado. Era como estar no meio de um exame final, olhar para o relógio e descobrir que restavam apenas cinco minutos. Precisávamos aumentar a velocidade.

Em vez de debater os requisitos do produto (“Quem deve ter acesso a X?”) em longas conversas no Slack ou reuniões, nossa proposta foi liderar o processo com código. Essas discussões eram pré-requisitos importantes quando programar era caro e demorado, mas agora estamos na era dos agentes. Em vez de fazer suposições sobre o funcionamento de uma ideia, simplesmente criávamos um PR para testá-la.

Mesclávamos código desde que não causasse nenhuma falha. Dessa forma, conseguimos esboçar e mostrar rapidamente as ideias aos parceiros multifuncionais em um verdadeiro campo de testes em tempo real. O texto não está perfeito? Sem problema. Falta funcionalidade? Tudo bem. Lacunas lógicas? Podemos resolver isso mais tarde. Na prática, isso acelerou muito o nosso ritmo de trabalho e criou confiança nas propostas que eventualmente selecionamos. Uma demonstração funcional na base de código real sempre supera um documento de requisitos do produto (PRD).

Como engenheiro, eu já tinha sinal verde para tomar decisões de produto, mas ainda contava com Sachi Shah, nossa gerente de produto, como parceira de reflexão para compartilhar a responsabilidade. Antes, nossa colaboração parecia uma cascata: ela definia um requisito, eu o implementava. Desta vez, parecia mais um ciclo de verificação: eu propunha uma ideia, mesclava protótipos no ambiente de preparação, solicitava o feedback de Sachi, ajustava os detalhes e, finalmente, lançava o produto finalizado.

Cai Charniga, designer de produto: mudar de pixels para solicitações de pull

Preciso confessar uma coisa: fiz pouquíssimos PRs neste projeto. Dois, talvez três. Eu não me transformei magicamente em um engenheiro, mas todos nós começamos a assumir funções que antes pertenciam exclusivamente a outra pessoa.

Neste projeto, os engenheiros tinham um sólido conhecimento da estrutura e uma compreensão profunda do funcionamento de permissões empresariais complexas em uma ferramenta como o Figma. Por isso, traziam frequentemente ajustes de fluxo e design. Quando você tem um design system robusto, que fornece diretrizes claras e confiança suficiente para que as pessoas se sintam à vontade para tomar decisões, um engenheiro pode se aprofundar em um recurso de design e desenvolvê-lo até chegar a um resultado realmente consistente. Ou seja, quando alguém chegava ao limite de sua capacidade, o trabalho não ficava parado, esperando que a pessoa certa o assumisse.

Por exemplo, quando trabalhamos nos fluxos de compartilhamento de pastas, precisávamos definir como o modal de compartilhamento comunicaria a herança de permissões a usuários com acesso de visualização ou edição, além de tratar os casos mais complexos em que essa herança é interrompida. Jenny Yu, engenheira de software, entrou no processo e criou mockups para algumas opções. Em seguida, envolvi Molly Rosen Marriner, escritora de UX, e desenvolvemos em conjunto as abordagens da Jenny na tela de trabalho do Figma Design: Jenny mantinha a solidez técnica do fluxo, Molly aprimorava a linguagem de permissões e eu dava forma à hierarquia visual.

O processo também corria no sentido inverso. Em alguns momentos, eu pegava uma alteração, começava a alterar o código e percebia o quanto estava acontecendo nos bastidores. Era o suficiente para voltar à equipe e admitir: “Sinceramente, não sou a pessoa certa para tocar isso”. Saber até onde suas habilidades vão é, em si, uma habilidade. Mesmo assim, acho que todo designer deveria tentar fazer um PR. Quando Ethan instalou o CoderBox, nosso sandbox para criação de ambientes de programação, percebi quanto tempo de construção algumas mudanças exigiam até que pudéssemos visualizá-las. Essa constatação aumentou minha empatia mais do que qualquer handoff.

Os engenheiros podiam fazer o trabalho de design e eu podia programar por conta própria. Com esse recurso, pude me aprofundar nos pontos necessários e explorar muito mais versões da UI de pastas do que seria possível no modelo de handoff anterior.

Sachi Shah, gerente de produto: trocar controle por convicção

Nessa nova forma de trabalho, a primeira coisa que tive que esquecer foi a suposição de que um bom raciocínio de produto era exclusividade dos PMs. Meu trabalho passou a ser associar as pessoas certas aos problemas certos, com autonomia para agir, e saber quando era hora de intervir novamente.

Jenny Yu se tornou uma das minhas parceiras de reflexão mais próximas em operações de conteúdo essenciais, como a movimentação, duplicação e transferência de pastas no Figma. Ricky Zein, também engenheiro de software, liderou a experiência para usuários individuais e equipes menores, um público com necessidades frequentemente diferentes das dos clientes Enterprise. E os cientistas de dados Patrick Kehinde Jr. e Eric Aberbook mapearam o impacto do novo modelo de permissões em cada grupo, o que ajudou a testar as nossas suposições e a manter o foco nos riscos mais importantes.

Quando deixei de lado a execução diária, tive mais tempo para me dedicar à questão estratégica por trás do projeto: uma melhor organização de arquivos ainda era importante em um mundo voltado à IA, ou as pastas estavam se tornando arcaicas com o aprimoramento das buscas por IA? Construímos artefatos que ajudaram a perceber como as pastas poderiam ter uma importância ainda maior quando as pessoas criavam mais trabalho, oferecendo às buscas futuras de IA uma estrutura e um contexto mais completos para consultar. Mas o que mais ajudou foi recuar para estruturar um portfólio equilibrado de iniciativas. Junto com as pastas aninhadas, a equipe correu para lançar habilidades no agente Figma, outra parte da estratégia nativa de IA do Figma. Por mais contraditório que pareça, dedicar menos tempo ao gerenciamento de cada detalhe me deu mais espaço para construir um roteiro para o avanço conjunto das necessidades fundamentais dos clientes e das novas experiências nativas de IA.

Dentro do próprio projeto, os clientes se tornaram o principal foco para o qual redirecionei minha atenção. Assumi a execução do programa de acesso antecipado (EAP) e adotamos uma abordagem bem improvisada. No Config, invadi os happy hours com Ayush Mehra, gerente de engenharia da equipe, para apresentar aos clientes o sistema de organização de arquivos que estávamos construindo. Convencemos várias pessoas a se juntarem ao EAP ali mesmo. A partir daí, continuamos expandindo. As comunidades Friends of Figma em Jaipur, Barcelona, Mumbai e Lahore se tornaram adotantes iniciais. Também entrei em contato com líderes da Comunidade ao redor do mundo e pessoas no X que tinham muito a dizer sobre a organização de arquivos, incluindo Ilya Miskov​, um designer que participou de uma de nossas primeiras conversas de descoberta.

O feedback dos clientes mostrou o comportamento das pastas aninhadas nos ambientes de produção das organizações, com arquivos bagunçados e hábitos estabelecidos. Esse feedback nos ajudou a detectar bugs, refinar a experiência e reduzir o risco da migração de clientes para um modelo de conteúdo totalmente novo.

O tempo que passei com os clientes me proporcionou um tipo de clareza sobre os produtos que seria impossível conseguir apenas especificando. Para trocar controle por convicção, precisei me envolver no trabalho para o qual estava mais bem posicionada, enquanto confiava que outras pessoas fariam o mesmo.

Este modo de trabalho só funciona quando a os membros da equipe confiam uns nos outros. Francamente, a sobreposição de funções foi estranha: houve momentos em que pisamos nos pés uns dos outros, cruzamos um limite de forma desajeitada ou tentamos algo que nunca tínhamos feito antes. Esse desconforto fazia parte de encontrar um novo normal e só conseguimos superá-lo porque investimos nos relacionamentos por trás do trabalho. Com o tempo, deixamos de tratar nossos domínios como territórios exclusivos e passamos a ensinar ativamente uns aos outros aspectos do nosso ofício que antes guardávamos para nós.

Mantivemos a integridade da confiança e do contexto por meio de rituais compartilhados: sessões semanais de caça a bugs, sincronizações multifuncionais, emparelhamento entre design e engenharia em tempo real e celebrações de marcos importantes, inclusive o lançamento interno para toda a Figma. Essas rotinas nos mantiveram alinhados em torno do mesmo objetivo: cumprir uma promessa ansiosamente aguardada pelos clientes sem comprometer a qualidade.

Levará algumas semanas para que as pastas aninhadas sejam disponibilizadas para todos os usuários.

Acesse a Central de ajuda para saber mais sobre como começar.