Scaling Design System I joined when Techcombank's design system had launched its first version and was adopted bank-wide. In the center team, we set out to scale standard documentation coverage across the library that brought the system from a visual reference to a decision-making tool, and managed contribution that made scaling sustainable without a full dedicated team behind it.
Where things stoodTechcombank's design system had launched its first version and was adopted at organizational scale: 400+ members across nine product teams on a single Figma platform. Components and patterns were in the library: variants, states, specs. Without guidelines, a component library act as a collection of style decisions, not design decisions.
Closing that gap wouldn't be straightforward. No dedicated resource owned the system, contributors were designers and writers fitting design system work between their own product deadlines.
Empathize We interviewed designers and writers, who were both users and authors of the guidelines, before setting anything up. Then we kept learning as guideline documentation were assigned.
The research provided us insights:
Using guidelinesExisting guidelines covered cases that had already been anticipated, and stopped there. The Do's and Don'ts format built confidence in clear-cut situations, but not in ambiguous ones. When a situation fell outside what was written, people defaulted to their own interpretation. The guideline hadn't given them a way to reason about pattern.
Writing guidelinesThe barrier wasn't doing the work, it was starting. A complex pattern, seen whole, felt too large to pick up alongside a full squad workload.
Contribution had no shape over time. Contributors showed up, did the work, and moved on, but there was no way to see effort accumulate.
Solutions For quality documentation Guidelines were structured in three layers, each answering a different question at a different moment in the design process.
The three layers gave contributors a shared starting point. How deep each pattern went was up to the owner.
For frictionless contribution 1 Complex guidelines versionedAn MVP that answered the most pressing questions first, with depth added iteratively. Large patterns became approachable without sacrificing quality. This really lowered the barrier to start.
2 Co-authorshipNo one had to tackle a complex pattern alone. Pairing naturally reduced the workload, but more importantly, it improved the quality of thinking. By the time the guideline reached its users, it had already been challenged, refined, and pressure-tested.
3 Making invisible work visible and reinforcedTracking streaks and recognizing consistent participation with a Design System Steward badge gave that effort a shape. It didn't solve recognition at the organizational level, but it made the work feel like it added up.
How thing improved Guideline coverage scaled from 10% to 70% in three months, and regular contributors grew from 8 to nearly 20, all while everyone involved was carrying full squad responsibilities.
But the metric that mattered most was the one we'd been working toward from the start: Design reviews gradually shifted from pattern alignment to higher-level decisions.
What I'd build nextI had designed for getting people in. I hadn't designed for what keeps the system, or the people building it, going.
Governance still has to answer what happens over time: what stays, what gets revisited, what earns the right to remain. Without that logic, a system doesn't evolve. It accumulates, and eventually recreates the same problem it was built to solve.
Making work visible within the team was a start, but not far enough. Recognition that actually shifts priorities lives at the organizational level, and that's a problem the design system team can inform, but not solve alone.