The Expense Policy page is where companies set up rules to pre-screen expense submissions. While it was one of the most important parts of the product, this page was also the oldest and had the most heinous usability issues. I embarked on a 6-week long project to redesign this core platform experience for Abacus.

Background

Abacus is the only real-time expense management software in the market. Everyone else does monthly expense reports. What this means is that we have incredibly timely and granular quality control over every single expense submitted, unlike other expense solutions whose control stops at the report level.

The Expense Policy page is where companies set up rules to control the quality of the flow of expense submissions. By defining specific requirements for certain types of expense and filtering out policy-violated submissions at an early stage, we make admins’ job easier.

Problem

When I began working at Abacus, there were already many problems with this supposed-to-be incredibly powerful feature page. They could be grouped under 2 categories:

  • Page UX problems: this page wasn’t built to scale. The 2-column layout clearly did not account for large companies with complex rule systems. In addition, lack of scannability, poor categorization, and inconsistent-turns-confusing UI interactions makes this page very hard to use.
  • Rule creation flow problems: Again, poor rule-type categorization hinders admins’ ability to create a rule that serves their need. These steps were designed in mad-lib style…

Goal

  • Create an experience that enables our admins to <span class='bold'>translate</span> their companies’ expense policy to <span class='bold'>actionable rule items</span> on Abacus
  • Revamp the page’s UX & UI to <span class='bold'>support larger, more complex organizations</span> (with a lot more rules!)
  • Focus on <span class='bold'>low-hanging fruits</span>. There are certain backend changes that will make this page fantastic, but there are also immediate frontend changes that will undoubtedly make this page 10 times easier to read and use. Focus on the latter first.

Page redesign

This was my first time (re)designing an entire web app page jam-packed with functionalities and micro-interactions. In hindsight, I did try to tackle too much in too much detail during the first round. Because there was so much co-relation between how a rule is created and how it manifests itself on a page, I stumbled a bit to find a good starting point. Finally, I settled on redesigning the page itself first.

At a first glance, you will immediately notice that it now has a one-column layout. Rules are now grouped under one sections but are clearly labeled and color-coded to signify their severity degree/type–Block, Warn, Mile(age), and Auto. I also create a “highlighting logic” for each type of rule based on their differentiators to make it easier for one to scan through the page. For example, for requirement rules, we bold the requirement (note, receipt, etc.) and for auto-approval rule, we bold the merchant.

I also create a highlighting logic for each type of rule based on their differentiators.

Modal redesign

Study & Research

Redesigning the rule-creation modal was the most UX-heavy part of the project. It involves redesigning the entire information architecture of rule creation modal, from which criterion we start the user with to which rules could be logically grouped together. I started tackling this by analyzing our old rule creation modal’s architecture:

I also used our internal dashboard, Abadash, to look up and study the rules of 10 differents companies with 20+ rules. By doing close rule sentence analysis, I started drawing patterns about one common rule formula.

Redesign Modal's IA

I came to understand that part of the reason why it was difficult to use the old rule creation was because it was so dense with unstructured content. In addition, users aren't able to preview the rule they're trying to construct. I decided to separate the rule creation flow into 3 parts:

  • <span class='bold'>Select</span> a rule type (requirement, budget, or time limit)
  • <span class='bold'>Construct</span> the rule based on its type
  • <span class='bold'>Preview</span> the rule and make adjustments if needed

Check out a detailed explanation of the first 2 steps in the proposed new information architecture below:

Redesign Modal's UI

After my proposal for a new modal's architecture was approved, I started working on the new rule modal's UI. There were serveral UI concepts. I was working with both horizontal and verticle modal wizards. After a couple of reviews, we decided to go with the concept below.

Testing

I creative some quick InVision prototypes to test out the new rule creation flow. Working with 2 members of the customer success team, we hopped on a couple of calls with our customers and did a cognitive walkthrough with each of them. We also gave them $50 Amazon giftcards!

Among what we found:

  • Copy is important! We spend the an entire round iteration working on improving copy for the different rule creation modals in order to make these mad-libs read more like real sentences. We also finessed existing tooltip copy and added extra contextual help to guide users through these flows. It is our goal for this page to be self-served instead of relying heavily on implementation specialists as we did before.
  • Among the extra features we added, the low-hanging fruits such as rule editing and previewing turn out to be the most fruitful. For v1 of this project, we actually scaled back some of the new features but these remain on the roadmap.

Launch

This project was launched mid-April, 2019.

RESUME

LINKEDIN

BEHANCE

GET IN TOUCH