Project Staff Research
Context
When a user has certain medical complications, our support team was required to call that user directly for additional details.
​
Problem
In order for our team to process the medical bills, the user is required to explain in thorough detail what went wrong. Some of these medical complications are rather touchy and emotional topics causing a great deal of emotional distress for our users to relive while also putting our support team in a difficult position of asking invasive questions. ​
​
Short-term Goal
Understand the current bill process system and why it exists.​
​
Long-term Goal
Limit the amount of phone calls our support team is required to make and to find an alternative solution to gather the information we need from our users in a less intrusive manner.
Context
Stage of Research
-
Discovery
-
Exploratory
-
Testing
-
Listening
Methodologies
-
​IDI (In-depth interview)- 30 Minute remote sessions via Microsoft Teams
-
Tree sorting
-
Prototype testing
Participants / Criteria
-
8 Staff members
-
6 Support staff
-
2 Team leads
-
-
Criteria​
-
Had experience calling users regarding these medical complications
-
Contributors
-
Stakeholders- Bill processors, current members, and support staff
-
Research requester- Director of service delivery
-
​Communication- Team leads
-
Note takers- Design team
-
Moderator / planner- Myself
Executive Summary of Insights
Testing Assumptions / IDI Insights​
-
Current process
-
The information we received from leadership for "current medical complication process" was alarmingly inaccurate​​​
-
-
Desired state
-
Leadership assumed getting rid of the phone call process altogether was the end goal for supporting our staff, however, research invalidated this assumption​
-
​
Prototype Insights​​
-
Follow up questions
-
Our support staff pointed out scenarios in which the proposed prototype would need adjusting
-
-
Terminology
-
​Support staff pointed out potentially "harsh" language shown in the prototype
-
Planning
Scope
​​
-
Understanding goals- Scheduled a meeting with our stakeholder to understand their goals, the "whys"​, and any constraints to be aware of. Additionally, determine why the current process is the way it is.​
-
Success metrics- Worked with stakeholder and designers to determine what we would use to define this study as a success or failure.
-
Methodologies- Determined the appropriate methodologies. In this case, an IDI with support staff to understand the current process and pain points, and lastly, a prototype test with our support staff based off their feedback from the IDI.
-
Constraints- Leadership set forth certain business requirements that affected what could and could not be adjusted within the proposed design changes.
​​
-
Criteria- Determined participant criteria.
-
Identified users- Utilizing our list of support staff and working with BI (Business Intelligence), we identified a group of staff who have past experience with calling users regarding medical complication.
-
Understanding problem areas- After conducting IDI's with our staff, we were able to access how the current process works and why it exists.
-
Understanding specifics- During the IDI's, were identified specific pain points and areas for improvement.
-
Distribution- Requested to speak with 10 staff members.
-
Recruitment- Recruited 8 staff members of which conducted both the IDI's and usability testing.
Recruitment
-
Questions- Based our IDI questions to answer the success metrics determined in the scope phase.
-
Follow up- Leveraged insights discovered from the IDI's to inform our prototype design which we presented to the same support staff afterwards.
Moderator Guide
Insights / Impact / Outcomes
IDI Insights
1. Current Process
Problem- When starting this process, leadership provided us with what they believed to be the current process for how our support staff handle medical complications. However, after conducting IDI's with our staff, we discovered the actual process was much different from the information we received.
Perceived Impact Rating- High
Outcome- Using the information we discovered in the IDI's, we were able to visually map out the current process based on scenarios / potential answers from our users. From here, our design team created a prototype based on the feedback received.
2. Desired State
Problem- Using the information we discovered in the IDI's, we were able to invalidate the assumption from leadership of deleting the phone call process was better for both our staff and users.
Perceived Impact Rating- High
Outcome- We identified our support staff truly desired was a better overall experience for our users. This meant leaving the ball in the users court for how they would prefer to provide us with necessary information, whether that was a phone call, done within their account, or an email.
​​
​​
Prototype Insights
1. Follow Up Questions
Problem- After our design team created a prototype with potential solutions to better serve our support staff, we conducted a usability study with the same participants from our original IDI's. During this testing, our support staff pointed out scenarios in which the proposed prototype would need adjusting to account for specific scenarios we had not considered.
Perceived Impact Rating- High
Outcome- Based on the feedback received, our design team adjusted the prototype to meet the needs of our staff and users.
​
2. Terminology
Problem- While our team focused more on the application side of the prototype, our support staff pointed out some potentially "harsh" language for our users.
Perceived Impact Rating- High
Outcome- After receiving feedback and suggestions from our staff, our design and communication team worked together to adjust the language as needed. ​
Prototype / Tree Sorting Results
.png)
Before
After
Business Requirements
#1-6
Retro / Lessons Learned
Validated / Invalidating Assumptions
Problem- While we asked for the current process during the initial stakeholder meeting, we assumed this to be true. It was not until we spoke with our support staff during the IDI's that we learned what we thought was true was actually highly inaccurate. This made for a lot of re-work to be done with the prototype design with a limited amount of time to correct it before our usability study.
Opportunity for Improvement- Researching / using other resources to determine the validity of stakeholders' assumptions prior to starting research sessions.
​
Mythologies- Listening to Phone Calls
Problem- We assumed we could better understand pain points from both our users and staff by listening to recorded phone calls regarding medical complications. While we did find some insights, the majority of insights we aimed to understand were actually found during the IDI phase. This caused our team a decent amount of time wasted that could have been better allocated elsewhere.
Opportunity for Improvement- In the future, rather than putting a lot of time and effort into an assumed resource, asking those that are familiar with the process what resources they would suggest we explore.
​
​