"A jack of all trades is a master of none, but oftentimes better than a master of one."

It wasn’t until last month that I came across the second part of this phrase.¹ However, to me, the first part alone had never made sense.

I am pursuing a Master’s degree in Integrated Innovation for Products and Services (MIIPS) at Carnegie Mellon University. The program “unites the disciplines of design, business, and engineering to build impactful solutions with real value.” When looking at my resume, people usually get confused. I have previously interned in business/operations, engineering/research, and design roles. So what am I (a transdisciplinary innovator?), and where do I fit? Design Operations (or DesignOps) might be one of the answers to the second question.

DesignOps

What is DesignOps? According to the Nielsen Norman Group, DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.²

At Intuit, like many other places, the definition is still evolving — it is sometimes called the creative oxygen to amplify design’s value and impact at scale. The purpose is to unlock innovation, customer engagement, and productivity through consistent, adaptable frameworks.

With Design being embedded in the production cycle due to the emergence of design thinking and its impact on business performance, over time, design units have become organizations within the organization. The need to harmonize design workflows and coordinate efforts and processes has led to the demand for new competencies to help the organization to manage the complexity of their design resources. As a result, many companies are introducing DesignOps as a function.³

Superside quotes Brennan Hartich, a former DesignOps leader at Intuit, “Adding a DesignOps headcount was even more important than adding another designer.”

My understanding of DesignOps and the role of Design Program Managers (DPMs) is that they are advocates for Design and designers. They help teams elevate their craft, champion scalable processes, create frameworks, solve problems, improve efficiency, and foster an environment of belonging.

Design Program Manager Intern at Intuit

I was the first DPM Intern at Intuit, with Bernice Lee, the Head of DesignOps for QuickBooks — as my manager, and Chris Bush, Director of Experience Design — as my Design Leader. When I came across the internship posting, I had not heard about the craft. But as I started to do some research, I was intrigued. During the interview process, I realized that the role aligned with what I was looking to do, and thanks to MIIPS, and my previous mix of internships, I had the tools in my toolkit that made me a good fit. Most DPMs have a few years of work experience in various roles before they make this career shift. I saw this as an excellent opportunity to learn.

There were twelve full-time DPMs on my team. I was embedded in a design team as it was expanding and did not have an assigned DPM.

“We are a catalyst for the design function. Our key strengths are in identifying those areas of opportunities that exist to help our designers scale and to help facilitate the design process. It could be as small of a task as defining what a tool should be, or as broad as leading sprints for our design teams to be able to really hone in on what the customer problem is.” — Bernice Lee, Head of DesignOps, QuickBooks⁴

At the start of my internship, my scope of responsibility was defined as follows:

• bring your POV and contribute to the DesignOps craft

• define a framework to create visibility for Fiscal Year 2023 work-streams to track key milestones, checkpoints in alignment with Product Managers and Product Development (Engineering)

• team op-mech audit and recommendations

• provide a framework for the team to document and publish work

These responsibilities were intertwined, and I was given the space to explore, redefine, and expand on the initial objectives.

Project

I followed Intuit’s recipe of Going Broad to Go Narrow

Discovering the problem
The product team housed multiple mission teams, each functioning well but in silos. There was potential to improve end-to-end visibility and knowledge sharing. Each mission team carried out its research, created design files, and once a project was shipped, they would move on to the next. Not everyone was documenting their research findings or cataloging their files so that they would be available to people outside the team. For a design leader or someone new on the team to get an asynchronous overview required finding and going through multiple files and then contacting the relevant people to get questions answered.

Thus, my objective was to overcome communication gaps, and provide a medium for documentation and visibility into work that was in-progress or shipped.

Documenting the conversations, breaking them down for affinity clustering, and identifying the themes

Exploring the solution
There were two parts to the solution — a set of operating-mechanism (op-mech) recommendations for the cross-geo team and creating a team hub to serve as the single source of truth. Coda, an all-in-one doc for teams, was the available tool of choice for building the wiki/hub for the team. I had used Notion, which is similar to Coda, for note-taking — but had never really exploited the full power of these relatively new tools. I started ideating, going through use-cases and documentation, and then creating small frameworks to test.

Refining the experience — Build
I started by building a master database for all the projects and tasks, linking it to “member cards,” which served as the connectors for all the tables, putting the team members at the center of this wiki. It was a constant challenge to avoid turning this database into a monster with dozens of columns and dropdown values to cater to everyone’s needs. The solution was to create child-views of this table for each mission team in their own small workspace within the wiki. These child views only displayed the columns they wanted to utilize and filtered out the content and dropdown options.

The Team Hub and Member Cards in Coda

Another priority for me from the start was ensuring that whatever I built was well documented, convenient to maintain, difficult to break, and easy to update. For this, I created a self-serve admin panel to add new dropdown values and locked the master tables to prevent accidental deletions and changes of columns. I also made a detailed help section that covered everything from the basics of Coda to detailed descriptions of all the fields in each table of the wiki.

Refining the experience — Release
About halfway through my internship, when I shared my progress with the DesignOps team —I was overwhelmed by the positive response. Many DPMs expressed interest in using the frameworks I had created and repurposing them for their teams. That’s when the idea of creating templates came about. I made a simplified version of the wiki and broke it down into templates such as sticky notes and a meetings hub. We published these templates within Coda, and they are available to everyone at Intuit.

“Yash went above and beyond my expectations to create and deliver a scalable and easy to use design-ops framework, in Coda, for his team. His work has gained the attention of the Design Program Manager community across the organization and they are starting to use his framework to automate and simplify processes across their teams.” — Sonu Macwan, Principal DPM

Coda templates published for use across Intuit

To drive adoption within my product team, I hosted sessions and did a share out. Before these sessions, I asked everyone to fill out a brief survey with the intent that it could be re-sent a few weeks later to gauge performance on a few metrics that I had defined.

Results of the survey sent before the implementation of my project

After my internship, the other DPMs will help drive adoption, not just for my team, but they have also started using the templates and frameworks within their teams to add to their existing files and build out new wikis.

Project timeline

Wrapping Up

I was fortunate to get the opportunity to attend the DesignOps offsite in San Francisco. It was a day filled with fun activities and meeting the people I had seen on Zoom for the past two months. I spent the rest of the week working from Intuit’s Mountain View headquarters.

The Intuit DesignOps offsite

Near the end of my internship, I presented my project in Design Rumble — a weekly session for designers to share their work with others from across the company.

It was a fun summer, learning a lot from this incredibly talented and equally crazy team that is so passionate about their craft. Before the start of my internship, I did not have clear expectations and had this vague idea of DesignOps based on what I had read online. Reflecting, I realize that the craft is rapidly evolving, and the team at Intuit continues to iterate on its purpose statement. What sets the DesignOps team apart is the diversity in experience, background, education, and skills. No two DPMs are doing the same tasks, and each has taken on different challenges and responsibilities. However, the commonality is the willingness to learn from peers, inside and outside their company, being receptive to new ideas, embracing change, and constantly going the extra mile to advocate for and get things done for their design teams.

As a new entrant, I see the value that DesignOps brings to Design, not just in a practical and business sense, but on a cultural level. It is indispensable in design-centered organizations, and I am excited to see the craft mature and grow.

[1] Jodie Cook. (May 13, 2021). Why Being A Jack Of All Trades Is Essential For Success
[2] Kate Kaplan. (Jul 21, 2019). DesignOps 101
[3] Patrizia Bertini. (Jan 22, 2021). Understanding DesignOps as a Strategic Function
[4] Digital Bulletin. (Jul 29, 2021). Bringing delight to design