Motus processes $1.4B in annual reimbursements across 3,000+ clients. Prior to this work, critical banking operations were happening in a black box—funds moving, errors occurring, and transactions processing with zero visibility for the internal and external admins managing them.
Banking operations at Motus were entirely opaque. When funds failed to disburse, when clients needed to understand their transaction history, or when internal teams needed to troubleshoot issues across thousands of companies, there was no system of record.
The gap affected three distinct users:
Internal Implementation Admins fielded escalations from confused clients who couldn't see what was happening with their money
Internal Banking Admins manually moved funds and resolved errors outside the product, with no audit trail
External Funds Admins had zero visibility into their own banking activity, leading to constant support requests
This wasn't just an inconvenience—it was a liability. Without transaction history or error tracking, every issue required manual investigation, every client question became an escalation, and Motus had no defensible record of banking activity.
My Role
I was brought in to design operational tools for a team that had never had a designer. Working directly with the PM and internal banking admins, I translated simple user stories into solutions that balanced technical constraints, cross-product consistency, and the needs of multiple admin types.
Multi-Product Ecosystem
Admins don't experience "products," they experience Motus. But behind the scenes, they move between Admin Portal (daily workflows), Insights (modern reporting UI), and now Payments (new banking tool). Every design decision had to account for this fragmented system.
Migrating from an Existing Legacy Banking Systems
Internal banking admins were already using MBS (Motus Banking System) with established workflows. Building a new Payments product meant rebuilding processes while accounting for existing mental models and operational patterns they relied on.
Component Decisions
With Motus undergoing a design system upgrade, we couldn't reuse existing components. Everything needed to be built new, even if similar patterns existed elsewhere. This made every component decision strategic: does rebuilding this actually streamline workflows, or are we duplicating something admins can already access?
Creating Cross-Product Cohesion Across a Fragmented System
Admins don't think in terms of "products"—they think in tasks. But a single workflow might require navigating from Admin Portal to Payments to Insights and back. I needed to create a cohesive experience across this fragmented system.
Audit Log Filtering and Scalability
I designed a comprehensive audit log that serves as the system of record for all banking activity. With thousands of clients and high transaction volume, the log needed robust filtering. I adopted patterns from Insights (Motus's reporting product with a newer, data-table-driven UI) including column visibility controls and multi-filter capabilities, even though the audit log lived in Admin Portal. This positioned the banking tools to align with where the design system was heading.
Error Handling Integration
Errors needed to be visible without creating noise. I explored surfacing them on company pages, but this only worked if you already knew there was a problem. Instead, I integrated error events directly into the audit log as a filterable event type, giving admins both proactive monitoring (global error view) and reactive troubleshooting (company-specific drill-down).
Common error scenarios I designed for:
01. Failed disbursements due to bank account being closed
02. Insufficient client funds preventing payouts
Reduced Escalations
External admins, especially new clients experiencing the Motus reimbursement process for the first time, previously had no product to look at. Not only did the addition of the Payments product reduce confusion, but it also provided visibility into every stage of the funding process.
Improved Internal Workflows
Banking admins validated that the audit log met their operational needs through iterative check-ins. Most importantly, the tool gave other internal admins who are the first line of defense for our clients visibility into errors that could cause delay in payments.
What I Learned
This project taught me how to design for operational complexity. Enterprise B2B products require different trade-offs: performance over visual polish, flexibility over simplicity, and designing for the messy reality of how admins actually work—not idealized user journeys.
Working without prior banking experience forced me to ask better questions, map workflows I didn't understand, and design systems that could evolve as I learned more about the domain. The best solution wasn't the most elegant, it was the one that worked within messy constraints while setting up future iterations for success.