Bilicube Journal
Practical notes on design, research,
and creative work with AI.
How to Code Qualitative Design Research
Qualitative coding becomes flattening when a short label replaces the conditions that made an observation meaningful. A comment about “missing” a control may describe a navigation problem, an unfamiliar task, a device constraint, a preceding action, or an explanation the participant is still uncertain about. The words alone cannot decide among those possibilities. A defensible approach to coding qualitative design research treats codes as provisional handles for retrieval and comparison. It stores context with each excerpt, separates description from interpretation, delays broad categorisation, and carries uncertainty into any design implication. The goal is not to eliminate judgment. It is to make judgment visible, revisable, and appropriately bounded.
When Should an AI Design Workflow Pause?
AI should pause when the context, evidence, or authority is not strong enough for the next step.
Primitive vs Semantic Tokens for Multi-Brand Systems
Primitive and semantic tokens solve different problems in a multi-brand design system. Primitive tokens store reusable values such as colors, spacing units, and type sizes. Semantic tokens describe what those values mean in an interface, such as a primary action background, default surface, or muted text role. The practical question is not which layer is universally better. It is whether recurring brand variation justifies the extra naming, mapping, and governance required by a semantic layer.
AI-Assisted Design File Cleanup Checklist
AI works best here as a second pair of eyes, not as an automatic file-cleanup tool. A reliable cleanup checklist therefore moves from inventory to classification to evidence-backed recommendations, with human approval for changes that could affect meaning, history, reuse, or the source of truth. Define the cleanup boundary first Before asking AI to inspect a file, record what is in scope. Identify the file or project, its current source of truth, the date of the review, and the types of content that may be examined. Include pages, frames, components, styles, variables, attachments, exports, comments, and linked references when they matter to the file’s use.
How to Turn Research Notes Into Design Decisions
Research notes rarely arrive as clean evidence. A single document may combine what someone observed, why the team thinks it happened, and what a designer recommends doing next. If that mixture moves directly into a shared component, token, or guideline, a local interpretation can become a system-wide rule without a clear record of how the decision was reached. A stronger path is a gated evidence-to-decision chain: preserve the observation, synthesize the finding, state the interpretation, define the decision boundary, choose the smallest system response, and record when the decision should be revisited. This does not make a research finding universal. It makes the team’s reasoning inspectable.
Hugo Content Checks Before Publishing
A Hugo build can succeed while publishing the wrong content. Drafts may be included by the selected build mode, files from an earlier build may remain in the output directory, and example content from a theme may appear beside the site’s real pages. A useful pre-publish gate tests those predictable conditions explicitly; it does not treat a green build as proof that the site is ready. The practical boundary is simple: automate conditions that can be stated as invariants, then review the rendered site and editorial substance separately.
How to Detect Semantic Drift in Design Tokens
To detect semantic drift in design tokens, compare what each token is supposed to mean—not only whether its name and file format still match. A token can remain valid in a design file and a code package while its role, reference chain, binding, or rendered result has diverged. The useful audit is cross-layer. It connects semantic definitions to the design-tool representation, code package, consuming component, and representative UI state. The result should be a discrepancy record that explains what differs, where it matters, and whether the team should correct, migrate, or deliberately preserve the difference.
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.