V
V
V
.
This one’s for the larger screen, Switch your display for a fantastic reveal.
Oracle | May 2025
Business Rule
Redefining how decision logic is authored and scaled across Oracle’s financial communications - moving from monolithic templates to modular, rule-based design.
DESCRIPTION
The Business Rule domain was introduced as part of Oracle’s shift toward modular, rule-driven communications. Previously, logic was buried inside rigid assembly templates - making updates risky, iterations hard to manage, and ownership limited to technical teams.
This project focused on designing a zero-to-one interface where domain experts could define, visualize, and reuse business logic without touching code.
ROLE
User Experience Designer II
DURATION
2 months
Our Design Goals
This wasn’t just about designing a form builder. It was about shifting power:
From developers → to business users.
From hardcoded logic → to modular, maintainable systems.
From hidden rules → to visible, testable ones
Design a rule-building experience that speaks business, not code
Create an interface where users can define logic using intuitive, readable conditions without needing technical fluency.
Make rules modular,
reusable, and easy to manage at scale
Treat every rule as a standalone, versioned object that can be shared across templates, updated safely, & audited with confidence.
Help users understand and test logic before it goes live to the customers
Build in clear visual feedback, simulated previews, and outcome testing to catch logic issues early and reduce rollout risk.
My Roles and Responsibilities
I led the end-to-end UX design for the Business Rule domain - from navigating system complexity to designing a brand new, zero-to-one interface for rule creation.
Understanding domain logic: Collaborated with PMs, architects, and solution engineers to deeply understand how rules drive communications.
Mapping user journeys: Interviewed internal stakeholders (like implementation teams and product owners) to identify user needs, workflows, and decision points.
Designing the rule authoring experience: Created flows, wireframes, and prototypes for a no-code, modular rule builder.
System modelling: Worked closely with backend and platform teams to ensure UX aligned with how rules were actually structured, stored, and executed. Mapped technical dependencies and constraints using ERDs and internal documentation.
Handling edge cases: Defined UX for complex logic scenarios including nested conditions, data iteration, and version testing
Stakeholder buy-in: Led design walkthroughs to get alignment from cross-functional teams and validate usability at each stage.
Understanding the System
Before Business Rule could succeed, I needed to understand where it fits within Oracle's new modular communication ecosystem - and how it was meant to replace the old assembly-template flow.
The Old Flow:
Assembly Templates
All logic, layout, and data transformations lived inside one giant JSON file
Logic was hardcoded and deeply nested (especially for iterations)
Developers were needed to parse it, update it, and debug it
Any payload change meant manually fixing the template
The New Architecture:
Modular & Decoupled
To fix this, Oracle introduced three independent domains:
User Defined Data (UDD)
Transforms and standardizes incoming data fields
Business Rule
Applies conditional logic based on user or data attributes
Content Control
Selects the right template based on business logic
So, if a customer gets a letter when they add a new beneficiary:
UDD formats the incoming payload
Business Rule checks “Did the user add a new beneficiary?”
Content Control triggers the appropriate communication template
And the best part? These rules can now be written, viewed, and tested in a UI, not in code.
Understanding the ERD Diagram
Before diving into wireframes or flows, I studied the Entity Relationship Diagram (ERD) provided by the product and backend teams to understand how business rules were structured at a system level.
The ERD helped me:
Map the structure of a rule: including how condition groups, individual conditions, and outcomes are stored and connected.
Understand versioning: how different versions of a rule would be tracked and applied.
Visualize nesting: how AND/OR conditions, iterations, and branching logic could be modeled.
Spot technical constraints: like which entities are reusable, what’s hardcoded, and which pieces connect to UDD or Content Control.
This technical grounding gave me the clarity to design interfaces that weren't just usable - they were aligned with how the system actually worked behind the scenes.
While the ERD wasn’t visible to users, it directly influenced key UX decisions from how rules are grouped, to how conditions are authored, to how test outcomes are attached.
Key UX Decisions
Designing the Business Rule builder wasn’t a linear journey. It involved constant back-and-forth between user mental models and system constraints. I worked through multiple iterations, balancing usability, modularity, and technical feasibility at every step.
If [field] [equals] [value] → then [do this]
The first challenge was figuring out how to visually represent logic that was previously written in deeply nested JSON. I broke down real examples from existing assembly templates and reverse-mapped them into flows like:
Then I asked:
How would a business user naturally explain this? How do they think?
This shaped the base structure of the builder:
- Condition blocks (field + operator + value)
- Group logic (AND/OR conditions)
- Outcome blocks (what should happen if true)
1. Early Exploration: From JSON to UI
Instead of a single-page form, I designed the rule builder as composable blocks - using Redwood cards, grouped containers, dropdown selectors, and inline inputs.
Each part of a rule (condition, logic group, outcome) became a standalone UI component.
This made the experience:
- Easier to understand at a glance
- Easier to maintain when rules got complex
- Visually consistent with Oracle Redwood patterns
2. Modular Component Thinking
Some of the hardest UX challenges came from supporting things like:
- Checking conditions inside a list (e.g., “If any of the user’s accounts are inactive…”)
- Supporting nested AND/OR logic (e.g., “If age > 60 AND [product is Gold OR account type is Savings]”)
I used:
- Indentation + iconography to show nesting
- Inline tooltips to explain what "iteration" or "group logic" meant
- Expand/collapse affordances to reduce visual clutter
3. Nested Logic & Iteration Handling
To build trust, I designed a side drawer where users could input mock data (like sample user JSON) and immediately see:
- Whether the rule matched
- What outcome it returned
- Which condition failed (if any)
This gave users feedback early without writing a single line of code or pushing anything live.
4. Testing Panel for Outcome Validation
Each rule came with:
- Draft + publish states
- A built-in version history viewer
- Validation checks before saving or publishing
This was especially important in banking, where one wrong rule can mean thousands of incorrect communications sent.
5. Safe Authoring & Versioning
Reflections and Learning
This project taught me that designing for complexity doesn’t mean simplifying the problem, it means helping users navigate it with confidence.
Key Takeaways-
Systems thinking is everything: Understanding the ERD, backend logic, and data flow helped me design interfaces that weren’t just pretty, they were possible, aligned, and scalable.
Modularity is a UX superpower: Decoupling logic into standalone, reusable blocks made the product more flexible, the UI more maintainable, and the experience less overwhelming.
Redwood brought constraints - and clarity: Designing within a mature design system like Redwood pushed me to work smarter, not just creatively. It made me think in patterns, components, and reusability.
No-code doesn’t mean low expectations: The goal wasn’t just to simplify, it was to elevate. I had to design for users who were smart, strategic, and detail-oriented just not technical.
UX vs. Dev Tensions Are Opportunities: I fought for the drag and drop feature but we didn’t ship it. And that’s okay. Working closely with devs taught me to translate “UX dreams” into “realistic wins” and lay groundwork for future layers.
I walked into this project trying to understand a messy JSON template.
I walked out having designed a platform that lets domain experts ship logic without touching code. And to me, that’s what UX is all about - turning friction into flow.
See Next Project
Oracle | Aug 2024
Entitlements
Understanding the Users
Business Logic Owner
"I know the rules, I just don’t want to mess them up in code."
Tenant Configuration Analyst
"I keep getting bugs for rules I didn’t even write."
Role
Integration Developer / Backend Engineer
Responsibility
Implements the assembly template logic, fixes issues in production
Background
Strong technical knowledge, not close to business logic decisions
Goals
Hand off logic ownership to domain experts
Work with cleaner, modular rule definitions
Reduce time spent debugging logic bugs
Pain Points
Often acts as a translator between business and JSON
Gets pulled into issues caused by unclear rule definitions
No UI visibility into what logic is running where
Tech Comfort
🟢 Expert – Strong technical knowledge
Role
Analyst / Implementation Specialist
Responsibility
Defines when, how, and to whom a communication should be triggered
Background
Understands the product and regulatory requirements deeply, but doesn’t write code
Goals
Define and manage rules independently
Preview how rules behave with different inputs
Reduce dependency on engineering
Pain Points
Needs developer support for even small logic updates
No way to test or visualize logic before going live
Repeats the same logic across multiple templates manually
Tech Comfort
🟠 Moderate – Intermediate (used to web apps, but not dev tools)
Shared Needs Across Users
Design a rule-building
experience that speaks
business, not code
Make rules modular, reusable,
and easy to manage at scale
Help users understand and test logic before it goes live to the customers
The Challenges
Tightly Coupled Structure
All logic, layout, and data dependencies were bundled inside the assembly template — creating fragile connections that broke easily with any change.
No Modularity or Reusability
Logic and conditions were hardcoded and duplicated across templates, making updates tedious and error-prone.
Iteration Was a Black Box
Repeating data (like lists of accounts or beneficiaries) was handled through complex, nested JSON — invisible to most users.
Rigid Layout Expectations
Incoming data had to exactly match Oracle’s template structure. Any deviation in the source payload broke the output.
High Technical Dependency
Only developers could define or debug logic. Domain experts and non-technical admins had no visibility or control.
Overview
Let’s say a bank needs to notify a customer that their account has been created, or that a new beneficiary was added. That communication may include the customer’s name, address, account number, and dynamic content based on their location or product type. Sounds simple — but at scale, this means triggering the right template, mapping the right fields, and following strict logic based on business and regulatory rules.
This is where Oracle’s Communications module comes in - dynamically generating personalized, regulation-compliant letters for millions of users across institutions. When it comes to financial communications like statements, policy updates, and disclosures — every word (and its timing) matters.
But behind the scenes? Things weren’t so smooth.
Every single one of those communications was controlled by something called an Assembly Template - a massive JSON file that dictated:
- what data showed up
- how the layout was rendered
- and which logic conditions triggered what content
That meant every letter depended on a single, deeply entangled file. And that led to... well, CHAOS.
🔐 MVP in progress. Screens under wraps.
This project is still in active development, and since it’s early-stage (and under NDA), final interface screens and proprietary visuals cannot be shared. However, the process, design strategy, and learnings below reflect my direct role in shaping the product end-to-end.
UX vs. Dev. vs MVP: What We Prioritised
When building a MVP for a system this complex, perfection’s not the goal, progress is. Many of our most exciting ideas (automated field suggestions, AI-driven rule logic, dynamic optimisation) went straight into the backlog. And that’s okay.
UX Ambition
MVP Tradeoff
Future Vision
Auto-suggested fields + logic
Show flat searchable list with helpful tooltips
Plan to layer in field prediction via user history or AI
Natural language rule builder
Stick to dropdown-based condition blocks
Add a “generate rule from prompt” feature later
Fully drag and drop rule UI
Composable click to add blocks, Redwood aligned
Long term: optional drag surface for power users
Real time preview updates
Build test panel with mock data inputs
Future: auto-preview based on last used payload
AI rule suggestions based on common templates
Parked for now
Plan to suggest rules based on usage patterns + errors
Rule impact analyser (explain what the rule affects
Postponed
Future: “What this rule touches” map for risk visibility
Impact
Launching the Business Rule builder transformed how Oracle’s clients manage communication logic turning what used to be a dev-only, error-prone task into a scalable, self-serve workflow. Even without automation or AI (yet), the shift from hardcoded templates to modular, user-driven rules made an immediate difference:
From fragile JSON to flexible UX
80-90% of basic
login conditions
is now authored by domain experts - no engineers needed
Rules became modular
reused across templates instead of being duplicated and rewritten
Debugging time dropped significantly
as logic could be tested before going live
Versioning, Validation, and Visibility
are now built-in, reducing rollout risk in highly regulated financial environments
“This gives us way more control - I don’t have to Slack an engineer for every small change.”
“I love that I can test the rule before I make it live. That gives me real peace of mind.”
💬 Feedback from stakeholders
V
V
V
.
CONTACT
RESUME
Oracle | May 2025
Business Rule
Redefining how decision logic is authored and scaled across Oracle’s financial communications - moving from monolithic templates to modular, rule-based design.
DESCRIPTION
The Business Rule domain was introduced as part of Oracle’s shift toward modular, rule-driven communications. Previously, logic was buried inside rigid assembly templates - making updates risky, iterations hard to manage, and ownership limited to technical teams.
This project focused on designing a zero-to-one interface where domain experts could define, visualize, and reuse business logic without touching code.
ROLE
User Experience Designer II
DURATION
2 months
Our Design Goals
This wasn’t just about designing a form builder. It was about shifting power:
From developers → to business users.
From hardcoded logic → to modular, maintainable systems.
From hidden rules → to visible, testable ones
Design a rule-building experience that speaks business, not code
Create an interface where users can define logic using intuitive, readable conditions without needing technical fluency.
Make rules modular,
reusable, and easy to manage at scale
Treat every rule as a standalone, versioned object that can be shared across templates, updated safely, & audited with confidence.
Help users understand and test logic before it goes live to the customers
Build in clear visual feedback, simulated previews, and outcome testing to catch logic issues early and reduce rollout risk.
My Roles and Responsibilities
I led the end-to-end UX design for the Business Rule domain - from navigating system complexity to designing a brand new, zero-to-one interface for rule creation.
Understanding domain logic: Collaborated with PMs, architects, and solution engineers to deeply understand how rules drive communications.
Mapping user journeys: Interviewed internal stakeholders (like implementation teams and product owners) to identify user needs, workflows, and decision points.
Designing the rule authoring experience: Created flows, wireframes, and prototypes for a no-code, modular rule builder.
System modelling: Worked closely with backend and platform teams to ensure UX aligned with how rules were actually structured, stored, and executed. Mapped technical dependencies and constraints using ERDs and internal documentation.
Handling edge cases: Defined UX for complex logic scenarios including nested conditions, data iteration, and version testing
Stakeholder buy-in: Led design walkthroughs to get alignment from cross-functional teams and validate usability at each stage.
Understanding the System
Before Business Rule could succeed, I needed to understand where it fits within Oracle's new modular communication ecosystem - and how it was meant to replace the old assembly-template flow.
The Old Flow:
Assembly Templates
All logic, layout, and data transformations lived inside one giant JSON file
Logic was hardcoded and deeply nested (especially for iterations)
Developers were needed to parse it, update it, and debug it
Any payload change meant manually fixing the template
The New Architecture:
Modular & Decoupled
To fix this, Oracle introduced three independent domains:
User Defined Data (UDD)
Transforms and standardizes incoming data fields
Business Rule
Applies conditional logic based on user or data attributes
Content Control
Selects the right template based on business logic
So, if a customer gets a letter when they add a new beneficiary:
UDD formats the incoming payload
Business Rule checks “Did the user add a new beneficiary?”
Content Control triggers the appropriate communication template
And the best part? These rules can now be written, viewed, and tested in a UI, not in code.
Understanding the ERD Diagram
Before diving into wireframes or flows, I studied the Entity Relationship Diagram (ERD) provided by the product and backend teams to understand how business rules were structured at a system level.
The ERD helped me:
Map the structure of a rule: including how condition groups, individual conditions, and outcomes are stored and connected.
Understand versioning: how different versions of a rule would be tracked and applied.
Visualize nesting: how AND/OR conditions, iterations, and branching logic could be modeled.
Spot technical constraints: like which entities are reusable, what’s hardcoded, and which pieces connect to UDD or Content Control.
This technical grounding gave me the clarity to design interfaces that weren't just usable - they were aligned with how the system actually worked behind the scenes.
While the ERD wasn’t visible to users, it directly influenced key UX decisions from how rules are grouped, to how conditions are authored, to how test outcomes are attached.
Key UX Decisions
Designing the Business Rule builder wasn’t a linear journey. It involved constant back-and-forth between user mental models and system constraints. I worked through multiple iterations, balancing usability, modularity, and technical feasibility at every step.
If [field] [equals] [value] → then [do this]
The first challenge was figuring out how to visually represent logic that was previously written in deeply nested JSON. I broke down real examples from existing assembly templates and reverse-mapped them into flows like:
Then I asked:
How would a business user naturally explain this? How do they think?
This shaped the base structure of the builder:
- Condition blocks (field + operator + value)
- Group logic (AND/OR conditions)
- Outcome blocks (what should happen if true)
1. Early Exploration: From JSON to UI
Instead of a single-page form, I designed the rule builder as composable blocks - using Redwood cards, grouped containers, dropdown selectors, and inline inputs.
Each part of a rule (condition, logic group, outcome) became a standalone UI component.
This made the experience:
- Easier to understand at a glance
- Easier to maintain when rules got complex
- Visually consistent with Oracle Redwood patterns
2. Modular Component Thinking
Some of the hardest UX challenges came from supporting things like:
- Checking conditions inside a list (e.g., “If any of the user’s accounts are inactive…”)
- Supporting nested AND/OR logic (e.g., “If age > 60 AND [product is Gold OR account type is Savings]”)
I used:
- Indentation + iconography to show nesting
- Inline tooltips to explain what "iteration" or "group logic" meant
- Expand/collapse affordances to reduce visual clutter
3. Nested Logic & Iteration Handling
To build trust, I designed a side drawer where users could input mock data (like sample user JSON) and immediately see:
- Whether the rule matched
- What outcome it returned
- Which condition failed (if any)
This gave users feedback early without writing a single line of code or pushing anything live.
4. Testing Panel for Outcome Validation
Each rule came with:
- Draft + publish states
- A built-in version history viewer
- Validation checks before saving or publishing
This was especially important in banking, where one wrong rule can mean thousands of incorrect communications sent.
5. Safe Authoring & Versioning
Reflections and Learning
This project taught me that designing for complexity doesn’t mean simplifying the problem, it means helping users navigate it with confidence.
Key Takeaways-
Systems thinking is everything: Understanding the ERD, backend logic, and data flow helped me design interfaces that weren’t just pretty, they were possible, aligned, and scalable.
Modularity is a UX superpower: Decoupling logic into standalone, reusable blocks made the product more flexible, the UI more maintainable, and the experience less overwhelming.
Redwood brought constraints - and clarity: Designing within a mature design system like Redwood pushed me to work smarter, not just creatively. It made me think in patterns, components, and reusability.
No-code doesn’t mean low expectations: The goal wasn’t just to simplify, it was to elevate. I had to design for users who were smart, strategic, and detail-oriented just not technical.
UX vs. Dev Tensions Are Opportunities: I fought for the drag and drop feature but we didn’t ship it. And that’s okay. Working closely with devs taught me to translate “UX dreams” into “realistic wins” and lay groundwork for future layers.
I walked into this project trying to understand a messy JSON template.
I walked out having designed a platform that lets domain experts ship logic without touching code. And to me, that’s what UX is all about - turning friction into flow.
See Next Project
Oracle | Aug 2024
Entitlements
Understanding the Users
Business Logic Owner
"I know the rules, I just don’t want to mess them up in code."
Tenant Configuration Analyst
"I keep getting bugs for rules I didn’t even write."
Role
Integration Developer / Backend Engineer
Responsibility
Implements the assembly template logic, fixes issues in production
Background
Strong technical knowledge, not close to business logic decisions
Goals
Hand off logic ownership to domain experts
Work with cleaner, modular rule definitions
Reduce time spent debugging logic bugs
Pain Points
Often acts as a translator between business and JSON
Gets pulled into issues caused by unclear rule definitions
No UI visibility into what logic is running where
Tech Comfort
🟢 Expert – Strong technical knowledge
Role
Analyst / Implementation Specialist
Responsibility
Defines when, how, and to whom a communication should be triggered
Background
Understands the product and regulatory requirements deeply, but doesn’t write code
Goals
Define and manage rules independently
Preview how rules behave with different inputs
Reduce dependency on engineering
Pain Points
Needs developer support for even small logic updates
No way to test or visualize logic before going live
Repeats the same logic across multiple templates manually
Tech Comfort
🟠 Moderate – Intermediate (used to web apps, but not dev tools)
Shared Needs Across Users
Design a rule-building
experience that speaks
business, not code
Make rules modular, reusable,
and easy to manage at scale
Help users understand and test logic before it goes live to the customers
The Challenges
Tightly Coupled Structure
All logic, layout, and data dependencies were bundled inside the assembly template — creating fragile connections that broke easily with any change.
No Modularity or Reusability
Logic and conditions were hardcoded and duplicated across templates, making updates tedious and error-prone.
Iteration Was a Black Box
Repeating data (like lists of accounts or beneficiaries) was handled through complex, nested JSON — invisible to most users.
Rigid Layout Expectations
Incoming data had to exactly match Oracle’s template structure. Any deviation in the source payload broke the output.
High Technical Dependency
Only developers could define or debug logic. Domain experts and non-technical admins had no visibility or control.
Overview
Let’s say a bank needs to notify a customer that their account has been created, or that a new beneficiary was added. That communication may include the customer’s name, address, account number, and dynamic content based on their location or product type. Sounds simple — but at scale, this means triggering the right template, mapping the right fields, and following strict logic based on business and regulatory rules.
This is where Oracle’s Communications module comes in - dynamically generating personalized, regulation-compliant letters for millions of users across institutions. When it comes to financial communications like statements, policy updates, and disclosures — every word (and its timing) matters.
But behind the scenes? Things weren’t so smooth.
Every single one of those communications was controlled by something called an Assembly Template - a massive JSON file that dictated:
- what data showed up
- how the layout was rendered
- and which logic conditions triggered what content
That meant every letter depended on a single, deeply entangled file. And that led to... well, CHAOS.
🔐 MVP in progress. Screens under wraps.
This project is still in active development, and since it’s early-stage (and under NDA), final interface screens and proprietary visuals cannot be shared. However, the process, design strategy, and learnings below reflect my direct role in shaping the product end-to-end.
UX vs. Dev. vs MVP: What We Prioritised
When building a MVP for a system this complex, perfection’s not the goal, progress is. Many of our most exciting ideas (automated field suggestions, AI-driven rule logic, dynamic optimisation) went straight into the backlog. And that’s okay.
UX Ambition
MVP Tradeoff
Future Vision
Auto-suggested fields + logic
Show flat searchable list with helpful tooltips
Plan to layer in field prediction via user history or AI
Natural language rule builder
Stick to dropdown-based condition blocks
Add a “generate rule from prompt” feature later
Fully drag and drop rule UI
Composable click to add blocks, Redwood aligned
Long term: optional drag surface for power users
Real time preview updates
Build test panel with mock data inputs
Future: auto-preview based on last used payload
AI rule suggestions based on common templates
Parked for now
Plan to suggest rules based on usage patterns + errors
Rule impact analyser (explain what the rule affects
Postponed
Future: “What this rule touches” map for risk visibility
Impact
Launching the Business Rule builder transformed how Oracle’s clients manage communication logic turning what used to be a dev-only, error-prone task into a scalable, self-serve workflow. Even without automation or AI (yet), the shift from hardcoded templates to modular, user-driven rules made an immediate difference:
From fragile JSON to flexible UX
80-90% of basic
login conditions
is now authored by domain experts - no engineers needed
Rules became modular
reused across templates instead of being duplicated and rewritten
Debugging time dropped significantly
as logic could be tested before going live
Versioning, Validation, and Visibility
are now built-in, reducing rollout risk in highly regulated financial environments
“This gives us way more control - I don’t have to Slack an engineer for every small change.”
“I love that I can test the rule before I make it live. That gives me real peace of mind.”
💬 Feedback from stakeholders
V
V
V
.
CONTACT
RESUME