How to Best Work with Product Designers as a Product Manager

Last updated: 2024-04-16

Problem Statement

To enable Product Designers to design delightful user experiences that sustain the business, Product Managers (PMs) must

• Possess a nuanced understanding of Product Design disciplines
• Provide clarity to Product Designers on the problems to solve and any constraints
• Act as a co-creation partner by giving helpful & open-ended feedback, encouragement, and support

In this article I provide guidance on these areas so that PMs can effectively collaborate with and empower their Product Designers.

Before we can have a meaningful conversation about how to work with Product Designers, we first have to level set on what they do. If you’re already knowledgeable about Product Design disciplines, feel free to skip ahead to the tips & advice.

What Product Designers Do

Product Designers integrate multiple design disciplines, including:

1. Information Architecture (IA)
2. Interaction Design (ID)
3. Content Strategy (CS)
4. Visual Design (VD)

These disciplines are intentionally listed with IA first and VD last. We’ll unpack each discipline in detail.

“Product Design” has become an increasingly popular term in recent years, but before that UI Design, UX Design, and CX Design — i.e. User Interface Design, User Experience Design, and Customer Experience Design — were more commonly used. We’ll talk about the distinctions between UX and UI later. My gut feeling is with the growing emphasis on the word “product” that “Product Design” will continue to gain prominence.

Analogy: Designing and Building a House

Analogies are a powerful tool for helping people grasp a concept by relating it to something they’re familiar with. So before we dive into the Product Design disciplines, let’s start with an analogy.

In the case of Product Design, a great analogy is designing and building a house. This entails the follow steps:

0. Defining the context (i.e. the problem space): who’s going to live there, what are their needs, where is the house is located (city, suburbs, or country), what’s the climate (hot vs cold, wet vs dry, seasonality, etc), etc
1. Defining the architecture: how many floors and rooms, what is the layout, how are they connected, what are the systems for electrical, plumbing, gas, heating, cooling, etc  
2. Defining the exterior & interior design: what is the external style (contemporary, modern, rustic, Victorian, etc), what is style for each room (paint color / wallpaper, flooring, furnishings, etc)

The order of these steps is 100% intentional. It’s useless to define the architecture without having the context defined. It’s likewise useless to design the exterior & interior until you know the architecture. Construction follows the same order. You build the home by laying the foundation and bones. Then you add the walls & floors. Then you paint and add the furnishings last.

A Product Designer also builds prototypes in the same order. Doing it in a different order is often suboptimal.

Information Architecture / Interaction Design

These two disciplines are tightly integrated. Once a user problem has been clearly framed, i.e. what problem are we solving and what are the constraints, a Product Designer typically starts with defining the IA / ID.

IA / ID define multiple facets of the experience, including

• What is the structure and hierarchy (often expressed as maps)
• What are the navigation systems and elements
• What is the flow
• What are the interaction patterns (e.g. CTAs / buttons, grippers, carousels, etc)
• What affordances do we provide for accessibility (e.g. keyboard-only interactions for computers, minimum touch target size on mobile)
• What are the standards & guidelines

Going back to our house analogy, the IA / ID defines the layout, how to get to different floors (e.g. elevator, stairs, ramp), what are the entrances between rooms (open entry, door, etc), etc. An example of an accessibility affordance is a ramp to the front door for low-mobility users.

IA is often expressed with wireframes and site maps. These convey structure, navigation, and flow without the skin. The skin is the visual design, and it typically requires the most effort to change. ID is often most effectively expressed with interactive prototypes, especially so you can see the tap & swipe interactions and appropriate use of animation to pull focus.

Content Strategy

CS defines multiple facets of the content, including

• What is the taxonomy / nomenclature
• What are the goals for the content & who are the audience(s)
• What is the voice / tone
• What is the actual content on a given screen or page (i.e. words, images, etc)
• What is the content lifecycle & governance: who reviews / approves, where does it live, how is it updated, how long does it live
• How do we communicate success or failure in task flows with content
• What affordances do we provide for accessibility (e.g. for assistive technology such screen readers)
• What are the standards & guidelines

CS heavily influences SEO, so we need to make sure that is factored into how content is structured and expressed.

CS and IA are intertwined — both define structure, therefore they should complement one another. Research exercises with users such as card sorting should inform both disciplines.

Visual Design

VD covers all aspects of the visual expression, including

• What is the color palette
• What is the typography: fonts, usage
• What is the visual representation of various components and systems (e.g. navigation, bottom bar, CTAs, header / footer, etc) and their specs (e.g. redline, etc)
• What is the photography, illustration, and iconography
• How do we signal possible interactions (e.g. drag & drop, pills for filtering, expressing CTAs with rounded corners so they look like a button, etc)
• How do we communicate success or failure in task flows with visual treatments
• What affordances do we provide for accessibility (e.g. color contrast ratios such as WCAG 2.0’s 4.5:1 between fonts and background colors for low-vision users)
• What are the standards & guidelines

VD is often what non-designers think of when they think of design. This is often a source of irritation for Product Designers — more on that soon.

Accessibility

I mentioned considerations for accessibility (aka a11y) for each discipline.

It is imperative that accessibility considerations are factored into the design from the get-go, not as an afterthought. Accessibility must be a “comes with” feature, not a “fast follow” feature. Not only is this the right thing to do for users, it protects your company — think of the implications and risks for failure to comply with regulatory requirements such as ADA (Americans with Disabilities Act).

In addition, it is far more difficult and expensive to bolt on accessibility later to a design, and that is even more true for code. Do it right the first time.

Tips on Collaborating with Product Designers

Now that we’ve level set on the disciplines, let’s talk about how you can foster the right environment for your Product Designer to flourish.

Tip #1: Frame the user problem with clarity

All design is rooted in the problem it’s solving. Make sure to communicate any constraints due to technology, business strategy & operations, compliance, etc. Prioritize the problem spaces and features that the team and Product Designer are digging into. It’s totally fine to collaborate on defining these. PMs sometimes think they have to unilaterally decide everything, but you should encourage and welcome input from the Product Designer and rest of the team.

If the user problem is not well understood, your first task is to get that sorted and to protect the Product Designer from pressure by well-intentioned stakeholders who want the Product Designer to just dive into designing the solution. It’s an enormous waste of time, like asking someone to cook you a meal with zero guidance on your food preferences, or trying to throw a party for a stranger. Context matters!

It’s helpful if you can provide the Product Designer with key scenarios / use cases that resonate with stakeholders to bake into the prototype.

Tip #2: Provide open-ended feedback, not prescriptive feedback

Many PMs and reviewers give overly prescriptive feedback to the Product Designer. That is, they tell the Product Designer exactly how to design the solution. This is nonsensical, as the Product Designer typically has the deepest skills in design, is the most informed on current and emerging design trends and patterns, and collaborates with their peers across a company to ensure cohesion of experiences.

Everyone dislikes prescriptive feedback, regardless of role. Being told not just what to do but also how to do it is often unhelpfully limiting and crosses the line into micromanagement. If you do this, your Product Designers will dread working with you.

Open-ended feedback on the other hand focuses on the problem to be solved and challenges the Product Designer to think through options. Ask probing questions. It’s totally appropriate to tell them when their proposed designs are missing the mark, just make sure to explain why and let them mull over potential solutions. Most Product Designers welcome feedback from their PM partner — it just needs to be delivered thoughtfully. The more proficient you get at delivering feedback in helpful, constructive, open-ended ways, the smoother you’ll riff off one another.

Tip #3: When giving feedback, focus on IA / ID first, then VD

I can quickly assess the level of sophistication of a given non-Product Designer partner based on the questions and feedback they provide on a prototype. Folks with a lesser level of design sophistication often over-index on the VD:

I don’t like that color, can we change it to X?

I don’t like that image, can we change it to Y?

I don’t like the shape of that button, can we…

Comments like these can be tiresome for Product Designers, because VD concerns such as color palette and imagery are governed by well-defined brand standards that the Product Designer is maintaining alignment with. It’s not that such feedback isn’t useful, it’s that there are other first-order concerns that should be addressed first.

Therefore, make sure to give feedback on IA / ID systems first. It’s OK to give feedback on VD too, but if you focus on that to the neglect of getting the IA / ID right, you’re focusing on the wrong things and signaling to your Product Designer that you lack design sophistication.

As with the house analogy, get the architecture right first, then you can dive into the weeds of exterior & interior design. If you haven’t even aligned on how many floors & rooms there are, how they’re laid out, how big they are, what purpose each serves, etc, why are you wasting valuable time diving into the exterior & interior design? The latter things totally depend on the former.

To give another analogy, it’s like picking the garnishing for the main course for dinner before you’ve decided what the menu is. Figure out the menu first, then select the garnishing accordingly.

There are times when comps / mockups are needed as illustrative examples early in the prototyping process to help stakeholders get it, but these should be regarded as preliminary until the Product Designer has time to dive into the VD systems. For that reason, Product Designers often plaster “FPO” on illustrative images / image boxes and “lorem ipsum” copy as placeholders in low-fi (fidelity) prototypes.

It’s also noting that some Product Designers are comfortable with creating medium-to-high fidelity mockups early in the process when using modern design tools such as Figma. This is really the preference of the Product Designer. If they prefer sticking with low-fi early in the design process, roll with that. It often helps focus attention on the areas that need to be sorted out first and avoid expensive re-work.

Tip #4: Have your Product Designer’s back during design reviews with stakeholders

Some Product Designers can deftly navigate feedback from stakeholders in real-time, but it’s way easier if the PM actively supports the Product Designer to make sure sessions is productive and focused. As a Product Leader, I believe it’s my responsibility to provide air cover and crowd control for my Product Designers in design reviews, as these can get rather intense with passionate stakeholders. Don’t leave your Product Designers out to dry.

There are many ways you can do this as the PM:

• Before the meeting, make sure to prep with the Product Designer. Have them walk you through the prototype, so you can provide feedback on refining it. Let them know who the stakeholders are, the things they care about, and questions they’ll likely ask. I also let the Product Designer know which questions I may ask them in the meeting. I learned this technique from a talented sales guy — he called it “pitching a fastball up the middle” — so that the SME could nail questions in front of prospective clients. You don’t ever want to blindside your Product Designer or make yourself look smart at their expense — this massively erodes trust
• Make sure the feedback and discussion stay aligned with the objectives for a given review. E.g. if we’re here to review content / copy with compliance, don’t allow the group to dive into feedback on IA, ID, and VD. Take those things offline
• Make sure that reviewers are expressing their concerns about the experience, not providing detailed solutions. Designing by committee is a surefire path to mediocre experiences. Everyone has an opinion on design (esp. on VD), but not everyone is equipped to meaningfully synthesize compelling options — that’s the Product Designer’s job. So encourage the reviewers to point out potential problem areas or areas of uncertainty, and after the review the Product Designer can sort them out
• If the review ends up in a rathole, facilitate the group out of it. In some cases, you may need to stay in the rathole for a bit because you need the feedback or the feedbacker is a key partner who is pointing out material implications and risks. But encourage timeboxing a discussion so that the group is productive, then take it offline

Internal reviews within an Agile team should be informal and allow for spitballing, i.e. it’s a safe environment. But when meeting with stakeholders, you and the Product Designer need to be aligned and crisp. It enhances your credibility with stakeholders and sets the right precedent.

Tip #5: Strategize together on test-and-learn

This includes preparation before research such as user testing, e.g. what are the objectives, which user segments are we testing with, what flows / parts of a prototype should we test, etc. Don’t feel the need to decide everything as the PM — offer suggestions and riff with the Product Designer and the Researcher.

Dialogue during and after user testing to align on insights and learnings to inform iteration and product decisions. It’s fun to sit together (physically or virtually) during user testing to observe what we got right and where we totally missed the mark. These sessions are often eye-opening, and the verbatims and reactions from users are gold to share with stakeholders and leaders so that we can collectively learn from the customer’s perspective.

Broadly speaking there are 2 types of research:

• Generative research: this is learning about meaningful customer problems. E.g. what pain points they’ve faced, how they’ve made decisions, where they’ve gone for guidance, what existing solutions / apps they’ve found useful and why, etc. Generative research can be conducted in many ways: IDIs (In-Depth Interviews), surveys, ethnographic studies, etc.
• Evaluative research: this is coming up with solutions to meaningful problems, then pressure testing your solutions with users via moderated or unmoderated studies. The higher the degree of uncertainty, the more valuable qualitative methods — e.g. user testing of prototypes — tend to be, because it’s expensive to build then fail. Fail early, learn inexpensively. As an Engineering leader once said to me: “In user testing, there is no failure. There is only learning.” Determine whether you have a problem gap or a solution gap. Fall in love with customer problems, not your solutions, and you’ll iterate to compelling solutions. Once the degree of risk has been reduced, more quantitative methods — e.g. A/B testing — tend to be more appropriate.

Tip #6: Express your appreciation

More so than any role, Product Designers face a constant stream of criticism of their work, some of it unconstructive, unhelpful, or vague. This can really wear on a person.

Let your Product Designer know when they’re kicking ass and why. When they go the extra mile, make sure to thank them. Obviously, you should do that for anyone you work with, but Product Designers experience more criticism than any other role. Counteract that negative energy with merited praise.

Tip #7: Educate yourself on design

It can be argued that this should be the first step, but realistically education is a process that takes time.

Look at every product and service you use as a consumer with an eye for Product Design. Does it clearly solve a problem? Is it intuitive? Is it usable? Is it delightful? Is it robust? Is it feature-rich? Is it consistent throughout the experience? Does it anticipate my needs? Does it meaningfully support and enhance the brand? Make mental notes where you find great examples. E.g. take screenshots as you use experiences, so you have a library of good and bad examples.

Ask your Product Designer a lot of questions and learn design practices. Most Product Designers are delighted to share knowledge with their PM — this levels up the partnership and makes it more effective. I’ve embraced terms such as cognitive burden, mental model, and frictionless / friction-oriented — they’re effective for framing design considerations with stakeholders. Ask your Product Designer about their favorite design books and blogs.

My recommended reading

Norman’s book is an all-time classic. It was written before the digital age, but the concepts and thinking are applicable today.

These 3 books made Tufte famous. He has been heralded as a genius when it comes to data visualization. Many regard Envisioning Information as the best of the series. Tufte provides several famous examples in his books, including:

• John Snow’s problem solving a cholera outbreak in London (no, not the GoT hero 🤣)
• The tragic failure in framing the risk of launching Space Shuttle Challenger in freezing weather

I have borrowed heavily from his concepts, in particular small multiples, in countless presentations. Between 1998-2008, many designers I knew believed that Tufte didn’t get web design. Since then, technology has developed in leaps and bounds, especially with rich data visualization (e.g. Google Maps) and mobile phones, so his concepts are quite relevant.

I am a big fan of Luke W. He is an OG on mobile design. Luke shares writeups from various events, but I find his own articles to be the most insightful. While he has tailed off writing since the pandemic started, many of his writings — even those from a decade ago — are still relevant and worth reading.

growth.design provides compelling growth & UX case studies in a comic book format. Each case study includes rich commentary on each page / screen of the experience, along with suggested improvements and callouts of applicable design principles.

Check out my Recommended Reading list for more books and blogs I think are worth your time.

Tip #8: Learn more about user experience roles

There is a lot of variance in terms of how Product Designer / UX Designer / CX Designer / UI Designer roles are labeled and described. Within the design community, there is a lot of discussion around the overlaps and differences between UX and UI.

As the acronym implies, UI is about the user interface, whereas UX is broader in scope and covers all aspects of the experience. Using Apple as an example, the iPhone interface is UI, whereas the combination of iPhone, Apple Store (physical retail), technical support, etc are parts of the UX. Apple is a company that nails UX — when I walked into the 1st Apple Store in SF, I was blown away; it was more like a gallery of products than a traditional retail store, and the Apple employees were evangelists who were eager to help people connect with the right products. It was so Apple. And it’s wildly successful: Apple retail stores average a staggering $5k sold per square foot, which is more than an order of magnitude higher than most retail (average of $325 per square foot).

Nielson Norman Group posted an excellent report on user experience careers and roles, from the perspective of the practitioners. This is a worthy read to understand how roles are evolving.

What do you think are other key tips and insights? Please share your thoughts and experiences in a comment below.

Before you go…

I hope you found this article helpful. I’d love for you to complete the 3 Ss below:

1. Subscribe to Ed on Product, so you’ll never miss an article and can join this community

   Type your email…

   Subscribe

2. Share this article, to ensure we’ll get more feedback to inform future articles
   • Click to share on LinkedIn (Opens in new window)
   • Click to share on Facebook (Opens in new window)
   • Click to share on Twitter (Opens in new window)
   • Click to share on Reddit (Opens in new window)
3. Score this article by answering just 1 question, so I can write better articles for you
   How likely are you to recommend this article to a friend or colleague?
   (0 = not at all likely, 10 = extremely likely)
   0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

Image by Firmbee from Pixabay.

Illustrations courtesy of unDraw.