I was the main designer for an application called Smart Locator. This application helps insurance agents match their clients with a car repair center during first notice of loss.
Smart Locator: Scheduling feature
User persona for a claims representative.
Problem
Users wanted to schedule appointments in our application.
Our application did not have a feature for users to schedule an appointment with their chosen repair center at first notice of loss.
Users wanted to schedule appointments in our application.
Our application did not have a feature for users to schedule an appointment with their chosen repair center at first notice of loss.
This meant that users had a secondary follow-up task to call the chosen repair center and schedule an appointment.
Data
I reviewed data to better understand feature utilization.
I took this opportunity to review data on which features were being least utilized during the selection process.
I reviewed data to better understand feature utilization.
I took this opportunity to review data on which features were being least utilized during the selection process.
The data showed that the "More details" button on a repair center's information summary was rarely selected, which influenced my design to ensure that available appointment information was not nested under the "More details" button.
Top image shows the "More details" button in an old design.
Bottom image shows feature usage for finding a repair center.
User flow showing where the scheduling feature could be added to the application.
User flow
Worked with project team member to create user flow.
With collaboration from my product manager, we created a user flow to identify the changes needed for this feature.
Worked with project team member to create user flow.
With collaboration from my product manager, we created a user flow to identify the changes needed for this feature.
This helped to solidify design requirements and helped my product manager plan for upcoming development work.
User testing
I tested a high-risk assumption using an A/B test.
At one point, I had two designs for an error flow. I created an A/B user test to determine which option was best.
Option A was the clear winner based on time per test, ease of use, and technical feasibility.
I tested a high-risk assumption using an A/B test.
At one point, I had two designs for an error flow. I created an A/B user test to determine which option was best.
Option A was the clear winner based on time per test, ease of use, and technical feasibility.
First task in user test.
Alterative scheduling option for full screen calendar.
Alterative idea design for time selection.
Error screen for user who failed to select option.
Current status
We have our goal defined for what would make this design successful once the feature is released
I worked closely with developers to create the first iteration and had the development team establish analytics to track how often this feature was being used. If at least 50% of users use the scheduling feature within our system, this would be considered a success.
To my knowledge the company has not rolled out this feature yet, so no analytics have been recorded.
We have our goal defined for what would make this design successful once the feature is released
I worked closely with developers to create the first iteration and had the development team establish analytics to track how often this feature was being used. If at least 50% of users use the scheduling feature within our system, this would be considered a success.
To my knowledge the company has not rolled out this feature yet, so no analytics have been recorded.
See the embedded prototype below to try out the new scheduling feature for yourself.
