Skip to content
bitzorcas
中EN

Concept

Design Language and Reference Boundaries

The visual formula, legal-industry reference boundary, and anti-template redlines for Design System 1.2.

Last updated

Design Language and Reference Boundaries

The BitzOrcas visual principle is:

Swiss typographic restraint + Fluent neutral material depth + shadcn semantic simplicity + the information density of Chinese enterprise UI.

This is a division of responsibilities, not a collage of four styles.

Reference: grid, proportion, raw scales

System: semantic roles

Component: state and density

Pattern / Recipe

Product Page

ADR 0801 + Frontend Design Guardian

InfluenceAdoptReject
SwissGrid, alignment, hierarchy, whitespace, typographic orderPoster-like exaggerated scale
FluentSurfaces, borders, overlays, elevation, quiet motionBrand glow and large glass surfaces
shadcnSemantic variables, composable primitives, open implementationTreating its default theme as the final brand
Enterprise UIDense tables, filters, batch operations, task efficiencyTiny text, heavy borders, crowded global bars

Commercial quality

  • Make the task, state, risk, and next action clear before adding decoration.
  • Use surface contrast and separators for default work areas; reserve shadows for actual elevation.
  • Allow at most one signature element per screen, such as a matter stage, evidence chain, deadline strip, or risk signal.
  • Use 14px for normal Chinese UI text and 13px for compact tables without shrinking action hit areas.
  • Use brand color for orientation and action, not for every link, state, focus ring, and navigation surface.
  • Validate with realistic long text, money, identifiers, permissions, and failure states.

Legacy legal products and earlier BitzOrcas designs may reveal:

  • the true scale of matters, clients, conflicts, time, deadlines, approvals, and finance;
  • workflows that require switching and comparing several matters;
  • customer acceptance of amber, navy, burgundy, and jade brand directions;
  • the importance of advanced filters, saved views, batch actions, and audit trails.

They do not authorize:

  • unlimited modules in the top bar or several persistent navigation rails;
  • a four-column filter form permanently occupying the first screen;
  • pale gold with white text, heavy borders, or tiny text everywhere;
  • gavels, scales, columns, or parchment as a shortcut for legal credibility;
  • different navigation, scrolling, and action placement on every page.

Anti-template redlines

The Design Guardian rejects these patterns by default:

  • every section rendered as a floating large-radius card;
  • purple-blue gradients, colored glow, or glass as the default background;
  • a mandatory title, three KPI cards, and a trend chart on every page;
  • meaningless pills, numbered sections, and English marketing fragments;
  • generic illustrations instead of real domain state;
  • oversized controls and whitespace used as a substitute for hierarchy;
  • generated bitmap text where users need to read exact UI content.

Premium quality comes from consistent proportion, material, information hierarchy, and complete interaction states.

Current source ownership

Design responsibilityCurrent ownerReview focus
Authored token sourcefrontend/packages/materials/src/tokens/sourceone-way Reference → System → Component dependency
CSS / TypeScript / schemapackages/materials/src/tokens/generatedgenerator-only output and a clean generate:check
Interaction primitives@bitz/componentssemantic tokens plus focus, disabled, and loading states
Shell and composed patterns@bitz/widgetsconsistent Side/Top, workspace, filter, and operation surfaces
Product pagesfrontend/apps/*SDK, permissions, fields, columns, copy, and business actions only
Exceptions and completionADR 0801, conformance ledger, UI checklistowner, exit condition, visual and accessibility evidence

The source still records component-compatibility and advanced-pattern work. Frozen means stable IDs, ownership, and behavioral contracts do not drift per page; it does not claim that every page is automatically conformant. Review concrete component states, representative viewports, and the conformance ledger together.

Design-review method

  1. State the user task, risk, and next action before discussing color or material.
  2. Trace every new value to an existing token; if none exists, identify its proper Reference, System, or Component owner.
  3. Check that the page did not reinvent a shell, filter, table, operation surface, or state language.
  4. Exercise realistic long copy, permission differences, empty data, failure, narrow viewport, keyboard, and reduced motion.
  5. Review an industry theme as brand expression only; it must not change permission, navigation, density, or SDK contracts.
  6. Require at least three stable use cases before proposing a new Pattern, then route it through Design Guardian and architecture review.
  7. Record pass or changes-required with a ledger reference instead of granting a verbal exception.

100%

Scroll or use controls to zoom · drag when enlarged · double-click for 100% / 200%