Happay Vendor Payments: Simplifying Corporate Payables

Why Vendor Payments?

Happay's vision is to create value to businesses by capturing processes encompassing "All Payables" of an organisation. After employee salary disbursement, employee T&E and vendor payment expenses are largely the two huge expense incurring verticals in any corporate.

Today, Happay is already a significant player in the T&E expenses segment with over 4500 customers globally. Expanding our product offering to Vendor payments segment of corporate expenditures is the logical next step for us to achieve.

Vendor Payments space, which is expected to grow and currently is around four times that of employee T&E expenses, will contribute more value to our existing and future customers thereby paving the way for Happay's destination of becoming a one-stop solution for businesses globally, to manage all of their payables.

The Problem

Accounts Payable (AP) functions traditionally have been paper intensive, time consuming, tedious and prone to human errors. The legacy software solutions available to digitise and automate AP offer broken and sub-optimal experience shared across multiple systems for different aspects of the process. This leads to higher training effort, slow adoption, and poor end-to-end process visibility and control.

Card Management Systems, Vendor Payment Processes and Systems, Enterprise ERP/ Accounting systems and Banks are islands which contain enterprise data and copies of them which result in a lot of effort and time to control, reconcile and get visibility of.

Additionally, due to outdated controls, only a few people in the organisation participate in the payments process resulting in bottlenecks and associated delays.

Stakeholders

Account Payables is a multi-sided problem involving Enterprises (Buyer), Vendor (Supplier), Banks and Payment Cards.

Each party has a particular and a different problem in this.

1. Enterprise wants to make payments to vendors only at the last minute; Additionally, the Enterprise wants a unified view across multiple silos of Banking Systems, Cards Systems and Enterprise Systems.

2. Vendors want to get paid immediately and want to have certainty of payment.

3. Banks would like to drive transaction volume through use of electronic channels as well as extend credit to both Supplier and Buyer.

While enterprises have deployed ERP systems, it is just another island which the Organisation has to navigate through. Banking Systems and Card Systems continue to be untouched islands resulting in delayed visibility of information and inconsistent information resulting in loss of productivity and delays in processing vendor payments.

End to end Vision capture-UX definition

Step 1 - Stakeholder discussion:

Multiple discussions and mapping sessions were done with product managers, in-house SMEs to understand the solution ecosystem and scope of value being proposed from a business vision perspective. The sole purpose is to make a mind-map of the scope of solution and user functions that the solution will eventually encompass as it matures over upcoming years.

Step 2 - Contextual Enquiry:

Once the basic understanding of the solution ecosystem was in place we intervened to find out user perspectives. Multiple contextual enquiry sessions were done supplemented with video diaries for further study. the focus was to understand how users go about completing tasks and how? What are the pain-points and delights if any. Another perspective is to understand the exclusive user behaviours across and within roles. The later helped us define the provisional personas which eventually is referred down the process and helped defining role based features.

Step 3 - Card sorting and IA:

Over the contextual enquiry sessions we were able to capture the task flows and understand the mental model of users around vendor payments. The sessions also helped us with a repository of colloquial terminologies and associations within information chunks, purely from user's perspective. These in turn are going to help us make the interface intuitive for them further down the process. Determining the associations and categorisation of content and information was done using open card-sorting sessions with 6 users from our finance team primarily. This eventually helped us define the basic grouping or housing of information within the scope of vendor payments which reflected the mental model of users interviewed. Hence, the Information architecture (front-end) was derived.

Step 4 - Content visibility matrix and navigation structure:

Once the information architecture was in place we got an understanding of the grouping . Now it was time to devise a way to replicate the groupings in a 2D interface and define navigation structure which helps faster discovery of information thereby enabling faster completion of tasks previously identified in step 1 and 2. We pivoted on frequency of access of information as the underlying logic of prioritising the information groups. the sole reason for doing so was because the nature of the solution was like tool which will eventually sees a regular use with the sole goal to complete known tasks with high efficiency on user's part. Hence, design goal is to enable faster find of high access items. Going by this logic, groups like Invoices, PO, PR, GRN came up as high frequency of access items whereas Vendors, Addresses, materials as medium frequency and remaining as low. The basic hierarchy of the groups being defined roughly we had to look at enabling and disabling the groups and their underlying task-flows for the three behaviour types/personas identified in step 2. This was necessary because of the very nature of the working of a typical organisation in this vendor payments context, which is the inherent hierarchy of employees and the difference in their roles and responsibilities. The hierarchy is typically 3 stages with document preparer being the person putting the information in system, then approver who is approving the correctness of the information put in the system and the pay guy who pays an amount to a vendor based on the validated information. The approval part is where the major difference lies from organisation to organisation, where one might have one- level of approval and the other multiple with no constant number to fix on. The whole mapping exercise eventually gave us the content visibility matrix which has the groups and their contents on y axis and the user personas/behaviours on x axis. The matrix helps visualise what content/information will be visible to which persona to the smallest category of information.

Step 5 - Navigation design

It was high time to start with defining the navigation at interface level . The basic idea was to separate the information groups by frequency. Three navigation designs on this idea were tested with 6 users in-house following up with an interview session, each. One being all groups shown upfront in a vertical left aligned format. second one with all on a horizontal format and third one with each separate frequency groups in a bigger group and showing limited items in horizontal format. The left navigation option came out as promising, owing to the following limited but not exhaustive factors:

Showing upfront the groups made user quickly identify entry points when asked for starting tasks unlike the other two options where either the new grouping was not complying with user's mental model around grouping or it violated Hick's Law.Moving from one group to another required least searching in comparison to the other options. Overall, left alignment of navigation ensured maximum focus due to the convention of reading from left to right and hence, better find-ability.

The pattern followed google mail which invariably every user within or outside organisation is well acquainted with. hence, abiding by Jakob's law we ensured least possible learnability on user's part.

Step 6 - Competition review

Competition review is done at this stage to check trends, practices and information that we might have missed till now that can be thought of and included before moving towards defining user flows and journeys. Though it had to be done initially, the project circumstances and timelines were such that it could be taken at this stage.

Step 7 - Mood board:

Once the navigation got solidified we moved on to do mood-board in parallel to defining the task-flows as user flows using low fidelity screens. The mood board was informed by three visual design patterns tested previously through teams in Happay. We took the colour and font from the top choice and worked upon it to define the primary, secondary and tertiary colours for the interface.

Additionally, a new direction from a usability standpoint was introduced to identify each high frequency group with an accent colour to help user visually identify between items when put together in any scenario. The accent colour was carefully chosen to sit well with the brainstormed statuses across information groups and conform to colour blindness test.

Step 7 - User flows:

Parallel working on mood-board, we started mapping out the user-flows as sketches initially. Later, we mocked the same up in low fidelity to validate with stakeholders (PMs, Finance and Dev. teams) and test it out with users. We used Axure to accomplish that which gave html outputs to facilitate interactions as required to complete flows.

Phase 1 - Limited scope of solution as a product

Step 1 - Adjusting designs from bigger scope to smaller scope

Owing to the limited timelines and plan we went forward with adjusting the current low fidelity designs from End to end vision capture to enable the limited scope of phase 2. Each item was taken up for review and optimised at design level to accommodate development feasibility and timelines. The intention of design effort in this phase was to enable an experience a-tuned to the limited scope only. Multiple iterations in low-fidelity were done to finalise on the scoped designs and sign-off for high fidelity designs to start. The low fidelity adjustments were done at component level first and then each information group is taken up like Invoice, Vendors, Addresses for phase 2 specific refinement.

Step 2 - High fidelity components to facilitate starter dev setup

High fidelity design effort started with designing components and basic interactions identified to be critical for Dev team, in order to start configuring things before moving into a sprint. Once the components were in place we started with high fidelity designs of key pages in advance of sprints but in alignment to the sprint tasks. Even the components were tested with users before solidifying.

Visual Designs