PM和RD如何和谐共处

原文地址: http://www.designstaff.org/articles/how-designers-and-engineers-can-play-nice-2011-12-22.html

How designers and engineers can play nice (and still run with scissors)

Jenna Bilotta – Dec 22, 2011

As a designer at engineering-centric companies for the last 10 years or so, I spend a lot of time working with engineers. These collaborations are the most functional and fruitful work relationships I’ve had.

Designers, you can create these kinds of relationships with engineers too — you just need to cut through the personal biases of both designers and engineers to create space for effective partnerships. If you are successful, the benefits far outweigh any of the growing pains and minor adjustments it takes to get there.

I’ve worked in consulting, in academia, and at one of the top engineering companies in the world. I’ve seen design behaviors from many perspectives and worked with many types of designers (from the very technical to conceptual to visual and otherwise).

There are a few consistent patterns of bad designer behavior that undermine our reputation with engineers. I’ve found great success by refining my approach to design in an engineering-centric company, and in the process created long-lasting, trusting, and efficient relationships with engineers where other designers have failed. A good designer can exponentially amplify their work if they have a great engineering partner, but to do that, they need to make a few small adjustments.

Here are my top tips for creating effective design and engineering relationships. My goal is to reduce bias on both sides of the fence, and help designers and engineers form stronger alliances to make better products.

1. Use the tools they use

As a designer joining a new team or starting a new project, the first step to is to ask a simple question: “How do you like to work?” Many designers make the mistake of using tools and processes that they are used to, or that they found success with on previous teams. But things move fast in software and every team is different.

I’ve found I can skip over any painful process mismatch by simply asking the engineering team how they like to work and what tools are already in place. Some teams might like to create a collaborative document to track bugs, or use formal bug tracking software. Some might even be OK living in email, or use an agile process with something like Pivotal Tracker.

The key to a designer’s success is not how pretty their mocks are, but how successful they are at communicating their design so the working product is as close to ideal as possible. A really great designer can adapt to any tools necessary to effectively communicate design — even if it takes a little longer to use a new tool, it pays off in spades down the road by reducing friction with engineering.

2. Participate in the entire engineering cycle

Designers can easily sour their relationship with engineers when they wait until late in the product cycle (right before launch) to become active. For an engineering team working toward launch, it’s frustrating when an outsider swoops in demanding a bunch of detailed changes. (And if you don’t get involved until right before launch, you are effectively an outsider.)

Engineers need designers to participate in the whole life cycle of a product or feature, not just developing the front-end. Designers should be deeply aware of (if not involved in) the hard engineering challenges of setting up basic data structures, storage, retrieval, and UI frameworks. Designers should celebrate and promote every engineering milestone along with the rest of the team — even if it’s a janky half-built prototype using #00C links set in Comic Sans.

Too often I observe my fellow designers rip into the aesthetics or interaction design of an early engineering prototype. When an engineer is met with critical feedback from a designer about issues they haven’t even begun to think about, it doesn’t encourage that engineer to include the designer in future reviews. This is how designers end up begging for massive changes the week before launch, and how we almost never get them.

3. Be specific about what needs improvement

Many designers think they are done when they give a completed, “pixel-perfect” mockup to an engineer. Designers start to get twitchy when a product or feature gets close to launch, and the front-end isn’t looking “to spec.” But instead of responding to the engineer’s latest build with “this doesn’t match my mockup, here’s the mockup again in case you lost it” — be specific!

Designers are trained to catch even the smallest details that most people won’t ever notice. Engineers aren’t purposefully missing the details — it’s just not a priority for them like basic functionality and deploying bug-free code are. It’s the designer’s job to catch these errors and point them out as specifically as possible, because the person you are working with hasn’t been trained to look for those types of details.

File bug reports with screenshots from the live demo and your mockups side-by-side. Annotate the screenshots with detailed descriptions of what needs changing. Show and tell. I often file a bug with annotated “before and after” screenshots and summarize the needed changes as a bulleted list. This way, both visual learners and language learners have the format they need to move quickly and deliberately.

I’ll even go as far as to file interaction design improvements separately from visual design polish because you might have engineers on your team that are stronger in one area or the other — it can be easier to divvy up the work if it’s broken into those categories. Generally, engineers respond very well to lists of improvements that they can methodically move through and check off once complete. It’s a little more work on my part, but I’m more likely to get changes in with this small amount of legwork.

4. Meatspace chats are lovely, but they can’t be tracked

Lots of designers I know would prefer to work out design details in person with a product manager or engineer. This is great, and can help improve team cohesiveness, but the side-effect is that there is no “paper trail.” Unless you are working on a team of two (you and an engineer), everything needs to be documented for the wider team to access and respond to.

So even if you do have a productive in-person chat with your engineer about design improvements, go back to your desk and immediately summarize it in an email or bug report. This gives the entire team a chance to respond, and acts as a record of decisions being made. Any decision that doesn’t come with documented rationale is up for grabs when things get tangled toward the end.

5. Drink a beer with your engineer

Never underestimate the power of socializing with team members. Get to know them, and allow them to get to know you. You can accelerate trust and communication if someone feels you care about them as a person — and not just a set of skills that you rely on to realize a design vision.


Engineers! You didn’t think you’d get off the hook so easily, did you? With all the things that designers can do to make your lives easier, likewise there are a few things you should be doing to create better relationships with designers.

1. Don’t let your first answer be “no”

As a designer, there is nothing more frustrating than to get excited about an idea, start chatting about it with an engineer, and have them shut you down before you even really explain the potential!

I find that lots of engineers (especially ones I haven’t worked with for ages), often respond negatively to design ideas and innovations because they seem like “too much work for something that doesn’t seem important.” Trust me, designers understand that you are working hard to make something minimally viable that doesn’t break if you look at it sideways.

But there is a reason why teams need both design and engineering. It’s our job to make an intuitive, fun and innovative experience that people love to use and want to keep coming back to. Otherwise, all the hard engineering work will be for nothing.

Designers can get carried away with fun or novel ideas, but instead of saying “no” outright, spend a little time trying to understand why your designer is so excited about the idea. Consider talking with her or another engineer about ways to achieve the same effect with less engineering overhead. If your designer thinks you’re an eager and open-minded collaborator, you are more likely to get that icon you need from them at 4am the night before the push.

2. “Fit and finish” is not engineering busywork

Different disciplines consider different things to be extremely important. To a great designer, attention to detail and creating a truly polished experience are paramount. These details matter; they can be hard to articulate but generally affect a user’s subconscious response to a product or feature. Many small detail mistakes can accumulate and lead to a sense that a product isn’t professional or reliable. Conversely, a highly polished app can create a stronger emotional response than one that is flawlessly engineered but has a sloppy user interface.

When a designer asks an engineer to move an icon three pixels to the left, or align two blocks of text on the same baseline, that one change might not seem important — but a collection of these things can really make a difference.

3. Do a gut check with your designer before you launch

If your designer is doing well on the list above, don’t punish her by releasing a feature without giving her a chance to review it — however small you think the changes are. Treat your designer as you would any other team member: Your designer is invested in the success of the product just like the rest of the team.

When you do a gut check with your designer, make sure you actually give her time to respond, suggest changes, and iterate before shipping. Showing the product to a designer just before launch as “FYI only” is as bad as shipping it without running it by your designer at all.


Hopefully my experiences — and the approach I’ve developed — over the last several years will help create stronger alliances between designers and engineers. I believe that this truly leads to much stronger products and better user experiences in the end.

What has worked well for you? Where have you struggled? Share your stories in the comments!

<think>用户现在问的是“pmpm_v是什么意思&rdquo;,看起来他们是在继续了解TBUS回路板中的标识。之前用户已经问过PH、CH、PM、AD的含义,现在进一步询问PMPM_V的区别。 首先,我需要确认PMPM_V在TBUS回路板中的具体应用场景。根据之前的回答,PM代表电源管理模块,而PM_V可能是指电压相关的电源管理部分。可能PM_V是PM模块中的一个子模块,专门处理电压监测或调节。 接下来,用户可能是在设计或调试回路板时遇到了这两个标识,需要明确它们的区别作用。比如,PM可能负责整体的电源分配保护,而PM_V可能负责具体的电压转换、稳压或电压监测功能。 需要进一步解释PM_V中的“V&rdquo;代表电压(Voltage),而PM是电源管理(Power Management)。因此,PM_V可能是电源管理模块中与电压相关的部分,比如电压转换、稳压、电压监测等。 另外,用户可能想知道这两个标识在硬件设计中的具体实现,比如PM_V是否包含DC-DC转换器、LDO稳压器、电压检测芯片等。同时,需要说明它们在回路板中的协作关系,比如PM模块如何与PM_V模块配合工作,确保电源的稳定可靠。 最后,需要确保回答清晰,分点说明PMPM_V的含义、作用、硬件实现以及它们之间的区别联系,帮助用户全面理解这两个标识在TBUS回路板中的具体意义。</think>**TBUS回路板中PMPM_V的含义解析** 在TBUS协议的回路板设计中,**PM**与**PM_V**是电源管理模块(Power Management)的细分标识,二者功能紧密关联但侧重点不同。以下是具体解析: ### 1. **PM(Power Management)** - **含义**:电源管理模块,负责回路板的电源分配、保护及状态监控。 - **核心作用**: - **多路隔离供电**:将总线24V电源转换为多路独立供电(如5V、3.3V),为不同功能模块(如通信芯片、MCU)提供隔离电源,防止干扰。 - **过流/过压保护**:通过电流检测芯片(如INA219)或比较器电路,实时监测各通道电流,当电流超过阈值时触发保护(如切断供电或报警)。 - **电源状态指示**:通过LED或GPIO接口输出电源状态(如正常、故障),供主控制器或上位机监控。 - **硬件实现**:通常包含DC-DC转换器、LDO稳压器、熔断器(PTC)、MOSFET开关及保护电路(如TVS二极管防浪涌)。 ### 2. **PM_V(Power Management - Voltage)** - **含义**:电源管理模块中的**电压专项子模块**,聚焦于电压的转换、稳压及监测。 - **核心作用**: - **电压转换**:将总线24V或隔离后的中间电压(如12V)转换为模块所需的工作电压(如5V、3.3V),通过DC-DC或LDO芯片实现。 - **稳压与滤波**:确保输出电压稳定(如±1%精度),通过电容滤波、反馈控制(如运放构成的稳压电路)减少纹波。 - **电压监测**:实时采集关键节点的电压值(如5V输出、3.3V输出),通过ADC芯片或MCU内置ADC外设转换为数字信号,供主控制器判断电源状态。 - **硬件实现**:通常包含DC-DC芯片(如LM2596)、LDO稳压器(如AMS1117)、电压检测芯片(如TLV431)及分压电阻网络。 ### 3. **PMPM_V的区别与协作** - **区别**: - PM是电源管理模块的**总称**,涵盖分配、保护、监控等全功能; - PM_V是PM模块中的**子模块**,专注于电压相关的转换、稳压与监测。 - **协作**: - PM模块通过PM_V实现电压的精准转换与稳压,同时通过电流检测、过压保护等功能保障电源安全; - PM_V的电压监测数据(如5V输出电压值)会反馈至PM模块,触发保护动作(如电压过低时报警)或调整稳压参数。 ### 总结 PM是TBUS回路板电源管理的核心模块,而PM_V是其专注于电压处理的子模块。二者协同工作,确保回路板电源的稳定、可靠与高效。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值