Zapier Transfer
Transfer was Zapier’s first “standalone product” and marked the start of a New Products arm of the company. It was launched as a Beta at ZapConnect in October 2022, built on an accelerated timeline of 6 months.
I served as Product Design Lead from the project’s conception, initially alongside an Engineering Manager and a team of FE and BE engineers. Transfer grew and evolved overtime to serve additional use cases grounded in user research.
Context
Zapier allows users to set up automations across thousands of Zapier’s app integrations. An automated workflow is called a “Zap.” In a standard Zap, there is a trigger and an action. The trigger is an event that starts the Zap, and the action is the event a Zap performs when triggered.
For example:
“As a user, when I get a new lead in Facebook Lead Ads, Zapier automatically adds that Lead to my Sales team’s Google Sheet.”
The problem
When I joined the Transfer project and began collaborating with the engineering manager, I received a lot of information about some user problems the team was setting out to solve.
1️⃣ Moving existing data in conjunction with a Zap
In feedback collected from our support and research teams, users of Zapier were reporting a problem related to pre-existing data.
Sometimes, a user would set a up a Zap that would work from that point on and into the future, but would be left with a chunk of pre-existing data from the past in their source app with no way to easily move it to the destination app.
For example:
“As a user, I’m excited to have discovered Zapier to automate my workflows. I set up a Zap that from this point on will move every Facebook Lead into Hubspot, my CRM. But I still have a bunch of existing leads in Facebook Lead Ads that I also want to move to Hubspot.“
Additional problem areas
2️⃣ “Catching up” broken Zaps
Users were also experiencing difficulty when their Zaps generated an error and failed to run. In these instances, data that should have been moved during the Zap would go missing, and the user would have to invest a lot of time manually identifying and moving the missing data.
For example:
“As a user, I had a Zap set up that moved leads from Facebook Lead Ads into Hubspot. But my Zap hit an API error, and a bunch of new leads that should have been moved over to Hubspot since that error generated have failed to do so… I need a way to resolve this data gap and move my missing leads over to Hubspot.”
3️⃣ Moving existing data independent of a Zap
We also had users who were reaching out to Zapier about their data needs related to app migration — that is, when a user switches applications and needs support copying data over into their new app.
In this use case, users didn’t need Zapier’s standard product of ongoing automations for future events. Instead, users wanted to move historical data from one app to another app one-time only.
For example:
“As a user, I previously used Google Sheets to manage my leads, but our business has grown and we’re migrating to a CRM. I don’t need an ongoing automation, but is there an easy way for me to move my existing leads data into my new workspace?”
📊
I learned about Zapier’s organizational goals relevant to Transfer.
We agreed to explore delivery of a “standalone product experience” to accomplish Zapier’s company goal of becoming a multi-product company.
Furthermore, we had committed to releasing and announcing this product at Zapier’s ZapConnect conference set to take place in Octoberc 2021, which was a mere 6 months away.
Process
Synthesis & reframing the problem areas
I spent time processing information from different sources - user feedback and needs coming from research and support, organizational goals coming from leadership, and understanding the scope and journey of Zapier’s main product.
Current state journey mapping
As a means of synthesizing the user problems we wanted to solve, I mapped them to the current state Zapier journey. This helped me understand at what moments Transfer can help existing users, and also gave me a means to communicate with my team and stakeholders.
Future state journey mapping
I also mapped the user journey for the use case involving data migration for non-Zapier users. In this case, the journey was entirely independent from the current state Zapier journey.
Developing initial concepts
I started to develop conceptual solutions for how to introduce Transfer to users for each use case. I used a divergent thinking approach initially in that I was envisioning ideal design solutions not limited by technical constraints. I knew that compromises would be required, but I found it important to illustrate what would be most ideal for users and a possible “north star” for the team to target longer term.
For example, for users who needed to move pre-existing data associated with a Zap (Use Case 1), I designed an interaction with Transfer within the Zap build experience where it was most contextually relevant.
I also designed an email experience for the event in which a Zap failed and a user needed a way to fill the missing gap of data (Use case 2️⃣). I hoped that we could build a way to do this either automatically or at the click of a button, keeping track of the data that failed to move on the backend and not requiring a complex journey on the user’s part to locate and select the missing data from the source app.
I took these concepts to my team to gather feedback from leadership and initiate a conversation around technical constraints.
I learned that given our tight timeline for delivery, we couldn’t track the missing data and automatically move it on behalf of users, and that in every instance, even in instances where they already had an associated Zap set up, we needed the user to go through and initiate the Transfer process, at least for this first Beta release.
I also learned that keeping Transfer as a standalone journey (not embedding Transfer functionality within the main Zapier product flow) was important to accomplish organizational goals, even if that meant compromising on ideal UX for these specific use cases. It was seen as inevitable that Transfer would evolve overtime as we gathered more information from users and learned firsthand from their usage and feedback.
These conversations led me to create some design principles to guide Transfer success.
💧Design an open and flexible solution.
Though I had some specific use cases to solve for, I also felt a need for more user research and validation to build confidence in Transfer’s longterm strategic direction. I set out to design a flexible Beta solution that wasn’t too pigeon-holed and contextual in that could be used to uncover use cases we hadn’t already identified.
🧩 Be nimble for fast delivery.
Utilize Zapier’s design systems, existing design patterns and components, and cooperate with Zapier’s current BE infrastructures to reduce added technical complexity and free up more time for a high-quality build.
🗣️ Share and gather feedback early and often.
Share designs consistently with the Transfer team, engineering management, design management, Zapier leadership, content and marketing teams, UXR, and other designers across Zapier to keep parties aligned and avoid unexpected pivots too late in an already tight timeline.
⭐️ Simplify complexity.
Utilize good content design, UX, and IA to make a complex process of moving data clear and simple.
I then went back and compromised on my designs to align with feedback and design principles.
My goal was to redesign the solutions so that they were still contextual (showing up at the right time and place depending on the use case) but were more-so entryways into a broader and flexible Transfer journey to test and learn from.
For example, I created a modal solution for users to enter the standalone Transfer journey immediately after setting up a Zap.
I redesigned an email template to link users into the Transfer journey, with agreement from the team that we would skip all steps we could pre-fill based on information we knew about that user’s scenario.
After becoming clearer on the broader journey and entry points, then came designing the core Transfer experience.
I led workshops with the FE and BE data team to identify the steps in the journey, the order in which they would need to occur according to our BE infrastructure at Zapier and technical complexities. We identified steps that would need to take place in definite order, and steps that allowed more design flexibility.
For example, I created a modal solution for users to enter the standalone Transfer journey immediately after setting up a Zap.
I redesigned an email template to link users into the Transfer journey, with agreement from the team that we would skip all steps we could pre-fill based on information we knew about that user’s scenario.
I worked with the team to discuss goals to build a simple UX and IA for Transfer.
I wanted to experiment with a UX that was different than the main Zapier builder, which users often reported as complex with a steep learning curve. I saw Transfer as a standalone product as an opportunity for us to recreate an easier-to-use UX and gather user feedback and data to justify similar UX improvements in Zapier’s main product.
Zapier’s main builder featured a single screen view with expandable accordions for several complex steps.
For Transfer, I proposed on overview screen to prepare the user for the steps ahead, and individual pages for each step to reduce the complexity involved at any one point in time in the experience, and a side navigation to communicate steps completed and steps remaining.
Next, I collaborated with a content designer to envision core aspects of the journey in more detail.
We workshoped possibilities for the ordering of the journey steps, using a content-led approach to break down complexity into clear guiding headers telling the user what was happening at each step in the journey. At this time, I started generating designs using Zapier’s design system and guidelines.
Selecting data source, destination, & data types
We spent time generating 3 design variations for what the start of the journey could look like where users could select the source app (where data was coming from), destination app (where data was going to), and the data types (i.e. “Leads” from Facebook Lead Ads or “Rows” in a Google Sheet).
We discussed user pros & cons and technical considerations for each of the three options.
In option 1, 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. This would work well in the short term, but in the longterm as the product scales, there may be too many choices to display here and not overwhelm the user.
In option 2, The user would select the source and destination apps, and select from a dropdown list of data types on the same screen before continuing. This option was more scalable.
In option 3, 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. This option created a clean and simple initial view, but required more clicks and didn’t display data type selection in-context of app selection.
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 exploration and interactivity, and optimize clarity by displaying relevant content together.
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 from UX, content, and technical perspectives, and decide on short and long term implementation plan.
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 modal (1) and standalone screen (2) solutions.
The sidebar design (3) was far too complex to build from a FE perspective in that nothing like it existed elsewhere in Zapier and we couldn’t utilize our current design system to build it. We couldn’t commit to such a complex build given the timeline of the Beta.
I designed an expandable/collabsible accordion solution as well (4, 5), which displayed filters as stacked rows of dropdowns when expanded. Not the most ideal visual design, but it was clear and functional, aligned with other patterns used across Zapier, and could be built with our existing design system.
My most preferred solution (6) did not involve an accordion, but rather a single row of dropdowns for filtering that would refresh upon clicking an “Apply” button, as well as a visual means to display filters as tags once they’ve been applied. It was complex in that I designed a means to differentiate between and/or filters within the tags.
The team agreed on simple and functional accordion solution which would display filters as stacked rows of dropdowns when expanded.
Growing the backlog for post-Beta
I designed incremental improvements to the filtering experience to build post-Beta once the team had more bandwidth to do so. These improvements would help us move towards the most ideal UX experience for filtering (6).
We spent 6 months in design delivery.
During this time, we dove deeper into the details of the designs and individual components, writing content, and making compromises as technical constraints arose. We held weekly design reviews with key stakeholders, gathering feedback consistently and continually iterating on solutions.
We interfaced with other Zapier teams to design the micro journeys to needed to support Transfer, such as a means to view and manage Transfers after they’ve run, and receive emails upon a Transfer’s success or in the event of an error.
Finally, we collaborated with marketing and video teams to explore entry points to Zapier, how to communicate its value and use cases, and how to guide users through the experience.
ZapConnect took place in October 2021, and Transfer launched successfully as a Beta.
User Feedback
We gathered feedback from hundreds of users via Typeform on a rolling basis and interviewed users to understand their motivations, pain points, and needs, asking questions such as:
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?
Synthesis
We identified 3 key functionality improvements that users wanted, and created a product roadmap to design and build them:
New source apps: Users requested the addition of more source apps. We also monitored drop-off rates for Transfer and discovered users were dropping off on the app selection screen because their source apps weren’t available. We grew source app integrations from an original 12 to >30.
Scheduling Transfers: Users requested functionality involving creating a recurring Transfers on a schedule. For example, users had recurring data movements that they would manually repeat on a weekly basis, and wanted Transfer to be able to do its job recurrently, not just one-time. In our metrics, we also noticed that Transfer retention (frequency of users coming back and using Transfer again) was low, and we saw releasing Scheduled Transfers as an opportunity to grow retention rates and ARR for Zapier.
Update data: Users also expressed a desire for not just moving data one time, but moving it from source to destination and updating it if and when it changes. We experimented with releasing this functionality for 3 apps highly requested by users, Shopify, Quickbooks, and Zendesk.
Reverse ETL: Users wanted to move data from data warehouses (Snowflake, Redshift, MySQL etc.) to their everyday apps where they can gain insight on this data and grow their business.
Scheduled Transfers allowed users to setup recurring Transfers to repeat on a schedule they defined.
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.
Overtime, we explored data gathered throughout our Beta experiment and envisioned longterm strategies for Transfer.
In response to our “update data” functionality users wanted, the team and I explored the Reverse ETL market in particular. We performed a competitive analysis and looked at a wide range of competitors already operating in this space. We made a hypothetical roadmap and even prototyped what such an experience could look like, and performed research on it with over 30 users.
We identified that it would take significant time and resources to build the number of source integrations and sync functionalities needed to compete in the marketplace and make Transfer desirable for users. We weren’t strategically confident that Reverse ETL was the right direction for Zapier, as my user research suggested that users wanted not just “sync” functionality across apps, instead a consolidated home for data and actionable data insights (an even more advanced solution than syncing data alone).
In conjunction, Zapier Tables, Zapier’s second standalone product, was gaining traction, and was facing a pain point around users not having a mechanism to import data into their Zapier Table. The team decided to shift our attention to redesigning Transfer to serve importing and eventually syncing data to Zapier Tables.
Read the Tables Import case study to learn more about my work on the Tables team.