Design Rules Need to Reach the Product to Be Useful
The design file has clear rules, yet the live screens keep drifting. Sometimes the documentation is out of date, a name has changed, or the reason for an exception exists only in someone's memory.
This week's articles look at ways to close those gaps: putting design intent into names, recording the reasons behind decisions, and making documentation and code point to the same source.
This week, we're looking at design rules that reach the product. What matters is not just how neatly the rules are documented, but whether people can find, apply, and check them while working.
Here are four key points from this week's articles👇
This Week's Signal
1️⃣ Deliver the appearance alone, and the reasoning gets lost
AI Does Not Read Your Design System the Way You Do draws a distinction between having components and communicating how to use them. People fill gaps with conversations like “we had trouble with that combination last time,” but AI needs a record to refer to. That includes when something applies, what not to combine it with, and why an exception was allowed. Before adding more to the library, it may be worth documenting the reasoning behind choices that repeatedly go wrong.
2️⃣ Names become part of the design
Connecting Design Intent Beyond Figma Through Naming Conventions shows how much a small name can tell an automation tool. Identifying an icon asset or a component's child changes how it is extracted and turned into code. But a name can change while the screen still looks fine, hiding a broken connection. Setting naming conventions needs to go hand in hand with a way to notice when those conventions break.
3️⃣ Agree on where the current source of truth lives
Design Systems 2.0: When Code Becomes the Shared Reference proposes a workflow centered on running code. Maintaining the same information separately in Figma, documentation, and code means reconciling copies with every change. AI's output can also vary depending on which copy it reads. Not every team needs to change its workflow immediately, but it should be clear which source takes precedence when values disagree. Knowing the documentation is connected to the deployed version is more reassuring than simply calling it up to date.
4️⃣ A system comes alive when it solves recurring problems
Eight Design Systems Worth Revisiting—and the Decisions Within Them offers more than button designs. It covers decisions such as whether to preserve input after an error, how to display partial data, and how far to extend a system when shared rules do not fit. Those decisions keep teams from solving the same problems from scratch. When improving a system, starting with a problem that has come up repeatedly can reveal the documentation you need more clearly than a component inventory.
Reads That Make It Clearer
- The Judgment Criteria of a Designer Who Made 600 Cursor IconsIndividual explorations become system rules, with responsibility continuing after delivery. The process shows how to separate standards worth fixing from questions worth exploring further.
- Critiquing Design with Claude CodeValidation needs a purpose too. Deciding whether to review visual quality, onboarding, or conversion makes it easier to turn feedback into actual changes.
This Week's Branding Signals
- Cass Art: Turning Material Stories into a Brand ExperienceThe relationship between paintings and pigments becomes spatial graphics. An art supplier's expertise moves beyond product descriptions and into the experience of exploring the store.
- BUZZ BROTHERS: A Rebrand That Turns Team Energy into MotionAn identity built around motion carries into print through typography and color. It preserves a recognizable impression without repeating the same composition everywhere.
This Week's New Tools
This week's newly added tools and references are grouped by workflow.
Finding Design Guidance to Share with AI
- Awesome DESIGN.mdA collection of documents covering brands' color, typography, and component rules.
- Google DESIGN.md SpecificationA document format for describing token values alongside design intent.
- TypeUI Design SkillsCompare visual examples and the design guidance behind them.
- Spectr GalleryA gallery pairing mobile app screens with design analysis documents.
Connecting Guidance to Work and Review
- oh-my-designA tool for installing design references and skills in an agent's working environment.
- Web Interface GuidelinesGuidance for checking interface details such as input, feedback, and accessibility.
- Refactoring UI SkillsAn unofficial collection of review skills for hierarchy, typography, spacing, and more.
Learning from Recurring Product Problems and System Operations
- BladeExplore component distribution, adoption tracking, and contribution processes.
- SeedsUseful references for presenting empty and partially available data.
- GestaltCovers accessibility and environments with different languages and reading directions.
- PajamasShows how to accommodate product-specific needs while maintaining shared rules.
- OrbitExplore booking-service patterns for dates, currencies, and travel itineraries.
- GardenCovers patterns that help people continue working, including error guidance and preserving input.
- PatternFlyUseful for designing complex admin screens with bulk selection, logs, and more.
- Cash App Design SystemGuidance for expressing product character through motion and tone of voice.
Sharing Work and Meeting Designers
