Cross-Border CSV Upload
Timeline
Q4 2021 – Q1 2022 (3 months)
Skills
Auditing, solution exploration, prototyping, and strong developer collaboration
Main Squad
Waqas (Director of Product)
Ming (Pod Product Manager)
Chris (Tech Lead)
Hansel (Frontend Lead)
Supporting Squad
Aleksey (Original feature PM)
Diandra (Original feature PD)
Bianca (Design Systems lead)
Omri (Co-founder)
Research
Before I joined the Payment Methods pod, the team ran discovery interviews with several clients/prospects. I pored through their notes and transcripts to identify survey participants on a different project, which made it much easier to ramp up to the pod's focus area and this project when I joined.
Waqas, the Director of Product, identified CSV Upload as a feature that would be quick to update to support cross-border payments and allow users to pay 1-many vendors (as opposed to only 1 at a time). This broadened Routable's functionality for its cross-border payment beta-testing cohort.
In order to best understand the feature, I ran through many of the specific QA testing tasks, picked the original designer’s brain, and documented the existing flow in a diagram since I was unable to find one that was up-to-date.
The flow diagram was a useful artifact to define and iterate on the steps in the flow that would need to be updated. It was also the quickest way to kick off collaboration with developers and other stakeholders, and it helped my new Product Management counterpart, Ming, ramp up on understanding this feature and the proposed updates more quickly.
Syncing with the original designer was crucial to understand the feature at a high level. I also learned what was left out of the initial versions, and I connected with the original product manager for any additional questions.
Now that we knew how the flow would ultimately function and which parts of the flow would need updated design, it was time to start exploring solutions.
Iterative Design
The designs went through roughly 3 major iterations, with explorations on particular elements sprinkled throughout. Here's a link to the working file if you feel so inclined.
Since this feature is relatively simple on the user-facing frontend, I mostly focused on the summary step of the flow. Everything prior to that step is primarily a backend concern. From a user’s perspective, you upload your file, review a summary of the payments you are about to initiate, and then initiate all of the payments. You may also have to handle some errors in your file and reupload, and/or get approvals from folks on your team before you can initiate the payments.
More information needs to be summarized for cross-border payments — especially any associated fees. The fee structure for cross-border payments is both more complex and more expensive than domestic payments, and one big insight that came out of the research was that other products aren’t great at making those fees clear. As a result, fee transparency became one of our guiding principles.
Near the end of the project, we ran into what appeared to be a huge snag — another pod was set to release a separate update for CSV Upload that would allow several new dynamic scenarios (eg. a vendor could choose their payment method a month after the upload had been completed). I thought I would have to design for numerous edge cases, but after taking the time to investigate each possible scenario (and clarify some ambiguous language from the other team), I realized the design for the summary step held up just fine. A quick check with the rest of the team confirmed it!
Some additional big wins came from the frontend lead, who advocated an alternative way to progressively disclose `All payments`, and the UX writer, who helped us create the clearest error messaging possible.
Here's one of the final prototypes:
Learnings
This project ended up being a bit of a moving target, but since both the product manager and I were new in our own way, that would have been tough to avoid. My initial design explorations were quite conservative, which goes against what I typically strive for with this kind of timeline: Go big and pare back as needed. It seemed like I had wasted time in the early stages of the project, but it actually paid off when we needed an MVP to keep one of our beta clients from churning. I was able to use those initial designs for the MVP, but they ended up churning for other reasons later on anyway. Cool!
If you're curious about the results of the work, well so am I. Getting any qualitative or quantitative feedback from a previous company is not easy. Hopefully I can replace this paragraph soon.