Duration: 2014-2015
Role : Developer and UX advocate
Skills & Tools : Development in ABAP, JS, CSS & HTML, UX Design Basics for UX advocacy
tl;dr : A banking application to help with the manual resolution of loan repayment exceptions (This might be a little dry, but Banking is an acquired taste)
Why are there no artifacts of my process in this page?
In all honesty, I would have remained the happy developer I was at SAP, had I not seen the customer's delight at the end of the process. By that time, we had not saved any artifacts that would be useful for a portfolio, had recycled a ton of post it notes and had wiped clean, all the surfaces that we had brainstormed on.
Project Context
I worked as a developer with the SAP banking team (for loan account management). This specific project is part of a larger suite of applications aimed at streamlining the back office processes in a bank. This app was developed in close association with our customer ATB Financial, Canada.
The Problem
During the repayment cycles of a loan there might be several occasions that might lead to an exception. One of the most commonly occurring exception is when the customer pays more than what is owed for the particular billing cycle(overpayment).
There are four possible solutions that can be applied to the excess amount
Prepay future loan receivables
Make a curtailment, in other words repay the remaining loan capital amount either in part or in full
Transfer the overpayment back to the original account from which the payment was made
Transfer the overpayment to another account
Depending on the loan account's current stage, one or more more options may not be available.
Why aren't these exceptions processed automatically?
For the following two reasons:
Most technical errors are processed automatically. These remaining exceptions require business knowledge and the back office users often tend to consult with their customers before applying a particular solution(insight from interviews).
The customers tend to prefer different solutions at different times depending on their personal financial situation and the stage the loan account is in.
Our Solution
Here is a short demo of our app:
You can find the technical details of the solution here.
The Design thinking process
This was the first time our team tried the Design Thinking process, deviating from our hybrid of waterfall and agile processes.
The interviews revealed several surprising insights:
Since the users had to jump around so many systems and tables to identify possible solutions, they maintained handwritten notes in a book (yes, seriously!). The fact that SAP software formats data in its own way and doesn't make it easy for users to copy and paste compounded the problem
Several parts of the back office processing were outsourced to resources with little to no background in finance
The back office users maintained a shared excel sheet to assign exceptions for processing. This had no way of storing notes, updating on progress and some members failed to update the sheet after completing the task.
When we synthesized our interview notes, we were able to see in what sequence the back office users accessed data, what tables were viewed in parallel and what conclusions they were able to make and how they chose the solution.
We made several paper prototypes and presented it as a video as we reached a stable iteration to our customers. Although this was an uncomfortable experience for some of us(what? presenting a childish paper prototype?!!) it helped us gain feedback quickly and change our prototypes on the fly. We later presented polished mockups and a technical proof of concept, which were received very well. There were no surprises or disappointments.
Development
We used the SAP FIORI UX guidelines and SAP UI5 components for the front end development along with major developments in the backend to support these features.
We distilled the messy process into three clear steps:
View: List of open exceptions
Inspect: Analyze the data relating to the exception the user is trying to resolve
Resolve: Resolve the exception by choosing one or more (partial resolution) of the possible options
Testing
We had several rounds of usability, integration (as the solution spanned across systems), functional and Solution Acceptance Tests by customers and SAP consultants. We then incorporated their feedback, did another round of testing and then finally released the app.