working with designers
Great designs are actually objective — because it all culminates down to that one simple, sophisticated, beautiful design. The subjectivity is a phase you pass through. The destination is clarity.
Working with designers is genuinely fun. I say that without reservation. Of all the cross-functional relationships a PM manages, this one has the highest potential for joy — and the highest potential for passive-aggressive disaster. The difference comes down to one thing: whether you treat design as a service function or a thinking partner.
In most Indian product companies, the designer-to-PM ratio is worse than engineering. You might have one designer covering three PMs. That designer is drowning in Figma requests while you are wondering why your screens look like a government portal. The fix is not “hire more designers.” The fix is how you work with the one you have.
What designers actually do (that PMs get wrong)
PMs routinely underestimate what design is. They think design means making things look nice. Pixels, colours, fonts. That is styling. Design is decision-making about how a human interacts with your product. It is information architecture. It is interaction patterns. It is the reason a user finds what they need in two taps instead of seven.
When a designer shows you a wireframe with grey boxes and placeholder text, they are not being lazy. They are forcing the conversation to stay on structure before anyone gets distracted by whether the button should be blue or green. Respect that discipline.
Product managers own the “what” and “why.” What problem are we solving? Why does it matter now? What does success look like? What are the constraints — technical, business, regulatory?
Designers own the “how it works.” The interaction model. The user flow. The information hierarchy. The visual language that makes complex things feel simple.
The overlap — and this is where fights start — is in the user. Both of you claim to speak for the user. The PM brings research, data, and business context. The designer brings empathy maps, usability heuristics, and pattern expertise. Neither perspective is complete alone. The best products come from the friction between these two views, not from one dominating the other.
Design review at a B2B SaaS company in Hyderabad. The designer is presenting a new onboarding flow.
Designer: “I have simplified the onboarding to three screens. Name, role, and first project. We skip the company profile for now and let them fill it later.”
PM: “I do not like this. We need the company profile upfront because the sales team uses it for lead scoring.”
Designer: “The current onboarding has a 34% drop-off on the company profile screen. Users are bouncing because we are asking for too much before they see any value.”
PM: “But sales will push back if they do not get the data.”
Designer: “Can we get it after the user completes their first project? Completion rates will be higher because they are already invested.”
PM: “That... actually makes sense. Let me check with the sales ops team on whether delayed capture works for their process.”
The PM almost killed a better solution because they were optimizing for a stakeholder instead of the user. The designer had the data. Good thing the PM listened.
The PM's instinct was to protect the internal stakeholder. The designer's instinct was to protect the user. The right answer required both perspectives.
How to give design feedback that is actually useful
Most PMs give terrible design feedback. “I don’t like it.” “Can we make it pop more?” “This does not feel right.” These are not feedback. These are feelings. And they are useless to a designer trying to iterate.
Good design feedback follows a structure. Every single time.
Name the user problem, not your preference. Bad: “I don’t like the dropdown here.” Good: “Our users are selecting from 200+ options. A dropdown forces them to scroll through all of them. Can we explore a search-first pattern?”
Reference the context, not the aesthetic. Bad: “This looks cluttered.” Good: “The user lands on this screen after a stressful error state. They need to find the retry action immediately. Right now the retry button has the same visual weight as six other elements.”
Separate structure feedback from visual feedback. In early stages (wireframes, low-fidelity), only talk about structure: flow, hierarchy, what information appears where. Do not comment on colours, fonts, or spacing. That comes later. If you give visual feedback on a wireframe, the designer knows you do not understand the process and will stop trusting your judgment.
Ask questions before making declarations. “What led you to put the settings here?” is better than “Settings should be in the sidebar.” The designer made a choice for a reason. Understand the reason before overriding it. Half the time, their reason is better than your instinct.
Notice what Priya did. She cited data, not opinions. She framed each point as a user problem, not a personal preference. And when the designer raised a complication, she did not bulldoze — she went to get more data. This is what a productive PM-designer relationship looks like in practice.
Running design reviews that do not waste everyone’s time
Most design reviews in Indian companies are broken. Eight people in a room. The designer presents. The founder says “make the logo bigger.” The marketing person wants a different colour. The engineer asks about API constraints that should have been sorted before this meeting. The designer leaves with fifteen contradictory opinions and a week of rework.
Here is how to run a design review that actually works:
Keep the room small. PM, designer, engineering lead. That is it. Three people. If a stakeholder needs to review, they get a separate async walkthrough — a Loom video with the Figma link. They leave comments. You triage those comments before they reach the designer.
Set the review scope upfront. At the start of every review, say: “Today we are reviewing the information architecture and user flow. We are not reviewing visual design. Colour and typography feedback is not useful at this stage.” This one sentence saves hours.
The PM facilitates. The designer presents. Your job is to keep feedback on track, cut off tangents, and ensure decisions get made. You are not the audience. You are the moderator.
End with decisions, not opinions. Every review should end with a clear list: what is approved, what needs another iteration, and what the open questions are. If you leave a review with “let’s think about it,” you have wasted the meeting.
The wireframing skills you need (and the ones you do not)
A PM who can sketch a rough wireframe in Balsamiq or even on paper is dramatically more effective than one who cannot. Not because you are designing — you are not. But because a visual is worth a thousand words of PRD text.
When you bring a low-fidelity sketch to the designer, you are saying: “Here is roughly what I am imagining. Tear it apart and make it better.” That is a starting point for a conversation. When you bring a two-page text description of the same screen, the designer has to translate your words into a visual in their head, and their mental image will not match yours.
Learn one wireframing tool. Balsamiq, Figma (just the basics), Whimsical — it does not matter which. Spend one weekend learning it. Use it to sketch rough layouts before your design conversations. Your designer will immediately work faster because they understand your intent without guessing.
What you should never do: create high-fidelity mockups and present them as “the design.” The moment you add real colours, real fonts, and pixel-perfect spacing, you have crossed into the designer’s territory. You are not a designer. A bad high-fidelity mockup from a PM anchors the conversation on the wrong solution and makes the designer feel like a production artist, not a thinking partner.
Pull up the last three design reviews you participated in. For each one, review the feedback you gave (check Figma comments, Slack messages, or meeting notes).
Categorize each piece of feedback:
- Problem-framed — You described a user problem. (“Users will not notice this CTA because it has the same visual weight as the surrounding text.”)
- Preference-framed — You stated a personal opinion. (“I think this should be bigger.” “I do not like this layout.”)
- Solution-dictating — You told the designer what to do. (“Move this to the left sidebar.” “Use a modal instead of a page.”)
Count them up. If more than 30% of your feedback is preference-framed or solution-dictating, you are making the designer’s job harder. Rewrite each preference-framed comment as a problem statement. For each solution you dictated, write the underlying problem — then delete your solution and let the designer propose one.
Repeat this audit monthly until problem-framed feedback becomes your default.
The “who owns the UX” question
This question poisons more PM-designer relationships than any other. Here is the answer: nobody “owns” UX. UX is an outcome. The PM owns the problem definition. The designer owns the interaction model. Engineering owns the implementation. The user experiences all three as one thing.
When a PM says “I own the UX,” the designer hears: “Your job is to make my wireframes look nice.” When a designer says “I own the UX,” the PM hears: “Business context does not matter.” Both are wrong.
What actually works is shared accountability with clear lanes. The PM decides what problem to solve and what constraints exist. The designer decides how the user interacts with the solution. When those two decisions conflict — and they will — you resolve it with user data, not hierarchy. Run a usability test. Look at the analytics. Talk to five users. The answer is almost never in the meeting room.
Working with designers in Indian companies
Two dynamics are specific to the Indian context and worth naming directly.
The “pixel-pusher” trap. In many Indian startups, especially early-stage ones, design is treated as a production function. The founder sketches the UI on a napkin, the “designer” translates it into Figma, and nobody questions whether the interaction makes sense. If you are a PM in this environment, your job is to advocate for the designer’s role as a thinker, not a tool operator. Start by asking the designer for their perspective before presenting your wireframes. Give them problems, not solutions. Over time, the founder will see better outcomes and start trusting the designer’s judgment.
The outsourced design problem. Many Indian companies outsource design to agencies or freelancers. This creates a handoff culture where the designer is never in the room when product decisions are made. They receive a brief, deliver screens, and disappear. If you are stuck with this model, invest heavily in the brief. Write detailed problem statements, include user research, link to analytics, and add screenshots of competitor approaches. The better your brief, the fewer revision cycles you will burn.
Test yourself
You are a PM at a consumer fintech app in Bangalore. Your designer Kavitha has spent two weeks on a new investment flow. She presents a clean, minimal design — three screens, progressive disclosure, no jargon. Your CEO attends the review and says: 'This looks too simple. Our competitors show more data on the main screen. Users will think we are not serious. Add the portfolio breakdown, risk indicators, and market trends to the first screen.' Kavitha looks at you. The CEO is waiting for your response.
The CEO wants more information density. The designer built for clarity and simplicity. You are caught in the middle.
your path
You are PM at Groww. The lead designer wants to do 3 rounds of user testing before shipping a redesigned portfolio summary screen. You have a hard deadline in 4 weeks for the feature (tied to a product launch event). Three rounds of user testing will take 5 weeks.
The call: Do you push the designer to cut testing rounds, delay the launch, or find another path?
You are PM at Groww. The lead designer wants to do 3 rounds of user testing before shipping a redesigned portfolio summary screen. You have a hard deadline in 4 weeks for the feature (tied to a product launch event). Three rounds of user testing will take 5 weeks.
The call: Do you push the designer to cut testing rounds, delay the launch, or find another path?
Where to go next
- Get the document right before the design conversation: Writing PRDs That Engineers Read
- Understand the user research that feeds good design: User Research Methods
- See how this fits into the product lifecycle: A PM’s Day-to-Day
- The parallel relationship you need to build: Working with Engineering