Building two digital products to deliver one service
Part 1: Discovery
After our success with Business Grants Portal, more government agencies have come to the GDS team for help with their grants systems, including the Ministry of Culture, Community and Youth (MCCY).
Working on the MCCY Grants Portal, presented an opportunity to improve on what we’d built for Business Grants Portal and solve new problems unique to the community grants landscape.
Background
There are two parts to the grant process — an applicant sends in an application and a grant officer processes it. The whole process was manual and tedious.
Our challenge was to design the grant process as a digital service, which involved building one digital product for applicants to apply for grants and one digital product for grant officers to process grants. Of course, we wanted to take out the tediousness and add some joy.
Here’s how we did it.
How we decide what to build
Most government agencies expect us to just take their existing forms and build a digital version of them. When we start our collaboration, we spend time explaining that digitalisation is about rethinking the service for a digital audience, not just digitising existing forms and processes — and their inherent pain points.
A large part of the groundwork we do to engage our stakeholders — explaining our process, involving them in workshops and co-design activities — happens during the Discovery phase of product development.
During Discovery, we aim to get a good enough understanding of who might use the product and what the opportunities are for improving the current situation. We may not be able to cover all parts of the current process in depth during the discovery phase, so we aim for an overview and in-depth exploration of the major issues — enough to determine what would be best addressed in our minimum viable product (MVP).
Building a complete solution will always take time. The public service version of an MVP usually means what we can build quickly to alleviate the biggest problems so that we can deliver value to our users and stakeholders fast.
What happens during Discovery
Every product is different, so the activities conducted during Discovery will change to suit the product. The objectives of Discovery remain more or less the same though and these were our objectives and activities for the MCCY Grants Portal.
- Understand the current situation
Grant experience
Usually one of the first things we would do during Discovery is market or desktop research to get an understanding of the space we were in. However, the core team that started on this product worked on the Business Grants Portal, so we were starting from a strong foundation.
We knew that streamlining processes and reducing duplication of grants delivered great results for business grants, so right from the start, we explored the possibility of doing the same for community grants. Having a successful case study to reference also helped us demonstrate to our stakeholders how a cross-agency collaborative approach could make a real difference to the outcomes achieved.
There were also improvements or enhancements that we wanted to test out. For example, Business Grants Portal was organised by process — when an applicant logged in, they saw all the actions they could perform. But we knew from our usability testing that applicants’ mental model was, “I have grant application XYZ and I need to submit a claim for it”, so they typically looked for the application and not the action.
While enhancements have since been made to Business Grants Portal, such a large change to the information architecture needed to be phased and prioritised. With the MCCY Grants Portal, we had the opportunity to build differently, test out alternatives and share our findings with the Business Grants Portal team.
Stakeholder groups
Piecing together our overview of community grants started with engaging our stakeholders from the various government agencies.
We met with officers who process grants and their managers in half-day sessions. We asked them to explain all their grants, policy objectives, target audience, outreach efforts, stages in the grant process and challenges they faced.
This helped us map out the different types of grants, find similarities and narrow down our focus for the MVP.
More valuable than an overview was the rapport that we started to build with our stakeholders. It was important for them to meet the team, understand our various roles and how we work, and to see that we were genuinely interested in understanding their challenges and problems.
Trust comes from being transparent, honest and eliminating unnecessary middle layers. That’s how the GDS team works but it’s not always what our stakeholders have experienced. Making a connection with them early in the process and demonstrating our values and ways of working help us set baselines and expectations for our working relationship.
In-depth user interviews
Talking to people who apply for grants is the best way to identify opportunities for improvement. We asked them to walk us through their grant experience so that we could better understand how the process worked for them.
Synthesis of the information we’d gathered started with mapping both the applicant and grant officer journeys with front line staff.
Involving stakeholders in the mapping process, in this case grant officers who had the most contact with and knowledge of what applicants go through, is a good way to get buy-in on the points in the journey that need improvement.
Mapping both the applicant journey and the grant officer journey at the same time helped us to understand how the grant officer’s process impacted the applicant’s experience and vice versa. The grant officers were able to appreciate that making things easier for the applicant at certain points would result in making their jobs easier down the track. This was an important insight to support changes to policy and process that would deliver a better service.
We could see from the work done thus far that streamlining the process would deliver greater efficiencies, enable us to get more grants on the system quicker and provide applicants with a more consistent experience. So we focused these mapping sessions on finding similarities in the processes across grants.
2. Explore new ideas
After getting as good an understanding of the current situation as possible, we had lots of ideas we wanted to test.
An example was the dashboard page or the page an applicant would see when they logged in, where we tested out a different information architecture to better suit applicants’ mental model.
As we were building two products, we tested prototypes for applicants with applicants and prototypes for grant officers with grant officers.
3. Determine what the MVP should be
Following our design and technology explorations, feedback from stakeholders and applicants and several iterations, we had a reasonably good idea of what our MVP should be.
The next task was to create a product backlog and start prioritising features.
As we were still working without a product owner, we facilitated product vision and prioritisation workshops to get all our stakeholders on the same page. We used prioritisation techniques such as buy a feature and dot voting to help our stakeholders talk through their differing priorities and come to a consensus.
Setting clear and measurable objectives at the start was crucial to ensuring we were collecting the right data for reporting. As team lead, it was important for me to be able to quantify the value the team delivered and ensure they were getting recognition for the work they were doing.
From Discovery to Development
Armed with our product vision and prioritised product backlog, we had both the direction and the plan clearly articulated to guide us as we started to build our MVP.
We may only have a Discovery phase at the beginning but discovery activities continue during the Development phase as needed.
If you’d like to learn more about how designers and developers work together in our team, stay tuned for Part 2: Development.
If you’d like to build digital products and services from scratch and are interested in working for the public good, get in touch with Soh Wendy, Janice Tan or Steven Koh.
