Ontario Provincial SSO
User Experience, Public Service, Digital Product

I worked as a Product Designer with the Ontario Digital Service to help lay the groundwork for a new single sign-on (SSO) for the province's digital services. We worked alongside 13 different program areas and the Public Secure team before handing our work off to a vendor.

Scope and context

As put by an end-user we spoke with, the current one key single sign-in portal acts as a 'fake front door', in that most of the program areas using ONe-key require further verification upon the completion of signing in. Some of the larger issues we tackled were:

Problem statement

We observed that ONe-key and Public Secure Pilot confuse our public users while not meeting the expectations of our internal stakeholders, which causes a lower adaption of Ontario's single sign-on solution from digital services, in addition to higher call centre volumes from users. Our goal was to improve Ontario's single sign-on solution so that more program areas and end-users would adopt Public Secure, and so that call centre volumes would subsequently be reduced.

Stakeholder interviews

We talked to 13 program areas, composed of eight applications currently using ONe-key, four on the Public Secure Pilot, and one on a portal that uses both ONe-key and Service Ontario. We identified some commonly mentioned pain points that existed within ONe-key and Public Secure Pilot. These included:

Authentication levels

There are three unique levels of authentication: low (username and password), medium (username, password and an additional piece of ID), and high (username, password, two-factor authentication). Depending on the program area being accessed, different pieces of information were required within and throughout these three levels of authentication to sign-up or sign-in, making the concept of a single sign-on tricky.

A map depicting the different levels of authentications and their respective requirements

User interviews and personas

As this was an engagement occurring in the midst of the COVID-19 pandemic, recruiting users to interview proved to be a challenge. After the synthesis of our 12 user interviews, we grouped common traits and came up with three user personas. As this is a single sign-on that has the potential to be used by effectively any member of the Ontario public, we chose not to create personas within a specific niche, instead opting for a more all-encompassing set of personas to help steer our work.

An image of the user personas developped for this project

User experience design

After synthesizing stakeholder and user interviews notes we drafted up flows we found were particularly common and/or problematic:

We ultimately drafted numerous flows that encompassed everything from informing Public Secure users of the portal changes to incorrect sign-on attempts, but those five flows remained the most important throughout our testing sessions.

Sign-up made simpler

Shortly after we began user testing with our preliminary onboarding flows, we discovered that many users confused the different sign-in options as different types of accounts altogether. Since emails were mandatory regardless of the chosen sign-in method, we decided to use the email to initiate the account creation proccess. On top of simplifying the flows, this changed the way many users perceived the sign-in options: now instead of seeing them as different account types, they more appropriately recognized as different means of signing in to the same account.

An image of the old and revised sign-up flows

Managing additional IDs

During our testing sessions many users confused unique ID's (ie. MyBenefits' MemberID) with something needed to create/sign-in to an Ontario account, while some outright forgot that it was even a part of the registration process to begin with by the time the screen for it arrived. We changed it so that the user is prompted to input their unique ID before creating an account.

An image of the old and revised flows for ID verification

User interface

As we ran through 11 user testing sessions we ended up with five iterations of our prototypes. In the ensuing section I'll detail a few more interface related changes we made to our screens.

Final mockups

All things said and done, we mocked up 8 scenarios, with over 15 flows and more than 120 total screens between them all. The five flows on the ensuing pages are those that are relevant to the aforementioned five problematic flows, and were the ones we continued to test the most.

Links to interactive figma prototypes: