Zapier Transfer
The original problem that initiated Transfer involved Zapier users running into missing blocks of data when their Zaps failed or generated errors. A Zap’s job is to move data from one app to another at the occurrence of a particular “trigger” event. So if a Zap breaks, there is a gap of missing data and a user would have to manually move the missing data from app A to app B. This experience was painful and time-consuming for users, and Zapier set out to build a solution to solve this problem.
Overtime, Transfer grew and evolved to serve additional use cases.
Context
Transfer was Zapier’s first “standalone product” and marked the start of a “New Products” arm of the company.
Zapier has always taken a default-to-action, build-fast-and-iterate approach to product development. Transfer was designed and built on an accelerated timeline of 6 months to launch as a Beta in time for Zap Connect in October 2021. At the time, the company’s priority was to become a multi-product company, and Transfer was Zapier’s first standalone product experiment.
Design process
I designed multiple iterations of the product, iteratively sharing with the product and engineering teams in design reviews and identifying requirements and technical constraints given the tight timeframe of the delivery, and iterating on the designs accordingly.
I also worked with a content designer to determine the best approach to content information architecture while remaining congruent with a comparative Zapier Workflows experience.
Original scope
The scope of the Beta was to support users in moving data from App A → App B relevant to their use case, across Zapier’s thousands of app integrations. The project involved stringent technical constraints and a tight delivery timeline, and I worked with the engineering team to map the core steps of the user journey:
Choose source and destination apps
Specify use case
Connect accounts
Map fields between source and destination
Preview data
Filter data and select records
Confirm the Transfer
Run the Transfer
Get notified upon completion
Track Transfer activity and status
Troubleshoot if errors occur
Start of the journey
For the start of the journey, I considered three key options for app and action selection.
In the first option, the user would select the source and destination app for data and see a stacked list of “recommended for you” options in the section below. In the second option, the user would select the source and destination apps, and select from a list of data types on the same screen before continuing. In the third option, the user would select the source and destination apps, and continue to the next screen to select the relevant data type based on the apps chosen.
The team decided to go with option 2, where the user can select both the apps and the action on the same screen to reduce number of clicks, encourage interactivity, and for optimal clarity of content and displaying relevant content together.
Option 1: Select source and destination apps + “Recommended for you” section
Option 2: Select source and destination apps + Select data type
Option 3: Select source and destination apps + continue to next screen to select data type
Filtering
I explored a variety of approaches to filtering data in a Transfer, including a modal, a sidebar, an accordion, on-screen filtering, and a standalone filtering screen. I met with my team to consider each approach, discuss considerations, and decide on short and long term implementation plan.
There were pros and cons to each solution from UX, content, and technical perspectives. From a UX and content perspective, we felt it was important for filters to be set and modified in-context of the data, so we steered away from the standalone screen and modal solutions.
The team agreed on the accordion solution to utilize the existing Zapier design system and build more quickly, while planning to scale to our preferred on-screen filtering solution as future release.
Beta
Transfer was released as a Beta during the ZapConnect conference in October 2021.
User Feedback
We gathered feedback from hundreds of users via Typeform on a rolling basis, interviewed users, and synthesized users’ motivations, pain points, and needs.
What were you trying to accomplish?
What were you able to accomplish?
How easy or difficult was it to get your need met?
How can we improve Transfer?
What else do you wish Transfer could do?
What went well?
Evolution of Transfer
My PM and I prioritized additional use cases and made new functionality product decisions in response to user feedback:
Data migration: Adding additional source integrations; supporting users that migrate app platforms and need to move old customer data into their new application
Scheduled transfers: Allowing users to schedule a recurring Transfer to take place hourly, daily, weekly, or monthly
Update or create: For recurring Transfers, enabling users to update existing data when it changes, rather than only moving records that are new
Reverse ETL: Supporting users in moving data from data warehouses (Snowflake, Redshift, MySQL etc.) to apps they use every day.
Success Metrics
We measured a variety of metrics to track success and growth:
> 1 million tasks per week completed by users
3500 people using transfer for backfilling weekly, Transfer’s largest use case
Successful tasks hit a high of 1.5 mil for 7 day period in February; more usually 1 mil per week contributing to company ARR
Projected to contribute to 3 mil of Zapier’s ARR in 2023
Since releasing scheduled transfers, retention grew from <60% to 70% and weekly active users grew steadily to exceed 350.
Challenges
Zapier’s continual shifting priorities did not allow our team the focus nor bandwidth to make adequate UX improvements or minimize errors in the Transfer experience. Though functional, Transfer’s UX could have been far better if we had had the opportunity to invest more technical effort into building the backend needed to support a more user-friendly experience, rather than applying not-always-fit-for-purpose Zapier code to a product very different from the rest of Zapier.
Before the team pivoted to supporting Zapier Tables, we had hoped to prioritize needed UX improvements on our roadmap, which were deprioritized during Transfer’s initial build due to technical complexity:
User-friendly source search and selection
Clear data mapping
Revamping the structure of the IA into digestible, user-friendly steps
These UX recommendations were developed based on patterns observed in the Reverse ETL market as well as user feedback gathered through surveys and interviews.
One of the challenges around Scheduled Transfers, which did not gain significant traction in increasing usage, was that it did not offer a pricing incentive when compared to a traditional Zap, and that the use case sounded similar to a traditional Zap to many users which didn’t create competitive differentiation. It was more of a backend stepping stone towards supporting real-time sync in the future.
Similarly, Update or Create and MySQL-as-a-source functionality laid the backend foundation for future growth towards large-scale data integration in the Reverse ETL marketplace, however in itself didn’t contribute to significant growth of the product, and the original builds possessed poor usability, given Zapier’s build-first-improve-later approach. The team’s shift to Tables prevented us from being able to make the improvements needed to make Transfer smooth and polished UX-wise.