As an early employee at Remote, I was the first person leading design for the fintech product developments teams. I also played a key role in refining and enhancing Remote's design process and design system.

Below are highlights from my time at Remote.

Scaling Remote’s Payment and Billing Experience

Problem

When I joined Remote, the payments and billing experience was a patchwork of data tables, built with no design input. As the first lead designer on the fintech side of the platform, I began identifying gaps in our service, gathering customer insights, and realized our current solution wouldn't scale. Customers didn't understand the payroll process, couldn't find invoices, and were confused by different workflows to pay an invoice.

Solution

The information architecture was redesigned, and the customer's two primary tasks - making a payment, and viewing an invoice - were clearly separated. Many smaller usability improvements were also included. The solution was pragmatic, focusing on customer impact, rather than a complete overhaul of the payments and billing experience. The solution scaled to address key customer pain points., and as a result we saw fewer late payments and a reduction in billing-related complaints.

Centralising Payment Records in Remote’s Platform

Problem

Payments were manually processed outside of the platform by Remote's internal team, and no payment records existed inside the platform. This solution was manageable at the start, but became problematic as Remote grew. The lack of visibility inside the platform meant manual checks and email conversations were required to check payment statuses. The workload for the internal team became too much, and customers didn't know when they would receive payment. 

Solution

Detailed payment records were built, with payment statuses that automatically updated when a new payment event occurred. Remote's internal team was able to manage payments directly in the platform, and the Remote platform soon became the team's single source of truth. The solution also enabled customers to track payments themselves, without having to reach out to customer support.

Redesigning Remote’s Data Tables

Problem

Data tables served as the primary way customers and internal teams interacted with data in the platform. As Remote grew, the table-based experience declined. Data tables needed to support more use cases, and new features were built on top of the data table component without consideration for the customer's entire experience in the platform.

Solution

I led the overhaul of Remote's data tables, rethinking how customers and internal teams interact with data in the platform. View more information about the process, solution, and challenges in the case study, Data Tables at Remote.