figma

Code, Craft, and the Making of Nested Folders | Figma Blog (opens in new tab)

Figma’s nested folders feature required much more than a file-browser update: it involved rethinking content structure, permissions, sharing, administration, and core infrastructure. The team responded to changing priorities and faster AI-assisted development by replacing a sequential product process with code-led experimentation, flexible roles, and continuous collaboration. This approach helped them turn early ideas into working solutions and ship a complex, long-requested feature.

Nested folders required foundational changes

  • Nested folders help growing teams organize files within shared projects.
  • Implementing them affected:
    • The file browser
    • Admin controls
    • Sharing and permissions
    • Figma’s underlying content model
    • Core infrastructure
  • The feature was therefore treated as a systems-level redesign rather than a simple quality-of-life improvement.

Moving beyond the traditional product process

  • Initially, the team followed a conventional sequence:
    • Product defined requirements.
    • Design mapped the user experience.
    • Engineering started implementation after the concepts were considered complete.
  • Midway through the project, priorities shifted as resources were also needed for AI-native initiatives.
  • Tools such as Figma Make, the Figma MCP server, agent skills, codebase prototyping, and context-aware agents made it possible to begin work from prototypes, code, or even informal ideas shared in Slack.

Leading with code

  • As code became faster and cheaper to produce, the team used pull requests as a way to explore product ideas.
  • Working prototypes and PRs helped the team test assumptions directly instead of spending too long debating theoretical solutions.
  • Code became a proposal and a communication tool, not merely the final implementation step.

Flexible roles and shared ownership

  • Responsibilities shifted according to the problem being solved:
    • Engineers made design decisions.
    • The designer contributed code.
    • The product manager focused less on daily execution and more on strategic questions.
  • This flexibility allowed the team to respond quickly as technical and product requirements evolved.

Replacing handoffs with conversations

  • Blurred roles turned team members into both students and teachers.
  • Instead of relying on formal handoffs between product, design, and engineering, the team collaborated continuously.
  • Sharing specialized knowledge and previously guarded parts of each craft helped build the trust needed to make decisions quickly.

The broader lesson is that complex product work benefits from treating code, design, and product thinking as shared responsibilities. For teams building foundational features under changing conditions, early prototypes, cross-functional ownership, and ongoing conversation can be more effective than rigid sequential handoffs.