📝 Articles
The Hardest Part of Design Systems Was Never Components
Layerone discusses the complexities of design systems, emphasising that the hardest challenges arise not from building components, but from fostering collaboration and adoption across teams. While many design systems focus on creating components, true success lies in aligning stakeholders, prioritising requests, and maintaining transparency. The design system team acts as a vital connector within the organisation, helping to ensure that systems evolve in a coordinated manner while supporting diverse product needs.
Why most design systems fail at the leadership layer
Ben explores why many design systems fail, attributing the issues to leadership rather than technical execution. They highlight three key failure modes: unclear ownership, misaligned incentives, and weak sponsorship. Effective design system leadership involves creating clear ownership, aligning incentives with system adoption, and actively supporting the system as a strategic asset. By building the right conditions for success, design systems can thrive and become true multipliers for organisations.
Your design system might be AI-ready. Your organisation probably isn't.
Murphy examines the organisational challenges that emerge when AI can successfully use your design system. Whilst technical preparation (tokens, documentation, semantic naming) is advancing rapidly, teams haven't addressed harder questions around quality control, accountability for AI-generated outputs, and contribution governance.
Motion Tokens: naming your movement
Francesco demonstrates how to structure motion tokens across primitive and semantic tiers, covering duration and easing values. By centralising animation decisions through tokens rather than hardcoded CSS values, teams ensure consistent interface personality whilst maintaining accessibility through prefers-reduced-motion support.
👀 Interesting Reads
Making product documentation work for humans and AI
In this post, Geri explores the evolving role of product documentation, emphasising that it must serve both humans and AI. By proposing a structure based on five key questions, Geri highlights how clear, well organised documentation can enhance usability and maintainability. This approach aims to transform often overlooked docs into vital infrastructure that supports teams and AI tools alike.
Design Token Naming Conventions
I discuss the challenges of naming design tokens within a design system, emphasising that clear and consistent naming is crucial for effective communication between design and development teams. I outline a three-tier architecture consisting of primitives, semantic tokens, and component-specific tokens, providing practical guidelines for when to create component tokens and how to name them effectively. I stress that naming should be an ongoing practice supported by lightweight governance to ensure clarity and usability as the system evolves.
🛠 Tutorials
Headless Storybook with Lit
James shows us how to build a "headless Storybook" by extracting Component Story Format (CSF) objects and merging them with the Custom Elements Manifest to create a portable stories manifest. Using TypeScript's AST to parse story files, the approach enables rendering Lit components in Next.js with server-side rendering, providing visibility into production behaviour whilst maintaining Storybook as the development source of truth.
🧰 Tools / Resources
Design Systems Documentation Schema
P.J. has created the Design System Documentation Standard (DSDS), defining a structured, machine-readable format for documenting design systems. This standard addresses six entity types: components, tokens, token groups, themes, styles, and patterns, while aiming to improve consistency and interoperability across documentation tools. The repository includes specifications, schemas, and examples to guide users in implementing and maintaining effective design system documentation.