While there aren’t code examples I can share from Zapier (or any prior roles), I’ve compiled screen recordings for the pages I made the most significant contributions to throughout my time working at Zapier. Each example also includes a link to the live site if you want to view the pages in their current state, just be aware that the pages/flows will likely include changes that were made since I left the company (2025). I’m always happy to further describe these examples with supplemental technical or execution details:
Zapier’s user dashboard, new-user state (circa 2025)
Zapier’s user dashboard, with some usage-based customization (circa 2025)
This page requires an existing account or a free sign-up in order to view. The more a user explores and develops/enables Zaps (Zapier’s lingo for automation workflows), the more this dashboard is expanded and custom recommendations made based on their usage patterns and linked app integrations — new linked resources are added, recommended templates are customized, and new sections appear that feature recently-run Zaps as well as Zaps that may require attention (examples include Zaps that have failed unexpectedly, Zaps where app authentication is incomplete, etc). This page was the primary focus of the team I spent the last year or so working alongside and throughout that time it required the most creative problem solving to find solutions that suited our users, the design and product teams, and a wide variety of stakeholders across other areas of the organization.
Zapier’s new user onboarding flow (circa 2025)
This page requires an existing account or a free sign-up in order to view. By asking for immediate user input to the questions in this flow we were able to improve recommendations for educational resources and blog articles that would be featured on the user and to help guide users into their first few Zap use cases and get Zaps that suite those use cases up and running as soon as possible. This approach enabled us to increase upgrades from free-to-paid accounts and Zap creation/activation rates on fresh accounts. This flow is one of the first micro-frontend apps I contributed to when I first joined Zapier, relatively little has changed since.
/app/onboarding/[stepSlug]?Zapier’s 1-app integration page (circa 2025)
Zapier’s 2-app integration page (circa 2025)
Zapier’s (legacy) workflow template detail page (circa 2025)
These pages were created with to let current and prospective users interact with multiple aspects of relatively basic but popular Zaps and explore the possibilities for how they’re configured before entering the Editor view such as possible app pairings popular templates that integrate with specific apps or app pairs, popular triggers (the “hook”-style steps that kick off an automation) and actions (the “reactive”-style steps that follow a trigger, often acting on the data captured in the trigger step), to mix and match the actions and triggers available for the specific app combination in order to find trigger and action combinations that adequately suite their particular use case, and to explore relevant resources (blog posts, FAQs, application details). These (and a few related pages) were among those that we migrated from an outdated frontend service and updated to accommodate an up-to-date frontend service and recent design decisions and initiatives for improving visual consistency and component reusability between pages.
gmail one-app integration page, the gmail + slack two-app integration page, and a specific (legacy) workflow template detail page but the same view applies to all app integration pages that match the following URL pattern: /apps/[primaryAppSlug]/integrations/[secondaryAppSlug]? as well as all (legacy) workflow template detail pages that match the following URL pattern: /apps/[primaryAppSlug]/integrations/[secondaryAppSlug]/[workflowId]/[workflowSlug]Throughout my time at Zapier, I consistently contributed to the company-wide design system (named Zinnia) which is a library of common components, micro-services, etc utilized by engineers across all front-end applications that make up both the marketing site and in-application experiences on zapier.com.
Most often my contributions to Zinnia took the form of backwards-compatible alterations to the common components. In order for the changes to be included in the published version of Zinnia, the alterations had to be accompanied by the addition of relevant documentation and usage examples (in the form of Storybook “stories” for the front-end components) to demonstrate new functionality and/or document any limitations that may apply. Unit tests and accessibility checks were run via CI/CD pipeline the standard expectation for contributions was that not only did all existing tests need to continue passing, but new tests that cover the new component states or functionality had to be included in the merge request before any of it would be published.
I deeply admire the small team of engineers dedicated to Zinnia and their dedication to quality code. While other areas of the application were permitted to be experimental (within reason), contributions to the design system required a higher caliber of quality, consideration, and communication — which meant I often learned a variety of new best-practice standards while working with this team that I could bring back to my own team for consideration. Similar experiences occurred when collaborating with other teams, but the consistency with which I learned valuable new development skills while working with this small-but-mighty team deserved a specific call-out.