Techlist.io - Korean Tech Blog Curator

figma2 min readCurated summary

This Twitter storm shows design systems are still up for debate | Figma Blog

Design systems were still an evolving, contested idea in 2017, without a universally accepted definition. The article examines a Twitter debate sparked by Airbnb’s Karri Saarinen, whose work framed design systems as essential for maintaining consistency and constraints at scale. The discussion suggests that a design system is broader than a library of UI components: it combines shared principles and patterns that shape a product’s overall design. ## An Evolving Definition - Designers offered varied interpretations of what a design system meant, reflecting the concept’s still-nebulous status. - Saarinen defined one as a “set of shared and integrated principles and patterns that define the overall design of a product.” - The debate demonstrated how the design community was actively refining the concept through public discussion. ## Why Design Systems Matter at Scale - Saarinen argued that larger, long-term projects require design systems to succeed. - Systems provide constraints and consistency across products, platforms, and teams. - Airbnb’s approach included principles such as: - Unified - Universal - Iconic - Conversational - Airbnb documented its process publicly as it developed its Design Language System. ## The Twitter Debate - Saarinen’s definition prompted a lively exchange with other design leaders, including Facebook product designer Sean Blanton. - The conversation explored what belongs within a design system and how broadly the term should be applied. - The article presents the discussion as valuable because experienced designers were clarifying the concept in real time. A practical takeaway is to treat a design system as an integrated foundation of principles, patterns, and constraints—not merely a collection of reusable visual components. Its purpose is to help teams create coherent products consistently as they grow.

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

Introducing Figma’s Live Embed Kit | Figma Blog

Figma’s Live Embed Kit lets anyone place continuously updated Figma designs and prototypes on websites or inside third-party tools. Embeds use a simple iframe and remain synchronized with the original file, eliminating repeated exports and uploads. Figma presents the kit as a way to improve team communication and signals future platform tools, including a planned API. ## Simple Embedding for Websites and Tools - Users can select **Share → Public embed** in a Figma file and copy the generated iframe code. - Developers can integrate Live Embeds into their own products using Figma’s embed documentation. - Third-party platforms such as Trello, JIRA, and Dropbox Paper can enable Figma embeds for their users. ## Always-Up-to-Date Designs - Because Figma runs on the web, embedded files stay synchronized with the source document. - Small changes—such as adjusting padding or replacing an icon—appear automatically in every embed. - Teams no longer need to re-export designs or upload updated files manually. ## Collaboration Use Cases - Internal wikis can display live designs alongside project and feature documentation. - Team messaging apps can let users share the latest design versions in conversations. - Blogs and project pages can show designs that remain current for readers. ## Broader Platform Direction - Figma aims to reduce the confusion caused by outdated files scattered across email, Slack, and file-sharing services. - The Live Embed Kit is described as an early step in expanding Figma’s platform. - Figma planned to release an API for retrieving additional information from files and incorporating it into new workflows. The kit is recommended for teams and developers that want design updates to flow automatically into the places where people communicate, document, and build products.

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

Secure (and usable) multi-AWS account IAM setup

Managing multiple AWS accounts increases billing, compliance, and operational complexity, but it provides valuable security boundaries between workloads. The post proposes a centralized IAM design in which users exist in only one account, receive minimal default permissions, and temporarily assume narrowly scoped roles in target accounts. MFA and short-lived credentials further limit the impact of compromised credentials, although the approach is constrained to roughly ten accounts by IAM group limitations. ## Why Use Multiple AWS Accounts? - Accounts isolate workloads at several levels: - **Network:** VPCs are separate unless explicitly peered. - **API access:** A compromised account cannot access others without delegated roles. - **Compute and billing:** Per-account spending limits, billing alerts, and CloudTrail monitoring can contain or reveal abuse such as cryptocurrency mining. - The main challenge is gaining these security benefits without creating unmanageable administrative overhead. - The proposed pattern is better suited to production environments than development setups where every developer may have a separate account. - Current IAM group limitations restrict the design to approximately ten accounts. ## Centralized IAM User Management - Each IAM user should exist in only one account. - Centralizing users makes onboarding, offboarding, password policies, and auditing easier. - Other accounts can be monitored for unexpected IAM user creation, which should generally never occur. - Users receive only the permissions needed to manage their own authentication settings. ## Why Use IAM Instead of SSO? - SSO would centralize authentication through an existing identity provider. - However, the post argues that SSO can limit the ability to apply MFA protection precisely to privileged operations. - Since MFA is central to the proposed privilege-escalation model, standalone IAM users are retained despite their administrative drawbacks. ## Minimal Default Permissions By default, users should be able to: - View their own IAM record. - Change their console password. - Create, update, or delete their own API credentials. - Create their own MFA device. They should have no meaningful access to other AWS APIs. This limits the blast radius of stolen usernames, passwords, or API keys: without the user’s MFA device, an attacker can generally do little more than inspect the compromised user’s record. ## Temporary Privilege Through Role Assumption - Users perform privileged work by calling `sts:AssumeRole` in the target account. - Assuming a role provides temporary credentials and a session token. - Credentials have a short lifetime, normally no more than one hour by default. - This resembles the Unix `sudo` model: users begin with restricted permissions and explicitly elevate privileges when necessary. ## MFA-Protected Privilege Escalation A role assumption should succeed only when both conditions are met: - The user has an active MFA device and can authenticate with it. - The user belongs to a group authorized to assume the requested role. MFA does not eliminate compromise risk, but it makes stolen API credentials substantially less useful and limits the damage they can cause without the corresponding MFA device. ## Privileges Grouped by Operational Topic - Administrative capabilities are divided into roles based on responsibility rather than assigning broad account-wide permissions. - Example roles include: - A **VPC role** for network configuration. - An **EC2 role** for instance management. - An **S3 role** for storage administration. - Users can then be mapped to groups and roles according to their job responsibilities, making permissions easier to understand and maintain. ## Practical Recommendation Use multiple AWS accounts as deliberate security boundaries, but centralize IAM users, keep their baseline permissions minimal, require MFA for role assumption, and grant temporary, topic-specific roles. This provides strong isolation while keeping privilege management manageable, particularly for production environments with a limited number of accounts.

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

Secure (and usable) multi-AWS account IAM setup | Datadog

The post presents a defense-in-depth approach to securing AWS accounts with IAM. Its central recommendation is to minimize long-lived credentials and broad permissions by combining strong authentication, role-based access, least privilege, and continuous auditing. Secure account governance is treated as an ongoing operational process rather than a one-time configuration. ## Protect the Root User - Use the root user only for tasks that cannot be performed through IAM. - Enable multi-factor authentication (MFA), preferably with a hardware security key. - Avoid creating root access keys. - Store root credentials securely and monitor for any root-user activity. ## Use Federated, Role-Based Access - Prefer AWS IAM Identity Center or an external identity provider for human access. - Grant users access through groups and roles instead of individual permissions. - Use short-lived role credentials rather than permanent IAM user access keys. - Require separate roles for administrative, development, production, and read-only work. ## Apply Least Privilege - Start with narrowly scoped permissions and expand them only when necessary. - Restrict actions by resource, account, region, and relevant condition keys. - Avoid wildcard permissions such as `Action: "*"` and `Resource: "*"`. - Use IAM Access Analyzer and CloudTrail activity to identify unused or excessive permissions. - Add permission boundaries or organization-level Service Control Policies when teams need guardrails around delegated administration. ## Secure Workloads and Automation - Assign IAM roles directly to EC2 instances, Lambda functions, containers, and other workloads. - Do not embed access keys in source code, configuration files, or deployment artifacts. - Store unavoidable secrets in services such as AWS Secrets Manager or Systems Manager Parameter Store. - Rotate and revoke credentials promptly when they are exposed or no longer required. ## Monitor and Audit IAM - Enable CloudTrail across accounts and regions, with logs protected from modification. - Alert on suspicious activity, including root-user use, policy changes, disabled logging, and unusual access-key behavior. - Regularly review users, groups, roles, policies, and unused credentials. - Use AWS Config, Security Hub, or equivalent controls to check compliance with account-security requirements. ## Centralize Governance - Manage multiple AWS accounts through AWS Organizations. - Keep production and sensitive workloads isolated from development accounts. - Apply Service Control Policies to prevent high-risk actions, even for administrators. - Establish a controlled emergency or “break-glass” access process with strong monitoring. The practical recommendation is to combine MFA, centralized identity, temporary role credentials, narrowly scoped permissions, and continuous auditing. No individual IAM setting is sufficient on its own; security comes from layering preventive controls with detection and response.

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

Team Library 1.0 | Figma Blog

Figma’s Team Library 1.0 turns shared components into a centralized foundation for collaborative design systems. Building on feedback from its February beta, the release improves component discovery, documentation, and organization. Figma argues that its centralized, online platform can keep teams synchronized without third-party tools or custom internal systems. ## A Centralized Source of Truth - Teams can share buttons, icons, dialogs, and other components across files and with all team members. - Published components and updates appear immediately in the Team Library. - Users receive notifications when shared components change and can choose whether to apply updates to their local instances. - Centralized storage eliminates manual exporting, syncing, and reliance on tools such as Slack, Google Docs, or custom company software. ## Improved Component Browsing - The beta required repeatedly opening a pop-up that obscured the canvas. - Team components are now available in a dedicated tab in the left sidebar, alongside layers. - Designers can drag components directly from the sidebar into their designs. - A separate local-components tab provides an overview of what will be published. - The sidebar tabs can be switched quickly with `Alt+1`. ## Built-In Component Documentation - The beta provided no place to explain how or when components should be used. - Team Library 1.0 adds documentation fields in the right-hand properties panel. - Teammates can read this guidance while browsing components, keeping usage information attached to the component itself. ## Better Categorization and Organization - The beta organized components only by file, which made larger libraries difficult to navigate. - Components can now also be grouped by frame and group. - For example, button components placed in a group named “Buttons” appear together under that category. - Shared component thumbnails can be visually customized by changing the background color of their containing frame. Figma presents Team Library 1.0 as a practical foundation for building and maintaining living design systems. Teams can adopt shared components with less friction, while documentation and categorization make those systems easier to understand and scale.

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

Introducing Live Embed of Figma designs in Trello & Jira Software | Figma Blog

Figma introduced Live Embeds for Trello and Jira Software, allowing teams to place Figma designs directly in cards and tickets. Embedded designs update automatically whenever the original Figma file changes, eliminating outdated image exports and reducing the effort designers spend sharing the latest work. The integration is positioned as a way to improve communication between designers, developers, product managers, and other stakeholders. ## Live, Automatically Updated Designs - Teams can embed Figma files in Trello cards and Jira tickets. - Changes made in Figma—such as adjusting spacing or colors—appear automatically in the embedded design. - Everyone can access the current version of a design without searching for files or replacing outdated screenshots. - The feature reduces reliance on exported PNGs that become obsolete as soon as the design changes. ## Improving Designer–Developer Collaboration - Trello and Jira are central tools for planning work, tracking deadlines, and coordinating product development. - Live Embeds help keep design information connected to the tasks where teams already work. - Atlassian described the integration as a way to streamline communication and make the latest designs easier to find. ## Expanding Figma Integrations - The Atlassian integration follows a similar Live Embed capability previously introduced for Dropbox Paper. - Figma emphasizes that its browser-based platform makes it well suited to embedding designs across different workflows. - The company planned to bring Live Embeds to more tools used by designers and their teams. ## Getting Started - **Jira Software:** Enable the Figma integration through Atlassian’s marketplace, then paste a Figma URL into a Jira ticket’s design section. - **Trello:** Enable Figma as a team Power-Up, then attach a Figma URL to a Trello card. Live Embeds are recommended for teams that want design work to remain synchronized with project-management tasks and accessible to everyone involved in shipping a product.

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

Robust statistical distances for machine learning | Datadog

The supplied text does not include the blog post itself; it is largely Datadog’s navigation menu. The only identifiable article is **“Robust Statistical Distances for Machine Learning,”** so a detailed, source-grounded summary is not possible without the article body. ## Article Focus - The post appears to address statistical distances used to compare probability distributions in machine-learning systems. - Its focus is likely making these comparisons more **robust to outliers, noisy observations, and distribution shifts**. - Such distances can support tasks including anomaly detection, model monitoring, data-drift detection, and evaluating generated data. ## Why Robustness Matters - Conventional distance measures may be disproportionately influenced by extreme values. - Outliers can make two otherwise similar datasets appear substantially different. - A robust distance should distinguish meaningful distribution changes from isolated or corrupted observations. ## Practical Implication The article’s central recommendation is presumably to choose statistical-distance methods based not only on mathematical properties, but also on their resistance to noise and outliers. Please provide the actual article text for a complete, section-by-section summary with the specific techniques and conclusions.

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

Robust statistical distances for machine learning

Statistical distances provide quantitative ways to measure how similar or different data distributions are, complementing visual tools such as histograms and Q-Q plots. The post compares the Kolmogorov-Smirnov, Earth Mover’s, and Cramér-von Mises distances, showing that each responds differently to local changes, long tails, and shifts in distribution. No single metric is universally best; the appropriate choice depends on which differences matter most. ## Visual Inspection and Q-Q Plots - Histograms offer a quick comparison of: - Minimum and maximum values - Center or average - Spread and overall shape - Q-Q plots sort both datasets and plot corresponding values against one another. - Points close to the first bisector indicate that the datasets likely come from similarly shaped distributions. - Visual methods are useful heuristics but do not provide a precise quantitative distance. ## Kolmogorov-Smirnov Distance - The KS distance compares empirical cumulative distribution functions (CDFs). - It is the largest absolute difference between the two CDFs at any point. - It is a true metric: - It is nonnegative. - It is zero only for identical distributions. - It is symmetric. - It satisfies the triangle inequality. - The distance is bounded between 0 and 1. - This makes it convenient for determining whether distributions are similar, but less useful for measuring how far apart very different distributions are. - For normal distributions with equal standard deviations and increasingly separated means, KS quickly levels off rather than growing proportionally. ## Earth Mover’s Distance - Earth Mover’s Distance (EMD), or the first Wasserstein distance, measures the minimum work required to transform one distribution into another. - “Work” is the amount of mass moved multiplied by the distance it travels. - EMD is equivalent to the area between the two empirical CDFs. - It is particularly useful for distributions with long or significant tails because distant mass contributes substantially to the result. - Unlike KS, EMD is unbounded and can grow with the physical separation between distributions. ## Cramér-von Mises Distance - The Cramér-von Mises (CM) distance sums the squared differences between empirical CDFs and takes the square root. - Its relationship to EMD resembles the relationship between L2 and L1 norms. - CM is less sensitive to isolated local changes than KS but more sensitive than EMD. - For normal distributions with separated means: - EMD grows linearly with the separation. - KS rapidly reaches a plateau. - CM grows approximately like the square root of the separation. ## Sensitivity to Distribution Changes - KS focuses on the maximum CDF difference, making it highly sensitive to local deformations. - EMD averages absolute CDF differences, so localized changes may have little effect. - CM provides a compromise, detecting local changes without reacting as strongly as KS. - In examples involving shifted or localized probability mass: - KS can increase dramatically from a small local deformation. - EMD may barely change. - CM usually shows a moderate increase. - Conversely, changes in distant high-percentile regions may have little effect on KS while producing much larger changes in EMD and CM. Choose the distance according to the type of distributional difference you need to detect: KS for maximum local deviation, EMD for overall displacement and long tails, and CM for a balanced sensitivity to both global and local changes.

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

Figma + Dropbox Paper | Figma Blog

Figma announced a live integration with Dropbox Paper that lets teams embed Figma designs and prototypes directly into collaborative documents. Embedded content updates automatically, reducing confusion over outdated files and keeping project stakeholders aligned. The integration reflects Figma’s broader goal of making design collaboration accessible across disciplines and tools. ## Live Figma Embeds in Dropbox Paper - Figma designs and prototypes can now appear as live embeds inside Dropbox Paper documents. - Updates made to the original Figma file are reflected immediately in the Paper document. - The feature helps project managers, engineers, and designers work from the same, current version of a design. - It eliminates the need to search for or repeatedly share updated design files. ## Broader Collaboration Across Teams - Dropbox Paper is positioned as a collaborative workspace for teams with Dropbox accounts. - Paper already supported integrations with services such as YouTube, GitHub, and Facebook. - Figma’s addition extends design collaboration beyond the design application itself. - The integration keeps teams in context while discussing and acting on design work. ## Simple, Lightweight Setup - Users can create an embed by copying and pasting a Figma project URL into Dropbox Paper. - The live document appears immediately without a complicated configuration process. - Figma removed unrelated application components from the embed, making it lightweight and fast. The integration is recommended for teams that use Dropbox Paper to coordinate work around designs. By embedding live Figma content rather than static exports, teams can maintain a more reliable and up-to-date source of truth.

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

Scaling support with Vagrant and Terraform | Datadog

The provided content does not include the blog post itself. It consists primarily of Datadog’s navigation menu and a promotional banner announcing its Gartner recognition, while the linked page suggests an article about scaling support with Vagrant and Terraform. ### Visible Content - Datadog announces that it was named a **Leader in the Gartner Magic Quadrant for Observability Platforms**. - The page navigation lists products across: - Infrastructure and application monitoring - Logs, security, and digital experience - CI/CD, service management, and AI - The URL references an engineering post titled **“Scaling Support With Vagrant and Terraform,”** but no article text is present. A meaningful technical summary requires the article body or a complete extract of the post.

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

Scaling support with Vagrant and Terraform

Datadog’s Solutions Team uses reproducible virtual environments to investigate customer issues across diverse operating systems, kernels, and integrations. Vagrant simplifies local VM creation, while provisioning scripts eliminate repeated installation and configuration work. Terraform extends the same approach to shared AWS environments, enabling teams to provision, preserve, and collaborate on sandboxes quickly. ## Reproducing Customer Environments with Vagrant - Containers are useful, but virtual machines are better when reproducing specific operating systems, kernels, orchestrators, or complex infrastructure. - Vagrant provides a simple workflow: - `vagrant init` - `vagrant up` - `vagrant ssh` - The main challenge is not creating a VM, but installing and configuring the technologies needed to match a customer’s environment. - With more than 200 integrations, engineers cannot be experts in every technology they may need to troubleshoot. ## Standardizing Setup with Provisioning Scripts - Vagrant provisioning supports tools such as Chef, Puppet, Ansible, and ordinary shell scripts. - Datadog stores reusable reproduction environments in a shared GitHub repository. - Each sandbox includes: - A `Vagrantfile` - A `setup.sh` provisioning script - A `data` directory for configuration files and supporting scripts - A `README.md` with usage information - Engineer-specific values, such as hostnames and tags, are kept in a local `.sandbox.conf.sh` file. - Once a sandbox exists, an engineer can run `vagrant up` and begin reproducing the customer issue within minutes. - The directory hierarchy organizes sandboxes by operating system, version or provider, and technology—for example, Ubuntu Xenial with Kafka. ## Sharing Remote Environments with Terraform - Terraform provides similar infrastructure management for remote cloud instances, including AWS EC2. - The team reuses the same `setup.sh` and `data` files for both Vagrant and Terraform, avoiding duplicate configuration work. - Each sandbox adds a `.tf` file that: - Creates an EC2 instance - Copies required data files - Executes the provisioning script remotely - A shared Terraform module handles common infrastructure tasks, while a `tf.example` file helps engineers create new configurations. - This preserves the same repository structure and workflow while extending sandboxes from local VMs to remote environments. ## Benefits for Team Collaboration - Remote sandboxes can remain available without consuming engineers’ local RAM. - Proper network security allows teammates to access and share environments. - Engineers can reproduce previously configured integrations during live customer interactions. - Investigations can continue across time zones, allowing teams to hand off urgent issues without rebuilding the environment. The overall recommendation is to treat reproduction environments as reusable infrastructure: encode installation and configuration steps once, store them in version control, and use Vagrant for local testing and Terraform for persistent, shared cloud sandboxes.

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

Improving cloud security visibility with ChatOps

Datadog built a largely serverless AWS security monitoring pipeline to detect suspicious API activity across more than 15 AWS accounts. Rather than process every CloudTrail event equally, it categorizes actions as log, notify, or alert, reducing false positives while preserving broad visibility. The system centralizes events, batches activity, and uses automated workflows to verify engineers’ actions or escalate potential compromises. ## The Security Monitoring Challenge - Datadog manages extensive AWS infrastructure across multiple accounts and nearly 200 geographically distributed engineers. - Every console or CLI operation generates an AWS API call, creating a high-volume CloudTrail data stream. - The monitoring system must detect malicious activity while also catching accidental exposure caused by configuration mistakes. - Processing every event manually would require an expensive, constantly staffed Security Operations Center. ## Prioritizing Relevant API Calls - Datadog maintains a focused list of security-relevant AWS API calls and assigns each to one of three categories: - **Log:** Lower-risk events retained for investigation, such as `CreateGroup` or `UpdateUser`. - **Notify:** Events that require the initiating engineer to confirm their identity and intent, such as `CreateUser` or `PutUserPolicy`. - **Alert:** Rare, dangerous, or clearly misconfigured actions sent directly to the security team. - A representative alert is `AuthorizeSecurityGroupIngress` with `0.0.0.0/0`, which exposes an EC2 security group to the entire Internet. - User verification reduces false positives and helps identify compromised AWS credentials. ## Cross-Account Event Pipeline - CloudTrail records API activity in each AWS account. - CloudWatch Event Rules filter for the selected API calls and publish matching events to SNS. - SNS forwards events across accounts to an SQS queue in a dedicated security AWS account. - Centralization is necessary because CloudWatch could not directly send events cross-account to SQS. - The queue also supports batching, which is important when Terraform generates many AWS changes in a short period. - A CloudWatch rule triggers a Lambda function every two minutes to drain the SQS queue and forward events to the security orchestration layer. ## Automated Decision-Making with Komand - Datadog uses Komand, a security orchestration and automation platform, to construct workflows from built-in and custom plugins. - A custom decision plugin evaluates: - The calling user - The event’s age - Request parameters and their content - Other contextual details - Based on the analysis, the workflow silently logs the event, notifies the engineer, or pages the security team through PagerDuty. ## Engineer Verification and Escalation - For notification-level events, the engineer receives an interactive Slack message containing API call details. - Confirming the action triggers a Duo push for second-factor identity verification. - If the engineer denies the action or fails to respond promptly, the workflow alerts the security team. - Komand coordinates the Slack, Duo, PagerDuty, and custom integration logic in one centralized workflow. ## Visibility and Continuous Improvement - Every workflow execution is logged and sent to Elasticsearch. - The resulting data helps Datadog visualize security events, measure detection effectiveness, identify behavioral trends, and improve alerting. - The pipeline is designed to provide actionable security intelligence without overwhelming engineers or security personnel. Datadog’s approach combines selective event filtering, cross-account centralization, batching, and automated identity verification. Organizations facing similar AWS-scale monitoring challenges can use the same principles to reduce alert fatigue while maintaining strong detection and response capabilities.

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

Improving cloud security visibility with ChatOps | Datadog

Datadog announces that it was named a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms. The provided content does not include the blog post’s body or Gartner’s evaluation details; it mainly contains Datadog’s navigation menu and product links. ## Announcement - Datadog highlights its recognition as a Leader in Gartner’s 2026 Observability Platforms Magic Quadrant. - The linked resource appears to be a Gartner-related announcement rather than a technical deep dive. ## Datadog’s Product Scope The navigation reflects a broad observability and operations platform covering: - Infrastructure monitoring, metrics, containers, Kubernetes, networks, serverless systems, and cloud costs - Application performance monitoring, profiling, dynamic instrumentation, and agent observability - Database, data-stream, jobs, and quality monitoring - Log management, sensitive-data scanning, audit trails, and observability pipelines - Security capabilities including cloud security, SIEM, workload protection, code security, and vulnerability management - Digital experience tools such as real-user monitoring, session replay, synthetic monitoring, and error tracking - Software delivery, CI visibility, testing, feature flags, and code coverage - Incident response, service catalogs, SLOs, workflow automation, and case management - AI agents, GPU monitoring, AI integrations, and investigation tools The supplied excerpt does not provide enough information to summarize Gartner’s criteria, Datadog’s strengths or weaknesses, or the report’s comparative findings.

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

Happy Emoji Release Day at Figma 🎉 | Figma Blog

Figma introduced emoji support in 2017 after users repeatedly requested it, emphasizing that emojis had become essential to modern digital communication and interface design. The main technical challenge was ensuring consistent rendering across operating systems without sacrificing visual quality. Figma chose individually cached, 64×64 full-color PNGs, providing sharper and more memory-efficient results than Slack’s single large sprite image. ## Why Emoji Support Mattered - Designers need to preview interfaces with the same visual content users will see in real products. - Emojis communicate tone, emotion, and nuance in advertising, messaging, email, and social media designs. - Some teams reportedly left Figma because the feature was missing. - Native browser rendering was unsuitable because emoji appearance varies between operating systems and platforms. ## The History of Emoji and Unicode - Emojis originated in Japan in 1999, when Shigetaka Kurita created 176 pictorial characters to supplement text. - Competing mobile carriers developed incompatible emoji sets, causing inconsistent rendering. - In 2009, the Unicode Consortium standardized emoji identifiers alongside other written characters. - Unicode defines the character code and general design guidelines, but companies remain free to create their own artwork. - As a result, the same emoji can look substantially different on Apple, Google, Facebook, Twitter, Samsung, and other platforms. ## Why Cross-Platform Rendering Was Difficult - Figma is a collaborative, cross-platform application, so Mac and Windows users need to see identical designs. - Depending on each operating system’s emoji library could make the same file appear differently to different users. - Visual inconsistencies can alter an emoji’s perceived meaning, creating communication problems. ## Figma’s Rendering Approach - Slack’s approach used a large PNG containing Apple’s emoji set and displayed relevant regions as needed. - That method was fast but limited by lower color quality and poor scalability at larger sizes. - Figma rejected the sprite-image approach because designers are especially sensitive to low-resolution visuals. - Instead, Figma used separate 64×64 full-color PNG files for each emoji. - Individual emoji files load slightly slower the first time they are used, but are cached for faster subsequent use. - This approach provides higher resolution and uses memory more efficiently than one massive image. Figma’s solution prioritized consistent, high-quality rendering over the fastest possible initial load. For design tools and other visually demanding collaborative applications, individually cached assets can be a better tradeoff than relying on platform-native rendering or low-resolution sprite sheets.

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

Figma 2.0: Now with Prototyping and Developer Handoff | Figma Blog

Figma 2.0 expands Figma from a collaborative design tool into a platform for entire product teams. Its two major additions—prototyping and developer handoff—reduce the need to export designs, synchronize files, or rely on separate tools. The release reflects Figma’s broader goal of helping teams build software together around a shared, cloud-based source of truth. ## From Designer Collaboration to Team Collaboration - Figma 1.0 focused on cloud-based design, multiplayer editing, and shared component libraries. - User feedback showed that designers also needed to collaborate with marketers, executives, and engineers. - Figma 2.0 therefore aims to empower entire teams, not just designers working together. ## Integrated Prototyping - Prototyping lets designers present work, gather feedback, secure approval, and test interfaces without leaving Figma. - Figma initially avoided building prototyping features because specialized tools already served that market. - Users wanted to design and present from the same document, maintaining one continuously updated source of truth. - The feature emphasizes slideshows and interactive hotspots rather than advanced motion graphics. - Prototypes update in real time as the underlying design changes, eliminating exporting and syncing. - Designers can: - Add or modify screens while others watch. - Connect frames through nodes in Prototype mode. - Turn objects or components into clickable hotspots. - Reuse hotspot behavior across component instances. - Order frames directly on the canvas for simple presentations. - Control presentations from a phone. - Figma describes prototypes as “living documents” rather than static artifacts, while remaining open to integrations with dedicated prototyping tools. ## Developer Handoff - Designers can share files with developers using view-only access. - Developers receive a Code mode in the properties panel. - Selecting an object reveals spacing measurements and redlines relative to nearby objects. - Developers can access CSS, iOS, and Android specifications. - Information is presented in both: - A scannable table of design attributes. - Generated markup or code. - View-only access means developers do not need paid editor seats, making collaboration more accessible. ## Building a Broader Platform - Figma positions version 2.0 as an all-in-one workflow for design, presentation, and implementation. - The company acknowledges that teams have different tools and processes. - Future plans include deeper integrations and partnerships across the wider design and development ecosystem. Figma 2.0’s practical recommendation is to keep design, prototyping, and developer collaboration in one shared cloud document whenever possible, while continuing to integrate with specialized tools for workflows Figma does not fully cover.

Read original(opens in new tab)