Rethinking the Admin Experience for Growing Organizations

When Figma Organization launched in early 2019, the assumption was that the original Admin Settings console would serve the needs of companies as they scaled. But as organizations grew and more collaborators joined design workflows, the scope of an admin's responsibilities expanded. The team at Figma realized that the tooling designed before the product had matured no longer matched how customers actually worked.

Figma's enterprise product team focuses on giving Organization admins ways to manage accounts and ensure team members have the right access. That work means joining sales calls, collecting feedback from existing customers, and collaborating with stakeholders across the company. When the team started to dig into how admins used the existing settings console, a few friction points emerged clearly.

Admins were making decisions at true-up without enough information to act confidently. They lacked visibility into features most relevant to them, and they were falling back on manual exports to get the data they needed. Compounding those issues, non-admins were seeing admin-only content cluttering their interface, while admins themselves were shown design creation prompts that didn't match their role.

Sizing the Problem From First Principles

What started as a possible UI refresh became a larger conversation about what an admin actually needs. When the enterprise team brainstormed with engineering, design, product, and research, they categorized ideas into "Do now," "Worth considering," and "Wild & crazy." The working group included product management, engineering leadership, design, and engineers alongside cross-functional support from research, data, marketing, and sales.

Input from sales was especially critical. The team heard that the Admin Settings view was limiting the value of any individual feature. Rather than layering more views and options onto the existing design, product manager Ben Stern advocated for turning the workstream into a full product update. The goal shifted from addressing symptoms to reoptimizing the entire admin workflow so features could be added more easily in the future.

The product team also considered how Figma supports organizations of widely different sizes. Enterprise offerings at other companies are often built exclusively for large firms; in contrast, Figma needs to accommodate teams of five and five thousand.

  • A VP-level budget-holder needs to understand the value of the product across the organization.
  • Design ops personnel need control over permissions and access to resources.
  • Security teams need confidence that their organization's data is secure.
  • Individual users have unique requirements and motivations every day.

At smaller organizations, one person often juggles admin duties, design operations, and individual design work. Larger enterprises may dedicate entire teams to each responsibility. Creating a single experience that flexes across all those scenarios guided the redesign.

Separating Admin From Maker

One clear structural change was separating the administrator view from the broader Organization page. Previously, admins encountered the same navigation used for design creation and consumption, including prompts to open files and view designs in teams and projects. The team removed admin-only pages from non-admins and created a top-level navigation option dedicated to admin settings.

That change gives large enterprise admins a direct path into the console they use daily, while still supporting smaller organizations where admins also drive design work. The navigation now separates the two roles clearly, regardless of team size.

Designing Without Handoffs

Once the navigation was settled, the team concentrated on member management workflows. Admin requests often pointed to the same areas: more robust filters and sorting mechanisms, and the ability to select many members at once for bulk actions like copying emails or changing permissions in batch.

The design process differed from typical handoff workflows. When designer Jordan Hsu shared his initial design spec, it specified polished click targets and visual states. What it intentionally left undefined was how multi-selection would be implemented—how users would add to their selections, deselect, and manage bulk operations.

Engineers Josh Tabak and Stanley Huang took the opportunity to research how other tools handle bulk selection. Looking at products like Asana and Gmail, they observed multiple approaches to shift+click behavior. They synthesized that research into a proposal that optimized for feasibility and intuitive experience rather than simply matching the design spec's wording.

This reflects a broader culture across Figma. Design files are open to contribution, and feedback channels on Slack invite opinions from anywhere in the company. The reasoning is that products designed with more voices produces better results, so collaboration happens during development rather than after.

Ownership Beyond Job Titles

For a product team, one of the more interesting aspects of the project was how it relied on engineers having ownership over product decisions. On the enterprise team, engineers actively research user experience patterns used across other tools. They synthesize findings into proposals and test them with real users.

The shift+click interaction was just one detail in a broader project, but it exemplifies how Figma's approach to scaling enterprise product covers more than just adding features requested by the largest customers. It involves continued questioning of existing assumptions, cross-team brainstorming, and understanding how different roles within an organization experience the same product differently.

Since the product team shipped these updates, the new Admin Settings is available for all Organization admins. As more diverse organizations continue adopting the platform, the challenge is how to build tooling that equally serves teams sharing smaller number of seats and companies running full deployments. And the work doesn't stop here; future features will need to build on the new foundation, and the flexibility built into the current architecture is part of that capacity to grow with user needs.