Bilicube Journal
Practical notes on design, research,
and creative work with AI.
Why Design Token Pipelines Fail Between Tools
Design token pipelines usually fail at the assumptions between tools, not inside one tool in isolation. A value can be correct in a design file, absent from an export, renamed during transformation, trapped in an unpublished package, or ignored by consuming code. If the pipeline is treated as one opaque automation system, every symptom looks alike. The practical fix is to debug the pipeline as a sequence of contracts. At each boundary, define what must be preserved—meaning, name, format, version, and delivery status—then place the check closest to the boundary that can break it. This approach does not prove that one architecture is more effective than another, but it gives a team a way to identify the first divergence instead of repairing the last visible symptom.
Trace a Design Token to the Rendered UI
A visual mismatch is rarely explained by the screenshot alone. To debug it, trace the design token from its expected source value through aliases, transformations, generated output, component usage, active styles, and the browser’s rendered result. The useful question is not simply “what looks wrong?” It is “where did the intended value first diverge from the observed value?” This first-divergence approach prevents premature blame. A source token may be correct while an alias, build step, theme, component mapping, override, or runtime condition changes the result later. Conversely, browser inspection can show the final value without proving which upstream decision introduced it.
How to Reconcile Conflicting UX Research Findings
When contradictory UX research findings appear, the first task is not to choose which study sounds more persuasive. Establish whether the findings answer the same question under comparable conditions. Two studies can produce different results because they examined different users, contexts, tasks, measures, or interpretations—not because one must be discarded. A defensible response is to decompose the disagreement, identify the smallest unresolved uncertainty, and choose a proportionate action. That may mean narrowing a claim, segmenting the audience, checking a measure, running focused follow-up research, or proceeding with a recorded boundary around the decision.
Hugo Taxonomies vs Sections: A Practical Framework
Hugo sections, taxonomies, and page resources can all appear to organize content, but they represent different relationships. Choose a section when content belongs to a hierarchical area, a taxonomy when a classification crosses those areas, and a page resource when a file belongs to one page or page bundle. Start with the relationship you need to express—not the URL you happen to want. That distinction helps prevent a common modeling problem: using a label as if it were a content area, using a content area as if it were a reusable classification, or placing page-specific assets in a site-wide structure. The choice affects navigation, templates, queries, and the structure maintainers must keep consistent.
How to Define a Design Token Contract
A design token contract should answer more than “what is this value called?” It should explain what the token means, which values it can hold, who owns the decision, where the authoritative data lives, how it becomes usable in code, and what a change means for existing consumers. That distinction matters because two systems can contain matching names and values while still disagreeing about scope, modes, units, or intent. When a mismatch appears, the team should be able to identify whether the problem is an ambiguous decision, an unsupported type, a transformation error, stale generated output, or an implementation mistake. Treat tokens as an explicit interface, not an informal promise.
How to Organize Design System Release Notes
A design system release note should answer a consumer’s next question, not document everything a maintainer did. Product teams need to know what changed, whether their product is affected, what action is required, and where to find migration guidance. Organizing notes around those decisions turns a changelog from a chronological activity log into an impact-routing tool. The structure does not need to be long. It needs to make scope and consequence visible before a reader searches through commits, package changes, or implementation history.
How to Test Design Tokens Before Release
A token file can tell you whether a value is valid, but it cannot show whether a button label disappears in dark mode, a disabled state becomes indistinguishable from its background, or a component receives the wrong semantic role. Design-token testing should therefore be a chain of release gates rather than one undifferentiated visual QA pass. Start with checks that are cheap to repeat against the token source. Then test the relationships and consumers that give those values meaning. Finish with targeted rendered review in the contexts most likely to expose integration problems. The goal is not to claim that a release is defect-free. It is to make the release decision traceable and proportionate to the change.
When to Introduce a Design System
A new product does not need a design system because one appears on the roadmap. It needs one when repeated interface decisions are creating coordination work that shared rules or patterns could reduce. That distinction matters. Introducing a small foundation—shared decisions, a few stable patterns, or a limited set of tokens—is different from building and maintaining a complete component library. The first responds to a present problem. The second creates an ongoing product and ownership commitment.
How to Plan a Design Token Migration
A design token migration across several products is not mainly a matter of renaming values or converting files. It is a coordination problem: each product may consume different token layers, use different component versions, and tolerate a different amount of change. A workable plan makes those differences visible, separates reversible product waves from breaking changes, and defines validation and rollback conditions before implementation begins. Define what is moving Start by writing the migration boundary in terms that product teams can act on. Specify whether the change covers only foundational values such as color, spacing, and typography; semantic tokens that express roles such as surface-default or text-muted; component-level tokens; design-tool variables; code packages; or all of these layers.