近来在公司内，被boss强制要求必须要画线框图，而且对线框图提出了诸多要求，包括：不允许添加图片和颜色，必须使用mockplus的形式，不能使用xd (Experience Design)的形式来制作，等。作为产品经理，在同事试用了多款工具后，更倾向于选择使用xd完成交互设计稿，而同事boss非常坚持，认为产品经理怎么能不画线框图呢？不画线框图你还是产品经理吗？“你这能叫线框图？”并当场百度，结果如下。

度娘给出的线框图：

我画出的交互稿：

确实感觉完全不是一个东东。而且知乎上搜索了一下，貌似很多同学对线框图的概念也不是特别清晰。所以，还是决定写篇文章来深入探讨一下到底什么是所谓的线框图。

WHAT?

首先让我们先来搞清楚线框图的概念，其实我们口中说的线框图的概念有点大。下面圈里面的东西都被我们称为线框图。而百度给出的应该是狭义上的线框图，即Wireframes。而线框也分为有链接跳转和交互的线框和流程线框。本文讨论的线框图是指包涵说明和流程跳转的线框图。

WHY?

那么，明确了线框的概念，再来看下到底为什么要画线框。（ps: 需要说明的是线框一般都是交互设计师完成的。作为创业公司的苦逼产品，交互设计自然要一个人负责到底啦）线框图的目的被整理为下面的几个：

Wireframes display site architecture visually （直观的展现站点结构 / APP结构）

Wireframes allow for clarification of website features  （定义站点功能）

Wireframes push usability to the forefront （将产品的可用性问题暴露出来）

Wireframes identify ease of updates （便于更新和修改）

Wireframes help make the design process iterative （使得设计过程相对独立）

Wireframes save time on the entire project  （为整个项目节省时间）

Experience shows it works （展现了产品如何实现它的价值）

那么是不是说在项目中只要能满足以上这些要求的任何工具都可以替代线框图呢？其实一直就有一些人认为线框图属于上古时代的东西，不应该继续沿用。理由整理如下：

Creation is a shared activity. Effective products and services require the involvement and communication of everybody in critiquing, evaluating and creating.  （线框图是单向沟通，绘制过程缺乏与团队的沟通，通常一个人在小黑屋里面画完，大家还有不同意见）

Create only what's necessary. You need just enough that will gather client or user feedback without bogging them down with unnecessary details.  （线框图是团队内部沟通工具，不是给客户作秀，没有必要的话自然要省略）

Create systems not pages. Approach and design for problems holistically instead of focusing on a single page. This allows us to create a series of modules that can be reused across the entire site.  （线框图是绘制页面，而不是完整的设计系统或模版，后者才是我们需要的）

Create as little waste as possible. Regardless of your role and who you work for, they're paying you to do one thing: ship something amazing. （老板和客户付钱是让你产出惊艳的作品的，而线框图则是一种浪费）

以上观点原文链接：http://www.creativebloq.com/netmag/why-wireframes-should-be-left-die-31411165

HOW？ whiteboard ->higher (middle) fidelity in mockups  -> Flow

OK，背景介绍的足够多了。那么到底需不需要绘制线框图呢？答案自然是：只有在需要的时候才绘制！我个人非常认同来自Adobe的产品大神Trip ODell的工作流程，即

白板 （没有白板的同学请选择纸和笔）

高（或中等）保真mockups

流程图

这个流程我个人也已经在多个团队试用过，效果不错，该讲清楚的基本都讲清楚了。至于线框图，在这个流程中是不存在的。

下面具体来讲一下这个流程。

第一步，讨论前的准备和思考，我会先在纸上画出来自脑海中和参考对象的几种方案（通常会有3种或更多），在思考过程中，我会将这些方案按照需求的背景和用户肖像及需求进行优先级的排序。

第二步，会议讨论期间，我会在白板上将我想到的方案画出来，并将参考对象指出。会议期间通常经过讨论和信息碰撞，可能会产生出更多的方案和细节的调整。最终会定稿一版方案（也可能犹豫不决的定了两版），而这版方案通常是在白板，笔记本和照片中的。在这个阶段中，一切能想到的细节都要进行充分的讨论。主流程中的一些边界条件也要列出并进行讨论。也包括功能实现的难度和可行性。任何遗留的细节都可能形成多米诺骨牌效应，导致整个方案被推翻。

第三步（非必要），将白板上的方案尽快制作成mockups，也就是上面图里面的Click Trough Prototypes（包含跳转和图片信息）。这个过程在使用恰当的工具的情况下是非常快的。因为方案的讨论已经在白板阶段完全解决了。高保真mockups的最大作用就是做用户调研和体验测试。如果要实现的界面和功能模块不需要做这些事情，mockups也可以省略直接进入流程图的第四步。

第四步，整理流程图。（流程图是将所有的界面平铺在一张图上，展示界面之间的跳转关系，并说明每个界面中的一些逻辑）这张流程图也充当了PRD文档的角色，在界面的旁边需要注明所有功能相关的逻辑和规则。这个文档也将用户测试案例的撰写和确定项目边界。

需要注意的是，在APP或网站的主流程中添加任何的页面都应该制作高保真原型(mockups / prototypes)，这些添加和修改应该通过基本的用户体验测试（因为它们至关重要，想想用户卡在你新加的界面上不知所措是多么糟糕的一件事情）。所以，在原型中，理论上已经包含了所有主流程中的界面和跳转。

所以，我个人的观点是，在项目流程中线框图并不是必须的。现代app和网站不是静态的，而是相对动态的布局和展示，所以传统的线框图会变成束缚而不是工具。

有人在帖子中提到，项目组需要有一个完全脱离设计元素的媒介，来纯粹的审视产品细节。Trip ODell提到，这个环节应该使用白板或纸笔在会议室中完成。这个过程即保持团队成员的高效沟通，使得所有想法和意见得到尽早的充分暴露，也可以完成快速的修改和调整。抓起板擦分分钟就可以完成的事情，是没必要到软件中进行修改的，在快速的讨论中，软件会变成束缚好想法的绳索，而不是帮助你拓宽思路和可能性的工具。这个流程在产品经理必读圣经，《启示录》，中也有提到。

Trip ODell将这个流程叫做“尽快从白板到原型”。这套流程他的团队使用了近10年，非常高效。

Trip ODell在Quora上的回答和讨论原始链接：https://www.quora.com/Whats-the-importantance-of-creating-wireframes-before-building-a-web-app

综上所述，如果你的团队已经养成了围绕线框图来完成产品设计的习惯，是时候尝试放弃它来让产品设计流程提速了。

不过，无论你是用什么工具，制作什么文档，确定并清楚的向团队说明这些文档的边界，作用和使用方法是非常重要的！

最后，简单介绍下我正在使用的工具：

完成制作高保真原型（第二部）我使用的是principle，它可以让你尽量完整真实的做出很多复杂的动态效果，可以在手机上把玩预览，也可以录制成视频分享给异地工作的开发同事快速了解主流程。备选工具Keynote。

完成流程图（PRD / 牵引图）的工具我推荐使用Sketch或者OmniGraffle。

你在工作中还在绘制线框图吗？你觉得它们有帮助吗？留言告诉我吧。

其他的一些关于线框图的讨论：

线框图设计绝没有你们想像的那么简单（中文贴）：https://zhuanlan.zhihu.com/p/20402307（主张使用OmniGraffle取代Axure回归页面本身）