Helios Design System

A scalable design system built for clarity, accessibility, and consistency across HashiCorp products. As a core designer on the HDS team, I helped build foundational components, improve accessibility, and align multi-product UX.

🏢 COMPANY

HashiCorp
(Helios Design System)

👥 TEAM

4 Product Designers (Including myself)
6 Design Systems Engineer
Design Manager
Accessibility engineer Lead

🤝 CONTRIBUTION MODEL

We worked as a cross-functional group of ~12 contributors, including designers, engineers, and PMs. Our weekly syncs focused on reviewing new components, aligning token usage, refining documentation, and testing implementations across HCP and open-source products.

🛠 TOOLS

  • Figma

  • VS Code

  • Confluence

  • GitHub

  • Browser DevTools

  • Slack & Zoom (feedback, testing, reviews)

📈 RESULTS

  • 30+ components launched and adopted across 5+ product teams

  • 20+ semantic tokens created or refined for spacing, color, and typography

  • 10+ documentation pages authored to improve clarity and adoption

  • Rolled out a refined color system and accessibility-first guidelines

  • Co-led efforts to standardize content patterns and banner guidance

  • Improved onboarding speed and designer–developer handoff with better documentation

  • Helped drive full adoption of Helios across key product surfaces like Boundary, Vault, and HCP

SUMMARY

Helios is HashiCorp’s internal design system, supporting consistency, accessibility, and scalability across product teams. It provides shared components, semantic tokens, and guidelines that help designers and engineers build faster and more confidently.

I contributed to core components, helped shape our token and color systems, wrote foundational documentation, and worked on improving the user experience of the 🔗 Helios site

FOUNDATIONS

We defined core building blocks early to align design and development across teams:

  • Spacing, type scale, and elevation systems

  • Base color primitives and component layout conventions

  • Border radius and shadow tokens to create structure and depth

These elements formed the base for all system components and variants.

IMPACT

  • Reduced layout inconsistencies and one-off spacing styles in Figma and code

  • Created a consistent rhythm across interfaces, especially in tables, modals, and side navs

  • Improved handoff speed and reduced review friction by providing exact values and spacing presets

COLOR SYSTEM

We built a semantic color system that supports both wireframes and full-fidelity UI:

  • Neutral colors for surfaces, borders, and backgrounds

  • Action colors for states like Highlight, Success, Warning, and Critical

  • Each color set included five shades (01–05) to cover interaction states

  • All combinations were tested against WCAG 2.2 guidelines to meet contrast requirements out of the box

I contributed to naming tokens with clear intent (e.g., Border/Primary, Foreground/Faint) and documented everyday use cases for badges, alerts, and buttons.

IMPACT

  • Reduced color token confusion by consolidating overlapping usage across 5+ product teams

  • Improved UI legibility and readability, especially in dark and dense data UIs

  • Enabled faster decision-making during component design reviews by referencing standardized semantic color pairs

  • Teams no longer needed to check contrast independently; accessibility was built in

TOKENS

Design tokens bridge design and code in Helios, defining core properties like color, spacing, and typography in a scalable, consistent format.

The system was structured in layers:

  • Core Palette: Raw HEX values (e.g., #0c0c0e) organized into ramps such as neutral-50 to neutral-700

  • Semantic Tokens: Contextual names (like foreground-primary, border-critical) that abstract the core palette into meaningful, usage-driven tokens

To improve usability, tokens were audited for consistency and accessibility, aligned across Figma and code, and documented with clear guidance for designers and developers. Naming conventions were clarified around key categories like Foreground, Border, Surface, and Page to support consistent usage.

IMPACT

  • Increased token adoption in production by aligning Figma and SCSS maps

  • Reduced token-related QA bugs (undefined or inconsistent token usage)

  • Improved onboarding by giving clear, intention-based names to design decisions

PROBLEM FACED

Communicating empty, error, and onboarding states with clarity and consistency.

Problem

One challenge I encountered while building system components was standardizing how product teams displayed application status.

A clear example of this was the Application State component, a flexible UI pattern used to communicate empty states, error states, and onboarding moments.

At the time, each product team had its own custom implementation. Some used banners, others created modals, and some stacked text, icons, and buttons with little guidance. This led to:

  • Inconsistent layouts and spacing

  • Non-semantic use of color and iconography

  • Missing or incorrect accessibility behaviors

  • Confusing user flows and overlapping actions

Solution

I worked with designers, engineers, and accessibility leads from five product teams to co-create a single, flexible Application State component in Helios.

Together, we:

  • Mapped shared use cases (e.g., empty states, 404s, form errors, onboarding prompts)

  • Defined semantic tokens for layout spacing, text, iconography, and action placement

  • Designed layout options (left or center aligned) with clear defaults and overrides

  • Supported media slots, error codes, up to 3 actionable buttons or links, and flexible body content

  • Documented best practices for accessibility (ARIA roles, heading levels, tab order)

  • Tested across screen readers, browsers, and products to meet WCAG 2.2 standards

Anatomy of the Application State

IMPACT

The component was adopted across all major HCP products, including Vault and Boundary.

It became the system standard for communicating stateful UX moments, reducing confusion, aligning interaction patterns, and making it easier for teams to deliver consistent, accessible UIs.

Key outcomes:

  • Improved design-to-dev handoff with clear layout and token guidance

  • Reduced one-off component implementations across teams

  • Created a scalable, branded experience for all empty, error, and onboarding flows

EXAMPLES IN USE

The following examples show Helios components and foundational tokens in use within HCP (HashiCorp Cloud Platform).

The UI features dense, task-oriented layouts, including tables, form inputs, and filterable lists, all built using Helios design tokens, layout patterns, and accessibility-checked components.

  • The table, search field, and button use Helios spacing, type, and interaction tokens.

  • The header hierarchy, status icon, and breadcrumb navigation adhere to a standardized component structure and documentation.

  • Semantic tokens ensure consistent spacing, shadows, and color behavior across different surfaces.

This screen is just one of many places where Helios powers the experience behind the scenes, helping teams ship UI faster, with more consistency and less rework.