V
V
V
.
This oneâs for the larger screen, Switch your display for a fantastic reveal.
V
V
V
.
CONTACT
RESUME
Understanding the Users
Tenant Admin
Toby Hector | 40 years
Role
Tenant Admin at multinational bank
Goals
Set up and maintain all users across tenancies
Ensure correct entitlements without breaking compliance
Minimize manual data entry and redundant setup
Tools Used
Oracle FS Cloud
Excel / internal tracking sheets
IDCS (for user login config)
Tech Comfort
đ Moderate â comfortable with enterprise tools
Needs
A clear, step-by-step setup process
Central visibility into whatâs configured vs. whatâs missing
Guardrails to prevent misconfigurations
Pain Points
Confusing terminology (âParty,â âTransaction Groupâ)
No centralized view across tenancies
Repeating similar setups in three places (Non-Prod, Pre-Prod, Prod)
Prish Shah | 31 years
Operator
Role
Customer Service Representative
Goals
Access only the tools and services needed to assist customers
Avoid errors that delay daily operations
Know who to contact if somethingâs wrong
Tools Used
Oracle FS Cloud (limited modules)
Internal ticketing/chat tools
Tech Comfort
đĄ Light user, task-based
Needs
Simple, intuitive navigation
Clear access error messaging
Zero learning curve
Pain Points
Gets âaccess deniedâ messages without knowing why
Doesnât know who assigned their permissions
UI feels admin-centric, not role-centric
Ayesh Khan | 38 years
Oracle Product Owner
Role
Internal product owner defining default configurations
Goals
Define standard configurations that work across markets
Reduce customer onboarding time
Ensure UI reflects the business logic behind access control
Tools Used
Internal config dashboards
Design documentation tools (like Confluence, Figma)
Support ticket dashboards
Tech Comfort
đ˘Expert technical knowledge
Needs
Internal config dashboards
Design documentation tools (like Confluence, Figma)
Support ticket dashboards
Pain Points
Canât visualize how customers are configuring post-setup
Terminology used in UI sometimes drifts from backend model
Hard to troubleshoot customer errors without visibility
Use Case Examples
Some common user scenarios I mapped and designed for:
A new employee being onboarded as an Operator across 3 tenancies.
A team lead creating a User Group for âCustomer Supportâ and assigning common transactions.
A bank admin checking why an Operatorâs access to a transaction was denied.
Entitlements
Oracle | Nov 2024
A scalable configuration system for managing users, roles, and access across multi-tenant financial services.
DESCRIPTION
This wasnât just about setting permissions. It was about building the foundational system that helps financial institutions stay secure, compliant, and scalable - without relying on engineering every time access needs change.
ROLE
User Experience Designer II
DURATION
3 months
Overview
Oracle Financial Services Cloud powers digital banking experiences for institutions across the globe. As part of this cloud-native ecosystem, I worked on the Entitlements module, a foundational configuration layer that helps banks manage user roles, permissions, and secure access across multiple tenancies.
đĄ
Think of it as the access control brain behind cloud-based banking ensuring the right people get the right access, at the right time, with complete control and clarity.
In the financial world, access = power.
But with that power comes an overwhelming amount of complexity - multiple tenancies, dozens of user roles, and security regulations that vary across regions. When Oracle Financial Services shifted to a cloud-native SaaS model, it opened up a whole new world of multi-tenant architecture. Which is amazing. But also? That meant customers (aka banks and financial institutions) suddenly had to deal with:
My Roles and Responsibilities
As a User Experience Designer II at Oracle Financial Services, I owned the end-to-end UX journey for the Entitlements module from messy backend logic to a clean, scalable interface.
Defined user flows for managing roles, permissions, and access across multiple tenancies
Structured a scalable system architecture for managing users, roles, and entitlements
Conducted stakeholder interviews to gather business needs and understand technical constraints
Mapped technical dependencies and constraints using ERDs and internal documentation
Ensured accessibility, consistency, and usability across devices
Designed wireframes, prototypes, and final UI specs with accessibility and scalability in mind
Iterated continuously based on internal feedback from product, engineering, and support teams
The Challenges
Fragmented Access Configuration Across Tenancies
Fragmented Access Configuration Across Tenancies
Fragmented Access Configuration Across Tenancies
Complex Role and Entitlement Management
Fragmented Access Configuration Across Tenancies
Absence of a Centralized, User-Friendly Configuration Interface
So the big question became:
How do we enable our enterprise customers to configure user access and entitlements securely, easily, and at scale across multiple tenancies and services?
This wasnât a feature update. This was foundational.
Strategic Focus Areas
Before jumping into screens and flows, I aligned with stakeholders on what this module needed to achieve not just technically, but experientially. Hereâs what shaped every design decision I made:
Clarity over Complexity
Enterprise systems tend to overwhelm with dense forms and nested logic. My first goal was to simplify without oversimplifying surface only whatâs needed at each step, and explain what it means.
Scalability from Day One
This wasnât a one-size-fits-all tool. Banks vary in structure, regions, and compliance needs. The system needed to handle hundreds of roles, user groups, and entitlements without breaking or confusing.
Security Without Friction
Access control is about safety but poor UX can lead to misconfigurations or dangerous shortcuts. I designed flows to be error-proof, with validation, visual feedback, and guardrails built in.
Configuration, Not Code
Admins shouldnât have to think like developers. This needed to feel like setting up a system, not writing one. Every interaction aimed to reduce the cognitive load of technical setup.
Understanding the System
Designing an intuitive experience wasnât just about wireframes it was about understanding how things worked behind the scenes. I had to translate complex backend logic into workflows admins could confidently navigate.
Studying the System Architecture
I worked closely with solution architects and engineers to study ERD diagrams and configuration dependencies â not to design like a developer, but to think like the system so I could design against it.
Note: All visual diagrams have been redacted or abstracted to comply with NDA requirements.
User access was multi-layered and entity-driven: First, a person was created as an Employee, then onboarded as an Operator, grouped into a User Group, which was finally mapped to Transaction Groups.
One user â one role: Users could hold different roles across tenancies and services making flexible, modular UI a must.
No visual mapping of system dependencies: Relationships between entities like User Groups, Operators, and Transaction Groups existed only in backend logic.
Key Design Takeaways
Created form flows that mirrored system logic but kept the UI language clean and human.
Built in step-by-step validation to prevent incomplete or misconfigured setups.
Planned a layout that worked across all tenancy types without duplication of effort
Outcome
Designing the EmployeeâOperator onboarding flow wasnât just a UI uplift - it directly improved how administrators manage access in Oracle Financial Services Cloud.
Faster & More Confident Onboarding
Admins no longer felt lost in complex setups. By breaking the flows into smaller, guided steps, they could create and onboard users without backend help or support tickets.
Reduced Configuration Errors
Clearer field guidance, role explanations, and validations led to a measurable drop in misconfigured user setups. Error rates during user creation dropped by approx. 30%, based on internal feedback and mock user testing cycles.
Saved Admin Time Across Tenancies
Though users still needed to be created per tenancy (Non-Prod, Pre-Prod, Prod), the streamlined flow reduced repeated effort through pre-filled patterns and smarter defaults.
Increased Trust in Access Control
The added transparency in login setup and access visibility helped admins feel more confident that users only had access to what they needed, nothing more.
âď¸ Better visibility = fewer accidental over-entitlementsâď¸ Better UX = fewer help desk escalations
High Technical Dependency
Only developers could define or debug logic. Domain experts and non-technical admins had no visibility or control.
Reflections and Learning
Designing for financial access control at an enterprise scale taught me more than just how to create flows - it pushed me to think like a system architect, a business analyst, and a support rep⌠all at once.
Key Takeaways-
Systems thinking is everything: What seemed like a âsimpleâ user creation flow was deeply tied to backend logic, tenancy configurations, and role hierarchies. Understanding those dependencies early made my designs stronger and more future-proof.
Complexity Isnât the Enemy, Ambiguity Is: Admins can handle complexity â what they canât handle is confusion. The biggest wins came not from reducing features, but from adding just the right clarity, feedback, and structure.
Enterprise â Boring: Even âadminâ tools deserve intuitive, human-centered experiences. Designing with empathy for enterprise users who are often under pressure and overloaded led to better outcomes and a more respectful UX.
Things Iâd Do Differently:
More hands-on user testing: Since this was a brand new product, we worked with proxy users â but Iâd push harder to simulate more realistic usage with real admins.
Earlier glossary alignment: Terminology differences between business, backend, and UI caused friction â aligning this sooner wouldâve reduced rework.
Push for more cross-tenancy automation: Even if technically complex, Iâd love to explore how we could sync operators across environments more seamlessly in future version
Enterprise UX isnât about simplifying the system, itâs about clarifying it.
And that clarity, when done right, can unlock incredible speed, trust, and scale.
Tekion | Jan 2025
Parts Purchase
Order
See Next Project
đ This project is under NDA.
This project is currently live and in use by Oracle Financial Services customers, but due to NDA constraints and the sensitive nature of enterprise banking configurations, I cannot share final UI screens or flows. That said, the strategy, decisions, and UX approach documented below reflect my direct contribution to the design.
01.
This wasnât just Access Control, It was Identity Crisis.
In theory, access control should be simple: create a user, assign a role, done. But in reality? The same user could exist in three different environments - Non-Prod, Pre-Prod, and Prod with different roles, incomplete setups, or worse... no record at all. Thatâs because the system treated users like isolated checkboxes:
Employee
Employee
+
+
?
Operator
Not Visible
Non-Prod
Pre-Pod
Prod
You would onboard someone as an Employee in one tenancyâŚ
Convert them to an Operator in anotherâŚ
And then completely lose sight of them in the third.
đ§ Solution
So, instead of forcing admins to guess where someone was onboarded (or wasnât). I designed a centralised access snapshot for each user. This interface showed:
Where the person existed (and where they didnât).
What role they held in each tenancy.
What transactions they had access to.
When and how their Operator profile was created.
This didn't just reduce confusion - it helped prevent errors, improved trust, and gave admins a birdâs-eye view they never had before.
đŻ Impact
Reduced repeated onboarding by flagging gaps across environments.
Gave new admins clarity on how Employee â Operator â User.
Reduced TAP escalations caused by âmissing accessâ that was really just âmissing visibilityâ
02.
The real problem was Language
One of the subtlest blockers in this project wasnât logic or layout, it was language. Everyone used different words for the same thing:
Backend called them âPARTIESâ.
Business said âUSERSâ
Admins? They were just confused âEMPLOYEES, OPERATORS... Whatâs the difference?â
Worse, terms like âTransaction Group,â âUser Group,â and âEntitlementsâ were used interchangeably with subtle (but critical) distinctions. The result was confusion, rework and more TAP requests.
So I ran a mini-language audit
I interviewed stakeholders across roles and reviewed internal docs, field names, and UI labels. My goal was to align mental models without breaking technical accuracy. Hereâs is a simplified snapshot:
Term in Backend
Party
Operator
Txn Group
User
What Business Means
A person
System access role
Set of permissions
Final access object
Updated UI Label
Employee
Operator Profile
Transaction Group
System User
đ§ Design Decision: Clarity First
Rewrote tooltips, field labels, and section headers in plain language.
Added in-line definitions where confusion was common.
Created a glossary doc shared across product, design, and docs teams.
đŻ Impact
Reduced back-and-forth during onboarding walkthroughs.
Helped Product and Dev agree on common terms which sped up alignment.
Reduced admin hesitation during setup.
Major Feature Upgrades
Design Decision: Streamlined the form with dynamic fields based on job type and removed redundant data points.
Impact:
1. Simplified Employee Creation Flow
- Reduced data entry time by ~30%.
- Lowered field error rates during setup.
- Helped admins onboard new employees faster and with more confidence.
Design Decision: Introduced a guided flow for converting employees to operators, with validation and smart associations.
Impact:
- Operator Onboarding Journey
- Cut onboarding friction by simplifying a multi-step process.
- Reduced misconfigurations, which previously led to TAP escalations.
- Helped new Admins get up to speed faster without training.
Design Decision: Added UI cues (tooltips, in-line explanations) to clearly explain how Employee â Operator, and when a User record is created.
Impact:
- Contextual Role Clarity
- Reduced admin confusion during setup.
- Improved comprehension during user creation â especially helpful for non-technical business admins.
- Addressed a key source of recurring TAP tickets.
Design Decision: Created a dashboard-like overview for each Operator showing tenancy-level access, reducing the need to navigate across modules.
Impact:
- Access Summary Snapshot
- Boosted Admin confidence in assigning roles.
- Reduced dependency on backend teams to verify access.
- Improved accuracy and visibility of entitlements configuration.
Understanding the Users
Tenant Admin
Toby Hector | 40 years
Role
Tenant Admin at multinational bank
Goals
Set up and maintain all users across tenancies
Ensure correct entitlements without breaking compliance
Minimize manual data entry and redundant setup
Tools Used
Oracle FS Cloud
Excel / internal tracking sheets
IDCS (for user login config)
Tech Comfort
đ Moderate â comfortable with enterprise tools
Needs
A clear, step-by-step setup process
Central visibility into whatâs configured vs. whatâs missing
Guardrails to prevent misconfigurations
Pain Points
Confusing terminology (âParty,â âTransaction Groupâ)
No centralized view across tenancies
Repeating similar setups in three places (Non-Prod, Pre-Prod, Prod)
Prish Shah | 31 years
Operator
Role
Customer Service Representative
Goals
Access only the tools and services needed to assist customers
Avoid errors that delay daily operations
Know who to contact if somethingâs wrong
Tools Used
Oracle FS Cloud (limited modules)
Internal ticketing/chat tools
Tech Comfort
đĄ Light user, task-based
Needs
Simple, intuitive navigation
Clear access error messaging
Zero learning curve
Pain Points
Gets âaccess deniedâ messages without knowing why
Doesnât know who assigned their permissions
UI feels admin-centric, not role-centric
Ayesh Khan | 38 years
Oracle Product Owner
Role
Internal product owner defining default configurations
Goals
Define standard configurations that work across markets
Reduce customer onboarding time
Ensure UI reflects the business logic behind access control
Tools Used
Internal config dashboards
Design documentation tools (like Confluence, Figma)
Support ticket dashboards
Tech Comfort
đ˘Expert technical knowledge
Needs
Internal config dashboards
Design documentation tools (like Confluence, Figma)
Support ticket dashboards
Pain Points
Canât visualize how customers are configuring post-setup
Terminology used in UI sometimes drifts from backend model
Hard to troubleshoot customer errors without visibility
Use Case Examples
Some common user scenarios I mapped and designed for:
A new employee being onboarded as an Operator across 3 tenancies.
A team lead creating a User Group for âCustomer Supportâ and assigning common transactions.
A bank admin checking why an Operatorâs access to a transaction was denied.
Entitlements
Oracle | Nov 2024
A scalable configuration system for managing users, roles, and access across multi-tenant financial services.
DESCRIPTION
This wasnât just about setting permissions. It was about building the foundational system that helps financial institutions stay secure, compliant, and scalable - without relying on engineering every time access needs change.
ROLE
User Experience Designer II
DURATION
3 months
Overview
Oracle Financial Services Cloud powers digital banking experiences for institutions across the globe. As part of this cloud-native ecosystem, I worked on the Entitlements module, a foundational configuration layer that helps banks manage user roles, permissions, and secure access across multiple tenancies.
đĄ
Think of it as the access control brain behind cloud-based banking ensuring the right people get the right access, at the right time, with complete control and clarity.
In the financial world, access = power.
But with that power comes an overwhelming amount of complexity - multiple tenancies, dozens of user roles, and security regulations that vary across regions. When Oracle Financial Services shifted to a cloud-native SaaS model, it opened up a whole new world of multi-tenant architecture. Which is amazing. But also? That meant customers (aka banks and financial institutions) suddenly had to deal with:
My Roles and Responsibilities
As a User Experience Designer II at Oracle Financial Services, I owned the end-to-end UX journey for the Entitlements module from messy backend logic to a clean, scalable interface.
Defined user flows for managing roles, permissions, and access across multiple tenancies
Structured a scalable system architecture for managing users, roles, and entitlements
Conducted stakeholder interviews to gather business needs and understand technical constraints
Mapped technical dependencies and constraints using ERDs and internal documentation
Ensured accessibility, consistency, and usability across devices
Designed wireframes, prototypes, and final UI specs with accessibility and scalability in mind
Iterated continuously based on internal feedback from product, engineering, and support teams
The Challenges
Fragmented Access Configuration Across Tenancies
Fragmented Access Configuration Across Tenancies
Fragmented Access Configuration Across Tenancies
Complex Role and Entitlement Management
Fragmented Access Configuration Across Tenancies
Absence of a Centralized, User-Friendly Configuration Interface
So the big question became:
How do we enable our enterprise customers to configure user access and entitlements securely, easily, and at scale across multiple tenancies and services?
This wasnât a feature update. This was foundational.
Strategic Focus Areas
Before jumping into screens and flows, I aligned with stakeholders on what this module needed to achieve not just technically, but experientially. Hereâs what shaped every design decision I made:
Clarity over Complexity
Enterprise systems tend to overwhelm with dense forms and nested logic. My first goal was to simplify without oversimplifying surface only whatâs needed at each step, and explain what it means.
Scalability from Day One
This wasnât a one-size-fits-all tool. Banks vary in structure, regions, and compliance needs. The system needed to handle hundreds of roles, user groups, and entitlements without breaking or confusing.
Security Without Friction
Access control is about safety but poor UX can lead to misconfigurations or dangerous shortcuts. I designed flows to be error-proof, with validation, visual feedback, and guardrails built in.
Configuration, Not Code
Admins shouldnât have to think like developers. This needed to feel like setting up a system, not writing one. Every interaction aimed to reduce the cognitive load of technical setup.
Understanding the System
Designing an intuitive experience wasnât just about wireframes it was about understanding how things worked behind the scenes. I had to translate complex backend logic into workflows admins could confidently navigate.
Studying the System Architecture
I worked closely with solution architects and engineers to study ERD diagrams and configuration dependencies â not to design like a developer, but to think like the system so I could design against it.
Note: All visual diagrams have been redacted or abstracted to comply with NDA requirements.
User access was multi-layered and entity-driven: First, a person was created as an Employee, then onboarded as an Operator, grouped into a User Group, which was finally mapped to Transaction Groups.
One user â one role: Users could hold different roles across tenancies and services making flexible, modular UI a must.
No visual mapping of system dependencies: Relationships between entities like User Groups, Operators, and Transaction Groups existed only in backend logic.
Key Design Takeaways
Created form flows that mirrored system logic but kept the UI language clean and human.
Built in step-by-step validation to prevent incomplete or misconfigured setups.
Planned a layout that worked across all tenancy types without duplication of effort
Outcome
Designing the EmployeeâOperator onboarding flow wasnât just a UI uplift - it directly improved how administrators manage access in Oracle Financial Services Cloud.
Faster & More Confident Onboarding
Admins no longer felt lost in complex setups. By breaking the flows into smaller, guided steps, they could create and onboard users without backend help or support tickets.
Reduced Configuration Errors
Clearer field guidance, role explanations, and validations led to a measurable drop in misconfigured user setups. Error rates during user creation dropped by approx. 30%, based on internal feedback and mock user testing cycles.
Saved Admin Time Across Tenancies
Though users still needed to be created per tenancy (Non-Prod, Pre-Prod, Prod), the streamlined flow reduced repeated effort through pre-filled patterns and smarter defaults.
Increased Trust in Access Control
The added transparency in login setup and access visibility helped admins feel more confident that users only had access to what they needed, nothing more.
âď¸ Better visibility = fewer accidental over-entitlementsâď¸ Better UX = fewer help desk escalations
High Technical Dependency
Only developers could define or debug logic. Domain experts and non-technical admins had no visibility or control.
Reflections and Learning
Designing for financial access control at an enterprise scale taught me more than just how to create flows - it pushed me to think like a system architect, a business analyst, and a support rep⌠all at once.
Key Takeaways-
Systems thinking is everything: What seemed like a âsimpleâ user creation flow was deeply tied to backend logic, tenancy configurations, and role hierarchies. Understanding those dependencies early made my designs stronger and more future-proof.
Complexity Isnât the Enemy, Ambiguity Is: Admins can handle complexity â what they canât handle is confusion. The biggest wins came not from reducing features, but from adding just the right clarity, feedback, and structure.
Enterprise â Boring: Even âadminâ tools deserve intuitive, human-centered experiences. Designing with empathy for enterprise users who are often under pressure and overloaded led to better outcomes and a more respectful UX.
Things Iâd Do Differently:
More hands-on user testing: Since this was a brand new product, we worked with proxy users â but Iâd push harder to simulate more realistic usage with real admins.
Earlier glossary alignment: Terminology differences between business, backend, and UI caused friction â aligning this sooner wouldâve reduced rework.
Push for more cross-tenancy automation: Even if technically complex, Iâd love to explore how we could sync operators across environments more seamlessly in future version
Enterprise UX isnât about simplifying the system, itâs about clarifying it.
And that clarity, when done right, can unlock incredible speed, trust, and scale.
Tekion | Jan 2025
Parts Purchase
Order
See Next Project
đ This project is under NDA.
This project is currently live and in use by Oracle Financial Services customers, but due to NDA constraints and the sensitive nature of enterprise banking configurations, I cannot share final UI screens or flows. That said, the strategy, decisions, and UX approach documented below reflect my direct contribution to the design.
01.
This wasnât just Access Control, It was Identity Crisis.
In theory, access control should be simple: create a user, assign a role, done. But in reality? The same user could exist in three different environments - Non-Prod, Pre-Prod, and Prod with different roles, incomplete setups, or worse... no record at all. Thatâs because the system treated users like isolated checkboxes:
Employee
Employee
+
+
?
Operator
Not Visible
Non-Prod
Pre-Pod
Prod
You would onboard someone as an Employee in one tenancyâŚ
Convert them to an Operator in anotherâŚ
And then completely lose sight of them in the third.
đ§ Solution
So, instead of forcing admins to guess where someone was onboarded (or wasnât). I designed a centralised access snapshot for each user. This interface showed:
Where the person existed (and where they didnât).
What role they held in each tenancy.
What transactions they had access to.
When and how their Operator profile was created.
This didn't just reduce confusion - it helped prevent errors, improved trust, and gave admins a birdâs-eye view they never had before.
đŻ Impact
Reduced repeated onboarding by flagging gaps across environments.
Gave new admins clarity on how Employee â Operator â User.
Reduced TAP escalations caused by âmissing accessâ that was really just âmissing visibilityâ
02.
The real problem was Language
One of the subtlest blockers in this project wasnât logic or layout, it was language. Everyone used different words for the same thing:
Backend called them âPARTIESâ.
Business said âUSERSâ
Admins? They were just confused âEMPLOYEES, OPERATORS... Whatâs the difference?â
Worse, terms like âTransaction Group,â âUser Group,â and âEntitlementsâ were used interchangeably with subtle (but critical) distinctions. The result was confusion, rework and more TAP requests.
So I ran a mini-language audit
đ§ Design Decision: Clarity First
Rewrote tooltips, field labels, and section headers in plain language.
Added in-line definitions where confusion was common.
Created a glossary doc shared across product, design, and docs teams.
đŻ Impact
Reduced back-and-forth during onboarding walkthroughs.
Helped Product and Dev agree on common terms which sped up alignment.
Reduced admin hesitation during setup.
Major Feature Upgrades
Design Decision: Streamlined the form with dynamic fields based on job type and removed redundant data points.
Impact:
1. Simplified Employee Creation Flow
- Reduced data entry time by ~30%.
- Lowered field error rates during setup.
- Helped admins onboard new employees faster and with more confidence.
Design Decision: Introduced a guided flow for converting employees to operators, with validation and smart associations.
Impact:
- Operator Onboarding Journey
- Cut onboarding friction by simplifying a multi-step process.
- Reduced misconfigurations, which previously led to TAP escalations.
- Helped new Admins get up to speed faster without training.
Design Decision: Added UI cues (tooltips, in-line explanations) to clearly explain how Employee â Operator, and when a User record is created.
Impact:
- Contextual Role Clarity
- Reduced admin confusion during setup.
- Improved comprehension during user creation â especially helpful for non-technical business admins.
- Addressed a key source of recurring TAP tickets.
Design Decision: Created a dashboard-like overview for each Operator showing tenancy-level access, reducing the need to navigate across modules.
Impact:
- Access Summary Snapshot
- Boosted Admin confidence in assigning roles.
- Reduced dependency on backend teams to verify access.
- Improved accuracy and visibility of entitlements configuration.
V
V
V
.
CONTACT
RESUME