Techlist.io - Korean Tech Blog Curator

figma2 min readCurated summary

Behind the scenes: international keyboard shortcuts | Figma Blog

Figma redesigned its keyboard shortcut system to work reliably across international keyboard layouts, after discovering that many users could not access shortcuts built for US keyboards. The project revealed unexpected challenges in browser APIs, Unicode casing, and the sheer number of keyboard configurations. Figma ultimately had to combine new shortcut mappings with layout detection and normalization improvements. ## Why International Shortcuts Matter - Figma shortcuts improve speed, accessibility, and access to menus and tools. - US-centric shortcuts excluded users whose keyboards lacked keys such as: - Backslash (`\`) for toggling the UI - Forward slash (`/`) for starting cursor chat - The team began a year-long effort involving multiple disciplines to make shortcuts accessible worldwide. ## How Figma Processes Shortcuts - Browsers send key presses as `KeyboardEvent` objects. - Figma translates each event into an internal representation. - Shortcut definitions and their associated actions are stored in JSON. - Available shortcuts depend on factors such as: - User preferences - Product context - Operating system - Whether a feature is enabled - Figma matches each key press against the active shortcut definitions and executes the corresponding action. ## Unicode and Shortcut Normalization Problems - Adding alternate shortcuts for each layout seemed simple, but normalization introduced unexpected issues. - On German keyboards, `Meta + Alt + ß` was needed for decreasing text weight. - JavaScript converts `"ß".toUpperCase()` into `"SS"`, turning one key into two characters. - Converting the result back to lowercase does not restore the original `ß`. - Figma worked around this by using the capital eszett character, `ẞ`, which remains stable when uppercased. - The capital eszett was officially adopted by Germany’s spelling council in 2017, although programming languages and tools do not uniformly support it. ## Detecting Keyboard Layouts - Figma prioritized layouts most commonly used by its users because thousands of layouts exist. - The desktop app can inspect the operating system’s keyboard setting. - Browsers provide less reliable information, so Figma used heuristics based on the experimental Keyboard API. - The API exposes characters associated with physical key positions. - For example, seeing `ä` on the `Quote` key, combined with other mappings, can suggest a Swedish layout. - Logging revealed more than 2,500 distinct keyboard layouts used on Figma within a single 30-day period. Figma’s experience shows that international keyboard support requires more than adding translated shortcut definitions. Robust implementations must account for physical key positions, browser and OS limitations, Unicode edge cases, and the enormous variety of real-world keyboard layouts.

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

Can design make work, work? | Figma Blog

The post argues that people managers should redesign their work rather than accept today’s overloaded, meeting-heavy norms. By reclaiming time, making feedback visible earlier, and creating better asynchronous collaboration practices, managers can help teams work with more focus and flexibility. The central recommendation is to question existing routines and deliberately build a more effective future of work. ## Reclaim Time by Reducing Meetings - Shopify began 2023 by eliminating recurring meetings with more than three participants, later restoring only the most essential ones. - The goal was to protect uninterrupted time for independent work, especially in a fully remote organization spanning multiple time zones. - Asynchronous collaboration through tools such as Figma and FigJam allows people to contribute when they are available. - Managers should examine how they actually spend their days and compare that with what leadership expects them to do. - Collaboration tools, visual planning, and brainstorming can replace some meetings—or make remaining meetings more focused on relationships, shared values, and team culture. ## Make Feedback Cycles More Manageable - Sharing early drafts helps prevent late-stage “swoop and poop” feedback from stakeholders. - Posting screenshots or work-in-progress material in FigJam lets colleagues annotate, add sticky notes, and react with emojis without interrupting the team’s workflow. - Early visibility creates a manageable feedback loop rather than requiring the team to respond to every comment immediately. - Visual brainstorming also documents decisions and makes collaboration easier to revisit. - Teams benefit from repeatable processes, but they also need structured opportunities to identify what is not working. - At Super, anonymous suggestions during monthly retrospectives led to operational improvements, including a new bug-reporting system and short weekly sessions for testing new features. Managers can improve team performance by removing unnecessary meetings, shifting more work asynchronously, and inviting feedback early and continuously. The broader lesson is to treat management practices as redesignable systems rather than fixed workplace traditions.

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

Husky: Exactly-once ingestion and multi-tenancy at scale

Husky, Datadog’s distributed, time-series-oriented event store, is optimized for large scans and aggregations rather than high-volume, low-latency point lookups. This makes exactly-once ingestion challenging, especially at Datadog’s multi-tenant scale. Datadog addresses the problem with deterministic, locality-aware routing that limits deduplication scope, improves storage efficiency, and supports autoscaling ingestion pipelines. ## Husky’s Ingestion Challenge - Husky separates storage and compute, allowing each to scale independently. - Its storage engine is designed primarily for large analytical scans and aggregations. - It is not optimized for massive numbers of low-latency point lookups, complicating duplicate detection during ingestion. - The ingestion system must guarantee that every event is stored exactly once while maintaining: - Multi-tenant scalability - Reasonable ingestion latency - Controlled infrastructure and storage costs ## Routing Events to Storage Shards - Datadog uses an upstream **Shard Router** to introduce locality into Kafka pipelines. - Events are deterministically assigned to shards based on their tenant, timestamp, and event ID. - Each tenant receives a list of shards rather than being permanently assigned to one shard. - A deterministic choice from that list distributes the tenant’s events while keeping the number of active shards as small as practical. - Downstream workers consume one or more shards and perform exactly-once ingestion into Husky. ## Benefits of Data Locality - **Simpler deduplication** - An event with the same timestamp and ID always reaches the same shard. - Deduplication only needs to occur within that shard. - Workers handle smaller sets of event IDs, making in-memory deduplication more efficient. - **Lower storage costs and better performance** - Each shard processes a relatively small set of tenants. - Husky stores each tenant in a separate table and does not mix tenants within files. - More tenants per writer produce more output files, increasing blob-storage costs and compaction work. - Restricting tenant cardinality reduces file creation and improves writer and compactor efficiency. ## Challenges in Deterministic Routing - **Changing shard assignments** - Tenant traffic can increase by one or two orders of magnitude. - Assignments may change when scaling a tenant across more shards or rebalancing traffic among existing shards. - **Distributed router consensus** - Every Shard Router node must make the same routing decision for a given event. - Inconsistent decisions could send duplicates to different shards and undermine exactly-once ingestion. - **Load balancing** - Shards must receive roughly equal traffic so downstream ingestion workers remain balanced. ## Time-Bounded Shard Placements - A simple deterministic mapping can select a shard using a hash of the event ID: ```text shard = shards[hash(event_id) % num_shards] ``` - This approach is cheap and stateless when all routers know the same shard list. - However, changing the shard list can cause the same event ID to map to a different shard, so assignment changes require additional coordination. - The article introduces **time-bounded Shard Placements** to preserve consistent routing while allowing tenant assignments to evolve, though the supplied excerpt ends before explaining the mechanism in detail. Datadog’s core recommendation is to combine deterministic, tenant-aware routing with carefully coordinated assignment changes. This narrows the scope of deduplication while reducing storage overhead and enabling balanced, scalable exactly-once ingestion.

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

Husky: Exactly-once ingestion and multi-tenancy at scale | Datadog

The provided content does not include the blog post itself. It contains Datadog’s navigation menu and a promotional banner announcing its recognition as a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms, but no article text about “Husky.” ## Content Available - The page links to Datadog products covering: - Infrastructure and application monitoring - Logs, databases, and data observability - Security and digital experience - Software delivery and service management - AI and platform capabilities - The banner promotes Datadog’s observability-platform recognition. - No technical details, sections, architecture diagrams, implementation discussion, or conclusions from the Husky article are included. Please provide the article text or a complete page extract for an accurate summary.

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

How Pinterest’s design systems team measures adoption | Figma Blog

Pinterest’s Gestalt design systems team created a “design adoption” metric to understand how widely its components are used during the design phase, not just after implementation. Code-based adoption metrics were limited to web components and often lagged behind design activity, while raw Figma instance counts lacked context. Using Figma’s REST API, the team built FigStats to measure Gestalt usage relative to all content in Pinterest design files. ## Why Code Adoption Wasn’t Enough - Gestalt’s existing adoption metric tracked component usage in code. - Code provided concrete data about which components shipped and whether teams modified them. - However, it had two limitations: - It only covered web components, not Gestalt’s iOS and Android components. - It took time for newly designed components to reach production code. - Measuring adoption in Figma provided earlier insight into whether designers knew about and used Gestalt components across all platforms. ## Defining a More Meaningful Adoption Metric - Figma’s built-in library analytics reported: - Component instances - Component insertions - Usage by team - These were useful counts but did not indicate whether usage was significant. - For example, 10 Gestalt components in a 1,000-node design represent only 1% adoption, even though the raw usage count is nonzero. - Pinterest therefore defined adoption relatively: Gestalt usage compared with the total content in a design file or page. - This approach helped distinguish isolated component use from meaningful reliance on the design system. ## Building FigStats with the Figma REST API - The Gestalt team used Figma’s REST API to inspect design files and identify layers originating from Gestalt libraries. - FigStats aggregated this information into a dashboard for visualizing component usage. - The dashboard enabled the team to explore adoption across Pinterest’s design work rather than relying only on manually selected examples. - Measuring actual file content also helped reveal whether designers were using complete Gestalt components or recreating and modifying patterns themselves. ## Using Adoption Data to Guide the Design System - Design adoption became a way to evaluate the value and reach of Gestalt. - Higher usage could demonstrate that investment in corresponding engineering components was justified. - Low adoption could indicate that: - Designers were unaware of an existing component. - The component did not meet their needs. - Documentation or discoverability needed improvement. - A component required redesign or better cross-platform support. - Because design precedes implementation, Figma usage could serve as an earlier signal than production code adoption. Figma’s native analytics provide a useful starting point, but meaningful adoption measurement requires context. Teams should compare design-system usage with the total design surface, use the data to identify gaps, and treat Figma adoption as a complementary metric to code adoption.

Read original(opens in new tab)
datadogOriginal article

Performance improvements in the Datadog Agent metrics pipeline | Datadog (opens in new tab)

Datadog engineers recently optimized the Datadog Agent's metric processing pipeline to achieve higher throughput and lower CPU overhead. By identifying that metric context generation—the process of creating unique keys for metrics—was a primary bottleneck, they implemented a series of algorithmic changes and Go runtime optimizations. These improvements allow the Agent to process significantly more metrics using the same computational resources. ### Identifying Bottlenecks via CPU Profiling * Developers utilized Go’s native profiling tools to capture CPU usage during high-volume metric ingestion via DogStatsD. * Flamegraph analysis revealed that the `addSample` and `trackContext` functions were the most CPU-intensive components of the pipeline. * The profiling data specifically pointed to tag sorting and deduplication as the underlying operations consuming the most processing time. ### The Challenges of Metric Context Generation * The Agent must generate a unique hash (context) for every metric received to address it within a hash table in RAM. * To ensure the same metric always generates the same key, the original algorithm required sorting all tags and ensuring their uniqueness. * The computational cost of sorting lists repeatedly for every incoming message created a performance ceiling for the entire metrics pipeline. ### Specialization and Runtime Optimization * **Algorithmic Specialization:** The team implemented specialized sorting logic that adjusts based on the number of tags, optimizing the "hot path" for the most common metric structures. * **Hashing Efficiency:** Micro-benchmarks identified Murmur3 as the most efficient hash implementation for balancing speed and collision resistance in this use case. * **Leveraging Go Runtime:** The team transitioned from 128-bit hashes to 64-bit metric contexts. This change allowed the Agent to utilize Go's internal `mapassign_fast64` and `mapaccess2_fast64` functions, which provide optimized map operations for 64-bit keys. ### Redesigning for Performance * The original design followed a rigid "hash metric name -> sort tags -> deduplicate tags -> iterative hash" workflow. * Recognizing that sorting was the primary architectural bottleneck, the team moved toward a new design intended to minimize or eliminate the overhead of traditional list sorting during context generation. To achieve similar performance gains in high-throughput Go applications, developers should profile their applications under realistic load and look for opportunities to leverage runtime-specific optimizations, such as using 64-bit map keys to trigger specialized compiler paths.

datadog2 min readCurated summary

Performance improvements in the Datadog Agent metrics pipeline

The Datadog Agent needed to process more metrics without increasing CPU usage. Profiling showed that generating unique metric contexts—especially sorting and deduplicating tags—was a major bottleneck. Datadog improved throughput through specialized sorting paths, faster hashing, and a more efficient context-storage design. ## Identifying the Bottleneck - Datadog uses Go’s CPU and memory profiling tools to optimize the Agent’s metrics pipeline. - Profiles were captured while Agents processed large volumes of DogStatsD metrics, ensuring the results reflected real workload pressure. - Flamegraphs showed that `addSample` and `trackContext` consumed the most CPU. - Sorting-related functions, including `util.SortUniqInPlace` and `sort`, were significant contributors to that cost. ## How Metric Contexts Work - Each received metric is assigned a metric context that uniquely identifies it in an in-memory hash table. - The context must incorporate: - The metric name - Tags included in the DogStatsD message - Container-generated tags - The context is computed as a hash, so it must be fast while minimizing collisions. - Tags must be consistently ordered so the same metric always produces the same context. - The original implementation sorted tags and removed duplicates, making sorting a recurring CPU expense. ## Specialized Sorting - Performance varied according to the number of tags attached to a metric. - Datadog introduced specialized sorting paths based on tag count. - This allowed common cases to use more efficient algorithms while retaining correct ordering and deduplication. ## Faster Hashing and Map Access - Micro-benchmarks compared hash functions according to speed and uniqueness. - Murmur3 performed best for Datadog’s requirements. - Datadog also changed metric contexts from 128-bit to 64-bit hashes. - A 64-bit hash still provided sufficient collision resistance for the use case and enabled Go runtime optimizations: - `runtime.mapassign_fast64` - `runtime.mapaccess2_fast64` - These optimized map operations improved both context storage and metric sampling performance. ## Redesigning the Algorithm - Sorting served two purposes: producing an ordered tag list and helping deduplicate tags. - Because sorting was the largest bottleneck, Datadog began exploring a design that could address these responsibilities more efficiently rather than relying on a single general-purpose sort. The practical lesson is to profile under realistic load, optimize the hottest paths, and combine targeted specialization, benchmark-driven implementation choices, and data-structure redesign to increase throughput without adding CPU capacity.

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

The Future of Design Systems is Complicated | Figma Blog

Design systems have evolved from simple visual metaphors into complex frameworks supporting many platforms, use cases, accessibility needs, and performance expectations. The article argues that teams need more structure to manage this complexity, but excessive control can suppress creativity. The future lies in balancing consistent systems with flexibility, experimentation, and contributions from the wider design community. ## Complexity Is the New Normal - Early systems such as Google’s Material Design used familiar metaphors—like stacked paper—to help users understand digital interfaces. - Google later abandoned that metaphor as users became more comfortable with digital interactions and products expanded across: - New devices and form factors - Accessibility standards - More sophisticated interactions - Higher performance expectations - Products such as Instagram evolved from single-purpose apps into platforms for discovery, advertising, partnerships, and shopping. - Larger teams now work across multiple interconnected systems, creating a need for better ways to organize design and development work. ## Taming Chaos with Structure - Design teams are adopting processes inspired by software development, particularly branching and merging. - Contributors can work on isolated branches, propose fixes or components, and have system managers review changes before incorporating them into the main system. - Spotify’s Encore supports “local systems,” allowing sub-teams to fork and extend the central system for specialized needs. - Spotify’s advertising team developed a strong collection of video-player components, which later influenced the broader organization. - Open design systems can: - Gather feedback from a wider range of users - Encourage outside contributions - Make products and design decisions more transparent - Build organizational trust and visibility ## When Structure Becomes Too Restrictive - Strict systems can limit experimentation and make designers feel they lack creative freedom. - A design system should reduce the effort required to express ideas, not create additional barriers. - Shopify designer José Torre compares systems to gardening rather than architecture: - Architecture implies that everything is planned and finished. - Gardening involves planting, observing, adapting, and intervening as unexpected growth occurs. - Components such as buttons and menus may develop in unforeseen directions, so systems need room to evolve rather than enforcing rigid boundaries. ## Finding the Balance - Effective design systems must combine consistency with adaptability. - Teams should establish enough structure to coordinate large, interconnected efforts while allowing local experimentation and new patterns to emerge. - Collaboration, contribution workflows, and ongoing maintenance are more valuable than treating a design system as a fixed, finished artifact. Design systems should be treated as living ecosystems: structured enough to provide shared foundations, but flexible enough to support creativity, accessibility, and changing product needs.

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

How Linear made the most of a DDoS | Figma Blog

Linear’s website went down during a DDoS attack shortly after a major redesign launch. Rather than leave visitors at a login page, the team turned the crisis into an opportunity by publishing the redesign directly as a Figma file. The unexpected workaround generated significant attention and demonstrated the value of fast, creative incident response. ## The Redesign and Its Complexity - Linear’s team had spent months exploring ideas for the new website. - The Figma file contained thousands of iterations, frames, large images, and design inspirations. - The file became so large that Figma warned it was approaching the browser’s memory limits. - Although the redesign took months to develop, the final work came together during the last 24 hours before launch. ## The DDoS Attack - On October 13, 2022, Linear’s homepage became unavailable. - The team initially suspected that the new redesign had introduced a technical problem. - Investigation revealed that the outage was caused by a distributed denial-of-service attack overwhelming the site with traffic. - Their immediate priority was restoring access to the application, so visitors were redirected from site pages directly to the login page. ## Turning the Outage into an Alternative Homepage - The direct login redirect restored app access but made the public launch feel anticlimactic. - As social media discussions about the redesign continued, Jori Lallo suggested publishing the Figma design file itself. - Paco Coursey and Edgar Ambartsoumian were initially hesitant, but Jori encouraged them to proceed. - The Figma file became an unconventional replacement for the unavailable homepage and attracted widespread attention online. The incident shows how a team can respond constructively under pressure: stabilize critical functionality first, then use creativity to preserve the user-facing experience when the normal solution is unavailable.

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

Figma Persona 2022: What’s your creative collaboration style? | Figma Blog

Figma Persona 2022 presents a playful quiz designed to help people reflect on their creative collaboration and working styles. Based on 21 questions across problem-solving, workspace habits, and collaboration, the quiz assigns one of eight Figma-inspired personas. The article encourages teams to use these insights to improve communication, planning, and creative collaboration. ## The Figma Persona Quiz - The quiz is intended as an end-of-year reflection and goal-setting exercise. - It evaluates three areas: - How someone generates ideas and solves problems - How they organize their workspace and use tools - How they collaborate with others - Results fall into eight personas: - Lone Ascender - Canvas Captain - Direct Mobilizer - Artful Detacher - Bounding Boxer - Branch Merger - Vector Networker - Bézier Curve Baller ## Organized Individualists - Organized individualists prefer: - Tidy processes and clear deliverables - Defined milestones and structured workflows - Working independently before regrouping - Async updates and bug bashes - They are most effective when given space to develop ideas and solutions. - Collaborators should provide clear expectations, async pre-work, and precise requests. ## The Lone Ascender - The Lone Ascender is described as an organized, analytical individualist. - This persona excels at: - Solving complex problems - Building tactical, practical, systems-driven solutions - Applying consistent processes - Scaling difficult or complicated work - Lone Ascenders favor pragmatism and systematic thinking over idealism. - They value occasional collaboration but may be protective of file organization and formatting. - Suggested tools and habits include: - Memorizing shortcut keys and quick actions - Using FigJam templates to extend structured workflows - Applying strong organizational systems within Figma Overall, Figma frames the personas as a lighthearted way to recognize different working preferences. The practical recommendation is to use the results as a conversation starter, giving teammates the structure, independence, or collaboration style that helps them do their best work.

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

How Magician uses Figma’s text review API | Figma Blog

Magician, an AI-powered Figma plugin from Diagram, uses Figma’s text review API to generate copy suggestions directly while designers edit text layers. The API runs in the background and integrates with Figma’s editor rather than requiring a separate plugin window. Diagram argues that this creates a productive intersection between product design and AI, helping users overcome writer’s block and iterate faster. ## Figma’s Text Review API - The API lets developers create default text review plugins that run automatically while users type on the canvas. - Plugins can highlight text ranges and provide replacement suggestions. - Potential applications include: - Spell checking and grammar correction - Improving marketing copy - Enforcing company style guides - Generating alternative wording ## Magician and Its AI “Spells” - Magician is a Figma design tool created by Diagram to support creativity and ideation. - Its initial features are organized as “magic spells”: - **Magic Icon** for generating icons - **Magic Image** for creating imagery - **Magic Copy** for writing assistance - The plugin is designed as an extensible platform so new AI capabilities can be added consistently. ## Magic Copy in Practice - Magic Copy uses the text review API to suggest alternatives as users edit text layers. - It can generate options for: - Headlines - Body text - Calls to action - Suggestions appear directly within the editing workflow, making the feature useful when designers are unsure what to write or want to improve existing copy. ## A New Plugin Interaction Model - Unlike traditional plugins that require users to open and interact with a separate window, the text review API works in the background. - Its results are integrated into Figma’s native editor interface. - Although the API was primarily intended for spell checking, Diagram repurposed it for AI-assisted copywriting. ## Iteration and Experimentation - Diagram began with Magic Copy and other features as separate plugins before combining them into Magician. - The team continuously fine-tuned each spell’s output to make it useful and consistent across different contexts. - Its development was influenced by accessible generative AI tools and models such as Stable Diffusion and OpenAI. - The team’s approach emphasizes starting small, testing ideas quickly, and refining what works. Magician demonstrates how Figma’s text review API can extend beyond correction tools into creative assistance. Developers can use the API’s seamless editor integration to build focused AI experiences that help designers write, explore, and iterate without interrupting their workflow.

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

Welcome to the WIP | Figma Blog

Modern digital products are never truly finished, so product development rarely follows the neat sequence of research, brainstorming, design, testing, and launch. Figma argues that teams should embrace this “work in progress” reality, sharing work earlier and designing workflows around continuous collaboration. The challenge is managing changing feedback and uncertainty without waiting for a mythical perfect moment to review or finalize work. ## Digital Products Are Always Works in Progress - Physical product development historically required a linear process because changes were expensive and slow. - Digital products can be updated quickly, making iteration continuous rather than stage-based. - Browser-based tools let collaborators access and modify the same file in real time. - Early sharing lowers the stakes: labels such as “[WIP]” signal that feedback is welcome and the work is not final. ## The Benefits and Confusion of Continuous Collaboration - Real-time collaboration encourages teams to share unfinished work sooner. - Feedback can become outdated as designs change. - Previous approvals may no longer apply when the underlying work evolves. - Teams need better ways to stay informed, including notifications, mobile comments, and integrations with tools such as Google Calendar, Microsoft Teams, and Zoom. - Because work may never have a clearly defined final state, teams can even forget to remove “work in progress” labels after launch. ## Review Work on a Predictable Cadence - In an always-changing workflow, it is difficult to identify the perfect time to involve stakeholders or leadership. - Teams may be tempted to wait until the problem, solution, or product feels sufficiently complete. - Figma recommends predictable, intentional reviews—such as regular weekly critiques—instead of waiting for a supposedly ideal milestone. - Frequent check-ins help teams build confidence progressively while keeping feedback connected to the current state of the work. Teams should treat iteration as a normal operating condition, not a sign of poor planning. Regular reviews, clear communication, and collaboration tools can make continuous work more manageable without forcing it into an unrealistic linear process.

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

A conversation with Figma's accessibility team | Figma Blog

Figma’s accessibility team describes how open beta testing and user feedback shaped screen reader support for prototypes. They learned that accessibility must account for different assistive technologies, varied user needs, and interaction between visual and nonvisual experiences. The team sees the current release as an important step, but plans further improvements to generated HTML and accessibility evaluation tools. ## Lessons from the Open Beta - Testing with real users revealed that support working well in Mac VoiceOver did not guarantee compatibility with JAWS and other screen readers. - Figma began testing major screen reader technologies earlier in development. - The team recognized that screen readers complement visual work rather than serving only users who cannot see. - Low-vision users may use visual and audio information together for additional context. ## Design Decisions for Screen Reader Support - Added positioning information to the accessibility tree so sighted screen reader users can understand the cursor’s location on the canvas. - Made “On hover” interactions activate when clickable elements receive focus. - Enabled scrollable areas to follow the screen reader cursor, similar to native HTML behavior. - Adjusted auto-hiding toolbars so focused controls remain visible. - Added shortcuts to open prototype mode: - Mac: `Option + Command + Return` - PC: `Alt + Ctrl + Enter` - Added a persistent screen reader support toggle and more guidance through Figma Community. ## Feedback from Accessibility Partners - Figma works with Fable to test product flows with people who use assistive technologies. - Partner feedback highlighted the need to communicate accessibility controls more clearly. - Accessibility navigation shortcuts are being added to the keyboard shortcuts panel, along with improvements to the panel itself. - For FigJam, screen readers now receive information about the number of children or siblings associated with each item. - Fable’s input helps Figma support different screen reader software and users with varying levels of expertise. ## Future Accessibility Improvements - Figma plans to make content available to screen reader users by default. - The team wants to give designers greater control over the HTML generated from their designs. - Longer term, Figma hopes to provide tools that help designers assess accessibility without requiring deep screen reader knowledge. Figma’s experience shows that accessibility improves through ongoing testing, direct collaboration with assistive-technology users, and removing assumptions about how people work. The current screen reader support is presented as a foundation for continued product and design improvements.

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

Figma’s feedback gift guide | Figma Blog

Feedback is most effective when it is treated as a thoughtful, context-dependent exchange rather than a generic “gift.” Figma argues that good feedback depends on timing, project stage, team culture, and the relationship between the people involved. Matching feedback to the work’s level of development helps teams stay open to possibilities while still making progress toward clear goals. ## Match Feedback to the Design Stage - **Brainstorming:** Keep feedback expansive so it does not eliminate promising directions too early. - **Early concepts:** Use research and data to narrow options while preserving an open mind. - **Product reviews:** Check that the work supports product and business objectives. - **Design critiques:** Offer detailed UX and visual suggestions and encourage consistency. - **Prototypes:** Focus on usability and animation. - **High-fidelity designs:** Examine detailed decisions that may benefit from another perspective. - **Final designs:** Identify overlooked flows, use cases, or remaining gaps. - When requesting feedback, explain what type of input would be most useful at that stage. ## Adapt to Team Culture - Feedback practices should reflect where a company is in its shift toward collaboration. - Teams early in that transition may need more context, frequent critical conversations, and patience while feedback relationships develop. - Teams with an established feedback culture can rely on direct communication through proven channels. - Feedback should meet teammates where they are rather than assuming every team has the same norms. ## Respect Timing and Working Styles - Timing matters as much as content; feedback is more constructive when people are ready to receive it. - Consider project deadlines, teammates’ schedules, time zones, and personal preferences. - Avoid sending work-related messages at inconvenient hours without setting expectations. - Communicating your own working style and accommodating others’ schedules can reduce friction. Thoughtful feedback helps turn conversations into action, but it requires adapting both the message and delivery to the project, people, and culture involved.

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

Taking cues from code | Figma Blog

Design systems are becoming more complex as teams collaborate across interconnected products, and Figma argues that design can learn from software engineering. The goal is to introduce structure without eliminating creative flexibility. The article highlights component composition and decoupling structure from presentation as ways to make systems more adaptable and scalable. ## Design Borrowing from Code - Design was once largely local and isolated, with files stored on individual machines. - Modern design involves larger teams, shared ecosystems, and dependencies across products and files. - Design systems help maintain consistency and quality at scale, but excessive structure can restrict exploration. - Figma sees software engineering patterns as useful models for handling this complexity. ## Nesting Components for Flexible Layouts - Simple systems can represent variations through component variants. - As the number of layouts grows, maintaining every variation separately becomes difficult. - Component properties can support limited optionality, such as cards with or without images or pull quotes. - Properties are insufficient when components differ substantially in orientation and structure. - Composition offers a more flexible approach: - Designers create small, reusable sub-components. - These sub-components are nested inside larger, layout-specific components. - The same building blocks can be recombined into many arrangements. - This reduces the need to anticipate every possible layout when designing the system. ## Decoupling Structure from Presentation - Basic design systems often hard-code a single visual theme into each component. - Teams may later add light and dark modes, followed by themes for different products, brands, or sub-brands. - As the number of themes increases, maintaining colors and styles becomes increasingly burdensome. - The article introduces headless design systems as an architectural response to complex theming requirements, separating a component’s underlying structure from its visual presentation. A scalable design system should favor composable building blocks and flexible theming rather than attempting to encode every possible layout and brand variation directly into monolithic components.

Read original(opens in new tab)