Designing a Payment Recovery Rule Builder for Revenue Teams
Data Realm is a software company serving ecommerce businesses. Repeated client requests for more control over payment recovery led the team to explore a new product using its existing backend expertise.
The team brought me in as the first designer to turn an early AI generated concept into a clear, usable workflow for revenue teams. I joined as the first designer and led product framing, research, interaction design, prototyping, and usability testing.
Status: Design handed off · In development · Target launch mid 2027
Note: This project was completed under NDA. I’ve simplified or recreated visuals and omitted confidential product details, client data, and proprietary information.
Problem
Revenue teams understood the recovery rules they wanted, but they relied on developers whenever those rules needed to change.
The harder problem was not understanding the business logic. It was knowing how to translate that logic into a valid configuration without making a mistake.
In early testing, participants often knew what they wanted the rule to do but hesitated when they had to decide where to start.
That became the core design challenge:
How might we help revenue teams configure payment recovery rules confidently without engineering support?
Prototype Testing Findings
Faster in repeat testing
Median task time fell from ~12mins to ~6mins across five participants.
Higher confidence
Clearer status and confirmation during rule creation
Validated the direction
Testing gave the team evidence to move forward with the guided rule builder
Narrowing the Opportunity
The project started with a broad goal: make payment recovery more proactive and easier to manage.
I used stakeholder interviews and workflow mapping to narrow that into a more focused first release.
The first version centered on two areas:
Rulesets Organize and manage groups of recovery rules.
Rule Building Create and edit the logic behind those rules.
This gave the team a clearer product boundary and helped us avoid trying to expose every backend capability at once.
Why I Chose a Structured Builder
The central interaction decision was how much flexibility to give users.
I explored three approaches.
Node Based Flow Builder
Flexible, but a quick survey suggested this approach was too complicated to use confidently.
Free Text to Rule
Engineering flagged that supporting free form rule logic would require much heavier validation and introduce more edge cases for the first release.
Block and Dropdown Builder
Made valid options visible and kept users within a controlled set of configurations.
Block and dropdown builder I chose the structured approach because it gave revenue teams enough flexibility without exposing the complexity underneath.
Tradeoff Less flexibility, but easier to understand and harder to get wrong.
The First Approach Still Created Uncertainty
I turned the structured concept into a high fidelity prototype and tested it with five participants.
I asked them to create an enterprise recovery rule:
When authorization fails, retry after 3 days for up to 2 attempts, then notify the business team by email.
Everyone could eventually complete the task, but I saw the same pattern across the group.
Participants hesitated before starting. After finding the create rule action, they were unsure what conditions and actions meant, what to choose first, and whether clicking the wrong option could create an invalid rule.
The interface exposed valid building blocks, but it still expected users to understand how those pieces fit together.
That changed the direction of the design.
Moving From Blocks to a Guided Sequence
Instead of asking users to assemble the logic more freely, I redesigned the builder around a clearer sequence.
I kept the structured block and dropdown controls, but reorganized them into a guided flow with a clear starting point, visible progress, and a final review before publishing.
1. Trigger What starts the recovery rule?
2. Retry timing When should the payment retry?
3. Attempt limit How many times should it retry?
4. Follow up action What happens after the final attempt?
The goal was to reduce uncertainty while keeping users in control of the rule.
Before Users had to interpret separate conditions and actions and decide where to start.
After The same structured controls appeared in a guided order: trigger → retry timing → attempt limit → notification → review.
Design principle Do not make users translate business logic into system logic on their own.
Repeat Prototype Testing
I tested with five participants who regularly worked with business rules and operational workflows.
Median task time fell from approximately 12 minutes to 6 minutes.
Because the same participants had already seen the task, familiarity may have contributed to the improvement.
I treat this as directional usability evidence rather than a controlled measure of product performance.
Participants also reported greater confidence with the guided flow, particularly around knowing what to do next and reviewing the rule before publishing.
Working With the Team
The team was new to working with UX, so I created a shared foundation for the project before moving into discovery.
I aligned the team on the product goals, UX approach, key questions, and expected deliverables, giving us a common reference point as the work evolved.
Working With AI
I used AI to speed up synthesis, market scanning, ideation, and critique.
I checked useful outputs against original sources, stakeholder input, technical constraints, and usability findings before carrying them into the design. I also kept confidential client data and proprietary product details out of external AI tools.
AI accelerated the work, but product framing and design decisions remained grounded in evidence from the team and participants.
What I Would Validate Next
If I continued the work, I would focus on three areas:
Adoption Whether revenue teams actually use the builder instead of relying on engineering.
Rule errors Whether users can configure and publish rules accurately in real workflows.
Time to change How quickly teams can update a recovery strategy when business conditions change.
I would also continue exploring governance features such as approvals, versioning, and rollback as more teams begin managing rules directly.
