Better tooling, better UX

Problem

In 2015, as Lead UI Engineer at Zazzle, I found myself having a concerning thought: "Why am I always trying to explain to Product and UX why we can't do something?". If I had to be pondering anything, I wanted to be pondering user intent, interaction design, and data flow -- not technical feasibility using old technology. It was around this time that I decided we had to upgrade our tech stack.

Actions taken

We definitely needed an upgrade, but what to choose? The first step was to examine the landscape of UI stacks, both in the present and in the anticipated future. I went to dev conferences, scoured the internet for everyone's opinion (and opinions about those opinions), and consulted my team for any experiences and preferences they had. After building a few personal pet/research projects with various frameworks, React (and TypeScript) rose to the top. I introduced React to my team, and all seemed interested. With that, we began brainstorming what a full React stack might look like at Zazzle. I divided up responsibilities (build system, i18n system, forms, etc.) to move as quickly as possible. After plenty of planning sessions, I made the case to a few key stakeholders that we needed a project to try out React. We seized an opportunity to recreate a small experience, and React passed with flying colors. The next and most important step was to get C-level buy-in to start using React going forward as a team. I started compiling a compelling presentation, complete with live examples that compared and contrasted React with our previous stack. This presentation was as much about the technology itself as it was about the business case for (and cost of) switching to a new UI framework. The presentation was a success, we built the next flagship experience on React, and now 95% of development is on the new React stack.

Lessons learned

Framing your argument in a way that your audience will appreciate is a vital skill. I had two audiences to convince: Engineering and Product. For Engineering, I showed off hot module reloading, and that's really all they needed. For Product, I argued that my proposed React stack would allow me to stop asking "how can I explain why we can't do this?" and start asking "how do we want this interaction to work?". I would be able to stop fighting my tools and start embracing them, vastly reducing the distance between what I wanted to do and how I would do it. That resonated for Product. And thus, consensus.