IDDS is Indonesia's design system for government technology, the shared language behind public services used at national scale. My work inside it: help the system keep up with how fast delivery now moves, without letting go of the consistency citizens actually trust.
A public service has to feel like one government. Here, consistency isn't a nicety. It's the product.
Government delivery runs on tight clocks. A brief can land at ten in the morning and need a concept by noon, and at that pace it is tempting to improvise a screen and move on. But every improvised screen is a small crack in trust: if two services feel like two different governments, people notice. On the build side, the same pressure shows up as drift, components quietly diverging until engineers are rebuilding pieces the system already had.
The real problem wasn't speed or consistency on their own. It was that they had been pulling against each other. I took on making them stop fighting, which came down to three things:
- Fast, but genuinely usable: shrink the time from brief to clickable concept without shipping something half-considered.
- Protect the handoff: design only with components that already exist in IDDS, so nothing new lands on engineering's plate.
- Turn fuzzy briefs into MVPs: take an incomplete request and give it a scope that can actually be built.
As a senior product designer inside IDDS, I designed the working method that gets us there (an AI-assisted workflow that composes existing IDDS components into a clickable prototype) and I designed it with engineering in the room rather than handing them a result to absorb later. That meant setting the guardrails for the system's voice and visual language, and making sure whatever we produced mapped cleanly onto the developer framework from the first step.
The method moves in four steps, each with a narrow job:
- Translate: parse an incomplete product doc into a clear, buildable MVP scope.
- Design: use AI to generate the concept from IDDS components only, never one-off parts.
- Validate: check it against the system, the voice, and the visual language before anyone gets attached.
- Prototype: hand off a clickable result that engineering can pick up without re-deriving it.
The point of building it with engineering, not around them, is that the output isn't a pretty picture to be reinterpreted. It already speaks the framework's language.
The gap between a brief and a prototype went from roughly a week to about an hour, and the speed didn't come at the system's expense. Concepts stay on existing IDDS components, which keeps services feeling like one government and means engineering isn't handed new parts to build at the worst possible moment. And because a rough idea becomes something clickable within the hour, a ministry reacts to a real artifact instead of a description. We learn what's wrong before investing days of design in Figma, not after. The rule I took from it: a decision-maker can't react to an idea, only to something they can touch. So you prototype to learn, not to impress.