Project

One of the major gaps identified in the content map of Zapier's new user journey was that creating a Zap in the editor involved several complex concepts and steps that lacked context and guidance. There were also multiple instances of unclear language and terminology in the Zap editor which weren't helpful for users.

I partnered with the UX designer on the Editor team to conduct a full content audit of the Zap editor, remove jargon and confusing language, identify opportunities to create clear, concise, and useful content, and provide more contextual guidance for users.

Strategy

We started by establishing three guiding principles for content improvements:

The first major change we implemented was to update the content in the trigger step. The original heading was "When this happens...", with a tiny question mark icon that would open a help article about setting up a trigger in the sidebar.

The absence of the key concept "trigger" made it difficult for users to build a consistent mental model of a Zap, as well as confusing to reference in documentation and communication with users (e.g., asking users to click the "When this happens..." step when explaining how to set up a Zap trigger).

The step also included a Built-In Apps section, which user research and feedback from the support team identified as a major point of confusion for users who did not know what these "apps" were or how to use them.

We

We updated the trigger step heading to "Trigger", and added the standard definition of a trigger as "an event that starts your Zap" from the Zapier Content and Messaging Guide. We replaced the tiny question mark icon with a "Learn more" button, which had greater visibility and information scent.

Lastly, we changed the way we defined and displayed user apps and our built-in triggers. In App event, a user would choose to start the Zap when an event happens in one of their apps. The built-in triggers were displayed on the right, with a clear explanation of what they would do—for example, the Schedule trigger would start the Zap at a specific time interval.

The trigger test section received a complete content and design overhaul. Before, this section had the heading "Find Data", mentioned the "samples" from the user's trigger app account, and directed them to "pick 1 to set up your Zap". Users had the option to choose from one of three samples, as well as click a "Get More Samples" button.

We knew from past user research that users did not know what this step was supposed to do. They didn't understand what a "sample" was, why there were multiple samples, and on what basis they should choose a sample. Clicking the "Learn more" link rarely helped to answer their questions.

We updated the section heading to "Test trigger", added icons showing the flow of data from the trigger app to Zapier, and added a clear description of the purpose of this step: "to confirm that the right account is connected and that their trigger is set up correctly". We also removed all instances of the word "sample", and simplified the actions that a user could take with a single "Test trigger" button.

We explored a brand new content approach for one of Zapier's trickiest concepts—dynamic values When you create a Zap, you may occasionally want to pass information from the trigger step to the action step.

For example, if your trigger is receiving a new SurveyMonkey survey response, and your action is sending an email in Gmail, you might want to populate the "To" email address with the email address of the survey respondent.

The problem was that this concept was not defined or explained to users anywhere in the Zap editor. In action fields that supported dynamic values users would see the placeholder text "Enter text or insert data...". Opening the dropdown menu would show a searchable list of dynamic data options from earlier steps, but it wasn't obvious to users what this meant.

Users who didn't understand the concept of using dynamic values to map data would frequently enter a static text value, not realizing that this same information would be sent to the action every time the Zap ran. This was a constant source of support ticket volume, and support reps would have to explain how data mapping worked to users with videos and screensharing.

We decided to experiment with embedded contextual guidance by adding a beacon to input fields that supported dynamic values. When a user hovered over the beacon, a tour tip would open with an animation showing the dynamic value changing. This also included an explanation of the concept: "information from earlier steps in your Zap", and a "Learn more" link that would open a help article explaining the concept in more detail in the sidebar.

We conducted several rounds of testing with low-context users to find out how the animation and description would help them understand the concept of dynamic values.

Outcome

The user research and iterative testing for each individual content and design change helped us to validate concepts and usability. We then adopted a methodical approach to release and test the impact of these updates in the live, open environment of the Zap editor.

Changes were first rolled out to a percentage of new users in a bandit optimization. Over the course of a month, we measured and tracked relevant metrics such as step completion rate, Zap activation rate, and support ticket volume for related issues. A few key results include: