NOTE: 📝
Click on images for
full preview
Overview
To help banks and NBFCs manage complex lending policies without engineering dependency, we designed a no-code Business Rule Engine (BRE). The goal was to let non-technical users independently create, modify, and manage loan eligibility rules - reducing turnaround time, improving operational efficiency, and accelerating loan approvals.
My role:
I led the design entirely while working closely with senior designer, engineering team to balance usability with technical feasibility.
Team
Me, Senior designer, 1 PM
Duration
1.5 Months
Outcomes
Impact
NOTE: The solution was greenlit for implementation, but the feature was not released due to company shutdown, so production impact could not be measured.
Internal testing results:
In UAT, we tested with 3 users. Users were able to create and modify rules independently in 1 session (~45 mins) without external support.
Brought down rule configuration time from weeks (engineering-dependent workflow) to ~30–60 minutes in the BRE interface
Reduced fragmented handling across tools from 3–4 touch points to a single interface.
Problem
Hard-coded lending rules were slowing down loan decisions
Lending policies change frequently, but in our Loan Origination System (LOS), every policy update required backend code changes. As lending rules became more complex, even small changes took weeks of engineering effort. This delayed loan sanctions for banks, reduced operational agility, and limited how quickly new products could be launched.
The existing workflow: Policy updates depended on JSON and engineers
Today, policy rules are written and updated in JSON format. This approach:
Requires technical knowledge
Limits access to a small set of client users
Still needs support and engineering help for complex changes
As a result, even routine updates involved back-and-forth with support teams, slowing down decision-making and increasing operational overhead.
Target Users:
The primary users are Admin and Operational users from banks and NBFCs. They have deeper understanding of lending policies but have little to no coding knowledge.
Requirement Gathering
To go deeper, I mapped real implementation flows across 7+ client setups, involving the product manager, senior product designer, and myself. This helped us identify:
Common patterns across clients
Opportunities to design for future scalability, not just current use cases
Market Research
We studied multiple Business Rule Engine products to understand: Core functionality, Design patterns, Strengths and limitations
Most products looked different visually but were fundamentally similar. They followed the same underlying rule syntax, with minor UI variations.
While researching, we came across NECTED, a no-code rule engine used across domains like finance, insurance, and healthcare.
UI approach: Choosing scalability over visual novelty
One key question was:
How should users build and read rules?
We had two choices of block based UI and flow based UI. After multiple discussions, we opted for a text-based rule-building approach. This format proved more readable, easier to review and debug, and significantly more scalable as rule complexity increased. While chart-based or flow UIs can appear intuitive for simple cases, they tend to break down quickly in real-world lending scenarios.
Needing alignment quickly, without a mature design system
We knew this system needed careful design to scale across products. However:
Timelines were tight
Engineering needed something concrete to evaluate feasibility
We didn’t yet have a mature design system for quick high-fidelity prototyping
"We needed a fast way to align across teams."
Using AI tools to prototype faster and unblock teams
To move quickly, I used Vercel to create a functional prototype of the rule builder. This helped us:
Get early alignment with product and engineering
Validate technical feasibility
Visualize the UI in logical blocks
The prototype was strong enough that many of its ideas carried forward into the final design.
Final designs
A single policy can contain up to 200 rules, so browsing and editing needed to be effortless. I designed interface allowing users to:
Quickly scan and switch between rules
Always know which rule they are editing
Reduce cognitive load while working with large policies
Introducing a new creation method without breaking existing habits
While we introduced a simpler block-based rule builder, we intentionally preserved the existing JSON editor.
This allowed users to:
Continue using what they’re comfortable with
Transition gradually to the new system
Avoid resistance caused by forced change
The goal was adoption through flexibility, not enforcement.
During a casual lunch discussion, we explored an idea:
What if users could create rules using plain language prompts?
Given that, we already had structured rule types and the system could be trained on existing patterns. This felt achievable. To prevent the idea from stalling, I quickly created a rough prototype showing how prompt-based rule creation could fit into the existing UI.
Due to its longer development effort, we parked it for a future release.