Sharing is caring!

When I first started writing this post, I focused on the output and artifacts of the last year. Then I tried to organize them into the buckets that the DesignOps community often uses to describe their work: People, Process, and Tools. It eventually dawned on me that readers should understand more of the context of why the team needed a DesignOps manager.

Read my first post on DesignOps here.

DesignOps manager for rewriting how a team works

My UX team’s beginnings are not uncommon. A company purchases one or two other companies, brings in existing product teams with their own “unique” way of doing things, and smashes them together into one team. These teams now are faced with the question, “what rules of working should we now follow?”

Things will be broken and that’s ok

The hard truth is that most of the processes that these teams used before will need tweaking if not a full revamp. It becomes everyone’s pain point and no one’s priority to identify, strategize, and roll out new processes.

DesignOps managers are a new role

In addition to my initial one-on-one with every member of the UX team, I set regular check-ins with directors in the UX organization (i.e. UX research director). One key pattern that surfaced from my conversations was that I was everyone’s first DesignOps manager.

The good news was that the team almost universally had never worked with someone who solely focused on DesignOps. This gave me a range to inquire more about where they felt the team needed help.

Most of the processes that these teams used before will need tweaking if not a full revamp

Specifics to my UX team and company

My manager, who brought me in, had a vision for the UX team to offer specialized services in addition to and to support Product Design. So, he created other teams such as UX Research, Design Systems, and Design Strategy. More people meant we needed better ways to communicate across our own teams as well as with other disciplines such as Product Management and Development.

Striving for higher levels of UX maturity

Not all UX teams have this luxury. In my case, the last two companies that I worked for had some version of an organization that prioritized hiring specialized UXers where the focus of work was elevated beyond mockups. Our goal was to bring in expertise and experience in other disciplines to offer a more nuanced approach to how our company offers and supports products and services.

More people and more complexity

If our team is growing, that means we are trying to catch up to other more established PM or DEV teams whose numbers already dwarf ours. The other reality is that if a company is willing to invest and grow a UX team, then they are most certainly doing the same with their other teams in PM, DEV, marketing, sales, and HR.

How do we work and how do we communicate?

Everyone’s interpretation of a process for setting priorities, doing work, evaluating effectiveness, and delivering work is different. Also our views of other disciplines’ roles as well as their understanding of us are not always aligned. So as a UX team, we needed to define and communicate what were the skills, expectations, processes, and artifacts that defined our practice.

DesignOps Manager and a process for how we work

DesignOps manager can help focus efforts to help unify a process between PM, DEV, and UX. Image Credit: https://craftwork.design/

Below are some of the activities that we are working to ensure consistent working processes and communication.

Agile UX basics

Product designers embed with product teams were possible. Follow the same sprint cadence and participate in Agile ceremonies where it makes sense to share information.

3-in-a-box present in key Agile ceremonies

The project leads from UX, PM, and DEV are together in as many of the Agile meetings as possible. This includes backlog grooming, sprint planning, daily standup(s), retro(s), and demo(s). If the teams are small enough, the leads should be together during key milestones and for critical decisions.

Regular stakeholder check-ins

Executive stakeholders need to see progress on the work. At the same time, the product teams need to surface the work to see if it still meets shifting company needs and priorities.

DesignOps managers can show how other UX disciplines support product work

As the UX industry matures, we start to see more specializations to help address pieces of the UX process. Our team is building out centralized teams such as Design Systems, UX Research, and Design Strategy to support Product teams. These teams are not embedded like the Product Designers. Nonetheless, they can augment the UX team’s capabilities in the following ways.

UX Research

Pair with the PM to help them put users’ needs in context.

Design Strategist

Help the product teams, stakeholders, and customers make sense of the seemingly conflicting priorities by leveraging user-centric, Design Thinking methodologies.

Design Systems

Take the boring repetitive work out of design and development. Establish a reusable and flexible design component library that makes it easier to instill consistency.

Continue to find opportunities to unify the process

Moving multiple teams from small startups to enterprise requires constant reviewing of how we work. I have regular check-ins with PMops counterparts to get a feel for what pain points they are trying to solve. That is where I connect them to one of the disciplines on the UX team to help.

One example we are working on right now is clearly defining a beta process. Beta means different things to different people. Sitting in on PMOps calls, I learned that a streamlined beta process will help with more accurate reporting. More accurate reporting will help with more accurate capacity planning. I connected UX Research and Product Designers with the PMOps team to collaborate.

Building up the UX team

As we were defining a clearer process for working, we needed to make explicit decisions on how we hire, what our standards are, and how we onboard.

Clarify the hiring process

We first decided to focus on standards that the candidates needed to meet from the perspectives of technical, collaboration, and communication. Then we created a grading rubric for the hiring committee to use.

Publish onboarding resources

Each team will onboard its new hires. To unify the key information that new hires will see first, I created an internal site to show them the following.

  • What are our mission and values
  • Who is on the team
  • How does each team operate
  • What tools we use and how to get access
  • Other key training resources
Connect with onboarding buddies

The onboarding process is a great opportunity to get the whole team involved with welcoming and supporting a new team member. One particular part of the process that can help encourage more one-on-one interaction is an onboarding buddy program.

The key lesson that I learned was to pair people within the same (ish) time zone. Also, make sure that the onboarding buddy has the same or a little more experience than the new hire. This ensures the onboarding buddy will be able to foresee most of the questions from the new hire.
Check out this post to read more about all of the work that goes into a structured onboarding program.

Big lessons learned

Have a vision

I was grateful that the UX leadership had a vision for how the team needed to operate. So, the steps we took with processes and tools were proactive. We did not know exactly what changes we needed to make or how we would implement them. Nonetheless, we had a direction and a path.

Use processes and documentation judiciously

When a team grows, it requires coordination and planning. The team should feel at ease that there are things such as onboarding and tool acquisition figured out. Systems help people not spend time on boring stuff.

Our managers and directors are thankfully sensitive to documentation and meetings. When we moved to adopt agile practices, it introduced a host of new behaviors and meeting requirements (I.e. standup, sprint planning, backlog grooming, demos, etc.). The team saw the benefit for communication. They struggled with the extra work and time commitment. Some things are a given in enterprise UX teams. However, there is always room to cut out needless administrative work.

Sign Up Today

Get insights and resources in your inbox before I publish them!

Matt Eng

Matt Eng

DesignOps Manager. Based in Austin,TX. Worked with clients such as Alcatel-Lucent, Ogilvy, RBC, Deloitte, Whirlpool, Polycom, Symantec, and Pebble. Matt teaches, mentors, and speaks about design, creativity, and fostering stronger connections within teams.