Strengthening the system from within
How SGDS is strengthening its foundations, flexibility, contribution model, and accessibility guidance so the system fits real product delivery.
Grounded in the same purpose
Even as SGDS continues to evolve, the philosophy and purpose remain the same: shared foundations that help teams build government services that feel connected, familiar, accessible, and trustworthy.
The areas below are about making the system more useful in real delivery: improving core quality, supporting responsible flexibility, opening clearer contribution pathways, and extending accessibility guidance as interaction models change.
Strengthening the foundations
Before SGDS supports more delivery workflows, its foundation layer needs to stay dependable in everyday product work.
This means:
- improving component quality
- aligning design assets and web components more tightly
- clarifying implementation guidance
- reducing avoidable drift in repeated patterns
- supporting teams with existing constraints
This foundation work makes SGDS easier to rely on. It also sets up the next question: how the system can give teams more flexibility without making familiar service patterns harder to maintain.
Making flexibility easier to adopt
A recurring challenge is flexibility. Many product teams have asked for more room to express product identity while keeping common service patterns recognisable.
Some have found SGDS difficult to customise. Branding, migration, and existing workflows can also be hard to reconcile with a shared system. These are valid concerns within real delivery timelines and operational constraints.
We hear you. Our intention is to help SGDS fit more naturally into product workflows. Therefore, we are exploring:
- Broader colour flexibility: Allow teams to use colours beyond the default GovTech palette, while keeping accessibility as the priority.
- Multiple neutral palettes: Provide more neutral options, such as cool, warm, and default greys, so products can choose a better fit.
- System typography expansion: Provide clearer typography options, including serif, sans serif, and monospace choices where they support the product experience.
- Support for custom brand fonts: Make it easier for teams to use preferred brand fonts while staying aligned with SGDS guidance.
- Controlled gradient generation: Define safer ways to generate gradients with clearer constraints around contrast, accessibility, and usage.
- Clearer guidance: Make style decisions easier to apply, including where and how visual flexibility should be used. Where possible, this should feel like a guided setup flow that lowers the barrier to adoption.
- Migration skills: Explore migration support as part of SGDS agent skills. These skills could help teams understand what can move towards SGDS and what needs product judgement. This needs careful design because migration affects product experience and code structure, not only component names.
The goal is responsible flexibility: product identity without losing familiar service patterns.
This should not create another learning curve. If these choices are easier to configure and understand, adoption becomes less heavy. That matters because SGDS should stay accessible by default, even as it becomes more adaptable.
Making contribution easier
Long-term adoption also depends on clearer contribution pathways.
The model we are exploring has three layers:
- Core
- Shared
- Product
1. Core
The SGDS team maintains the core system. This covers:
- foundations
- components
- accessibility standards
- implementation guidance
- reusable patterns
This layer gives product teams a stable base to build on.
2. Shared
Teams across government may build patterns, workflows, or components on top of the core system. Some of these could also benefit other products. When a pattern proves useful beyond one context, it can move into a shared layer for broader reuse.
This creates a feedback loop between product delivery and real implementation needs. It also reduces the need to solve similar problems separately.
3. Product
Individual products still need flexibility for service-specific needs.
Some workflows or interaction patterns are intentionally product-specific. They may be tied to operational context, requirements, user needs, or service workflows. This layer gives teams room to adapt experiences without needing to fork or replace the system underneath.
Together, these layers keep the core stable, create space for shared reuse, and leave room for product-specific work.
Accessibility beyond graphical interfaces
Accessibility remains one of the foundations SGDS cannot compromise on.
Today, much of our accessibility guidance focuses on graphical interfaces and keyboard use. As services include new ways of interacting, SGDS may also need to consider natural language, AI-assisted interactions, voice, multimodal interactions, and automated or assisted service flows.
These areas require careful research, testing, and iteration. The goal is to keep accessibility close to how people actually use services, so SGDS can remain accessible by default.
What this supports
The aim is to make SGDS easier to maintain with the people who use it.
This helps the system stay practical as products, workflows, and interaction models change.
These improvements may be quieter than launching a new component, but they affect how well the system fits real product delivery.
Published May 2026
Singapore Government Design System
The Singapore Government Design System was developed to empower teams in creating fast, accessible and mobile-friendly digital services.