top of page
The re-making of: Aditya Birla SME Loan Application Platform
Reading time: 15 mins I Scanning time: 6 mins I Grasp time: 30 mins (approx.) I Project date: May 30, 2017 I by Saikat Roy and team
The outcome of the project banner
ABFL Direct. A direct SME (small and medium-scale enterprises) loan platform. Yes, that's all about the product. And what were they struggling with?
80% bounce rate right from the homepage...Scary right?
There's nothing scarier than a high bounce rate in conversion based digital products. That is when Aditya Birla Finance (a 20+ years old non-banking financial institution) reached Kuliza Technologies (an end-to-end product development firm) to fix it.
So we came into the picture. And the result?
Increase in 64% conversion rate in 3 months. Oh bonus:
saved offline cost by 12% (post digitisation of offline services)
How did we do that? And what happened in the backstage of this successful solution?
Please head below to check the rest.
Before starting with the craft piece, I would like to mention that you may always click/ tap on the respective sections to know more details (for instance, Ledership, Collaboration, etc.)
A solution is ideally followed by a problem, or to be precise, a Right Problem.
We knew the problem as well as our stakeholders, which was:
"The site is having 80% bounce rate right from the homepage".
Now, validating that given problem and coming up with a 'Right Problem Statement' is what determines the efficiency and effectiveness of a solution. Else, from my experience, I have seen large teams coming up with a solution after 6 months that does not have any measurable result or impact.
And thus, the search started for finding out the right problem.
Inspiration phase
An inspiration is nothing but finding an opportunity for motivation.
In this phase, we tried to find motivation. Once we have the motive, we will have some intent (which is more figural in nature, than motive) to drive our implementation or solution.
In this case, inspiration consisted of the following milestones.
Yeah, reaching a purposeful intent is never an easy job.
The inspiration phase depicted via general illustration (modified, post inspiration from HCD by IDEO and Double-diamond by British Design Council)
Based on the problem we were trying to solve, the talents of people we had, the cost of project and most importantly the time allocated to us defined the milestones for inspiration phase as mentioned in the image above.
Here's a brief, before we dive-deep
• 01 Requirement gathering: to understand more about the business goal, the current state of user experience, the target user, domain knowledge, and etc.
• 02 Service blueprint: to understand more about the issues within journey flow and pain points
• 03 Usability and cognitive evaluation: to understand more about issues within frame-by-frame design based on evidence-based and expert evaluation
• 04 The checklist: collating who are we solving for, what are we trying to solve, why are we trying to solve it, which will give us a clue about how we are going to solve it
Now let's dive-deep in what we did within each of these sections.
Requirement gathering
Requirement gathering I Inspiration phase (01of05)
This section had to start with detailed stakeholder interviews.
Now, who are these stakeholders?
Well, in an ideal scenario, the biggest stakeholder is your user. Again, "in an ideal scenario"! But in a practical scenario, there are n number of stakeholders based on a project or an organisation.
In this case, we took both business and user as our stakeholders.
The business stakeholders are easy to reach. What about user stakeholders? Well, we took the help of previous customer care data and web-metrics to understand that. And yeah, used method acting (keeping oneself in users' shoes) to understand few of their pain points. We are going to look at user as stakeholders within 03 Service blueprint and 04 Usability and cognitive evaluation sections.
So here are some of the notable pointers we have derived after a brief stakeholder interview sessions with Achintya, Kalpesh, Neha and Maninder (the sales, product, business and customer service team leads respectively).
The summary from stakeholder interviews
Neha was also kind enough to share the existing SOP of the complete service.
Here's that:
The earlier SOP for ABFL direct product
Post that, we tried to get hold of their customer journeys (screen-by-screen flows) through a mock test. They also shared briefly about the group they are targeting (which we are going to talk about within persona section).
For this case study, let's take an example of the longest but one happy flow.
The epic story:
User is in the home screen, applies for a loan bigger than ₹ 2.5 lakhs and gets it approved
The end-to-end happy flow of one earlier journey
So, we have all the raw data from stakeholder. Enough for us to understand the current flow and domain knowledge on SME loan process in India (govt. regulations related to it and all).
What's next?
"You can have data without information, but you cannot have information without data."
- Daniel Keys Moran, an American computer programmer and science fiction writer
Now, we create an understandable information out of these data.
Creating an output from these gathered data into a simpler form for all Lehman to understand and refer, some call it Affinity Map.
Thus, here comes the output, or flow of the then web-portal (online > offline).
Affinity map. The earlier flow of the app
This was printed widely and kept at the entrance of our brainstorming room to check if we missed anything vital (both for stakeholders and designers).
Other than business flows we also got an idea about the group of people they were targeting, which helped us derive persona of our target users.
• Small and medium scale business owners (SMEs)
• They are briefly within 18 years to 45 years of age (if more than 45 years, they have some assistant to support within their daily chores)
• And, an 8 page document containing all the business cases of govt. regulations on loans based on someone's requirement vs. eligibility (damn, that took us 1.5 hours and endless tea/coffee time to grasp)
Based on these, we had created around 6 personas. Then merged two of them within two others since they were too narrow to keep as an independent persona and was hardly making any psychographic or demographic difference.
For this case study,
Let's pick a persona who is eligible for more than ₹ 2.5 lakhs of loan.
A persona, eligible for a loan of more than ₹ 2.5 lakhs
Once we have this solid flowchart of the current offering and the users we were solving for, we wanted to diverge further to understand what goes beneath each and every skin (or components) within the flow. That includes user action, front-end, back-end, support services and etc.
In fact, all design process are but collaboration of diverge and converge cycle.
That brings us to the next set of affinity map or service blueprint (in a broader sense).
Service blueprint
Service blueprint I Inspiration phase (03of05)
My personal favourite of a service blueprint digram is the theatrical experience map (sooner I am going to write an article on that, if time permits).
For now, you may refer the following service blueprint diagram (via. theatrical experience map), for the then web-portal.
Service blueprint of the then portal. Represented as a theatrical experience.
A theatrical service blueprint includes five basic partitions-
01 User task/ Business goal
02 Physical evidence
03 Front stage
04 Backstage
05 Support
In addition to that, there's few cross-lines in-between all these partitions-
a. Line of desirability
b. Line of ability
c. Line of interaction
d. Line of visibility
e. Line of internal interaction
Question is, why is it important?
Well, to study the NPS (Net Promoter Score) and to understand whether it's an engineering, product or design problem.
Trust me, you don't want to provide a usability solution (design) to a reliability issue (engineering), and let the product and business team scratch their head over next few months on "Why is this bl**dy conversion rate not improving!!"
At this stage we simply want to gather as much data as possible.
And then, marking things in red (which are probably redundant for the user) and marking things in blue (which are probably something frustrating for the user but are mandatory as per govt. regulations).
What to do with the blue's?
We are going to apply Tesler's law (Law of conversion of complexity) ↗, which states that there are certain amount of complexity which can not be removed or hidden but can be shifted (either to front-end or back-end or somewhere innovative). We are going to come back to that in the implementation phase.
Marked issues (in red) and mandatory pain points (in blue)
The next set of data we were looking for were some kind of evidence based or some kind of expert evaluated, which brings us to the next stage.
Usability and Cognitive Evaluation
Usability and cognition I Inspiration phase (04of05)
What is usability?
The ability of a user to perform a task.
And cognition?
What goes inside the user's mind while they perform a task.
Ever imagined the similarity between a computer CPU and a human head? Both gets hot while performing large and complicated task. Again the amount of hotness is dependent on the ecosystem they are in (for instance, in AC room or a fan cooling the heat); trust me, this too increases a user's ability to handle frustration and complete a complicated task (there are research studies from reputed Universities like Stanford on this).
We had a holistic problem statement evaluation and a business flow evaluation, then we had the flow based evaluation, and now we were looking to have a screen-based/ frame-based evaluation.
There are ample amount of ways to perform a usability and cognitive evaluation. Some are data-based, others assumption based or hypothesis based.
In this case, based on the timeline we had and the amount of budget allocated to us, we performed a data-based combined with an expert evaluation (on the basis of hypothesis, but informed decision based on industry standard and experience). The idea was to test the hypothesis through user testing once we have some kind of prototype in place; talked about this in implementation phase.
To start with, we luckily got the heat map data through integrated hotjar software, which talks about the experience of real-time users as a grouped analysis. The colour hue scale ranges from red (being the most clicked/ tapped/ watched) and green (being the least clicked/ tapped/ watched).
Heatmap data of the then portal
Starting with this heatmap data, we jumped into an expert evaluation through sketch collaboration tool to figure out the issues within each and every screens for a particular journey.
There were certain screens as per coverage matrix which were overlapping (those have been evaluated only once). Why evaluating screens based on journey matters? 'Context', one need previous and anticipatory context to evaluate even a single frame.
The idea behind this evaluation was mostly about asking 'WHY might be' for the resulted data from heat maps.
Expert evaluation (usability and cognition) for each and every screens with a particular journey
Now, once we had all the data on the problems from all perspective, we moved ahead to the next step. Which was creating a checklist of issues we were trying to solve.
The checklist
The checklist I Inspiration phase (05of05)
A checklist is a research conclusion that helps to plan and then derive a solution for a problem, and then acts as a verification list once we have the solution.
Most of the time when I see there's no connection between research and the solution (mostly biased), I can easily guess it's because of not having a checklist. Based on my experience, not having a solution plan based on a research checklist costs a company in repeated cycles.
In our case the checklist had four basic components:
• Who are we solving for
• What are we solving
• Why are we trying to solve it
Which will help us to derive, 'How are we going to solve it' or the implementation plan.
So as you can see,
a checklist is a clear purpose statement for solving a problem.
Let's move to the next set with who are we solving for or "who are our users". As been discussed within the 01 Requirement gathering phase, finally we came up with 4 sets of personas, and for this case study, we are going to pick the following persona.
A persona who is eligible for more than ₹ 2.5 lakhs of loan
Persona
A persona, eligible for a loan of more than ₹ 2.5 lakhs
A persona defines 'who are we solving it for'
It acts as a checklist throughout the entire process and continues post development and metrics to constantly question our biases and working in favour of our target users.
Once we had the persona, next question that lies is what are we trying to solve?
Reducing the bounce rate of the current site which is around 80%, to a minimum of 15% by reducing all kinds of user pain-points and frictions on the way
What we were trying to solve problem statement with the 4/4 graph
Once we had the user and problem definition, it's time to find the business reason or why are we trying to solve it?
Why? It gives a clear purpose to the designer about the impact of their design. It immensely motives a team to work hard and work efficiently.
The business relies on the approved loan. More approved loan means more profit to the business. Now higher is the number of loan application, higher are the chances of approved loans. Faster the application process, higher is the number of loan application.
The purpose or why were we trying to solve it
This checklist items were printed in large chart papers and sticked at our meeting rooms (removing all other stickies and notes from inspiration phase), so that we are focused and constantly in check of what we were doing.
Since we have the checklist or problem statement in place, let's move into the ideation or solution phase.
Implementation phase
Ideation phase
Ideation is all about playing with ideas based on researched material from inspiration phase. But before starting to ideate, we needed a plan on how to ideate.
Well, we had the tangible intent (the checklist), now we are going to create a tangible solution proposal.
Till a product crosses the development phase and launched in the market, I prefer to call it a solution proposal since it is yet to be marked as a tangible solution. Sometimes it changes drastically from the stage when it's a design solution to when it's marketed.
Question is, how are we going to derive a plan from what we have, the checklist (and the data from inspiration phase)?
It's a personal framework me along with few of my colleagues (an ex-university) have created during the mid stage of our career where we have figured out that all design requirements can be categorised into these 4 broad categories (we call them playcards). Probably I will write an article later on this (again, if time permits). For now, here are the broad categories:
• Stylistic design
• Functional design
• Strategic design
• Innovative design
In this case study, we are probably not going to talk about all these playcards in detail; what differentiates each of them and the impact of each of these cards. In contrary, we are going to pick the one that falls fit for this particular case study and dive deep.
These are the following features we can derive from the checklist we have in place:
• The goal for solution need to be a new source of value for business (increasing conversion rate)
• The outcome for solution need to be a unleashing the old offering (completing a loan application)
• The achieves for solution need to be a new source of revenue (more number of application)
• The risk/ reward is mid-high (since it's a medium budget project)
• The value/ project timeline is mid-long term (since the timeline was mid-long)
Based on these evaluation, it clearly falls under the strategic design playcard.
The strategic design playcard
Now there are n number of ways to solve through a strategic design. All different ways vary based on project timeline, project budget, stakeholder availability, user data availability, user research budget and etc. Trust me, there's no one-size-fits-all process. And if someone approaches all problem with some similar process of solution, I would prefer calling them design executioners than design thinkers. Merely because 'why would a company hire a designer who can pick a process from the internet and follow through a solution. Can't anyone from the product team do the same?'
Based on the project's timeline, budget, product build strategy and all, here's the process we had drafted to derive the expected solution through strategic design.
The implementation process (a strategic design process)
There are a lot of questions that might come up. To pick one: why did we pick method acting or user story instead of starting with an assumption based design or open card sorting based design (architecture based). We are going to talk in detail about all those within each and every section as we move ahead.
User story conversion I Ideation phase (01of06)
This is where I would request for password to access rest of the content. I know it's frustrating, but there are confidentiality clauses to be adhered by any ex-employee of a company as an ethical practice, and I believe it can only be showcased as a portfolio for hiring purpose or study purpose, definitely not to be public.
These are the following motto to showcase this case study:
01 Showcase to get hired
02 A good conversation to improve a design logic
03 A good conversation starter for another ethusiast
04 A new productive connection with similar or better talent network
If your motive follow any of these, please send a personalised email stating a motive.
Ask for password at saikatroy@outlook.com
Or if I have already given you the password
In any case, if you are simply scanning through and wanted to understand my capability and what else went in the backstage of this project, you can always access the rest from the below links. Happy appraising, and thanks a lot for your time in this.
• Leadership
• Collaboration
• Challenges
bottom of page