Request & Receive

In late 2023 we set ourselves the goal to reposition WeTransfer as the one-stop service to get (as well as send) big files. For over six months, I led the end-to-end design of File Requests—arguably the biggest new feature brought to the product in years.

Overview of end-to-end file requests feature set

The opportunity

Many WeTransfer users don’t choose to use our service, but they’re asked to by others. We identified that nearly two hundred thousand paying subscribers download over two million transfers a month, and receivers typically outnumber senders almost threefold.

Getting the right files, in the right format, on time, and in one place is a need faced by millions of our customers across various industries and roles.

Working closely with my product manager, we shaped a strategic proposal for a new set of features that would cater to two primary categories of jobs to be done:

one-to-one requesting
one-from-many receiving

We focused on developing product-market fit for a single set of use cases first before scaling to adjacent audience needs.

A viable bet?

By helping people gather and track large files in one place, our goal was to improve the ‘retention valleys’ that occur when people subscribe intermittently. Working with business performance analysts to model impact, we predicted a 4–7% increase in M1 retention following the adoption of file request benefits.

Snapshot from assumptions mapping session — I start every sizeable initiative with an assumptions mapping workshop to create alignment across multi-functional stakeholders.

Competitors like Dropbox and OneDrive offer high friction functionality for this need, but we believed WeTransfer’s scale and ‘radically simple’ UX ethos would enable us to claim and lead this market.

Testing assumptions, not solutions

With any sizeable project, I invite stakeholders across functions to participate in an assumptions mapping workshop to create alignment. These insights help inform which gaps in our knowledge and confidence we can fill in with user research.

Creative professionals (our core audience) are often held back waiting on assets from clients and collaborators who aren’t always sure what is required of them, when it’s due, or how to supply it.

I ran a series of concept tests on early prototypes to build a better understanding of the needs and pain points to address. Creative professionals (our core audience) are often held back waiting on assets from clients and collaborators who aren’t always sure what is required of them, when it’s due, or how to supply it.

By mapping out the spread of opportunities, we were able to work with engineers to determine a feasible MVP spec and approach the work in three phases:

request upload flow
request creation flow
request management flow

Extract from user flow wireframes — Early wireframe mapping of user flows.

Design discovery

Throughout this process, I worked closely with our team’s engineers to graduate from low to high-fidelity explorations. Drawing on competitor analysis and observing request UX patterns across adjacent industries (such as payment requests), we explored a range of intervention proposals, iteratively presenting our latest thinking to customers.

Example of the range of visual explorations of the request upload flow — Selection of visual explorations of the request upload flow.

Ongoing communication and collaboration was essential throughout this process. For example, we had to ensure our approach to fulfilling requests didn’t have a negative impact on wallpaper advertising. We also checked in regularly with our support team to see how our proposals resonated with the concerns and suggestions they’d received from customers over time.

Following insights from user interviews, we also discovered that file requests have the potential to be used for malicious intent—bad actors posing as trusted brands to acquire sensitive data from others, or distributing suspect materials by hacking the upload process. We worked with the Trust and Safety and Legal teams to prototype solutions to mitigate and moderate such scenarios.

The ontology of a request

One of the first major hurdles we encountered was how to define and align on exactly how a request works. An early perspective was of requests as essentially ‘empty transfers’—mutable containers with predefined property values that can be eventually filled with files by another actor.

This model proved insufficient for several reasons, the most pressing being that it does not sufficiently cater to ‘one-from-many’ use cases. We explored three competing architectural models:

request as a draft transfer
request as a folder
request as a separate entity that can reference multiple transfers

We landed on the latter as the most robust and scalable approach.

By involving engineers in the co-designing process we discovered that building out an entirely new relational entity would reduce code complexity and avoid future friction.

A many-legged creature

The initial confidence with which we’d identified the problem space and outlined our end-to-end proposal betrayed some naivety, as we continued to identify dependencies and unforeseen challenges:

What limits and entitlements (max open requests or request uploads) will users face based on their subscription tier?
What are the properties of request states (closed, unpublished, expired, or deleted)?
Which notification emails need to be sent and to whom?

Spinning plates

On the surface, WeTransfer is not an overly complex product, yet concurrent parallel projects redesigning the main navigation, transfer send window, and wallpaper builder required trust and constant coordination across design teams.

Examples of requests feature entryway explorations — The evolution of explorations into surfacing file requests without impacting sending flows or wallpaper advertising.

Our shared design system saw a flurry of updates in this period as we took the opportunity to consolidate new UI and interaction patterns, and a seemingly straightforward initiative to surface the request creation form briefly spiralled into an existential investigation into the information architecture and conceptual model of our entire product offering.

Lofi workshopping of product architecture and conceptual models.

However, this work allowed me to streamline the styling and visual grammar of various entities (transfers, requests, reviews) across the system—a scope increase justified by the valuable UX improvements it would provide.

Example of the new structure and 'grammar' of entity teasers

The devil in the details

When shipping a product to millions of users, the details matter. Every line of product copy, every border, every value of form field padding or transition duration has been meticulously considered.

A range of explorations into how to communicate storage limits in the request form — A sample of design explorations into how to best communicate impending storage limits whilst keeping users in their flow.

Every line of product copy, every border, every value of form field padding or transition duration, has been meticulously considered.

Engineering had already commenced long before any final end-to-end designs were approved and handed off. As design progressed through the phases identified early on, I ran repeated rounds of usability tests across all flows and shared the insights with the wide team to continue refining the final designs.

Mobile flow showing annotations for accessibility and stress cases.

Besides earlier due diligence, I conducted dedicated accessibility testing and continued to identify further edge and stress cases. As v1 was built behind a feature flag, I was able to provide rolling design QA up to and following release.

Going to market 🚀

In the months leading up to launch, we liaised with product marketing and customer insights to identify key activation and conversion touchpoints and shape how Request & Receive would be positioned, which value propositions to highlight, and how we would talk about requesting files.

One of the most fun parts of the entire project was supporting our creative studio team to bring our work to life in the form of marketing and onboarding videos. I consulted on the script, storyboards, and edits—and in early September 2024, we rolled out the ability for millions of users to request files on WeTransfer!

Launch trailer courtesty of the amazing in-house creative studio and product marketing teams at WeTransfer.

Minimum viability, and beyond…

Of course, we hadn’t been focused entirely on v1. Throughout the design discovery process, I explored ‘destination postcard’ treatments for how we imagined Request & Receive evolving to address the wider array of needs and pain points we’d earlier identified.

Every week I aligned with the product and engineering leads on our team to calibrate our desired roadmap post-rollout, shaping our priorities through to v2, pending insights from real usage data and further user research.

Examples of these ongoing improvements include:

Request details view with analytics
Improved transfer management tools
Auto-storage with third-party integrations
The ability to design request pages
Improved notification management controls

But that's a story for another day…

Shout-outs

When I see ‘we’, I want to thank the following colleagues in particular: Matthew Willse, Kelly Stevens, Erika Rossi, Jeremiah Chaney, Nicole Stanton, Joe Yuhas, Maxi Céspedes, Matt Riley, and Kayleigh Fuggat.