VITAL Premiums
A case study on high-constraint, iterative design.
What is VITAL?
Scheduling application that coordinates
Built “quick & dirty” on a RAD tool. Schema dictates the UI and, therefore, creates a solution with very limited UX flexibility. Corporate philosophy also prohibited caching, microservices, and other useful architectural elements.
Premiums Project
As a UX designer I partnered with the engineering lead and the product owner to address a recurring problem:
Situation: Shifts during high-volume call times were not getting filled
Problem: SVRS was failing to meet speed of answer and service level requirements
Implication: SVRS incurs losses (penalties)
Solution: Increase visibility and accessibility of Premium shifts
Research
Empathy Exercise
From time to time, agents will receive SOS emails from the operations team. I simulated receiving and responding to one of these emails. I had some immediate observations:
User Research
I hypothesized that finding and adding premium shifts was just too difficult. I tested my hypothesis by ...
Contextual Inquiry - I asked users to copy my empathy exercise so I could watch
Interviews - I asked about users’ experience regarding SOS emails and premium shifts
Key findings -
Design
Users & Personas
Operations staff worked so closely with the team on new features that I did not need a persona. I would refer to the individuals directly.
Victoria VI was my persona when working with most agents.
Story maps
“As an agent, when I receive an SOS email, I want to add premium shifts to my schedule, so I can help the company and increase my compensation.”
Receive SOS email from operations
Define which shifts/times are needed
Locate shifts I can take
Confirm premium amt. & work rules
Schedule shifts
Don’t show me shifts outside my center
Don’t let me schedule outside work rules.
Whiteboarding, brainstorming, etc.
Metrics for success
Delta in plus-minus for premium shift times
Button clicks (TBD upon UI creation)
Delta in avg. premium pay (week over week, month over month, etc.)
Don't break the database!
Work within IronSpeed (RAD tool) constraints
Get it done in 2 months
Wireframing & Prototyping
Premium Management features
Design problem: Advertising ALL premiums ALL THE TIME throughout the ENTIRE APP was going to turn them into a nuisance. How to keep them relevant?
I designed the “Advertise” feature in addition to general premiums management. This would cause critical shift times to appear on the home screen and in an email notification.
“VIEW” button
A critical aspect of the Premiums functionality was making sure users could quickly and accurately pick up shifts.
I added a “VIEW” button next to advertised premiums on the home screen.
This took users to a filtered list of shifts that were:
Notating premium shifts
Design Problem: Available shifts didn’t align perfectly with premium hours. Sometimes a shift would overlap two different premium pays.
I used a value agnostic symbol on list views and expanded information on detail views.
Exclusion: I wanted to help users calculate their premium pay. Engineering couldn’t pull this off in our time and tech constraints.
Notating premium shifts
Why the green circle?
My original assumption was that users would want to see the dollar amount in a list view of shifts. I was right, but this feature would double project timeline.
Next I tried green “dollar signs.” This failed user testing. As various agents and managers tested my prototype the general reaction to the dollar sign made them “feel icky”
Trying to get to to testing other features, I just put a green circle. Unexpectedly, users responded very positively. I still hate it, but it passes user testing and moves the needle on metrics.
Mobile-friendly version
Our not-so-friendly mobile version was updated as well.