Your Designer is a Partner, Not a Pixel-Pusher. Brief Them That Way.

You open the Figma link. Your designer has delivered exactly what you asked for. The dropdown is there, the table has the right columns, and the button is the perfect shade of brand-approved blue. It’s pixel-perfect. And it’s completely wrong.

You feel a familiar sinking feeling. This isn't the solution. It doesn't solve the user's actual problem. Now you have to go back, give awkward feedback, and kick off another cycle of rework. You’ll lose a week, maybe two. The engineer who was ready to start building is now idle.

The failure didn't happen in Figma. It happened before a single pixel was placed. It happened in your brief. You treated your designer like a pixel-pusher, a pair of hands to execute your vision. You handed them a solution. You should have given them a problem.

The Wireframe is a Trap

The most common PM mistake is walking into a design kickoff with a low-fidelity wireframe and a list of UI requirements. We think we’re being helpful. We think we’re speeding things up by providing a "starting point."

We are doing the opposite.

This approach strips your designer of their most valuable skill: creative problem-solving. You hired them for their ability to understand user psychology, explore divergent ideas, and craft elegant solutions, not to trace your napkin sketches. When you hand them a wireframe, you implicitly narrow the solution space to your own limited imagination. You’ve anchored the entire project to your first, best guess.

This is the pixel-pusher brief. It turns a strategic partner into a short-order cook. The result is a feature that technically meets the requirements but lacks soul and fails to truly connect with the user’s need.

Write a Brief That Invites Partnership

A great design brief doesn't prescribe a solution. It defines the problem so clearly that the solution feels almost inevitable. It’s not a list of features; it’s a packet of context. It’s the sandbox your designer gets to play in.

Here’s how to build a better one.

1. Frame the Problem, Not the Page

Start with the human story. Who is this for and what is their pain? Forget about the UI for a moment. Use a framework like Jobs-to-be-Done to articulate the core need.

• Bad: "We need a new settings page for email notifications."
• Good: "When a project manager gets overwhelmed with updates, they want to filter out the noise, so they can focus on the critical blockers."

Share the raw evidence. Don't just tell your designer the user is frustrated; show them. Give them the verbatim quote from