Designed and implemented Product Design team project process

Overview

While leading the Product Design team, I was responsible for establishing project processes for the team. After a few years of experimentation with our project process, my team was ready for a concrete and refined process for handling UX projects, especially large and complex asks.

The previous year we had established our team mission and values, as well as identifying our UX maturity level as “Structured” per the Nielsen Normal Group’s UX maturity model.

Business Problem

After retros and discussions with my team, two main areas of improvement emerged.

Large projects got bogged down and delayed due to misalignment with stakeholders on project goals. This lead to continuous rework, and frustration from the Product Design team.

Considering the overall company OKRs of improving efficiency and working more rapidly, I saw how an updated team process would align with business goals.

We made our core 2024 team OKR “Solve the right problems, faster.”

My Role

I lead retrospectives and collaborative working sessions with the Product Design team to define our OKR and process updates, and engage the team in learning and shaping the new process. I spoke with Product Managers, Engineering Managers, and executive stakeholders to make sure we addressed areas of improvement where Product Design’s work overlapped with other teams.

I refined and documented our improve project process, based on the IBM Enterprise Design Thinking framework. I accompanied this diagram with a Miro talktrack explaining how other teams would interface with the Product Design team at each stage of our process. This made it easy to share our new process with other team leads and answer initial questions.

I also followed up with team leads to discuss their feedback on the process and continued to refine our project approach with my team.

The process diagram calls out where to start the cyclical process based on how the project starts: from a feature idea, from a problem to solve, or from a place of pure exploration.

This updated process tailored our work approach to the types of projects we often found ourself faced with: large, complex issues which needed solutions sooner rather than later.

As a team, we also put emphasis on three areas of our process we wanted to strengthen:

Setting project metrics of success

This would allow us to better align with stakeholders one what the end goal of the project was – rather a focus on building a feature, we could switch to helping solve a problem. This helped ensure the design solutions we provided were providing the right functionality for the right users.

Running ‘North Star’ design sprints for feature ideas

Many of our projects to date had begun with a request to design a specific feature, that was often already well-socialized among stakeholders. Yet often these features ended up being scrapped or needing major rework after design effort had gone in and user research revealed that they were not meeting customer needs.

Running design sprints to rapidly prototype and test these feature ideas let us engage the ask to produce features, but without spending unnecessary time designing for a feature project that would ultimately be canceled.

Post-launch reporting on project success

The other side of the coin to setting project metrics of success, post-launch reporting on projects allowed us to better demonstrate our team’s value to the business, as well as providing concrete, easy-to-digest ‘scores’ for project success (you can see one such report here).