Lab Management System - Invoicing

Lab Management System (LMS) is a new internal app intended to replace legacy systems that our manufacturing departments have been using for decades. One of the main features of LMS is what I worked on - invoicing.

Role

  • Lead UX designer

Processes

  • Contextual inquiry

  • Usability testing

  • Prototyping

Team

  • 10 software engineers

  • 1 product owner

  • Shipping department manager and supervisor

When

2021-2023

Background

Billers invoice orders before they are shipped to customers. During invoicing, billers have the responsibility of:

  • making sure that all products in the order are properly in the package and meet the quality standards

  • selecting the appropriate shipping method for the customer

  • checking that all appropriate itemizations are in the invoice (e.g. shipping fees, discounts if applicable, any product add-ons, etc.)

User Problem

The billers had one main problem - with legacy systems, they were juggling two different apps to invoice orders and they had to memorize which products had to be invoiced in which app. This obstacle was unnecessary, arising solely from technical limitations. With the billers having piece-rate pay, figuring out which app to use based on the product decreased their efficiency, which worked against their priority to work fast.

Our Goal

To automate processes wherever possible so that invoicing users would have less decision-making and higher efficiency. I also wanted to minimize user error so that our customers wouldn’t receive invoices with wrong charges.

Iterations

During the first iteration, I focused on matching the user’s workflow and breaking information up into a step-by-step process that is easy to follow:

  • Section 1: Verifying that all order details are correct, which includes customer name, their patient name, shipping address, account number, product type, pricing, and more.

  • Section 2: Selecting shipping method

For section 1, I reused some components that were used on a separate page since similar info was already displayed there. This was to avoid reinventing the wheel if appropriate.

First iteration of the invoicing screen

As I continued to iterate and got feedback from stakeholders, I made numerous changes to better prioritize efficiency and ease of use.

Not reusing designs

I realized that the benefit of reusing the design from another page in section 1 wasn’t worth the con of showing a lot of info, of which some weren’t necessary on the invoice page. It also became apparent that arranging in a different layout could benefit the user to see the info in a different light and avoid overlooking important pieces of info.

Hide the side menu

To fit all the content on one page without scrolling, I decided to hide the global side menu. This makes sense also because users don't typically want to leave the invoicing process to navigate elsewhere, so having the menu available during invoicing wouldn’t be very useful.

Add a fixed section for the invoice summary

Because the invoice total changes based on the products and shipping method, I decided to place the invoice summary in its own fixed section so that it remains visible at all times even when the content overflows the screen.

Invoicing flow after a few iterations including the user editing some order details.

Usability Testing (LMS)

I conducted usability testing comprised of 7 different activities for 7 users in the Shipping department. The System Usability Scale (SUS) was an average of 93.57, meeting our guideline of 80.0 or greater, which indicated that the designs were usable and would be recommended by the user to others. The following are some of the design decisions that the users appreciated as they helped reduce potential errors and increase their speed of invoicing:

  • The users liked the layout where everything fit in one screen without scrolling

  • Ability to scan the barcode of the order that automatically takes them to the invoicing page

  • Blocking users from invoicing an order if the customer’s account had issues (e.g. if they’re behind on payments)

  • Defaulting shipping selections based on product size and customer’s address to reduce clicks

  • Clicking the “Submit” button automatically printing the invoice paper that they need to insert in the package so that they wouldn’t have to click another button to print

  • Displaying suggestions to bundle the case with another if there’s an order found for the same dentist that’s ready to be invoiced

  • Ability to modify any order info within this invoicing flow. With legacy systems, they had to exit the invoicing flow to make changes to an order and come back to invoicing, which was tedious and time consuming

Example prototypes used in usability testing

Bundling flow

Uninvoicing flow

Final Solution

What did I learn from this project?

  • Stakeholders aren’t perfect (just like everybody) and may not be able to remember all edge cases when they provide requirements at the beginning of the project. So what can we do to help? We can lend a hand by asking questions about weird possible scenarios to the project team to see if any of them are actual scenarios we need to consider

  • Reviewing early iterations of design will always be beneficial to get feedback from stakeholders and even help the previous point

Next case study