Digitizing Foreign Trade Inside a Regulated Platform
Overview
Bank of Chile is Chile's leading NYSE-listed bank — 2M+ clients, multi-billion-dollar digital infrastructure, with a nationwide network of branches, ATMs, and digital services.
This case details how a manual, back-office financial service was digitized and launched in just three months by a 12-person team—completely bypassing the traditional research phase. The Product Owner needed to move directly from user stories to high-fidelity designs, we built product confidence without direct client research by leveraging deep domain expertise, adjacent project insights, established platform patterns, and real-time access to back-office operators.
Case Metadata
Role
Senior UX Consultant — sole designer on the project
Scope
External Commerce, the Bank's corporate international trade product — digitized from an analog service into a full desktop application: payroll creation, order management, approval workflows, real-time currency purchase, role-based messaging, and administrative controls
Timeframe
3 months (within Apr 2017 – Sep 2018 at Bank of Chile)
Team
1 Product Owner, 1 development lead, 10 developers, plus senior management stakeholders and the Bank's External Commerce operators, who we met with regularly
Core Challenge
Digitize a manual, spreadsheet-driven trade payments service in three months — inside rigid bank UI guidelines and regulatory requirements, with no budget for user research or validation
Skills & Core Competencies
Complex Financial UX, Design Under Constraint, Design System Contribution, Domain-Driven Design Decisions, Developer Collaboration, Regulated-Industry Compliance
1. An Analog Service Inside a Digital Bank
External Commerce is the Bank's corporate platform for managing international payrolls and payments to the US and Europe. Historically, it operated as a manual, back-office process: clients either submitted requests in person or uploaded IRS-mandated XML payroll files online for manual processing by bank executives.
Key insight: The cost landed in two places. For the Bank, it was operational overhead and error exposure on high-value international transfers. For the operators running the service, it was a working life built on spreadsheets: reconciling payrolls by hand, tracking client requests across files, and absorbing the friction of every exception personally.
Three Months & Twelve People
Time constraints meant the Product Owner needed me to skip formal research and validation and move directly from user stories into high-fidelity prototypes.
A non-arbitrary constraint
With eleven engineers and a three-month window, the burn rate made a discovery phase expensive in a way that's easy to underestimate.
The risk is worth naming
Without users in the process, you lose the ability to be surprised. What you build reflects what the organization already believes about its customers.
Where else confidence could come from
The bank operators
The Bank's External Commerce operators were in the room throughout, and we met with them regularly. They were not a proxy for the corporate clients, but they were users — the people running the service every day, who knew every exception, workaround, and failure mode the spreadsheets had accumulated. Half the user picture was available to me the entire time.
An expert Product Owner
The PO had deep operational knowledge of External Commerce. Working closely with him let me absorb the mechanics of international trade payments quickly and design with accuracy rather than assumption. A domain expert is not a substitute for users, but they are a far better starting point than a requirements document.
Borrowed evidence
Prior research from Term Deposits and other Bank projects carried over — overlapping users, the same platform, and findings about how corporate finance staff works with banking tools that had already been validated. Research done once at this bank could be spent more than once.
Key insight: What this adds up to is a real method, not a compromise: lean on existing patterns, industry standards, domain knowledge, and whichever user population you can reach — and stay explicit about the difference between validated and reasoned.
2. Designing the Payroll Application
Payroll processing was the core of the platform, designed for clarity, accessibility, and scalability.
The User Persona: accountants and finance staff at medium-to-large companies — comfortable with banking software, but needing streamlined tools to handle heavy transaction loads.
The workflow would offer two options: on the one hand, it would retain the ability for users to upload their .xls files — just as before, but now with digital processing — and on the other, a second option allowing users to manually create multiple payrolls directly on the platform for processing.
The user interface: Our persona was used to interact with high data density, maximum accuracy, and strict regulatory control interfaces. With that in mind, I designed a flat, minimalist style with generous negative space so actions could be easily scanned, favouring clearness and operational readiness, aligned with the Bank's design guidelines.
When it came to developing the manual payroll application, which was the core premise of this digitization process, I designed a form-based data entry and workflow engine inspired by shopping cart logic: users could create multiple payrolls, place them on temporary hold, and finalize them when ready.
A step-by-step process — naming payrolls, entering company information, creating orders, confirming — gave users full control and visibility at each stage, which matters when the transaction is an international transfer that cannot be casually undone.
Key insight: I worked directly with developers to resolve backend limitations while protecting the clarity of the interface. With a team of eleven engineers moving at pace, design decisions had to arrive ahead of implementation and survive contact with the platform's actual constraints.
3. Advanced Controls for Approvers and Administrators
The platform introduced new capabilities for administrators and senior roles. A Foreign Trade banking approval workflow that manages the verification, risk assessment, and execution of cross-border financial transactions.
Transaction Initiation
The corporate client or relationship manager submits the trade application alongside supporting trade documents through the payroll (e.g., proforma invoices, bills of lading, purchase orders) via the digital banking portal.
Document & Compliance Verification
Back-office trade specialists review the documents for International Chamber of Commerce (ICC) compliance. The system checks the client's existing credit lines, available collateral, and counterparty risk limits for the destination country and issuing/advising bank.
Finally, a user with the right role and permission can authorize the submission of the transaction to an approver who grants final authorization or rejection and confirms USD/EUR exchange rates in real time.
Subsequently, the bank issues the trade instrument via the SWIFT network (for example, the SWIFT MT700 message for letters of credit) or transfers the funds to the receiving bank.
To support approval workflows, we integrated role-based communication tools — including message boards and urgent SMS notifications — paired with automated audit logging to ensure transparency across approval workflows.
4. Designing Inside the Bank's Constraints
A recurring issue across modules was table density, with many screens exceeding eight columns and forcing excessive horizontal scrolling. Unconstrained layout changes weren't an option, so column visibility had to become user-configurable:
I designed column visibility controls. When tables exceed eight columns, horizontal scrolling degrades scannability. Because fixed layouts weren't viable, we made the interface negotiable by letting users toggle column visibility on demand.
Key insight: Designing around this constraint led to a superior outcome. Rather than dumping every column onto every user via horizontal scrolling, customizable visibility recognizes that an approver and an accountant require fundamentally different views of the exact same data.
5. Patterns That Outlived the Project
Some core user needs — particularly around approval workflows, messaging, and critical payroll updates — exceeded the capabilities of the existing design system. Drawing on prior research and shared insights from adjacent team projects, I gathered the proof needed to secure approval to design new, scalable patterns and contribute them back to the system.
Sub-Navigation & Feature Discoverability — Customer feedback highlighted a persistent issue: sub-tab elements lacked visible actions, leaving key features hidden. The new design brought primary actions forward, making sub-tab functionality immediately discoverable.
Action Prominence & System Feedback — To help users parse complex screens at a glance, we moved away from the Bank's heavily gray UI. We introduced higher-contrast elements, clearer alert states, and explicit system feedback.
Takeaway: These patterns were fully integrated into the Bank's design system and formally signed off by the UI QA team — the gatekeeper for the shared component library. Passing this threshold meant our work became a permanent resource for every future team across the organization, extending its impact far beyond this single project.
6. Business Impact & Outcomes
Key Takeaway: Skipping research and having no evidence are not the same thing. The work was knowing which substitutes were load-bearing and which were guesses.
In an institution this size, the news of a successful project rarely travels back to the people who built it. What returns is gratitude — clients are extremely happy, congratulations, great work. Real and welcome, but not measurement. Nobody told us how many companies onboarded, how much back-office time was recovered, or whether error rates fell, because those numbers lived in departments with no reason to send them downward.
Business Impact
Objective
Solution & Execution
Impact
Service digitization
Replaced a manual, back-office-processed workflow with a self-service platform covering payroll creation, ordering, approval, currency purchase, and messaging
Launched and well received. Corporate clients gained direct control over transactions previously handed to an intermediary; satisfaction was relayed back through the Bank, and the UX work was formally recognized
Internal operations
Designed the operator-facing side around the real workflow, informed by continuous access to the external commerce team throughout the project
Spreadsheets eliminated from daily operations. Operators moved from reconciling payrolls across files to working with clients directly through the platform
Delivery under compression
Substituted operator access, domain expertise, borrowed research from adjacent projects, platform patterns, and systematic peer critique for a formal research phase
Shipped in three months with a twelve-person team — without designing on assumption alone, and with the limits of the approach stated rather than hidden
Regulatory compliance
Designed within Bank UI guidelines and Internal Revenue Service requirements
Reduced user friction while maintaining full compliance with banking and government standards
Design system contribution
Designed new sub-navigation and action-prominence patterns, justified with prior research from adjacent projects
Adopted into the Bank's design system and approved by UI QA, extending the shared component library for every team that followed
Learnings & Reflections
This was one of the smoothest projects I worked on, and the reason is worth being precise about: a Product Owner with genuine operational expertise, clear business requirements, and direct access to the people who ran the service. Much of what would normally come from discovery was already in the room. That is not always true, and it is not something a designer can count on.
The wider lesson is about the difference between skipping research and working without evidence. Research is one way of acquiring confidence, not the only one — domain expertise, findings from adjacent projects, validated platform patterns, structured peer critique, and access to even one of your user groups all buy some of it. What none of them buy is the ability to discover if you are solving the wrong problem.
“In banking, UX success depends on deeply understanding the industry, the processes, and the user roles. Constraints — regulatory, technical, and organizational — are not obstacles to the design work. They are most of it.”
