Hatching Ideas at the Ministry of Digital Development & Information (MDDI)
Yeo Yong Kiat | When MDDI invited us to speak at their inaugural Hatch-a-thon event in early August 2024, we were more than pleased to have our software engineers and UX designers explain how innovation works in design theory.
MDDI had organised a large hack-a-thon-like event known as Hatch-a-Thon, with the objective of "hatching" good solutions for their officers' problem statements. It was to be a grand one-day affair, where they would gather the entire ministry and have speakers engage them on digital products for various use cases.
If you've been following our story thus far, you'd know immediately that this was a golden opportunity for us to speak to policy officers, whose needs our products were designed to serve. But beyond our products, we wanted to engage policy officers on the topic of innovation.
Innovation is very much about bringing existing solutions into new spaces. It is more implementation than raw creativity, and more engagement than the brute force of technology. When we survey the landscape in public service, problems and solutions are familiar faces across sectors and agencies, albeit with slightly different flavours. The key to rapid innovation across the system is to first work out the factors of success in one agency - and then to quickly understand the unique business context of another agency with a strong view to implementation, and user engagement on change management processes required for this implementation.
Here at Transform, we knew that the solutions and problem statements we had gathered from within the Ministry of Health and National Healthcare Group would re-surface in one form or another. Imagine the potential if we could share not just one particular product or problem statement, but speak on a range of problem statements, tools and mindsets we had gleaned from our ongoing innovation work in health care.
The first task at hand was to gather the troops. So I asked the Sense product team if they'd be keen to engage an entire ministry.
Along with the opportunity of showcasing Sense, I wanted Shaina, Lay Hui and Wilson to share about how quick prototyping could be done with modern AI tools, and how our suite of three products were designed to solve recurrent problems across the public service.
The greatest privilege I've had in 2024 was to have a team committed to the public service. Not solely in terms of product development, but a keen interest to engage and educate on mindsets and know-how. The ladies and gentleman agreed without hesitation, despite a heavy backlog of product development work which I had assigned to them the week before.
You may ask: why not front this marketing initiative yourself as the product manager, instead of giving the product team another needless task that doesn't translate into product development? Shouldn't product teams focus on product work, rather than needless senior management face time? Isn't senior management and user face time the work of the product manager and Deputy Director?
On the contrary! Product teams should never shy away from speaking to stakeholders and users, for various reasons:
Any product team needs to continually speak to its users and target audience. If we're not out there speaking to our users at least once a week, then we are not building for them - we're likely building in a vacuum, and creating something for ourselves.
I would always much rather have my team speak than me. One of the greatest things ever at work is to see your team talk about the things they do, and do the work they love. These moments of genuine excitement and pride are truly priceless in our professional lives.
Stakeholder engagement should be a holistic team affair. Unilateral engagement solely by the product manager may save the product team time, but senior management misses out on the team philosophy and we miss out on the chance to build relationships. "Selling a product" is as much the team as it is about the product.
A mature product team relishes any opportunity to interact with its prospective users, because every touchpoint is an opportunity to change mindsets and build a relationship.
A product is good not because of the underlying technology or an impressive list of features. A product is good because it meets users at their needs without product bloat or bells and whistles.
With about 5 years of experience with government digital systems, the team articulated Sense's unique value proposition to public service:
- Data Security: When it came to handling sensitive data, the government takes no chances. Sense could be entirely deployed in the government environment, separated both data and metadata, and security parameters could be scaled up according to evolving needs - this gave the Ministry of Health confidence to adopt Sense as a data analytics solution.
- Flexibility & Self-Service: user access control, the connection to databases and the self-definition of metadata could all be configured by policy officers themselves, without the need for any data or system engineers - commercial solutions, today at least, still required engineering experts to some extent, and we wanted to empower policy officers in this regard.
- Potential Integration with the Government Ecosystem: we saw Sense as not just being able to connect to data sources, but to various other government in-house digital products as well. Fancy analysing data directly from FormSG application forms? Or perhaps you want an integration with SingStat open datasets? Maybe you'd like to call Sense in as an API to enhance your existing system interface? Sense was a critical product to retain as an in-house capability.
We knew from our user studies that government officers valued these features more than all the bells and whistles of high technology. Many officers had told us that they would much prefer a product that they could use without any worries of data breaches. They had also articulated need for a product that gave them full control over configuration, so that the product could keep up with policy reviews rather than wait endlessly for service requests and enhancements. Finally, policy officers had also emphasised to us to build something that could eventually integrate with the greater ecosystem of products (e.g. FormSG) that other parts of government were already building.
These were all good ideas, so we took them in to create Sense.
We intentionally kept the Sense user interface simple and clean. Because we knew that policy officers suffered cognitive overload from their day-to-day work.
When Shaina and Lay Hui engaged policy officers, we realised that many public service officers suffered from cognitive overload and context switching. Significant portions of their workday were spent reviewing appeals, engaging stakeholders, drafting public communications paragraphs and discussing policy proposals. By the time they had to deal with data analytics, it was usually near the end of a workday when they had exhausted their craniums.
The last thing anyone would want to see was a power-driven user interface filled with many dazzling icons and features. In our team's own words - no one really wants to operate an Adobe Photoshop if the job they want done can be achieved with a simple Microsoft Paint.
When designing Sense, we made sure to give users as much empty space as possible, with only a chat bar and a collapsible panel for chat history search, if required. This created the impression of a blank canvas, inviting policy officers to co-create with Sense. Beyond reducing clutter, we opted for a simple white colour scheme and simple black words, to keep the mind free.
We reduced features to a minimum, taking the liberty to optimise features such as choice of LLM or context memory specifications. As a result, we were able to hide many icons, further reducing clutter on the visual workspace and also reduce the cognitive load on the policy officer. Imagine having to decide what LLM you would like to use at the end of a tiring work day, when all you want is for something to get the work done!
Even the login protocol was carefully designed. Aside from technical reasons, we didn't favour an email One-Time Pin (OTP) because we wanted to reduce the hassle of having to switch between interfaces. We wanted login to be a seamless experience, where officers could leverage on the WOG AAD login protocols on their government-issued laptops, and login with a simple click.
Nothing flashy. Just user-centric features and design, that sought to help officers focus on their work.
It's only halfway through the work year, but the team is only just getting started.
8 months so far into the year - it's been a wild but meaningful ride with these young ones. I hope to take them further and higher, with the limited time I have left in GovTech. If you're interested in hearing about our user design process, feel free to drop me an email at yeo_yong_kiat@tech.gov.sg. If I'm still hanging around in GovTech, I'd love for my team to share more of their work with you.