介绍
去年我和团队开始了一个项目，第一个月之后，进度比较慢，不过初步文档也出来了，当时发生了一件事情，就是引入“高保真原型”，导致项目进入了近两个月的崩溃模式。
团队表示，他们在领导的首肯下引入了高保真UI设计，这种高保真的设计界面不仅能让用户知道他们的软件是什么样子的，还能让领导看到软件界面，让他们对自己的设计工作有更直接的认可。
。
这个东西我之前用AXure试过（有人说这个软件只是低保真，高保真才是Sketch这样的纯粹的UI设计工具）。这次我也换用了他们所谓的高保真，就是用UI工具把菜单按钮一个个逼真地画出来。
当我第一次看到结果时，我认为这种方法很好。它美观、直接、优雅。而且，我立刻就知道成品会是什么样子。我什么都不用想。外观已经存在。软件只是时间问题。
于是我开始用这种高保真度设计界面。一个月后，我发现了几个危险的问题。
首先是周期问题。一个小小的建议和调整，原本以为一个小时就够了，结果竟然……一两天，于是项目周期就开始无限延长了。
第二个问题是需求的满足，那些所谓的调整最后发现，并没有带来需求的改变，只是界面变丰富了，但是需求和功能没有任何提升。
第二个问题是功能解释的问题。如果对界面进行新的设计，虽然之前的功能设计和实现方法非常清晰，但界面设计总是很难达到预想的“效果”。我们感觉都在实现同一件事，但结果却不一样。
这个还不算什么大问题，最大的问题是到最后都不知道自己在干什么了，对于同一个界面，每个人理解都不一样（虽然都认为没什么区别，后面会讲到）。究其原因，还是没有主线思路和产品框架设计，没有深入理解功能和底层实现方法，所有界面都是虚构的、照搬同类项目，没有和底层算法逻辑直接对接，或者说前端设计师有太多非常简化的幻想，没有底层算法逻辑支撑的幻想。
嗯，有大事发生了！
什么是TMD高保真？
目前高保真原型设计尚无明确的定义，含义大概就是字面意思，就是在软件（功能）开发完成之前，通过与用户的沟通，清晰地画出并表达出软件期望实现的界面、交互方式，确定软件功能。
高保真应该是通过Axure或者Sketch等工具设计的软件的外观和相关功能，包括UI元素，UI风格，交互方式等。
据我了解，高保真可以提供三种类型的人机交互：
我们之所以采用高保真度是为了降低成本，包括研发成本、沟通成本。
为了降低研发成本，需要在一开始就确定软件最终的样子，这样在研发过程中就不会出现对需求理解的错误和偏差，也不会出现研发返工、对需求理解不透彻的问题。
降低沟通成本，就是把客户想要的东西做出来，让客户看到这个界面、这个使用流程，客户会根据这些实际的东西提出进一步的需求，从而加快需求的进度。
就这么简单，你相信吗？
高保真的想法有什么问题吗？
1.高保真会让你把产品设计误认为是外观或者交互设计。
这对于手机上的移动应用或网页应用来说，是可以接受的。这些应用的海量用户太多，操作要求简单易用，所以界面简单、清晰、直接最重要。要扩大范围，对于一些管理MIS系统，高逼真度也是可以接受的，毕竟有些领导不懂技术，甚至不懂系统的逻辑和脉络，需要一个简单易用的界面来了解系统。
但在工业软件产品的设计和开发中，如果一开始就追求高逼真度，那就麻烦了。如果所有模块都按照高逼真度设计，那简直是自找死路，因为它们最重要的不是它们的外观和交互，而是内部复杂的逻辑，以及如何将这些逻辑结合起来解决某个具体的问题。
说实话，漂亮的界面和交互方式都是锦上添花。我们后面有充足的时间来做这些，这也是在业务逻辑和核心内容完成后才做的。但如果没有产品的核心细节，那就不专业了。
因此我们必须开始把关注点从漂亮的界面转移，重新思考业务场景和实现流程，这才是最重要的。
2、高保真设计过分强调UI与交互设计的艺术性，而忽略了产品设计的内容。
产品规划与设计起着至关重要的作用，特别是行业软件规划，与互联网行业完全不同。
但无论哪个环节，产品规划和设计都是最重要的出发点，尤其行业软件，逻辑越复杂，界面就越不重要，没必要像互联网行业那样追求风格和美观。
产品经理的设计与实现思维决定了产品几乎一切，产品经理的领导力也是产品整体功能体系、功能模块设计、场景化应用流程等最关键问题的体现。
专业领域的界面设计是底层业务逻辑和算法的表达，这些才是UI设计的主要内容，而非艺术。如果底层算法设计师或产品经理没有把握好全局，任何专业化的功能设计都难以体现。做个花架也不是最坏的结果。最终，这种没有本质成果积累的事情，会把产品的发展方向、团队的能力方向引向另一条不归路。
反正高保真设计第一版出来之后，我慢慢发现原版的专业设计功能渐渐没了！为什么？因为这些专业功能由于业务壁垒，很难理解，尤其是对“领导”来说！
3.高保真忽略了具有一定复杂度的软件的迭代改进过程
如果你的软件已经有过研究经验，或者该类型软件已经是业界比较常见的软件作为参考，那么你就适合采用高保真原型设计，因为此时高保真资源消耗可以降到最低。
如果你的软件没有一个非常非常完整全面的前期设计，也没有可以100%复制的对象，你的全面高保真软件可能只是一个梦想。
此时的高保真设计，由于前期技术基础的不足，并不是基于对软件内部逻辑的分析，而是为了高保真而高保真。随后，软件功能细化过程中产生的冗余设计和返工，会随着高保真工作量的增加而被放大。所有错误的方向，都会对你后续的努力造成越来越大的自残。
4. 高保真度取悦了客户，但却放弃了软件本身的功能需求
高保真是一种和客户沟通的方法，但不是唯一的方法。我认为，框架、内容、呈现、细节优化是打造一个软件产品的必经阶段。
当有足够的时间和资金，或者绝对必要的时候，可以在最终的表现形式和细节优化中引入高保真，但无论如何，框架和内容永远、永远、永远是第一位的，你所有的注意力应该在这里，而不是高保真。
我们之所以倾向于使用高保真，是因为这个环节最贴近用户，能直接看到用户的看法，获得客户的直接认可。但一味的迎合客户，最终可能会把客户带入坑。
高保真背后可能隐藏的其他问题
1. 高保真度掩盖了专业能力下降的趋势
雷军说设计专业软件，有时候我们用战术上的勤奋来掩盖战略上的懒惰，这就是一个活生生的例子。
互联网产品，特别是手机产品，都说是高逼真度，但这未必适合油田应用。很大程度上，这种东西让你逃避了深入的思考，尤其是从产品整体架构、生态、生命周期的角度去思考，而这对于软件设计来说更是重要。是的，项目太忙了，思考就成了最稀缺的东西。
想好一个模块，我会拿起纸笔，或者在白板上画出软件架构、信息流、功能体系、界面，然后不断去实现、去完善。拿起笔设计专业软件，去修改，然后去写代码，去迭代、去演进……如果你辛苦画出了一个高保真的设计图，你会经常去调整它吗？你会经常去迭代它吗？
高保真会阻碍你的思考，导致你的专业分析能力下降。
2. 高保真度导致技术团队分裂
高保真的UI一般是纯软件开发者向行业需求分析和设计师提出的需求，这样简单的界面，IT开发人员不需要对业务逻辑有很深入的理解。
但目前石油行业的软件开发一般只能由具有很强业务背景的人员来完成，如果按照传统MIS软件和软件外包公司一样的要求进行分工，业务需求和功能实现就会割裂，这是行业软件最怕的。
当然，大多数人都认为这是明确责任的重要方式。不，事实上，当团队成员真正互相指责时，高保真是一个完美的借口（成员之间、团队之间、部门之间、公司之间）。
因为在我看来，大多数项目在设计开发初期，很难确定需求，如果一定要做，那你就用90%的精力去实现10%的内容，这是极其无利可图的。
UI设计必须高效，高保真必须严格把控！
经过这次血淋淋的经历，我对专业软件开发中的高保真有几点想法（结论）：
对于一个已经经过讨论有了想法的模块，如果你不能在30分钟内完成一份UI与交互设计规范，那么就已经是过度设计了。
晨会（或者敏捷讨论）确定的模块功能会立即实现，当天或者最迟第二天实现模块的原型。用最小原型实现高保真可能比画高保真更有效率。
当团队间对高保真有强烈的需求时，其实可能并不是真正的高保真问题，很可能是团队对项目的理解和功能设计没有做好，或者项目合作中存在恩怨（甚至！在所谓的“高保真”之争之下，还可能隐藏着团队间的血案）。
当客户对高保真度有强烈的要求时，似乎最大的可能性是客户还没想清楚自己想要实现什么，这时候应该先沟通项目理解和设计。
最后，一些结论和经验
高保真并不适合以功能为重点的专业软件。这是互联网产品设计的重要方式（没有专业的流程和业务框架，但用户的傻瓜式体验是首要的），但并不适合专业软件。因为专业软件的专业性和重要性在于解决关键问题，而不是让所有团队成员甚至“领导”都高兴。
高保真的另外一个不恰当之处就是花费了太多的时间在美化UI上，耗费了太多时间和精力在专业研发上，对大家的核心功能和专业软件的简洁性造成了巨大的影响。
高保真并不适合一个不断迭代更新的产品。高保真并不适合专业软件，尤其是需要不断迭代改进的专业软件。不断迭代升级是专业软件（或者所有工业软件）正常的成长过程。
高保真需求可能并不根植于软件界面。最后，当一个团队开始把希望寄托在高保真上时，很可能团队协作和管理出了问题。高保真成为大家暗中指责、攻击对方的手段，把所有的闹剧都掩盖起来，显得非常正义高尚。
因此，如果你正在制作专业软件，请务必大声喊出：
搞砸你的高保真音响！
