我桌上放着一张照片，今天终于找到它的灵感出处了😂 照片其实是从杂志上剪下来的广告，来自很久很久之前的 2006 年，被我特意从国内带来了美国。 照片里超现实主义的大眼睛小朋友，手上抓着当时刚上市的 Canon 相机。 灵感出处是 1970 年的海报，未来主义的大眼睛模特，手上抓着 Kodak 相机。Kodak 在日本叫做 Kako？有意思。 抄袭太 low 了，复刻 30 年前的东西就对啦😂👏 和 Gen Z 那种挂在嘴边的“怀旧”不同，复刻、再现、重制几十年前的设计，是设计中常见的一个设计思路、创意方法。 …… 后续：今天（2024年）离 Canon 复刻 Kodak 已经过去小二十年，是时候再复刻一次了。这次直接用 Midjourney 生成图片就完事啦。

前两天有一篇关于线框图（Wireframe）的文章，“Wireframes are useless”（线框图无用）。这篇文章在 Medium 上获得了超过 1K 的鼓掌。 一般设计圈子里共鸣最多的文章，多半要么是情绪化的、正邪对立的、语不惊人死不休的，比如“设计师不需要学习编程”，要么就是浮想联翩的、牵强附会的、无病呻吟没话找话说的，比如“开国元勋教会我的 10 个想法”。 难得这篇热门文章让我产生很多共鸣。 说说这篇文章，也说说应该怎么阅读设计类文章。 “线框图无用”这篇文章表达了什么？ 文章作者是设计公司的联合创始人兼产品设计师，公司业务是数字产品设计，即帮助客户设计网站、APP。他们公司最近四年都没有使用线框图，而且并没有因此对客户、设计团队产生不良影响。 作者说的线框图是指表达 UI 设计意图的“高保真”线框图，而一般产品经理画的那种面如死灰的线框图，他们称之为“草图”。 文章分两大块： Part 1，UI 线框图的四大争议 线框图帮助我们对策略和内容相关问题做决策 他们把产品决策和视觉设计上的决策分离，让产品决策先行，而后用产品决策指导视觉设计。如果过早设计 UI 线框图，会尝试更多、更快，让事情变复杂。 线框图帮我们早期测试产品理论 想法挺好，但是用户无法从线框图体验易读性、色彩、人机工学等等产品可用性体验，无法把线框图转化为使用体验。 线框图加速设计流程 20 年前这么说没错，但是今天我们有 Sketch、Figma、Adobe XD……可以方便地创造产品原型。何苦还要再设计 UI 线框图？ 线框图防止你讨论审美观 其实面对干巴巴的线框图，我们还是会讨论审美观！而且在今天的产品设计里，如果撇开互动设计和视觉风格谈设计，也很难洞察技术实现、信息架构、用户体验。 Part 2，远离 UI 线框图的注意事项 设计流程 现代的数字设计、产品设计并没有完结之日，产品设计也会经过不断优化。所以他们选择了跳过 UI 线框图、从第一天开始真实地做设计，而后不断优化。 设计技能 摆脱 UI 线框图做设计，要求设计师同时考虑交互、信息架构、视觉表现等不同要素，实际上要求设计师具备不同技能 很有意思的一篇文章，我的概括不足以表达完整的意思，请自行前往阅读。 怎么阅读一篇设计文章？ 最近十几年，我每天坚持阅读设计类的文章。另外平时做家务、休息时，我也听设计类播客、看设计类视频。因为我的设计理念，也因为我同时为国内和北美客户做设计，所以现在我日常阅读、收听、观看的内容基本是英文的。 读设计类文章有很多种方法，以今天推荐的这篇文章为例，说说合理阅读设计类文章的几个方法。 读它，不要扫描它 用户从来不阅读、用户只会扫描内容。设计师应该像专业人士一样阅读专业文章，不能把自己当做消费内容的一般用户。只读标题、只扫描不阅读、只流水式阅读而不思考…这些读法最后都没有鸟用。 今天推荐这篇文章很典型，标题很惊悚、但内容很理性。如果你只是读标题，或者草草扫过照片和大标题，你很可能会曲解作者的真实观点和建议。 阅读这样的设计文章时，一边读、一边思考、一边和自己的工作结合，往往是最有效的阅读方法。 明确文章的背景和语境 平时我们说的设计，常常不是同一个“设计”。 设计涵盖面很广，品牌设计、用户体验设计、视觉设计、产品设计…基本上是完全不同的工作。设计师的身份也有很多种，有 Agency / 设计公司的、有 In House / 公司内设计团队的、还有 Freelancer / 自由职业的。设计师也有各自分工，比如初级设计师和美工差不多，设计主管一会儿做设计、一会儿做管理，而设计总监不一定动手做具体设计。 如果抛开这些背景和语境，按照自己的设计师身份读文章，结果也会鸡同鸭讲。 比如今天推荐的文章来自设计总监级别的设计师，说的是网站和 APP 这类产品设计领域，作者来自 Agency / 设计公司，介绍的是整体的策略和思路，而不是具体的某某操作方法。 如果你是 in house 的交互设计师，很可能你觉得作者在扯淡。 多思考，少站队，别急于表达 专业设计师和设计外行、设计爱好者相比，最大的不同是什么？ 外行点评优缺点，爱好者提建议，专业设计师确定问题并给出解决方案。 作为专业设计师，我们阅读的目的是学习，那些脱口而出的“我觉得”，不但缺乏价值，而且往往自贬身价。 比如今天推荐的文章里，作者很明确地阐述了他们所谓的“线框图”，是特指高保真的 UI 线框图。如果你不花点时间，想清楚这种线框图和 PM 画的线框图有什么差异，估计你也很难理解他说的到底是什么。 我为什么难得对这篇文章有共鸣？ 其实很简单：感同身受。 我的以前做了很久的产品总监，现在的身份是设计顾问，类似于设计总监。我的工作室是 Agency / 设计公司，在帮助客户解决设计问题过程中，我也有类似的流程和方法。 作为产品经理，我当然会画线框图，方便和同事交流；但作为设计师，我从来没有画过 UI 线框图。 One More Thing 原文作者没说清楚讨论 UI 线框图的几个重要前提。 UI 设计环节里，线框图到底解决什么问题？ 传统而言，UI 设计环节里的线框图，最主要的作用是展示页面排版。通常 UI 设计上游部门的产品经理或者运营人员，会用更简单的线框图，来表示页面里需要哪些内容。 UI 设计师会按照易用性、审美等原则，对内容进行排版。比如设计一个 Landing Page，头图有多高、配多大的文字；产品介绍放在第几屏、需要占满几屏；用户反馈模块是多个小块、还是一整块自动切换？ 现在做产品设计，到底是谁在设计 UI 线框图？ 以往的 UI 线框图当然是 UI 设计师负责，它们往往是创意和视觉表现的第一步。 而 202X 年的现在，设计团队越来越多地采用数据驱动、目标驱动的方式做产品设计；特定场景的 UI 设计、UX 设计，也有各种确定的设计模式；设计系统的普及，让控件级别的 UI 设计完全标准化，模块级别、页面级别的 UI 设计也趋于标准化… 这些变化导致 UI 线框图的工作，往设计流程的上游转移。 比如设计一个 Landing Page，运营部门的人可以按照原始策划、加上 Landing Page 特定的设计模式、再套用公司已有的设计系统，自己设计出一个有效也不乏基本可用性和美感的设计稿，而且往往比 UI 设计师的 UI 线框图更符合业务需求。 UI 线框图方法的一大缺点：脱离真实数据 拿 Lorem ipsum 做 UI 设计会导致很大的误差，UI 线框图本身也有误差，两种误差叠加起来，UI 线框图的准确性就不得而知了。 比如还是设计 Landing Page，UI 线框图里设计了全屏幕的大型头图，用于展示客户案例；但是拿到真实数据和素材后才发现，没有高清大图；这就出现了尴尬的问题：在客户重新拍摄高清大图之前，是修改 UI 设计、还是拿形象不佳的小图临时充数？ 每个设计团队的工作流程各有不同，理解这些重要前提，可以帮助设计总监、设计师理解 UI 线框图在自己团队里的意义。

如果你有管理设计师的经验，或者经常和设计师合作，你会发现一个痛苦的规律：多数设计师虽然有想法，但是其实不会思考。 如果你是需要独立处理问题的设计师，处理设计需求的过程中，也经常会遇到“头脑一片空白”的窘迫，完全不知道从何下手。 怎么才能帮助设计师、设计团队思考？ 设计领域有几个常见的设计思维框架，能帮助设计师、设计团队思考，比如英国设计协会的 Discover、Define、Develop、Deliver 4D 模型 / “双菱形模型”；比如 IDEO 的 HCD 模型：听到（Hear）、创建（Create）、交付（Deliver）。 今天推荐另一个设计思维的框架，来自 Spotify 设计团队的文章：从直觉到计划：深思熟虑的执行框架（From Gut to Plan: The Thoughtful Execution Framework）。 作者是 Spotify 资深产品设计师，介绍了他们的设计执行框架。分为几大步骤： Spotify 的设计框架和其他框架的整体思路相似，不过更偏向于实施，或者说更务实。 按照我的经验，Spotify 这个思考框架，更适合互联网公司的 in house 设计团队，适合处理产品设计、UX / 用户体验设计这些领域的设计问题；英国设计协会、IDEO 的框架更适合设计公司这种 agency 性质的设计团队，适合处理更宽泛领域的设计问题。 作者提供了这个思考框架的 PDF 版：下载地址 设计师一般欠缺分析和推理能力，靠直觉、本能做设计。 这一方面需要设计师具备极其丰富的经验，或者说需要积累成百上千的设计模式，来“本能”地找到合适设计方案。这对多数设计师而言根本不现实，特别是在 UX 设计领域，UX 设计不但横跨了用户体验与设计等不同领域，还必须与产品、技术团队紧密协作，单凭个人经验做设计，“本能”的结果会很狭隘。 另一方面，依赖直觉、本能做设计，往往会偏重于设计方法、而脱离真实的问题，最后变成用正确的工具、正确的方法、解决错误的问题、得到毫无价值的结果。 到任何一个公司里看一下，真正能解决问题的，是那些说“我再想想”、“我研究一下”的设计师，而不是第一时间抢着说“我知道”的人。 IDEO 和 Spotify 们的设计框架，可以帮助设计师学习如何思考。 Spotify 设计执行框架里，最后一步“学习”也是设计师往往欠缺的技能。 很多设计师只关心假设和设计，把设计初期的目标、分析、确定问题和机遇这几步，以及设计完成后的总结，都当做事务性工作丢给总监和主管完成。 如果不回头学习每个设计中的成功和失败经验，设计师就只能学到方法、而很难学到经验了。 现在国外大厂都喜欢推自己的设计团队网站，Spotify 算是内容比较丰富、同时也不那么自恋的一家，推荐阅读。 一般公司大到一定程度，做人就比做事更重要，所以很多公司的设计师、主管和总监就喜欢写高大上的文章。相比之下，Spotify 设计团队更务实，不像很多大公司的设计团队喜欢写那些虚头巴脑东西。 设计师肯定要学会包装自己、学会写更大的文章烘托自己的价值。不过作为读者，我当然更喜欢读 Spotify 的文章 Spotify 设计团队的网站：https://spotify.design/

客户做面向美国市场的家居产品，宣传品由国内团队设计、感觉不满意，希望我来改进设计。 看完他们现有设计之后，我发现他们的设计各种不美国： 浣熊也叫 Trash Panda，直译是垃圾熊猫。在美国的文化里，浣熊经常就是那个在垃圾箱里翻垃圾的小东西。换成别的产品，也许能使用浣熊卡通、二了吧唧的形象，但是 Trash Panda 这个联想显然不太适合以安全、卫生、舒适为基本特征的家居产品。 文化差异、习俗差异、各种约定俗成的差异，是面向美国用户做设计最大的难点。设计语言、设计风格也是一大障碍，脱离美国消费者喜好的设计肯定不合适。 PS：这位客户和国内其他出海产品相比，他们设计上有一大优点：文案比较好。虽然有些说法和美国人有差别，不过比国内厂商那些硬翻译的奇怪英语好太多了。 为美国用户做设计的实用建议 设计师想突破文化差异，最好的方法是尽可能地尝试外国文化。比如： 设计师想学习国外的设计风格，最好的方式是多参考、多练习。比如： 以上说的每个建议，单列出来都不难，放在一起就变成了几乎无法完成的任务。 怎么破解？ 花时间一项一项解决，一次吃一小块，连续吃五年。 大部分设计师，可能觉得反正没机会为外国用户做设计，何苦多学那么多？ 这就犯了设计师的大忌：狭隘！ 国际化无可避免，跨文化设计技能将越来越有价值。 而且中国地域辽阔、人口众多，北京人、重庆人、四平人之间的文化差异不亚于外国人，学会跨文化设计技能，你将能为中国任何城市的人做出优质设计。

先说结论：使用中文的 Twitter 用户，周活跃用户大约有 10~25 万人。 注：我的工作是设计顾问，需要直接帮助企业做决策，所以本文的目标读者首先是老板们，然后是企业里负责市场、产品、运营的同行们。我专长在中小企业和创业公司领域，本文适合这类企业，或者大公司里的独立运营的小项目。阅读难度：入门。 我们拿不到让瑞幸咖啡崩盘的那种数据 大家应该都看过浑水调查瑞幸的数据了。 数据的重要性不必多言，老板们善于解读经营报表，对市场调查数据敏感，哪怕看似直觉的快速决策，往往也建立在历史经验数据基础上。在一个完美世界里，我们有无限的资本和无限的时间，当然是像浑水公司那样花钱采集数据最专业啦！ 但是很遗憾，中小企业和大公司的独立项目买不起这么贵的数据。 大部分情况下，我们需要借助极其有限的资料，来估算数据，并利用估算结果来做出经营决策，比如品牌定位、产品定位、营销投放预算等等。 全世界一共有多少位钢琴调音师？ 中小企业和独立项目经营中，经常会面对缺少参考值、范围很含糊、只能依靠估算来测算的奇怪问题。比如我们要估算一个城市需要多少咖啡师。 ”全世界一共有多少位钢琴调音师“这个怪问题，曾经是谷歌的产品经理面试题，这种需要估算的问题称为”费米问题“（Fermi problem），类似问题还有”宇宙里有多少智能文明“。 评估类似问题的方法来自著名物理学家恩里科·费米（Enrico Fermi），也就是著名的”撒了一把纸屑就推算出原子弹爆炸当量“的那位神奇的费米。 费米的估算方法不同于麦肯锡们的正规调查方法，甚至直觉上也不符合基本的统计学，但在有限条件下，费米方法是最快、最有效获取一手数据的方法。 怎么快速估算 Twitter 的活跃用户？ 既然是估算，不奇怪，我也用了费米的方法。（注：忽略了简体中文、繁体中文用户带来的差异，忽略了水军带来的差异，原因就不解释了） 初始数据 首先我们需要找到初始数据、参考值。我选择了 Twitter 的 #（Hashtag、关键词）功能来获取初始数据。 最近 Twitter 上的中文用户正在拿 #我为什么来推特 这个关键词，来讨论玩 Twitter 的理由，通过 Twitter 的搜索功能，可以找到有多少用户参与了 #我为什么来推特 的讨论。（点这里查看原始资料） 第一轮估算：用几个小时的数据，估算一天的数据 我手工数了有多少条推包括了 #我为什么来推特 这个关键词。 因为我很忙，身边也没有实习生和志愿者，所以我的计数只覆盖了几个小时。我拿这个原始数字，根据每小时 Twitter 用户的活跃度，估算出 1 天之内有多少人参与了这个关键词。 估算结果：第一天有 2000-5000 人参与了 #我为什么来推特 这个关键词。 图例：每小时 Twitter 用户活跃数（微博的数据与之相似） 第二轮估算：寻找话题半衰期的起始点 Twitter 和微博一样，话题都有半衰期，我怎么知道话题是什么时候开始的？（我怎么知道我计数时数的是第几天的数据？） 这里的估算依据是罗杰斯的创新扩散模型，因为我是活跃的 Twitter 用户，我看到 #我为什么来推特 这个关键词的时间，应该就是话题出现的第一天。 第三轮估算：用一天的数据，估算一周的数据 按照以往的观察，Twitter 上一个热门的中文话题，相关的讨论大约能持续 2-3 天。 这个数据有点不符合直觉，毕竟 Twitter 和微博类似，都是内容快速更迭的社交网站。注：实际上整个 Twitter 的话题半衰期，大约是 2 小时。 按照这个信息衰减的速度，我估计第一天的活跃讨论总数，是一周内所有讨论数量的 1/5。 估算结果：第一周有 10000-25000 人参与 #我为什么来推特 这个关键词。 第四轮估算：用参与用户的数量，推算活跃用户的数量 这个估算比较简单，社交网站上发布内容的用户，一般不会超过 10%，所谓”沉默的大多数“。 我们就简单一点，拿上面的一周数据乘以 10 吧。 估算结果：使用中文的 Twitter 用户，周活跃用户大约有 10~25 万人。 图例：沉默的大多数 估算的数据有多可靠？ 按照我和客户们的经验，在早期决策阶段，特别是品牌策略、产品策略这些阶段，如果数据的误差不超过一个数量级，就足以帮助企业做出决策。 而且！我们不是 MBA 出来的、咨询公司范儿的青年才俊，我们不喜欢纸上谈兵纯理论的事。 正常情况下，我们都会拿估算的数据，和已有的真实数据交叉对比。通过互相验证、寻找不同数据的相似性，来快速提高估算数据的准确度。 整理的真实数据可以是经营数据，也可能是市场调研、用户访谈、同行交流的结果。 如果估算的数据、上个月的报表、街头访谈的小姐姐都说不爱喝咖啡，同行的老王上次也说他在咖啡上没赚到钱……那么我们肯定不会在咖啡领域投钱了。 后话 以上是一个小时快速写的短文，数据基于心算。而且我不是数据专家，我的初衷是向我各位客户老板们汇报我的工作方法。 实际操作中，我们并不会像上文那么粗略地估计。比如我们会请实习生采集更多数据，比如我们会去查找比对 Twitter 的历史数据，比如我们会拿初步分析的毛数据，和客户一起快速筛选和细化。 在品牌定位这种实际场景下，基于估算的数据分析可能会持续 1-2 周。估算得到的数据，能让我们的在无法进行定量分析的情况下，得到更多的决策依据。 欢迎大家留言一起交流，或者直接联系我，我们一起来帮您的品牌和产品估算数据。

我提交的设计几乎没有低级错误，客户们都很喜欢我这个优点。 低级错误是指那些无关设计技巧的、很容易避免的错误。比如：错别字，没有对齐，设计前后不一致，图片模糊。 这里有个真实例子。我给 X 总公司做设计顾问，我先交付设计好的 PPT 模板，X 总的设计师再按照实际场景，把模板修改为实际的 PPT。修改之后，X 总的设计师提交了一个充斥低级错误的 PPT 文档，本来很正常的一个设计，一下子出现了山寨的感觉。 出现低级错误时，设计师往往觉得很委屈：时间太紧张啊，甲方给的稿子就有错误啊，从来没做过这种设计啊，这只是小样、不是最终稿啊 – 反正都是别人的错。设计 PPT 时出现低级错误，设计师会更有理由：Power Point 软件和 PS、AI 都不一样，很难使用啊。（很难自圆其说吧？我用了超级弱鸡的 keynote 来设计 PPT 模板，鸟软件难用得想吐……那我也没出错啊。） 遇到低级错误，客户不会想到什么委屈不委屈，客户会觉得：这个设计师，要么不细心（个人素质不行）、要么不认真（工作态度不行）。 素质和态度的问题，谁也帮不了你。但是作为经验丰富的商业设计师，我来分享5个工作技巧，帮助设计师避免低级错误： 遇到低级错误，客户不会想到什么委屈不委屈，客户会觉得：这个设计师，要么不细心（个人素质不行）、要么不认真（工作态度不行）。 1，合理安排时间，避免忙中出错 1小时完成3小时的工作量，不出错就怪了。设计师应该学会提前安排时间，遇到时间太紧张的、时间和其他工作有冲突的，应该试着和主管、客户协商，争取更充裕的时间。 比如我曾遇到一个很困难的任务，要按照英文校对稿、修改一本多种语言混杂的专业书籍。因为这种工作很艰涩，很容易出错，虽然它只有2小时的工作量，我申请了2天的时间去完成它。 2，建立任务清单，增加工作条理，帮你远离混沌 设计师（尤其是偏艺术、偏视觉的）一般以思维发散、做事情缺逻辑“见长”，工作起来没什么条理。这时候就可以用上人类文明发展这么多年的一大牛B产物 – 清单！设计师可以把设计中一定需要考虑的问题，列成几个清单，打印出来贴在电脑边，设计时查对清单，避免遗漏。 比如我做 UI 设计时，脑子里其实有一个清单：每个元素、组件，我都会设计它的缺省状态、空状态、出错状态、极限状态。如果我处理了文字太长、导致换行的极限状态，那么我就不会搞出文字换行顶乱界面的低级错误。 3，养成自我检查好习惯，充分利用无需动脑的肌肉记忆 为什么你可以不看着键盘盲打？为什么天黑了你也不会把饭吃进鼻孔？因为这些是肌肉记忆，不需要动脑，下意识就能完成。在设计过程中不断自我检查、自我纠错，是避免低级错误的基本技巧，如果你反复练习、养成了自我纠错的好习惯，那么不管任务多复杂、时间都紧张，你都可以利用已经形成的肌肉记忆，随时启动自动纠错。 我大概工作1、2年之后，就形成了有用的肌肉记忆，来帮我下意识地自我纠错。（俗称“脑子里始终有根弦”） 4，减少干扰因素，避免分心 这个不用多解释了，每个设计师都向往不受干扰的安静环境。现实中，办公室总是很嘈杂，两三个市场部的碧池，说话声就能打乱全公司所有人的思绪。设计师也特别希望工作时间能连续、不被打断。而现实中，设计工作总会被打断。有个别没素质的人，不但随便占用设计师的时间，还直接用油油的手指戳设计师的屏幕，我操，人神共愤。 我从来都是戴着耳机工作。坚决不用 QQ、微信聊天。不着急的 mail 就等一下再回复。以前我在 MySpace 工作时，公司里有个视频直播用的小黑屋，隔音、隔光，有时候我就溜进去工作，效率超高。 5，学会校对 设计师都是活人，是人就会出错。不管设计时你有多细心、多专注，设计结束之前，务必再重新校对一遍。特别是设计师身体状态欠佳时，更需要仔细校对。比如我，如果遇到那种半夜2、3点，累得眼睛发花、肚子饿死、太阳穴砰砰跳的情况，越累就越容易出错，这时候我就多校对一遍。 如果一个 team 里有多个设计师，设计师之间也可以相互校对。人都有思维定式、有思维盲区，换个人来校对，小伙伴往往能一眼看出你忽视的小错误。 “不出错”，这不仅是一个设计师的口碑，它也影响设计的效率。如果没有低级错误，我们就不必成天查漏补缺，满世界擦屁股，我们可以把有限的时间，用在优化策略、增加表现力、提高转化率这些更重要的设计工作上，帮客户创造更多价值。 多用一些技巧，多花一点心思，你也可以避免设计中的低级错误。

苹果公司前员工，在 YouTube 上曝光了 iPhone 早期的两款原型机：一款采用了类似 iPod 的虚拟转轮设计，另一款则是今天小 baby 也会使用的触控图标设计。（ 详细介绍在这里 ） 照片中就是这2款原型，简陋到令人发指！很难想象，iPhone 这么伟大的设计，10年间改变了整个世界，而所有的惊心动魄，都来自这两个卑微的原型。 看到这张照片，我立即想起产品设计圈子里一个长久的争论：做产品设计，高保真、低保真……哪种原型比较好？ 答案很直接：我在产品设计中坚持使用高保真原型，你也应该这么做！ 你对高保真原型的理解是错误的！ 一般产品团队，不同成员会按工作流程，逐级输出原型：PM 出“低保真”线框图，UI 设计师出静态的“中保真”页面，交互设计师出可操作、有动效的“高保真”原型……大家会用视觉、交互的细节，来衡量原型的保真程度。呃，这种工作流程里，每个人交付的是……其实是产品设计文档，而不是原型。 所谓原型（Prototype），它的作用是在产品上线之前，提前验证产品需求、产品设计是否合理。一个“高保真”的原型，必须能准确传递设计意图、能帮助测试者判断设计是否合理。 以上面的照片为例：第一代 iPhone 选择人机交互模型的阶段，原型的核心作用，是让乔布斯们模拟用户身份，通过实际操作，来选择一种基本的人机交互方式。这两个界面简陋到想哭，但它们都是经典的“高保真”原型：能操作，能区分两种操作的不同效果 – 它们不但准确传递了设计意图，而且能帮助测试者判断设计是否合理。 我想这个选择过程应该不难 – 原型1是二级操作，用滚轮控制菜单，相当于酷炫版的方向键，累赘；原型2是一级操作，点到什么就执行什么，直接。乔布斯们通过这两个原型作出了正确的选择。 为什么产品设计中应该避免低保真原型？ 在一个完美世界里，从 PM 到设计师到老板，每个人都准确地知道产品需求是什么、产品设计是否合理，每一个决策都有数据和经验做支撑，每一个设计都经过仔细考量，每一个人都会花大量时间去阅读文档，开发团队准确实现了每一个产品功能……而在现实生活中，呵呵，你见过多少人仔细读文档？你以为那么多需求变更是怎么出现的？你以为产品上线之后才痛改基本逻辑的情况很罕见？ 所以，正常的产品团队，会在几个关键节点上，利用准确的高保真原型，来预估需求和设计是否合理。 低保真原型，因为它的不准确，导致测试结果不可靠，非常容易对产品设计产生误导。尤其是那种外观精致、操作华美，但是不准确的所谓“高保真”原型，很容易把所有人带进沟里。 怎么做才能输出高保真原型？ 在设计产品原型过程中，PM、设计师应该分清楚文档和原型的差别 – 文档传递明确的需求，原型传递待定的问题。设计高保真原型的最基本要点，是清晰地界定目前遇到的问题。 还是拿照片里的 iPhone 一代原型机举例：这个阶段的问题是“不知道哪种人机交互方式更合适”，而不是“哪种人机交互最好看”。 设计高保真原型的另一个要点，是让原型简单、直观。 产品原型的受众，通常是决策者，或者是真实用户，这两类人并不会了解产品的整个框架、逻辑、流程和规则。如果你制作一个复杂的原型，评估原型的人很可能会被带入某一个细节的沟里 – 古人早说过了，这叫“盲人摸象”。 小结 产品原型的目的是验证产品需求、产品设计是否合理 一个“高保真”的原型，能准确传递设计意图、能帮助测试者判断设计是否合理 不准确的“低保真”原型会产生误导 文档传递明确的需求，原型传递待定的问题 保持产品原型简单、直观 1月19日更新： 这篇文章原来只是我的个人项目的一部分，没想到放到知乎之后，会有很多人关注。 为了谢谢大家，我把 iPhone 早期的两款原型机背后的故事（八卦）给补上。如果你不介意读英文，完整的故事在这里：Tony Fadell tells us the story of the iPod-based iPhone prototype 上面照片里的两款原型机，你猜测乔布斯支持哪一款？- 他支持左边那种违反直觉、最后被无情抛弃的虚拟 iPod 转轮界面。其实这也可以理解，在十年前，那个 iPod 主宰世界的年代， iPod 转轮是一个很直觉、很好用的交互方式。据说乔布斯还花了不少心思（伎俩），坚持推进这个转轮界面。 但是，乔布斯不是拍脑袋的2B领导，他安排工程师、设计师研究了各种可能的原型设计。同时参与选型的，还有其他各种能想到的原型机，包括小屏幕 + 虚拟转轮设计，以及实体转轮 + 实体按钮设计。感谢上帝，乔布斯最后的选择造就了我们今天看到的 iPhone。 另一个八卦是右边这种触摸屏设计。这是 Scott Forstall 团队开发的手机 OS，也就是今天的 iOS，这个 OS 基于苹果电脑的 OS X 操作系统，把那么庞大、复杂的电脑操作系统，塞进一个初期的原型机，很困难吧？所以最初的原型测试中，团队并没有把 OS X 移植进原型机，而是在 Mac 上模拟了效果。 最后说一个八卦，主导 iOS 开发的 Scott Forstall，也就是和乔布斯共同缔造了“拟物化”设计语言的那个人，在乔布斯过世之后，因为各种原因被 Jonathan Ive 取代。Jonathan Ive 在手机操作界面上最显著的贡献，就是“扁平化”设计风格 – 一个由工业设计师倡导的、得到平面设计师追捧的、以小清新征服年轻人的、“分不清标题、正文和链接”的 UI 设计语言。

以后我会在“设计”栏目里，介绍关于设计的好文章，分享关于设计的想法。 今天介绍的是 Facebook 产品设计 VP Julie Zhuo 的文章：What You See is What You Use 。Julie Zhuo 是个很好的作者，她总能用很小的故事，传达设计的深思。 文章从 Julie Zhuo 住处说起，楼上有漂亮的天台、楼下有同等漂亮的平台，大家都喜欢在楼下的平台呆着，因为它显而易见，每天你都能看到它。同样的，手机顶部把信息折叠起来的“汉堡包”导航，可用性远不如直白的手机底部导航条。Julie Zhuo 建议设计师让信息显而易见，别让用户费力寻找信息。 我非常赞同这个观点。这是可用性（Usability）设计的一个基本点：Visibility of system status（10 Usability Heuristics for User Interface Design）。 比如我负责客户 H 先生的网站设计时，按照同样的原则修改了导航栏。最初 PM 给出的导航栏设计，把二级频道折叠、同时展开了用户个人信息，这样的设计看起来很简洁。但是我改成了展开二级频道、同时折叠了不常用的用户个人信息，这样的设计易于使用，当然也就增加了二级频道的访问量。 这个话题还有个更好的例子 – 消费类无反相机，总是用 menu 键、Fn 键藏起很多不常用的功能，而专业单反相机，浑身排满了密密麻麻的按钮 – 前者看起来蛮优雅，符合设计师的情趣，但是后者……如果你是专业摄影师，或者像我这样喜欢从来不关相机、随时准备抓拍，这种按钮随手可得、按一下就能调整设置的相机，真是好用到想哭。