Creating a product design process

How we utilize our team’s full toolset to build better, together

A process helps teams operate efficiently and yield consistent results. It plays an important part in unifying expectations and approaching problems holistically. This is a look into the process we utilize as product designers at ServiceTitan and how we got here.

We made it work

2016 — We were a team of four designers and fifteen product managers. We had a young design culture and were racing towards building new features in an effort to appeal to a larger customer base. Each team was creating their own approach to product development. Ultimately our customer base grew, along with our technical debt and inconsistencies in the experience. 😓

It’s not you, it’s the fact that we don’t have a process

2018 — We are now a solid design team of ten, catering to multiple modules across the product. We design with purpose and create efficient workflows for our users. Scaling without a process in place was painful. We needed to do the following to set ourselves up for success:

  1. Formalize a process that outlined each phase of product design so all team members knew what to expect and how to best contribute.
  2. Create a design system.
Our Design Process
We need to make sure we’re solving the right problem and not a symptom.

Phases of our process

We started by listing what we felt were relevant steps in our product development cycle. We defined what each phase consisted of and had a couple teams adopt it. We found that teams were starting with a problem and not validating it properly. This led us to solving the wrong problem and uncovering that it was the wrong problem too late; this caused rework for designers and delayed release dates. We learned that we needed to reframe the problem we were solving based on insights we gathered. We also initially combined Design I and Design II but later realized that refining UI and incorporating key components into our Design System should be a separate phase.

Through trial and error, we landed on these six phases:

  1. Discovery. What’s the problem? Let’s look at some metrics, talk with users, and see how they are working around what exists today.
  2. Reframe. Conduct user interviews to validate that we are solving the right problem and not a symptom. Create user stories, task flows, and a competitive analysis. View what our findings are as a broader team and see if there are any gaps or things we need to consider.
  3. Design I. Wireframe your heart out. This is the time to iterate, test, and see if we uncover new user needs.
  4. Design II. Basically our bread and butter. Develop production-ready mocks that utilize our design system.
  5. Deliver. Refine interactions and provide additional output if needed.
  6. Support. Align with quality assurance engineers around expected functionality and UI elements.

Getting everyone onboard

It wasn’t easy…changing how a product organization functions takes time. Here’s a few strategies that helped us move things along:

  1. Demonstrate. It was important to show that what we’re proposing works and that it’s ultimately going to make the product better. We had a couple teams implement this process and found that it gave them a better understanding of our users’ needs. The teams were also more agile and aligned around success metrics.
  2. Reinforce. We printed this process and displayed it throughout the office. Having something tangible that we could reference helped remind teammates that we had a process and the impact we could make when we utilized it.
  3. Engage. Getting feedback on what does and doesn’t work is important. We wanted broader teams to embrace our process and know that it’s an evolving artifact that is meant to cater to us.

What we‘ve learned

This process has set larger initiatives up for success. We found that it needs to account for smaller and more urgent features. We’re currently working on outlining feature types and the approach we need to take for each one.