Benefits of the Granicus Design System
One experience across products, faster delivery, aligned design and code, and less UI-library sprawl - what teams gain by adopting GDS.
Every Granicus product is trying to do the same hard thing: help people get work done in civic and public-sector software that feels clear, trustworthy, and fast. When each app invents its own buttons, forms, and spacing, that promise gets harder to keep - and more expensive to maintain.
GDS (@granicus/gds-core) is the shared UI system for Granicus web
products: token-driven React components, light and dark themes, and a Figma
source of truth that maps 1:1 to code. Here is what you gain when teams adopt
it.
One experience across products
Users should not have to relearn basic UI when they move between Admin UI, Blue Haven, Bazaar, or the next Granicus app. Shared components and tokens mean familiar patterns - primary actions, form fields, dialogs, feedback - look and behave the same way.
That consistency is not cosmetic. It reduces training friction, cuts support noise, and makes the portfolio feel like one company instead of a patchwork of UI kits.
Faster delivery for product teams
Design systems earn their keep in velocity:
- Stop rebuilding the basics - teams spend time on product flows, not another custom button.
- Clear defaults - sizing, spacing, color, and type come from tokens, so screens come together faster in review.
- Parallel work - design can prototype in Figma SPECS while engineering
wires
Gds*components that match those specs.
The win is not “fewer pixels.” It is fewer debates, fewer one-off CSS forks, and shorter paths from idea to shippable UI.
Design and engineering stay aligned
GDS is designed in Figma and shipped in code. Component sets in SPECS map to
GdsButton, GdsTextField, and the rest of the library - so handoff is a
shared vocabulary, not a guessing game.
When tokens change (color, type, space), the theme updates once. Products that consume GDS pick up the language without each team re-implementing the visual system by hand.
Less library sprawl, lower cost of change
Many Granicus frontends grew up on different stacks - Chakra UI, Material UI, Ant Design, and local patterns. That flexibility helped early delivery. At portfolio scale it creates:
- duplicated effort for the same UI jobs
- uneven accessibility and visual quality
- painful upgrades when every repo has its own kit
Converging on GDS does not mean rewriting everything overnight. It means new work and high-traffic seams land on one system, so the long-term cost of change goes down: one place to fix a focus ring, one place to improve a dialog, one place to ship dark mode correctly.
Built for real product constraints
GDS is practical for how Granicus ships software:
| Benefit | What it means in practice |
|---|---|
| Token-driven theming | Light and dark modes from semantic tokens, not hard-coded hex |
| MUI under the hood | Familiar React patterns, with Granicus wrappers and theme |
| Tree-shakeable packages | Import only the Gds* components you need |
| Documented & demoable | Docs, Storybook, and Figma for the same system |
| Internal distribution | Published to Granicus Artifactory under @granicus |
You keep the productivity of a mature React ecosystem while owning the brand, tokens, and component contracts that matter to Granicus.
Better accessibility by default
Accessibility should not depend on which repo a screen lives in. Shared components carry shared expectations: focus states, contrast-aware tokens, predictable keyboard behavior, and labels that travel with the control.
Every improvement to a GDS component helps every product that uses it - which is the opposite of fixing a11y bugs one app at a time.
A foundation products can grow on
GDS is not a freeze-frame of today’s screens. It is a foundation:
- Foundations - color, typography, spacing, elevation
- Components - the building blocks used in real product UI
- Adoption paths - gradual migration for apps that already have another kit
As more products adopt the system, contributions and feedback make the library stronger - the same loop that makes design systems valuable at any scale.
Who benefits
- Product managers - clearer UX consistency and faster feature delivery
- Designers - one Figma system, less re-spec work per app
- Engineers - fewer UI kits to learn, maintain, and upgrade
- Users - interfaces that feel coherent across Granicus
Start here
Ready to try it in an app?
- Getting started - install, theme, first component
- Foundations - tokens behind the look
- Components - the gallery of
Gds*building blocks - How EHQ will start using GDS - adoption in a multi-app product family