Figma

736 posts

www.figma.com/blog/engineering

Filter by tag

figma2 min readCurated summary

The Right Code for Your Design System | Figma Blog

Code Connect is Figma’s beta tool for improving design system adoption by connecting design mockups directly to production code. It replaces generic, auto-generated CSS snippets in Dev Mode with an organization’s actual component code, documentation, and usage guidance. Figma argues this can help developers build faster, use components correctly, and avoid creating duplicate one-off solutions. ## The Design System Adoption Problem - Design systems create a shared language between designers and developers. - Figma has already improved the design-to-code connection through: - Auto layout - Variables - Component properties - Dev Mode - A persistent challenge is adoption: - Developers may not know everything a design system contains. - Components and patterns may be used incorrectly. - Teams may create and maintain redundant custom components. - A design system succeeds only when it is used consistently and according to its intended guidelines. ## Code Connect’s Approach - Code Connect lets teams customize the code snippets shown in Figma Dev Mode. - Developers see real design system code rather than automatically generated CSS. - The feature is intended to: - Speed up implementation - Increase design system adoption - Encourage consistent component usage - Reduce duplicated, one-off components ## Connecting Design and Code - Design and development traditionally use different tools and optimize for different goals: - Designers focus on exploration and deciding what to build. - Developers focus on structure, implementation, and maintainability. - Figma presents Code Connect as another step toward allowing both disciplines to move smoothly between creative exploration and systematic implementation. - The tool is designed to address the broader disconnect between design workflows and coding workflows, rather than merely changing individual developer habits. ## Meeting Developers Where They Work - Code Connect is distributed through familiar development ecosystems: - npm for JavaScript and TypeScript projects - Swift Package Manager for SwiftUI projects - Setup instructions and the package are available on GitHub. - Developers can install and configure it through a command-line workflow. - Figma plans to add support for more platforms. - Once installed, design system teams can attach best practices and documentation directly to components and mockups, reducing the need for developers to search through separate documentation or code repositories. Code Connect’s practical recommendation is to bring production-ready component code and guidance into the developer’s existing design-inspection workflow, making the approved design system implementation the easiest option to use.

Read original(opens in new tab)
figma2 min readCurated summary

Alaska Airlines Reaches Cruising Speed With the Help of Variables | Figma Blog

Alaska Airlines uses Figma and its Auro design system to create consistent experiences across websites, mobile apps, kiosks, and digital signage. Moving away from Sketch and InVision resolved fragmented workflows, improved collaboration with engineers, and accelerated product development. Figma variables further help the 45-person design team adapt designs across screen sizes, themes, and the needs of more than 23,000 employees. ## Building a Reliable Design System - Alaska’s previous Sketch and InVision workflow lacked: - A single source of truth - Intuitive prototyping and collaboration tools - Consistent reusable components - Easy synchronization between design and engineering - Designers frequently made small but important inconsistencies in colors, buttons, checkboxes, modals, and date pickers. - Manual copying between platforms created version-control problems and contributed to accessibility issues. - Figma enabled Alaska to document Auro clearly for both designers and engineers, creating a more consistent digital ecosystem. ## Redesigning the Flight Status Experience - Severe storms exposed weaknesses in Alaska’s underused flight status page, which lacked information such as flight tracking and aircraft details. - A cross-functional “tiger team” rebuilt the page using approximately 90% Auro components. - The team completed the work in one sprint instead of the estimated four or five sprints without Figma. - Afterward, average time spent on the page increased from 36 seconds to 5 minutes and 10 seconds—a 761% increase. ## Connecting Design and Engineering - Figma components mirror the web components used by engineers, making designs easier to implement accurately. - This alignment improved product consistency and increased trust between design and engineering teams. - Alaska also documented Figma practices such as auto layout, merging, and branching to encourage adoption. - Designer education reduced conflicts and helped teams make better use of Figma’s capabilities. ## Using Variables at Scale - Figma variables allow Alaska to adapt designs for: - Different screen sizes - Light and dark modes - Themes for internal teams and external partners - The approach saves designers an average of 11 hours per week. - Variables help the team support the needs of more than 23,000 employees while maintaining a coherent design system. Alaska’s experience suggests that a well-documented design system, shared tooling, and variables can significantly reduce repetitive work while improving consistency, accessibility, and collaboration across an organization.

Read original(opens in new tab)
figma2 min readCurated summary

How Carvana Fuels Consistency and Scale | Figma Blog

Carvana scaled its design operations by moving from scattered tools to Figma as a centralized source of truth. Its design systems team uses Figma variables to enforce consistency, support rapid rebranding, and reduce design-development friction. The approach helped Carvana adapt quickly during rapid growth and integrate acquired businesses such as ADESA. ## Creating a Single Source of Truth - By 2019, Carvana’s design system was fragmented across a PDF UI kit, Principle, and Sketch. - Designers relied heavily on copying and pasting, causing small changes to diverge across repeated components. - Moving the system to Figma centralized libraries and connected design and engineering workflows. - The transition became especially valuable during the pandemic, when car sales surged and Carvana needed to scale quickly without adding process friction. ## Using Variables to Improve Consistency - Rapid growth introduced inconsistencies in: - Colors - Spacing - Typography - Corner radii - Figma variables let Carvana define reusable values for design properties. - Number variables standardized spacing and corner radii, while color variables helped maintain brand accuracy. - Although setting up variables required an initial learning period, the team achieved more polished designs and fewer revision cycles. ## Supporting New Brands and Business Lines - Variables allowed Carvana to create new themes without rebuilding its component library. - After acquiring ADESA, Carvana added an ADESA theme and applied the new branding to existing designs quickly. - The redesign took less than a week instead of the estimated month required to restyle the component library manually. - Themed components also enabled the team to create ADESA design comprehensives three times faster than usual. ## Connecting Design and Development - Figma’s shared libraries and variable-based system help designers and developers work from the same standards. - Centralized component structure and functionality make handoffs clearer and reduce inconsistencies between design files and implementation. - Carvana’s 40-person design systems team uses these practices to support consistency across a 10,000-person organization. Carvana’s experience suggests that a centralized design system, combined with reusable variables and themes, can make rapid growth more manageable. Investing in the system early reduces rework while making future products, brands, and acquisitions faster to integrate.

Read original(opens in new tab)
figma2 min readCurated summary

Codegen Plugins (And Other Tips) for Automating Design to Code | Figma Blog

Codegen in Figma’s Dev Mode is intended as a starting point for design implementation, not a complete replacement for developer judgment. Figma provides built-in snippets, while custom plugins extend code generation for different frameworks, languages, and team conventions. The post highlights several tools that can accelerate design-to-code workflows across web and mobile projects. ## Codegen as a Design-to-Development Starting Point - Codegen automatically generates code from defined design rules or specifications. - Figma argues that generated code should augment—not automate away—the design and development process. - Dev Mode creates code snippets for selected canvas objects in the inspect panel. - Users can choose different programming languages and measurement units. - Teams with mature design systems can build custom codegen plugins to match their conventions. ## Anima: Customizable React and HTML Generation - Exports Figma components into React or HTML with CSS, SCSS, or Tailwind. - Produces interactive, responsive, and maintainable snippets. - Detects repeated components to reduce duplication. - Learns team conventions from added code snippets. - Supports prompts for animations and style-specific adjustments directly in Dev Mode. ## Builder: AI and Code Components - Generates React, Svelte, and HTML using AI. - Can incorporate a team’s existing code components to better align design and implementation. - Allows users to refine output conversationally and train it to match their coding style. - Automatically adapts designs for responsiveness. - Provides a separate web interface for experimenting with generated code outside Figma. ## Figma to Code: Open-Source Multi-Platform Output - Converts designs into responsive web or mobile code. - Supports HTML, Tailwind, Flutter, and SwiftUI. - Lets users preview Tailwind output and copy it into their code editor. - Is available as a free, open-source Figma Community plugin. ## Locofy.ai: Interactive Web and Mobile Code - Generates code for components and full screens in React, HTML/CSS, Next.js, Gatsby, and Vue. - Supports design optimizations such as auto layout and frame grouping. - Adds interactivity through semantic HTML tags, libraries, and actions. - Produces responsive layouts, reusable components, props, and human-readable class names. - Enables teams to share prototypes, bind data, and export code or Storybook files. - Supports direct GitHub synchronization with automatic merging and conflict resolution. The practical recommendation is to use codegen to reach a useful first draft faster, then have designers and developers refine the output against the project’s design system, architecture, and coding standards.

Read original(opens in new tab)
figma2 min readCurated summary

The Future of Design Systems is Marketing | Figma Blog

Design systems succeed only when people actively use them, so building a high-quality toolkit is not enough. The post argues that design systems teams should treat their systems like products, using marketing practices—audience research, tailored messaging, advocacy, and impact measurement—to drive adoption. This approach can turn a “nice-to-have” resource into an essential part of how an organization designs and builds products. ## Understand the Audience - Find product-market fit by learning how designers, developers, and leaders work, what frustrates them, and what they value. - Interview people across the Product Design and Engineering organization, from individual contributors to executives. - Begin with their existing processes, bottlenecks, and goals rather than immediately pitching the design system. - Use this research to shape the system’s positioning and continuously refine it. ## Tailor the Message to Each Group - Different audiences need different versions of the design system’s value proposition: - **Designers:** Emphasize creative enablement and brand consistency. - **Developers:** Focus on reusability, standardization, efficiency, and smoother design-to-code workflows. - **Decision-makers:** Demonstrate return on investment through faster delivery and reduced technical debt. - Address objections directly, including concerns about flexibility, technical constraints, and the effort required to implement the system. - A carefully adapted pitch can turn skepticism into support. ## Treat Adoption Like a Campaign - Replace one-off Slack announcements, presentations, and poorly attended training sessions with a deliberate go-to-market strategy. - Build compelling narratives around why the system matters to the organization. - Identify internal champions who can promote adoption within their teams. - Use supporting capabilities such as Code Connect, typography and gradient variables, and library analytics to make adoption easier to encourage and measure. The practical recommendation is to market a design system as actively as it is built: understand its users, communicate benefits in their language, recruit advocates, and measure whether it is delivering organizational value.

Read original(opens in new tab)
figma3 min readCurated summary

The Anatomy of a Component Sprint | Figma Blog

The Washington Post’s design system team developed a roughly 10-day “component sprint” to replace siloed, linear workflows with continuous designer–developer collaboration. Each component is jointly planned, designed, implemented, refined, and documented, with input from the wider team throughout. The process aims to reduce miscommunication, uncover technical constraints early, and create components that serve real product needs. ## Why the Component Sprint Was Needed - The Washington Post launched its design system in 2019 to help teams deliver news experiences quickly and consistently. - Earlier components followed either: - A design-led process for inputs such as selects, radios, and checkboxes. - A developer-led process for technically complex components such as carousels and search inputs. - Both approaches caused delays, unexpected compromises, and gaps in communication. - Designers sometimes overlooked existing components or pursued custom solutions, creating overrides and last-minute requests for new variants. - Developers could be forced to focus on visual details instead of solving technical and product problems. - The new process brings the relevant people together early and gives designers and developers shared ownership. ## Sprint Structure and Shared Ownership - A designer and developer from the core design system team lead each component from beginning to end. - Every planned component receives its own sprint, although the timeline can vary. - The approximately 10-day process is intentionally open and inclusive rather than closed and sequential. - The wider team contributes feedback and expertise at multiple stages. ## Kickoff: Balancing Impact and Effort - The team holds a weekly 30-minute meeting to evaluate candidate component tickets in Jira. - Ideas are prioritized according to potential impact and required effort. - Jira tickets serve as shared, evolving spaces where stakeholders can: - Leave feedback asynchronously. - Record insights from Slack discussions. - Group related ideas. - Connect proposals to business goals. - An impact-versus-effort matrix visualizes priorities: - Larger circles represent ideas with more votes. - Numbers identify clusters of related ideas. - Colors indicate associated business goals. - Once a ticket is prioritized, a designer and developer are assigned to lead delivery. ## Concept: Defining Scope and Goals - The sprint begins with a two-hour meeting involving the wider team. - In a FigJam file, participants: - Define the component’s goals. - Agree on requirements. - Assess the scope of work. - Clarify assumptions and technical needs. - The meeting reserves the final 15 minutes for review. - Using FigJam enables both technical and non-technical contributors to participate. - The team focuses first on shared expectations and requirements, avoiding premature debate over detailed visual design. The component sprint provides a practical framework for building design-system components collaboratively: prioritize openly, pair design and development from the start, and establish scope with broad input before implementation begins.

Read original(opens in new tab)
figma2 min readCurated summary

How to Build a Design System | Design Systems 102 | Figma Blog

A design system creates a shared language and reusable components that improve product consistency, team efficiency, and collaboration. Figma recommends building one around the organization’s specific goals and challenges rather than following a universal formula. The process begins with understanding the problem, auditing existing work, involving cross-functional partners, and choosing an approach that can evolve over time. ## Lay the Groundwork - Define why the design system is needed: - What problems should it solve? - What goals should it support? - How will success be measured? - Recognize that systems vary in scope: - Small teams may need a simple component library. - Enterprise organizations may require a comprehensive system. - Design the system to grow as product and team needs change. ## Take Stock of Existing Design and Code - Collect screenshots and examples of the product across: - Platforms and devices - Interactive states - Alternate versions - Look for recurring patterns and consistent UI elements that can become system foundations. - Audit the codebase for existing reusable components, shared CSS variables, and repeated UI patterns. - Build on existing engineering work instead of creating disconnected design and development systems. ## Organize and Evaluate the Product Landscape - Categorize the collected examples to understand the current design language. - Identify: - Inconsistencies across products or platforms - Redundant solutions - Disconnected user experiences - Problems being solved differently by designers and developers - Use these findings to prioritize where a unified system can provide the greatest value. ## Find Cross-Functional Champions - Involve designers, developers, product managers, and other stakeholders. - Seek people who care about consistency and can advocate for the system internally. - Include developers early because they can assess: - Technical feasibility - Implementation requirements - Long-term maintenance - A design system can begin with a single dedicated contributor, but broader collaboration helps it serve the whole product team. ## Choose an Approach - Decide whether to: - Build a custom system from scratch - Adopt an existing framework and adapt it to the organization’s needs - The best choice depends on the team’s goals, existing assets, technical context, and available resources. A practical starting point is to define measurable goals, audit both design files and production code, and form a cross-functional group before creating components. This ensures the design system addresses real product problems and remains useful as the organization evolves.

Read original(opens in new tab)
figma2 min readCurated summary

Surf the web like it’s 1999 with these old-school cursors | Figma Blog

Figma’s 2024 April Fun Day celebrated the history of digital design through four temporary cursor styles: 8-bit, Y2K, Skeuomorphic, and Aero. The initiative treats cursors as more than interface tools—they are avatars that express personality and enable collaboration through chat, emotes, and high fives. Users could activate the nostalgic cursors in any Figma or FigJam file by selecting the cursor icon. ## Cursors as collaborative avatars - In multiplayer Figma and FigJam files, cursors show where collaborators are working. - They also support social interaction through: - Cursor chat - Emotes - High fives - Figma describes cursors as a way for people to see and relate to one another through screens. ## 8-bit: Pixel nostalgia - The 8-bit style draws on early web design, text-based terminals, arcade games, and operating systems before modern graphical interfaces. - Its influences include: - Pac-Man and Space Invaders - DOS computers - Windows 2000 - Classic Mac and early GUI design - The cursors use deliberately low resolution and pronounced pixel grids. - Familiar icons such as pointing hands and pencils were redesigned with a friendly, elementary appearance. - Designers associated the style with tactile interfaces, expressive icons, and memories of discovering graphical operating systems. - The aesthetic was developed by “dialing back” resolution to make the pixels and blocky forms visually prominent. ## Four digital eras revisited - Figma’s temporary cursor collection was inspired by: - **8-bit:** Early computers, arcade games, and pixel graphics - **Y2K:** The turn-of-the-millennium internet and pop culture - **Skeuomorphic:** Real-world textures and tactile interface elements - **Aero:** Glossy, translucent visual design associated with Windows Vista - The project combines product interaction with nostalgia for earlier eras of computing and the web. The collection was intended as a playful, limited-time way to personalize collaboration in Figma and FigJam while revisiting the visual languages of earlier digital design.

Read original(opens in new tab)
figma2 min readCurated summary

Join Us for Framework by Figma: Our Global Design Systems Event | Figma Blog

Figma announced Framework, a global design systems event focused on new tools, best practices, and the future of design systems. The event aims to help teams manage increasingly complex systems while improving collaboration between designers and engineers. It also highlights Figma’s broader effort to connect design systems more closely with code and organizational adoption. ## Event Focus and Agenda - Framework was scheduled as a half-day virtual event on April 16, 2024. - The program included: - Deep dives into new design system features - Best practices from companies such as Verizon - Product sessions about Figma’s future direction - A design-to-code roundtable with Bumble, GitHub, and Hewlett Packard - Expert Q&A sessions - The article also references features announced at Framework, including Code Connect, typography and gradient variables, and the Library Analytics API. ## Building More Adaptable Design Systems - Design systems have evolved from basic style guides into foundations for product design and development. - Figma acknowledges that implementing and maintaining them can be complex. - Its approach aims to support both structured workflows and more flexible, freeform design. - Product sessions were intended to cover how teams can structure, maintain, and increase adoption of their systems. ## Connecting Designers and Engineers - A central goal was to bring design systems practitioners from design and engineering together. - Sessions addressed both design principles and technical implementation. - Figma previewed capabilities intended to reduce the gap between design and development. - The event emphasized cross-functional collaboration as essential to successful design systems. ## Global Design Systems Community - Framework was presented as a global community event, with virtual programming for broad access. - Additional events were planned for Asia on April 18 and Tokyo on April 23, alongside future meetups in London and other cities. - Participants could attend the main-stage announcements and sessions online regardless of location. Figma positioned Framework as both a showcase of new capabilities and an opportunity to learn from the teams shaping modern design systems. Its practical recommendation was to participate in the event, explore the new design-to-code and analytics tools, and apply the shared practices to improve system adoption and collaboration.

Read original(opens in new tab)
figma3 min readCurated summary

AI + Design: Figma Users Tell Us What’s Coming Next | Figma Blog

Generative AI’s impact will depend not only on technical capability but also on how effectively it is designed into products and everyday workflows. A Figma survey of more than 1,800 designers, developers, and executives shows high expectations for AI, but limited evidence that current implementations are delivering meaningful value. The findings point to a risk of “AI feature fatigue” and suggest that thoughtful, user-centered design will determine whether AI becomes genuinely useful. ## Survey Scope and Methodology - Figma surveyed more than 1,800 users between February 26 and March 3, 2024. - Participants included designers, developers, and executives across the US, Canada, Australia, the UK, Japan, France, and Germany. - The research examines how organizations view AI’s near-term impact and how teams are incorporating it into products. ## High Expectations, Limited Results - 89% of respondents expect AI to affect their company’s products or services within 12 months. - 37% anticipate a “significant or transformative” impact. - Executives are especially likely to view AI as important to company goals. - Despite this optimism, 72% of people whose products include AI say it has only a minor or non-essential role. - Only about one-third report improvements in business metrics such as revenue, costs, or market share. - Fewer than one-third say they are proud of what they have shipped. ## The Risk of AI Feature Fatigue - Figma researchers observed growing indifference toward adding “yet another AI feature.” - More than 20% of teams building AI products identify failure to solve a real user need as a major challenge. - This concern is particularly strong among designers. - Fewer than half of respondents working on AI products or features have shipped anything, indicating that a larger wave of AI products may still be coming. - Organizations risk flooding the market with novelty features that users do not find useful. ## Designing AI Into Existing Products - One-third of respondents rank integrating AI coherently into existing products as a top challenge. - Simply adding AI without improving the overall user experience is unlikely to drive adoption. - Teams need to help users understand: - What AI tools are available - When those tools are useful - How AI improves existing workflows - The article uses ChatGPT as an example: its rapid adoption was driven partly by a simple, accessible conversational interface, even though the underlying model capabilities already existed. - Good design can make powerful technology more approachable, aligned with user expectations, and easier to use. ## Practical Implication AI products are more likely to succeed when they address concrete user problems rather than adding AI for its own sake. Organizations should prioritize coherent product integration, clear user experiences, and measurable improvements over ambitious but disconnected features.

Read original(opens in new tab)
figma2 min readCurated summary

23 Prototyping Resources to Bookmark Right Now | Figma Blog

Prototyping is valuable throughout product development—not just at the end—as a way to align teams, gather feedback, conduct research, and improve products through iteration. Figma’s curated collection of 23 resources supports different learning styles, from introductory videos and community files to presentation techniques and advanced prototyping features. ## Cover the Basics - An eight-minute video introduces interactive prototypes, animation, and incorporating tester feedback. - A 50-minute playlist covers: - Easing curves and transitions - Smart Animate - Scrolling - Device frames - A 63-minute “Prototyping 101” video explains basic frame-to-frame navigation and advanced features such as interactive components. - A two-part series for product professionals demonstrates how non-designers can create lightweight prototypes. - Part one covers basic prototype creation. - Part two explores transitions, Smart Animate, scrolling, and other motion techniques. - The “Accessible prototypes in Figma” community file demonstrates prototype accessibility features, including compatibility with screen readers such as VoiceOver on Mac and JAWS on Windows. ## Level Up Presentations - Prototyping can make presentations more dynamic and engaging, whether for boardrooms, classrooms, or other audiences. - A 70-minute video explains how to build interactive slide presentations in Figma. - A short tutorial shows how to embed interactive elements, such as scrollable mobile screens, inside presentation slides. - Another video demonstrates using the Figma mobile app to click through presentation slides. ## A Broader Prototyping Practice - Figma positions prototyping as a tool for: - Building shared team understanding - Testing ideas with users - Facilitating stakeholder feedback - Iterating before development - The resource list follows recent Figma prototyping enhancements, including updates that help bring designs to life across mobile, tablet, and smartwatch interfaces. - The article is organized as a learning path, with additional sections intended to cover video, motion and flow, variables, and recorded office hours. Use the resources progressively: begin with the introductory tutorials, then explore accessibility, presentation workflows, motion, variables, and community examples as your prototyping needs become more advanced.

Read original(opens in new tab)
figma3 min readCurated summary

How Figma's Databases Team Lived to Tell the Scale | Figma Blog

Figma’s database stack grew nearly 100× from 2020, pushing its single-Postgres architecture beyond the limits of vertical partitioning. After adding caching, read replicas, and vertically partitioned databases, the team found that individual tables were reaching terabyte and billion-row scales, creating vacuum reliability issues and approaching AWS RDS IOPS limits. The solution was to pursue horizontal sharding while preserving Postgres, minimizing application changes, avoiding massive backfills, and maintaining consistency and rollback options. ## Scaling from One Postgres Database - In 2020, Figma ran on one large Postgres instance. - By the end of 2022, it had introduced: - Caching - Read replicas - Around a dozen vertically partitioned databases - Related tables, such as those for Figma files and organizations, were grouped into separate database partitions. - Vertical partitioning reduced pressure on the system and provided valuable short-term runway. ## Why Vertical Partitioning Was No Longer Enough - The team monitored multiple scaling constraints, including: - CPU and I/O utilization - Table size - Rows written - Database IOPS - Some tables grew to several terabytes and billions of rows. - Large tables began affecting reliability during PostgreSQL vacuum operations, which prevent transaction ID exhaustion. - High-write tables were on track to exceed the maximum IOPS supported by Amazon RDS. - Because a table is the smallest unit of vertical partitioning, splitting databases by table group could not solve these limits. ## Requirements for the Next Scaling Strategy Figma established several design goals for horizontal scaling: - Minimize developer changes and preserve the existing relational data model. - Make future scale-outs transparent to application teams after initial compatibility work. - Avoid months-long backfills of large tables. - Roll out changes incrementally to reduce outage risk. - Preserve rollback capability after physical sharding. - Maintain strong consistency without relying on difficult double-write schemes. - Support near-zero-downtime scale-outs. - Favor technologies and techniques the database team already understood, given the limited runway. ## Evaluating Alternatives - The team considered CockroachDB, TiDB, Spanner, and Vitess. - Moving to another database would have required a risky migration between storage systems while preserving consistency and reliability. - Figma already had substantial operational expertise running Postgres on RDS; replacing it would mean rebuilding that expertise under severe time pressure. - NoSQL systems were also unsuitable because Figma’s application depends on a complex relational data model and requires the flexibility of relational queries. - The team therefore favored a lower-risk approach that retained Postgres and offered greater control over the migration. ## Practical Direction Figma’s experience shows that vertical partitioning can be an effective intermediate step, but it cannot solve limits imposed by individual tables. For systems with rapidly growing relational workloads, horizontal sharding within a familiar database ecosystem can provide a safer path to scale when it is introduced incrementally and designed around consistency, rollback, and minimal application disruption.

Read original(opens in new tab)
figma3 min readCurated summary

How We Built a Custom Permissions DSL at Figma | Figma Blog

Figma’s original permissions system—a large Ruby `has_access?` method in its monolith—became too complex, risky, and expensive to maintain. As collaboration features expanded, permission rules involving roles, links, hierarchies, organizations, billing, and deleted files caused bugs, delayed projects, and heavy database load. Figma responded by building a custom permissions DSL and cross-platform logic engine to make rules more modular, flexible, performant, and easier to debug. ## Why Permissions Became Difficult - Figma’s collaboration model requires detailed access rules for files and other resources. - Access can come through: - Roles inherited from parent folders, teams, or organizations - Link-sharing settings - User roles and authorship levels - Passwords, expiration periods, and organization restrictions - Originally, permissions lived in a Ruby monolith using ActiveRecord. - A model-level `has_access?` method accepted a user and resource, performed database queries, and returned a Boolean. - Product engineers had to call this method correctly from controllers. ## Problems with the Original System ### Complex Logic and Difficult Debugging - `has_access?` methods grew into long functions with many optional parameters. - Engineers were reluctant to modify them because mistakes could expose access to large numbers of files. - All permission logic for a resource was intertwined, making it difficult to isolate or test individual rules. - Debugging often required adding many print statements and understanding the entire permissions implementation. ### Inflexible Hierarchical Permissions - Permissions were nominally represented by hierarchical integer levels, such as edit access being higher than view access. - Boolean flags introduced exceptions that undermined the hierarchy, including options such as: - `ignore_link_access` - `org_candidate` - `ignore_archived_branch` - A user could have a higher access level but fail a lower-level check when a flag changed the behavior. - These flags differed between resources, forcing engineers to remember numerous special cases. - Figma needed granular, non-hierarchical permissions that could operate independently or define new permission hierarchies. ### Excessive Database Load - As Figma scaled, permission checks accounted for roughly 20% of database load. - This created a serious scalability concern because database capacity had physical limits. - Although the database team was pursuing vertical and horizontal sharding, Figma also needed to reduce and better control permission-related queries. ## Building a Custom Permissions DSL - Figma generally prefers adopting open-source or commercial solutions, but existing options did not adequately address its requirements. - The company chose to build: - A domain-specific language for expressing permissions - A custom cross-platform logic engine - A migration plan for moving critical permission rules into the new system - The intended result was a permissions system that improved developer ergonomics while increasing correctness and performance. Figma’s experience shows that permissions can become a foundational scalability and reliability problem when implemented as one growing authorization function. A dedicated, composable DSL can provide clearer rules, more flexible access models, and better control over database usage.

Read original(opens in new tab)
figma3 min readCurated summary

Behind the Feature: The Multiple Lives of Multi-Edit | Figma Blog

Multi-edit began as a way to reduce repetitive work when editing component variants, then evolved into a broader interaction model for editing matching objects across Figma designs. The feature addresses shortcomings in ordinary multi-selection, where selecting the right objects and applying certain edits—such as resizing or changing text—is difficult. After years of refinement, Figma launched multi-edit as a more natural, second-nature workflow. ## The Philosophy Behind Multi-Edit - The idea originated in 2019 during a design summit focused on Figma’s variants feature. - Designers noticed that editing variants required too much repetitive work. - The initial insight was to create a mode where one edit could apply simultaneously to all variants. - The team soon recognized that the same capability could help with many other design tasks. ### Why Existing Multi-Selection Wasn’t Enough - Figma already allowed users to select multiple objects, but the workflow had significant limitations: - Selecting exactly the objects users wanted to edit was difficult. - Some edits worked well across selections, while others did not. - Changing shared properties such as color, font, or font size was relatively easy. - More structural edits, including resizing multiple objects, were cumbersome. - Editing the actual text content of multiple text nodes was also difficult. ### A Long Period of Hibernation - Although the concept was sketched quickly, development did not begin immediately. - The team needed to resolve fundamental questions about how multi-edit should behave. - Early thinking treated it as a powerful, specialized mode similar to multi-select text editing in advanced text editors. - Refining the concept required reconciling that new mode with Figma’s existing selection model. ## Bringing Multi-Edit to Life - The finished feature lets users select and edit matching objects across frames and component sets. - Suggested interactions include: - `⌘ Command + ⌥ Option + A` to select all matching objects. - Shift-dragging to select specific matching objects. - Selecting multiple text objects and pressing Enter to edit their text together. - Selecting a component set and pressing `Q` to edit variants simultaneously. - Figma provides a playground file so users can experiment with these workflows. ## Knowing When It’s Ready - The article frames multi-edit as an example of a feature that required extensive iteration before feeling obvious. - Its goal was not merely to add a new command, but to make repetitive editing feel effortless and intuitive. - Figma’s broader product philosophy is to question established design-tool conventions when doing so can simplify everyday work. Figma’s experience suggests that seemingly simple, natural interactions often require substantial exploration. Multi-edit is most useful when users repeatedly update related objects, variants, or text, and its shortcuts can make those bulk edits significantly faster.

Read original(opens in new tab)
figma3 min readCurated summary

How We Engineer Feedback at Figma with Eng Crits | Figma Blog

Figma’s engineering critiques (“eng crits”) are designed to gather feedback early, before technical decisions become expensive to change. Unlike formal technical reviews, they are collaborative forums for exploration, brainstorming, and expert input—not approval gates. Figma found that using FigJam’s open canvas made it easier for many engineers to contribute and helped teams avoid late-stage, launch-blocking feedback. ## Why Early Feedback Matters - Engineers are encouraged to share in-progress work, including unpolished ideas and early technical directions. - Traditional technical reviews often happen after a design has already been developed, making feedback potentially disruptive or launch-blocking. - Eng crits occupy a middle ground between informal design critiques and formal technical reviews. - Their purpose is to help teams: - Explore novel approaches - Get expert feedback on technical designs - Unblock projects - Improve work through discussion rather than approval ## “Lifting Ideas Up” as Teams Scale - Early-stage teams often share ownership of both the overall architecture and its implementation. - As teams grow, newer contributors may be limited to executing established plans rather than shaping them. - Eng crits create a way for more people to contribute without undermining the original direction. - Figma CTO Kris Rasmussen emphasizes that eng crits are for soliciting feedback early and often, not for deciding whether work is approved. ## Why Format Matters - Synchronous technical reviews tended to focus discussion on a few team leads. - Asynchronous reviews often produced long, disconnected comment threads rather than meaningful conversations. - Figma drew inspiration from brainstorms and retrospectives conducted in FigJam. - FigJam enabled participants to: - Contribute simultaneously - Share early thinking and inspiration - Add screenshots of unfinished work - Provide context and prompts - Offer feedback without waiting for a single presenter or responding through fragmented threads ## Scaling the Practice - Figma initially piloted eng crits with teams of roughly eight to ten people. - The collaborative format quickly gained support and was turned into a repeatable process. - Calendar invitations were later opened to a much broader audience, eventually attracting more than 200 participants. - Engineers were encouraged to join when they had relevant expertise or curiosity, rather than treating attendance as mandatory. ## Anatomy of an Eng Crit - Figma sends invitations to all engineers working on the editor. - Invitees are marked as optional so they can participate when a topic is relevant or opt out when it is not. - Cross-functional collaborators may also attend. - Participation is driven by relevance and interest, rather than by a formal approval hierarchy. Figma’s experience suggests that technical feedback works best when it is early, inclusive, and explicitly separated from approval. Teams can adopt a similar model by using a shared visual workspace, inviting contributors broadly, and framing reviews as opportunities to improve ideas rather than gates that determine whether work may proceed.

Read original(opens in new tab)