Submission Editing
The Project:
The goal of the project was to allow agents to edit their own submissions in the Partner Portal at Pie. Prior to this, once a submission was finished, any edits had to be sent to our underwriting team to manually update the submission, even if it was not an update that would result in a price change.
My Role:
For this project I had the responsibilities of Product Designer and UX researcher.
The Process:
Discovery:
The first step was to pull all of the possible end points (called decisions) at the end of a submission. There were three possible decisions: quoted, referred, or declined. Each of these options had different actions that we offered to the agent. Each page also had differing amounts of content.
I reviewed the Journey Maps that I had created before to see if there were other pain points that would be addressed by working on this project. I saw that this should be able to help if an agent entered incorrect info (especially if they didn’t have that info at the time of the quote), as long as we allowed them to edit declined quotes as well.
Prior Screens, with all possible combinations of decisions an agent could get on a submission. Each decision has different content shown and different actions possible on the screen
concepting
This was one of the first project that we wanted to start sharing code across applications, so I pulled inspiration from the underwriting system to see if the dev team could re-use that code. For the proposal, first I had to review to see what fields wouldn’t be shown from the main screens. I also had to decide what would be most applicable to our agents in the floating side bar.
Floating sidebar that underwriting uses to see the most important info to them. This sidebar follows the user down the page.
Early concept of what this could look like with what info would not be shown to our external users
UX testing
This project was up against a deadline, and was running behind schedule, so the buffer we had originally scheduled for usability testing of this project with agents was quickly absorbed. Due to this being a complex project the plan was to test with agents once a lot of the flows were built into our test environment.
I pivoted and recruited internal sales reps (many of whom came from agencies themselves) and had them walk through the prototype with myself setting the scenarios and confirming they could find the info they needed.
I also did schedule agents to usability test the flow about a week before launch when the build was mostly stable. The main goal was to find if there were any show stoppers that had to be fix before launch and identify ways to improve the flow after launch.
Concessions made
One of the biggest changes we were making, was having our partner portal talk back and forth to the underwriting system. The problem is that some of our policies were on a legacy program that didn’t talk back. If we were to allow the users to edit in those cases, it might overwrite any of the work that our UWs had done. We then made the decision for the sake of the timeline to lock editing if an UW had worked on the file in one of the legacy systems.
What the users would see if an underwriter had edited the file.
FLOWCHART
Flow for devs for all of the versions of the file. Miro link
Final Mocks
All of the flows mocked out for the Dev team in this beast of a file. This was done in Adobe XD, so all of the screens are on the same page. There was a table of contents page so you could jump to the flow that you wanted to focus on.
Final Results
Slide created by presented to management on results after 37 days.