This is the first in what I hope to be a series of PM 101 posts, wherein I focus on some fundamentals of Product Management.  For this first article, I’ve chosen a topic that’s near and dear to my heart, as well as one that’s been raised several times during my teaching sessions at General Assembly — how should Product Managers work with Designers.  Now, to clarify I’m using “Designer” as a catch-all term to include everyone involved in the User Experience, User Interface, and Human Interactions side of the product equation — basically, the people who are trained to define how the user interacts with our product in order to achieve their goals.  With that established, let’s explore some common issues and potential paths to success…

Start With Expectations

First and foremost, as with any other team, we want to establish what the expectations are that we have of one another.  Some UX and UI teams like it when their Product Managers relate their thoughts and requirements in a visual format (wireframes, mockups, sketches…), but others prefer to start strictly from the same user story that’s going to be delivered to the development team.  And, by the same token, as Product Managers we need to be very clear about what we expect the output of these teams to be — what fidelity of design is expected, how much design work needs to be done before developers start working on the project, will the design team be working with the dev team or just tossing their designs over the wall?  All of these questions should be hashed out well ahead of time, before one pixel drops on a screen or one pen hits the paper for a sketch.  The number one reason that teams wind up in conflict with one another is due to mismatched, and often unspoken, expectations — if we don’t tell someone what we expect, we can’t hold them accountable when they miss the mark.  So, talk with your design teams and know what they need going in and what they’re expected to deliver coming out.

Respect Your Designers

As I’m sure you’ve noticed, I’m a big believer in establishing relationships based on trust and respect.  And in many organizations, one of the teams that you need to work the hardest at establishing and maintaining a trusted, respectful relationship with is your designers.  And no, it’s not because they’re “creatives” and left-brains who need constant coddling.  It’s actually because in many large organizations, UX and UI are second-class citizens.  When scope needs to be cut, what goes first?  The polish.  When budgets for a project need to be cut, what goes first?  User testing.  When people want to nitpick at something just to feel like they’ve had their influence, what do they focus on?  “The color of the button on the third page of the website, third from the bottom looks a little too cerulean for my tastes.”  In short, the Design team gets crapped on.  A lot.  But you need to be their champion, you need to be their bosom buddy.  You need to reinforce with them that you’ve got their back, and that you trust their decisions.  Honestly, I don’t care if you have a Bachelor of Science in Human Factors Engineering and have studied Color Theory and Design Thinking in your spare time — if you’re not on the Design team, your job is not to design the product.  Your job is to facilitate the efforts of the Design team in achieving their goals — and if you disagree, to have that discussion in respectful terms with the proper amount of deference to the people whose job it actually is to design the product.  All too often, Product Managers see themselves as Designers — whether they have the actual training and experience or not.  Know your strengths, know your weaknesses, and respect the people whose job it is to actually do these things every single day — it’s likely that they’re seeing and working with patterns that you’re not necessarily aware of.  Don’t try to design it for them — let them design it and provide constructive feedback.  They’ll appreciate it, and you’ll have more time to do your actual day job.

Set the Tone for Collaboration

I’ve worked with and heard many stories of design teams which were very insular, had a “throw it over the wall” mentality, and who felt that their designs were like the stone tablets that Moses brought down from the mountain — sacred and immutable.  They sucked.  There’s really no nicer or better way to say it, and I’m not afraid to call it out.  Look, Product Managers aren’t Designers, Designers aren’t (usually) Engineers, and Engineers aren’t (usually) Designers — so just because a Product Manager stated a problem, and the Designer made it look all awesome and pretty doesn’t mean that the Engineers don’t get a say in the matter.  Sometimes, designs can be too aspirational — either they can’t be achieved with the current tech in use at the company at all, or they can’t be achieved in a reasonable amount of time and with a reasonable amount of effort.  And you should, as the Product Manager, empower your Engineers to make those calls during implementation — and to communicate them back through to the Design team.  But first and foremost, we as Product Managers need to model the behavior that we want to see — we need to look at what we’re doing and how we’re doing it closely to make sure that we are asking for engagement and challenge and corrections to our own deliverables.  I love to communicate visually, because it’s how I think — but when I hand over mockups to my Designers or my Engineers, it’s with the clear understanding that those mocks are just an idea — and usually a very loosely thought-through idea.  I want them to challenge the design; I want them to make something better than I can put on paper or in Balsamiq; I want them to take my ideas and run with them if they make sense, or toss them aside if they don’t.  I’m defining the “what” and the “why” — Design and Engineering are concerned with the “how”.