OFSC Product | Parul Sharma

Oracle Financial Services Cloud

Modernizing Mid-Market Retail Banking with Oracle's Cloud-Based, API-Driven Solution

Product Design | Digital Transformation

Note: This is a broad, high-level summary of the product, intentionally kept general to ensure compliance with my Non-Disclosure Agreement

About the Project

Oracle Financial Services Cloud (OFSC) is a cloud-native, multi-tenant SaaS platform that modernizes banking operations for US mid-market retail banks.

With a microservices architecture, it offers scalability, flexibility, and rapid service deployment, while integrating automation, security, and API-driven customization to streamline workflows and enhance customer engagement.

Key Services

Communication Cloud Service – Enables real-time messaging for transactions, alerts, and compliance, enhancing customer engagement.
Deposit Origination Cloud Service – Automates account opening, onboarding, and verification, streamlining customer acquisition.
Deposit Servicing Cloud Service – Manages deposits, fund movements, interest calculations, and scheduled transactions.
Financial Services Marketplace Cloud Service – Connects banks with third-party providers and fintechs to expand services.

Business Goal

During kickoff, the Product Manager shared Oracle’s goal to modernize mid-market retail banking with a cloud-based, API-driven, and highly configurable solution, prioritizing efficiency, innovation, developer experience, scalability, and security.

My Role & Team

Role: Sr. UX Designer

Team: 11 (Including me, 2 Junior Designer's, Design Lead, Product Manager, Tech Lead & 5 Engineers)

Duration: Sept 2022 - Jan 2025

Outcome

One of the domains I worked on led to significant improvements, including:

40% Reduction in Manual Effort – Pre-built templates simplified configuration.

25% Increase in Operational Efficiency – Optimized workflows improved processing speed.

50% Improvement in API Integration Time – Enhanced API documentation enabled faster adoption.

20% Reduction in User Errors

Project Kickoff - Clarifying UX Priorities

After understanding the business goals, I clarified UX priorities through in-depth discussions and key questions.

As we work on modernizing mid-market retail banking, can you provide insights into our primary users and their key pain points?
What data do we have—such as user analytics, research findings, or support tickets—that highlight existing friction points?
From a business perspective, what sets us apart? Have we analyzed competitor strengths, weaknesses, and adoption trends?
How configurable should the solution be, and in which scenarios is flexibility crucial? How will users—developers or non-technical—interact with APIs?
Finally, what are our success metrics? Are there specific KPIs, operational efficiency benchmarks, or user adoption goals that we should measure to evaluate the impact of our design?"

Due to my NDA, I can only provide an overview of the research and cannot share detailed data into the user research conducted.

User Research & Key Insights

After the project kickoff and understanding the UX priorities, our first step was to better understand the users and the problem space. To achieve this, my lead designer and I shadowed several sales calls, where our sales representatives were pre-selling the idea and engaging with potential customers. The goal was to gain insights into customer needs, whether they are using similar products, and if so, the difficulties they face with the current solutions. We also wanted to learn about their expectations for the new product, how they envision it fitting into their existing systems, and how they are currently managing their workflows and the challenges associated with them.

During these sales calls, our focus was primarily on understanding:

Who the users are
What their needs are
What pain points they experience
What they expect from our product

After shadowing and reviewing sales team calls, and spending time with them, we gained a deeper understanding of our users and their key pain points. The insights we gathered are as follows:

Primary User Groups:

Bank Administrators: Responsible for configuring financial services and managing security.
IT Teams: Handle integration, API management, and system maintenance.
Financial Officers: Oversee transactions, account services, and compliance.

Key Findings:

High Learning Curve: Users struggled with understanding microservices-based workflows.
Fragmented Navigation: Switching between different cloud services was cumbersome.
Configuration Overload: Bank admins were overwhelmed by the multitude of options when setting up financial services.

Problem Statement

Financial institutions face challenges in adopting cloud-based solutions due to complex onboarding, fragmented workflows, and a lack of customization. Additionally, users—including bank administrators, IT teams, and financial officers—struggle with understanding microservices integration, navigating multiple cloud services, and configuring workflows effectively

After conducting user research, we were able to clearly define the core problem statement that would guide our focus throughout the product life cycle. This problem statement provided valuable insights into the key challenges faced by our users, helping us align the product vision with their needs. As we moved forward, this statement became our foundation, ensuring that every phase of the product development process—from ideation and design to implementation and iteration—was centered around solving these specific user pain points.

Analyzing and synthesising the insights gathered from user research

To prioritize design solutions and synthesize our findings, we conducted an affinity mapping exercise to organize and categorize a large volume of data, ideas, and insights, helping us identify key patterns.

Possible UX Design Solutions

Based on the affinity mapping exercise, we were able to generate potential UX design solutions, which we then validated with the product manager and development team. This step ensured that we were designing the right solutions and that everyone was aligned on the approach.

It was crucial to confirm that the designs were feasible within the current code environment and could be implemented within a reasonable time frame.

To achieve this, we involved product managers and engineers in each phase of the design process.
Below are the design decisions that we were able to finalize through mutual agreement:

1. Intuitive Onboarding & Guided Workflows

Design an interactive wizard-based onboarding process to guide users through initial setup.
Implement app tooltips and contextual help sections for complex configurations.

2. Unified Dashboard for Seamless Navigation

Create a centralized dashboard with a service overview panel to access multiple cloud services (e.g., Deposit Origination, Communication Cloud, etc.) in one place.
Create an intuitive design with a well-structured information hierarchy and integrate a universal search feature.

3. Simplified Configuration with Pre-Built Templates

Develop a pre-configured templates for common banking workflows, while reducing setup time.
Enable a drag-and-drop interface for custom configurations.

4. Enhanced API Documentation & Developer Tools

Introduce an API sandbox environment for testing integrations before deployment.
Provide step-by-step API guides and auto-generated code snippets for ease of use.

To streamline navigation across various cloud services and enhance workflow configuration, we integrated all four services into a unified, centralized dashboard within the Oracle Financial Services Cloud (OFSC) product. By consolidating these services, we introduced a service overview panel, allowing users to seamlessly access and interact with multiple cloud services in a single interface.

Improving the information hierarchy and ensuring that each service is clearly categorized and accessible through distinct domains. We are making an intuitive user experience that simplifies the management of complex cloud operations. Below is an illustration of the OFSC dashboard.

My Role & Contribution

As a Senior UX Designer, my responsibilities encompass overseeing the entire end-to-end design process for various domains within the Deposit Origination Cloud Service (DOCS). I took ownership of the user experience design and documentation across these domains, ensuring that each component aligns with the product's goals and user needs. One of the key domains I have worked on is the Beneficiary Domain. Below is a detailed explanation of my work and contributions to this specific domain, outlining the overall process of working on an individual domain.

Beneficiary Domain UX Process

Kickoff

Beneficiary Domain

Whenever we start working on an individual domain, the first step before diving into the actual work is to hold a kickoff meeting with the product managers. During this session, the product manager would provide an overview of the domain, covering key aspects such as:

What is a Beneficiary? Understanding its definition, purpose, and role within the system.
Why is it needed? Exploring its significance, the problems it solves, and its impact on users or business processes.
How is it configured in our product, OFSC? Gaining insights into how the Beneficiary concept is structured, implemented, and integrated within Oracle Field Service Cloud (OFSC).

This meeting would help establish a clear understanding of the domain, align expectations, and ensure that all team members have the necessary context before moving forward with design and development work.

1/4

Data Model

Data Model and Data Dictionary

After that, we are provided with a data model, which serves as the foundation for structuring and organizing the information. This model defines the relationships between different data entities, specifying attributes, constraints, and how they interact within the system. It plays a crucial role in ensuring data consistency, integrity, and usability across the application.

User Goal

Defining User, Goal and Motivation

After receiving the data model and data dictionary, we proceed to define the key aspects of the problem we are addressing. This involves identifying the target users—who they are, their roles, and their specific needs. We then clarify the precise objectives we aim to achieve, ensuring alignment with user requirements and business goals. Additionally, we analyze the underlying reasons behind these objectives, understanding why accomplishing this goal is essential for the users. In essence, this step is about defining the user goal, which serves as the foundation for our solution approach.

Scope of Work

Scope of Work: Defining Configuration Services and Information Architecture

Once our user goal is defined we then move to our next section which is defining the scope of work, where we begin by determining the Configuration (CRUD) services for the Beneficiary module. CRUD (Create, Read, Update, Delete) operations form the foundation of data management, enabling users to interact with and modify beneficiary-related information. These services ensure that the system can efficiently handle data entry, retrieval, modifications, and removals while maintaining data integrity and security.

Once the CRUD services are established, we proceed to define a high-level information architecture. This involves structuring and organizing data, workflows, and user interactions within the system to ensure seamless navigation and efficient data accessibility. The information architecture serves as a blueprint for how different components of the system interconnect, outlining:

Data Flow – How information moves between different modules.
User Access and Permissions – Who can view, modify, or delete data.
System Interactions – How external or internal services integrate.
Hierarchy and Categorization – Logical grouping of data and functionalities.

This step is crucial for ensuring a well-structured and scalable system that aligns with business goals and user requirements.

Next Steps: Advancing UX Design and Implementation

As we move forward, the next steps involve identifying the appropriate Redwood components and design patterns that can be leveraged to ensure consistency, efficiency, and alignment with Oracle’s design system. This includes:

Identify Redwood Components & Patterns – Review existing Redwood UI components and patterns to ensure consistency and efficiency. Determine if new components are needed.
Create or Modify UX Patterns – Develop new UX patterns if required or refine existing ones to align with user needs and Redwood guidelines.
Design High-Fidelity Wireframes & Prototypes – Build detailed wireframes and interactive prototypes to validate user flows and interactions.
Explore Desktop Redwood Design – Optimize Redwood design for desktop interfaces, ensuring responsiveness, usability, and seamless cross-device consistency.

Establishing Consistent UX Patterns Before Wireframing

Before diving into wireframing, we ensure that our design patterns for record creation are already well-defined. This approach maintains consistency across the product and streamlines the design process.

To achieve this, before even beginning domain-specific designs, we brainstormed and explored various potential flows and patterns. Through iterative experimentation and refinement, we carefully evaluated multiple approaches. After thorough consideration, we finalized a standardized pattern and documented it for future reference.

Now, whenever we start designing a new domain, we refer to this documented pattern to ensure consistency. If we encounter a new requirement that isn’t covered in the existing documentation, the entire team collaborates to brainstorm potential solutions. After evaluating different approaches, the most effective pattern is implemented and formally added to the documentation.

This structured approach ensures that our product remains cohesive, scalable, and user-friendly, while also allowing for adaptability when new challenges arise.

For demonstration purposes, here are a few screens showcasing how we documented our patterns in Figma

For demonstration purposes, this video showcases an overview of UX documentation on a Confluence page, which developers and other team members refer to

Understanding the Beneficiary Feature in Oracle Field Service Cloud (OFSC)

In the Oracle Field Service Cloud (OFSC) application, the Beneficiary is a designated feature that allows users to manage relevant settings and configurations. To access this feature, navigate to Configuration > Beneficiary within the application. This section provides tools and options for defining, managing, and customizing beneficiary-related parameters to align with organizational needs.

Please check these links for a more detailed inspection: Figma File Link and Prototype Link

Handoff

Once we complete the domain wireframes, we conduct a detailed walkthrough of the user flow with the product managers and engineering team. This ensures that everyone is aligned on the proposed design and that the flow is feasible for implementation using our existing Redwood components.

After incorporating any necessary feedback and finalizing the design, we officially hand it off by documenting all relevant links on the Confluence page. This includes sections such as Initiation, Discovery, Design, and Handoff along with any supporting materials required for a smooth development process.

Finally, we close the associated Jira tickets to mark the completion of our design phase. Below is the overview video and the corresponding Confluence handoff page.