原文: The ideal designer & project manager

 One question I’m often asked is what is the ideal designer? - I get this from managers or VPs in tech companies, trying to figure out what’s wrong with the relationship their managers / leaders have with the design staff.

Working with ideals is an interesting exercise: it reveals assumptions and forces opinion as there’s no right answer, and even if there were, this universe rarely grants ideals (at least to me). So here’s my staple answer on ideal roles, followed by some thoughts on reality.

The Ideal PM

The best PMs partner with design in a similiar way to their partnership with programmers. They collaborate (not dictate) with the designers/programmers, perhaps starting with their own seeds, or ones from the business folks, and then delegate as much of the engineering thinking and design thinking as they can. The ideal PM focuses on creating the best environment for all roles to do well: marketers, analysts, designers, testers, everyone. They carefully shift the environment, the power balance, and their direct involvement depending on the project goals, the talents involved, and how far along things are.

Instead of designing, PMs should first use their unique powers to co-ordinate their team with (or protect their team from) management, other project teams, budgets, star-charts, etc. Any other time spent designing should only be: in partnership with designers looking for collaboration/feedback, where designers don’t have time or when quality is low (just like they’d help out test, documentation, or whatever). A good PM is a leader and a results machine: willing to do anything to empower people on their team, including keeping their hands out of the design cookie jar (slap).

The ideal designer

Someone with many design talents and who is a natural thought leader on the team. They not only make wireframes and prototypes, but drive the thinking and tradeoffs behind them, comfortably evangalizing good ideas and staying near the center of important discussions. They are drivers in resolving design issues, solving problems, and making things happen, and people happily come to them for help with decisions. They are communicators and collaborators as much as idea generators, leading design ideas through engineering, marketing and other parts of the process. They negotiate with PMs on when to handoff design leadership and who is best able to represent a decision, a design or a problem to the rest of the team.

Designers should be the tiebreaker in design issues and be granted signifigant authority when ease of use, style and other design traits are important goals. The designer’s opinion on design matters should trump others, just as an engineer or marketer’s opinion would in certain situations. A good product designer earns these powers through the respect of everyone they interact with, as an intelligent, thoughtful, reliable teammate.

The common dysfunctions

I offer these not as inditements of entire disciplines - that’d be stupid. Instead, I can tell you that when there are problems, these are the most common things I’ve seen for PMs & Designers. If what follows pisses you off, find your counterpart: maybe PMs & Designers can at least bond in their flaming hatred for me.

(Hint: Put your lead suits on now)

Common PM dysfunctions

Many PMs know little about design, or worse, believe they know everything - the result is any good designer will be quickly frustrated and turned off by them. Arrogant PMs, particularly from tech-backgrounds, often have limited exposure to designers, or only mediocre, limited role / contracted ones, creating a self-fulfilling loop for their low expectations for design staff. Even if they come across a superstar design talent, the PM will be blind to it, misuse it, or frustrate it to the point that they are rendered mediocre, insanely bitter, or both.

PMs can be tyrants and empire builders (”Here comes Napoleon” is often heard just before PMs enter rooms), comically insecure about their power, who see designers as threats to their fragile sense of power.

Common designer dysfunctions

(Hint: Don’t touch that suit unless you’re adding another layer).

Many designers claim to want leadership roles, but as soon as there is a design tradeoff debate, or a tough business decision, moments where there is an interdisciplinary leadership vacumn that they are primed to fill, they retreat. When their team leaders need to be taught core design principles, brand fundamentals, or any basic concept, some designers sit in gloomy silence, prefering endlessly clever protests in private to stepping forward in mixed company as a true design leader. This kind of passive aggression confirms the team’s perception of designers as (bitter) specialists, and simultaneously reinforces the designer’s frustration with their environment.

Designers often have auteur sized egos without the auteur quality track record of shipped work (At least in the eyes of their team, if not in truth). This gap between how designers percieve their talents vs. how their team values their talents must narrow for relationships to improve, and the designer, in the minority, often has to compromise first but is unwilling to do so.

So how do you fix PM / design relations?

PMs have more responsibility for these issues: so I start there. They are often granted more authority than designers, and have broader responsibility - meaning it’s up to them to delegate authority to design or do whatever it takes to make designers effective. A good PM should see a designer or programmer as both a person and a resource, and their job is to maximize the value of that resource towards the goals. If a PM is honestly trying to make a designer as valuable as possible, collaboration becomes natural and tension evaporates. And if the designer reciprocates (does whatever it takes to help towards the goals), same thing.

But designers have to take risks with their roles - if they want more power or influence that only comes with asking for bigger challenges and delivering: something they have to push for on their own (In old-school Microsoft parlance, you have to step up). These changes make designers feel vulnerable, but growth requires moving out of comfort zones.

In groups with no history (or a bloody one) of pm/design relations, it often takes a pilot effort: pick your most compatible pairing of a PM and a designer, define a new set of ground rules, and give them the cover-fire and resources (by their definition) to run with it. In a month when they can show kick-ass results, highlight them to the rest of the organization as the model to emulate. You need local examples of the new relationship working for people with intrenched opinions to change their minds. (Often you need to pick a trio of PM/dev/design for the pilot to work).

Reward models for Designers & PMs

The Pavlovian answer to all these problems is how the senior manager overseeing everyone rewards PM/designer behavior. If designers are rewarded for stepping up and being visible, they’ll do it more often. If you give kudos to the PM/designer pairings that collaborate best, more people will emulate them. So moving a team closer to ideals has more to do with what behavior is rewarded (promotions, raises, kudos, yachts, mansions, etc.) than what’s said or written down. Writing role definition documents is a waste of time if not tied to the core reward system.

One tricky pattern at many software companies (Microsoft included) is how people are rewarded for features: new features, big features, it’s features that drive how visible people are in their organization. (This is the true reason for bloat: people know it’s bad design, but the system rewards it, so someone always does it). To give designers more power in these environments demands shifting the PM reward structure away from feature design, and towards team building & team results, a difficult culture shift.

Notes and caveats

• Since ideal people are rare, the best you can often do is approximate with a team. If you have 3 or 4 PMs who in conjuction play the roles, you have a virtually ideal situation. In reality this is a better way to use these idealizations that trying to hire perfect people.
• Often it’s the lead position (lead designer / lead PM) that is closest to the ideal in the role that they play: using their own talents, and the talents of their reports, they are most accountable for using the resources in the best way possible.
• It’s synergy at the manager levels that makes all the difference. If the overall project manager is sympatico with the most senior design manager, they’ll naturally pave the way for similiarly healthy relationships all the way down. But if they don’t, that gap will cause all of the organizations problems. Until they admit this and solve it, progress is uphill, on ice, in the dark, naked, while chased by rabid crampon wearing wolves.
• There are many different kinds of design, which means many different relationships and roles. If I knew the details in a particular case (Feel free to offer one) I’d likely offer a modified set of ideals. The roles of visual, interaction, game, and web designers all create unique challenges.
• Where is usability / user assitance / marketing / VP / me in all this? Hey, it’s just a blog post - can’t cover everybody. If you raise entertaining complaints in the comments, odds go up I’ll write about your favorite role pairing next time.

译文: 理想的设计师和项目经理

        我时常困惑：理想的设计师是一个什么样子的呢？我从技术公司的经理和副总裁那里寻找答案，试图去弄清楚，经理和设计人员之间的关系到底是怎样的。

理想的项目经理

        优秀的项目经理与设计师之间的关系非常类似他们与程序员之间的关系。项目经理通常和设计师或程序员合作（而不是命令），他们通常接到其它各个部门人员的需求，经过取舍后，尽可能的以工程师和设计师的立场思考问题。理想的项目经理能够创造一个融洽的工作环境，使得市场人员、分析人员、设计师、测试人员等各个项目成员和谐地发挥各自最大的能力和作用。

项目经理无需参与具体设计，他们需要首先运用独特的能力去协调各种流程、项目、预算、保护团队成员等。只有当产品设计人员时间不够等情况，需要和项目经理一起合作、收集反馈的时候，项目管理人员才具体参与到设计工作当中。优秀的项目经理会是一个领导者、驱动机器，他们愿意为激励团队成员去做任何事情，甚至能够将甜点直接送到团队成员的嘴边^_^

理想的设计师

        这是一个有着设计天赋的人员，并且是其他人眼中供人的领导者。他们不仅仅制作线框模型（wireframe model）和原型图，而且经常进行换位思考，传播好的创意，参加各种重要的讨论。当遇到设计难题时，他们是导航员，能够解决问题，实现创意，并且人们非常高兴去征求他们的意见。他们是一个优秀的沟通人员和合作对象，就像一个发电机一样，不断的将好的设计想法和创意传输到工程师、市场人员和其他的各个流程当中。他们需要和项目经理沟通何时将转移产品的设计权限、谁来将一个决定、一个设计、或一个问题传达到团队的其他成员当中。

设计师在设计任务中应该是一个决策者，并且当涉及到“易用性、样式和其他设计特点”时，应该给设计师足够的权限去完成设计任务。设计师在设计问题上的意见应该胜过其他人，就像在开发当中，工程师的意见是最重要的。一个优秀的产品设计师通过和其他人员的交流学习到这些能力，他是一个聪明的、有思想的、可靠的团队成员。

常见的错误
        我列举出这些常见的混乱错误情况，是为了让大家发现问题所在，并非人身攻击，请勿对号入座^_^

项目经理常见的错误

        许多项目经理并不了解设计，更糟的时，他们总以为他们对一切都很在行，结果导致任何一个优秀的设计师马上被打击失败。自大的项目经理，特别是那些有技术背景的，通常对设计师的期望并不高。即便是他们遇到了一个十分出色的设计师，他们也会视而不见，并且妄加指责，甚至挖苦。

项目经理被人们认为是“拿破仑”，尤其是当他们进入办公室之前，我们总能听见有人说：“拿破仑来了”。这是一个暴君、专制者的形象。滑稽的是，他们对自己的权利十分担心，往往视设计师为自己的威胁，害怕他们削弱自己的权利。

设计师常见的错误

        很多设计师要求领导者的角色和地位，但一旦遇到了严重的争论问题，或是棘手的商业决策问题，他们就会首先撤退逃跑，形成了权利的真空。每当团队领导者需要去学习、获得那些核心的设计概念、原则、品牌基础、或是任何基础概念是，有些设计师就沉默不语、一言不发，以保护自己的权益不受伤害。

设计师经常自负地不进行任何质量监控的记录，他们坚信自己作品的完美性。因此，设计师自认的才能和团队准确衡量他们才能之间存在一个鸿沟，而且，大部分设计师宁肯不设计也不妥协。

如何修复项目经理和设计师之间的关系

        项目经理对这个问题负有更多的责任。和设计师相比，他们通常拥有更多的权利，因此也应该承担更多的责任。也就是说，他们有义务让设计师更有效率地工作。优秀的项目经理应该视设计师和工程师为资源，他们要尽可能地使这些资源发挥的作用最大化。如果项目经理认真地、努力地想尽可能实现设计师的价值，那么合作是自然而然的事情了，紧张的气氛也将会消失。同样的，如果设计师也抱着相同的心态去回馈项目经理，也将会产生相同的效果。

        但是设计师的角色承担着一些风险，如果他们想要更多的权利或是影响力，那么结果只会是带来更多的挑战和任务。

        在一个全新的团队里，建立好项目经理和设计师之间的关系需要一个示范效应：选择一个最为配对的项目经理和设计师，设定一些基本原则，给他们足够的资源，启动项目，等待产品有了雏形，作为示范案例和模仿对象展现给团队的其他成员。

一些提醒和告诫