The Experiment was a product designed to address changes that came from the switch to WFH, establishing a new interaction paradigm in a space dominated by massively popular tools. I was brought on to advance the Experiment from a demo to a beta version for testing. Collaborating closely with developers, I steered our work towards a minimum viable product, ideating features as we progressed.

During development, I noticed previous design decisions (from the demo) that restricted use cases and limited total active users. Recognizing the impact on potential growth and future 'design debt,' I spearheaded the vision of a new iteration that expanded use cases, simplified UX, and leveraged the existing front end. During pitch, we aligned our concept to Google’s broader company-wide objectives to help its reception.

This team faced three main issues that added significant complexity: trust, resourcing, and tech debt. Leadership was skeptical about the product’s viability, necessitating they produce a quick win to demonstrate potential. Additionally, the code structure and API were cumbersome for developers, slowing progress. To address that, the team created another production build, which introduced a clunky ‘two product’ experience that had eroded leadership’s trust in the team. They needed a quick, visible win to restore trust, but core problems were in the back-end (i.e. not easily viewed or quickly fixed).

To tackle these challenges within our timeline, I first collaborated closely with developers to understand the issues. After numerous technical discussions to dissect back-end complexities, we aligned on a strategy that nested the two interfaces with iFrames, and masked the stitch with shared UI elements and entry points. The Quick Fix made it appear as a single, unified experience, despite being two production builds under the hood. This ‘UX theater’ solution allowed us to deliver new features quickly without growing our tech debt, though it didn’t solve the underlying issues.

The Quick Fix was a resounding success, awarding us the credibility needed to increase funding and buy time to find a sustainable long-term solution.

Senior leadership requested a tool with specific needs, involving visualizing lots of datapoints from across the company. Since the user base of this product consisted of a small group of senior leadership, feedback cycles were quick but also highly critical, necessitating that any demo presented was of the highest quality.

We were developing features based on these stakeholders’ requests, which (in this case) meant our feature priorities were decided spontaneously. This lead to a feeling amongst the team of a lack of direction. To address this, I organized a workshop to clarify our Critical User Journeys (CUJs). We discussed leadership’s overall goals, the real-life process to achieve these goals, how our product fit into the process, and technical limitations – identifying low-hanging fruit, easy wins, and big bets.

The workshop produced concrete artifacts that helped the team develop a clear roadmap and justify their decisions to leadership, increasing trust and ensuring alignment with leadership's objectives.