Don't insult designers with your wireframes

For product managers, providing requirements to designers has always been a tricky and dangerous topic. Unfortunately, most of the product management professionals still think that designers will do the user interface exactly same how they provide in their wireframes.

However, is this the right way? HELL NO! Giving a wireframe or mockup to a product designer and ask him to provide in a polished way is one of most aggressive insult to them. Unfortunately, most of the designers are used to work in this way so they don't even feel the insult anymore… Problem comes out from two simple root causes:

1- Why does wireframes stand for?

2- What roles are you expecting from product managers and product designers?

I agree that product managers are owning their product and responsible for it's all success and failure. However, owning a product does not mean that she decides everything.

Product Manager asks what she or he's looking for. A product manager does not focus on HOW!

  • PM explains user (business) needs, expected outcome, benefits, etc.
  • Engineering team decides how to do it and builds it
  • Product designers work and decide on user experience
  • Then PM is the final point to evaluate all feedbacks and to approve work done in user acceptance tests before release.

This is a team work, not a single man decision making game.

When are wireframes needed? When to avoid?

From my point of view, we as product managers don't need wireframes for most of the cases. If a product manager can clearly explains user needs, limitations, expectations, etc.. and product designer gets the points clearly, there won't be a huge issue. Only several iterations should be expected. (Product designers' knowledge on product and users should be high too.)

Don't mix your expectations from a product designer. That colleague of yours is there to work and think on your users' experience. Describe the user pains and gains, let designer understand your product and rest should come smoothly.

Let's go over a simple example:

  • You don't need to say: "I need a Save as Draft button here." Try this one instead: "Users require a draft version of their work before finalizing and saving as last state." So now, it's product designer's

Ok, but what if product is so complicated and designer needs some guidance?

It's common that product designer may not know all user needs or experience as much as product manager and team do. In this case, it'll be good to explain the user flow in wireframes. In these wireframes, you should point out:

  • Crucial needs (elements) or actions and why they are needed
  • How use case should be as basic level (Not pure user experience I'm speaking)
  • What you expect as outcome

And after preparing the wireframe (a primitive prototype for designer), you should have a meeting or call with your colleague to describe what you ask for. I strongly recommend a written requirements with acceptance criteria in addition to your wireframes.

Recently I did this method twice with a colleague of mine. I can proudly say, we are so happy with the output. And I can assure you, outcome of his designs does not even look similar to my basic wireframes at all. But he got all of our concerns, needs and gains.

Even though I had good experience in this method, I don't think it's the right way!

The reason is simple. You hire a person for this role. And you trust her/his skills on product design. That person's skills, understanding and experience on user experience should be better than yours (unless you made a bad recruitment) Then let them do why they joined your team.

We all product managers hate when someone on the top says what you need to develop without asking your opinion. Right? It's all same from my perspective.

Spend your precious time to describing what and why you need it in verbal and written ways. Not wireframes!

Long story short, respect people what they are doing.