Batch Billing rethinking how to create invoices

Project Description

Batch billing was designed to achieve rapid invoicing for multiple matters while giving users the ability to adjust in bulk. We observed that the service isn't meeting the goal to allow the user to adjust their bills adequately and is not accessible to new users, which is causing many support cases and product feedback requests to improve the feature.

How might we improve batch billing so that our customers are more successful? We will know we succeeded when we see increased usage of the feature and reduced call volume to the customer service team.



Challenge

Users are not saving time by batch billing. The feature is lacking assumed functionality and because of the poor UI, they need constant guidance from our customer success team. New customers find the feature underwhelming and non-intuitive. The goal was to redesign batch billing to allow for expanded functionality and improve accessibility for both new and current users.

Approach

I worked closely with the front facing to understand the customer’s workflow and mindset to create a framework for the feature. I collected data from usability and discovery calls until I discovered patterns and stopped finding differing input. Working with the team, I created wireframes in Sketch and high-fidelity prototypes using InVision to test with customers.

Outcome

I presented to the entire team once completed and was able to get valuable feedback about how to break such a disruptive redesign into smaller iterations that allow it to fit comfortably with the teams sprint cycle and the user’s workflow. Since there is no availability to assign this project to one team it will be used to satisfy “quick wins” over many sprint cycles. Applying credit to batched invoices was recently launched and has been a hit.


Problem Statement

The batch billing feature provides a way to rapidly invoice many matters at a time. From the constant support cases and negative feedback, the current design falls short in allowing our users to batch bill and make adjustments with confidence, especially with new users. The goal is to improve batch billing so that our customers are more successful based on increased usage of the feature and reduced call volume to the customer service team.

Hypothesis

We believe that creating an efficient billing system within Mycase’s product experience for users will achieve a higher rate of invoice creation and a reduction in call volume to CS. We will know this is true when we see an increase in product satisfaction, batch invoice creation, and a decrease in reported calls on the topic from CS.

Research

I utilized multiple research projects on while in discovery and in parallel to the development of the feature. I employed usability tests with internal stakeholders, gathered competitive intelligence on how current competitors handled batch billing and prototyping sessions with pseudo-users. All while gathering intel and asking current users on their expectations and needs throughout. Researching the payment experience was a massive undertaking. We accumulated data from 128 connected calls with current payment users. I Conducted expert interviews with CS reps and other members of user-facing teams including payments, sales, and training/onboarding.

In order to quickly digest large sums of data I employed a checkbox into my spreadsheets that had a legend that expanded on each check box that a user conversation fell into. All detailed call notes were also recorded.

Data was tallied and broken down by practice area for more insights into the needs by more narrow user groupings. These results were then shown graphically to the team. From this data, I was able to see that our users were not using for a few reasons and that many of these reasons were rooted in their practice area.

It appears you don't have a PDF plugin for this browser. No biggie... you can click here to download the PDF file.

Defining the Experience

Since this was a big overhaul both in look and functionality I got to imagine the possibility of what it could be. I began by understanding the user journey through research with customers. Using the Payment personas developed I was able to see what user type was hurting most from the current iteration and where they needed change to eliminate that pain. After I had mapped out what the current state was and what the future version could be I began wireframing ideas.


After I had an idea I tested it with customer experience representatives and other internal team members to test the usability of my idea and see what feedback I could generate. After I began to see trends in the feedback provided I felt confident in moving forward iterating further and sketch out several more mid-fidelity wireframes that illustrated more accurately the functionality the users needed. From there I began working with a product team to review and have them begin testing with me and talk about the feasibility of developing with their current product roadmap.

Iterating and Testing

The Lean UX methodology helped heavily in how I tackled this project. Going in with a mindset willing to experiment helped in rapidly outputting mocks of ideas. Using the scientific method to help isolate specific user needs and make hypotheses to develop solutions for them. As we continue to build new features and expand on current ones I will remain lean and agile.

My first iteration was low-fidelity to test the functionality. My goal was to have testers not get caught on the design and focus on if they could intuitively complete the task at hand. I was building out the idea of a wizard to really make batch billing accessible to new users. Using modals allowed for the expansion of features and filters that users could apply, boosting the value of the overall service that was needed. Specifically the ability to apply credits and filter out what type of expenses to automatically populate on the invoices. This iteration, however, was not a fit for power users as it added too many steps if they had no need to apply additional filters and adjustments. Once I had hammered out the functionality and cut out many steps that should be unnecessary, I began mocking in higher fidelity using our style guide.



From, To & Lessons Learned

Overall this project was a success. One lesson I learned on this project was the importance of regular team syncs to ground me when I would show them Ideas that were not feasible to build. The value of iteration helped me run with better solutions and find the best aspects of failed iterations to get the best version without wasting resources. By the time this project was completed I had created a pile of sketches and wireframes. Moving forward I will rely more on internal feedback from the team to help keep my ideas grounded and feasible with our sprint cycles.

Final Iteration

Original