I was tasked to design a new rules engine for revenue cycle back office users. Currently, Information Systems Analysts primarily write the claim rules that are requested by Business Analysts, which causes some process problems.
Our Users
Back Office Managers, Business Analysts, Analytics Managers and Information Systems Analysts
Problem
The current tool requires technical coding skills. In most cases, business analysts can only submit work requests for rules to be created, this is due to how complex and developer centric their current tool is today.
There is a gap between the Billing Language vs the Rule Builder Language. This causes confusion when business analysts submit a request and how the IS Analyst interprets it.
Our Goal
Our goal for this project was to bridge the rule building gap between business analysts and IS analysts by redesigning a more flexible rules engine. I was assigned the task of designing a Claim Rules Engine, while keeping in mind that all other teams implementing a rules engine going forward, would follow the pattern that I would define. This included:
Primary Navigation
Secondary Navigation
Change Management
Adding a Rule or Folder in a Tree structure
Moving a Rule
Rule Expression Builder
User Interviews
In order to start on the right foot, I teamed up with a user researcher from the Human Factors team. We started by interviewing users using their current rules engine solution. We interviewed back office managers, analytics managers and other IS analysts who write the rules. Below are some of the questions that we asked:
“How often is this tool used?”
“What context is it used in - daily tasks or crises situation?”
“What is the purpose of the tool?”
“What are the advantages of an analyst using it vs other employees?”
“What are the current tools used to make these decisions?”
“What are the pain points associated with the existing tools?”
Pain Points Discovered
Business Analysts
Terminology is difficult - translating and comprehending business language vs development is a challenge.
Communicating rule requests to IT is time consuming.
Managers:
Terminology is difficult - translating and comprehending business language vs development is a challenge.
Communicating rule requests to IT is time consuming.
IS Analysts:
Terminology is difficult - translating and comprehending business language vs development is a challenge.
Education - Would like more dynamic examples of rules
Needs a way to search for a rule
Overall look and feel of current rules builder is “stuck in 1995.”
Process Flow Chart
The interviews provided us with in depth knowledge of each users process. We learned how managers and business analysts deal with billing issues today, as well as an Information Systems Analysts process when receiving a billing issue rule request.
Personas
I designed a persona for Business Analysts, who were our primary users. The main takeaway from our Business Analysts were that they wanted control to write rules as well. They understood that complex rules would always be assigned to the IT staff, but if the rules engine was designed to allow non technical users to write simple to medium level rules, it could save a lot of time and wasted meetings for all teams (thus increasing revenue). Increasing education, documentation and bridging the terminology gaps were the main takeaways from the Information Systems Analysts, who were our secondary users.
User Flows
To make sure there were no dead ends in the user’s interaction with the solution, I sketched the main User Flow, which helped me to detect all possible actions done by either the user or the computer. Mapping the basic flow of the app forced me to figure out each step the users would take throughout the solution.
Low Fidelity Wireframes
The user flow allowed me to begin laying out each design in its simplest form. Creating low fidelity wireframes helps me design the workflow first vs what the feature looks like. Low fidelity is also beneficial for testing ideas with our end users. Since this was a large feature, I broke down the feature in 3 phases...
The Core (Navigation) - This is where I began. After hearing the pros and cons of deploying rules to production environments from our IT users, I was able to tailor the workflow closer to their process.
2. Folder Management - The main goal here was to make sure I designed a tree that allowed users to add folders or rules, copy, move and delete. A future feature that will be added is drag and drop to provide a more efficient and intuitive experience when moving rules.
3. Writing a Rule - This UI consisted of writing a qualification (Does this rule qualify?), writing an action (If the rule qualifies, this is what happens), and sometimes writing an alternate action (if all else fails, use this action) as well.
High Fidelity Wireframes
The next challenge was designing the high fidelity UI’s. The original UI was created on a different UI codebase. As a UX goal, we pushed teams to move into our new front end code base in order to create consistency. This was a challenge as, I had to make sure the new UI library had everything my team needed in order to develop my designs.
Next Steps
Conduct Usability Studies
We will continue to conduct usability studies until the feature is available to clients in the Fall of 2019.
Improve efficiency
Build upon Move Functionality - Allow users to Drag/Drop inside our tree component
Add Search Capabilities to easily find a rule
Build upon Copy Rule Functionality
Takeaways
Even though I was only designing for a “Claim” Rules Engine, I had to make sure the decisions that I made for my design patterns were flexible for other Rules Engines created in the future. In fact, other Rules Engines are currently in development and it is exciting to see that those teams are adopting my UX patterns.