Redesigning an interactive editor

At Zapier, we give our users the building blocks to connect and automate the web apps they love—no code required. And once they link up 2 tools, our service can automatically pass data between them, so our customers can focus on the more important stuff.

Designers use Zapier to collect feedback by automatically sending Typeform responses to their user research Trello boards. Project leads use it to turn starred Slack messages into Todoist tasks. And marketing teams use it to keep in touch with Eventbrite attendees by adding them to MailChimp lists. If you can dream up an integration, Zapier can help you build it.

We call the virtual construction zone for those integrations the Zap Editor—it’s always been pretty good at facilitating one-to-one app connections.

But here’s the problem: Zapier’s not just one-to-one connections anymore. It’s one-to-many—as many as you want. That’s the power of our biggest update ever, Multi-Step Zaps. Now you automate 3, 5, or even 20 apps with a single workflow. The possibilities are endless, and way more intricate.

Complex app combinations required a more powerful editor. Our goal was to create something simpler than the original while adding more flexibility to our app.

Here’s how the Zapier product team designed the new Multi-Step Zap Editor by taking risks, cutting out unneeded options, and working one-on-one with our users.

The problem

We call any connection between applications that performs a specific task a Zap. When you build a Zap, you’re deciding which apps to connect, which accounts to use, and what you want to happen when it runs.

That experience could be quite stressful or intimidating with even just 2 steps. Add in the complexity of multiple steps with multiple actions, and things get interesting.

Our legacy editor, while simple to use, wouldn’t let you add more than one trigger and one action. A Trigger is what kicks your Zap off—like a New Email in Gmail, for example. The Action is what happens when that Trigger occurs, maybe Send Channel Message using Slack.

Let’s say you’d also like to save the email’s attachment to Dropbox. That would be a second Action in your Zap—“Save Attachment.” That’s the magic that you see inside the new editor—the part our legacy editor wasn’t able to support.

Multi-Step Zaps add an exponential number of possibilities and combinations, and with them comes a more complex back end and UI. Although you’re performing complicated and technical tasks in the editor, we want you to feel like you’re doing something as simple as pouring a cup of coffee. We want our editor to handle the heavy lifting, and allow our customers space to be creative.

Redesigning the editor

We built our new editor, which has been in the works for almost a year, on 3 ideas:

1. Zapier customers are adventurous, savvy, and driven to do more
2. Multi-Step Zaps need a flexible editor that can stand up to the stress of complex workflows
3. The new editor’s interface needs to feel seamless and simple

5 months before release day, we were due to launch a redesigned version of the editor to 10% of new users. I was new at Zapier and had spent most of my time working on user onboarding. I didn’t know much about the editor and had come in to help with responsive styles and take care of a few remaining CSS tasks.

The team had been doing a lot of user testing before I joined, and they’d gotten lots of positive reactions from our customers. Our users told us that the editor was great because it provided the tools they needed to construct multi-step workflows. It was what they asked for.

But something still wasn’t right. It felt harder to them. They were telling us that it took more time to set up a Zap, and that there seemed to be more steps.

In reality, there weren’t more steps, but users thought there were. Certain steps seemed like they were dragging, and they introduced frustration to the experience. Our initial redesign added power, but the effortless feeling was gone. Shipping something sluggish wasn’t an option.

We decided to hold off a little longer on the release and instead spend more time building something that we were sure people would love. Sometimes you have to take a step back to realize it’s time for a redesign of your redesign.

1. Default to action

We’d been working on the editor for over 6 months, but we wanted to get it right. At Zapier, we always try to default to action—a wrong decision today can be changed tomorrow. We set up a meeting to talk it over and come up with a plan to make some necessary improvements.

I, alongside our engineers (Justin Deal, Steve Molitor, and Craig Labenz), our CPO (Mike Knoop), and our CTO (Bryan Helmig) got together on Zoom. We started going over our users’ problems. Then we discussed what it would take to do another design pass and what our timeframe would be if we decided to do it.

On my first day at Zapier, a few different teammates gave me advice: “Do whatever you think is good. Make something crazy.”

So, I did: I went to the meeting with mockups of a very different looking editor.

I was pretty sure everyone would agree that it was too complicated to deliver in our timeframe—I thought it was, too. But I went ahead and shared my screen. What followed was a brainstorming session that led to starting on a redesign of the editor the following week.

Even if your idea isn’t perfect, put it out there. Take every opportunity to spark conversations with your team and debate the merits or problems with design changes. You never know what new ideas might come from simply sharing a rough sketch or mockup.

Remember: a wrong decision today can be changed tomorrow.

2. Simplify complexity

One thing that was important to me from the start was that the editor feel visually connected to other parts of Zapier. Right before joining the editor team, I spent a few weeks redesigning Zapier’s Task History pages, a user’s record of every task they’ve automated.

I designed and implemented a new timeline element for the detail pages. A soft gray line connects each step of a task. You can dig deeper into each step by expanding the input and output data of each task. But if you just want to see if the task ran successfully or not, you’ll see that first—no digging necessary. I felt that this same language could be applied to the editor in some way.

3. Better together

I continued to work on mockups in Sketch, and uploaded them to InVision for feedback on interactions. The engineers started working on some of the required back-end and front-end changes. We already had a good foundation, we just needed to move things around.

One challenging part of the redesign was going from a multiple-page editor to a single-page editor. There were some things we needed to work out on the front end in order for everything to behave as we’d designed.

Instead of pulling users in and out of contexts at each step of their Zap, the new version of the editor guides you through the entire process, and the context changes as you go—no need to initiate it.

Each step and substep of the process defines what the next step will be in many cases. The idea of the sidebar is to provide more transparency, but sometimes we don’t know what we’ll need until the user selects another option. The editor sees that change and is smart enough to say, “Okay, now we’ll need that Webhook URL.”

Communicating this visually was a challenge. We need the user to understand which context they’re in so they know how to move forward. They would also want to know what the next step would be, and be able to gauge how much further they had to go. We decided to be explicit about what we’d need from them, and based on their inputs, ask for more information at the appropriate times.

To communicate this I relied heavily on color, typography, and iconography in the sidebar. I  pushed for simplicity and visual communication over using more text. I wanted the design to allow for a natural progression and to keep from getting in anyone’s way.

As a team, we met every Monday for an hour to share what we’d completed and what we planned to work on next. With everyone present, it was a great time for knowledge sharing and open discussion. When anything unexpected came up between meetings, we’d have a conversation about it in Slack and come up with a plan.

The process for managing scope and tasks for the project was similar to other projects. We create task checklists using Hackpad, organize them into categories, and prioritize them. Once someone finishes a task, they pick up the next one and put their name beside it.

4. Test assumptions

No matter how confident you are in your designs, there are bound to be some rough edges. That’s especially true of a product like Zapier, where we hand users a toolbox of 500 apps and tell them “Have at it!”

So to make sure we were on the right track, we enlisted our favorite UX researcher, Eileen Ruberto. She conducted usability tests on the new editor and interviewed everyone, from new customers to power users. Some of them had seen a beta version of Multi-Step Zaps, while others had never heard of Zapier.

Eileen scheduled times to chat with our customers over GoToMeeting and invited the product team to listen in and observe the tests. The responses we got were invaluable: it’s a privilege to experience user feedback firsthand.

We didn’t need to devote time and resources to user testing—we could have pushed the code live. But we would have been launching an inferior product. We wanted to open up more doors for our users, and they told us which ones to unlock.

Your customers are your compass. Listen to their frustrations, and they’ll guide you to your next amazing feature. When you take the time to talk through their pain points, you’ll start to understand which parts of your product need some extra TLC. Trust me: hearing frustrations and joys directly from a customer during a live screen share is the best kind of motivation.

The feedback that Eileen collected gave us encouragement, confirmation, and clarity along the way. And if we hadn’t stopped to collect it, you might be looking at a drastically different end result.

Automating the future

After off-the-wall iterations, in-depth user testing, and more than a few late nights, we’re happy to share our new-and-improved Zap Editor. We also built a new landing page specifically to illustrate all of the exciting new features that the editor puts into your hands. Give it a try (free for 14 days), and let us know what you think.

Takeaways

• If something isn’t right, don’t be afraid to switch directions—even if it means missing a deadline. Everyone will be much happier in the end.
• Forget about egos. Keep an open mind and encourage feedback. Don’t forget why the project exists in the first place.
• When redesigning a key feature, take the necessary time to research and test throughout the project. Encourage teams to join the testing sessions.