Designing Key Tasks for a Training Management System
SEIU 775 Benefits Group is a non-profit dedicated to administering health, retirement, and other benefits to caregivers in Washington and beyond. They are also Washington state's second-largest educational institution by enrollment and provide training for hundreds of thousands of caregivers annually.
This case study covers how I designed low-fidelity wireframes of key tasks for My Benefits Resources, a web app that allows users to enroll and manage training on behalf of caregivers.
Hayley Jang, UI Designer
Context
Becoming a caregiver in Washington state involves extensive training and a certification exam. After getting certified, caregivers are required to complete 12 hours of training annually to maintain their status.
Caregivers can select and enroll in courses on their own, or with the assistance of third-party organizations. These role of these third-parties range from acting as support when technical issues or language barriers arise to completely managing and scheduling a caregiver's training for them.
Problem
The custom SalesForce plugin that SEIU 775 Benefits Group (BG) used to provide third-parties with access to caregiver training records was being sunset.
BG decided it would design and develop its own caregiver training management system, dubbed My Benefits Resources (MBR), as a replacement. Stakeholders wanted to start with a minimum viable product (MVP) version of MBR that supports 14 key user tasks.
In this case study, I'll be covering a portion of my contribution to MBR: the design of the new caregiver search page.
Discovery
There were three main user groups within the existing training management 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 BG Admins: Individuals across various teams within the BG who can perform services on behalf of other BG teams or caregivers
These user groups all had their own unique permissions and tasks so maintaining this access was critical to a successful launch. For the caregiver search page, this was simple as all groups had the same access level.
Our UX Researcher Sophie conducted user interviews with members of the three groups to better understand their experiences within the current system. She uncovered high level pain points that were shared across the user groups [Figure 1.3].
Common pain points within the current training management system
Define
Of these pain points, I noted two that seemed particularly relevant given the functionality and context of the caregiver search page:
Having to read through a lot of information
When the system presents too much information all at once, users experience cognitive overload and can miss crucial information or CTAs
Dealing with duplicate caregiver profiles
If a user is not able to successfully search for a caregiver—either through user error or system failure—a duplicate profile may be created, which clutters the database
I used these two pain points as guiding principles throughout my ideation phase. This enabled me to center my work around the user and drove the majority of my design decisions.
Ideation
I used the design and flow of the current caregiver search page as a starting point for my ideation. This simplified my process as it ensured that whatever I designed kept feature parity and allowed me to focus on making direct improvements to the overall user experience.
I began by cleaning up the existing UI to improve visual hierarchy and reduce information overload [Figures 2.1 + 2.2]. This concentrated on three core issues:
- Displaying more information than is currently needed
- Excessive white space between page elements
- Redundant UI elements that add visual clutter
UI issues present in the existing caregiver search page
Mockup of current caregiver search page with all UI issues removed
Search Fields and Requirements
In the current system, users are presented with 7 possible input fields for making a search. Some of these fields must also be used in a specific combination to make a valid search query [Figure 2.3]. Encountering this list of requirements and the many input fields can be an overwhelming experience, especially for first-time users.
To minimize this cognitive strain, I developed a new way of presenting the search requirements and input fields to users [Figure 2.4]. This involved grouping the fields into sections based on their accompanying search combination requirements and dynamically highlighting required fields based on the user’s initial input.
Search requirements and input fields in the current system
My proposed revision of the search field
Search Results
My design for the search results was comparatively simple. I attempted to improve the readability of the results by removing visual clutter, aligning the Related and Unrelated tables, and adjusting the white space within the rows [Figure 2.6].
Search results as they appear in the current system
My proposed revision of the search results
Adding Caregivers
Certain users also have the option to add new caregivers to the database from the search page. The button for this is hidden and only appears after a user makes a search, to help prevent the creation of duplicate profiles. However, very little information is provided about this in the current search page [Figure 2.7].
To improve this, I added the following helper text to the Empty state and the Search Returned state of my new search page design [Figure 2.8].
No instructions for adding caregiver in the current page
New instructions for adding a caregiver, before & after searching
Putting It All Together
After coming up with ideas to address the various problems within the existing caregiver search page design, I combined them all to create a low-fidelity mockup of how caregiver search would look and function within the new system [Figure 2.9].
Low-fidelity mockup of the caregiver search page for MBR
Iteration
Once I mocked up my design on a frame scaled to our target screen size, I realized that I had made an oversight. There was only enough space to display 3 search results above the screen cutoff, which was much lower than the existing design's capacity [Figure 3.1].
At a loss for what to do, I reached out to my teammates for advice. They suggested a sidebar search layout—an option that I had completely overlooked. I had been so focused on working within the bounds of the existing search page that I hadn't explored alternative layouts.
After some tweaking, I reached my next iteration. This design was able to display more than twice the amount of search results above the fold than my previous one [Figures 3.2, 3.3, 3.4].
Only 3 results visible when viewed on 1366x768
Revised page layout with search field sidebar
Revised page layout with search sidebar (empty state)
Revised page layout with search sidebar (search state)
Usability Testing
During my work on MBR, I got the opportunity to conduct internal usability testing with 8 participants. These tests focused on whether participants could successfully complete all 14 key user tasks across my designs for the entire training system.
While testing my caregiver search page design, all 8 participants successfully completed their tasks. Even more interesting though was some feedback we received regarding caregiver creation:
- During testing, one participant expressed disapointment that the requirement to make a search before creating a new caregiver profile was still present
- The same participant mentioned that they would sometimes make a "throwaway" search just to get to the create caregiver button
- After learning of this, we asked the following 3 participants about the current profile creation flow and received similar sentiments
Final Iteration
After discovering this discontent over the imposed friction of the profile creation flow—as well as several new requirements that I received from stakeholders—I revised my designs accordingly [Figures 3.5 + 3.6]. These changes included, but were not limited to:
- Search field combo requirements no longer apply in the new system
- Added additional columns in results table for easier caregiver identification in light of the new possible search queries
- Improved sidebar layout with additional filters and option to clear all fields
- Added the option to create a new caregiver without making a search first
- Combined Best Matches and Similar Matches tables
Final delivered wireframe for Caregiver Search (Empty state)
Final delivered wireframe for Caregiver Search (Search returned state)
Additional Wireframes
Selection of additional final delivered wireframes for MBR
Outcomes
Unfortunately, after almost a year of working on the project, leadership decided to put the My Benefits Resources project on hold. I did not have the chance to see my designs implemented or measure the impact I made.
Had we continued, there were several metrics that I would want to monitor in order to evaluate whether my designs met the original objective:
Task success rate
In our usability testing, we had a 100% success rate with my caregiver search page design. I would want to test this again with my finalized design and at a larger scale with more participants across all user groups.
Error rate
Amount of duplicate profiles created, failure to find a caregiver that exists in the system, or times a user accesses the wrong profile after making a search could all be interesting points to track.
User satisfaction
This could be measured with a brief satisfaction questionnaire or a follow-up interview asking users whether pain points from the old system are still present within the new system.
Reflection
This was one of the longest continuous projects that I have had the privilege to work on and it was filled with learning lessons. Some of my main takeaways were:
Leave no stone unturned
Take the time to generate and explore as many ideas as possible when tackling a design challenge, even if there is an existing solution.
The more the merrier
Get feedback from others as often as possible to promote a diversity of ideas, eliminate personal biases, and prevent tunnel visioning.
Set your workspace up properly
Identify and use the proper screen, font, and UI element sizes for all design work, even in the early exploration stages, to prevent incompatibilities later on.
