设计 | 重新认识线框图

线框图被产品经理奉为圭臬,但对设计师而言,线框图的存在则是面目模糊。在整个产品设计流程里,线框图是一种很好的产品工具,而不是一个可行的 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 和设计师协作的低保真线框图。很多身兼产品、设计、开发多个身份的独立开发者,事实上也是这么操作。
  • 减少沟通误差。同时,因为我是产品负责人,需要利用线框图和设计稿来主导整个产品流程,我会在设计中尽可能使用真实数据,尽可能提高设计的真实性,以此减少沟通中的误差。

普通产品设计团队,也可以在产品设计流程中使用上面两个技巧:

  • 提高沟通效率。普通团队一般不会横跨产品、设计两个流程,更实际的做法是增加产品和设计两个流程的重叠。也就是让设计师尽早介入产品设计流程、把设计任务尽可能前置,帮助设计师提前理解产品逻辑,跳过低保真线框图、提前出设计稿。
  • 减少沟通误差。设计师基于真实数据做中等保真的设计稿,避免概念性的、抽象的产品设计带来的沟通误差。

别照本宣科地使用线框图。

在使用线框图之前,先根据自己的产品特点、团队特点,想清楚怎么使用线框图。

和所有设计工具一样,效果取决于用法。线框图的最终效果,还是看你有没有用正确的方法、解决正确的问题。

Author picture

倪爽设计顾问,倪爽设计工作室

Scroll to Top