Researchers Managing Designers, Part 2: Insights on UX Design Management
By: Workday Design
Tags: Design, Ux Researcher, Design Manager, Women In Tech, Design Management

After I completed my transition from individual contributor to manager and officially shed my researcher identity (read: accepted my fate), it was time to really roll up my sleeves and focus on how to begin climbing the enormous mountain of managing the design team in front of me.

My approach for managing a design team has shifted from when I first entered into UX design management. When I was first getting my bearings, it was all about figuring out what work needed to be done, and the timelines and scope of work were largely provided by product management. I could coordinate timelines and deliverables all day long, but it took me some time to realize that managing a design team was not just about pushing the work. It was also about managing the quality of it. More than that, it was about what didn’t get into the product rather than about what did. So what do design managers do and what have I learned about how to be a good design manager?

Provide Structure & Prioritization

A large part of my role centers around providing structure and prioritization for my team’s work in order to enable the designers to focus on the actual design work. One of the ways in which I go about structuring and prioritizing the work is to meet with the Product Management leaders in our product space and plan out what will be worked on in the next 1 to 2 releases and assessing priorities both from the product management and design sides. Eliminating this task for designers helps them free up time so that they have more time to contribute to the design solution instead of spending time in the weeds of project planning. By doing this legwork for the team, I can give them a set of clear priorities for what to work on and help them start with enough information (such as product owner, targeted release, and a high-level description of work) to be able to kick off new projects.

Remove Roadblocks

My job is to make my team successful. To do that, I remove roadblocks for them. I spend a lot of time managing relationships with our stakeholders, which is helpful when more challenging conversations need to be had. For example, if research reveals that we are not delivering value with a proposed new feature and therefore we think we should pump the brakes, or if the team is having difficulty working with a stakeholder. These are potential blockers for my team and I support them by being the one to engage in these conversations with stakeholders so that they can continue working. I like to tell my team to think of me as an umbrella that is here to keep them dry.

Drive a Shared Understanding

Also within my realm of responsibilities is driving a shared understanding of UX. UX teams are well equipped to both create and share knowledge about our users. Armed with deep domain expertise and skilled in the art of studying our users, the design team is well positioned to understand the people that use our products. In order to create a shared understanding among ourselves and our stakeholders or product teams, it is important to engage with them throughout the design process in an effort to demonstrate the value of UX. It is my responsibility to make sure that our stakeholders understand how to best work with design and that they see us as experts for them to leverage.

Manage Quality

We all want to deliver a great experience to the user. However, inevitably things happen that get in the way of that — features are added to MVP, development scope gets cut, timelines get pushed up, or maybe someone is just not bringing their A game. It’s my role as a design leader to be able to push back when the team feels that the design is not up to par given the constraints.

Likewise, my role includes challenging my designers to produce quality designs. I encourage my team to take a thoughtful and holistic approach to their design work and make sure they have the time and space to do so. Sometimes, this means pointing out to my team when this is not happening and helping them course correct. (More on this in Part 3 of this series, Career Growth: Your Team’s and Your Own).

Provide Feedback on Design Work

The importance of design management in my mind (and management in general) is realizing that, in your role, you have the privilege of helping others grow in their career. During the time I have spent with my team to date, it has been an absolute joy to watch them develop in front of me. An important part of encouraging your team’s development is providing feedback, including feedback on areas they need to work on. Giving critical feedback can be hard, but at the end of the day, sugar-coating feedback does nothing to help a designer grow or a product succeed. Because feedback is so important, I’ve explored what makes for effective feedback with my team.

Within Workday’s UX org, we have other members of the leadership team who have gone through career transitions similar to mine: from UX Research to design team management. I remember asking one of them how they went about providing feedback on their designers’ work. Their advice was leading with questions. Questions?!! Researchers love questions! It was then that I realized that my approach for providing feedback on designs didn’t need to dramatically shift from how I would provide feedback as a researcher when working with designers.

I like to think of the way that I work with designers as a form of pair design. I’ve always liked the metaphor of pilots and navigators, as explained in “Pairaphors: Explaining Pair Design (Metaphorically).” Think Han Solo and Chewbacca, where the designer is the pilot, fearlessly flying the ship, and the researcher is the navigator, making sure they stay on track and avoid pitfalls. As a researcher, I was naturally full of questions and constantly asking myself and the designers if specific elements of the design would be understood by our users, as well as finding ways to make sure we focused on those areas during our research so that we could see if we were off course.

Just like in research, providing good feedback as a design manager is about asking the right questions. This translates to making sure that questions are grounded in the objective of the design. What elements of the design are related to the objective? Are those elements effective in achieving the objective? Why or why not?

Another tactic that is beneficial, and that very much mirrors the methods used by a UX Researcher, is leading with questions. For example, In Discussing Design, Connor and Irizarry ask questions about the objectives of designs, why designers chose certain approaches, and the constraints that affected their choices. This not only helps me get more information to base my feedback on, but it can also help designers to feel more comfortable talking about their thought process and design decisions. Win win!

I’ve also encouraged my team to seek feedback on their designs early and often (more on this later). I want to make sure they are well equipped with the resources to collect the feedback that they need and to take advantage of the many avenues in which they have to do so. A few of these are:

Asking for peer-to-peer feedback from designers outside of the team. By including designers who have not been working heads down on the design, my designers get the advantage of a fresh perspective from people that will approach a problem from potentially different angles. Doing so helps designers talk through their design decisions and help assess how well those decisions are tracking against their goals. It also gives designers time to practice critique; both in terms of helping them become comfortable having someone critique their work as well as critiquing someone else’s. Presenting work during our weekly show-and-tell that is open to the broader design team (our version of a design critique with a more casual name). While similar to asking for peer feedback, this forum in particular brings together designers from across product areas. In this setting, designers can solicit feedback from a number of designers at one time. Putting designs up on the wall in our design space with a pen and sticky notes to welcome feedback. Including a scenario along with the design helps those leaving feedback measure the design against its intended objectives. Getting design work up in shared spaces also helps to increase transparency and visibility into the design process with those both inside and outside of the design org. And, of course, gathering feedback through user research. I’m a big fan of hallway testing (when appropriate) and have encouraged the designers on my team to utilize the method in order to solicit quick feedback on their designs.

Frequency of Feedback

While there are many different opportunities and forums for designers to seek feedback and receive critique on their designs, another important factor to be mindful of is when and how often that feedback should be happening. Asking for feedback too early when a designer is still noodling on how to make sense of the problem at hand can actually become troublesome if they aren’t able to clearly communicate the design problem to others. Once the designer has established this understanding, it is safe to begin seeking feedback. When exactly the designer reaches this point will vary based on both the individual and the challenge before them.

The more design iterations and UX research a designer is able to do during a product’s life cycle, the more certain they can be that the design is meeting its objective. However, there also comes a point when it is time to stop iterating on the design so that it can find its way into the hands of developers and come to life. Getting feedback too close to this date can be equally detrimental if it is too late for the designer to be able to act on any of the feedback.

Although I mentioned that designers should seek feedback on their work often, there is such a thing as too much critique. While there is no magic number as to the number of critique sessions that should be happening, there are a few things to look out for, such as progress stalling because the evolution between each iteration is small or because critiques begin to go in circles.

At the end of the day, needs will vary by project and team so find what works best for your team. However, what’s worked well for my team are weekly deep dives (with our immediate team) into our current projects and weekly syncs with our product teams (design, research, product management, and development). Additional ad hoc meetings can always be scheduled; however, as a good rule of thumb, it’s important to formally sync up at least once a week with stakeholders. Best practice is to really be in contact daily over Slack (or be co-located if you are able to do so) to tackle questions and issues as they arise so that work can continue to move forward.

From providing structure and prioritization to providing feedback, the one area that I have grown in the most is becoming comfortable with my team operating more independently. From where I started on this journey as a first time manager to now, my team and I have grown into a stage where I can have a more hands-off approach, waiting in the wings to help them as needed.

In Summary

While I still have a long climb ahead of me, it’s important to look back and reflect upon the progress that I have made so far in UX design management. If I think back to when I started this blog post (about 6 months ago), I’ve grown during that time. As much as this post has been about sharing my experiences with others in an effort to support those who are on a similar journey, it has also served as a great source of reflection. As one of my team members told me, “If you’re not having an identity crisis, are you even writing a blog post?” This statement could not be more true. Stay tuned for Part 3 of this series where I will talk about handling career growth — your team’s and your own.