The challenge

🎯 "From chaos to clarity: How we reduced rule creation Setup time by 62% to enhance the increment in DIY journey for our fraud & risk management platform

Background & problem space!

So risk analysts were unable to create rules, Right?

With Initial data observation, we found out that analysts were spending a lot of time while creating risk rules and also dropping off in the middle of the journey. We observed the global reasons were,

Confusing user experience 😵‍💫

Risk analysts struggle to navigate through the system and often get lost in complex workflows. Thus used to be assisted flow and tickets rise

Misleading tools & constant reinvention 🔄

Without standardised, reusable templates, teams keep creating similar rules from scratch

Current design

All hands

Meet the artists

My role
Product Design Lead — UX Research, Visual Design Prototyping, User Flows, Product Strategy.
Team
PM: Ayush Aggarwal, George Mathew, Saurabh Kumar
Design: Vishesh Raj
Eng: Shashi Gupta
Duration
APR’ 25 - MAY’25
(4 weeks)

Impacts

What did we achieved

53%
Increment in Rule creation completion rate
38%
Increment in DIY rule creation adoption rate
48%
Decrement in Error Rate per Step
62%
Decrement in Average rule creation time

Work process

How does it started - Design process

“Ohh wait! ⏰ Is it that simple?” - I doubt that 👀, Let me show how it looked like...

Desk research

Understanding the rule creation journey

Initial Complexity Assessment 🤯: In the initial discussions including PRD walkthroughs, we found out a lot of gaps in understanding the overall the rule creation journey. Few of them listed below

• Mental overload • Domain expertise gap• Technical jargon barrier• Multiple stakeholder perspectives

Different historical

transactions baseline

Operators & entities

are linked

A functional mathematical view of rule creations

Current Rule Configurations framework

Drawing Insights

So how did we simplified it?

I collaborated with product & risk team to understand how different rules are being created to bring some structure for it. Analysed metrics to understand how it shortfalls.

Card sorting

Figuring out different rules & bucketing them

Historical rules (Velocity specific rules)
This rule operates where some count/sum of a number of transactions is being compared with sum/count on another aggregated transactions over a period of time
Non-Historical rules (Data match/Compare)
These rule operates when there is a single parameter is being matched with other single parameter real time.

Secondary research

Analysing the key players(Competitors)

For identifying the strengths and weaknesses of the product I did a competitive research for direct and indirect players after a framework for competitors like Stripe, Seon , Unit 21, Cashfree, Razorpay etc

Competitive matrix

Primary research - user interviews

Extracting user needs

While this exercise was jam-packed with a lot of work, exploration, framing out right set of questionnaires, discussion with stakeholders. It feels impossible to boil down all the things, but if I had to, it would be the key insights that we received.

Template shortage
Doesn’t understand what type of rule they want to create
Complexity
Doesn’t understand dependancies & complex actions
Limited Collaboration
“Can't easily share created rules with teammates for review"
No draft Saving
Unable to save the rules as draft as every rule isn’t created at the moment
Sequential logic glow
Think in "if-then-else" chains, not complex boolean operations
Syntax overwhelm
"I spend 30 minutes just figuring out the right attribute format”
Context Switching
"I have to jump between 4 different tools to gather data for one rule"
Boolean Confusion
AND vs OR combinations become mind-bending with 5+ conditions"
No Visual Feedback
"I can't see if my rule makes sense until I deploy it"
Testing Uncertainty
"I never know if my rule will work until it's live"

Persona

Colatting the information

Ripul Arora

Position

Risk & AML anayst, WNS

Industry

Finance & banking

Education

BBA

Location

Gurugram, India

Age

Story

Ripul Arora is a fraud & risk analyst at WNS. Ripul receives an alert about a new fraud pattern: "Suspicious account takeover attempts using stolen credentials from overseas IPs". Ripul opens the Trident dashboard to understand and after analysing the case Ripul that there is a requirement of new rule for catering these types of overseas frauds.

"I know what I want to catch, but translating it to this technical format is like learning a foreign language every time!

🏆 Goals

Primary: Reduce fraud losses by 15% this quarter
Efficiency: Cut rule creation time by 60%

💫 Wants

Speed: Create rules in under 10 minutes
One-Click Templates - "Ready-made rules for common attacks"
Confidence: Preview rule impact before deployment
Real-time Help - "Contextual guidance during rule creation"

🔧 Needs

Immediate: Visual rule builder for complex condition
Urgent: Rule templates for common fraud patterns
Draft Auto-save - Never lose work due to browser crashes

😰 Fears

Technical Fear: Syntax error causes rule to fail silently

User journey

Mapping the flow

Implementation

How did we solved it

Note: The revamped design was supported with new design system, We created a new IA & bifurcated the rule creation process into 3 simple steps rule definition, conditions & actions for the overall journey, proposed a new structure and designed flows with additional features

To solve the syntax problem, we asked the analysts choose the type of rule they want to create at the beginning of the creation journey itself

As the next steps I created a rule definition page where the analyst defines the type of rule they wanted to create solving problems like IA, progress of application, complex functionalities etc

Introducing the new syntax for the historical types of rules i.e, Velocity & Spike rules

Quick recap ✨

Historical rules: This rule operates where some count/sum of a number of transactions is being compared with sum/count on another aggregated transactions over a period of time

Now how do you create a generic rule, for creating it a scalable all generic rules we created it under Non - Historical rules umbrella. Let’s understand this with an example, Suppose we need to create a rule

If A & B or (C & D), where A-f(x), B-g(x), C- p(x), D- q(x)

Quick recap ✨

Non-Historical rules: These rule operates when there is a single parameter is being matched with other single parameter real time.

As the last step we had the analyst to setup the output ie. the different risk suggestions (mathematically the risk scores) that the rule will provide when it triggers

In the end

What did I learned as a designer

While this revamp was jam-packed with a lot of learnings. It feels almost impossible to boil down all the things, but if I had to, here they are!

Don’t trust the assumptions, go for the facts

While the start of this project my assumptions were that fraud analysts are power users who want maximum control & flexibility upfront while the research revealed 67% were occasional users who froze when seeing complex options - they wanted confidence and quick wins, not comprehensive control.

Early Feedbacks: Fast Failure & Quick Recovery

While we were iterating on the designs I started taking earlier feedbacks with product team & risk users at Wibmo which helped to understand what designs were lacking how context was missing to how it would be cleared. They brought unbiased opinions. This saved us from going to complete failure & bouncing back faster.