✦ My Thoughts and Scribbles
At GovTech Edu, we work on multiple EdTech products within one ministry, each with its own dedicated designer. Unlike private companies, where products often follow a single business theme, government products within the same ministry can be completely different from one another—different users, different needs, and entirely different types of products. Because of this, one product might require a specific design component that doesn’t exist in others, and vice versa. Without a dedicated design team overseeing the bigger picture, this can lead to inconsistencies and inefficiencies.
Acknowledging this, we’ve operated with one core principle: every designer is responsible for bridging their local design with the main design system. This approach works best because each designer holds deep context for their own product, making them the strongest advocates when proposing and contributing new design components.
During my time as a Senior Product Designer at GovTech Edu, I took on a high level of ownership in the Financial Management Platform—one of the most complex products I’ve ever worked on. With countless flows and use cases, the platform required a wide range of design components that not only looked visually cohesive but also functioned seamlessly for our less tech-savvy users. I often referenced design benchmarks, but more often than not, I had to adapt and improvise from common patterns to ensure they truly fit the product context and aligned with my users’ behavior. This meant frequently modifying our existing design system to better suit my local context. Of course, this raised concerns about maintaining design consistency across products, so I had to be extra mindful in executing design components while balancing standardization with real user needs.
After plenty of trial and error, I’d love to share some of the best collective practices that have proven effective in helping us manage the design system across products :
While working on the Financial Management Platform, I quickly realized that this product was fundamentally different from others within GovTech Edu. Unlike most platforms designed to enhance teachers' learning experiences, ours focused on administrative workflows for treasurers and school operators—a niche user group with entirely different needs. As I built the platform, I found that the existing design system didn’t fully support our requirements. I kept encountering unique design cases—such as complex reporting tables, planning forms, and extensive banners that weren’t covered by our current system. Instead of making ad-hoc modifications each time, I decided to document every new component separately in one place. This might sound simple, but it made a huge difference. By consolidating everything, I could identify recurring patterns, which helped me make more thoughtful design decisions moving forward.
Beyond just aiding my own process, this documentation became essential when aligning with cross-functional design teams. It also served as a reliable source of truth for engineers and other designers whenever they needed to reference or adapt my designs.
Since managing the design system is a collective effort, we needed a structured process to align our work. That’s when we introduced a biweekly design system meeting, bringing all designers together to review each product’s components. With my local documentation in hand, I use this time to walk the team through my adaptations and gather their feedback.
These sessions also help cross-check whether similar components already exist in other squads, reducing redundancy. When a new component is approved for standardization, we complete a submission form with universal prompts to ensure consistent documentation. This approach helps us build a more adaptable, well-documented design system while keeping collaboration smooth.
Choosing the right tools has been key to supporting our collaboration. At one point, our team decided to create a published site for our design system—not just for internal use but as a reference that could potentially be adopted by other ministries as well. However, with no dedicated resources or budget to develop an independent site, we had to get creative and find a simple, free tool that everyone could access. At the time, we already had some component documentation, but it wasn’t complete. To fill the gaps, we collaborated with copywriters to create a structured documentation outline using Google Docs, assigning each designer as the PIC for specific components to ensure all necessary details were captured. Google Docs turned out to be the perfect choice, as it allowed us to work collaboratively and cross-check each other’s contributions in real time.
For the actual publication, we discovered Contentful, a free tool that let us build a custom CMS. We set dedicated working sessions to migrate all the information and add proper visual references that had been prepared in Google Docs. Personally, this whole process felt like a refreshing break from the usual routine—it gave me a chance to be more hands-on with the craft and take ownership of building a design system site from scratch.
As someone who had never been hands-on with a design system before, this approach has given me a deeper understanding of how it works while fostering a strong sense of ownership. It’s made us more mindful when creating new design components and has strengthened our bond as designers. With greater transparency in our work, it’s now much easier to ask for help because we know exactly what each other is working on
*In tribute to this article, I’d like to give a shoutout to Afnizar and Lody Andrian as the design system PICs for making this happen :)