Bilicube Journal
Practical notes on design, research,
and creative work with AI.
Design System Contribution Intake Without a Queue
A design system contribution process should route proposals by readiness and ownership, not turn every request into a centralized delivery ticket. The intake record needs enough context to distinguish a local product need from a reusable system candidate, then direct each proposal to self-service, collaboration, or system-team-led discovery. That distinction changes what intake is for. It is not a promise to deliver every requested component. It is a way to make the next decision visible: clarify the problem, test reuse, prepare a contribution, or keep the pattern within the product.
Archive or Delete Project Files? A Decision Framework
Creative teams should not decide what happens to a project folder simply because the project is finished. A completed campaign may contain approved exports, editable source files, rejected concepts, licensed assets, research, and approval messages, each with a different reason to remain available. The practical question is not “keep or delete the folder?” It is “what purpose, risk, or future need does each record still have?” Archiving or deleting project files works best as a record-level appraisal decision. First identify why a record might matter. Then check retention and privacy constraints, estimate the cost of recovering it, and choose active storage, controlled archiving, or documented deletion.
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.