Corporate Services

Corporate services for the Singapore government

Table showing the roles involved in the project. I was the design lead for the product squad. I was involved September 2020 to September 2021

Background

As the UX Lead for the product, I led the product through the entire design thinking process.

My role started from the discovery workshop, to the prototype phase, and to the pilot phase for development handoff.

The product is a web app that acts as a single touchpoint for all corporate services in one of Singapore’s government ministries. It leverages on a BPM workflow engine to dynamically manage forms and workflows to enable faster adaptation to business change. It reaps the benefits of the ministry's new commercial cloud so that users can make their requests while working from home.

This was born in a skunkworks collaborative space to accelerate digital problem statements using Agile methodologies.

Problem

Employees were having a hard time with corporate services due to the sheer size of the organization, the security requirements, and their resulting processes.

1) Employees do not know who to approach for corporate services due to fragmented service delivery with multiple touch points.

2) Raising corporate service requests in a high security environment meant having to be on-premise at the office, which is challenging in times of COVID-19.

3) Employees are also having difficulties tracking and following up with these requests.

4) Service providers have to deal with long approval lead times when digitalising business changes due to strict security requirements.

Discovery Workshop

We used IBM's Enterprise Design Thinking and Scrum planning frameworks to translate a nebulous problem into actionable next steps.

Agenda for IBM Enterprise Design Thinking discovery workshop

Solution

From our discovery workshop, the stakeholders and the development squad ideated and validated a few solutions to explore.

1) Consolidate corporate services into a single touch point.

2) Leverage on the commercial cloud to enable access to services from home.

3) Present service requests using a mental model familiar to our users: tracking parcel delivery.

4) Utilise a workflow engine to enable quick changes to business workflows.

Process

I used IBM's Enterprise Design Thinking model of The Loop to structure my process.

The Loop in Enterprise Design Thinking by IBM. The Loop consists of 3 phases: Observe, Reflect, and Make.

Observe - Interview and test with requesters and service providers to understand their needs and pain points in their context.

Reflect - Speaking with our Product Owners, who are also our sponsor users, often to ensure alignment.

Make - Rapid prototyping various concepts to fail early and learn fast.

I also adapted the Lean UX tenet of "minimum viable conversation required to move forward one step"

This was becaused I was the only designer in a lean Agile squad. That meant cutting out unnecessary deliverables to minimise waste.

Examples:

1) My usability test note-taking spreadsheet functioned as a research plan, and a test report, and a compliance metrics calculator. My Product Owners accepted it and It was taken as a best practice in the designers' Chapter.

2) I talked through the screens and flows with my developer instead of a comprehensive handover document. This increased agility by cutting out the time it would have taken to create those deliverables.

Research

As the requirements were complex, my approach was 'bias towards action' to quickly validate my ideas.

I drew up countless wireframes and prototypes from low to mid to high fidelity and relentlessly tested them with users.

Some of the screens showing how I iterated from low to mid to high fidelity.
Some of the many different versions, iterations, and screens I tested

I ended up with a web app that features the ongoing requests front-and-center, as users spend most of their user journey checking their requests. A request details page similar to online parcel delivery trackers caters to existing mental models. A comment feature sits at the bottom of each request details page to cater for back-and-forths.

Adversities Faced

The skunkworks was a new project, and we were the first batch of products to go through this program.

Thus, we were faced with many blockers, risks, and issues, with many unknown dependencies in our journey.

The main ones that affected our product were:

1) There was a directive for all products to use a new design system at a very late stage. This meant we had to switch from 1 design system to another after all the high fidelity screens have been developed. All the product squads handled this by negotiating this requirement with the stakeholders collectively. As a result, we reached a compromise of a partial integration, minimising further delays to product launch.

2) The COTS workflow engine we settled on perviously was rejected as non-compliant after all the technical exploration has been done, setting us back by 4 sprints. This meant our initial idea to customise workflows for service providers with our own front-end had to be scrapped. We pivoted by focusing all efforts on the service requesting experience. Thus, we managed to focus on the features for our target persona, the requesters. We also managed to hit usability compliance metrics for SUS, SEQ, efficiency, and task success rates with this persona.

You may refer to the video below for an early version of the prototype before the direction pivot and design system switch.

Final Design

You may refer to the video below for a demo of the product on the dev environment.

Outcome

We achieved scores above what was needed for compliance for our usability metrics.

SUS = 68.1 (C;Okay)

Average SEQ = 5.75 (Fair)

Efficiency = 6.3 (Exceptional)

Task Completion Rate 83% (Fair)

The product is also projected to reduce annual working hours by 150,000 hours, and achieve an annual cost avoidance of SGD700,000.

Learnings

The biggest learning was stakeholder management in a high-power distanced, low-design mature environment.

I had to drive user-centricity with POs who were not supportive of user research. I tried to resolve this by speaking with their stakeholders as part of the user group, and got them involved. When they saw first-hand how the stakeholders behaved and what their needs are, they became more receptive to speaking with users, and gradually became more user-centred in their decision-making.

Other learnings were to consider beyond the ideal flows, and accessibility, and consider them early, as integral to the design process.

I could have also implement the Lean UX set-based design approach to minimise costs of pivoting.

Other projects: 
choyjinghui@gmail.com