techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

datadog3 min readCurated summary

Secure publication of Datadog Agent integrations with TUF and in-toto | Datadog

Datadog describes how it secures the publication and distribution of Datadog Agent integrations using The Update Framework (TUF) and in-toto. TUF protects clients from tampered, outdated, or incorrectly signed packages, while in-toto provides verifiable evidence about how each integration was built. Together, the systems create a chain of trust from source and build processes to the integration installed by an Agent. ## Why Agent integrations need stronger supply-chain security - Integrations are distributed software components that run inside the Datadog Agent. - A compromise of the source repository, build infrastructure, signing credentials, or distribution system could lead to malicious code reaching customers. - Authenticating only the final package is insufficient if attackers can: - Replace repository metadata - Replay an older vulnerable release - Roll back clients to compromised versions - Exploit a stolen signing key - Publish artifacts that were not produced by the approved build process ## TUF for secure package distribution - TUF separates repository responsibilities across cryptographic roles rather than relying on one signing key. - Metadata roles such as root, targets, snapshot, and timestamp help clients verify: - Which keys are trusted - Which integrations and versions are authorized - Whether metadata is current - Whether files have been modified - TUF protects against common repository attacks, including: - Key compromise through key rotation and delegation - Rollback attacks using version information - Freeze attacks using metadata expiration - Mix-and-match attacks involving inconsistent metadata - The Datadog Agent can therefore reject integrations that fail authenticity, integrity, freshness, or version checks. ## in-toto for build provenance - in-toto complements TUF by describing and verifying the steps used to produce an integration. - Build metadata can show that required steps—such as source retrieval, dependency installation, testing, packaging, and signing—were performed by authorized parties. - Attestations connect each build step to its inputs and outputs, making unauthorized substitutions easier to detect. - This ensures that a validly signed package was not merely signed, but was produced through the expected supply-chain process. ## Combining distribution security and provenance - TUF answers whether an integration is authorized and safe to download. - in-toto answers whether it was built according to the approved process. - The combined design creates layered verification: - TUF validates repository metadata and package integrity. - in-toto validates build identity, steps, and provenance. - The Agent enforces the resulting trust decisions before installation or update. - This approach limits the impact of a compromise in any single part of the publication pipeline. Datadog’s approach illustrates that software supply-chain security requires more than package signatures. Using TUF for resilient distribution metadata and in-toto for build provenance provides a stronger, defense-in-depth model for safely delivering Agent integrations.

Read original(opens in new tab)
Software Supply Chain SecurityDatadog AgentTufIn Toto+1
figma2 min readCurated summary

5 ways to level up your prototyping workflow in Figma

Figma prototyping can be made faster and more realistic by reusing connected components, managing scrolling content centrally, and simulating natural interaction timing. The post presents five techniques that reduce repetitive setup while improving testing, presentation, and collaboration workflows. ## Master Components for Repeated Connections - Turn persistent navigation, such as tab bars or hamburger menus, into master components. - Link each item in the master component once; new instances inherit those prototype connections. - For components from a team library, place the library instance inside a new local master component. - Deep-select nested layers to create links without detaching the instance. ## Components for Scrolling Content - Convert long scrolling content into a component to preview how different device viewports initially crop it. - Set constraints for internal elements and enable **Clip content**. - Configure the desired scrolling direction through **Overflow Behavior** in prototype mode. - Place and resize component instances within designs to compare viewport-specific views while managing content centrally. ## Timed Delays and Overlays - Use the **After Delay** trigger to make transitions feel less abrupt. - Combine timed delays with overlays to simulate loading states or intermediate feedback. - For example, a form can show a submission state, brief loading sequence, and success message before navigating to a confirmation page. ## Table of Contents for Multiple Flows - Create a table-of-contents frame as the prototype’s starting screen. - Link each option to a different user flow, allowing one shared URL to present multiple design alternatives. - All flows must be located on the same Figma page. ## Observation Mode - Use Observation Mode to follow a collaborator’s view in the editor or prototype. - It supports remote user testing by showing where users are and how they interact with the design. - It is also useful for helping meeting participants follow along during presentations. These techniques make Figma prototypes easier to build, reuse, test, and present. Centralizing repeated behavior in components and using realistic timing and navigation can significantly streamline the workflow.

Read original(opens in new tab)
FigmaUser ExperiencePrototypingInteraction Design+3
figma2 min readCurated summary

Looking to improve your Figma workflow? Check out our updated user forum | Figma Blog

Figma relaunched its online forum to help designers learn from one another on subjective, workflow-specific topics that traditional support articles cannot fully address. The updated community introduces clearer channels, new programming such as AMAs and livestreams, and revised guidelines. Bug reports and feature requests are being moved to Figma’s support platform for more focused, private follow-up. ## A More Focused Community Structure - New and renamed channels organize discussions around specific areas of design practice. - The **Design Systems** channel supports conversations about libraries, best practices, and team processes. - Additional channels cover **Prototyping**, **API and Extensions**, and **Workflow and Process**. - **Open Design** lets users share work, request feedback, and find collaborators. - A **Start Here** channel explains the forum structure, guidelines, and code of conduct. ## Moving Support Issues to the Support Platform - Bug reports and feature requests will no longer be handled in the forum. - Figma’s support platform allows one-to-one troubleshooting and the sharing of files or account information that should not be posted publicly. - Support staff can tag and route issues internally. - The support team meets weekly with product and engineering teams to discuss bugs and feature priorities. Figma encourages users to use the relaunched forum to connect, exchange workflow advice, share projects, and learn collaboratively, while directing technical issues and product requests through official support channels.

Read original(opens in new tab)
FigmaDesign SystemsPrototypingAPI+1
figma2 min readCurated summary

Getting to the bottom of line height in Figma | Figma Blog

Figma explains why it is changing text layout so that extra line height is distributed above and below letters and measured more modernly. The decision grew out of a historical review of typography, from metal type to digital fonts, where old physical constraints and platform inconsistencies shaped today’s behavior. The update is optional, and existing files remain unchanged unless users choose to update them. ## Figma’s New Approach - Figma will distribute extra line height above and below text rather than handling it through older conventions. - Line height will be measured in a more modern way. - The change is optional: - Existing files will not change automatically. - Users can update older text at their own pace. - Figma developed the approach through research and testing because its users employ text in many different contexts. ## The Early Centuries of Typesetting - Metal type separated typography into two roles: - Type designers created letterforms. - Typesetters arranged physical blocks into readable pages. - Font size referred to the height of the metal block, not necessarily the visible letters. - Two fonts with the same nominal size could have different letter heights and baseline positions. - Typesetters could place lines directly together, a practice called setting type solid. - To improve readability, they inserted thin strips of lead between lines. - This spacing was called “leading,” pronounced “ledding.” - For example, 16-point type with 4 points of leading produced a 20-point line height. - Choosing the right amount of leading depended on the font, font size, and line length. - The physical system imposed constraints: - Leading could be added but not removed. - Fonts generally arrived as fixed, unchangeable blocks. - Baselines and internal font proportions varied between typefaces. ## Digital Typography Introduces New Problems - Computers replaced physical type blocks with collections of numerical data stored in font files. - Fonts had to support different platforms and formats, including Windows, Macintosh, and OS/2. - Rendering differences, bugs, and platform-specific behavior made typography less consistent. - Digital typography also created new freedoms: - Text could extend beyond traditional font boxes. - Elements could overlap. - Typesetters could add, reduce, or completely remove leading. - Unlike metal type, digital fonts could define arbitrary default line heights, often making them taller than the nominal font size for improved readability. Figma’s changes attempt to preserve useful typographic principles while adapting them to the flexibility—and historical complications—of digital text layout.

Read original(opens in new tab)
FigmaCSSTypographyWeb Design+2
figma2 min readCurated summary

GitHub takes its collaborative culture to a new level | Figma Blog

GitHub adopted Figma to make its design system more collaborative, scalable, and accessible—especially for its distributed workforce. What began as a grassroots effort to standardize design evolved into a dedicated seven-person team and a largely Figma-based workflow. Figma’s browser-based collaboration and API helped GitHub remove tooling barriers, streamline contributions, and bring designers and engineers closer together. ## Building a Dedicated Design Systems Team - In 2015, GitHub lacked staff dedicated full-time to its design system. - Designers repeatedly recreated components, worked with outdated patterns, and lacked consistent documentation. - A grassroots initiative began improving the process and documented workflow. - Within six months, GitHub formed a permanent design systems team. - By 2019, seven of the company’s 25 product designers focused on reusable, interchangeable components. ## Removing Friction from the Design Workflow - Maintaining the design system initially required specialized software and knowledge of complex tools. - Contributors found it difficult to update shared assets such as GitHub’s Octicons SVG icon library. - GitHub tested Figma because it eliminated the need to install desktop software. - Combining Figma with its API enabled an automated, platform-independent contribution workflow. - The design systems team subsequently migrated UI components into Figma, making most design and development resources available in one place. ## Turning Figma into a Remote Collaboration Hub - Figma’s web-based workspace helped GitHub’s remote employees collaborate despite being in different locations. - Designers could work simultaneously in the same file, effectively replacing the physical whiteboard. - Shared design sessions and “design jams” helped ideas gain momentum and encouraged experimentation. - Prototyping became easier because designers could create and adjust flows without switching tools. - GitHub viewed Figma as a natural fit because both products emphasize collaboration between designers and engineers. ## Faster Feedback and More Connected Teams - Figma lowered the barrier for people outside design to participate in the feedback process. - Real-time collaboration helped distributed teams communicate more directly. - By consolidating components, prototypes, and design discussions, GitHub could support more efficient and consistent delivery. GitHub’s experience suggests that a design system works best when its tools make contribution as easy as consumption. For distributed organizations, a browser-based, collaborative platform such as Figma can turn design-system maintenance into a shared engineering and product activity rather than a specialized, isolated process.

Read original(opens in new tab)
FigmaDesign SystemsPrototypingGithub+3
figma2 min readCurated summary

Reintroducing DesignSystems.com | Figma Blog

Figma relaunched DesignSystems.com as a dedicated resource for people building and maintaining design systems. The site’s new direction is shaped by community feedback and focuses on practical guidance, content for practitioners at every experience level, and a range of perspectives. Figma plans to expand the site regularly through new articles, resources, and community contributions. ## A Community-Informed Relaunch - The redesigned site follows the original launch in May and incorporates feedback from: - Designers - Developers - Content strategists - Design operations managers - Contributors and users represented both large organizations and small, individual teams. ## Three Areas of Focus - **Actionable content** - Articles and resources are intended to provide clear takeaways. - Guidance should be applicable to real design-system work. - **Content for all practitioners and teams** - The site will support beginners as well as experienced design-system professionals. - It will include introductory guides and stories from established teams at companies such as Lyft, Asana, and Harry’s. - **Multiple viewpoints** - Design-system challenges can be approached in different ways. - The site aims to present varied perspectives on similar problems so practitioners can learn from one another. ## Ongoing Community Contributions - Figma describes the relaunch as a starting point rather than a finished product. - Readers are encouraged to: - Share feedback - Submit ideas - Contribute articles or resources - Sign up for site updates The practical recommendation is to use DesignSystems.com as an evolving source of implementation advice and community perspectives, while contributing feedback and experience to help shape its future content.

Read original(opens in new tab)
FigmaDesign SystemsComponent LibraryDesign Ops+1
figma2 min readCurated summary

We refreshed Figma's UI: An inside look at our process | Figma Blog

Figma’s 2019 UI refresh aimed to modernize the product without disrupting users. Rather than redesigning its structure, the team focused on visual inconsistencies in typography, layout, color, and iconography, using extensive research and internal discussion to guide decisions. The process began by cataloging problems, then organizing them into broader themes. ## Why Figma Needed a Refresh - The interface had evolved piecemeal as the product expanded. - Teams created custom components when existing patterns no longer fit, producing inconsistent: - Tables, buttons, and input controls - Shades of gray, red, and blue - Visual and interaction patterns - The original UI foundation predated major features such as Multiplayer and Components. - Both users and employees increasingly noticed the inconsistencies. ## Step One: Brainstorming the Problems - Figma held a two-hour session with the entire design team. - Designers explored the product firsthand, documenting quirks, shortcomings, and successful patterns with notes and screenshots. - Findings were collected in a shared Figma file and text document. - Strong group reactions—such as an “oh shit, that’s bad” response—helped identify issues likely to have broad impact. - The team deliberately paused for several days afterward, allowing opinions to settle and new insights to emerge. ## Step Two: Organizing and Synthesizing Findings - The team revisited the brainstorm after the reflection period and debated which problems mattered most. - Designers converted detailed observations into broader post-it themes. For example: - Several notification inconsistencies became “We need a system for how we handle notifications.” - Notes were grouped by similarity, such as: - Color - Legibility - White space - Notifications - This clustering reduced noise and revealed larger systemic issues, including typography, icons, dialogs, toolbars, sharing, layers, components, and file browsing. - Figma found that grouping was useful but overly complex classification was not. - The team abandoned an additional “visual to foundational” axis because it made the framework harder to use. ## Lessons from the Process - A visual refresh often becomes necessary gradually rather than because of one decisive moment. - Broad, understandable categories are more useful than abstract or overly narrow ones. - Time between brainstorming and synthesis helps teams reassess initial reactions. - The refresh prioritized surface-level improvements so users could benefit from a more coherent interface without learning an entirely new product.

Read original(opens in new tab)
FigmaDesign SystemsUser ExperienceUser Interface+2
figma2 min readCurated summary

#FigmaTip Roundup: Spring cleaning edition | Figma Blog

The post presents a set of Figma organization tips framed as “spring cleaning” for design files and systems. It focuses on reducing clutter, improving file discoverability, and making shared libraries easier for teams to navigate. The central recommendation is to use Figma’s built-in naming, sorting, thumbnail, and organizational features regularly. ## Batch Rename Layers - Select multiple layers, right-click, and choose **Rename**, or use `Command + R`. - Rename layers uniformly, add numerical suffixes or prefixes, or replace parts of existing names. - Regular expressions provide more advanced naming control. - This is especially useful for cleaning up large projects with duplicated or inconsistently named layers. ## Create Custom File Thumbnails - Add a new page at the top of the page list and create a single **640×320** frame. - Use the frame to display a title, description, images, project status, or version information. - Match the frame and canvas background colors for a clean thumbnail. - Custom thumbnails make files easier to scan and identify in the file browser. ## Sort and Review Files - Use the file browser’s sorting options to find clutter. - Sort by **File Name** to locate unnecessary files, including those still named “Untitled.” - Sort by **Date Created** or **Last Modified** to identify outdated or inactive work. ## Clean Up Team Libraries - Review components for redundancy, outdated elements, or items that no longer serve the team. - Remove components by opening the Components tab, right-clicking an item, and selecting **Remove from Library**. - Components can also be hidden from the library by adding a period (`.`) or underscore (`_`) to the beginning of their names. ## Organize Components with Frames and Pages - Use frames and pages to group components and design-system elements into meaningful collections. - This reduces reliance on long names separated by forward slashes. - A clearer structure makes shared libraries easier for teammates to browse and maintain. Regularly applying these techniques can keep Figma files, layers, and libraries manageable as projects grow, improving both individual workflows and team collaboration.

Read original(opens in new tab)
FigmaDesign SystemsComponent LibrariesRegular Expressions+1
datadog3 min readCurated summary

Building highly reliable data pipelines at Datadog

Datadog’s approach to reliable data pipelines focuses on delivering correct data on time, even when individual jobs fail. Reliability therefore requires fault tolerance, monitoring, and fast recovery rather than eliminating every failure. The company achieves this through isolated, short-lived clusters and pipelines designed to limit the impact of failures. ## Reliability Means Timely, Correct Results - A reliable pipeline is one that consistently produces correct outputs within the required time window. - Occasional crashes do not necessarily make a pipeline unreliable if automatic recovery still delivers the data on schedule. - Pipelines should be designed with the expectation that failures will eventually occur. - Monitoring must detect unexpected failures early, while operational processes should support rapid recovery. ## Architecture for Batch Pipelines - Datadog streams and analyzes live data in real time but uses batch pipelines for features such as optimized long-term storage. - Historical data is stored in object storage. - Cloud Hadoop/Spark services launch and configure processing clusters. - Luigi workers manage tasks and workflows, while Spark workers compile code and submit jobs. - Jobs can be launched through a web interface, command line, or scheduler. ## One Cluster per Pipeline Instead of placing all workloads on one large Hadoop cluster, Datadog gives each pipeline its own cluster. - **Isolation:** Jobs do not compete for resources or interfere with one another, simplifying monitoring and diagnosis. - **Workload-specific hardware:** Clusters can use CPU-optimized or memory-optimized instances depending on the job. - **Elastic scaling:** Clusters can be expanded to catch up with delays or handle growing data volumes without waiting for a shared cluster. - **Safer upgrades:** Hadoop and Spark versions can be upgraded gradually across separate clusters. - Clusters are typically short-lived, averaging about three hours, although dozens may run simultaneously. ## Using Spot Instances to Encourage Fault Tolerance - AWS spot instances can reduce infrastructure costs by as much as 80%, but their nodes may be terminated whenever capacity or demand changes. - Rather than avoiding this failure mode, Datadog designs pipelines to tolerate disappearing clusters. - Long-running jobs are risky because failures discard more work and make recovery slower. - Pipelines are split into smaller jobs: - **Vertically:** Separate transformations into multiple stages, persisting intermediate results in S3. - **Horizontally:** Partition input data so multiple jobs process different portions concurrently. ## Breaking Up the Rollup Pipeline - Datadog’s rollup pipeline generates aggregated time-series data for historical metrics queries. - A single job would take more than 14 hours, making failures costly and difficult to recover from. - The pipeline is divided into two stages: - Aggregate high-resolution data and checkpoint it to S3 as Parquet files. - Convert the intermediate data into a custom format optimized for queries. - As these jobs grew, they were partitioned further using Kafka’s partitioning scheme. - Kafka partitions are grouped into shards, allowing Datadog to: - Adjust how much data each job processes. - Run more or fewer jobs as needed. - Isolate unusually large or sensitive shards. - This decomposition adds overhead because launching jobs and checkpointing to S3 take extra time, but it substantially limits the work lost during failures. ## Practical Recommendation Design pipelines around failure rather than assuming uninterrupted execution. Use isolated, scalable clusters, short jobs, intermediate checkpoints, and partitioned processing so that failures affect only a small portion of the workload and recovery remains fast.

Read original(opens in new tab)
Database DesignPostgreSQLAWSMonitoring+4
datadog1 min readCurated summary

Building highly reliable data pipelines at Datadog | Datadog

The provided text does not include the blog post’s actual article content. It contains Datadog’s navigation menu and a link titled “Highly Reliable Data Pipelines,” so the post’s argument, architecture, and technical conclusions cannot be summarized reliably. ## Available Information - The page appears to be a Datadog engineering blog post about building highly reliable data pipelines. - The surrounding content is primarily Datadog product navigation. - It also promotes Datadog’s recognition as a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms. Please provide the article body or a complete page extract for a detailed technical summary.

Read original(opens in new tab)
KubernetesDatadogObservabilityApplication Performance Monitoring+3
figma3 min readCurated summary

Pairing is the key to evangelizing your design system | Figma Blog

A successful design system depends on relationships and culture, not just tools, documentation, or component libraries. Robin Rendle argues that pairing directly with designers is the most effective way to build trust, discover system problems, and encourage adoption. Working together turns the system team from a source of criticism into a practical partner that helps teams move faster. ## Treat the Design System as a Cultural Project - Early efforts focused on creating a UI kit and component library, assuming better tools would solve inconsistency. - The author learned that design systems reflect relationships between designers, engineers, product managers, and customers. - Gusto complemented its technical work with: - A Slack channel for questions and feedback - Design system office hours - An introductory UI kit for new employees - These initiatives helped, but pairing proved more effective because it involved working directly with people. ## Pairing Is User Research - Side-by-side collaboration reveals: - Which components and patterns are confusing - Where documentation is incomplete - What feels awkward or works well - Which user needs the design system is failing to address - Pairing replaces assumptions with direct observation of how people actually use the system. - Sessions also help the team evaluate whether: - Designers and engineers know the component library exists - They understand current HTML, CSS, and accessibility practices - Components are being explained in terms of organizational benefits - Useful designs should become official reusable patterns - Unlike office hours, pairing reaches people before they necessarily recognize that they need help. ## Pairing Turns Critique into Collaboration - Design system guidance should feel like accelerating someone’s work, not restricting creativity. - New systems are often complex, poorly documented, and full of hidden constraints: - Limited color choices - Existing components that designers may not know about - Accessibility requirements - Technical limitations embedded in the codebase - Simply imposing these rules can make the design system team seem controlling, causing people to ignore documentation or work around the system. - Pairing creates a more productive conversation where the design system team shares institutional knowledge while learning what product teams need. - Both sides benefit: product teams work faster and learn reusable patterns, while the system team gains insight into real-world requirements. ## Pairing Builds Design System Advocates - Designers and engineers who receive direct, helpful guidance are more likely to understand and support the system. - Personal collaboration builds trust and makes adoption feel like an advantage rather than an obligation. - Each pairing session can turn participants into advocates who carry the system’s practices and rationale back to their teams. Design system teams should prioritize pairing as an ongoing form of user research, education, and relationship-building. The strongest systems are not merely documented and enforced; they are developed collaboratively with the people expected to use them.

Read original(opens in new tab)
FigmaDesign SystemsAccessibilityCSS+4
figma1 min readCurated summary

Figma Time Travel | Figma Blog

Figma Time Travel is a playful April 2019 feature that lets users revisit historical design styles through version history. With one click, users can choose from four themed “palette years,” transforming their designs into retro-inspired visual eras. The feature is presented as an Easter egg rather than a major productivity tool, giving designers a lighthearted way to explore Figma’s capabilities. ## Accessing Historical Design Styles - Time Travel is available through Figma’s version history. - Users can select from four new options representing distinct historical palette years. - Each option applies a different retro visual treatment to the design. - The feature is designed for one-click experimentation. ## A Playful Easter Egg - Figma describes the feature through humorous references to older workplace environments and technology. - The “1973 vintage” option evokes grey cubicles and mechanical keyboards. - The launch was intended to celebrate April with fun rather than an April Fool’s prank. - It reflects Figma’s interest in incorporating unexpected, entertaining details into its design tools. Designers can find Time Travel in version history and use it as a creative experiment or nostalgic Easter egg rather than as a serious archival workflow.

Read original(opens in new tab)
FigmaDesign CollaborationDesign ToolsVersion History
figma2 min readCurated summary

Updates to the Figma desktop app experience | Figma Blog

Figma’s March 2019 desktop app update focused on making the native experience more convenient and design-friendly. Users could make Figma links open directly in the desktop app, choose an sRGB color profile on macOS, and benefit from a more streamlined Windows interface. Together, these changes reduced workflow friction and created more usable canvas space. ## Opening Figma Links in the Desktop App - Figma URLs previously opened automatically in browsers such as Chrome, Firefox, or Safari. - Users can now update the desktop app, click a Figma link, and select **“always open in the app.”** - This setting can be changed under a file’s preferences by disabling **“open links in desktop app.”** - Individual links can still be opened manually through the file menu when the browser remains the default. ## Color-Space Management on macOS - The Mac desktop app now allows users to choose between: - An unmanaged color profile based on the computer’s display settings - The sRGB color space - The sRGB option helps designers accurately evaluate web designs against the color appearance expected in browsers. - Windows support for color-space management was planned for a future release. ## Streamlined Windows Interface - Figma consolidated menu options and removed unnecessary interface elements. - The redesigned UI provides more room on the canvas for actual design work. - The update was intended to improve usability without changing the core desktop workflow. Figma recommended updating or downloading the latest desktop app to take advantage of these improvements, particularly for users who rely on desktop-based workflows or need more reliable color accuracy.

Read original(opens in new tab)
FigmaDesktop AppMacosElectron+3
figma2 min readCurated summary

Dribbble Scores with Live Design Collaboration for its Remote Team | Figma Blog

Dribbble adopted Figma to make collaboration feel more like working together in the same room despite its fully remote, globally distributed team. Figma replaced a fragmented collection of tools with a shared, real-time workspace and a single source of truth for designs. The result was faster iteration, clearer feedback, and less time spent managing files and communication. ## Remote Collaboration Challenges - Dribbble’s design team included seven product designers and developers working across multiple time zones. - Remote work helped attract talent and offered flexibility, but made spontaneous collaboration more difficult. - The team relied on video conferencing and several disconnected tools, without a seamless way to work together. - Designers lacked visibility into one another’s work, while file management and multiple feedback channels reduced time available for design. ## Figma as a Shared Design Workspace - Figma allowed multiple people to work in the same file simultaneously, recreating the experience of brainstorming in a room or on a whiteboard. - Online files were easier to find and access, eliminating the need to ask colleagues for the latest version. - Designers could stay within one tool instead of repeatedly switching between applications. - Figma’s handling of vectors, images, and copy-paste attributes also appealed to Dribbble’s designers. - The team eased adoption by importing existing design files and recreating familiar interface components in Figma. ## Faster Pairing and Feedback - Figma supported Dribbble’s practice of using design pairs to solve problems and deliver products quickly. - A single, current file reduced communication friction and kept designers aligned on the latest changes. - Multiplayer editing made it easier to hold frequent critiques, duplicate frames, explore alternatives, and comment in real time. - The team could solve design problems in minutes rather than days; in one example, five people collaboratively produced an approved profile design in about 20 minutes. ## Integration with Dribbble - Dribbble used Figma’s API to build an integration for publishing work directly to Dribbble. - Users can select a layer in Figma and choose **Integrations → Dribbble** to begin the Dribbble desktop upload flow. For fully remote design teams, a shared real-time workspace can replace fragmented collaboration processes. Dribbble’s experience suggests that adopting a single source of truth helps teams communicate more clearly, iterate faster, and spend more time designing.

Read original(opens in new tab)
FigmaDesign SystemsReal Time CollaborationRemote Collaboration+3
figma2 min readCurated summary

The power of Figma Drafts | Figma Blog

Figma Drafts provide a private space for experimentation before designs are ready for team-wide visibility. Josh Dunsterville argues that separating rough exploration from polished project files reduces fear of judgment and encourages faster, more creative iteration. The central principle is simple: create first, organize and share later. ## Why Drafts Matter - Traditional design workflows often encourage sharing only polished, “presentable” work. - This can lead designers to prioritize tidy files, perfect pixels, grids, and layer names over exploring solutions. - Drafts act as a private personal folder, independent of broader team or project permissions. - Individual draft files can be shared when appropriate, but drafts cannot be opened globally to an entire team. - The concept resembles a physical notebook: informal, incomplete, and free from pressure to look finished. - This environment can also help overcome designer’s block by removing the need to plan every detail before starting. ## Using Drafts for Exploration - Drafts can hold anything from quick app concepts to experiments with Figma features. - Untitled files, rough shapes, default colors, and messy layouts are acceptable. - The key workflow is: **create first, organize second**. - Designers should use drafts to quickly capture and test ideas without worrying about presentation quality. ## Moving Ideas into Projects - When a draft is ready for further development or team collaboration, it can be moved into a project. - Files can be transferred by: - Dragging them into the desired project. - Selecting the “Drafts” location inside the file and choosing a project. - If an idea may be useful later, duplicate the draft before moving it so the original remains as a snapshot. - Drafts can remain the messy source of truth, while project files are cleaned up for broader use. - File-browser filters such as file name, creation date, and last-modified date help manage drafts as they accumulate. Drafts are most valuable when treated as a low-pressure digital notebook rather than a staging area for finished work. Keep early thinking private and messy, then promote only the ideas that merit organization and collaboration.

Read original(opens in new tab)
FigmaDesign SystemsPrototypingCollaborative Design+2