BoxPay’s routing feature has been live since its inception. However, the original design was basic, only to meet functional needs. With merchants expanding globally with multiple gateways, the limitations started creating friction in operations and revenue optimisation. As BoxPay kept scaling, the need for a smarter, more flexible payment routing system became urgent.
The Ask
I was assigned to revamp this feature – not just visually but functionally. The goal was clear: empower merchants with full control to define routing logic that matches their growing and diverse business requirements.
How it All Began: A Tale of Flipping the Existing Design for Better Control - Flip the card 👇🏻
New & Improved Design – design which helped onboard 2 new merchants
Please ensure you select at least one of the following: countries, currencies, or payment categories
Existing Design – design which needed an upgrade
New & Improved Design – design which helped onboard 2 new merchants
Please ensure you select at least one of the following: countries, currencies, or payment categories
Existing Design – design which needed an upgrade
New & Improved Design – design which helped onboard 2 new merchants
Please ensure you select at least one of the following: countries, currencies, or payment categories
Existing Design – design which needed an upgrade
New & Improved Design – design which helped onboard 2 new merchants
Please ensure you select at least one of the following: countries, currencies, or payment categories
Existing Design – design which needed an upgrade
Refining Through Iteration
Incorporating the suggestions, I refined the design to create this improved version.
Designing the core: ‘Rule Workspace’
Once everyone in the team was aligned with this intention, I focused first on the heart of the feature – the Rule Builder Workspace. This is where merchants define the logic and assign gateways.
Fig. 3.1. Complexity in existing competitor flows
One thing I was absolutely certain of - complexity shouldn’t come at the cost of usability. Not every merchant has the luxury of a dedicated, tech-savvy team. Many are small-scale, less equipped, and unfamiliar with navigating advanced systems. A good design should empower them too. After all, not every interface needs to feel like flying a plane.
Fig. 3.2. Project Requirement Document
Fig. 3.3. Tackling complex use cases first
Fig. 3.2. Project Requirement Document
Fig. 3.3. Tackling complex use cases first
Before sketching anything, I aligned with the Product Manager to clarify ambiguous use cases and remove assumptions. We revisited the PRD and made some changes.
I initially set out to make the feature stand out. But I took a detour by tackling the most complex use case first ( as shown in Fig.3.3.) – a move that quickly derailed our timeline. With the PM’s help, we shifted gears to solve simpler needs first, then scaled up to handle complexity.
Following this approach, I shared some early versions with:
🧩 Product Manager, to validate logic handling and confirm the look of the design
🖥 Frontend developers, to check for the feasibility of these designs
📝 Chief Product Officer (CPO) and other stakeholders, to match with their expectations
Before sketching anything, I aligned with the Product Manager to clarify ambiguous use cases and remove assumptions. We revisited the PRD and made some changes.
I initially set out to make the feature stand out. But I took a detour by tackling the most complex use case first ( as shown in Fig.3.3.) – a move that quickly derailed our timeline. With the PM’s help, we shifted gears to solve simpler needs first, then scaled up to handle complexity.
Following this approach, I shared some early versions with:
🧩 Product Manager, to validate logic handling and confirm the look of the design
🖥 Frontend developers, to check for the feasibility of these designs
📝 Chief Product Officer (CPO) and other stakeholders, to match with their expectations
Before sketching anything, I aligned with the Product Manager to clarify ambiguous use cases and remove assumptions. We revisited the PRD and made some changes.
I initially set out to make the feature stand out. But I took a detour by tackling the most complex use case first ( as shown in Fig.3.3.) – a move that quickly derailed our timeline. With the PM’s help, we shifted gears to solve simpler needs first, then scaled up to handle complexity.
Following this approach, I shared some early versions with:
🧩 Product Manager, to validate logic handling and confirm the look of the design
🖥 Frontend developers, to check for the feasibility of these designs
📝 Chief Product Officer (CPO) and other stakeholders, to match with their expectations
Fig. 3.1. Complexity in existing competitor flows
Finalising the ‘Rule Workspace” look
Each design pass uncovered something new. Slowly but surely, clarity emerged:
and a user guide for easy understanding......
🌀 Golden Ratio in the design
The structure of this rule-creation workspace was guided by visual balance and flow. I overlaid the Fibonacci spiral to ensure key user interactions align with natural eye movement — leading to an intuitive and aesthetically pleasing experience. The design balances function and form, reducing cognitive load while remaining visually harmonious.
Looking at the overlay of the Fibonacci spiral (which is how the Golden Ratio often manifests visually):
👉🏻 The focus area (where users interact the most) — drop-downs, fields, and conditions — falls nicely within the inner spirals, guiding the eye naturally.
👉🏻 The vertical flow of the form is harmonious, and the spiral leads naturally from the top-left (starting point) toward the call-to-action elements like “Add Processor” and “Confirm & Review.”
👉🏻 There’s ample whitespace, consistent spacing, and alignment that collectively create visual comfort.
One Smart Condition
The original routing design required merchants to input all four fields. This was rigid. So, I redesigned it with - One smart condition field, allowing users to define only what mattered.
Users have the freedom to create rules in whichever order suits their needs.
Applying Progressive Disclosure & Law of Proximity
To reduce cognitive load, I used progressive disclosure — showing one field at a time, revealing the next based on user input.
Related conditions were grouped horizontally to visually signal their connection.
Choose Multiple Processors With Ease
Users can now effortlessly select multiple partnered payment gateways and distribute daily transaction volumes with ease.
Key aspects of the redesigned Rule Workspace:
Video. 1. Prototype of the Rule Workspace Design
"Nope to horizontal scrolls." Users preferred vertical flow for better readability.
"Big blocks, big problems." The single-rule idea didn’t scale — mentally or practically. Breaking the logic into separate rules made it more approachable.
"Stand out, but stay aligned." The new design needed to feel fresh without straying from the design language or alienating existing users.
"OR is out." To avoid logic confusion, we stuck with just AND/UNION operations.
Video. 1. Prototype of the Rule Workspace Design
"Nope to horizontal scrolls." Users preferred vertical flow for better readability.
"Big blocks, big problems." The single-rule idea didn’t scale — mentally or practically. Breaking the logic into separate rules made it more approachable.
"Stand out, but stay aligned." The new design needed to feel fresh without straying from the design language or alienating existing users.
"OR is out." To avoid logic confusion, we stuck with just AND/UNION operations.
One Smart Condition
The original routing design required merchants to input all four fields. This was rigid. So, I redesigned it with - One smart condition field, allowing users to define only what mattered.
Users have the freedom to create rules in whichever order suits their needs.
Applying Progressive Disclosure & Law of Proximity
To reduce cognitive load, I used progressive disclosure — showing one field at a time, revealing the next based on user input.
Related conditions were grouped horizontally to visually signal their connection.
Choose Multiple Processors With Ease
Users can now effortlessly select multiple partnered payment gateways and distribute daily transaction volumes with ease.
Video. 1. Prototype of the Rule Workspace Design
Once the Rule Builder Workspace took shape, the Chief Product Officer (CPO) brought up a thoughtful question during the product workshop:
“Do you think this setup can handle all the edge cases our merchants deal with?”
Back for Round Two: The Plot Thickens
Back for Round Two: The Plot Thickens
Back for Round Two: The Plot Thickens
Back for Round Two: The Plot Thickens
This led to a collaborative effort between the CPO and PM to list out 13 real-world use cases - including complex scenarios like:
▫️ BIN-specific card routing
▫️ Discounts based on network type or issuing bank
▫️ Multi-currency flows with varied payment methods
▫️ Region-specific fallback handling
Fig. 4. Listed 13 real-world use cases
Fig. 4. Listed 13 real-world use cases
Each case was run through the prototype to ensure the design could support them seamlessly. A few edge interactions prompted quick design refinements, but overall, the workspace held up well and remained intuitive.
Scavenger Hunt
Meanwhile, I ran usability tests with non-technical team members using a method known as a Scavenger Hunt - a practical way to observe whether users could complete key tasks independently. Each of the 13 use cases was framed as a goal-based task, and users were asked to execute them using the interface. The aim was to test how quickly and naturally users could:
1️⃣ Recognise the correct entry points
2️⃣ Understand the rule-building flow
3️⃣ Complete each action without confusion
From the test, one recurring hiccup stood out: users struggled to identify the inline field meant for naming a rule.
After syncing with the dev team, we made the field more prominent, re-tested it, and saw immediate improvement in feedback. I then updated the final Figma files to reflect the fix.
These iterative checks ensured functional completeness and a smooth and accessible user experience.
In the event of conflicting rules, the transaction will adhere to the rule in listed order.
© 2024 BoxPay. All right reserved
Fig. 5.1. Inline field creating friction in task completion
Fig. 5.2. The solution – separating the name input and mirroring it in the header
In the event of conflicting rules, the transaction will adhere to the rule in listed order.
© 2024 BoxPay. All right reserved
Fig. 5.1. Inline field creating friction in task completion
Fig. 5.2. The solution - separating the name input and mirroring it in the header
With the Rule Workspace ready, the next big piece was shaping the user journey. Like many of our competitors, I initially considered the standard 3-step flow:
✏️ Add a rule name and description
🧩 Define logic and assign a payment gateway
💾 Review and save the rule in a separate table
While this structure was functional, it felt unnecessarily stretched and repetitive. It didn’t align with my original goal of creating something fresh and intuitive. So, I took a different route - merging all three steps into a seamless, single-screen flow. This way, users could stay in one place, think less, do more, and build complex rules with fewer clicks and greater clarity.
When a user creates a new rule, the workspace appears right in place. Once completed, it neatly folds into a compact card - stacking vertically, much like Gmail threads. Want to add another? Just hit “Add New Rule”, and a fresh workspace drops right below the last.
Each rule minimises into a quick snapshot with an expandable chevron, making it easy to scan, edit, or revisit. No tab-hopping, no fragmented views - just one continuous, scrollable space that keeps everything tidy, intuitive, and in context.
Fig. 6.1. Initial approach – generic user flow found in most competitor products
💡💡💡
After spending a few days wrestling with how to merge the entire flow into a single screen, inspiration struck most unexpectedly - while sending an email. As I typed away in Gmail, I noticed how the compose window sits right within the inbox and how every new email simply stacks on top of the last, creating a neat, scrollable list. No separate screens, no back-and-forth.
That’s when it clicked - what if routing rules worked the same way?
Inspiration from Gmail’s smart compose
Some additional features locked in:
Saving or Activating
Rules can be activated or saved as drafts, with status tags for easy tracking and later edits.
Create New Rule
New rules stack below the old ones, Gmail-style — no need to switch pages.
Drafts That Wait for You
Not sure yet? Just leave it — your progress is saved as a draft so you can return and complete it anytime.
Full View or Quick Glance — Your Choice
Expand to view rule details, collapse to keep things clean and focused.
Change Priority at Will
Sorting & priority setting made simple with up/down arrows (P.S. drag & drop felt clunky for large cards).
Copy, Delete, Disable or Activate
Everything you need to build a rule — accessible in a single click.
By keeping the entire journey on one screen, users could:
▫️ Name the rule
▫️ Define logic
▫️ Choose gateways
▫️ Save or activate - all in one place
This single-screen approach cut down the creation time significantly and reduced navigation friction.
With the Rule Workspace ready, the next big piece was shaping the user journey. Like many of our competitors, I initially considered the standard 3-step flow:
✏️ Add a rule name and description
🧩 Define logic and assign a payment gateway
💾 Review and save the rule in a separate table
While this structure was functional, it felt unnecessarily stretched and repetitive. It didn’t align with my original goal of creating something fresh and intuitive. So, I took a different route - merging all three steps into a seamless, single-screen flow. This way, users could stay in one place, think less, do more, and build complex rules with fewer clicks and greater clarity.
When a user creates a new rule, the workspace appears right in place. Once completed, it neatly folds into a compact card - stacking vertically, much like Gmail threads. Want to add another? Just hit “Add New Rule”, and a fresh workspace drops right below the last.
Each rule minimises into a quick snapshot with an expandable chevron, making it easy to scan, edit, or revisit. No tab-hopping, no fragmented views - just one continuous, scrollable space that keeps everything tidy, intuitive, and in context.
Fig. 6.1. Initial approach – generic user flow found in most competitor products
💡💡💡
After spending a few days wrestling with how to merge the entire flow into a single screen, inspiration struck most unexpectedly - while sending an email. As I typed away in Gmail, I noticed how the compose window sits right within the inbox and how every new email simply stacks on top of the last, creating a neat, scrollable list. No separate screens, no back-and-forth.
That’s when it clicked - what if routing rules worked the same way?
Inspiration from Gmail’s smart compose
Some additional features locked in:
Saving or Activating
Rules can be activated or saved as drafts, with status tags for easy tracking and later edits.
Create New Rule
New rules stack below the old ones, Gmail-style — no need to switch pages.
Drafts That Wait for You
Not sure yet? Just leave it — your progress is saved as a draft so you can return and complete it anytime.
Full View or Quick Glance — Your Choice
Expand to view rule details, collapse to keep things clean and focused.
Change Priority at Will
Sorting & priority setting made simple with up/down arrows (P.S. drag & drop felt clunky for large cards).
Copy, Delete, Disable or Activate
Everything you need to build a rule — accessible in a single click.
By keeping the entire journey on one screen, users could:
▫️ Name the rule
▫️ Define logic
▫️ Choose gateways
▫️ Save or activate - all in one place
This single-screen approach cut down the creation time significantly and reduced navigation friction.
Once the design was locked in, it moved into development - a phase that wrapped up smoothly within three weeks.
I collaborated closely with the front-end and QA teams to ensure the implementation stayed true to the design, down to the last pixel. During this phase, I flagged a few minor UI inconsistencies and bugs, which were quickly resolved during dev handoff.
With everything polished, the feature was deployed to the sandbox environment - ready for real-world testing and feedback.
We then ran a final round of user testing - this time with internal teams, a few merchants, and even some friends and family. The response was overwhelmingly positive - users genuinely enjoyed the fresh, intuitive approach and expressed delight in how effortless the feature felt.
Development and final round of testing
Even before full-scale launch, early indicators pointed to strong adoption and usability wins:
✅ 13/13 use cases passed using the new interface (including complex routing conditions with BIN, network, and card-type logic)
✅ 80% success rate in first-time usability tests with non-technical users. Supported advanced logic, yet stayed simple for all user types
✅ Consistent feedback from stakeholders: “Feels intuitive - like creating a Gmail filter.”
✅ Reduced steps from 3 to 1, saving time and reducing merchant drop-offs
✅ Final tweaks (like editable inline fields) added after testing - led to 100% clarity in the final round
✅ Presenting this feature to potential clients helped onboard 2 new merchants - bringing the total number of partners to 33.
Impact? Oh, It Made Some Noise!
The journey of building this feature came with a few unexpected (but valuable) lessons:
👉🏻 Inspiration doesn’t always strike in brainstorming sessions - sometimes, it arrives in your inbox, mid-email and with time.
👉🏻 The KISS (Keep it Simple, Stupid) rule is gold. Not to try to build a spaceship when a bicycle will do to get started. Designing from simplicity gave me the clarity I needed to scale smarter.
👉🏻 People from different roles - sales, devs, friends outside tech - all brought in fresh perspectives. The more conversations I had, the sharper the design became.
While we kept the scope limited to a lean Version 1 to measure response and usability, we already had a few exciting enhancements on the radar:
• Filters - allowing users to search and sort through created rules by name, payment method, creation date, etc.
• Prioritisation Enhancements - giving users more granular control over rule order beyond manual stacking and tedious clicking of up and down arrows.
More to come, but we had to start somewhere - and starting with clarity felt like the right call.
Hindsight, Foresight, and All the Bright Sides
