Worked Button contract example

Type: Example
Status: Active illustration
Canonical for: A compact worked mapping across the candidate Design and Development Contracts
Depends on: Candidate package; this is not an evidence-derived requirement or validated optimum

This example does not propose PDS property names, Button variants or a production serialization.

Shared kernel excerpt

FieldIllustrative value
conceptIdds.component.action-button
conceptTypeComponent
preferredLabelButton
descriptionInvokes an immediate action in the current product context.
statusStable
productScopeShared system

Linked alternatives:

  • ds.component.link for navigation;
  • ds.component.toggle-control for persistent binary state;
  • a product pattern contract for multi-step confirmation.

Design Contract excerpt

Selection boundary

Use when: the user intentionally invokes an immediate action such as saving, creating, retrying or opening a dialog.

Avoid when: the interaction primarily navigates to another resource, changes a persistent binary setting, or selects an option from a set.

Semantic dimensions

DimensionConceptsMeaning
Action-group emphasisemphasis.high, .medium, .lowRelative prominence within a named action group.
Impactimpact.neutral, .destructiveConsequence of activation; independent from emphasis.
Statestate.enabled, .disabled, .loadingCurrent interaction condition; independent from purpose.

Illustrative rules:

  • button.action-group.single-high: at most one emphasis.high Button in the same action group.
  • button.impact.independent: destructive impact does not by itself determine emphasis.
  • button.navigation.avoid: use the Link concept when the primary outcome is navigation.
  • button.icon.accessible-name: an icon-only Button requires an accessible name.

The contract does not require these semantic dimensions to become public runtime props. It requires their mapping to the actual design and code APIs to be explicit.

Mapping across layers

Semantic conceptIllustrative Figma valueIllustrative code valueMapping
emphasis.highHierarchy=Primaryappearance="primary"Exact within an action-group scope
emphasis.mediumHierarchy=Secondaryappearance="secondary"Exact within an action-group scope
emphasis.lowHierarchy=Tertiaryappearance="subtle"Contextual visual realization
impact.destructiveTone=Criticaltone="danger"Exact consequence mapping
state.loadingLoading=Trueloading={true}Exact state mapping

The labels differ, but the mapping makes the governed concept addressable. If the actual system mixes these concepts in one property, the mapping should record that rather than pretending the API is factorized.

Development Contract excerpt

Illustrative implementation binding:

FieldValue
FrameworkReact
Package@example/design-system
Export/importButton
Storybookcomponents-button
Figma mappingComponent key and Code Connect source

Illustrative public API mapping:

API propertyTypeSemantic dimensionNotes
appearancefinite string unionAction-group emphasis / visual realizationEvery value maps to an emphasis concept and treatment.
tonefinite string unionImpactDoes not imply emphasis.
loadingbooleanStateSuppresses duplicate activation according to implementation behavior.
disabledbooleanStateMust preserve disabled semantics and focus policy documented by the system.
typebutton/submit/reset unionNative behaviorForm context determines outcome.
onClickevent callbackAction eventPayload and timing are implementation-defined and documented.

What an agent should receive for a decision

For “Add a destructive final confirmation beside Cancel,” the projected packet might include:

  • Button purpose and Link/Toggle exclusions;
  • the current action-group scope;
  • impact and emphasis as separate concepts;
  • the final-confirmation pattern rule;
  • the closest valid alternatives;
  • actual Figma/code mappings for the supported implementation;
  • icon-label and focus requirements;
  • applicable validators.

It should not automatically receive every Button story, every token value or unrelated product pattern.

What remains outside this component contract

  • whether deletion is permitted;
  • whether confirmation is legally required;
  • user authorization;
  • rollback implementation;
  • product-specific copy approval;
  • the business rule determining which entity is affected.

The component contract can represent these conditions and states, but the product or platform owns their truth.