HTML MASTER CLASS /// LEARN TAGS /// BUILD STRUCTURE /// SEMANTIC WEB /// HTML MASTER CLASS /// LEARN TAGS ///

Working With Designers

How to work with designers as a thinking partner, not a spec-delivery pipeline.

⚡ Total XP: 0|💻 management XP: 0

Skill Matrix

UNLOCK NODES BY LEARNING NEW TAGS.

Select an unlocked node to view details root

🚀 LEVEL UP TO SENIOR:Unlock 500+ Advanced Practical Challenges & Exercises.

🎓 COURSERA PARTNER:Earn professional Google, Meta, and IBM certificates to supercharge your resume.

The quality of the PM/design relationship shows up directly in the product — teams that collaborate early ship coherent experiences, teams that hand off specs ship a patchwork of disconnected screens.

1Involve Design Before the Spec Exists

By the time a PRD is 'final,' many of the important product decisions have already been made implicitly — layout assumptions, flow order, what's emphasized. Loop designers in during discovery, while the problem is still fuzzy, so their expertise shapes the solution instead of just decorating one you already picked.

2Protect Design Time From Scope Creep

Adding 'just one more state' or 'a quick edge case' after a designer has already built out a flow is rarely quick — it can mean reworking the whole system. Treat late additions to a design in progress the same way you'd treat late additions to a sprint: they go through prioritization, not a hallway request.

3Step-by-Step Breakdown

Introduction. The worst PM/designer relationship looks like a waterfall: PM writes a spec, throws it over the wall, designer makes it pretty, throws it back. The best relationship starts collaboration at the problem stage — before anyone has decided what the solution even looks like.

Bring Problems, Not Wireframes. If you hand a designer a wireframe you sketched, you've already made the design decisions and just want them to polish it — which wastes their expertise and usually produces a worse outcome. Instead, share the user problem, the constraints, and the success metric, and let design explore the solution space with you.

Giving Feedback Without Redesigning. When reviewing mockups, critique against the user problem and business goal ('does this reduce the confusion we saw in testing?'), not personal taste ('I'd make it blue'). Vague taste-based feedback is the fastest way to make a designer stop trusting your input.

Knowledge Check. A designer presents two mockup directions for a new onboarding flow. What's the most productive way for a PM to give feedback?

→Say which one they personally like the look of better
→Evaluate each against the onboarding completion goal and the specific user confusion the redesign was meant to fix

Summary. Great PM/design partnerships are built on shared context, not handoffs. Involve designers while the problem is still being defined, give feedback rooted in user outcomes, and protect their time from scope creep introduced after they've already started building.

Pascual Vila

Frontend Instructor // Code Syllabus

Common Pitfalls & Errors

The Error //

Handing designers a finished wireframe instead of a problem

// Wrong
"Here's my wireframe, just make it look nice."

// Right
"Users drop off at step 3 of checkout — can we explore why and how to fix it?"

The Solution //

If you've already decided the layout before design is involved, you're using a trained designer as a visual polish tool. Share the user problem and constraints first, and let design contribute to the actual solution.

The Error //

Giving feedback based on personal taste

// Wrong
"Can we make the button pop more? I just don't love it."

// Right
"In testing, users missed the CTA entirely — does this version address that?"

The Solution //

'I don't love the color' isn't actionable and signals the PM is reviewing aesthetics rather than outcomes. Tie every piece of feedback back to the user problem or metric the design was meant to address.