Bank OZK Digital Banking Ecosystem
Background
At Bank OZK, I worked on a suite of enterprise platforms supporting commercial banking operations — primarily DEAL, which I owned end-to-end, and goZK, where I contributed to ongoing refinement and new feature design. DEAL is an internal system that manages the full lifecycle of commercial loans—from origination and underwriting to closing, servicing, and payoff. goZK is a banker-facing platform for client relationship and accounts management. Together, these platforms formed an integrated ecosystem used by bankers to onboard clients, open business accounts, originate and underwrite loans, manage assets, and maintain regulatory compliance.
As the primary UX designer on the commercial products side, I collaborated directly with senior stakeholders, translating complex banking policies, operational procedures and legacy constraints into usable, efficient digital workflows. My work spanned from high-level product architecture down to detailed interaction patterns and data visualizations, delivering end-to-end workflows and detailed UX specifications across multiple platforms.
The problems I solved were deeply systemic:
Unifying fragmented processes across client onboarding, underwriting, loan approvals, and servicing.
Simplifying highly technical calculations and compliance rules (e.g., loan sizing limits, beneficial ownership structures) into clear UI flows.
Bridging modern products with legacy core systems that lacked real-time APIs—designing solutions that allowed a gradual transition while keeping operations consistent.
Reducing redundancy and manual work by ensuring data appeared at the right time, in the right place, for the right role.
This required not just screen design, but ecosystem thinking: understanding how stakeholders, bankers, and systems interacted, and crafting interfaces that aligned business logic, regulatory requirements, and user needs.
Key Initiatives
Commercial Products
| Bank's CRM System
| Loan Lifecycle Management
Business Account Opening
Design a new business account opening experience to address the limitations of the current third-party system (BPM), which lacked data validation, system integration, and process transparency. The existing process was fragmented✂️ and manual✋, requiring bankers to leave the system for compliance checks and duplicate data entry, leading to long client interactions, frequent rework, steep training requirements, and Service Level Agreement (SLA) breaches. The new flow is designed to support efficient data collection and account opening during in-branch client visits, enabling bankers to complete the process collaboratively with clients in a single session.
| Disconnected Systems → Data Integrity Issues
No integration ⛓️💥 capability with core or other internal banking systems
Duplicative data entry 📄📄📄 increased inconsistency and operational overhead
Lack of a single source of truth across platforms
| Manual workarounds and system hopping at multiple steps led to long SLAs
Compliance and verification checks were performed outside the system, often multiple times and away ↪️ from the main workflow
Bankers had to retrieve information manually at multiple points in the process
| Insufficient Validation for Complex Inputs
The current system cannot validate complex structures like beneficial ownership percentages, relying on manual review and offering limited guidance to bankers on accurate data entry.
| Misaligned Information Structure → User Confusion
For example, in the current system, one-to-many relationships—such as customers with multiple roles or addresses—are captured as separate, unlinked data sections, lacking proper hierarchy or grouping.
Disjointed layout and mismatched structure increased user confusion, training time, and the risk of critical data entry errors.
BPM Interface
Fragmented Compliance Logic
Multiple compliance checks — including OFAC, Verafin, and BizChex — occurred at different stages, on different entities, and served different regulatory or business purposes. The system had to account for varying business rules and edge cases depending on the result of each check, making flow design and decision logic highly non-linear.
Complex, Layered Data Structures
The workflow needed to support seamless collection and validation of business-level and individual-level data including 1-to-many relationships, dynamic associations, and hierarchical data such as beneficial ownership. These inputs needed to be captured accurately in a single flow, while remaining intelligible to bankers and compliant with regulatory standards.
This was a high-impact initiative involving both the commercial and consumer product teams, with direct participation from the CFO, the Director of Innovation Labs, product leadership, and engineering leads.
I served as the Lead UX Designer for the initiative, responsible for guiding the end-to-end design strategy across teams. I participated in the summit, facilitated cross-functional workshops, drove alignment between UX, product, and engineering, and contributed to technical problem-solving efforts.
From fragmented logic to a shared system-wide foundation
Why
The commercial product logic was complex, fragmented, and undocumented. Teams needed a common foundation before deeper discussions.
What I did
Created conceptual mockups showing disconnected micro-flows. They were not full solutions, but conversation starters.
Used these mockups to align internal UX and PM teams on business logic, terminology, and key unknowns.
Identified what needed further discovery during the summit.
Why
The summit would bring together senior stakeholders from multiple cross-functional verticals including CFO, Innovation Labs, Engineering, PM, UX, and frontline bankers. They needed a shared visual language.
What I did
Designed a diagramming toolkit with pre-defined modules, logic shapes, and blank components for live mapping.
Balanced known elements, potential modules, and open-ended space to support cross-functional ideation.
Enabled participants from non-design backgrounds to contribute meaningfully during the workshop.
Why
The workflow involved complex business logic and deep technical dependencies; mapping it together ensured shared understanding across functions and alignment on ownership, data flow, and key decision points.
What I did
Facilitated a cross-functional workshop using the toolkit to map the full end-to-end process.
Helped resolve questions like: When should each compliance check occur? What happens when a check fails? What system needs to own which step?
Identified gaps, edge cases, and ownership issues (e.g., beneficial ownership logic, rerun rules, fallback paths).
Captured the shared understanding in a collaborative flow diagram.
Why
Broader business approval was needed to move forward.
While we waited for broader business sign-off, we couldn’t afford to pause execution. We prioritized flows with the most clarity and highest impact.
What I did
Converted the summit’s working diagram into a simplified visual for stakeholder signoff.
In parallel, began UX design on key flow segments (e.g., business info intake, account selection), and created prototype for early user testing.
Analyzed early user testing findings to identify opportunities for improving the structure of key flow segments.
Why
This phase required deeper collaboration across disciplines, including continuous discussions within UX, with product, and with engineering, to resolve complex logic, technical limitations, and compliance requirements before finalizing the design.
What I did
Designed data-rich interfaces that supported complex inputs and relationships while preventing errors.
Partnered with product and compliance to define thresholds, rerun rules, and documentation requirements.
Led in-depth feasibility and trade-off discussions with engineering.
Beneficial Ownership Structure & Calculation
Strategy:
| Common Approach: Inefficient Linear Workflow
The common linear approach to Beneficial Ownership (BO) management is fundamentally flawed. It mixes the complicated, structural-based data collection task with straightforward form-based data collection tasks, making the entire process far more complicated and time-consuming than it needs to be.
Because the data wasn’t structured logically, the system couldn’t validate cross-level BO percentages, leading to high cognitive load and increased risk of input and calculation errors.
| Optimized Two-Phase Solution
By analyzing the workflow, I identified two fundamentally different data collection tasks—one structural and reasoning-based, the other detail-oriented and repetitive. Each demanded different cognitive and technical approaches. To streamline the process, I separated them into two phases.
In Phase 1, users focus on defining the ownership structure by entering only names and ownership % , allowing quick validation of totals without distraction.
In Phase 2, they complete individual data collection for each confirmed owner. This separation reduced cognitive load, minimized unnecessary effort, and made the most complex step of BO management faster, clearer, and less error-prone.
Why
Testing the full workflow revealed overlooked logic gaps and edge cases that affected data accuracy and cross-system consistency.
What I did
Consolidated findings from testing to address data duplication, ownership conflicts, and sync delays between our system and the core.
Defined clear data-handling logic—how new records are created, how existing ones are linked, and how changes propagate without real-time API connections.
Designed user-facing mechanisms (inline alerts, push actions, and visual states) to make system behaviors transparent and prevent incorrect updates.
Two key examples illustrate how I addressed these data-handling constraints:
| Preventing Duplicate Records Under System Constraints:
The existing data model for managing one-to-many relationships posed a challenge: any new customer records are instantly created and stored within the system during enrollment, automatically detecting or linking potential duplicates would require significant engineering effort. For this initiative, I designed a workaround that minimizes duplicate creation by prompting users to search for existing records first and validating their input before adding new entries. This approach preserved data integrity while remaining feasible within system constraints.
| Handling Data Updates Without Real-Time Integration:
Because the bank’s core system (Navigator) doesn’t support real-time APIs, data synchronization was a key constraint. The core only pushes data in a nightly batch at midnight daily or through an on-demand data update. To preserve data integrity, business rules prohibit pushing data from the enrollment flow, updates must originate in and be pulled from the core. To account for this limitation, I designed a controlled update model that made system states, dependencies, and data freshness visible to users, ensuring accuracy and continuity even without real-time integration.
On-Demand Data Refresh Workflow
| Guided Multi-Type Data Collection
The final workflow provides a structured, linear experience where each section focuses on a specific category of information, while supporting structured data collection within each. Rather than treating document requirements as a separate checklist module, I integrated them directly into the flow. This approach differed from other internal systems, which handle more complex, multi-party applications requiring uploads from multiple sources. In this case, bankers complete the process alongside clients in the branch within a single visit. Since the documents requested at each step represent only the minimum required to proceed, integrating them directly into the guided flow made the process more efficient, seamless, and aligned with the in-branch experience.
| Integrated Compliance Checks
I designed a new compliance handling approach where different types of checks are run at the right stage of the process. The CDD questionnaire, which resides entirely in Verafin, is treated as an external dependency. Bankers complete it outside the flow but must confirm completion through a “soft gate” checkbox before submitting. Checks such as OFAC and BizChex, which return decision data, are embedded directly into the workflow at the end of each relevant section. I also introduced an override mechanism that allows bankers to proceed with valid proof when a check fails, while ensuring transparency and auditability through clear system feedback.
Business Entity Info Collection with Embedded Checks
| Error Behavior and State Management
I defined comprehensive error behaviors across the system, from data validation to sync failures, including inline notifications, contextual banners, and recoverable states. These patterns ensure that bankers can identify, understand, and resolve issues without leaving the flow, improving both efficiency and confidence in the system.
Validation on Section Exit
This project transformed one of the bank’s most complex internal processes into a guided, transparent experience that bankers could confidently complete with clients in a single branch visit. The new design unified fragmented systems, integrated multiple compliance checkpoints, and established clear data-handling logic that reduced rework and improved accuracy. It proved that even in highly regulated, legacy-bound environments, clarity and usability can be achieved through thoughtful structure, guided workflows, and precise handling of technical limitations.
| If There Were More Time
The project ran on a tight schedule, leaving limited room for deeper iteration and extended testing. With more time, I would:
Introduce data visualization elements in the status bar to provide real-time clarity, such as counts of missing fields or section-level alerts, to make progress tracking and data validation more intuitive.
Further evaluate the dual-CTA pattern, where each section maintains its own primary action and a secondary “Move Forward” button activates once all sections are complete. While this structure effectively guided users and prevented confusion, subtle hesitation observed during testing suggests opportunities to refine its visibility and affordance.
| Designing Clarity Into Organizational Complexity
True simplicity in enterprise systems doesn’t only come from reducing steps, but from aligning how business logic, data relationships, and user actions are represented in the interface. Complex processes become manageable when logic, validation, and progress are surfaced in context rather than hidden behind abstract checklists.
| Designing Within Constraints
Technical and regulatory limitations like non–real-time APIs and rigid data models inevitably narrowed what could be built. I focused on expressing those limitations through clear states and feedback, so users understood when data was current, pending, or dependent, turning system constraints into predictable, understandable interactions.
| Workflow as a Thinking Tool
Using visual mapping and structured frameworks made complex logic easier for everyone to reason about. It turned collaboration with engineering, compliance, and leadership into a shared problem-solving process instead of abstract discussion.
Next Project: goZK | Needs Assessment
Business Needs Assessment
Design a guided tool that helps bankers conduct structured, high-quality needs-assessment conversations with business clients (either in person or over the phone) ensuring consistency, efficiency, and accurate opportunity capture.
I was the sole UX designer on the commercial product side, responsible for the end-to-end design process, from defining business logic and mapping banker workflows to prototyping and interaction design. I collaborated closely with product owners, commercial bankers, and engineering leads to align on data structure, compliance needs, and conversational flow logic. Beyond visual design, I shaped how system intelligence supports bankers in real time, ensuring the experience feels both guided and adaptive.
Why It's a Problem
Without a shared framework, bankers rely on personal style and memory, leading to inconsistent service quality, compliance risks, and missed opportunities to uncover client needs.
Solution:
Guided Conversation Framework
A structured yet flexible flow provides contextual prompts, progress tracking, and consistent opening/closing statements to ensure every banker delivers a professional, on-brand experience.
Guided Conversation and Data Collection Framework
Why It's a Problem
Unbalanced pacing can frustrate clients, increase branch wait times, and reduce the number of completed assessments in a day.
Solution:
Conversation Timer
A single conversation timer helps bankers maintain the ideal length, which is long enough for depth, short enough for efficiency. It sits persistently in the left panel, with subtle visual cues that help manage pacing without interrupting flow.
Why It's a Problem
Typing responses disrupts conversational flow, making bankers appear disengaged and lengthening client meetings.
Solution:
Chip-based Dynamic Data Collection
Bankers select from quick chips for common answers; fields adapt automatically to show only relevant follow-ups, keeping input fast and fluid.
Dynamic Fields via Quick Chips
Why It's a Problem
Without real-time data analysis, bankers may overlook cues that signal product needs, directly impacting revenue and relationship growth.
Solution:
Auto-Identified Opportunities Panel
As bankers record information, potential products are surfaced automatically in a bottom panel. Opportunities can be selected for recap and next steps.
Opportunity Auto-Identification, Selection & Recap
Why It's a Problem
After conversations, bankers often struggle to summarize outcomes, leading to lost follow-ups, compliance gaps, and unclear client next steps.
Solution:
Intelligent Recap Page
Automatically summarizes key points, conversation time, open questions, and selected opportunities. Bankers can quickly mark items as Open Today, Follow Up, or Unselected and set reminders directly.
Recap Page: Automated Summary & Action Planning
Why It's a Problem
Returning clients often repeat information because bankers lack historical context, weakening trust and wasting time.
Solution:
Last Assessment Overview & Change Tracking
Shows the full summary of the client’s last assessment, with highlighted changes to goals and priorities since the last visit—helping bankers instantly tailor conversations.
Change History: Contextual Change Highlighting
Next Project: goZK | Banker Team
Banker Team
Create a way for bankers to clearly see and manage who owns the client relationship and which specialists support it. This included introducing a Banker Team capability into an already established client profile without disrupting existing workflows.
The system had no structured way to assign or display a lead banker or supporting specialists for a client. Assignment was handled manually within each team, and only the team lead knew who was responsible for what. As a result, other bankers lacked visibility and frequently routed new requests or client inquiries to the wrong person, or had to ask the team lead for direction, which creates delays, miscommunication, and inconsistent client service.
I was the sole UX designer responsible for:
Defining the scope and structure of how Banker Team should exist within the current product.
Mapping role-based permissions and states across lead bankers, specialists, and other bankers.
Translating business rules into clear, predictable user behaviors.
Delivering the end-to-end UX, from conceptual model to final interaction patterns.
| Design Constraints & Considerations
The feature needed to fit into an established client profile with fixed layout patterns and limited flexibility for introducing new components. It also had to remain non-disruptive to daily banking tasks while still supporting visibility into ownership. Additionally, assignment and reassignment behaviors had to align with system-wide logic for active, inactive, and transitioning bankers.
| Placement Strategy
Information hierarchy: Ownership is contextual, not part of daily workflow. So it should be visible but not compete with primary banking activities.
Pattern alignment: The summary card area is already used for high-level client context; placing Banker Team there maintains layout consistency.
Scannability: The card surfaces key ownership information immediately, reducing the need for bankers to ask team leads or rely on memory.
Action segregation: Assigning, removing, or reassigning bankers is an infrequent operational task; keeping actions within a panel prevents clutter in the main profile.
Clarity between “view” and “manage”: The card presents essential information, while the panel provides controlled access to management functions.
Support for edge cases: Inactive bankers, temporary coverage, and reassignment are handled cleanly without overwhelming everyday interactions.
Operational reliability: Making ownership visible at the top reduces misrouted requests and improves internal coordination.
The final design establishes a clear and consistent way to display ownership and guide role-appropriate actions. By defining distinct behaviors for lead bankers, non-assigned bankers, and scenarios involving inactive team members, the experience resolves previous ambiguity and ensures accurate, transparent routing of client responsibilities.
| Interaction Logic
Lead bankers have full control over team composition. They can assign specialists, remove team members, or step down from the lead role themselves.
| Design Reasoning
Progressive disclosure: Removal controls only appear on hover to reduce visual noise and prevent the card from feeling action-heavy. The default view prioritizes contact information (email + phone), reflecting that communication is the primary daily use case.
Role clarity: Only lead bankers see the full management surface, reinforcing their operational responsibility for maintaining an accurate team.
Controlled editing: Allowing lead bankers to remove themselves ensures clean transitions during role changes without requiring back-channel coordination.
| Interaction Logic
Non-assigned bankers can take an available specialist seat or reassign the lead role to themselves when appropriate. Doing so transitions their UI to the full lead-banker view.
| Design Reasoning
Self-service empowerment: Bankers no longer rely on team leads or manual communication to update ownership; they can take responsibility directly when business processes require it.
Adaptive permissions: The interface updates immediately after reassignment, reinforcing a sense of clarity and control when ownership changes.
Reduced misrouting: Giving non-assigned bankers the ability to claim responsibility reduces operational delays and dependency on a single team lead.
| Interaction Logic
When a banker becomes inactive (left the bank, changed departments etc.), any active banker can initiate an organization-wide reassignment request. This requires approval to ensure alignment with internal controls.
| Design Reasoning
Clear status communication: The UI explicitly surfaces inactive states, pending approvals, and newly assigned bankers to prevent ambiguity during transitions.
Governance alignment: Reassignment requires approval, matching institutional policies and ensuring correct handling of sensitive client relationships.
Operational continuity: Making reassignment accessible to any active banker prevents bottlenecks and keeps client ownership up to date even when transitions are unexpected.
Next Project: DEAL | Loan Management
Loan Management Platform
Design a unified platform from the ground up to manage commercial loans from origination through paid-off, supporting loan data entry, document workflows, collaboration, and audit requirements across the lifecycle.
I was the sole UX designer on the commercial product side, responsible for the end-to-end design process, from defining business logic and mapping banker workflows to prototyping and interaction design. I collaborated closely with product owners, commercial bankers, and engineering leads to align on data structure, compliance needs, and conversational flow logic. Beyond visual design, I shaped how system intelligence supports bankers in real time, ensuring the experience feels both guided and adaptive.
Commercial lending is fundamentally a data-driven domain, decisions, automation, compliance, and user workflows all depend on how accurately data enters the system and how accurately data enters the system and how consistently it moves through each stage. To make sense of this complexity, I approached the work with a data-first lens grounded in the design process I follow across all my projects.
Instead of starting with screens, I began by analyzing:
What data exists (data inventory)
When it becomes relevant in the lifecycle
Where it enters (forms, imports, integrations)
How it transforms (validation, enrichment, decision logic)
What it enables (tasks, approvals, stage progression)
Where friction or repetition occurs
Which data elements are process-driving vs. supporting
This analysis surfaced a set of structural questions that directly shaped the design. Rather than treating them as implementation details, I used them to frame the core design challenges.
Specifically, I made four foundational structural decisions:
How should loan data be organized? By lifecycle stages or by logical grouping?
I analyzed the relationship between the approval timeline and the data entry behavior. I found that:
Bankers frequently move between stages, often returning to earlier sections to complete or verify information.
Many data points are relevant across multiple phases (e.g., from Origination $\rightarrow$ Underwriting $\rightarrow$ Closing).
A strict stage-based grouping would force us to duplicate fields across pages, introducing version control issues and data inconsistency.
Stages are still represented in the status bar at the top, but the data itself remains structured in stable, predictable logical categories where fields can become required, optional, or locked depending on stage.
The Insight
The process is linear, but the data access is non-linear. While the lifecycle moves forward in steps, the loan file is a persistent object.
| Solution:
Stages are represented in the status bar at the top, but the data itself remains structured in stable, predictable logical categories where fields can become required, optional, or locked depending on stage.
What structural pattern can hold a large volume of related data without overwhelming users?
I took the raw data inventory provided by the business and PM and worked with PM to categorize the fields, and then identified:
1-to-many relationships (e.g., multiple loan parties, multiple collaterals)
Dense categories that would result in endless scrolling without intervention.
Logical break-points where large sections could be subdivided.
The Insight
In data-heavy systems, cognitive load is caused by lack of hierarchy, not just volume. Users can handle large amounts of data if the container is predictable.
| Solution:
I defined a scalable hierarchy to handle this variance:
Cards for major categories
Sub-cards for repeated entities (1-to-many)
Subsections to break dense forms into digestible groups.
Expand/collapse controls to reduce scrolling and allow targeted review
This hierarchy directly informed the UI and visual design system, ensuring the interface could scale with complexity.
Loan Page - Loan Data Tab
How do we determine the visibility and availability of data based on its value to the user?
To determine how data should appear on screen, I categorized the entire inventory into five functional roles: Decision-Making, Process-Driving, Documentation, Reference/Context, and Reporting.
While most of the categories mapped naturally to the main workspace, the Reference/Context group presented a unique structural requirement.
The Insight
Data points like Assigned Team, Loan Associations, and External Contacts do not drive the decision logic itself, but they are critical information anchors that users check repeatedly while performing other tasks.
| Solution:
If these fields lived inside the main scrolling flow, users would lose access to them as soon as they scrolled down. This drove the decision to introduce a dedicated Side Panel component.
Availability: It keeps high-frequency reference data visible regardless of where the user is in the workflow.
Scalability: It creates a designated "container" for contextual data, allowing the system to accommodate new reference points in the future without cluttering the primary workspace.
Loan Page - Side Panel Expanded
How does the architecture extend beyond the single loan file?
Defining the loan structure was only the foundation. To make the system functional, I needed to define the supporting ecosystem that manages these loans. I analyzed the operational requirements and identified three distinct layers of user needs:
Discovery: How users find and filter loans (Tables, Dashboards).
Workflow: How users process the work (Tasks, Checklists, Approvals).
Governance: How admins control the system (Access Control, Field Config, Dropdown Management).
| Solution：
I expanded the scope to map the full system architecture. This established the navigation and relationships for all major modules:
With the structural foundation in place, I designed the key interfaces that drive the lending lifecycle. The following highlights cover the platform's core components: daily workflows, document management, admin operations, and cross-system interactions.
| Checklist-Aligned Grouping
Document categories follow the same grouping logic used in the Checklist system, so bankers see a structure that matches how documents are requested and reviewed today.
| Familiar Folder Layout
A collapsible folder tree presents these groups in a pattern bankers already know well, making it easy to browse, expand, and manage large sets of documents.
| Address Bar for Orientation
A simple address bar shows the current path and provides an additional way to move back up the hierarchy without relying only on the folder tree.
Loan Page - Documents Tab
| Loan-Level Overview
The loan grid acts as the main entry point, giving users a clear view of all active loans across stages, owners, and priority levels.
| Bottom Summary Bar
A fixed summary bar highlights key totals and counts, allowing users to quickly understand the overall distribution of loans without additional filtering or reports.
| Customizable Views
Because the grid includes many possible fields, users can create custom views with only the columns relevant to their workflow.
Loan Grid & View Configuration Modal
| Leveraging an Existing Platform
The approval workflow was originally built as a separate initiative, and full integration was not a priority when DEAL was created. Since the approval committee and the origination/underwriting teams operate independently, we chose to reuse the existing approval system instead of rebuilding it inside DEAL.
| Access Limited to Approval-Relevant Tabs
Committee members only access the Approval tab and Admin tab in DEAL. They do not work inside the loan-level data, and their decisions are based on summarized reports generated from loan data—not on detailed field-by-field review.
| Summarized Data for Decision-Makers
Each approval request includes a structured summary panel that highlights the information most relevant to the committee, rather than exposing the full loan record. This supports faster review and aligns with how approval decisions were already made.
| Recording Decisions Efficiently
The Decisioning tab is designed for the coordinator responsible for entering each approver’s decision and comments. Instead of multiple approvers logging in individually, the coordinator can record the full chain of approvals quickly and maintain an accurate audit trail.
Approval System (Coordinator View)
| Context
This internal engine controls the behavior of over 300 data points across the loan lifecycle, defining behavioral rules like Shown Since, Required Since, Locked Since, and Maintenance Allowed. These configurations are conditional, varying based on the specific combination of Lending Vertical, Loan Type, and Property Type.
| The Initial Approach:
I began by exploring a standard interface that mirrored the database structure: Dependent Filters. This required users to drill down through a deep hierarchy: selecting a Lending Vertical, then Loan Type, just to locate a single configuration record.
| The Discovery: The Scalability Trap
During low-fidelity validation, I identified a critical failure in this standard model. While dependent filters work for defining one specific record, they break down during policy governance.
If a user needs to enforce a global rule, like "Require 'Flood Insurance' for all Construction Loans during Stage 1 (Origination)", the dependent model would force them to manually locate, click, and edit the exact same field across every single construction loan permutation individually.
The Complexity Analysis
To validate that this was not just inconvenient but operationally impossible, I calculated the scale of the maintenance burden:
2
Lending Verticals
25
Granular Loan Types
10
Property Types
500
Unique Criteria Combinations for a Single Field
When applied across the entire data inventory:
500 Unique Criteria Combinations
300+ Fields
150,000+ Configuration Points
This data proved that a 1:1 editing model would turn a 5-minute policy update into hours of manual data entry.
The Strategy Pivot: From Database Model to User Model
I re-evaluated the core intent. The initial design failed because it forced the user to think like a database (Day 1 Setup). However, the admin's primary goal is Day 2 Modification, reacting to business policy changes efficiently.
| The Solution: Attribute-Based Governance
I shifted the mental model from Record-Level Editing (Precision) to Batch Logic Management (Velocity).
Independent Filters: Users query by attributes rather than drilling down paths.
Bulk Governance: This enables admins to push a single rule change to hundreds of underlying combinations instantly, solving the scale problem.
The "Conflict" Trade-off: Selecting multiple records often results in a "Conflicting Configuration" state where values differ. This is acceptable because the user intent is enforcement, not review. Admins do not need to see the old values to overwrite them with a new standard policy.
Field Configuration Module
This case study represents only a fraction of the DEAL platform. The full system encompasses the entire loan lifecycle, including modules for Loan Origination, Underwriting, Credit Risk Review, and Asset Management etc.
Due to the proprietary nature of the detailed banking workflows, I have focused this page on key structural challenges. I would welcome the opportunity to walk you through the broader system architecture and discuss the end-to-end business logic in a conversation.
Next Project: DEAL | Partial Release Tracker
Partial Release Tracker
Migrate the "Partial Release (* releasing collateral piecemeal as individual units are sold)" workflow, currently managed manually via spreadsheets, into the DEAL platform to centralize data governance, eliminate redundant entry, and streamline the release of collateral for commercial construction loans.
I was the sole UX designer on the commercial product side, responsible for the end-to-end design process, from defining business logic and mapping banker workflows to prototyping and interaction design. I collaborated closely with product owners, commercial bankers, and engineering leads to align on data structure, compliance needs, and conversational flow logic. Beyond visual design, I shaped how system intelligence supports bankers in real time, ensuring the experience feels both guided and adaptive.
The RESG group at Bank OZK specializes in originating large-scale commercial real estate loans (e.g., hotels, condos), where the construction itself serves as collateral. As borrowers sell individual units, the bank must "release" that specific portion of the collateral to transfer ownership and pay down the loan—a critical workflow known as "Partial Release."
Historically, this entire process was managed in a massive, disconnected spreadsheet workbook. Users were forced to toggle between a Formula-Based Dashboard (a dense recap sheet for auto-calculated summaries) and a sprawling 120-column data grid to track hundreds of individual units. This project focused on migrating that fragile, manual burden into a streamlined, digital workflow within the DEAL platform.
I restructured the flat-file data model into a tiered interface to reduce cognitive load and eliminate horizontal scrolling:
| Persistent Context
Locked critical identifiers (Unit #, Sq Ft, Status) to the left of the view.
| Stage-Based Grouping
Organized tracking data into distinct tabs (e.g., Underwriting, Pending Sale, Wire Received) so users only interact with fields relevant to the current lifecycle stage.
| Dynamic Value Mode
Consolidated data points that require both Total and /SF views (such as Underwriting or Basis) into single columns. By adding a toggle directly to the column header, users can switch measurement units in place, eliminating the need to display duplicate columns for the same data field.
| Centralizing Calculation Inputs
Variables like Admin Fees or Exit Fees apply to the entire loan, yet they were previously repeated in columns for every single unit. This created a major data governance risk: if a user accidentally modified just one cell in a column of 200, the calculation logic would break.
I extracted these variables out of the grid and into a dedicated "Rate Settings" modal. This ensures that calculation rules are applied uniformly across the entire dataset, preventing row-level discrepancies while removing redundant columns from the main view.
Rate Settings
| Batch Processing
Recognizing that sales often occur in clusters, I implemented a floating bulk-action module. This allows users to select multiple units for simultaneous status updates or data entry, significantly reducing repetitive clicks.
Floating Bulk-Action Module
Replaced a formula-heavy spreadsheet dashboard with a live, visualized dashboard that consolidates key metrics, sales progress, and loan performance in one place. The new interface supports real-time tracking of unit sales and payoff milestones, and introduces predictive insights—including estimated loan maturity, quarterly sales velocity, and risk of overdue timelines. These visualizations help bankers proactively manage pacing and identify gaps early, rather than reacting to static snapshots.
Dashboard
Reflections
| The Reality of Enterprise Design:
Working at Bank OZK clarified a fundamental truth about commercial banking software: UX is not a direct revenue driver. Unlike consumer products, where a better experience directly converts to sales, internal banking platforms generate value indirectly by facilitating banker efficiency, ensuring accuracy, and reducing operational risk.
Because of this, business priorities often override the desire for "perfect" design. I learned that in this environment, there is rarely budget or time for extensive A/B testing or endless iteration on a single module. The business often chooses the "good enough" solution to ensure speed to market across a wide breadth of features.
| Bridging the Gap: Persistence via Process
Instead of fighting against this reality, I adapted my way of working. I accepted that we couldn't iterate endlessly before launch, but I refused to let UX debt disappear into the void.
I established a practice of "continuous backlog management." I didn't stop at the design file; I worked directly in the QA environment to test the build. When I found edge cases, UI polish issues, or workflow frictions that were out of scope for the current release, I created Jira tickets.
For the PM: This turned abstract UX feedback into tangible, visible items that could be evaluated for future roadmaps.
For the Product: It ensured that "phase 2" wasn't just a myth, but a documented list of actionable improvements waiting for resources.
Strategic Mindset
I learned that in enterprise banking, UX drives value indirectly—through operational efficiency and risk reduction—rather than direct revenue. This reality often demands speed over polish. I shifted from rigid perfectionism to strategic prioritization: accepting necessary trade-offs to maintain development velocity, while clearly defining the long-term ideal so that "good enough for now" doesn't become the permanent standard.
Operational Process
To ensure design quality persisted beyond the happy path, I integrated UX directly into the engineering lifecycle. I treated the QA environment as a critical design surface, formally logging UI debt and workflow gaps into Jira. This transformed abstract feedback into a visible, manageable backlog of work, ensuring that improvements were tracked and prioritized rather than lost in conversation.
The Long Game
Navigating strict constraints taught me to view scope limits as phasing decisions, not failures. I learned to decouple the ultimate vision from the immediate sprint, advocating for a "phase 2" that actually happens. This approach allowed me to be a pragmatic partner to the business—moving fast today while protecting the user experience of tomorrow.
My time at Bank OZK ended due to the conclusion of my U.S. work authorization, but it deeply shaped how I approach enterprise UX. I’m grateful for the complexity of the problems I worked on and for the colleagues who sharpened my understanding of how design, business, and technology intersect in real systems.
After and during my time at Bank OZK, several senior colleagues I worked closely with across product, engineering, and strategy reached out to collaborate again on new ventures. This included joining an early stage startup as a core team member to lead design for client facing SaaS products, as well as consulting on independent initiatives and a startup focused on business education let by a former senior manager.
Selected projects from these collaborations are highlighted below.
Thank you for reviewing this case study.
I am currently open to full-time Product Design opportunities. If you are interested in discussing the detailed research or logic behind this project, please feel free to reach out.
