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 significant contributions to over the (almost) three years I spent working across multiple teams at Zapier. Each example also includes a linked example 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:
The more a user explores and develops/enables Zaps (Zapier’s lingo for automation workflows), the more this dashboard is expanded and customized — 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.
NOTE: this example shows the full onboarding flow, which is made up of all flow steps that follow this URL pattern: /app/onboarding/[stepSlug]/
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.
NOTE: this “single category” page example shows the artificial-intelligence app category page, but the same view applies to all app category pages that follow this URL pattern: /apps/categories/[categorySlug]
xx
NOTE: this “one-app integration” example shows the gmail single-app integration page, but the same view applies to all single-app integration pages that follow this URL pattern: /apps/[appSlug]/integrations
xx
NOTE: this “two-app integration” example shows gmail + slack two-app integration page, but the same view applies to all two-app integration pages that follow this URL pattern: /apps/[primaryAppSlug]/integrations/[secondaryAppSlug]
xx
NOTE: this “legacy workflow template” example shows a specific legacy workflow page, but the same view applies to all app category pages that follow this URL pattern: /apps/[primaryAppSlug]/integrations/[secondaryAppSlug]/[workflowId]/[workflowSlug]
xx
NOTE: these examples show the lead-management templates-by-use-case page and the tables templates-by-metaproduct page, but the same view applies to all templates-by-use-case and templates-by-metaproduct pages that follow this URL pattern: /templates/[useCaseSlug OR metaProductSlug]/
xx
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.