Project type: Design project at AI-powered Accounts Payable Solutions Company
Project length: 3-4 months
My role: Lead Designer
Collaborators: Product managers, engineering team, customers
Project length: 3-4 months
My role: Lead Designer
Collaborators: Product managers, engineering team, customers
Background
*Company name has been fictionalized to white-label proprietary solutions.
Vexa.ai is an AI-driven financial platform that streamlines invoice processing, purchase order matching, payments, and more. While AI automates much of the workflow, AP specialists play a crucial role in reviewing flagged invoices and routing them to the appropriate approvers with the right business context. Approvers review invoices to ensure they are legitimate, necessary, and compliant with company policies. They verify invoice details, check for business justification, and flag any discrepancies or potential fraud before approving payment.
As the platform scaled to support larger enterprise customers, a common challenge emerged: approvers who were out of office often became bottlenecks in the invoice approval process. Both existing customers and prospects frequently requested an Out of Office feature that would allow them to delegate approvals to a designated substitute, ensuring invoices continued to move through the system without delays.
Discovery
At first glance, this seemed like a straightforward problem to solve, but we needed to account for the different user flows and roles involved. To gain deeper insights, we interviewed customers who had requested this feature and consulted our own finance team. Through these conversations and internal discussions, we key considerations that shaped our design decisions:
1. Who can assign substitute approvers? 👥
Typically, approvers themselves select their substitutes—usually colleagues or managers. However, admin users emphasized the need to assign substitutes on behalf of approvers in cases of unexpected absences or when approvers forget to set one.
Typically, approvers themselves select their substitutes—usually colleagues or managers. However, admin users emphasized the need to assign substitutes on behalf of approvers in cases of unexpected absences or when approvers forget to set one.
2. How long are approvers typically out of office? 🏝️
Most users assign a substitute for absences longer than two days, though this also applies to extended leaves such as maternity leave.
Most users assign a substitute for absences longer than two days, though this also applies to extended leaves such as maternity leave.
3. Will substitute approvers have enough context to make decisions? 📝
In most cases, yes. Users indicated that if a substitute lacked context, they would simply defer the decision until the original returned. Given this, we determined that additional features to provide more context were unnecessary.
In most cases, yes. Users indicated that if a substitute lacked context, they would simply defer the decision until the original returned. Given this, we determined that additional features to provide more context were unnecessary.
4. Do original approvers want notifications about invoices handled by substitutes? 🔔
Generally, no—most users prefer to disconnect while out of office. However, some approvers still check emails and wanted optional alerts, so we decided to make notifications configurable.
5. Should this feature be available on both web and mobile? 📱Generally, no—most users prefer to disconnect while out of office. However, some approvers still check emails and wanted optional alerts, so we decided to make notifications configurable.
Yes. Many approvers rely on the mobile app for quick approvals, so allowing them to assign substitutes directly from their phones ensures they can do so easily while on the go.
Design Process
Approver’s Workflow
In the navigation bar, approvers can switch between different companies, and some have access to multiple companies. It was important to note that assigning a substitute approver applied to all companies they had access to—not just the currently selected one. While an ideal UI hierarchy would make this distinction obvious, we had to work within the constraints of the existing design. Ultimately, we determined that the user menu was the most intuitive place for this feature.
Even after deciding the user menu was the right place, I explored several design iterations. When designing a new feature, I always think ahead to how the UI might evolve. During this redesign, we discussed user status indicators—a potential future feature that would display when a user is online, offiline, or out of office. Since we eventually wanted to introduce in-app chat, it made sense to consider presence indicators.
Initially, we tied the out-of-office scheduling closely to user status, inspired by how status works in chat apps like Slack and OOO scheduling in Google Calendar. The idea was that users would intuitively click their status to set their availability and assign a substitute approver.
Early Iteration - Version 1
Early Iteration - Version 2
Early Iteration - Version 3
However, testing with customers revealed that over 60% of users didn't find the design intuitive as expected. They didn't expect to schedule out-of-office time by adjusting their status. In response, we gave it its own dedicated option in the user menu, making it clearer and easier to find.
Even though we weren't building real-time presence statuses, we decided to keep the "Active" and "Out of Office" indicators. This served as an area to remind user when their scheduled out-of-office time was coming up.
Final Iteration
Final approver's workflow to assign a substitute approver
As part of this update, we also took the opportunity to revamp the user menu. While the navigation bar’s colors were recently refreshed to match the new branding, the user menu had remained unchanged.
To enhance usability and visual clarity, we introduced a dark UI theme to distinguish it from the rest of the interface. I also added icons for the menu options and tightened the spacing throughout the menu screens for a more polished look.
In the previous design, users could update their avatar and name directly on the main menu screen. However, these actions didn’t warrant such prominent placement, as they weren’t frequently used. To declutter the menu and improve scalability, I moved these options to a dedicated profile section, allowing the main menu to present the options more clearly.
Before Design | User Menu & Settings Section
After Design | User Menu & Profile Section
To ensure consistency across platforms, I applied the dark theme and similar UX improvements to the mobile app, creating a seamless experience for users.
Mobile App Experience
Another key consideration for approvers' workflow was access control. It was also possible for a chosen substitute approver to not have the necessary permissions to access approval pages. While we debated automatically notifying admins to assign temporary permissions, we opted for a simpler approach: displaying a warning message so the original approver could take action outside the platform (via email, chat, etc.). This allowed us to address the issue without overcomplicating the first iteration of the feature.
Warning message when a substitute approver requires access
AP Specialist’s Workflow
AP Specialists manage approval flows—initiating, tracking, or canceling them—so it was crucial for them to see when a substitute approver was involved. I carefully mapped out designs for different time lines invoving substitutions.
To ensure clarity while maintaining a clean UI, I incorporated this information using subtle visual cues. The original approver was displayed in low-opacity to indicate they were temporarily replaced, with detailed change history accessible via a popover tooltip—an existing component in our design system. Additionally, since approval records are critical for audit purposes, these substitutions remained visible in historical logs.
Pending approval with a substitute approver
Rejected by a substitute approver
Approved with a chain of substitute approvers
Limitations
To define the scope of the first iteration, the product manager and I met with the engineering team to discuss edge cases and technical constraints.
1. Scope restriction to invoice approvers
This feature was designed specifically for invoice approvers and did not extend to Purchase Order (PO) mismatch approvers, as these are separate approval processes with different workflows.
This feature was designed specifically for invoice approvers and did not extend to Purchase Order (PO) mismatch approvers, as these are separate approval processes with different workflows.
2. Handling multi-step approvals
Invoices often require multiple levels of approval, meaning a substitute approver could already be assigned to a later step in the process. Ideally, in such cases, the original approver’s step would be skipped to prevent redundant approvals. However, since this scenario was relatively uncommon, we deprioritized it for future iterations.
Invoices often require multiple levels of approval, meaning a substitute approver could already be assigned to a later step in the process. Ideally, in such cases, the original approver’s step would be skipped to prevent redundant approvals. However, since this scenario was relatively uncommon, we deprioritized it for future iterations.
3. Date selector
While a date range picker would have improved usability, it wasn’t available in our existing design system. To minimize engineering effort, we opted for separate "From" and "To" date pickers instead.
While a date range picker would have improved usability, it wasn’t available in our existing design system. To minimize engineering effort, we opted for separate "From" and "To" date pickers instead.
By setting these constraints, we ensured a focused and efficient rollout while leaving room for future enhancements based on user feedback.
Learnings & Results
As always, new questions arose once engineering began implementation, and our lead UI engineer played a key role in surfacing concerns early. One critical detail that hadn’t been fully considered was the timing of UI updates. The engineer pointed out that the approval UI should continue displaying the original approver until the exact moment their Out of Office (OOO) status became active—at which point, it would update to show the substitute approver. This approach made sense, as approvers could cancel or modify their OOO schedule right up until their planned absence.
The engineering team also requested additional mockups for edge cases. While I had accounted for nested substitutions (where a substitute approver also goes OOO and assigns their own substitute), I had initially overlooked some scenarios—such as when an AP Specialist manually reassigns an approver before an OOO substitution takes effect. This feedback allowed me to clarify the designs further, ensuring the UI handled complex approval scenarios smoothly.
A key piece of customer feedback concerned the population of the substitute approvers list. Initially, we believed the list would display all users with 'approver' permissions organization-wide. However, this allowed users to accidentally select someone from a different department, creating a potential security risk. We thought this could be addressed by the implementation team during onboarding, but we realized this detail wasn't scoped appropriately from the beginning.
