Google Store had outgrown its bootstrapped CMS. The system was buckling under years of hacks and patches. Updating the site took a huge amount of repetitive, manual work, and required a large team of contractors to handle it. The stress and the tedium of this job caused data errors, frequent team attrition, and worst of all, leaks (in 2021, we accidentally leaked images of the Pixel 4a prior to debut, and it was quickly picked up by 9to5Google and Android Police).

In the brainstorming phase, we identified two sets of users, and invited them to solution with us. Our first cohort was direct users, i.e. the operations team. We conducted a design thinking workshop that had small groups sketch out a metaphorical illustration of what an ideal, next-gen CMS would be able to do. Their feedback became valuable input for the Catalog portion of our project.

Our second cohort was indirect users, i.e. our marketing partners. Though our creative team does not operate the CMS, they are the ones building the creative templates and pages; thus it was important to get their take on what kinds of pages GCMS needed to power. I gathered their input, and built a mid-fidelity "mock" of what a futuristic GStore site could look like, to get their input and alignment. Their feedback was critical for the Merchandising portion of our project.

Through my research, it became clear that the operations team needed more granular control over their data, and more change visibility to ensure their editing accuracy. I became inspired by the robust tracking and management tools for software development, such as SVN and GitHub. Source code repositories have already solved many complex data management problems, and successfully scaled them for exponentially more users than GCMS needed.

Leveraging concepts from their basic principles, I proposed a CMS framework that

(1) Broke down page level saving to field level saving
(2) Introduced a structured, attribute-driven product catalog hierarchy
(3) Passed all data through a release checkpoint to ensure two sets of eyes on every update

My proposal for an “internal CMS that leveraged source control” garnered considerable interest in executive stakeholder reviews, and was greenlit for implementation.

I planned and executed all core features needed to view/edit/manage CMS data. When combined and used together, the following features allow operators to orchestrate accurate, sweeping changes with precision, even in highly unpredictable launch seasons:

GStore maintains a large amount of products that have attribute variations. For example, the Pixel 4a has several colors, HD sizes, screen sizes, and carriers - Selling a Pixel 4a requires 64 product “permutations” in the catalog, each with its own SKU. Previously, all this data was manually updated - leading to frequent mistakes with severe effects downstream.

To ensure we always sold, shipped, and activated the exact phone purchased by the customer, we launched two powerful attribute features:

Product Wizard. Instead of 64 copy-pastes, operators could now create the Pixel phone in the catalog by simply stating its attributes. The wizard automatically generated all product permutations, and saved the data as a release.

Bulk Edit. Lots can change about a product pre-launch (e.g. colors added, dropped, storage capacity increased, decreased, etc.) Every time this happened, operators had to manually track and edit these changes. To mitigate this, I launched Bulk Edit, allowing operators to display tables of attributes across multiple products. These dynamic tables provided Excel-like edit functionality. After launch, changing 48 phone permutations of “Fire-red” to “Marvelously maroon” could be done in seconds!

I designed GCMS with 5+ year scalability in mind. When it came time to overhaul the merchandising portion, our work was significantly easier, because (1) our features were already compatible with release management, and (2) we were simply taking our own design system and extending it to more use cases.

Similar to Product Catalog, I established a clear hierarchy and taxonomy for all GCMS-powered web pages. At the molecular level, we had module “instances.” Instances were based on page templates provided by our frontend team. Every instance was carefully tracked from a central location in GCMS. Different combinations of module instances could be used to build different versions of pages.

Different pages and modules could also be organized into “regions.” It’s essential for a global e-commerce platform to allow regional teams the autonomy to customize their pages per local cultural and language patterns. Page region control allowed global teams to adopt US templates, but quickly customize them to their specific needs.

No matter how good the system is, it will fail without the buy-in and blessing of the user. So, as the team readied for launch and rollout, I pivoted to “landing” the GCMS project.

I launched an operator educational program called “Teach the Teacher.” This included video demos of CUJS (critical user journeys), performed in a fully functional staging environment. This resource empowered global operations leads to be able to teach and onboard their own teams with confidence, and greatly increased their excitement during the large transition.

To prepare the rest of the org for GCMS launch, I initiated several roadshows - a detailed dive for product managers, and a more general one for executive leadership - to demystify the upcoming changes.

This deck served as an introduction and “how to” operations manual, but also evangelized the importance of continued feature improvements, and measuring and monitoring the health of GCMS over time.

This deck inherited the nickname “GCMS 101” and was passed around the org extensively - I’m still granting doc view permissions, over a year after launch!

To ensure that any team was able to monitor GCMS's system health and user satisfaction, I worked with our UX research team to set up a bi-annual "baseline" study. In this study, operators of varying tenure/seniority are asked to perform key user journeys. Time on task, satisfaction score, and task success is measured, anonymized, and reported to the working team.

This longitudinal approach to overall platform health was another key factor in landing the project successfully. In its first baseline, operator success and happiness wasn't showing as large an increase as we had anticipated. Simultaneously, engineering leadership and ownership was being transferred to Bangalore post-launch, and many of the engineers there wanted to work on new features instead of improving old ones. Thanks to the baseline study, I was able to make a case for finishing and launching several MVP+ features, as the baseline study made it apparent that operators found the MVP versions difficult to use/understand.

By the end of the project, I was supporting 40+ engineers and 2 PMs across two countries, and peer-leading a UX team of 3. Post-launch, I reduced operational expenses by executing a smooth UX handoff to a cross-functional team in Bangalore.

The new release system meant operators could now deprecate their manual release spreadsheets, mitigating a major cause of site leaks. After the full migration from the old CMS to GCMS, catastrophic site leaks were reduced from multiples per year, to ZERO!

I codified all my GCMS design work into a design system. Based off Google Material 2, but suited for dense, enterprise-style information architecture, this library of patterns continues to guide GCMS design contributors today.

In Q3 2021, Google Store leadership created quarterly “GStore Ownership” Awards to reward exceptional achievements. I was the very first UX recipient, receiving the award for “landing” GCMS by always fixing the underlying problem.

I consolidated recollections and examples of my cross-functional work in a 45 minute UX talk called “Yes to UX." In it, I discuss how to work most effectively with cross-functional partners, i.e. how to get them to say “yes, I agree” - but also how to assess and regroup when they don’t. I have given this talk internally to audiences of 200+ Google UXers.