Get started as a developer Onboarding for the early adopters program.

Early adopters use the same design system packages you're already familiar with, but opt into experimental DS v2 by:

 Angular 21 has not been formally tested by the design system team. A couple of teams have used it successfully, but we can't guarantee full compatibility. View setup walkthrough video

Using design system v2

A) Try it in your existing app

See what changes in your context before committing to a full upgrade.
  1. Create a branch in your repo
  2. Apply the initial DS v2 setup changes (imports, prefix, tokens v2)
  3. Run the app and review the changes
  4. Start with one page and share back with your team — don't try to fix the entire app on day one
 Why this approach works well:
  • Quick feedback on impact and risk
  • Easy to abandon (don't merge the branch)

B) Try the workspace template repo

Understand the workspace pattern and DS v2 structure before applying it to your product.
  1. Open the template repo for your framework:
  2. Click Use this template
  3. Choose Create a new repository
  4. Select an owner + repo name
  5. Choose Public or Private
  6. Click Create repository from template
  7. Clone the repo locally
  8. Install and run, go into the directory you created and run the following commands (in order):
    1. npm i
    2. npm run build
    3. npm run start (Angular) or npm run dev (React)
  9. Go to the listed port number of your localhost

Choose how you receive updates

Consider your tolerance for changes.

Next branch

Best balance of stability and the latest changes. You get changes once they have been reviewed and tested.

Dev branch

Fastest access to new fixes and improvements. Expect more churn and occasional breaking changes.

Production branch

Least change over time. Not ideal for early adopters, since fixes and improvements arrive later. If you're unsure, start on "Next." Move to Dev if you need fixes sooner, or to Production if you need more stability.

Compatibility and mixing rules

DS v2 experimental isn't "fully backward compatible" in practice because tokens v2 can visually impact DS 1.0 components.
  • You'll get the best results when tokens and components are upgraded together.
  • Mixing experimental and production components in one app may be possible, but is not recommended.

Plan your upgrade scope

  • If possible, start with a small/simple application while you're learning the new system.
  • For most teams with a monorepo setup, you will need to update the import statements and add the design tokens to the specific project you're upgrading.
 Monorepo setups can vary, which may affect the exact update steps. If you have any questions, book a drop-in hours session.

Updating your custom components

Most DDD services have custom UI alongside design system components. Set aside time to review and adjust custom elements to align with DS v2 styles.
  • Start by identifying where you have custom UI (a quick inventory is enough to begin).
  • Replace hard-coded values in your custom UI with the corresponding Tokens v2 values, such as:
    • Spacing (padding, margin, gaps)
    • Typography (font, size, weight, line height)
    • Color (text, background, borders)
    • Elevation / shadow (surfaces)

When tokens v2 values don't cover what you need

  • Identify gaps where Tokens v2 don't cover what you need.
  • Where needed, create custom styles to bridge those gaps, while keeping them consistent with the DS v2 look and feel.

Getting help and reporting issues

Use the #design-system-early-adopters Slack channel first so the cohort benefits and the design system team can clarify details before a GitHub issue is created. Avoid DMs to individual design system team members, and avoid the standard #design-system-support channel. Use the early adopters channel so all participants can benefit. Drop-in hours are the best option for deeper troubleshooting, debugging, or talking through bugs and features. Book drop-in hours (Tuesdays + Fridays, 1–3 PM MT)

Rollback and branching strategy

  • The simplest rollback is to reverse the setup steps.
  • If you're working in a branch, rollback can be as simple as not merging the branch.
  • Rollback becomes harder once you've made many manual updates to custom components.

End of program expectations

  • Moving to production at the end of the early adopter program (end of March 2026) includes switching goabx → goab.
  • Once the early adopter program ends:
    • The experimental library will no longer be updated
    • Design system team effort will shift to the production libraries and packages
    • Web components continue to be updated