hpe-branding/07-adoption-and-compliance.md

07 — Adoption and compliance

What it actually costs to align a product UI with the HPE Design System, and how to check whether one is aligned.

Three adoption paths

1. React plus Grommet plus grommet-theme-hpe

The path the design system is built for. Install the theme and you inherit colors, fonts, component defaults, keyboard navigation, ARIA support, focus handling, and responsive behavior.

Cost: highest if the product is not already React. Lowest ongoing cost after that, because brand refreshes arrive as a version bump.

This is the only path where the accessibility table in 05-accessibility.md reads "handled" down most of the column.

2. hpe-design-tokens only

For any other stack. Tokens are tech-agnostic and published to npm. You get the correct colors, type, and spacing. You do not get component behavior.

Cost: moderate to adopt, permanent to maintain. Every accessible behavior (keyboard, ARIA, focus, semantic structure, responsiveness) is yours to build and re-verify.

The docs recommend mapping to v0.9.0 tokens first to reach parity with the product's current look, verify against familiar styling, then upgrade forward. That turns one risky change into two with a checkpoint between them.

3. Reference only

Read the guidance, match by eye, use the templates as design references. Fine for a prototype or an internal tool. Not defensible for a customer-facing HPE product, because the values drift the moment the brand moves and nothing signals that they have.

Review checklist

Usable as a gate in a design or code review. Every item traces to a rule in the docs, cited to its doc here.

Brand marks (02)

• HPE Element is present at top-left of the product experience
• Element is accompanied by the company name and the product or service name
• Lockup spacing and layout are unmodified
• No HPE GreenLake badge on new material (the existing badge is retired)
• Correct positive or reversed logo variant for the background

Color (02)

• No raw hex values in the UI. Semantic or component tokens only
• Primitive tokens are not referenced directly
• Status colors used only where they carry meaning, never decoratively
• Strong backgrounds pair with onStrong text and icon tokens
• Nothing is conveyed by color alone. Every case has a label, icon, pattern, or underline as well
• Data visualization series start at the first token and proceed in order

Typography (02)

• HPE Graphik loaded from the HPE CDN, not bundled or substituted
• Heading levels chosen for semantics; size set by token, never by demoting a heading level
• Heading hierarchy has no skipped levels
• Paragraphs carry the maxWidth for their t-shirt size
• Sizes in rem so browser font settings scale the UI

Layout (02)

• Spacing comes from the scale, not arbitrary pixel values
• Spacing tokens used for layout; component or element tokens for elements
• Gap and padding, not margin
• Borders only where spacing and background contrast are insufficient

Copy (04)

• Sentence case throughout, including labels, columns, tabs, menus, dialogs
• Buttons ending in a short preposition capitalize it ("Sign Up")
• No all caps anywhere
• No string begins with a lowercase letter
• Acronyms defined on first use, and only used if repeated
• Long product names shortened after first reference
• Error messages do not blame the user, do not say "try", do not say "retry after some time"
• No references to "your administrator"
• Term list observed: application not app, ID, OK, I/O, "log in" vs "login"

Accessibility (05)

• Keyboard navigation reaches and operates every control
• Focus is visible on every focusable element
• All images and media have descriptive alt text
• All form fields, buttons, and errors have meaningful labels
• Decorative icons carry aria-hidden; meaningful icons carry a label
• Automated scan clean (axe or Lighthouse)
• Manual test performed. Automated tools catch 30 to 50% of violations, so a clean scan is a floor and not a pass

Version hygiene (03)

• Token major version recorded, and known to match sibling products. Two HPE products on different majors will not look like the same company
• No references into the deprecated.* token namespace

What compliance is worth arguing about

Not every item above carries the same weight. Ranked by consequence:

1. Accessibility failures. These can be procurement blockers, and in some jurisdictions legal exposure. Everything else on the list is cosmetic by comparison.
2. Element and logo misuse. Governed by the HPE Terms of Use, and the one category where a brand team is likely to intervene directly.
3. Hardcoded hex values. Not visible to a customer today, but this is what makes the next brand refresh expensive rather than free. The cost lands later, which is why it gets waved through.
4. Copy rules. Cheap to fix, visible to customers, and the thing that most often makes an acquired product feel un-HPE.
5. Spacing and type scale drift. Real but low-stakes individually. It accumulates into a UI that looks off without anyone being able to say why.

Where an acquired product typically stands

Worth setting expectations before scoping any alignment work. A product that joined HPE through acquisition usually has: its own component library, its own color constants in code, its own typeface, its own copy conventions, and no token layer at all. The realistic sequence is tokens first (path 2), copy second (cheap, high visibility), component migration last if ever.

The full React migration is rarely justified on brand grounds alone. It is justified when the accessibility column in 05-accessibility.md becomes a requirement, because that is where the "handled" entries are worth real engineering months.

Open questions

• Is there an HPE-internal alignment audit or scorecard that products are measured against? Nothing public suggests one. The design system repo does carry an alignment-audit entry in its knowledge/ directory, but it is a planned stub scoped to auditing the design system's own docs, tokens, and components, not product teams. Do not cite it as evidence of a product gate.
• What is the expected timeline for products to reach v2-Landmark, and is there a deadline attached?
• For an embedded or OEM UI, whose brand governs, and does the Element rule still apply?
• Does any HPE release process actually check the items above, or is this a self-assessment?