Code for Canada

Roles

I assumed the following roles for this project:

User Experience (UX) Designer
Interaction (IxD) Designer
User Interface (UI) Designer
Visual Designer

Deliverables

Interaction Design:
High-fidelity interactive prototypes for key tasks

UX/UI Design:

Personas
User journeys and task flows
Low-fidelity wireframes
High-fidelity mockups and prototypes
Design system and UI kit
Competitive analysis
User surveys and one-on-one interviews
Site map
Usability tests and findings

Project Specifications

Duration:
October 2022 - November 2023

Tools:

Figma
FigJam
Jira
Miro

Overview

The RCMP is dealing with many tickets regarding their scheduling application. The tickets pertain to the errors the users are facing and requesting help from the scheduling department when these issues can be fixed if the users understand what to do.

Code for Canada is a national nonprofit organization that uses tech and design to improve life in Canada, but in this case, the RCMP. I was placed on a project to fix their pain points and create a seamless experience for both end users.

Initial Findings & Restrictions

Code for Canada and RCMP had an initial meeting to understand better the issues they are facing and how Code for Canada can fix them. The meeting included the Executive Director, Lead Project Manager and the head of the scheduling department of the RCMP.

Findings

The Director wanted it to have a dashboard look and feel, similar to turbo tax
The scheduling department was facing an overwhelming amount of tickets per day
Even though there were attempts to show people how to avoid errors, they would get the same errors every time
Only one person was handling all the tickets
Tickets and scheduling timing issues would cause issues with regular and overtime pay
Tickets would cause future scheduling to be late and in disarray

Restrictions

We would have to work in a highly secure network on RCMP-certified laptops where we could only access approved websites
Figma and other application need to pass security authorization
No access to Github, Google apps (Gmail, Drive) and Microsoft One Drive
We cannot make ANY changes to the current Portal they use because another company runs it, and we had no access to change any of their codes or features
Approving applications takes time

Create an application that guides users to increase successful schedule submissions and decrease the number of tickets while working within the restrictions given.

First Round Discovery

After gaining access to the Portal and testing the scheduling system, we realized it's not entirely the user's fault for submitting incomplete schedules or tickets. This was due to the old and outdated Portal, and the user flow and visual hierarchy needing revision. Unfortunately, I cannot speak about all the parts that caused issues due to the secured network. Still, if I were in the officer's point of view, I wouldn't understand any of the errors, and I would want to spend the least time submitting my schedule and overtime pay. Eventually, the person that deals with the schedule will fix it in the end.

Insight & Pain Points

We, as the interviewers, realized her knowledge of the scheduling system and the meaning behind error messages is very high, and if you don't know a lot about it, you wouldn't be able to understand her
The tickets she receives are the same, and even though they are guides for the users, they still send in incomplete schedules
Over hundreds of tickets every two weeks or so, including overtime pay and unexpected workdays

Research & Interviews

Vast range of knowledge
Even though some of them have worked in that department for a while, they still didn't understand everything
They deal with so many tickets a day that it doesn't allow them to work on other assignments they have

At the end of the interviews, we asked for suggestions they might have to see how they would fix the problem. Many said, "Revamp the whole Portal/Scheduling System," and we definitely would if we could. Others suggested a "decoder" for the errors so they can truly understand what it means and how they can fix it.

With all the information we gained, I devised a Buddy system to guide the users through this confusing platform to help them understand and how to proceed past error codes.

Examples of what the stakeholders were looking for

Understanding Flow

For the first idea, I wanted to take advantage of the web browsers they were using, which was Google Chrome, and with further testing, we found that they use some Chrome Extensions. Since all users would submit their schedule on a secure laptop/desktop that the RCMP set up, they already include specific Chrome Extensions installed.

This user flow represents how users traditionally apply for overtime pay and submit their schedule, but with the added Chrome Extension we created. With the Extension, users can search for the errors they encounter with the option to show the most common error codes.

Understanding What Users Find Intuitive, and Why

Low-fidelity prototype testing allowed me to understand better how users expected to complete the tasks I was focusing on. By clicks and misclicks — and more importantly, having a dialogue about what they expected and when — I knew which adjustments needed to be made to lay the foundation for a more fully realized high-fidelity prototype. Small details such as actionable and consistent iconography and consistent paths to get back would become essential elements of the design system.

Revision into Prototype One

The Chrome Extension would pop up when selected, showing any user-specific help and pinned FAQ about error codes or questions. We would get the user-specific help by "scrapping" the user data, which a Chrome Extension allows for. This would be the same as the actual programs but adding additional help.

A feature we decided to add to aid the users is a shift code calculator because users don't input traditional hours into their schedule but instead use codes to determine their start and end times.

The Home Page would allow users to search for articles about issues other people face and how to fix them.

Surfacing New Issues

The high-fidelity prototype brought test users closest to the real experience, revealing some issues. While we gained insightful information and user testing with this prototype, we faced a significant roadblock. We discovered a similar application was being created by an internal team and was "in the pipeline." Still, they have yet to progress in the last few months. This caused a significant issue for us as we were 2 months into the project with a majority of testing and research all done. Luckily, we could still use the insight we gained and proceed in another direction, but these parts of these prototypes can and will be used in new ideas we came up with.

(Clickable prototype to the right; please select full screen for the experience)

Another Potential Idea but...

While considering a Chrome extension, we had another idea on the back burner, and I decided to prototype it. So, the stakeholders and my team had a better visual understanding of it. We tried out a chatbox that would use AI to communicate with the users to help them with any errors they are facing or give them a tutorial on how to traverse through their current scheduling system.

Unfortunately, this would not be allowed because the secure network would not allow third-party applications to access anything within the private network. As this would be the perfect idea to solve all issues, it would not be available to us, but we still knew what couldbe usedin the future!