Project type: Design project at MineralSoft, Enverus 
Project length: 4 months
My role: Product Designer 
Collaborators: Product manager, developers, (internal) operation team members, customers
What is MineralSoft?
MineralSoft is a mineral management platform for oil & gas assets. Our customer base includes banks, investment funds, family offices, E&P companies, government agencies, and universities. We help the mineral managers understand their portfolio, audit revenue, and analyze the cash flow. These activities can help our customers keep a tab on their investments and impact their acquisition & divestiture decisions.
MineralSoft's Sustainable Advantage
One of the big reasons for choosing MineralSoft is our integration with EnergyLink. EnergyLink is a product in Enverus that provides customers access to digital revenue statements and JIB invoices that they would otherwise receive in the mail or from individual operator portals. Revenue statements and invoices tend to be formatted differently by every oil and gas operator and can be challenging to interpret. However, Energylink works with 90% of the oil and gas operators in the US and can provide standardized and easy-to-understand statements. 
How MineralSoft provides revenue data
Revenue statements sent from EnergyLink customers/operators automatically flow into MineralSoft as soon as they are received and processed in EnergyLink.
If customers receive any revenue statement from out-of-network operators, they can upload a statement to MineralSoft. If it is a paper copy, they will need to scan and create a PDF. We will process these statements with three days SLA. 
Project Context
When I joined MineralSoft, a new module to process revenue was just released. Two new features aimed to help the bank customers were posting workflow and check reconciliation: 
1. Posting workflow: 
Since banks required more scrutiny in their process and control over data, they asked that statements be "unposted" by default. Unposted statements require review and manual posting by customers. Previous to posting, they will not show up in any of our revenue-based reports. Once posted, banks will up-feed the revenue data into their systems so that they can make the deposits to their customers accordingly.
2. Check reconciliation:
Mineral managers receive paper checks from the operators. They will need to keep track of these checks as they make the deposits and ensure that they have the revenue detail statements that correspond to the checks. Managers held a record of them in Excel previously. MineralSoft introduced a feature to create a check record so that the mineral managers can see if the corresponding statements to the checks exist in the system.
Design Challenge
When I came in, the user experience of these additional workflows was less than ideal. I heard those newly onboarded customers were confused about where to go and how to complete their tasks. I set out to re-design the revenue processing workflow so that it would be more intuitive. In addition, it would be an opportunity to reduce the number of support and training calls.
Here are the original designs before I made any changes:

The "Incoming Revenue" page served as a place for all unposted checks and check details to live,
except for the "Recently Posted" tab. (Before design)

All posted statements showed up on the "Revenue" page. (Before Design)

I talked to the product manager and developers to understand the reasons behind the current implementation. I learned that the reason for the split of two pages was a technical one. MineralSoft has an account switcher on the side navigation menu, from which you can change the account. However, the new module aspired to accelerate the bank customers' daily jobs by allowing them to drop checks to all accounts from one place. So, the new page, "Incoming Revenue," made this possible. 
Even though you are in "Benchmark Fund IV," you can see all accounts in the "Incoming Revenue" table. In the "Revenue" table, you only see the "Benchmark Fund IV" account's statements.

Quick Research
​​​​​​​To dig deeper into the revenue processing workflow, I met with four operations team members separately. Since they train and support our customers every day, I knew they had a good perspective on our recent releases. Using my test account, I asked them to complete the following tasks & answer questions. 
1. Create a check
2. Find a check that is matched with check details
3. Post a check
4. Add a check to the check details that are missing check
5. Find scans with errors
6. Delete a check
7. Delete a check detail
8. Explain what each tab is about
9. Explain the difference between the page "Incoming Revenue" and "Revenue."  

I compiled my notes with some color coding and presented them to the product/engineering team. Among all the excellent feedback, what stood out to me was the excessive number of tabs and pages. Navigating through different tabs was confusing and time-consuming because of the time it took to load the data.

Working documentation that I shared with my team

Design Iteration
Next, I worked on the improvements to the Revenue module. I got feedback from the product/engineering team, operation team members, and two customers who were using the Revenue module in production.

First Design Iteration

Here is the first iteration that I presented. First, I removed the "Incoming Revenue" page altogether. Then, I introduced two columns, Checks and Check Details. These columns indicate the status of each object. Users can post when checks are in the "Created" status and check details are in the "Received" status.
While I received positive feedback from customers and operations team members on this design, the engineering team told me that this was not feasible to implement. The design mixed too many existing tables and created a considerable challenge. 
After multiple back and forth with my engineers, this is the final design we compromised.

Revenue / Unposted / Check Details

Revenue / Unposted / Checks

Revenue / Posted

The primary set of tabs define the workflow from Processing to Unposted, then finally Posted. Under the Unposted tab, you can see a list of checks and check details. We still added the status for each object, so the call to action was more apparent. 
One downside for this design was that the status column added more width to the table and thus led to more horizontal scrolling. It's not ideal, but I think the compromise is worth it to add clarity in navigation. 

Final Thoughts
Since the new release, we have received positive feedback. Customers find our platform much easier to navigate. They found it a huge time saver not to go back and forth between two pages. Plus, the clear status of the checks and check details was helpful to know what's going on. 

"I like everything being on this page where we don't have to toggle back and forth so much. It's much cleaner looking!" - Quote from a customer
Unfortunately, we didn't tackle the anti-design pattern that we created, the Account column on the Revenue page. This issue remains a problem to address because, ideally, the account name on the side menu should match the information in the table. A good solution would be to have an "All Account" option in the account switcher. When this option is selected, we will display information across all accounts, and a user will be able to filter down to the specific account if they want to. 
Another concern that the engineering team brought up is the amount of data the cross-account Revenue table would accumulate over time. Again, we don't want to diminish the performance of the table. So, in the next iteration, we resolved to add the time filters and, by default, only display the revenue data from the last 12 months. 
Some of these new ideas are not tested with users yet, so we need to validate that they are reasonable solutions. We will continue to monitor the usability issues as we onboard more bank customers. 

You may also like

Back to Top