The learning curve before AI
What our research showed about how teams adopted SGDS before AI-assisted delivery became part of the workflow.
What we wanted to learn
Before AI-assisted workflows became part of product delivery conversations, we wanted to understand how teams adopted and used SGDS during real project work.
Most teams already recognised the value of accessibility, consistency, and compliance. They were also trying to build services aligned with those principles.
From there, we focused on the delivery experience:
- Which parts of SGDS felt intuitive?
- Which parts took more effort to apply?
- How well did design and development workflows connect?
- Where did teams spend the most coordination effort during delivery?
The larger effort came from applying guidance consistently within active delivery environments.
The findings
The main finding was that adoption depended on how SGDS worked within everyday delivery.
Design intent, implementation behaviour, team capability, documentation, and local workflows all had to align before a service could feel coherent.
Designers and developers were often operating in separate systems
Designers and developers often worked in different tools, workflows, and implementation contexts.
The clearest gap was between design intent and implementation. Designers expected SGDS components to behave in one context. Developers had to rebuild that behaviour in another.
The SGDS component sat between visual design context and development context. Teams still had to translate intent into working code.
Documentation helped teams understand the system. Teams still needed a better bridge between design intent and implementation.
Even though teams used documentation regularly, guidance often sat outside the moment of delivery. Teams had to move between design files, documentation, code examples, accessibility references, and project requirements.
Each switch added interpretation work. Across larger projects, that coordination effort became part of the learning curve.
Standards still had to fit delivery
Teams understood the value of SGDS. The challenge was applying shared standards while working within timelines, frontend capacity, inherited patterns, and product constraints.
This meant adoption depended on how well SGDS fit into day-to-day delivery work.
Skill gaps increased delivery effort
The research also showed how much delivery depended on available frontend and design expertise.
Some teams had limited in-house support to interpret standards across design and code. Others relied heavily on engineers for small UI changes.
Guidelines still had to be translated manually into working interfaces. Teams also had limited low-code or no-code tools that understood government compliance needs.
This increased the effort needed to build consistent, user-friendly digital services efficiently.
Local workflows solved immediate problems
Under delivery pressure, teams sometimes used local workarounds.
Some adapted SGDS components. Some detached design components. Others built custom patterns or used familiar implementation approaches.
These decisions often made sense within a single project. Over time, they could make services less aligned across the wider ecosystem.
What the research taught us
The learning curve was about more than learning components. It was about applying shared decisions under real delivery conditions.
Teams needed SGDS guidance to be available in the tools they used and consistent across design and code.
Today, we are in a better position to narrow that gap. SGDS agent skills help bring system context into the tools teams already use to design, build, and review services. With the current technology, design and code can finally work from a more shared language.
We explored this shift further in:
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.