Clear ownership makes for a happy team

Hybiscus flowerIn a lot of my posts, I talk about deputizing everyone to give input to the user experience, product and design process.  However, it’s important not to lose sight of clearly defined roles and ownership, or you’ll end up with a very mediocre product.

“Websites designed by committee end up beige and tweed” – A COO I used to work with

On a product team, you usually have executives, product managers, maybe project managers, content producers, designers and engineers.  Note that these people might be on different teams organizationally, but they need to understand that they are on the same team pragmatically.

Each and every person should be able to give input to every single aspect, from strategy, to tactics, to the pixels on the page and which screens show.  However, just because everyone’s voice should be heard, doesn’t mean that the project manager should dictate what color a button should be, or an engineer should be the final decision maker in the pivot of a company’s strategic direction.

That said, this blog is about design, and how to be a good designer even when you’re not a designer.  Here is the most important thing I will ever tell you about doing design:

Give your designers problems to solve, and don’t tell them what interface they have to use to solve the problem.

First of all, if you are not the designer, you are not the expert in design and interaction.  You might have knowledge, you might even be really good.  But the designer is the person paid, probably very large amounts, by your company to do that job and to think through all the options.  You should let them do their job.  If you don’t feel like they are good at design, you should talk to your supervisor or theirs about replacing them.  Don’t undermine them or overrule them.

Second, you are all on the same team, working for the same goal.  If you and the designer have a difference in opinions about what specific interface or interaction will meet that goal, the designer should win by default.  They are the one who will be held responsible for the interface they’re designing.  They need to be the tie breaker, even when the designer is part of the tie.  Would you want to be held responsible for decisions someone else makes against your will?

Third, designers are highly in demand right now.  Every designer I know hears from at LEAST one new recruiter a week.  If you’re constantly overruling your designers, they’re going to wonder what you need them for, and they’re going to go join a company where they get to actually do their job.  Maybe this is a good thing – maybe they aren’t the right designer for your company.  But ask yourself: if you hire a different designer, are you still going to overrule them when they disagree with you?  If so, the problem isn’t the designer.

Designers have a role in this too.

Execs’ job is to steer the company in the right strategic direction.  They get the big bucks, and have the big risks, to make it worth the sweat and tears they put into this.  Designers should bea  voice at the table, when strategies are being discussed, but once a strategy has been chosen – by the exec, not by the designer – it’s the designer’s job to jump into it with both feet and tow the company as hard as they can toward those goals.

Product managers’ job is to decide the tactics that get you to the big picture the execs have drawn.  They also need to determine the requirements for those tactics, and make sure the whole team is clear on what needs to be done.  Designers should give input, suggest features, and argue against the ones that are just cognitive clutter – but in the end the designer needs to trust the product manager to do the right thing for the company, and make the best design to fit the features specified.

Project managers’ job is to keep things moving on a timetable.  Designers have a responsibility to communicate how long things are going to take them, taking into account possible delays, iterations, and things that’ll go wrong.  And then, when the project manager sets a timetable and commits the company to it, it’s the designer’s job to pull as many all-nighters as are necessary to get things done by their due dates.

Content producers deliver the content the designer relies on to design their screens.  The designer can give direction as to length and sometimes structure, but in the end they need to trust the content strategy and adjust their designs to fit the content, or make the designs AROUND the content provided.

Engineers make the world happen.  They need to be involved in the design process, and designers need to trust that the engineer will build what they’ve designed. When the engineer says something can’t be done, the designer must listen to the alternatives, and be flexible enough to change their design to fit reality.

The bottom line

  1. Trust your designers to know what they’re doing.
  2. If you can see it or click on it, the designer has the final word, not you.
  3. Designers: open your ears and listen, and trust others to do their jobs if you want them to trust you.

Today’s Interesting Link:

From Up North – If you’re like me, inspiration comes from everywhere.  From Up North is a fantastic blog that gathers up inspiration from all over the art world – fine art, illustration, design, word art, tattos – you name it!  It’s daily and easily consumed and I love it.

 Today’s Usability Quote:

 “[Having too many choices] takes [customers] out of the purchasing process and puts them into a decision-making process.”  – Stew Leonard Jr.

Today’s Music To Design To:

Arash’s self-titled album is Iranian pop, so I don’t understand the words.  This makes it great for design work!  It’s energetic, exotic, uplifting and a little bit sexy.  I REALLY hope the lyrics don’t talk about drowning kittens and stealing candy from babies, because I like it so much.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>