面对设计师或产品经理不合理的需求，程序员应该怎么办？

如果你是负责 UI 代码的工程师，那么你就应该尽自己最大的能力来实现设计师和产品经理的愿景。但与此同时，你并不只是生产机器中一个小小的齿轮。你是这个技术领域的专家，对细节有自己的思考和想法——你最清楚那些设计是如何落地的。

这意味着你的角色不仅仅是为向你指派的各个功能提供解决方案。有时候，你也应该站出来说不，或至少提供一些意见和选项，让产品团队可以做出更具战略眼光的决策，这是很合情合理的。

业务价值就是一切

所有企业都希望创造价值并赚取利润。这句话并不带有价值判断。因为商业的本质就是这样，团队协作产生价值，而金钱仅仅是衡量这些价值的工具。

创造价值的关键是从战略层面有效分配资源。作为工程师，你在某些任务上投入的时间不仅是总成本池的一部分，也会不断消耗你自己在任务期限前的剩余时间。如果你的公司是资源有限的初创企业，那么这些分配决策可能会直接影响你们的成败。即使你身处一家大型组织，诸如是否率先打开新市场这样的决策也会决定整个产品项目的未来。

因此，产品经理的职责就是始终以尽可能产生最大业务价值的方式分配资源。为了做到这一点，他们需要了解有哪些可行的选项。

业务需要你的见解

这时候，轮到你出来了。作为一名工程师，你能充分了解在实现由设计和产品团队创建的用户体验时，都会涉及哪些内容。

当然，某些产品人员可能具有技术背景，但你毕竟是开发人员，每天面对的都是代码，所以你肯定有某种一线层面的独特见解。

因此，如果产品团队想要做出明智决定，那么肯定需要你分享这些见解。换句话说，你的工作不仅是提供估计数字，并不惜一切代价推进开发工作。你的职责还包括估计各种情况、考虑各类需求的后果、并提供更快速或者更好地完成团队目标的替代路径（至少有时需要这样做）。

“像素级的完美”—并非总是最佳状态

考虑一个例子。也许你在一个团队中工作，这个团队坚持的原则就是对设计师提供的 UI 原型做出“像素级”的完美实现。实际上，坚持像素级完美是这个团队的骄傲，任何偏差都被标记为需要尽快解决的 UI 错误。

这听起来像是一项可以带来高价值的政策，并且大多数时候的确如此。但在某些情况下，你真的应该走一条不一样的道路。

曾几何时，我就在这样的团队中工作，有一次领导要我更正的一个 UI 错误就属于这种类型。那是一个 iOS 应用，其中导航栏两侧的按钮距屏幕边缘正好 20 像素。

这个需求背后的想法是合理的。设计师希望所有视觉元素对齐，以使内容周围的空白看上去感觉一致且自然。问题在于，他不仅要将这一规则应用于标准按钮，而且还要应用于后退箭头。

如你所见，后退箭头实际上比其他按钮更靠近屏幕边缘一点。并且箭头旁边的文字也没有与其他什么东西精确对齐，而那位设计师认为这是不可接受的。

但是，这里正确的决定是不改变任何事情。这就是表达异议，并解释具体原因的时候了。

你也知道，当时（现在也可能如此）调整这种特殊按钮的间距有点复杂。它是 iOS SDK 的标准 UI 组件的一部分，并且属于苹果并不完全鼓励开发者定制的细节类型。

因此，对其进行定制会带来很多意想不到的复杂性和风险。一方面，它花费的时间比设计师的预期要长得多。这不仅仅是要调整设置，还涉及到与系统标准对抗的一套程序。

此外，需要对这个应用中所有导航栏都进行这种更改，有的情况下还有其他布局代码在运行，这种更改就可能会引入意外行为。更进一步，这种更改还增加了质量检查团队的测试时间，总而言之，这些时间加起来不是一个小数字。

换句话说，这件事可以做到，不是特别“困难”。但这根本不是我们真正需要花那么多时间来做的事情。它没有提供任何业务价值，实际上还可能带来负面价值，因为它与用户在其设备上几乎所有其他应用中看到的后退箭头的位置都不一样。那么，为什么要给自己找这么一堆麻烦呢？

为他人提供各种选项

现在，你可能会认为，取代产品经理的角色并监管设计需求并不属于你的职责范围。你甚至可能根本就没有太多关于设计决策的发言权，而只能听从那些专家的设计选项。在大多数情况下，你都是正确的，我也很同意。

但这里说的并非让你来做出设计决策。这里说的是让你再确认一遍，确保那些选项的确是设计专家在了解所有情况后依旧会做出的决定。

当他们开始设定需求时，他们可能从未想到过像按钮间距这样简单的事情会如此麻烦，更不用说它还会带来那么多其他形式的风险。因此，告诉他们那些宝贵的信息，才能让他们做出的任何决定都会尽可能符合现实情况。

同样，他们可能会希望使用其他一些功能来代替某个价值较低的组件，或者他们可能希望省出时间来优先处理更重要的功能，尽量避免延期风险。你的意见可以帮助他们做出能带来更理想产品成果的决策，而当你为他们提供选项时，你的身份就是他们的合作伙伴。

诚恳友好地给出选项

提供这些选项的方式也很重要。你绝对不会想要被人看作是“根本不明白设计”的杠精工程师。

为避免这种情况，你需要避免说出这种工程师味道的发言：由于技术原因，X 无法完成，具体原因说了你也不懂。”为了避免这种尴尬，你需要以任何非技术人员都可以轻松理解的方式向对方传达信息。

这说起来容易，做起来难。事实证明，设计师或产品经理实际上不需要了解技术细节也能重新考虑他们的要求。他们只需要了解对他们而言最重要的取舍：用户体验和业务价值。

为了以这种方式解决问题，请试着以下列方式来表达意见：

1. 实现成本：即使你只是一名初级工程师，你的时间也是很昂贵的。在上面的间距示例中，设计师或项目经理实际上不太可能为如此简单的要求预料到会有如此高的成本。你可以向他们解释，这个小东西实际上会占用 X 个小时的开发时间（原本预计不超过几分钟），这可能就足够他们改变主意了。

2. 测试成本：除工程成本外，每一项要求都增加了质量检查团队所花费的时间，毕竟他们需要确保体验符合产品标准。间距调整不仅会影响一个功能，还会影响整个应用的所有页面，这意味着在回归测试期间需要执行的步骤多了很多。这些投入值得吗？你可以告诉产品团队新增步骤的具体数据，让他们更清楚不同决策背后的成本。

3. UX 风险：当你引入与系统对抗的需求时（例如，间距调整），它也引入了在意外情况下出现各种奇怪行为的可能性。例如，当导航控制器是某些视图控制器的子级时，也许实现间距的方式会使按钮完全不在预期位置上。你可以做个列表，列出这类更改可能会导致的各种问题，告诉对方这些问题为什么会降低或破坏用户体验，并在以后修复时需要付出更大的代价。

4. 交付风险：同样，增加的任何复杂性也会增加可能无法及时交付功能的风险。如果你在很多小事情上花费的时间都比预期要多，那么完成项目的时间和资源预算就会被吃光，团队就会落后。你可以解释这种风险可能会严重到什么程度，并让产品团队决定这种代价是否值得。

请注意，以上所有内容都用不着让非技术人员了解复杂性或风险背后的技术细节。相反，重点在于量化风险的方式，并澄清此类风险的定性含义。无论如何，你提供的数据是为了让设计和产品专家更好地发挥其专业能力，而非为了拒绝要求搞出来的看似高深的偷懒理由。

顺便说一下，这套流程适用于各种大小设计要素和功能。不管 UI 决策是否会给项目增加几个小时的成本或一整个冲刺的时间，对工程师来说，关键都在于做好沟通，这样产品团队才能给出正确的生产需求。

平衡反馈与公司文化

公司和公司当然不能一概而论。一些人欢迎和鼓励开发人员的这种反馈，而另一些人则持不同的态度。你的反馈可能一开始会被误解为对设计的批评，并且总会有人自负而敏感。你提供的任何反馈意见都应先考虑到你所在公司的文化和与你一起工作的同事心态。

换句话说，如果你处在一个欢迎跨职能协作并鼓励坦诚相待的环境中，那么这种反馈对于团队的成功就是很有利的。你的反馈让你的团队能更清晰透明地认识现实，从而提升了交付最佳成果的可能性。只要你能认真而富有建设性地提供反馈意见，你就可以真正从工程师中脱颖而出，被视为真正注重成果的团队伙伴。

原文链接：

https://triplebyte.com/blog/-is-that-button-spacing-worth-it-how-and-when-engineers-should-push-back-on-design/?ref=rddtpost