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.
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.
Pair with the PM to help them put users’ needs in context.
Help the product teams, stakeholders, and customers make sense of the seemingly conflicting priorities by leveraging user-centric, Design Thinking methodologies.
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!