class="topic_img" alt=""/>
英文原文：Why Engineers build crappy products，looks like it was designed by an engineer
就像是工程师自己设计的产品
当你第一眼看到下面的用户界面时，你会尖叫出来，它一定是由工程师设计出来的。
via Daring Fireball User Interface of the Week
为什么会这样？对于工程或软件开发过程而言，是什么导致了用户实际不可能去使用的用户界面？
用户不满的完美风暴
简短版本：
成为擅长交际的人
http://youtu.be/RAY27NU1Jog
考虑一种新产品的过程，最初是想了解软件应该做什么，那么，就从定义问题的解决方案开始。这里有个假定，问题本身被正确地定下来了，但它经常不是这样的。这些需求经常体现为用户故事和线框图，它们定义了用户要做的事情和具体的界面，用户将借助该界面来完成那些目标。
这里有个隐藏的条件，对于技术能够做什么是理解的。有时候，尤其对于一种新颖技术方案的产品而言，技术能够做什么还无法完全了解。不管解决方案是否位于已知的问题领域，在开发产品的时候，常常会碰到不同的挑战。开发软件实际上是非常难的。
鉴于此，工程将注重设计，开始考虑解决方案的总体结构，在产品风险最大的地方应该精心组织他们的开发投入——这部分往往是技术上最有挑战的。如果我们借助原型或某种模拟界面使其运转，以证明这些地方功能正常，那么唯一搞明白的就是理清产品的剩余部分。
工程的不确定特性
到了有意思的环节。每个工程师都喜欢从头开发，因为他们可以探索而不必应对现有代码的折衷、约束和杂乱。这是一种探索的过程，一种能够探索一种技术空间可能性和潜力的过程。这真的很棒，让工程变得有趣的很大一部分。
从小的功能开发，用新颖的方式将其组合在一起，做出逐渐强大的东西。工程师可以接触带有不同功能的各种小物件，使得探索它能够实现所有功能变得更加容易。能够炫耀这些酷炫东西，从社交上是值得做的，除了它不能做什么，还有它能够做什么。关注这些技术层面，使得人们去优化各方面的功能。
陶醉于界面
Engineers Keeping it Real: Go Fuck Yourself
问题是产品不等同于技术。技术对于开发产品是必要的，却不是充分的。技术只是管道，使产品变得可能，但实际上不是人们关心的东西。
对潜力的陶醉与创建优雅产品相冲突，因为产品最重要的是做出选择，从非常复杂的地方创造出清晰明了的东西。这更像是迷失于森林之中；理想和抱负，两个方面的努力是直接矛盾的。
例子：我又做了一件蠢事
我们最近在开发一个产品，它使用 email 做为一种界面接触点（interface touch point）。当用户打算和另一名仅仅部分地设置了账户的用户交互时，现有的需求说明无法真正解释应该发生什么。我们只是在摆弄着一些东东，因此责备需求不明确是不公平的；因为在开发的时候，经常是这样，我们最终迷失在人们期望不到的杂乱中。
从边界情况的角度看，当关注于工程实现和基于能够实现的东西基础之上所开发的响应的健壮性时，我本能地开始构建能够处理这种情况的代码。它把松懈当做端点，在这种情况下，它做了一些更加聪明的事情，那么，email 应该也自然地做着更加聪明的事情。
我开始深入到能够存储那些将要排队的部分请求，便于将来在用户界面去处理。我开始创建一大堆功能，因为我正在考虑技术相关的东西，其它的界面有着“优雅”的地方，我想开发完整的东西。愚蠢慢慢地爬进了界面，因为我一直在搜寻一种技术上的解决方案。
这不是产品的核心。没有人真正关心过它。对于类似情况，答案真的不是过多的技术解决方案。我认为没有问题，但是技术解决方案不是解决问题的最有效方式。这实际上是设计方面的问题。
技术是简单的
如果团队之间协调不够，如果设计组“完成了”他们的工作，然后将东西抛给了工程组，那么将出现这种对话，工程组将针对“漏掉的、但是我们需要解决的地方”提出设计需求。它可以是漏掉的，但是它不需要被解决。在这种情况下，解决方案根本就没有“解决掉这个问题”，而是重新界定了这个问题。这种重新界定把问题放到了工程师所不希望的地方。这不是要建立用户能够解决的、一整套部分完工的请求队列系统，对于重要任务或不管什么任务给予报警，而只需让 email 界面简洁、并把用户跳转到网站的主流程里。
总之，工程师倾向于成为蹩脚的产品设计人员的原因在于：
— END —
译文： 《为什么工程师会造出蹩脚的产品 》 腊八粥
相关文章
