techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

figma3 min readCurated summary

The Atlassian Method: The Power of Developer Joy | Figma Blog

Atlassian treats “developer joy” as more than a smoother developer experience: it is a company-wide philosophy centered on reducing friction and protecting the craft of development. After poor productivity and satisfaction in 2022, Atlassian standardized tools, improved processes, and empowered engineering teams to address frustrations directly. The effort produced major gains, including higher satisfaction, faster pull-request cycles, more frequent deployments, and improved roadmap delivery. ## Developer Joy as a Company Priority - Developer experience typically covers workflows, tools, and processes; developer joy focuses more deeply on the values, standards, and craft of development. - Atlassian found that developers lose more than eight hours per week—about 20% of their time—to inefficiencies. - Common sources of friction include: - Searching for information and solutions - Poor tooling and redundant systems - Cross-functional coordination with design and other teams - Planning and process overhead - In 2022, Atlassian frequently missed public roadmap commitments, while developer satisfaction fell below 50%. ## Operationalizing Joy - Atlassian created a cross-functional “champions” program to identify and eliminate organizational frustrations. - The initiative focused on: - **Systems:** Auditing tools and processes, standardizing where possible, and removing redundant tools—the company’s “Noah’s Ark of tooling.” - **Culture:** Establishing coding standards, shared values, and metrics that emphasized quality and craft, not just efficiency. - Every engineering team allocated 10% of its time to developer productivity improvements. - This gave developers an “ownership stake” in solving the problems affecting their work. - Developer joy became a company-wide OKR reported by teams every month. ## Measuring the Business Value - Atlassian accepted short-term tradeoffs, prioritizing engagement and productivity improvements over immediate revenue optimization. - The company measured both quantitative and qualitative outcomes. - Within a few months, it achieved: - A 50% increase in developer satisfaction - A 50% reduction in median pull-request cycle time - A threefold increase in deployment frequency - Delivery of all customer roadmap commitments instead of repeated delays - An increase in internal CSAT from below 50% to 80% - The results reinforced the idea that investments in tools, processes, and clear measurement compound over time. ## Toward Team Joy - The success of developer joy helped Atlassian build broader support for applying the same principles beyond individual developers. - The initiative began moving toward the larger concept of “team joy,” extending the focus to collaboration and the shared experience of delivering work. Organizations seeking similar results should treat developer productivity as an ongoing company responsibility: give teams dedicated time to improve their systems, reduce unnecessary complexity, and measure satisfaction alongside delivery performance.

Read original(opens in new tab)
Software DevelopmentDevOpsDeveloper ExperienceAgile+3
figma3 min readCurated summary

How We Migrated onto K8s in Less Than 12 months | Figma Blog

Figma migrated most of its core services from AWS ECS to Kubernetes in under 12 months because ECS was increasingly limiting its platform ambitions. Kubernetes offered better support for stateful workloads, Helm-based software, autoscaling, service networking, and the broader CNCF ecosystem. The migration was considered worthwhile because Figma had relatively few core services and had already containerized its workloads, making the transition more manageable. ## Figma’s Existing Compute Platform - By early 2023, Figma was already running all services in containers on Amazon ECS. - ECS had enabled rapid adoption of containerized workloads, but Figma’s growing infrastructure team began evaluating a more capable long-term platform. - Figma is not organized around thousands of microservices: - A small set of powerful core services provides modularization and traffic isolation. - New product capabilities are usually added to existing services rather than creating new ones. - This limited service count made a Kubernetes migration more practical. ## Limitations of ECS - ECS lacked Kubernetes primitives needed for complex workloads. - Running `etcd` on ECS required fragile custom startup code to manage cluster membership because ECS does not provide StatefulSets or persistent pod identity. - Kubernetes StatefulSets provide stable identities and stateful networking for systems such as `etcd`. - ECS did not natively support deploying groups of services packaged as Helm charts. - Open-source tools such as Temporal would require manual conversion into Terraform configurations. - This increased installation and maintenance effort. - ECS also made routine infrastructure operations more cumbersome. - For example, safely removing a malfunctioning EC2 instance was difficult. - EKS can cordon a node and move its pods elsewhere while respecting graceful shutdown behavior. ## Access to the CNCF Ecosystem - Kubernetes would give Figma access to a larger ecosystem of open-source cloud-native tools. - Autoscaling was a major motivation: - Figma was provisioning services for peak demand, wasting resources during lower-traffic periods. - Kubernetes tooling such as KEDA supports scaling based on CPU, SQS queue length, and custom Datadog metrics. - Figma expected to adopt a service mesh eventually. - Existing AWS load balancer routing created operational drawbacks: - Network Load Balancers could take several minutes to register or remove targets. - This slowed emergency deployments and increased incident remediation time. - Envoy offered more customization than AWS load balancers, including custom filters for shedding load during incidents. - Figma had already deployed standalone Envoy machines for a major service and saw Kubernetes ecosystems such as Istio as a path toward fleet-wide service-mesh adoption. Figma’s experience suggests that Kubernetes was justified not simply as a replacement for ECS, but as a foundation for more capable operations and broader platform tooling. Organizations considering a similar move should first assess their workload complexity, existing container maturity, and whether Kubernetes capabilities will materially reduce infrastructure work.

Read original(opens in new tab)
KubernetesDocker & ContainersTerraformHelm+4
figma2 min readCurated summary

The Long and Short of It: Issue no.6 | Figma Blog

Figma’s sixth issue of *The Prompt* examines how AI is changing design, engineering, product development, and human curiosity. Its central argument is that adopting AI requires more than learning new tools: it requires understanding which human skills—judgment, creativity, problem selection, and curiosity—remain essential. The issue presents AI as a collaborator that can expand creative and technical work without replacing the craft behind it. ## AI and the Future of Design - Figma’s design leaders ask what “good design” means as AI makes product development more accessible. - As execution becomes easier to automate, design judgment and strong craft principles become more important differentiators. - The focus is on building practical, thoughtful products with AI rather than pursuing novelty for its own sake. ## What Engineers Contribute Beyond Code - Figma CTO Kris Rasmussen argues that engineering is not merely the production of code. - Engineers provide value by identifying which problems matter and determining effective ways to solve them. - AI may commoditize portions of coding, but it also creates space for engineers to focus on architecture, judgment, problem framing, and higher-level innovation. ## Curiosity and Judgment-Free Questions - Perplexity CEO Aravind Srinivas describes AI-powered search as a continuation of encyclopedias and wikis. - The goal is to give people a source of answers without the social pressure or embarrassment that can inhibit curiosity. - AI can act as a “copilot” for exploration, though improving the reliability and usefulness of its answers remains an ongoing challenge. ## Humanoid Robots and Embodied AI - The issue considers whether humanoid robots are finally moving from science fiction into everyday reality. - Androids reflect humanity’s longstanding fascination with reproducing intelligence and ourselves in technological form. - Conversations with robotics builders explore both the promise and the risks of giving AI a physical body. ## The Role of Print and Material Experience - *The Prompt* is also an 80-page print magazine produced with Figma’s Brand Studio and designer Chloe Scheffe. - Vellum paper, illustration, color, layout, and physical materiality interpret the issue’s themes. - The print edition emphasizes experiences that digital tools and AI cannot fully reproduce, reinforcing the value of tangible, intentional creative work. AI’s greatest potential lies in extending human abilities rather than eliminating them. Designers and engineers should use it to increase experimentation and efficiency while preserving the judgment, creativity, and curiosity that give their work meaning.

Read original(opens in new tab)
AIGenerative AIProduct DesignSoftware Engineering+2
figma2 min readCurated summary

HP Powers Up Design Handoff with Dev Mode | Figma Blog

HP built its Veneer design system to unify digital experiences across more than 100 product lines and many independent business units. By combining design language, reusable components, documentation, governance, and community feedback, HP reduced duplication and improved consistency. Figma’s Dev Mode further streamlined handoff, helping developers interpret designs faster and cutting development time by up to 50% on some projects. ## Building a multilayered design system - HP’s diverse products—including printers, laptops, and gaming systems—each have distinct brand and product requirements. - Teams previously worked in isolation, making it difficult to maintain a consistent digital experience. - Veneer evolved from a frontend component library into a broader system containing: - Design language and tokens - Shared components and patterns - Usage guidelines, code standards, and snippets - Governance and community collaboration - Its multilayered structure supports HP’s numerous sub-brands rather than forcing every product into one rigid system. ## Measuring adoption and impact - HP tracks both usage data and feedback from designers and developers. - Veneer’s iconography library includes 915 components used by 320 teams. - The library averages approximately 85,000 component inserts per week. - HP reported that Veneer saved projects 500% more time than the time invested in creating the system during 2023. - Some projects experienced a 50% reduction in development time. - Adoption remained challenging because designers were protective of their product-specific work and teams needed flexibility for different sub-brands. ## Dev Mode improves design handoff - Dev Mode gives developers direct access to design specifications in Figma, reducing meetings and repeated clarification between design and engineering. - **Compare changes** helps teams identify differences between design versions, especially when updating existing products. - **Ready for development** lets designers indicate which parts of a design are prepared for implementation, helping developers focus on the correct work. - **Variables** connect designs to primitive and semantic tokens, allowing HP’s system to scale across themes and modes. HP’s experience suggests that a successful enterprise design system must be flexible, measurable, and supported by strong collaboration. Pairing such a system with Dev Mode can make handoff clearer, reduce redundant work, and give both designers and developers more time to focus on higher-value work.

Read original(opens in new tab)
FigmaDesign SystemsDesign TokensDev Mode+2
microsoft3 min readCurated summary

Managed DevOps Pools – The Origin Story

Microsoft’s vast, diverse engineering organization had accumulated more than 5,000 self-hosted Azure DevOps pools, creating duplicated tooling, inconsistent reliability, security gaps, and compliance challenges. Its One Engineering System (1ES) team addressed this with 1ES Hosted Pools, a standardized service for flexible, secure, and scalable CI/CD infrastructure. Adoption reduced costs by more than 60%, cut remaining self-hosted pools to a few dozen, and eventually led to the external Managed DevOps Pools offering. ## The Scale and Challenges of Self-Hosted Infrastructure - Microsoft supports over 100,000 engineers across many businesses, programming languages, operating systems, hardware platforms, build engines, and test frameworks. - By 2021, teams had created: - More than 5,000 self-hosted Azure DevOps pools - Hundreds of thousands of agents - Teams needed capabilities unavailable from Microsoft-hosted agents, including: - Larger compute sizes - Private-network connectivity - Custom images - Stateful agents - Long-running tests - The decentralized approach caused: - Duplicate engineering effort - Uneven support and reliability - Poor resource utilization and higher costs - Inconsistent patching and security practices - Difficult and time-consuming compliance audits ## 1ES Hosted Pools - 1ES developed a standardized internal service for custom Azure DevOps infrastructure. - Teams could connect agents to private resources such as package registries, secret managers, and on-premises services. - They could bring custom images, using centrally maintained images as their base. - Business continuity features allowed backup pools and failover to other Azure regions. - Agents were stateless by default, but teams could reuse stateful agents for better performance through local caches. - Stateful agents were automatically recycled based on age or available disk space. - Teams could select Azure VM families and sizes suited to their workload. - Standby agents could be pre-warmed on schedules or automatically provisioned using historical demand. ## Operational and Business Benefits - **Lower costs:** Infrastructure bills fell by more than 60% through improved utilization, better SKU selection, and selective use of Azure Spot VMs. - **Faster development:** Teams spent less time maintaining CI/CD infrastructure and more time building products. - **Simpler compliance:** Standardized telemetry made audits easier and allowed security and compliance improvements to be deployed centrally. - **Greater mobility:** Developers changing teams no longer had to learn different infrastructure-management systems. - **Improved security:** Features such as Azure Confidential VMs, Trusted Launch, and Secure TPM became available across pools. - **Reduced fragmentation:** By 2024, Microsoft had reduced its remaining self-hosted pools from more than 5,000 to only a few dozen. ## From Internal Platform to Managed DevOps Pools - 1ES first built Hosted Pools as an internal “Host On Behalf Of” service to validate whether centralized management could reduce self-hosting. - Success inside Microsoft, combined with customer demand, led to the external **Managed DevOps Pools (MDP)** service. - Organizations using VM Scale Set agents or self-hosted agents can migrate to MDP to gain standardized scaling, security, compliance, and operational support. - The external offering initially does not include every feature available in 1ES Hosted Pools, though additional capabilities may be added later. Centralizing CI/CD infrastructure can eliminate redundant platform work while improving cost efficiency, security, compliance, and developer productivity. Managed DevOps Pools extends Microsoft’s internal solution to organizations facing similar self-hosting challenges.

Read original(opens in new tab)
CI/CDDevOpsCloud InfrastructureAzure+3
figma2 min readCurated summary

An Update on our Make Designs Feature | Figma Blog

Figma temporarily disabled its Make Designs AI feature after discovering that some generated mockups closely resembled real applications, including Apple’s weather app. The issue came not from model training, but from insufficiently reviewed components and example screens in Figma’s custom design systems. Figma removed the problematic assets and planned stronger quality assurance before relaunching the feature, later bringing it back under the name First Draft with updates. ## How Make Designs Works - Combines an AI model, contextual design-system data, and a user prompt. - Uses generally available models such as OpenAI’s GPT-4o and Amazon Titan, without additional fine-tuning. - Relies on separate mobile and desktop design systems containing hundreds of components and example compositions. - The language model selects, arranges, parameterizes, and themes components based on the prompt. - Amazon Titan generates the images used in the resulting designs. ## What Went Wrong - Figma reviewed the design systems during development and private beta testing. - Shortly before Config 2024, new components and example screens were added without sufficient vetting. - Some assets resembled patterns from real-world applications. - A prompt for a weather app produced results that appeared notably similar to Apple’s first-party design. - The incident was identified after designer Andy Allen raised the concern, prompting an immediate investigation. ## Figma’s Response - The team traced the similarities to assets in the underlying design systems. - Problematic components and examples were removed. - Make Designs was rolled back and disabled. - Figma postponed relaunching the feature while developing a more robust QA process. ## Future Direction - Make Designs was originally called “First Draft” to emphasize that AI output is only a starting point. - Figma wants users eventually to connect the feature to their own company design systems. - This could reduce the time spent locating, assembling, and configuring components. - Figma maintains that designers remain essential for refining drafts into meaningful user experiences. - The feature was later re-enabled with updates and renamed First Draft. Figma’s experience highlights the need to carefully audit not only AI models but also the data, components, and examples supplied to them. AI-generated designs should be treated as starting points that require professional review and creative refinement.

Read original(opens in new tab)
AIDesign SystemsGenerative AIUser Interface+3
figma2 min readCurated summary

Crafting the Visual Identity for Config 2024 | Figma Blog

Figma’s Brand Studio created Config 2024’s visual identity as an immersive extension of the Figma brand. Inspired by the redesigned Figma canvas and Figma Slides, the team developed a flexible, shape-based system that could work across a massive physical and digital conference experience. The result balanced visual variety with practical UX needs for more than 10,000 in-person attendees and a larger virtual audience. ## Balancing Form and Function - The team drew inspiration from switching between different modes of making, such as creating, sharing, and presenting work. - They developed a visual language centered on shapes that could: - Shift and transform - Amplify creative ideas - Reveal unexpected perspectives - Represent collaboration and multiple modes of creation - Three large physical supergraphics formed the conference’s central installations. - Attendees used them as seating, photo backdrops, and meeting points. - The identity was designed not only for visual impact but also for usability. - It supported complex experiences such as registration and navigating popular talks. - The system helped guide attendees through the event while maintaining a cohesive look. - Simple primitive shapes served as the foundation for more complex graphic structures. ## Designing at Scale - Config required a large volume of assets across physical spaces, digital surfaces, signage, merchandise, and other touchpoints. - The team created a modular system that could remain consistent without becoming repetitive. - Its core shapes came directly from the Figma toolbar: - Rectangle - Circle - Polygon - These basic forms reflected the starting point of the design process in Figma and became components of larger supergraphics. - The team built a reusable component library in Figma to generate variations efficiently. - Each supergraphic included three variants, allowing shapes to be presented from different angles and creating visual variety across the conference. Figma’s approach demonstrates how a strong event identity can combine expressive branding with a practical, reusable design system. By treating simple interface primitives as flexible building blocks, the team created a conference experience that could scale across environments while remaining recognizably Figma.

Read original(opens in new tab)
FigmaDesign SystemsUser ExperienceComponent Library+1
datadog3 min readCurated summary

Timeseries indexing at scale

Datadog’s metrics volume grew 30× from 2017 to 2022, while customers began running increasingly complex queries. This growth exposed limitations in the Timeseries Index service, whose original indexing approach became a performance and maintenance bottleneck. The post introduces Datadog’s metrics architecture and explains how its indexing strategy evolved to handle large-scale workloads more reliably. ## Metrics Platform Architecture - **Intake** - Datadog Agents send data points through a load balancer to metrics intake. - Each point contains a metric name, timestamp, numerical value, and optional tags. - Tags such as `env`, `host`, and `service` provide dimensions for filtering, aggregation, and comparison. - Data is written to Kafka, allowing multiple consumers to process it for storage, indexing, analysis, and archiving. - **Storage** - The short-term storage layer has two services: - The Timeseries Database stores tuples of `<timeseries_id, timestamp, float64>`. - The Timeseries Index stores `<timeseries_id, tags>` mappings. - The custom Timeseries Index database is built on RocksDB and supports filtering and grouping during queries. - **Query Processing** - The distributed query layer contacts index nodes, retrieves intermediate results from the timeseries database, and combines them. - Filters such as `env:prod AND service:event-consumer` restrict results to matching data points. - Grouping by tags, such as `service`, produces separate timeseries for each group. - Aggregators such as `avg` combine values within each group. ## Why Timeseries Indexing Matters - Indexes prevent queries from scanning every timeseries associated with a metric, much like database indexes avoid full table scans. - Poorly designed or insufficient indexes can make queries slow and consume excessive CPU and memory. - As Datadog’s data volume and query complexity increased, the indexing system became a critical scalability concern. ## Automatically Generated Indexes - The original system generated indexes from live query behavior. - Slow or resource-intensive queries were recorded in a query log and analyzed periodically. - Index selection considered: - Query frequency - Execution time - Number of input timeseries identifiers scanned - Number of output identifiers returned - Highly selective queries—with a high input-to-output ratio—received indexes. - Obsolete indexes that no longer received queries were removed. - These indexes acted as materialized views, replacing expensive scans with efficient key-value lookups. ## Original Indexing Service Design - The service was written in Go and used embedded SQLite and RocksDB databases. - SQLite stored metadata, including: - Index definitions - Query logs - Query counts and timestamps - Input and output cardinalities - Query durations - Index definitions were read frequently, updated rarely, and cached entirely in memory. - Query logs were bulk-written in the background, keeping them out of the ingestion and query paths. - SQLite’s SQL interface made the metadata easy to inspect and modify manually. - RocksDB handled the high-volume write workload required to index trillions of events per day. Datadog’s experience shows that indexing strategies that work at smaller scale can become bottlenecks as data volume and query sophistication grow. Effective timeseries systems therefore need adaptive indexing, careful separation of query and ingestion workloads, and storage technologies suited to extremely high write rates.

Read original(opens in new tab)
Database DesignDatadogApache KafkaGo+4
datadog3 min readCurated summary

Timeseries indexing at scale | Datadog

Datadog’s “Time Series Indexing at Scale” explains how an observability platform can index and query enormous numbers of time series without making tag-based searches prohibitively expensive. The central challenge is matching flexible combinations of metric names and tags while keeping ingestion, storage, and query latency predictable. The article presents indexing strategies and architectural trade-offs that allow Datadog to support high-cardinality telemetry at scale. ## The Challenge of Time-Series Indexing - A time series is identified not only by its metric name but also by its complete set of tags. - Modern monitoring systems may contain billions of series generated by containers, hosts, services, and dynamic infrastructure. - Queries often filter on multiple tags, requiring the system to efficiently find the intersection of several large sets of series. - Indexing must support both: - Fast writes as new series appear - Low-latency reads for interactive dashboards and alerts - High-cardinality tags make naïve database indexes expensive in both storage and query processing. ## Inverted Indexes for Tags - Datadog uses an inverted-index model that maps searchable terms—such as metric names and tag values—to the series containing them. - A query can retrieve the posting list for each term and intersect those lists rather than scanning every time series. - Common terms may correspond to very large lists, so the system must optimize how these lists are stored, compressed, and combined. - The index separates metadata used to identify series from the time-series values stored for those series. ## Distributed Indexing - Index data is partitioned across machines so that no single node must hold or process the entire dataset. - Sharding enables horizontal scaling as the number of metrics, tags, and customers grows. - Query coordination gathers results from multiple shards and combines them into a single response. - The design must balance: - Even distribution of index data - Avoidance of hot shards - Efficient fan-out during queries - Resilience when individual nodes fail ## Managing Index Growth and Cardinality - Dynamic environments continuously create and remove series, making index lifecycle management essential. - Datadog must handle churn caused by short-lived containers, deployments, and changing tag values. - Compression and compact data structures reduce the memory and storage required for posting lists. - The system distinguishes between frequently queried data and less-used data to control resource consumption. - Cardinality limits and indexing policies help prevent unusually large tag dimensions from overwhelming the system. ## Query Performance and Trade-offs - Indexing every possible attribute would improve search flexibility but increase write, storage, and maintenance costs. - The platform therefore makes trade-offs between indexing coverage, freshness, and query speed. - Query execution can combine index filtering with additional processing over the remaining candidate series. - Caching and reuse of intermediate results can reduce repeated work for common queries. - The architecture is designed to maintain predictable latency even as data volume and query complexity increase. ## Operational Considerations - Large-scale indexing requires monitoring the index itself, including shard balance, ingestion lag, memory usage, and query fan-out. - Background processes must compact, expire, and rebalance index data without disrupting active queries. - Fault tolerance is important because an index outage can affect dashboards and alerts even when the underlying metric data remains available. - Separating indexing from time-series storage allows each subsystem to scale and evolve independently. Datadog’s approach illustrates that scalable observability depends as much on metadata indexing as on storing metric values. Systems handling high-cardinality telemetry should use distributed inverted indexes, compact representations, careful lifecycle management, and explicit trade-offs between flexibility and operational cost.

Read original(opens in new tab)
KubernetesObservabilityApplication Performance MonitoringLog Management+4
figma2 min readCurated summary

What is Good Design in the Age of AI? | Figma Blog

AI is making product creation faster and more accessible, increasing the importance of design as a differentiator. Figma argues that designers should not chase automation or trends, but apply enduring principles such as empathy, creativity, and solving real user needs. The future of good design will depend on experimentation, stronger design-to-code connections, pragmatism, and new forms of human–AI collaboration. ## AI Creates a New Design Inflection Point - Like the iPhone’s launch in 2007, AI is introducing a new medium that requires experimentation and the development of new interaction patterns. - Early mobile products often forced desktop experiences onto smaller screens; today, many AI products similarly rely on basic chatbots and templates. - Designers can unlock AI’s potential through: - Richer interactions - Intuitive gestures - Patterns designed specifically for AI - AI can generate code, designs, and complete applications from prompts, allowing teams to move rapidly from concept to creation. - As more people participate in product development, thoughtful design becomes increasingly important for products to stand out. ## Codifying the Fundamentals of Good Design - Figma’s AI feature for generating initial UI drafts needed to understand the mechanics of good design. - Because large language models are text-oriented, generating high-quality visual interfaces is more difficult than generating text or code. - A complete rulebook for design is impractical: - Good design contains too many contextual details to define exhaustively. - Extremely large prompts exceed technical token limits. - Figma instead focused on reducing design expertise to a small set of broadly applicable principles. - Teaching AI requires designers to make their intuitive knowledge explicit by creating rules that are: - Clear - Concrete - Practical - General enough to apply across many interfaces - The process resembles teaching design: instructors must break complex judgment into principles that others can understand and use. ## Design’s Continuing Role - AI should elevate design rather than simply automate it. - The most valuable design foundations remain relatively constant despite technological change. - Designers’ roles may evolve, but their understanding of users, creativity, and ability to solve meaningful problems remain essential. ## Practical Direction Teams should treat AI as a new design medium, not merely an automation tool. They should experiment with AI-native interaction patterns while grounding products in concise, teachable design principles and genuine user needs.

Read original(opens in new tab)
FigmaAIDesign SystemsLarge Language Models+2
figma3 min readCurated summary

Are we finally entering the age of androids? | Figma Blog

Humanoid robots are moving from science fiction into public spaces and workplaces, forcing people to confront both the promise and risks of embodied AI. Their humanlike form makes technology more intuitive and emotionally engaging, but it also encourages people to project intelligence, intention, and personality onto machines. The article argues that designers must shape this illusion carefully, using humanoid robots to foster connection and understanding rather than control or deception. ## Humanoids as Technology in Human Form - Ameca, created by Engineered Arts, performs at Las Vegas’s Sphere as an interactive entertainer. - It turns toward speakers, displays facial expressions, tells jokes, and responds conversationally. - Its appeal comes from combining AI with expressive robotics. - Apollo, developed by Apptronik and argodesign, represents a different model: - It is designed as a general-purpose laborer. - Its flat face, cameras, and LED mouth prioritize function over lifelike appearance. - Humanoid robots have deep cultural roots, appearing in Greek mythology, Taoist philosophy, and science fiction. - Their human form makes software easier to engage with through gestures, expressions, and face-to-face interaction—what Engineered Arts CEO Will Jackson describes as a heads-up alternative to screen-based technology and virtual reality. ## What the Illusion of Sentience Unlocks - Humans naturally anthropomorphize objects and search for faces, motives, and signs of life. - Madeline Gannon uses body language and animal behavior as inspiration for designing industrial robots with recognizable personalities. - Even simple geometric animations can appear intentional: the Heider and Simmel experiment showed that people assign motives to moving shapes. - Ameca intensifies this effect through: - Furrowed brows, smiles, and expressions of surprise - Celebrity impressions - Custom personalities created by a dedicated “Persona Architect” - The ability to switch behavioral modes depending on context - Engineered Arts deliberately avoids making Ameca appear fully human: - Its metallic body avoids realistic skin. - It has no defined race or gender. - Its artificiality makes the theatrical nature of the interaction more visible. - The technology underneath remains impersonal: AI interprets language and maps it to suitable facial expressions. Nevertheless, users can experience meaningful emotional moments, such as a shy attendee gaining confidence while speaking Japanese with Ameca. - Gannon argues that designers must make complex systems legible, much as everyday objects communicate how they should be used. - She sees design as a way to redirect technology toward curiosity, kindness, and care, creating relationships based on connection rather than control. ## Designing Androids for Work - Apollo does not claim to be sentient; its purpose is practical labor. - It is being developed to address worker shortages, including work in Mercedes-Benz factories and potentially space exploration. - Its humanoid shape is primarily a response to human-scale environments and tools. - Unlike Ameca, Apollo must appear approachable enough for workers to accept, while avoiding the uncanny valley. - The article frames this as a central design challenge: workplace robots need to communicate socially without misleading people about what they are. Humanoid robots are most valuable when their appearance and behavior clarify how people should interact with them. Whether used for entertainment or labor, designers should treat the illusion of intelligence as an ethical material—balancing emotional engagement with transparency and purposeful design.

Read original(opens in new tab)
AILarge Language ModelsAutomationHuman Computer Interaction+3
figma2 min readCurated summary

Can we reach beyond the echo chamber? | Figma Blog

The Browser Company’s Arc browser aims to rethink everyday browsing by drawing inspiration from outside the technology industry. Karla Mickens Cole and Nashilu Mouen argue that products become distinctive when they reflect many creative influences rather than copying existing conventions. Their approach to AI emphasizes subtle, useful experiences that blend naturally into users’ lives instead of adding AI merely as decoration. ## Designing Beyond the Tech Echo Chamber - The team deliberately looks to literature, film, art, and nature for inspiration. - Mouen cites writers such as Zadie Smith and Toni Morrison, asking how technology can be “in tech, without being of tech.” - The browser is treated as a large creative canvas with room for experimentation and play. - The team’s diverse perspectives contribute to a brand built from “many voices.” ## Reinventing Familiar Browser Conventions - Arc challenges established patterns, including the traditional placement of browser tabs. - The team’s recurring question is “Why not?”—a mindset that encourages them to reconsider assumptions. - Arc’s unboxing experience drew on: - Movie title sequences - The opening atmosphere of A24 films - The visual phenomenon of sunspots - These outside references help the product feel meaningfully different, not simply functionally new. ## Making AI Feel Natural - The Browser Company wants AI to solve practical problems and blend into ordinary browsing rather than overwhelm users with conspicuous AI branding. - Cole compares the desired approach to flowers: - They can appear unexpectedly and make an experience feel special. - They suggest care without being disruptive. - They reflect AI’s ongoing “seasons of growth.” - The team sees AI as something to plant thoughtfully within the product experience, not apply indiscriminately. ## Rapid Experimentation - The team prototypes quickly and evaluates which AI ideas genuinely improve the product. - Mouen notes that they had explored more than 30 applications in the previous month alone, indicating an experimental process in which some concepts will work and others will not. - Their view of AI is therefore practical and seasonal: its impact depends on the context and the moment. The article’s central recommendation is to build technology with influences beyond technology itself. For AI in particular, thoughtful integration, experimentation, and emotional subtlety may create more valuable experiences than adding obvious, standardized features.

Read original(opens in new tab)
AIUser ExperienceProduct DesignWeb Browsers+1
figma2 min readCurated summary

Welcome to The Prompt | Figma Blog

AI may transform design and building, but its ultimate impact remains unsettled. Figma’s *The Prompt* explores that uncertainty through essays and interviews with experts across design, engineering, product development, and the built environment. The collection argues that human judgment—especially the ability to ask thoughtful, well-framed questions—will remain central to making AI useful. ## Prompting as a Creative Discipline - Prompt engineering is described as the practice of getting better answers by asking better questions. - Like interviewing or editing a magazine, effective prompting requires: - Clear context - Thoughtful framing - Useful guidance - AI’s capabilities are treated as largely inert without human direction; people must coax useful results from the technology. - The act of questioning is presented as a fundamentally human and creative instinct. ## The Purpose of *The Prompt* - Created by Figma’s Story Studio and Brand Studio, the magazine launched at Config 2024. - It combines writing, interviews, and illustrations to examine how AI is changing creative and technical work. - Contributors come from both inside and outside Figma and work across: - Design - Engineering - Product development - Robotics - Manufacturing - Residential housing ## Questions About AI’s Future The magazine uses a range of prompts to investigate both immediate applications and larger societal questions, including: - What constitutes good design when AI can generate and automate more work? - Whether code becoming a commodity should be feared - How much data is actually necessary - How starting with imperfect or incomplete ideas can shape innovation - Whether AI development can move beyond technological echo chambers - If efficiency undermines creativity - How to build AI features that people both want and trust - The relationship between artificial design intelligence (ADI) and artificial general intelligence (AGI) - Whether automation can unlock the full potential of design systems - The role of robots in construction and housing - Whether society is entering an age of androids ## Practical and Long-Term Perspectives - Contributors examine ambitious challenges, such as applying AI to manufacturing and housing. - They also focus on what AI can deliver reliably today rather than only speculating about distant possibilities. - The goal is to make complex systems more understandable and usable while learning how to guide AI more effectively. Figma presents *The Prompt* as both a magazine and an experiment in inquiry: meaningful progress with AI depends not just on increasingly capable systems, but on humans asking clearer, more imaginative, and more responsible questions.

Read original(opens in new tab)
AIDesign SystemsLarge Language ModelsAutomation+4
figma3 min readCurated summary

Why Are We So Afraid Of Code As A Commodity? | Figma Blog

AI may commoditize code production, including language translation and design-to-code workflows, but that does not eliminate the need for engineers. The article argues that engineering’s lasting value lies in identifying the right problems, understanding users and constraints, and designing elegant, maintainable systems. AI should therefore be viewed less as a threat and more as a tool that expands creativity and shifts engineers toward higher-level decision-making. ## Code Generation Is Not the Same as Engineering - AI can increasingly: - Translate between programming languages, such as Python and C++. - Generate code more efficiently. - Convert designs into implementations using frameworks such as React, TypeScript, Kotlin, and Jetpack. - Design-to-code is comparable to translating between programming languages because modern design tools already represent designs in structured, code-like forms. - Producing code is only one part of engineering. Engineers must also: - Decide which problems are worth solving. - Choose appropriate solutions. - Create abstractions for reasoning about complex systems. - Balance correctness, simplicity, context, and constraints. - Framework-specific expertise becomes less valuable over time than first-principles reasoning about the common ideas underlying different platforms. ## The Art and Creativity of Engineering - AI is expected to automate rote work, potentially freeing engineers to focus on more creative activities. - There are often many viable ways to build a system; AI may expose additional approaches that engineers would not have considered. - Engineers remain responsible for evaluating tradeoffs among those options. - Technical implementation is presented as a creative discipline in which constraints can inspire better solutions and product decisions. ## Embracing Shifts in Engineering Roles - Engineering work begins before coding: - Teams discuss user needs. - They triage problems. - They align on what to build and how to approach it. - As AI handles more low-level implementation, coding will represent a smaller portion of an engineer’s responsibilities. - Engineers will spend more time prioritizing, aligning teams, interpreting context, and making product and system-level decisions. - The abstraction level of software development is rising as AI takes responsibility for increasingly lower-level parts of the technology stack. ## What AI Will Not Commoditize - AI still struggles to fully understand: - What users actually need. - The context surrounding a problem. - Conflicting constraints and product priorities. - How to compose intuitive, maintainable systems. - Engineers will continue to add value by reasoning from first principles and solving technical challenges from the ground up. - The central question is not whether AI automates design-to-code, but how engineers use that automation to work faster and explore better solutions. The practical recommendation is to embrace AI for repetitive implementation work while developing the higher-level skills that remain difficult to automate: problem selection, user understanding, system design, tradeoff analysis, and creative technical reasoning.

Read original(opens in new tab)
Generative AIReactTypeScriptDesign To Code+2
figma2 min readCurated summary

Stack the deck with Figma Slides | Figma Blog

Figma Slides is introduced as an open-beta presentation tool combining Figma’s high-fidelity design capabilities with FigJam’s collaborative feedback features. It aims to help designers and non-designers create more engaging presentations without exporting work into separate tools. Figma positions it as a way to turn product reviews, sales decks, and pitches into clearer visual stories and collaborative conversations. ## Why Figma Built Slides - Presenters commonly struggle with: - Designing creative layouts - Finding effective visuals - Spending more than eight hours creating a deck - Figma users created approximately 3.5 million presentations in the previous year. - Designers often had to move Figma work into other presentation tools or distribute prototypes and pre-reads to non-designers. - Figma Slides brings presentation creation into the same environment as design and collaboration. ## High-Fidelity Design Features - Slides includes core presentation features such as: - Speaker notes - Slide transitions - Presentation-focused editing tools - Design mode provides access to Figma Design capabilities, including: - Auto Layout - Advanced properties - Precise alignment and snapping - Interactive components and states - Interactive components, such as hover states, can remain functional during presentations. ## Shared Libraries and Assets - Existing Figma text styles, color styles, and design assets are available directly in Slides. - Designers can reuse established libraries instead of recreating presentation elements. - Copy-and-paste workflows work across Figma products, reducing the need to export interface designs individually. ## Grid View for Structuring Narratives - Users can edit individual slides or switch to grid view for an overview of the entire deck. - Grid view organizes slides into rows, making it easier to: - Rearrange sections - Review the overall story - Refine the narrative arc - This bird’s-eye perspective is particularly useful for long presentations where restructuring becomes difficult. ## From Presentations to Conversations - Figma’s experience with FigJam revealed the limitations of one-way presentations. - FigJam became a regular tool for meetings such as team kickoffs, bug bashes, executive reviews, all-hands meetings, and Q&A sessions. - Figma Slides is intended to combine polished visual storytelling with collaborative participation, helping more people contribute to and influence the discussion. Figma Slides’ central promise is to make presentations both visually sophisticated and easier to build collaboratively, allowing teams to design, organize, and discuss their ideas in one shared space.

Read original(opens in new tab)
FigmaUser ExperienceFigjamDesign Collaboration+3