Last updated: 2022-08-05
Some Product Managers (PMs) lack a nuanced understanding of Product Design disciplines, provide direction & feedback to Product Designers in unhelpfully limiting ways, and fail to build an effective partnership with Product Designers.
In this article I provide guidance on how PMs can effectively collaborate with and empower their Product Designers to design delightful customer experiences.
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:
- Information Architecture (IA)
- Interaction Design (ID)
- Content Strategy (CS)
- 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:
- 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
- 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
- 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 customer 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
- What is the navigation / navigation systems
- What is the flow
- What are the interaction patterns (e.g. buttons, grippers, carousels, etc)
- What affordances do we provide for accessibility (e.g. for limited-mobility users such as keyboard-only users)
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 ADA affordance is a ramp to the front door.
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 use of animation to pull focus.
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. Discovery exercises with customers such as card sorting should inform both disciplines.
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 communicate success or failure in task flows with visual treatments
- What affordances do we provide for accessibility (e.g. contrast ratios such as WCAG 2.0’s 4.5:1 between fonts and background colors for low-vision / no-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.
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 customers, it protects your company — think of the implications 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 customer 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 customer 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 (and I would too).
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 options are missing the mark, just make sure to explain why and let them mull it over. 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, but these should be regarded as such until the Product Designer has time to dive into the VD systems. For that reason, Product Designers often plaster “FPO” on such comps and images.
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 reviews to point out potential problem areas or areas of uncertainty, and 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 user testing, e.g. what are the objectives, which customer segments do the participants represent, 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 research moderator.
Dialogue during and after user testing to align on insights and learnings to inform the next iteration of the prototype. It’s incredibly 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 entertaining!
Tip #6: Express your appreciation
More so than any role, Product Designers face a constant stream of criticism of their work, some of it not particularly constructive, unhelpful, nor tactfully delivered. This can really wear on a person.
Let your Product Designer know when they’re kicking ass and why / how. 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 pick up the lingo. 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 for recommended bloggers and books.
My recommended reading
Norman’s book is an all-time classic. It was written before the digital age, but the concepts and thinking are totally 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 stated 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.
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:
- Subscribe to Ed on Product, so you’ll never miss an article and can join this community
- Share this article, to ensure we’ll get more feedback to inform future articles
- Score this article by answering just 1 question, so I can write better articles for you
Illustrations courtesy of unDraw.