Designing A Training Management Tool

SEIU 775 Benefits Group is Washington state's second-largest educational institution by enrollment and provides training for hundreds of thousands of home caregivers annually.

This case study covers how I designed lo-fi wireframes for the MVP launch of My Benefits Resources, a web app that allows users to enroll and manage training on behalf of caregivers.
Role: UX Designer
Tools: Sketch, Invision
Methods: Wireframing, prototyping, usability testing
Duration: 12 months (July 2020 - July 2021)
A computer monitor displaying a high-fidelity wireframe of the My Benefits Resources caregiver dashboard

Background

Becoming a home caregiver in Washington state requires the completion of several extensive training courses and a certification exam. After becoming certified, caregivers are required to take 12 hours of training courses annually in order to maintain their certification.

While caregivers can enroll themselves in these courses, sometimes assistance is required due to technical difficulties, language barriers, or because their employer manages training for them. In these cases, a third-party—such as employer agencies or help center reps—will access a caregiver's training records to relay information or perform tasks on behalf of them.

The Problem

The SalesForce plug-in system previously used by the Benefits Group to provide third-parties with access to caregiver training records was being sunset by its owners. Years of customizing this plug-in to communicate with multiple data pipelines and accommodate unique use cases meant that the Benefits Group was hard-pressed to find a suitable alternative that would work "out of the box".

To solve this, the Benefits Group decided to design and develop its own caregiver training management system. This came to be known as My Benefits Resources (MBR).

The scope of this project for my team was to provide our Tech department with UX research, UX/UI design, and consultation as needed for the MVP launch of My Benefits Resources.

My Role

I led the design of the information architecture, low-fidelity wireframes, and prototypes. I also collaborated with our UX Researcher and UI Designer at various points throughout this project.

I worked on MBR from July 2020 until July 2021, when the project was put on hold by senior leadership due to other urgent projects and unforeseen circumstances arising.

My design process for this project is outlined below:

Discovery

Because I had no experience using our current training management system, I scheduled a walkthrough with a coworker who was able to get me up to speed. In the process, I learned of the three main user groupa within this system:

  • Employers: Agencies that employ caregivers and manage their training, client assignments, and more
  • Member Resource Center (MRC): An SEIU 775-affiliated support center that caregivers can contact to ask questions and get assistance with issues involving training, healthcare, and benefits
  • SEIU 775 Benefits Group (BG) Admins: Individuals across various teams within the BG who can perform services on behalf of other BG teams or caregivers

In addition to these three groups, there were also several sub-groups within them, each with their own unique set of permissions as well. Ensuring all groups retained the same permissions in the new system was critical to a successful MVP launch.

To stay keep track of all this, I created a spreadsheet that listed out each feature required for the MVP version of MBR and whether or not a user group had access to the feature. This information was collected through work that our UX researcher had done and additional stakeholder conversations.

Truncated chart of user permissions for various user groups, access indicated by Y/N

Once finished, I shared this spreadsheet with the Tech team and other stakeholders to review. Throughout the project, I returned to this spreadsheet to update it with any new info that was uncovered through additional research and conversations.

I also created high-level information architecture diagrams for the three main MBR user groups. This was done by building off of a diagram of the current system that a product owner provided to me.

IA diagram for the Employer user group

Define

While I was working on the User Permissions Spreadsheet and IA diagrams, our UX Researcher had been conducting user interviews with members of the three main user groups and gained insight into their pain points, wants, and needs.

Below are high-level summaries of her findings:

Armed with the permissions spreadsheet, information architecture diagrams, and these UX interview findings, I was ready to start designing.

Design

In this section, I will be focusing on my design and iterations of the "caregiver search" feature. Screenshots of my designs for other MBR features can be viewed at the end of this section.

Searching for a caregiver is the first step for almost all of the user flows within My Benefits Resources. It is also a feature that all user groups have access to. As such, it was important for me to reduce any friction found within the existing search experience.

To begin designing the new caregiver search feature, I started off by reviewing the design and functionality of the search feature in the current system.

Caregiver profile search feature in the current system

After that, I began ideating and experimenting with different ways to design the search feature. I kept the pain point of "information overload" in my mind and tried to explore different ways of simplifying the search experience.

Caregiver Search: Initial Design Ideation

Option A: Search results are displayed on the same page and updated every time the user clicks the Search button. If there are no results, the user sees a Create a new student button.

Option B: Search criteria are separated by related groups and are hidden until expanded to help with information overload. Name (or the most popular used search fields) are expanded by default.

Option C: Most popular search fields shown by default. Others are hidden until expanded.

Option D: Users choose what type of search they want to make. Shows them all the potential search criteria.

Option E: “One size fits all” search bar that takes any query and shows the most relevant results based on the type of information entered.

While exploring these potential designs, I encountered several important questions that influenced how I should design the search feature and what limitations to consider:

  • What are the most helpful Caregiver Information fields to display in the search results?
  • What are the most frequently used search fields by current users?
  • Should users be forced to make a search before being given the option to create a new Caregiver?
  • How strictly do the search instructions/criteria need to be followed?
  • Is it possible to combine the search fields into one all-encompassing field?

However, until I could connect with someone who could actually answer my questions, I decided to play it safe and follow the limitations of the current state as closely as possible to ensure that my designs would be technologically feasible. Because of that, I chose to move forward with Option A and began to explore it further.

Caregiver search Option A

Caregiver Search: 1st Iterations

I continued to iterate upon my work through design critique sessions with my teammates and gathering feedback from them.

Option A: Search results are displayed on the same page and updated every time the user clicks the Search button. If there are no results, the user sees a Create a new student button.

Option B: Search criteria are separated by related groups and are hidden until expanded to help with information overload. Name (or the most popular used search fields) are expanded by default.

Option C: Most popular search fields shown by default. Others are hidden until expanded.

After several rounds of refining, I eventually settled on a design that I was satisfied and ready to test with during our first round of internal usability tests. Below is the design that I chose to move forward with.

Caregiver Search: 2nd Iterations

I chose this design because in addition to it being the most similar to the current state's design, I felt that having the search fields above the results instead of side-by-side with them would allow for more white space, improving readability and reducing information overload.

We conducted our first round of usability testing with 3 participants and a second round of testing with 5 participants. All of the search-related tasks that we had participants perform were completed successfully, however there were still actionable issues to address based on what we observed and the feedback we received. Some of which surprised me. This included:

  • Users appreciated being able to filter for inactive and active caregivers and that they are both enabled by default
  • One user did not notice the search result when it returned "0 caregiver(s) found"
  • The "Create New Caregiver" button shows up below the fold in laptop view and requires users to scroll down first to access it
  • First and Last name should be separate search fields instead of combined into a single field

What surprised me the most was the "Create New Caregiver" button showing up under the fold. I had been designing on a larger external monitor so this issue flew completely under my radar and I'm glad that I was able to catch it.

I took these findings and applied them to my designs for the 3rd and last iteration of the caregiver search wireframes before the My Benefits Resources project was paused indefinitely.

Contrary to my previous opinion, I determined that a design where the search fields are side-by-side with the search results would be the best way to address buttons showing below the fold and users missing the messages in the search results area. To compensate for this loss of horizontal width, I removed some of the information presented in the search results as it seemed there were already enough unique identifying information to help users find the exact caregiver they are looking for.

Caregiver Search: 3rd Iterations (Final)

Additional Final Wireframes

Option A: Search results are displayed on the same page and updated every time the user clicks the Search button. If there are no results, the user sees a Create a new student button.

Option B: Search criteria are separated by related groups and are hidden until expanded to help with information overload. Name (or the most popular used search fields) are expanded by default.

Option C: Most popular search fields shown by default. Others are hidden until expanded.

Option C: Most popular search fields shown by default. Others are hidden until expanded.

Option C: Most popular search fields shown by default. Others are hidden until expanded.

Option C: Most popular search fields shown by default. Others are hidden until expanded.

Reflection

If I Had More Time...

If I were to continue work on this project, I would want to work with our UX Researcher to evaluate the information architecture that I proposed. The IA was While nobody voiced issues with the user flow or design layout during usability testing, that does not mean that what I designed is perfect.

A method like card sorting, where I could have users organize information and pages into groupings that make the most sense to them could help validate (or disprove) my design choices. This could also provide insight into how the information on the caregiver profile pages that I designed should be presented. There is a huge amount of information that exists on the profile pages and I only them based on what made sense to me and my assumption of what would make sense to the users.

Thank you for reading!