Transaction Tracker

The Premise

• At Plansource, Our primary product is a Benefit Administration Platform.
• With healthcare costs in the U.S. being so high, employer-provided insurance is very critical for employees. We act as the central hub connecting benefit vendors with companies and helps them enroll to benefits each year.
• These enrollments would typically have enormous amount of API transactions
• A single failed transaction can mean a total loss of coverage, turning a manageable healthcare need into a financial crisis for an employee's family.
• After one of the enrollment seasons, when too many tickets were raised like these, from product side we decided to look into the issue and figure out a feasible solution.

The Problem

• Previously we didn't have a way to monitor all the transactions.
• If a transaction didn't go through, users might identify it at a later stage and raise a support ticket.
• Our inhouse support team then had to manually go through each of the separate databases find the issues and rectify it.
• This was a painstakingly hard process.

Users

Our primary personas included External and internal support team members. The secondary personas were internal development team members.

The Process

Initial Research

• Even though we hypothesised that the problem as real and required action, we had to validate this.
• So we decided to start the project by interviewing our internal support team.
• We tried to understand their current process, how they were handling support tickets regarding the transaction errors and how beneficial it would be for them if we introduced a tool like this.

Initial Proposal and Stakeholder Approval

• We submitted our proposal and findings to the leadership.
• We also shared the overwhelming response we received from the support team on this proposal.
• The stakeholders understood the benefits like OPEX reduction and proactive error reduction, shared their insights about the project and agreed to make it part of the upcoming quarterly planning.

User Research

• We went back to users to design the solution. Revisited their daily workflow.
• One key insight was that they were more concerned about transactions that didn't go through vs the ones that did.
• We listed out different errors that could happen and how probable it was to happen.
• We also figured out the severity and how they handled each of these type of errors.
• We checked what was the data they wanted to see in each of these scenarios and what realated actions could be automated from the systems side.
• Next we did a card sorting excercise with the data they mentioned and tried to figure out if all of them were essential to be viewed as well as in what order.

Looking for Inspiration

• We looked for similar systems in our competitors. But the resources were limited in their internal tools.
• Since it is a way to showcase status of some entries that was needed we investigated other similar applications outside our domain as well across internet.

Ideation

• Once we were clear of the requirements we started exploring ideas for the same.
• We reworked the expected userflow to focus on the errors to make the process more proactive than reactive and discussed it with the users.
• Users were pretty positive on the same.
• For a flow like that we figured out a dashboard approach would be better.But at the same time we should be providing user capability to search and reach a particular transaction easily.
• Our solution was to incorperate both in the dashboard.
• There would be a summary section which would give a top level view of the transactions.
• Then there would be all the transactions listed below which could be searched or filtered upon so that users could easily drill down to particular transactions easily.
• We also created secondary flows and edge cases based on these.
• Finally we presented our findings to the key stakeholders and users and got inputs.
• Then we elaborated the flows and came up with the base UX design as wireframes.
• After that we user tested the wireframes using an unmoderated study with 5 users in userlytics to figure out the bottlenecks in the flow.

Design

• Next we followed it up with the visual design.
• For heavy data application it is better to keep the design simple and minimal so that it doesn't overload the user.
• We already have a design system in place which abides by that principle. So styling was already defined.
• The UI was then prototyped

Usability Testing, Handover and Follow up

• To validate the designs and the prototype was thoroughly tested with internal and external users in a moderated manner.
• Based on the testing there were minor amends done like fixing some columns in the table of transactions, adding more filtering options etc.
• Finallly the designs were shipped for development. The implementation once done was again checked by us.
• We also followed up with users and collected their feedback, which were generally positive except for some minor hiccups in edge cases.