线框图被产品经理奉为圭臬，但对设计师而言，线框图的存在则是面目模糊。在整个产品设计流程里，线框图是一种很好的产品工具，而不是一个可行的 UX 设计和 UI 设计工具。
前 Google 设计师 Alex Socoloff 在推特上说：“Unpopular opinion: Low-fi wireframes are just a waste of time.”，意思是“非主流的观点：（产品设计过程中的）低保真线框图就是浪费时间”。
我赞同这个说法。
作为设计顾问和设计专家，我都建议客户（中小企业、创业公司为主）的设计师不要依赖线框图做设计，而是让设计师从产品需求阶段就提前参与到流程里，在充分理解产品逻辑的前提下，把 PM 的产品逻辑线框图直接转化为基于真实数据的、中等保真的设计稿。
使用线框图的常识
在整个产品设计流程里，线框图是一种很好的产品工具，而不是一个可行的 UX 设计和 UI 设计工具。或者换句话说，代表产品逻辑的线框图通常是必要的、有效的，而代表设计稿的低保真线框图往往作用很有限。
线框图一般有三种用法：
- 一是作为思考工具。线框图原本可以用于确认产品逻辑、用户界面、用户使用流程，很遗憾现在太多团队用错了线框图，用 PM 的产品逻辑的线框图、代替了设计师的用户界面和用户使用流程线框图
- 二是作为沟通工具、协作工具，分阶段地讨论设计。在复杂的项目里，在多方参与的综合项目里，在内部竞争异常激烈的大公司里，线框图都是必须的沟通工具、协作工具，但后面还需要很多轮细化、优化…一点一点完善，光是照着线框图开会（掰持）的时间，就够快速行动的小团队做死几个产品了
- 三是作为最简陋的产品原型，来获取用户反馈。线框图特别是低保真线框图颗粒度太粗，线框图形式的“产品原型”很容易误导用户
“教科书式”的线框图使用方法
以 2B 的产品举例。
2B 的产品经理，确认产品设计的流程比较长，特别是多数 2B 产品买单的老板、提需求的管理层、实际使用产品的员工…这些人出发点、想法都不同，所以产品部门的 PM 会用产品逻辑线框图和其他各种图表、文档，来阶段性、层层递进地交付产品需求。
再由设计部门的设计师来阶段性、层层递进地交付低保真线框图、低保真设计稿、中保真设计稿、高保真设计稿、互动原型，逐步把代表产品逻辑的线框图，转化为代表最终产品的设计稿、互动原型。
这种渐进的流程，可以逐步细化、逐步获取反馈。所以它是一般产品设计里最常用的流程。
使用“教科书式”线框图的误区
很多团队忽视了传统“教科书式”线框图的限制，在使用中反而造成了问题。
失真的风险
渐进的线框图、设计稿，分摊了用户/客户反馈的风险，但同时增加了线框图到低保真设计、高保真设计、产品原型、测试产品之间的风险。通俗地说，用户/客户并不见得理解线框图，那些对线框图十分满意的客户，看到产品原型之后说翻脸就翻脸。
这种情况在需求多变、用户角色众多、合作方众多的项目里，基本上就是家常便饭。
从 PM、设计师的角度而言，很难用增加设计轮次的方法来减少失真。减少这些失真的主要思路，是尽可能用真实数据、做近乎真实的产品设计，减少使用概念性的、抽象的产品设计。
混淆产品逻辑和 UX 设计、UI 设计
很多小公司、小团队会模仿大公司的流程：PM 先出线框图，再找 UX 设计师、UI 设计师“美化”线框图。但因为小团队分工不会太细，PM 输出的线框图很难说是产品逻辑线框图、还是 UI 设计草稿；如果下游的 UX 设计师、UI 设计师水平有限，PM 往往就通过产品逻辑线框图定义了 UX 设计和 UI 设计。
PM 是 UX 设计和 UI 设计的外行，这就导致了这种产品设计流程从根子上就是反用户、反体验甚至是反常识的，白白浪费了 UX、UI 设计师的专业技能，浪费所有人的时间。
避免这种问题的常用方法，就是前面我建议的：让设计师从产品需求阶段就提前参与到产品设计中，用跨部门、跨流程的协作来减少沟通成本、试错成本，最终提高产品设计的整体效率。
不必要的成本支出
现在有 Figma 之类非常强大的设计工具，可以极低成本低实现交互原型，很多以前需要滞后到开发之前才能提交的产品原型，现在在产品需求阶段就可以低成本实现。
很多产品团队已经在利用 Figma 们缩短流程，而 Figma 越来越偏向项目管理、偏向工程化，也强迫设计师去进一步提高使用 Figma 的效率，把单纯的设计工具扩展为设计管理工具，以便进一步提高整体产品设计效率。
怎么跳过低保真线框图
举例说一下，怎么跳过低保真线框图。
以前我在公司任职和自己创业阶段，做过很多年产品总监，负责产品和设计团队，工作中我其实经常会画打引号的“线框图”。
我在项目中的身份，通常既是产品总监又是设计专家，这样导致我设计线框图时，会不断切换身份、切换视角，最终输出一个既符合产品逻辑、又满足 UX 和 UI 设计要求的线框图。根据项目本身所处阶段、产品设计的侧重点，我输出的“线框图”可能是纸面、白板上的手绘草图，可能是 Axure 风格的传统线框图，也可能是已完成初步 UI 设计的设计稿；一般我都会说清楚，这个“线框图”是代表逻辑还是代表设计，然后分别交给 PM 和设计师跟进。
这里我用到了两个技巧：
- 提高沟通效率。因为我一个人横跨了产品、设计两个流程，充分理解产品逻辑、充分满足 UX 和 UI 设计要求，所以我可以直接跳过用于 PM 和设计师协作的低保真线框图。很多身兼产品、设计、开发多个身份的独立开发者，事实上也是这么操作。
- 减少沟通误差。同时，因为我是产品负责人，需要利用线框图和设计稿来主导整个产品流程，我会在设计中尽可能使用真实数据，尽可能提高设计的真实性，以此减少沟通中的误差。
普通产品设计团队，也可以在产品设计流程中使用上面两个技巧：
- 提高沟通效率。普通团队一般不会横跨产品、设计两个流程，更实际的做法是增加产品和设计两个流程的重叠。也就是让设计师尽早介入产品设计流程、把设计任务尽可能前置，帮助设计师提前理解产品逻辑，跳过低保真线框图、提前出设计稿。
- 减少沟通误差。设计师基于真实数据做中等保真的设计稿，避免概念性的、抽象的产品设计带来的沟通误差。
别照本宣科地使用线框图。
在使用线框图之前，先根据自己的产品特点、团队特点，想清楚怎么使用线框图。
和所有设计工具一样，效果取决于用法。线框图的最终效果，还是看你有没有用正确的方法、解决正确的问题。
