Techlist.io - Korean Tech Blog Curator

figmaMay 15, 20232 min readCurated summary

Announcing FigJam screen reader support | Figma Blog

FigJam now supports screen readers and keyboard-only navigation, enabling users to read and create much of a file’s content. The release focuses on making canvas-based collaboration more inclusive while acknowledging that some features remain inaccessible. Figma’s approach relied heavily on user testing, careful iteration, and reusable accessibility patterns. ## What the Update Enables - Users can move focus around the FigJam canvas and through menus and screens. - Screen readers can interpret: - File structure and canvas hierarchy - Shapes containing text - Stickies and tables - Image alt text - Users can create, edit, and read content without relying on a mouse. ## Expanding Accessibility to Collaborative Work - FigJam was prioritized because it brings entire teams together for brainstorming, alignment, and decision-making. - Its relatively surface-level interface provided an opportunity to address accessibility before tackling Figma Design’s more complex menu and interaction structure. - The goal is to make collaboration inclusive for as many team members as possible. ## Designing Without Established Canvas Patterns - Unlike conventional websites and widgets, canvas-based tools have relatively few established ARIA patterns or accessibility best practices. - Figma first had to determine which capabilities were essential for effectively using FigJam with assistive technology. - The team worked with Fable and users of assistive technologies to test designs and gather feedback. - User journeys helped define a practical set of core features for the initial release. ## Learning Across Keyboard and Screen Reader Setups - Different screen readers, settings, and keyboard layouts create thousands of possible interaction combinations. - Beta interviews revealed new usage patterns and accessibility issues that informed the product. - Improvements also benefited Figma’s broader codebase, including reusable ARIA labels and tags for React components. - Remaining unsupported features include cursor chat, stamp adjustments, voting, the emote wheel, widgets, and editing freeform vector elements such as lines, highlights, washi tape, and marker drawings. Figma’s release is a meaningful foundation for accessible FigJam collaboration, but users should expect continued gaps as the team expands support to more interactive and multiplayer features.

Read original

Figjam React Keyboard Navigation Screen Readers+2

figmaMay 8, 20232 min readCurated summary

The Future of Design Systems Is Accessible | Figma Blog

Design systems can make accessibility a scalable, built-in practice rather than a late-stage compliance task. By standardizing accessible colors, components, documentation, and feedback processes, they allow improvements to spread across an entire product ecosystem. The article also highlights AI as an emerging tool for detecting and fixing accessibility issues, while emphasizing the need for responsible implementation. ## Accessibility and design systems belong together - Only about 3% of the internet was accessible to people with disabilities in 2022. - Design systems offer a way to improve that figure by embedding accessibility rules into shared components and guidelines. - In-house design system adoption increased by 22% in 2020, and 47% of surveyed organizations reported including accessibility guidelines. - Accessible design is both a social responsibility and a business opportunity, given the global population of people with disabilities and their significant purchasing power. - Accessibility can be integrated into: - Tested foreground and background color combinations - Individual UI components - Consistent documentation and usage guidance - Ongoing feedback and testing processes - System-level changes can be propagated across many product instances, making accessibility fixes more efficient and consistent. ## Responsible AI in accessibility - Design system teams are increasingly exploring AI to improve accessibility. - New AI-powered tools aim to identify and resolve common issues automatically. - Potential applications include: - Generating descriptions for images - Labeling buttons that lack accessible names - Adding semantic structure to interfaces - These tools can accelerate accessibility work, but they should supplement—not replace—human expertise, testing, and accountability. Design systems should treat accessibility as a foundational requirement from the beginning. Teams can make the greatest impact by combining accessible system components and standards with continuous testing, inclusive feedback, and carefully governed automation.

Read original

AI Design Systems Accessibility Wcag+2

figmaMay 2, 20232 min readCurated summary

How Figma Draws Inspiration From the Gaming World | Figma Blog

Figma’s technology shares more with a game engine than a traditional web application. Like games, it combines graphics rendering, interaction, multiplayer, animation, and other systems to create a responsive digital world. This architecture, along with close collaboration across engineering, design, product, and research, enables Figma and FigJam to support complex creative work in real time. ## Engineers as Digital World-Builders - Game engines combine foundational systems such as: - Graphics and rendering - User controls - Multiplayer - Physics and collisions - Animation - Artificial intelligence - Combat or other specialized mechanics - Figma similarly builds a 2D graphics and rendering system for the web. - Engineers ensure that text, shapes, and lines appear correctly while users pan and zoom across a canvas. - Collaboration is central to Figma, so its real-time collaboration engine is called “multiplayer,” inspired by cooperative games. - Figma and FigJam are built from many interacting “systems,” including: - Multiplayer editing - Spring animations - Audio and cursor chat - Component Variants - Plugins and widgets - Because these systems must run efficiently in browsers and mobile apps, Figma uses a game-engine-like stack rather than a conventional web stack. - The canvas is written in C++ and compiled to WebAssembly, helping address memory and performance constraints. ## Creativity Requires Systems-Level Collaboration - Game developers work closely with artists and designers to refine both technical behavior and user experience. - Figma follows a similar model, with engineers collaborating across product management, design, data science, and research. - Interdependent systems create emergent behavior: changing one system can affect many others. - The article compares this to *The Legend of Zelda: Breath of the Wild*, where fire can provide warmth and food, cause damage, or help defeat enemies. - Figma’s complexity produces comparable interactions, where an apparent problem in one feature may actually result from behavior elsewhere in the system. - This systems-level collaboration helps teams investigate unexpected failures and improve the overall product rather than treating each feature in isolation. Figma’s game-inspired approach is both architectural and cultural: build modular, interacting systems, optimize for real-time performance, and involve diverse disciplines in solving problems. Teams building similarly complex collaborative tools can benefit from treating the product as a living digital world rather than as a collection of disconnected web features.

Read original

Real Time Collaboration Rust Webassembly C+++3

coupangApr 17, 2023Original article

Coupang Rocket Delivery: A (opens in new tab)

Coupang transitioned its Rocket Delivery management from a text-based zip code system to a spatial index-based system using Uber’s H3 library. This shift addresses the limitations of zip codes, which became too coarse for high-density delivery areas, by enabling precise, map-based visualization and manipulation of delivery zones. By adopting a hexagonal grid-based approach, Coupang has improved operational flexibility and its ability to handle complex urban delivery environments. ### The Limitations of Zip Code Systems * Zip codes originally served as the base unit for Rocket Delivery, but as delivery volumes scaled, individual codes became too large for a single driver to manage. * Sub-dividing these areas (e.g., splitting a zip code into specific apartment complexes or even individual buildings) required the manual expertise of senior managers because text-based addresses lack inherent spatial intelligence. * The previous reliance on text made it difficult to visualize delivery boundaries or reassign areas quickly in response to changes in order volume. ### Implementing H3 for Geospatial Indexing * To modernize the system, Coupang adopted H3, a hexagonal hierarchical geospatial indexing system that converts geographic coordinates into unique cell identifiers. * Hexagons were selected over square grids because they provide uniform distances between the center of a cell and all its neighbors, which minimizes distortion in distance-based calculations. * The system uses H3’s hierarchical structure to manage different levels of detail, allowing the platform to aggregate small hexagonal units into larger, custom-defined delivery polygons. ### Technical Challenges in System Redesign * A primary engineering hurdle was selecting the optimal grid resolution to ensure cells were small enough to capture individual building footprints without creating excessive data overhead. * The team developed algorithms to transform groups of hexagonal indices into filled polygons, enabling camp managers to "draw" and modify delivery zones directly on a digital map. * By basing the system on spatial coordinates rather than administrative text, the platform can dynamically adjust to urban changes, such as the construction of new high-rises or the demolition of old structures. Transitioning from text-based addressing to hexagonal indexing allows logistics platforms to move beyond the constraints of administrative boundaries. For high-density urban delivery services, adopting a spatial-first infrastructure like H3 is a necessary step to ensure scalability and operational precision.

Data Visualization Geospatial Data H3 Spatial Indexing+2

datadogApr 17, 20233 min readCurated summary

Making fetch happen: Building a general-purpose query and render scheduler

Datadog rebuilt its dashboard scheduler to improve responsiveness while distributing network and rendering work more efficiently. The legacy system helped, but had grown into a complex set of roughly 20 interdependent heuristics that were difficult to maintain and poorly separated query scheduling from rendering. A simpler, general-purpose approach reduced request spikes, improved fetching performance, and created a foundation for browser-aware task scheduling. ## Limitations of the Original Scheduler - A periodic updater determined when widgets should request fresh data based on factors such as time range and browser focus. - Query tasks for visible widgets ran immediately; offscreen queries were delayed using heuristics such as pending-query counts and historical fetch durations. - Render tasks similarly prioritized visible widgets and delayed offscreen work. - The system improved performance over an unscheduled baseline by reducing main-thread work and flattening query traffic. - Over time, it accumulated around 20 parameters and interlinked rules. - Query and render concerns were mixed together: - Queries could be delayed because too many render tasks were pending. - Renders could be delayed based on data size even when browser resources were available. - The dashboard-specific implementation could not easily be reused across Datadog’s increasingly generalized widget framework. ## A General-Purpose Scheduling Strategy - Datadog separated query scheduling from render scheduling so each could be developed, tested, and rolled out independently. - The team evaluated existing heuristics across dashboards of different sizes and under different browser conditions. - Several rules were removed without harming performance: - Unfocused or occluded tabs did not need special delays because the periodic updater and browser already throttle them. - The redesign aimed to preserve two goals: - Keep query execution distributed over time. - Prioritize widgets visible to the user. - The new system was progressively deployed, first to dashboards and then to the shared data-fetching framework used across Datadog. ## Simpler Query Scheduling The new query algorithm uses a small set of straightforward rules: - Fetches for visible widgets run immediately. - Non-visible queries are ranked and executed in fixed time windows, subject to a task limit. - Query execution pauses when the number of pending fetches becomes too high. - The chosen configuration uses: - A 2,000-millisecond time window. - A maximum of 10 tasks per window. - FIFO-style ranking for offscreen queries, favoring earlier requests. - The scheduler uses only about six parameters instead of the legacy system’s roughly 20. - The simplified algorithm produced a better task distribution than the old scheduler. - “429 Too many requests” errors dropped significantly, reducing retries and helping data arrive sooner. ## Browser-Aware Render Scheduling - The old render scheduler did not account for the browser’s available CPU and memory resources. - Datadog adopted the Browser Scheduling API to create prioritized tasks that the browser can schedule natively. - Tasks can receive priorities such as: - `user-blocking` - `user-visible` - `background` - A `TaskController` assigns a priority signal to scheduled work. - Priorities can later be changed for all tasks controlled by the same controller, and tasks can be aborted. - The API was supported in Chromium and Firefox Nightly, with a polyfill for other browsers. Datadog’s experience suggests that performance schedulers benefit from simple, independently testable rules: prioritize visible work, smooth network activity, and let the browser manage expensive rendering when possible.

Read original

Database Design Performance Optimization Query Scheduling Browser Scheduling Api+4

datadogApr 17, 2023Original article

Making fetch happen: Building a general-purpose query and render scheduler | Datadog (opens in new tab)

Datadog replaced its complex, dashboard-specific scheduling system with a generalized, modular query and render scheduler to improve performance across all its web applications. By simplifying query heuristics and leveraging the Browser Scheduling API for renders, the engineering team achieved a more stable backend load and smoother UI interactions. This transition transformed a brittle set of rules into a scalable framework that optimizes resource utilization based on widget visibility and browser availability. ## Limitations of Legacy Scheduling The original scheduling system was a complex web of over 20 interlinked heuristics that became difficult for developers to maintain or reason about. While it performed better than an unscheduled baseline, it suffered from several structural flaws: * **Tight Coupling:** Query and render logic were unnecessarily linked; for example, fetches were sometimes delayed based on pending render tasks, even when throttling fetches wasn’t necessary. * **Lack of Generalization:** The system was hardcoded specifically for dashboards, making it impossible to use the same optimization benefits for other widget-heavy products in the Datadog suite. * **Inefficient Resource Management:** Renders were often delayed based on arbitrary data size rules rather than the actual real-time availability of the browser's CPU and memory resources. ## A Simplified Query Algorithm To create a more predictable and efficient system, the team stripped away redundant rules—such as manual throttling for unfocused tabs, which modern browsers already handle—and moved to a streamlined query model. The new algorithm is governed by only six parameters: * **Visibility Priority:** Fetches for widgets currently visible in the viewport are executed immediately to ensure a responsive user experience. * **Fixed Time Windows:** Non-visible queries are ranked by enqueue time and processed in 2000ms windows with a limit of 10 tasks per window. * **Error Reduction:** The more stable distribution of tasks significantly reduced "429 (Too many requests)" errors, leading to faster overall data loading since fewer retries are required. * **Framework Integration:** This simplified logic was moved into a standard data-fetching framework, allowing any Datadog product using generalized components to benefit from the scheduler. ## Render Scheduling with the Browser Scheduling API While the query scheduler handles data fetching, a separate render scheduler manages the impact on the browser’s main thread. By moving away from legacy heuristics and adopting the Browser Scheduling API, Datadog can now schedule tasks based on native browser priorities: * **Prioritization:** The API allows developers to categorize tasks as `user-blocking`, `user-visible`, or `background`, ensuring the browser prioritizes critical UI updates while deferring heavy computations to idle periods. * **Resource Awareness:** Unlike the old system, this API is natively aware of CPU and memory pressure, allowing the browser to manage execution timing more effectively than a JavaScript-based heuristic. * **Future-Proofing:** Currently supported in Chromium and Firefox Nightly (with polyfills for others), this approach allows for mass updates to task priorities and the ability to abort stale tasks via `TaskController`. Standardizing on a modular scheduling architecture allows engineering teams to optimize both network traffic and main-thread performance without the maintenance overhead of complex, custom rule sets. For high-density data applications, leveraging native browser APIs for task prioritization is recommended to ensure smooth rendering across varying hardware capabilities.

Datadog Query Scheduling Browser Scheduling Api Task Optimization+3

figmaApr 12, 20232 min readCurated summary

How to build ground-breaking products: A manager’s guide | Figma Blog

Great products come from clarity: teams need to understand the customer problem, the reason it matters, and what can realistically be built. Managers help create that clarity by focusing on customer value rather than internal goals, involving customers directly, filtering ideas, and keeping teams aligned. The article argues that practical, collaborative decision-making produces stronger products than pursuing organizational priorities or exciting ideas in isolation. ## Design for Customers, Not OKRs - Avoid “shipping the org chart”—building products around company hierarchy instead of customer needs. - Localized goals and narrowly defined OKRs can cause teams to solve the wrong problems. - Roadmaps and planning should make the product’s value proposition visible to the wider organization. - Prototypes help teams: - Identify whether they are addressing the right problem. - Build leadership support. - Let decision-makers explore a solution before committing to it. - Make product decisions faster and more transparently. ## Put Customers to Work - Ironclad used a customer round table of 10–15 participants to understand how customer needs changed during the pandemic. - Insights from these conversations shaped a major portion of the company’s 18-month product roadmap. - Customers contributed throughout the process by reviewing concepts and beta-testing features. - Co-creation improves product quality while also making customers more invested in the final outcome. ## Filter Ideas Through Three Questions - Collaboration can generate too many ideas to pursue effectively; Work & Co. produced nearly 50 concepts for an IBM Research platform within weeks. - Managers should evaluate ideas by asking: - Why does this product or platform need to exist? - What does it need to do? - How will we build it? - The goal is not to choose the most exciting idea, but the most valuable and shippable one. - Strong product management connects creativity with feasibility. ## Keep Teams Focused - After selecting a direction, managers must help teams remain focused on executing it. - The article introduces the Eisenhower Matrix as a strategy for prioritizing work according to urgency and importance. - This kind of prioritization helps teams concentrate on meaningful product work rather than being distracted by less consequential tasks. Managers should ground product decisions in customer value, use prototypes and customer collaboration to reduce uncertainty, and apply practical prioritization to turn promising ideas into products that can actually ship.

Read original

Figma User Experience Prototyping Figjam+4

figmaApr 3, 20233 min readCurated summary

The growing pains of database architecture | Figma Blog

Figma outgrew its single Amazon RDS PostgreSQL database as traffic increased roughly threefold annually, pushing peak CPU utilization above 65% and making latency unpredictable. Initial fixes—larger hardware, read replicas, new databases, and PgBouncer—provided temporary relief but could not adequately reduce write load or handle replication-sensitive reads. Figma ultimately chose vertical partitioning, moving groups of related tables into separate databases as a lower-risk, incremental path to scalability. ## The Limits of a Single Database - Figma stored metadata such as permissions, file information, and comments in one large RDS instance. - Increasing users, new features, and preparation for a second product drove database traffic sharply upward. - Peak CPU utilization reached more than 65%, with latency becoming less predictable as the database approached its limits. - Full saturation would have made Figma unavailable, so the infrastructure team addressed the risk before it became an outage. ## Tactical Measures for More Headroom Figma introduced several short-term improvements: - Upgraded the database from an `r5.12xlarge` to an `r5.24xlarge` instance. - Added multiple read replicas to distribute read traffic. - Created separate databases for new use cases to prevent further growth of the original database. - Added PgBouncer to pool connections and reduce the impact of thousands of application connections. - These changes provided approximately another year of runway, but writes still consumed substantial resources. - Some reads could not be moved to replicas because the application was sensitive to replication lag. ## Evaluating Horizontal Scaling Figma considered horizontally sharding the database but found substantial technical and operational risks: - Many managed horizontally scalable databases were not natively compatible with PostgreSQL. - Migrating to NoSQL or Vitess would require complex double-read and double-write migration strategies. - NoSQL would also require significant application changes. - A managed distributed PostgreSQL system could make Figma an unusually large customer, exposing it to untested scaling limits. - Self-hosting would require new expertise, training, and considerable operational investment, diverting attention from the core scalability problem. ## Choosing Vertical Partitioning Instead of splitting individual tables across many database nodes, Figma chose vertical partitioning: - Groups of related tables would be moved to separate databases. - This approach immediately reduced load on the original database. - It preserved a future path toward horizontal sharding for particularly large or demanding table groups. - The strategy was considered more incremental and operationally manageable than replacing PostgreSQL or adopting a self-hosted distributed system. ## Selecting Tables to Move Figma evaluated candidate tables using two criteria: - **Impact:** Moving the tables should remove a meaningful portion of the database workload. - **Isolation:** The tables should have limited dependency on tables that remained in the original database. - To measure impact, the team analyzed average active sessions (AAS), which estimates the average number of active threads handling a query. - They gathered query activity from PostgreSQL’s `pg_stat_activity` view at 10-millisecond intervals to identify CPU waits associated with individual queries. Figma’s experience shows that database scaling does not always require an immediate move to distributed infrastructure. Carefully selected vertical partitioning can reduce pressure on a primary database while limiting migration risk and preserving more ambitious scaling options for the future.

Read original

PostgreSQL Amazon Rds Database Sharding Pgbouncer+3

figmaMar 27, 20233 min readCurated summary

Little Big Outtakes | Figma Blog

Figma’s “Little Big Outtakes” shares the behind-the-scenes decisions that shaped 30+ small product updates. The stories show how difficult edge cases, team feedback, and disciplined scoping often produced better outcomes than simply adding more functionality. Across search, prototyping, and previews, the teams improved features by making complexity visible, validating ideas collaboratively, and prioritizing achievable impact. ## Multi-select Search: Designing for Edge Cases - Multi-select search extended Figma’s find-and-replace feature, allowing users to select specific results with `Shift + Click` or `Cmd/Ctrl + Click`. - The team discovered a major complication: users cannot independently select a parent layer and one of its children. - Selecting multiple search results could therefore include unexpected descendants, especially in deeply nested files. - To clarify the behavior, the designers added: - A visual hierarchy in the search sidebar showing parent-child relationships. - Hover-selection previews when users hold `Command` or `Shift`. - Highlights for indirectly selected items and outlines for directly selected children. - The team concluded that edge cases were not peripheral to the feature—they fundamentally defined how multi-selection needed to work. ## Overlay Blur: Turning Ideas into a Concrete Fix - Figma’s prototyping viewer previously struggled to render background blur on overlays because overlays do not have ordinary content directly beneath them. - Engineer Brandon Lin documented his proposed approaches, potential problems, and solution before implementing the fix. - Teammates suggested passing the overlay’s position into the rendering code so it could identify the correct area to blur. - The final changes associated overlays with their respective frames and ensured that multiple overlays were drawn and layered in the correct positions. - Team feedback gave Brandon confidence that his initial reasoning was sound while helping make the implementation more precise. ## On-Canvas Previews: The Value of Scoping Down - On-canvas previews let users hover over design-panel options—such as blend modes, effects, and color blend modes—to preview changes before applying them. - The original concept considered a much broader scope, including boolean operations, component properties, and font selection. - Rather than attempting to support everything, the team audited dropdown-based editor properties and assessed each option for feasibility and performance risk. - They prioritized features that would not require major geometry changes or substantial canvas modifications. - The smaller release proved powerful enough to be useful while allowing the team to deliver and refine it more quickly. Figma’s examples suggest that strong product work often comes from embracing complexity selectively: expose confusing relationships, seek feedback early, and narrow ambitious ideas to the highest-value implementation.

Read original

Figma Prototyping Figjam User Interface+2

figmaMar 22, 20233 min readCurated summary

How the Figma design team level set on career leveling | Figma Blog

Figma revamped its product design and writing career levels after realizing its old one-page ladder no longer scaled with a growing, multi-product organization. The project began as an effort to define “craft” more clearly but expanded into a comprehensive framework for hiring, coaching, performance evaluation, and skill development. The resulting career levels emphasize concrete expectations, specialization at senior levels, and a visual, easier-to-use format in FigJam. ## Why Figma Revisited Its Career Framework - When Sara Culver joined Figma as a design manager in 2021, “craft” was widely considered essential to success, but teams disagreed on what it included. - Craft might mean: - Visual design - Prototyping - Motion or other specialized skills - Broader product design capabilities - The existing ladder had been created when Figma was smaller and covered areas such as: - Product strategy - Craft and quality - Mentorship and developing others - As the organization expanded, the document became too vague to support consistent coaching, evaluation, and hiring decisions. ## Research and Team Feedback - Culver surveyed designers about how they used the existing ladder and what they wanted from an updated version. - Designers asked for: - More detailed and concrete expectations - Clearer guidance for senior-level hiring and promotion - A stronger definition of craft at each level - The team questioned whether senior designers should be expected to excel equally in every skill or whether the framework should recognize “T-shaped” designers with broad abilities and deep expertise in one area. - Figma also reviewed career frameworks from companies including Slack, BuzzFeed, Meta, and Basecamp. - Designer Shana Hu provided extensive feedback and proposed a more visual FigJam-based format. ## Principles for the First Draft - The team created an inspiration board containing examples of career ladders and skills frameworks. - The proposed framework aimed to: - Group skills into clear areas - Replace rigid “ladder” language with “stages” or “levels” - Reflect the nonlinear nature of career growth - Use visual design to make expectations easier to scan and understand - Culver organized the framework around four core skill areas, with specific skills assigned to each area. ## Resulting Career Levels - Figma ultimately published new Product Design & Writing Career Levels alongside a Skills Widget. - The FigJam resource describes: - Expected performance at each level - Core competencies for product design and writing roles - Skills designers can develop over time - The framework is intended to help managers make better hiring and performance decisions while helping employees understand where to focus their growth. Figma’s approach suggests that career frameworks are most useful when they are specific, collaboratively developed, visually accessible, and flexible enough to recognize both broad capability and senior-level specialization.

Read original

Figma Figjam Product Design Career Leveling+2

figmaMar 14, 20232 min readCurated summary

How to get the most out of teams | Figma Blog

Effective people management is about creating conditions where teams can act with autonomy, focus, and purpose. The article recommends a few practical systems: limit goals, protect uninterrupted work, make participation equitable, encourage experimentation, and actively support career development. These practices help employees do better work while making managers accountable for the team’s success. ## Set Fewer, More Meaningful Goals - Ask team members to list their priorities at the start of a quarter or half. - Reduce an initial list of 10–15 goals to just three, forcing clear choices about what can realistically be completed. - Connect individual goals to the company’s most urgent strategic initiatives. - Make goals concrete and measurable by defining the impact they should create. - Share goals with other leaders to improve alignment and accountability. ## Make Meetings Worthwhile - Work & Co. limits teams to one daily check-in, leaving the rest of the day for focused individual work and collaboration. - Managers should distinguish between issues that require meetings and those that can be handled asynchronously in Slack or FigJam. - For unavoidable meetings, use structures that prevent outspoken participants from dominating. - Twitch adapted Amazon’s written-memo format for hybrid work: - Participants read a shared six-page document. - They spend 10–15 minutes adding questions and comments. - The group discusses the annotations afterward. - Written participation gives quieter employees a meaningful voice, especially in large meetings. ## Make Ideas More Valuable Than Turf - Ambiguous responsibilities can cause conflict, while overly rigid job descriptions can prevent innovation. - Oura Ring treats campaigns and projects as experiments built around strong hypotheses. - Teams measure results, then decide whether to scale, repeat, or abandon an idea. - Making experimentation everyone’s responsibility reduces confusion about ownership. - Employees are encouraged to pursue opportunities outside their formal roles, even when that means occasionally crossing boundaries. ## Support Nonlinear Career Conversations - Careers rarely follow a straightforward upward path. - Managers should help employees imagine multiple possible directions rather than presenting advancement as a single ladder. - This guidance is particularly important in remote work, where informal networking and spontaneous conversations happen less often. Managers can unlock their teams’ potential by replacing excessive control with clear priorities, focused collaboration, room for experimentation, and deliberate career support.

Read original

Figma Figjam Slack Product Management+2

figmaMar 13, 20233 min readCurated summary

Raising the (table) stakes on tables in FigJam | Figma Blog

FigJam introduced native tables to make roadmapping, planning, and organizing information clearer and easier to edit collaboratively. The team deliberately focused on visual presentation rather than complex data manipulation, prioritizing simplicity for both table creators and viewers. Building the feature required extensive work on multiplayer conflict resolution, responsive editing controls, and visual clarity at different zoom levels. ## Why FigJam Needed Tables - Internal teams were already creating tables with stickies and shapes for: - Feature requirements and prioritization - Project tracking - Product marketing messaging - Design critique feedback - Brainstorming and vote counting - Native tables improve performance and reduce the effort of assembling makeshift grids. - The core requirements were to make tables: - Clear - Easy to create - Editable by everyone - FigJam intentionally avoided becoming a complex spreadsheet or data-manipulation tool. ## Designing for Creators and Users - The team treated table creation and table editing as equally important experiences. - A single toolbar click creates a pre-styled table, similar to other FigJam elements. - Users can choose from a limited style palette, while the entire table remains visually consistent. - Adding rows or columns derives styling from the neighboring row or column. - Changing a table’s color automatically adjusts its text for readability. - Programmatically drawn borders help separate cells without creating excessive visual noise. ## Multiplayer Editing Challenges - Tables may contain many cells edited simultaneously by users at different zoom levels. - Unlike ordinary elements, simultaneous table edits cannot simply use “last update wins” behavior. - Changes often need to be merged so multiple users’ contributions are preserved. - Multiplayer support consumed at least half of the engineering effort. - The team spent months addressing concurrency bugs and edge cases, including collaborative typing in the same cell. - Testing included simulated second users, such as a script that repeatedly typed “FigJam.” ## Interaction Design for Collaborative Tables - Standard FigJam selection-based editing became visually overwhelming when multiple people edited different cells. - The team changed table behavior in two important ways: - Editing controls appear on hover and follow the user’s cursor. - A prominent button lets users add a complete row or column. - Table functionality adapts to zoom level: - At distant zoom levels, users can move and arrange the table. - At closer zoom levels, they can resize it and add rows or columns. - This approach keeps the interface uncluttered while exposing more controls when they are useful. The resulting feature keeps tables intentionally simple and presentation-focused while making them native to FigJam’s collaborative, visual environment. For teams that need lightweight planning, tracking, or structured brainstorming, native tables are preferable to building grids manually from shapes or sticky notes.

Read original

User Experience Figjam User Interface Real Time Collaboration+3

figmaMar 6, 20233 min readCurated summary

Creators need creators | Figma Blog

Figma argues that creators need both open sharing and sustainable ways to support their work. To strengthen Figma Community, it introduces new selling tools and the Figma Creator Fund, helping creators monetize paid resources while funding free ones. The goal is a healthier ecosystem where consumers gain access to useful work and creators can keep innovating. ## Learning Through Open Sharing - Rogie King describes learning HTML, CSS, and design through other creators’ blogs and public experiments. - Figma Community extends that model by letting people explore complete, layered design files rather than isolated tips or screenshots. - Sharing work publicly helps creators learn, build an audience, and contribute to a collective creative culture. ## Expanding Figma Community - Figma Community grew from an initial collection of 49 plugins into a broader platform for design files, plugins, and resources. - Community members can use plugins and build tools tailored to their workflows. - Figma presents the platform as an open, collaborative ecosystem where creators learn and grow together. ## Problems with Creator Logistics - Making and sharing creative work often requires handling: - Websites and domains - Hosting and payment processing - Marketing and social media - Refunds, customer support, and license keys - These business responsibilities can distract creators from designing, experimenting, and building. - Exposure alone is not a sustainable source of income, especially as creators’ personal responsibilities change. ## New Selling Tools - Plugin developers will gain access to more powerful APIs, including capabilities that are typically paid. - Creators can offer: - One-time, one-click payments - Free experiences through Figma’s payment API - Direct user access without emailing files or managing license keys - Improved analytics and tracking will help creators measure reach and impact. - Consumers will benefit from clearer paid-versus-free labels, direct purchasing, and try-before-you-buy options. ## The Figma Creator Fund - The Creator Fund will provide grants to people who make free resources for Figma Community. - It is intended to balance two important goals: - Keeping resources accessible to consumers - Compensating creators for the time and effort required to produce quality work - The fund reflects Figma’s belief that creators should be able to give back without relying solely on unpaid labor or “exposure.” ## Building the Next Generation of Community Work - Figma hopes the new tools will encourage creators to develop plugins, icon sets, design systems, and other resources. - Feedback, feature requests, and bug reports remain part of the collaborative process. - The company frames these changes as an early step toward making Figma Community more sustainable and creatively ambitious. Figma’s recommendation is implicit: creators should continue sharing openly, but should also be able to charge for their work or receive support when they provide free resources. The new selling tools and Creator Fund aim to make that balance practical.

Read original

Figma Design Tools Front End Development Plugin Development+3

figmaMar 5, 20233 min readCurated summary

Meet the maker: Marcin Wichary | Figma Blog

Marcin Wichary’s book *Shift Happens* explores the 150-year evolution of keyboards, typing, and QWERTY as tools shaped by many people rather than a single inventor. His making process relies on rapid prototyping, experimentation, and frequent feedback, whether he is writing, designing, coding, or preparing print materials. The project demonstrates how play and iteration can make a complex, long-term creative effort manageable. ## The History and Meaning of Keyboards - The book examines how keyboards evolved from typewriters to teletypes, computers, and modern devices. - Although keyboards seem functional and unremarkable, their role has changed significantly: - They were once primarily used for producing documents. - Today, they are often used for chatting, texting, and online communication. - QWERTY’s history reflects collective technological development; its designer is effectively “everybody and no one.” ## A Prototyping-Based Creative Process - Wichary builds small versions of ideas, evaluates them, and shares them with others. - He began designing the book’s layout before finishing the manuscript. - Custom plugins automated the flow of text and images into the print layout. - He ordered a print-on-demand prototype as soon as the first manuscript was ready, before completing proofreading. - He tested difficult print scenarios, including: - Black pages - Vivid colors - Highly detailed photographs - Specific paper and page sizes - Iteration often made the project feel unfinished and chaotic, but embracing that uncertainty helped him improve the work. ## Using Experiments to Sustain Momentum - To avoid becoming overwhelmed by writing, research, and image licensing, Wichary created small experimental projects. - He: - Reverse-engineered vintage keyboards and connected them to modern computers. - Built unusual keyboards, including a piano-based typing keyboard. - Tested exceptionally good and bad keyboards. - Created mini-games and a typewriter simulator. - These projects were partly useful for research but also helped preserve his enjoyment of the subject. ## Reviving the Gorton Typeface - Wichary recreated Gorton, a distinctive technical typeface associated with 1980s keyboards and CNC machinery. - Because it had never been released as a TrueType font, he redrew it in Figma and refined it in Glyphs. - The work connected to his first Figma project, which involved type-design tools, and gave him an opportunity to use those tools as a practicing type designer. ## Figma as a Book and Collaboration Tool - He used Figma for: - Moodboards - Print layouts - Website and Kickstarter designs - Newsletter materials - Color systems - Reusable layouts through auto layout - Plugins helped manage complex layouts that had to be revised repeatedly. - Figma’s sharing features made it easy to solicit feedback from people unfamiliar with the tool. - Comments, voting, and canvas annotations supported collaboration with friends, designers, and remote 3D artists. ## Feedback as Part of Making - Wichary built a custom app to gather reactions to individual book chapters through a private URL. - Reviewers could respond using emojis or short comments. - The app made feedback more accessible and provided a refreshing break from writing. - Building a purpose-specific tool also made the feedback process enjoyable rather than purely evaluative. The project’s central lesson is to combine disciplined iteration with playful experimentation. Prototypes, small tools, and early feedback can expose problems sooner while keeping a demanding creative project engaging.

Read original

Figma Prototyping Typography Auto Layout+4

figmaMar 1, 20233 min readCurated summary

The Future of Design Systems is Automated | Figma Blog

Design systems are moving from static libraries toward automated, extensible ecosystems powered by plugins, widgets, and AI. These tools can automate repetitive work, expand Figma’s capabilities, and increasingly generate or recommend design solutions using existing system components. The article argues that automation will change designers’ responsibilities, but not eliminate the need for human judgment, creativity, and strategy. ## Plugins and Widgets as Design-System Extensions - Plugins have a long history in design and publishing software, dating back to tools such as HyperCard and QuarkXPress. - They created a broader ecosystem in which users could build and share custom effects, brushes, styles, and workflows. - In modern design systems, plugins generally serve two purposes: - Automating repetitive existing tasks. - Extending product capabilities through analytics, testing, accessibility checks, and other functionality. - Widgets add collaborative and visual tools directly to the design workspace, helping teams organize information and communicate around design systems. ## Automating Repetitive Tasks - Plugins can reduce manual work involved in maintaining and applying design-system assets. - Automation allows designers to spend less time on mechanical operations and more time on problem-solving and decision-making. - The broader trend reflects a shift from tools merely supporting designers to tools actively performing parts of the design process. ## Extending Design-System Capabilities - Plugins can provide capabilities that are not included in a core design application. - Examples include: - Gathering usage and library analytics. - Testing designs. - Improving accessibility. - Connecting design workflows to other tools and systems. - This extensibility enables teams to adapt their design environment to specialized organizational needs. ## AI-Assisted Design - Earlier experiments, such as Airbnb’s 2017 work on generating code from low-fidelity wireframes, demonstrated the potential of machine-learning-assisted design. - More recent tools such as Diagram’s Genius can analyze Figma files and suggest designs using components from an organization’s design system. - These developments suggest that AI is beginning to make earlier prototypes practical. - AI tools may eventually help generate interfaces, recommend components, complete workflows, or produce code from design input. ## Changing Roles and Responsibilities - Automation raises concerns about whether designers and developers will be replaced by software. - The article frames this as a question about how tools shape professional practice, rather than simply whether they eliminate jobs. - As routine production becomes automated, human designers may focus more on: - Defining problems. - Making judgments and trade-offs. - Establishing product direction. - Applying empathy, taste, and contextual understanding. - The future of design therefore depends on how practitioners adapt alongside increasingly capable tools. Design teams should treat plugins, widgets, and AI as ways to expand human capability rather than substitutes for design thinking. The most effective systems will combine automation for repetitive work with human oversight, creativity, and strategic judgment.

Read original

Figma AI Design Systems Machine Learning+4