Reusable components need consistent states and behavior as well as shared color and spacing values.
By the end: separate design tokens, component variants, and task-specific behavior without forcing every screen to look identical.
Name tokens by their role
A token is a named design value, such as a spacing step, focus color, or primary-action background. Naming a value by role lets the design evolve without making every component choose an unrelated literal. A token named "primary action" is more informative than an unexplained color copied everywhere.
Tokens do not decide where a primary action belongs. A destructive action may need a distinct role. Keep sufficient contrast for the actual foreground/background combinations, including hover, focus, and selected states. Recoloring a token is not a complete theme audit.
Separate a shared value from its use
Suppose two workshop cards look unrelated even though both offer the same kind of reservation. One uses a pale blue action and the other an amber action without an explanation. A visitor must work out whether the colors indicate different consequences or arbitrary styling. A shared design value can remove that accidental difference. It cannot decide whether reservation should be the main action in every context. Assign treatments according to each control's job.
A token gives a value a reusable name. You can think of a named primary-action background as an instruction to use the same value wherever that role applies. A variant is a component treatment, such as a filled primary button or an ordinary secondary button. The screen decides which action gets that treatment. These are different decisions. If View details should be secondary, changing the shared blue value to amber does not fix its mistaken primary assignment. The role must change at the screen or component level.
A value cannot choose the right action
Example problem · both actions primary
Clay basics · 3 demo places available
Action wording: Reserve a place
Action wording: View details
Example proposal · roles separated
Clay basics · 3 demo places available
Primary action wording: Reserve a place
Secondary action wording: View details
The alternatives keep the same actions and facts. The proposal changes which action is primary; recoloring both filled actions would leave their competition unresolved. These are static hierarchy examples, not new controls or measured attention results.
Names in an existing stylesheet do not always describe their current appearance. This site's Graphite theme has a variable called --green whose screen value is actually blue, #9abef3. Its gold value is #d5b477. The token experiment uses those same blue and amber color values as local action alternatives. Do not reason that a variable named green necessarily means success, ecology, or a green hue. Follow the value and its actual use. A historical name is evidence about naming, not proof of semantic meaning.
The foreground matters as much as the action background. These cards use the dark --on-accent text color, #172437, on their filled actions. Reusing that foreground with an arbitrary new background could make labels difficult to read. A shared system therefore needs permitted foreground and background pairs, not a bag of independent colors. The two specimens preserve the same reservation wording and facts while changing the action fill. That isolates a visible value change in the illustration without claiming that either choice produces better task completion.
Evaluate the foreground with its background
Blue action role · static specimen
Reserve a place
Fill: #9abef3 Text: #172437
Graphite screen value of --green
Amber action role · static specimen
Reserve a place
Fill: #d5b477 Text: #172437
Same action role, alternative fill
The specimens use the exact blue and amber fills from the card experiment with its dark text value. The role does not change when the hue changes. Graphite's variable named --green currently supplies blue on screen, so its spelling is not a reliable hue or success-state description.
Other repeated values can have roles too. A gap between related facts differs from the gap before the action group. Sharing a spacing value helps similar relationships look similar, but applying one gap everywhere removes those distinctions. The systems lab does not expose a spacing editor; its change is bounded to the selected cards' accent. Keep that limit in mind when inspecting the example. It demonstrates propagation of one choice across two cards, not automatic generation of a complete application theme or layout system.
Before using the model, identify the information that must remain stable through a recoloring. Clay basics takes place in the west studio, while Ink printing takes place in the east studio. Both show Saturday at 14:00 and initially show three local places. Their actions must continue to name reservation and details rather than a generic token operation. Predict that changing a color will preserve those facts and each card's local state. The next exploration checks that prediction instead of judging the palette only from a default screenshot.
Try the interface
Your task: Change the selected accent role and compare both workshop cards. Use their actions and check that labels and outcomes remain specific.
Refactor the working workshop card
Studio Desk demonstration. Actions affect this page only, not a real booking, account, or payment.
Reference card treatment
Weekend workshop
Clay basics
Make a small piece with a tutor.
When Saturday, 14:00
Where West studio
Available 3 places in this demo
No local reservation made.
Weekend workshop
Ink printing
Make a small print with a tutor.
When Saturday, 14:00
Where East studio
Available 3 places in this demo
No local reservation made.
Selected card treatment
Weekend workshop
Clay basics
Make a small piece with a tutor.
When Saturday, 14:00
Where West studio
Available 3 places in this demo
No local reservation made.
Weekend workshop
Ink printing
Make a small print with a tutor.
When Saturday, 14:00
Where East studio
Available 3 places in this demo
No local reservation made.
Only the selected treatment changes. The reference holds this lesson's starting treatment; unrelated style settings match across both sides. Design controls preserve local card feedback; Reset comparison restores both cards and the design controls. These alternatives are not assigned a quality score.
Watch one choice reach two independent cards
The comparison starts with the selected cards using the amber action role, while reference cards retain blue. Choose Blue action role and compare Clay basics across the two sides. Then inspect Ink printing. Both selected reservation fills change together, but the session names, locations, and action labels remain specific. The example changes a local accent value passed to the selected cards; it does not recolor the whole lesson, the reference cards, or every focus outline in the library.
Reserve a place on selected Clay basics. Its action becomes Release demo place, availability changes from three to two, and the status says one demo place is reserved with no payment taken. Inspect selected Ink printing before touching it. Its availability remains three because each card owns independent local reservation state. The reference cards are independent too. Confusing visual reuse with shared task state would cause a behavioral error that consistent colors cannot conceal.
Shared treatment, independent reservation state
Clay basics · static card specimen
Weekend workshop
Saturday, 14:00 West studio
Available: 2 places in this demo
Action wording: Release demo place
Secondary action wording: View details
One demo place reserved. No payment taken.
Ink printing · static card specimen
Weekend workshop
Saturday, 14:00 East studio
Available: 3 places in this demo
Action wording: Reserve a place
Secondary action wording: View details
No local reservation made.
This is a possible selected-side snapshot after reserving only Clay basics with the amber role active. The accent propagates to both cards, but only the operated card changes availability and feedback. The counts are local demo states, not shared live inventory.
With that place still held, choose the other accent role. The selected Clay card should still show its release action, two available places, and reservation feedback. Open View details on selected Ink printing, then switch the accent again. Its materials and apron text should remain open. These checks distinguish a restyling operation from a reset. A visitor changing an appearance preference should not silently lose work. Here the design presets preserve feedback, while Reset comparison deliberately restores both cards and the design controls to their initial states.
Use Release demo place on the held Clay card and read the resulting status. It returns to No local reservation made and three available places. No server has accepted a booking or released real inventory at any point. You can compare the same action across both palettes without inferring a production guarantee. A real reservation system would need its own availability and acceptance rules, including what happens when another visitor takes the last place during a request.
Inspect a details action next to a reservation action. In these ranked cards, reservation has the filled primary treatment and details remains secondary. Recoloring follows that role assignment rather than promoting every control. Now use Tab to locate the focused control. The focus outline uses the site's gold variable, not the card's local accent. In the amber alternative, similar hues can make focus and action fill appear related, but the outline's position still marks a different state. Assess it against the surrounding background rather than equating matching colors with matching functions.
Similar final colors can hide different transitions
Starting state
Operation
Result
Blue; Clay held; Ink details open
Choose Amber action role
Amber; Clay still held; Ink details still open
Amber; Clay held; Ink details open
Choose Blue action role
Blue; Clay still held; Ink details still open
Blue; Clay held; Ink details open
Reset comparison
Amber selected, blue references; no held places or open details on either side
Start with a held Clay place and open Ink details. Choosing Amber changes the accent without clearing those states. Reset also returns the selected accent to amber, but deliberately clears both sides' card state. Color alone cannot distinguish those operations.
Finally press Reset comparison and check both sides, including any reference card you changed. Held places and open details should disappear because reset remounts the cards. The selected accent returns to amber, its initial choice in this lesson. This differs from merely choosing Amber action role after using the cards, which preserves their state. Two controls that produce similar colors can have very different contracts about retained work, so appearance alone cannot tell you which one was used.
Specify component behavior
A button component needs rules for focus, disabled state, pending work, and labels. A form field needs visible identity, hints, errors, and a value contract. A data table needs meaningful headers and selection behavior. A shared border radius alone does not create a coherent interface.
The model changes an accent role across two selected cards while reference cards keep the original treatment. The actions retain their own names and messages. This is a bounded token-propagation example, not a production component library or a guarantee that all combinations are accessible.
Specify the component while it changes
A reusable button needs more than a rectangle specification. The reservation control starts as Reserve a place, changes to Release demo place while a local place is held, and keeps a status nearby. A details control instead changes its expanded state and label between View details and Hide details. Those contracts can share visual treatments without sharing outcomes. If a specification says only blue button, it omits the decisions that let someone predict what activating each control will do.
An implementation can also inherit rules from its surroundings. In this example, the general lab button rule supplies a minimum height of 44 CSS px, 17 CSS px text, and ten by twelve CSS px padding. The primary-action rule then supplies the accent fill and dark foreground. The card's gap and heading rules contribute other parts of the result. Looking at a color assignment alone misses that combined behavior. An apparent component specification should identify which shared rules still apply, especially when a later rule overrides an earlier one.
That inheritance matters during maintenance. Suppose someone changes all lab button text to a smaller size to fit one awkward label. Every card that inherits the rule may shrink, even if its local accent never changes. Conversely, adding a local background can leave an unsuitable inherited foreground in place. The specimen identifies the actual authored values involved, not a claim that every browser paints exactly those physical pixels. Evaluate the combined result with real labels and states.
Local --web-accent fill; --on-accent text; transparent border; weight 650
Which action receives primary status
Card accent choice
Blue #9abef3 or amber #d5b477
Held-place and details state
Keyboard focus rule
3 px var(--gold) outline; 3 px offset
Persistent selection and reservation status
These are authored CSS values from the working card, not measured device pixels. The local accent changes the primary fill, while shared lab and focus rules continue to apply. Inspecting only the local color would miss text, sizing, and keyboard indication.
A field component needs a different contract. Consider a fictional Email field containing [email protected]. Its visible identity must survive typing, its hint explains the use, and an error must describe a repair without deleting the value. The course's form examples make those responsibilities observable. The systems lab contains cards, not editable forms. The static field specimen extends the component-specification idea to another application task. It is labeled as an example so it cannot be mistaken for a new input that accepts data.
Some states should deliberately refuse an operation. In the separate save editor, pending work blocks editing and repeat submission until a reply or abandoned local wait ends that state. A shared button treatment cannot supply that policy on its own. Nor does a disabled appearance prevent duplicates elsewhere in a real service. When specifying a pending variant, state what remains visible, what input is unavailable, and how the person recovers. Do not apply that editor's pending policy to these immediate card toggles, which have no simulated waiting stage.
A field specification includes the entered state
Example · identity lost after typing
Entered value
mina
Generic feedback: The form could not be submitted. Check your details.
These static text specimens contrast missing visible identity with a persistent label, hint, and repair message. They are not inputs. The incomplete value 'mina' is deliberately unchanged, so the comparison concerns identification and feedback rather than a corrected address.
Use the existing card actions to inspect a nondefault state before deciding the system is coherent. Hold one place, open details, and move keyboard focus between the two controls. Ask whether the labels still fit and whether feedback stays attached to the relevant card. Then change only the accent. This checks a component in use, not merely a palette. A shared look is useful when it preserves recognizability through state changes. It is harmful if it hides whether the action is a reservation, a release, or information disclosure.
Allow exceptions with reasons
A booking flow and a staff dashboard have different density and task priorities. They can share controls and terminology without sharing one rigid layout. Document exceptions in terms of content and use, rather than adding unexplained one-off values whenever a screen is inconvenient.
Review components with long labels, missing content, errors, pending states, and keyboard operation. A system that only documents default screenshots leaves most real application behavior unspecified.
Make exceptions explicit without breaking recognition
A visitor deciding whether to attend Clay basics needs a readable session identity and a clear reservation action. An organizer finding a waitlisted guest may need compact comparable rows instead. Forcing both tasks into identical workshop cards would preserve a shape at the expense of the task. A useful system shares terminology, control behavior, and appropriate values while allowing different arrangements. Saying the dashboard should feel different does not specify an actionable design reason.
Consider two ordinary pages outside the lab. A workshop description may make its reservation action prominent after enough information to decide. A booking-detail page may offer cancellation as a secondary, consequential action. Both can use the same button construction, but they should not receive a primary treatment merely because it is available. Changing the primary token cannot repair a mistaken role assignment on either page. The specimen labels its contexts as hypothetical designs, not additional routes or working controls.
Shared construction does not require identical priorities
Explain the consequence before final cancellation.
These hypothetical page specimens preserve Clay basics and Mina Hart's two seats while assigning emphasis by task. They are static proposals, not new booking or cancellation routes. A consequential action needs its own behavioral protection even when it shares a button style.
Exceptions also require boundaries. If a destructive action uses a warning treatment, its label still needs to name the consequence. Color alone does not establish danger, permission, or reversibility. A reservation's blue or amber fill in this experiment says nothing about payment or refund rules. A cancellation confirmation elsewhere in the course is inline and recoverable locally, but real inventory may prevent restoration. Do not borrow a convenient visual variant and accidentally borrow a promise the actual operation cannot keep. Specify the behavior separately from the visual role.
To inspect a proposed system change, begin with the same session facts and one specific operation. Record the old treatment, make the value change, and compare that operation in its default and changed states. Here you can compare no reservation with one held place, and hidden with open details. If you change labels, spacing, and color together in another project, any observed difference concerns the combination. Even faster completion by several colleagues would not isolate color as the cause or prove that the whole system is usable.
Technical checks answer narrower questions. A contrast calculation tests a foreground and background pair under stated assumptions. A geometry check can show that a label fits without clipping at an inspected width. Neither measures whether a visitor understands Release demo place or notices an essential condition. Conversely, a person's preference for amber does not establish keyboard visibility. The current experiment offers deterministic local state changes and simultaneous comparisons, not collected user-performance measurements or an automated quality score.
A reproducible local check has a bounded conclusion
Action
Inspect directly
Supported conclusion
Reserve selected Clay basics
Release label, 2 places, local reservation status
This card changed its local state
Choose the other accent role
Both selected fills change; Ink remains at 3 places
Shared appearance does not share reservation state
Return focus with Tab
Outline location against its actual neighbors
Keyboard target can be inspected in this state
Reset comparison
Both sides restored; selected accent amber
Reset clears local card feedback by design
This trace checks propagation without losing local state. It supports a claim about this example's behavior. It contains no participant measurements, so it cannot establish that amber improves comprehension or that a complete design system is accessible.
For a practical handoff, describe one shared role, its permitted values, and the behavior that must survive a change. For these cards, that could mean a reservation action whose fill changes together across selected sessions while held places, details, labels, and feedback remain independent. State that Reset comparison is the deliberate exception that clears local state. Then name a task-specific exception such as cancellation remaining secondary. This is enough to test a concrete contract again without pretending that one accent experiment defines every component, every theme state, or a production booking service.
Exercises
Separate a token from a decision
Two buttons use the same primary-action token, but only one should dominate the current task. Is the token system broken?
Hint
The value is shared; the role assignment may be wrong.
Worked answer
Layer
Responsibility
Token
A named value
Variant
A role or state treatment
Screen design
Which action deserves that role
Consistency does not remove contextual judgment.
Not necessarily. Reassign the secondary action to an appropriate variant while retaining coherent token values. The system should help express hierarchy, not declare every button primary merely because the component supports that style.
Complete a field specification
A component sheet shows a beautiful empty field and nothing else. What important states are missing?
Hint
Think about entered data and things that go wrong.
Worked answer
State
Design question
Focused
Can the active field be identified?
Invalid
Can the error be understood and repaired?
Filled
Does the label remain visible?
Long content
Does information remain available?
Specify behavior as well as appearance.
Include focused, filled, disabled where appropriate, invalid, and pending or read-only cases if the product uses them. Specify labels, hints, messages, associations, and keyboard behavior. Check long content and enlargement. A screenshot of one default state is not a full component contract.
Sources and further reading
Selected guidance and technical definitions were reviewed, not a complete usability literature or accessibility audit. The interfaces are original teaching examples. They do not establish measured improvements in task performance. These optional links are not runtime dependencies.