Ops Portfolio

Research Repository

UX Playbook

Design Case Study

Management & Mentorship

Resume & Experience

Recommendations

Explore

Design Case Study

Corporate Accounting: How I failed fast with Prototyping (2020)

Summary

Prioritizing early user feedback on a prototype helped to course correct and avoid engineers spending time on a solution that would not meet user needs. Iterating on the prototype based on the additional needs uncovered during the prototype testing resulted in a design one user declared was “better than anything we have ever had.”

Skills

📋 Usability Testing

🖥️ Wireframes & Prototyping

💬 Qualitative Research (In Depth Interviews)

PROBLEM

Users were regularly duplicating their efforts to track accounting transactions.

In 2019, my development team was tasked with building a critical missing feature in the AppFolio software: Corporate Accounting. The goal was to create functionality for Property Managers to track their Company Accounting separate from their Property Accounting while increasing efficiency and reducing human error.

My team worked on Corporate Accounting for about a year. In this case study, I have chosen to focus on a feature need that came up toward the end of the project: when maintenance was completed by a 3rd party vendor, our customers wanted to be able to pay that vendor directly from their Company books, then get reimbursed by the Property.

DISCOVERY

The current functionality was tedious and error-prone.

The team had been working in the Corporate Accounting space for at least 6 months at this point, but we needed a better understanding on the specifics of this customer request - I conducted interviews with customers to understand our customers’ current processes.

We heard that our customers typically paid vendors from their company books, but our “Work Orders” system only supported creating bills to be paid from the property books, not the company. Though customers could manually record transactions on their company books that needed to be paid by the properties, but we discovered that the frequency of these reimbursements made the process tedious and error-prone.

⁠

PROTOTYPING

I collaborated with engineers to create simple approach.

Taking what we learned from customers, I facilitated a “Design Studio” (a collaborative brainstorming session) with the development team. I then designed a potential user flow, discussed the technical approach and feasibility with the development team, made a few changes, and set to prototyping.

Pretty soon I had what I thought to be a brilliant, single-step solution, and I was excited to conduct some prototype tests in upcoming customer calls.

⁠

ITERATION

My “brilliant” solution failed in customer calls.

Unfortunately, the customers we talked to during prototype validation were not impressed with my so-called “brilliant” solution.

We’d missed something in our initial discovery conversations: The person who paid the vendor and the person who submitted the reimbursement were different people. They had access to different information and worked through different processes. They were in completely separate departments, often working in different locations. There was no way that this task could be done in a single step.

⁠

I’ll admit I was a little disappointed at first that my first “simple solution” wasn’t going to work. But the next prototype was even simpler. Once I realized we were dealing with two tasks, I was able to reduce the cognitive load for each individual task (and each user).

In the end, the Maintenance Manager had no change to their existing processes. The user who documented the accounting for Property and Company was now able to do so with a single “Bill Back” task.

⁠

OUTCOME

“This is better than anything we have ever had. You guys are great, you really listen to what we need and take actions and I like your process.”

-Customer feedback

A few days later, we came back to one of the customers most unhappy with our first solution, and they were delighted with the changes I had made! They were happy that we listened to them, and we were happy to know we would be building something of value.

Conducting prototype tests before building the feature allowed us to discover what customers didn’t think to tell us in our initial discovery. This is one of my favorite stories to tell regarding the importance of talking to customers and testing your assumptions.

I often say that a big part of my job as a User Experience Designer is to be wrong.

Every time I share a prototype, whether it’s with engineers, fellow designers, or potential users, I am hoping they will show me what I’ve done wrong because I don’t think I will ever get it 100% right on the first try — iteration is essential to good design.

This project was the inspiration for my guest post on the Axure blog:

Fail Fast with Prototyping⁠

⁠

Explore More:

⁠

Resume & Experience⁠

⁠

Recommendations⁠

⁠

Research Repository⁠

⁠

Email Me

⁠

Connect on LinkedIn

⁠

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.