Context

• In 2017, the Digital Service Standard was born (and updated yearly) with a mission to improve the online experience of ministries under the Ontario Public Service (OPS) and make services simpler, faster and better

• The DSS outlines specific criteria for creating a good digital product or service. These criteria are built on a shared core, including:

  • repeatable service design and data sharing patterns

  • transactional platforms (e.g. payments, notifications)

  • open standards for data and systems

  • hosting and internet infrastructure that allows scalability and quicker application deployment

  • well-documented application programming interfaces (API) to support flexible design and re-use of systems and data

Problem Space

Among the multiple initiatives I worked on, the largest undertaking was having to build an end-to-end experience for users on the Ontario Public Service’s most widely used internal tool, ONRequest.

ONRequest is an extremely robust platforrm and allows government employees to fill out almost any form you can think of.

Much of our exploratory research and discovery revealed that most of our power users (individuals who were using ONRequest at least 3 or more times a week on average) were craving an easier, more convenient way to fill out multiple forms.

As such, the overwhelming demand for a solution turned this problem into a high priority, high impact initiative.

Use Case

I’ll use an example to illustrate our use case.

Most branch administrators or workforce coordinators need to conduct co-op student onboarding which occurs every 4 months.

At the time, requests had to be separately submitted and each individual request had a unique REQ# identifier within our summary page. In addition, each request would have one recipient, one requester and an approver on the back end.

To fill out multiple requests, our users had to filter through the various search categories and find the appropriate forms per request.

To increase task efficiency, the idea of bundles (bulk requests) became frequently discussed as a massive solution to reducing workload for these users.

How would bundles work in ONRequest?

A new bundling flow would connect all the dots in the process of onboarding/offboarding and make it easier for admins knowing they could select and go through multiple forms with ease.

The end goal was:

• to have all related requests in one place

• to only fill out the recipient once

• to have one approval for bundled requests

• to create an umbrella REQ# specific to each bundle for tracking efficiency

High Level User Journey/Flow

At a surface level glance, this would be the new journey that our users would follow. The main difference between this flow and the old flow would be the green and yellow stages.

For comparison, here’s what the old flow looked like:

Design

100% of our users were on desktop as ONRequest security layers could not be bypassed on a mobile device. Normally, I would take a mobile-first approach to design but because of this, I could design for desktop breakpoints right off the jump.

Navigation

As per our new user flow, I submitted multiple blueprints for users to navigate to bundle creation. After multiple rounds of design feedback, I arrived on the following additions:

• A net-new icon added to the top nav bar, bringing the total icon count to 4

• A net-new “My Bundles” section situated underneath “Top Favourites”

Original Layout

New Layout

As mentioned above, there were many iterations of feedback because I was asked to come up with initial designs that took a “blue sky” approach (design as if there were no technical constraints).

After early discussions with the developers, I realized that they were against this approach since ONRequest as a whole platform was built on older, back-end architecture and it would be extremely costly to make front-end changes to accommodate for back-end deficiencies.

I was able to eliminate multiple concepts and found a prototype that ranked high with user satisfaction during MVP tests while unanimously meeting approval with the developers.

Creating A Custom Bundle

In keeping with some modern day, UX best practices for form design, I originally implemented a table format for users.

They could select the appropriate tab and pre-select all requests that they wanted to fill out before proceeding.

This design would also keep the user above the fold before natural scroll came into play.

After some more design critiques and feedback, I eliminated the table and kept it simple to a search query format with auto-fill via an active directory pull.

Selected forms would appear in a preview box for confirmation before user proceeds.

While these solutions were more aligned with modern day UX design best practices, user testing revealed shocking results.

Most of the power users on ONRequest (individuals making 3 or more requests weekly), skewed higher in age. As a result, these new designs did not resonate with their mental models of what bundling would look like.

After listening carefully to most of the preliminary usability tests, I reverted to an older 2 column design layout. The left column would be used for selection and the right column would be a selection preview.

It didn’t look like any modern site. But in the grand scheme of the UX, I had a huge intuition/assumption that it would be drastically more well-received.

Labelled Tab Finder Layout

We conducted some A/B tests to compare these newer, jankier designs to the more modern ones I mentioned above.

The secondary tests revealed MUCH higher user satisfaction rating and responses towards the older tabular finder layout in part due to the familiarity of the new layout with the way users were finding individual categories to fill out forms.

Instead of funneling users fully through search, providing it as a secondary option seemed to be the better solution. Majority of the users vastly preferred labelled category filter tabs so that they could keep their typing to a minimum.

When I conceptualized this design, I found from my secondary research that everyone who used ONRequest already knew which categories forms would be found under. This not only included power users but also extended to users who maybe only used ONRequest once a week.

With this knowledge in hand, the left hand column was specifically designed to mimic a structured category “filter down” flow starting with main categories and filtering down through sub-categories to eventually reach individual “Forms”.

Users were able to add as many requests as they desired to a bundle (all requests would appear in the bundle preview in the right hand column)

Our back-end tool, Enterprise Service Management Tool (eSMT), was able to automatically determine whether a request would be classified as a primary request or a secondary request.

Primary requests within a bundle would have to be submitted and approved before the user could fill out secondary requests. Secondary requests could be rearranged and filled out in the user’s desired order.

Filling Out Requests

After bundle creation, the user would fill out each form in the bundle.

Bundle Summary

Upon submission, the user would be directed to a summary page containing the pre-filled details of all the collective forms within the respective bundle.

Original

I had originally redesigned the whole summary page but after discussions at length with the devs, they told me that they would be undergoing astronomical technical debt if we followed through, so we pivoted and decided on a revamp of the original, individual request summary page (shown on left).

With the new bundle summary page, I introduced a more comprehensive view of individual form details via collapsible chevrons.

If there was ever a point where a user should be spending longer time looking at, it was this page.

The summary page was also accessible via automated email link which would be generated as soon as the user submitted.

As mentioned above, I tried to redesign this page originally because I was unsure if the devs could track individual forms within a bundle with a standard "REQ#”.

After deliberating, I was relieved to discover that bundles could be given a brand new “BUN#” tag for tracking purposes.

The Impact

Decreased task time when filling out multiple forms

Improved “time on task” when filling out multiple forms by 43% (basically cut the perform time by half which is incredible) and decreased single page bounce rate by 6%.

Decreased number of reported manual adjustments

Because a bundle would still only have a single approver for all the requests, users automatically became more vigilant when filling out each form as a mistake would mean they would have to resubmit the entire bundle again if they discovered a mistake(s) after submission.

 Staples >