《产品炊事班的小账本》2017年4月刊
本文约1.5万字，阅读60分钟，思考1星期；解答了27个产品/交互设计的常见疑问。
问题一：如何理解模态？
何时应该使用模态？模态和阻断有什么区别？
Hozin的回答：
模态对话框(Modal DialogueBox) ，阻断(Blocking），都有明确的解释，欢迎自己搜索，为了理解这两个词儿，大家一起来练习个绕口令。
模态=管制刀具；
阻断=杀人凶器；
管制刀具不一定是杀人凶器（可以用来切菜）；
模态不一定是阻断的（可以是非阻断的强制提醒）；
杀人凶器可以是管制刀具；
阻断可以由模态来完成；
杀人凶器不一定是管制刀具（毒药、板砖也可以）；
阻断不一定是模态（非模态、强制跳转也可以）；
关于模态，知乎上有个文章，分析的很形象：
交互设计中什么情况下适合用弹窗？什么情况下适合新页面打开？什么情况下适合新页面覆盖？
问题二：表单内容靠左靠右问题？
如图，看了多数app 这种表单内容文字都是靠右侧，可是为什么我感觉靠左侧更快捷阅读呢？
Hozin的回答：
经典问题，以下最优视觉扫描路径分析
问题三：资深交互设计师和普通交互设计师的差别是什么？
Hozin的回答：
1.理解信息架构，看清楚交互的本质
2.基于信息架构提供多样化设计
3.合理强奸用户，达到商业转化
问题四：交互设计前景如何？
从【前端开发岗位】转成【交互设计岗位】难不难？
Hozin的回答：
正在整理答案，发现提问不见了，不知道小密圈是什么机制，也希望那位提问者能看到本内容。
前端开发是一种结果明确的工作；交互设计是一种结果不明确的工作；实际上所有的设计工作都是结果不确定的。
Hozin写过前端（Hozin.com曾经是手工维护），并且固执的认为HTML开发人员才是真正的网页设计师。
因为Hozin学习HTML的时候，经常访问网页设计师:web标准教程及推广,网站重构,XHTML+CSS,CSS布局,DIV+CSS,validator,mozilla firefox
HTML本身就是一种信息架构，前端开发人员学习交互设计非常容易！
希望前端人员掌握交互设计技能，也希望交互设计都掌握HTML知识。
一个优秀的前端开发人员不应该转做交互设计岗位，基于以下两点：
1.交互设计师的定位尴尬
在国内，视觉、交互、动效、用研，可能都被交互设计师这个职位包揽了；
大量院校设置的交互设计专业本质上都是HCI，而不是Interaction。
100个公司对交互设计有100种认知，工作状态完全是【看脸吃饭】。
2.市场需求量
前端工程师需求量非常旺盛，薪水起点也很高；
交互设计师需求量一般，大量培训机构把滞销的UI设计师也包装成交互设计人才；
前端开发人员正确的职业转型是这样的：
1.轻松的把Web端交互技能掌握，在从事前端工作同时，多进行设计实践
2.转型Web端（后端）基础产品职位，学习产品设计工作技能（业务分析为主）
3.面向供应链、进销存、BI等偏后台方向，成为优秀的产品经理
全栈前端工程师也可直接转型技术管理类职位。
问题五：学习交互设计有必要出国吗？
我15年本科毕业，最近收到了代尔夫特交互设计研究生的offer，却非常纠结。之前我对工作不满意，于是辞职申了国外的研究生。申请完后马上找了新工作。很喜欢目前的工作，作为交互设计师还能做用研、产品的工作，还有好些厉害的前辈指导。我觉得这个工作能够让我实现「成为产品设计师」的目标。如果放弃它，付出很高的时间、金钱、职业发展成本去留学，收获的知识，不说全部，起码大部分在国内工作也能学到吧？留学是否值得？而出国，我觉得可能会更快地提升思维和视野。而且之前也是花了挺大精力准备，一旦放弃日后就不太可能再去了。想问下交互老法师怎么看，留学还是工作？
Hozin的回答：
兼听则明，偏信则暗，以下乃一家之言，仅供参考。
1.明确区分IxD和HCI
如果是在互联网公司，那你现在从事的应该是IxD，而不是HCI；
外行可能觉得【交互设计】和【人机交互】差不多，内行会觉得差异非常大；
Hozin的专业领域是IxD，对HCI只知道一些皮毛而已；
代尔夫特提供的学习机会是哪一个领域？请先分清楚！
2.关于代尔夫特
手边刚好有一本来自这个学院的书籍，感觉非常靠谱；侧面证明了他们的教学实践体系非常健全。
一句话，机会很难得！
如果10年前有这种机会，Hozin毫不犹豫就去了（教育背景对30岁以后非常有用）。
荷兰学校，语言是否会成为障碍？
3.IxD学院派
前几天刚看了国内某著名IxD领域教授公布的教学大纲，出现“因特网电子商务”等落伍的字眼；
所以，国内的这些真的不必读……闭门造车，与实践严重脱节；
最近刮起一阵北美留学UX硅谷淘金的风潮，呵呵，呵呵，呵呵
欧洲的设计专业和北美区别比较大！
欧洲人有严谨的专业精神，北美相对比较懒惰（这也是为什么硅谷大量的华人雇员）；
国内IxD学术领域，目测是向北美这边靠拢的；
目前没有一家美国互联网公司在国内风生水起（好吧，除了亚马逊）；
学院派要考虑一下就业，学以致用。
4.绕不过去的实践
教育心理学当中，布鲁姆教育目标分为6类：知道、领会、应用、分析、综合、评价；
根据这个理论，设计类专业几乎一定要通过实践赋能，只看书，只听课，木有卵用；
设计界，通过大量实践，野生出来的行业专家很多；
一定要搞清楚代尔夫特的实践教学是怎样的。
5.出国深造，还是留在国内野生？
具体要看家庭背景和个人目标，自己选吧
只提醒一点：出国深造，也许回国就业会水土不服，最终选择移民可能性比较大。
所以你面临的是选择未来的生活方式，而不是一份学业。
请多咨询家人的建议！
5.为什么一定学这个专业？
IxD这个概念是1999年才提出来的，属于交叉学科，只有不到20的积淀，未来不明确；
HCI的历史就不清楚了，请自己检索。
如果出国深造，应该选择一个更通用的专业领域，比如心理学、计算科学、产品（工业）设计等，方便未来就业。
以上就是Hozin要对你说的，何去何从，自己选择哦
问题六：交互设计是在未来需要提升的能力有哪些？
现在无论是web还是移动端交互组件已经很成熟了，作为交互设计师要怎么证明自己的价值呢，今后要提升的能力是什么呢？
Hozin的回答：
的确，web端和移动端的交互组件已经很成熟，但熟练掌握这些【常识】的人，少之又少，很多著名大公司的产品依然有低级错误。
交互设计师的价值
1.让【常识】真的普及
至少跑通流程和易用性
2.梳理和维护私有规范和标准
规范和标准是关乎成本的大事情
3.合理创新
组件成熟不等于无法创新，只是创新难了
交互设计师需要提升的是对信息架构的认知和使用
比如【同形异构】和【同构异形】问题
高阶的交互设计人员已经开始转向信息架构师，马上就来到。
问题七：产品设计师是做什么的？
之前也听过一些言论说以后UI和交互都会像产品设计师的职位转型，请问产品设计师是什么职位？具体做什么呢？产品经理+设计师么？
Hozin的回答：
对【产品经理】这个职位，大家是有误解的
很多新人以为刚毕业就可以做【经理】了，高高大上啊，别做梦了！好伐~~~~
Manager和Management差异很大，市面上招聘JD中的【产品经理】有一些是【产品设计师】，有一些是真正的【经理】。
换句话：产品设计师=俗话说的“产品经理”
真正【经理级别】的【产品设计师】是【产品线经理】或者【产品负责人】
很多公司根本没有【产品经理】这个职位！
正常的职业发展规划通常是这样的：
实习生>产品助理>产品设计师>高级产品设计师>产品线负责人（经理）>产品总监>产品VP
很多公司会将产品人员划分为技能/管理，两个不同的发展通道，又会细分不同的发展线路，请看下图吧。
问题八：有关于页面布局有好的文章和好书推荐吗？
Hozin的回答：
布局，来源于围棋术语。感谢汉语言文化的博大精深，让这个词充满了各种玄学，以至于很多情况下，不得不用更精确的英文去解释。
布局，翻译成英文有如下：
Layout偏重表现层面，甚至UI视觉最终的完稿，这个过程也可以叫Layout；
Distribution偏重逻辑散布，一步一步的划分为多个完全不想容的领域；
Partition偏重空间分配，比如室内装饰设计中的生活分区；
问题当中的“布局”姑且理解为：界面设计中如何划分区域和摆放组件。
提到布局，就要涉及另外两个词：栅格Grids和模式Patterns
问题当中的“布局”，更确切的翻译应该是Grids Layout
用google搜索Grids Layout会有很多线索！
为了精确的回答这个问题，Hozin会避免回答两个问题：
1.如何确定一个界面应该有什么内容
2.如何选定交互框架，各种交互框架的利弊
下面提供一些布局的具体学习资料
1.Web端布局，标准屏幕，屏幕复杂度
Hozin写过一篇文章《页面线框图教程（之二）：画地为牢的框架设计》
（页面线框图教程（之二）：画地为牢的框架设计 | HoZiN | 产品思维_信息架构_交互设计）
2.Web当中的“栏位”
Web界面可以无线向下延展，高度不重要，宽度重要！
因此Web Grids会按照宽度分纵栏，通常会有两栏、三栏、四栏；五栏及以上很罕见。
为了适应常见分栏，Grids系统的n值通常会选取一些公约数，比如12、16、20
2011年国外已经有人把892种栏位分配都列全了，请看回复贴图（还有个PDF一会贴出来）或者下面的地址
链接：(The 892 unique ways to partition a 3 x 4 grid)
如果不是瀑布流WaterFall,通常横栏之间的分配是有韵律的比如342或者3234
3.基于Web实现
不会CSS的设计师，不是真正的Web设计师，Google搜索 CSS Grids会有很多线索
比如下面这些代码例子
(Grid by Example - Usage examples of CSS Grid Layout)
4.布局与模式的关系
这俩没有直接关系，但是有很强的关联，很多常用模式本身（特别是Framework）就是布局的一种。
5.响应式布局
给出一个专门搜集响应式网站的地方，很多案例，请自己总结
链接： (Media Queries)
6.移动APP几乎不存在布局问题
屏幕空间比较小，各种模式已经成熟惯用，几乎不存在【布局】问题。左右分栏和瀑布流，在移动端都会很悲剧。
不存在布局问题，不代表不使用Grids系统
比如8pt栅格，链接： (了解8pt栅格系统，快速而统一地完成界面布局)
7.学习书籍：主要是基于平面构成和版式设计
无论是交互设计师还是视觉设计师，强烈推荐去看印刷排版方面的著作，Hozin有很多本，只拍了身边留着的一本给大家看看。
常用设计技巧是“对角线”请看下图
推荐Book#14《秩序之美》这本书，介绍了Grids Layout的具体用法
问题九：标签与分类是一样的吗，什么场景下使用分类，什么场景下使用标签？
Hozin的回答：
知乎上关于标签和分类的问题：
Hozin的答案：分类如姓，标签如衣。再赠送另外一个东西“群组”
分类和姓氏一样，每个人只有唯一的，如图
标签和衣服一样，每个人可以穿很多，并且天天换，如图
分类是一种强关联，具有约束条件；标签是一种弱关联，无拘无束。
分类是一层一层的树状结构；标签是一种无层级的网状结构。
强关联和弱关联可以混搭共存，并不矛盾如
分类几乎没有扩展性，大家都不会单独使用分类。
分类是随时可以添加标签的哦！标签也是可以随时添加分类的哦！
总之，强烈建议使用标签！！！因为分类能做的事情，标签也能做！！
有一种标签的变体，就是群组，用【关系表】实现，也是经常用的。
问题十：请问一下网站交互设计模式书中提到的“上下文”要怎么理解？
Hozin的回答：
本答案仅在小密圈内部交流，因为可能存在一些学术争议。
学院派，北美留学硅谷淘金的孩子们，可能看了本答案会BlaBlaBla的甩一些洋文，实在不想撕逼了。
《网站交互设计模式》书中所提的“上下文”英文为Context
以下四个单词，在交互设计领域非常容易混淆，因为它们都可以翻译为【场景】
Scene/Scenario Situation Story Context
为了相对严谨的回答这个问题，Hozin搜索了一些有趣的文章片段。
这些英文段落都是UX领域的文章，都存在这四个词在文章里同时出现。
链接：（english.stackexchange.com）
链接：Using Scenarios | UX think（uxthink.wordpress.com/2）
特别是下面这句文献当中的段落
In this scenario the context is not only thestage for the interaction scene. it is part of the interaction itself (Pederson2006). JOURNALOFIA.
好，下面来Hozin对这四个【场景】的理解
Scene/Scenario来源于戏剧，是通过想象创造或还原出来的。一些设想（假设)，或者架空现实的场面，应该翻译为【情景】比较准确。
Situation偏重强调真实存在、客观事实，应翻译为【真实场景】
Story偏重叙事连贯性，并且一定有人物的存在；Story在开发领域等同于业务用例，应翻译为【用户场景】，或者干脆翻译成【用例】
Context偏重于局部实现，具体到交互设计就是内容与内容的关系，界面与界面的关系，表单与表单的关系，应翻译为【使用场景】或者【上下文】
好~~~最后，从实战的角度出发，只要你遇到这四个单词，或者遇到【上下文】，不需要特别的去研究，把它们统统理解成中文的【场景】就好啦（除非你是写论文，做学问）
提醒大家，凡是用中文【场景】写交互设计、用户体验、服务体验、产品设计的文章和书籍，绝大部份都是在【赶时髦】，可以当成读物看个消遣，不要太当真哦。
问题十一：在具体设计一个产品的过程中，把握住哪些关键点才能让整个产品有着一致的交互体验，或者交互模式？比如iOS端和android端，比如web端和移动端？
Hozin的回答：
一致性，在交互设计中非常重要！保持交互一致性，有两个武器：原则Principles和规范Standards；规范又有两个层面：指南Guidelines和规格Specifications
四者的关系如[图01]所示，下面分解举例。
1.原则Principles
一些指导性的东西，在设计当中要遵从。在整个产品（无论多少端，多少子产品）都要遵守的。
举例：一个界面完成一个任务；表单超过10项必须分步骤；用户必须随时能回到主界面……这些原则可以由不同的形式来实现，但必须遵从这些原则。
2.规范Standards
具体来说就是指南和规格的合集，所以请继续参考下面的
3.指南Guidelines
圈定具体的交互模式、色彩搭配和设计禁忌。在这个层面，一个[构]可以有多个[形]，但某个形只能有一个[构]，达到相同位置、相同外观、相同操作。通过指南能够让各个端（IOS和安卓）看起来似曾相识，便于用户学习和养成习惯。
举例：在没有左侧导航的详情界面，必须包含面包屑；面包屑只能出现在PC浏览器端，不允许出现在响应式web界面中。
IOS和安卓的官方Guidelines就是这样的东西，但也可视情况制定私有的指南，也就是各个公司自己的设计指南。
4.规格Specifications
规格非常具体的秒数了每一个模式的每一个形态的具体尺寸、色彩、响应，精确到数值。
举例：一级标题，字号为宋体 18pt；行高30pt；行上下外距为5pt；色值为#CC9300。
你或许知道IOS和安卓的Guidelines，但那只是一个对外的版本。你必须相信，在真正设计IOS系统界面、苹果官方网站的时候，存在一个苹果公司内部的极其严格的Spec，而对外公布的所谓Guidelines只是整个严格Spec的阉割版本，给予开发者的参考罢了。
Spec的意义是保证某一个端的某一个版本，其内部交互设计达到精确到数值层面的一致。实际上已经是一份精确到代码、素材层面的设计规范。
以上，当你看到一份设计规范的时候，你要明白，那些精确到数值和代码的都是Spec范畴；那些只给了一些框架、搭配建议、禁忌的只是一份Guidelines而已。
附赠一个资料《如何建立一套 UI 设计规范？》
问题十二： 知乎付费的时候为什么不允许跨号支付，跨号支付会存在什么风险 ？
Hozin的回答：
为了反洗钱和金融安全，银监会出台了一列网上支付的规定，所以支付相关功能是非常典型的专业化产品线路：皮肤科的大夫治不了心脏病！支付产品的核心就是合规，有一些功能实现很简单，但是金融政策是有限制的，这也是为什么一张支付牌照叫价几个亿的原因。
作为支付产品的非专业人员，特意咨询了一大圈专门搞支付的朋友，首先有一个结论：【朋友代付】功能不涉及到支付【合规】问题；理论上知乎是可以开发相关功能的。
知乎为什么暂时不提供【朋友代付】呢？基于以下几点原因
1.账号运营支撑和安全考虑
最早的一批知乎用户是用Email注册的，即有一大批知乎用户可能是非实名用户；如果A账号被盗用，冒充朋友邀请B账号帮助支付，这种风险可能会发生，并且追溯起来很难。有【朋友代付】功能的产品都会有一个限定：某用户发起邀请其他人代付，必须自己也开通过支付，绑定过银行卡（这样保证发起者也是实名的）
2.场景问题，金额太小
朋友之间代付，需要一些场景支持，核心可能是支付额度。与购物平台不同，知乎上的支付几乎都是小额，几元钱、几十元不等，如此小的金额，朋友代付的需求非常弱；同理，微信红包的上限是200元，也不会存在让朋友代付红包的功能。
3.核心转化阶段
一个功能上线必然要有运营数据支持，参与支付的用户比例，每天的线上流水，都还没有达到一定水平，此时上线朋友代付是没有任何意义的。
问题十三： 目标阅读用户是开发人员，如何写出一份好的交互文档呢？
Hozin的回答：
《如何写一份通俗易懂的交互文档》知乎的几个答案都靠谱
如果前端开发也算开发，那么Hozin也曾经是一个开发人员。
程序员几乎不看文档，不喜欢看，也懒得看！作为一个用户，大家在注册知乎、微信的时候会去查看《用户注册协议》的内容么？
既然程序员不喜欢看文档，那么Ta们如何获取需求呢？
1.他们喜欢看最终效果，即UI视觉设计，或者静态HTML（也不喜欢看原型）
2.他们希望通过面对面沟通需求，而不是【浪费时间看文档】
开发小组工作的场景是这样的：
A程序员感觉对需求把握不准，转回身问【老大】：文档上这个地方是要写死还是可配置的啊？【老大回答】：可以单独配置。
所以，一个开发小组当中，可能只有一个工程师仔细看过文档而已，其他工程师通过他的口述复习需求。
既然程序员不看文档，那么文档的意义何在呢？
1.文档主要是写给测试人员，他们要通过文档写测试用例，保证实现的功能和文档需求一样
2.文档是设计人员与开发人员之间的工作协定，是一种责任备忘，写的越详细越好
3.当然，视觉设计师和动效设计师也会根据文档配合开展工作
文档只是需求沟通的一部分，文档之外当面澄清需求，解答开发人员的疑问才是关键核心，一份文档【三分写，七分讲】；讲解能力是设计师必备的技能。
针对知乎上的答案，如果交互设计文档是专门写给开发人员的，Hozin补充三点：
1.不要做什么动效啊，动态面板之类的东西
程序员不喜欢探索你的那些动效，请直接平铺出来链接路径，触发什么动作，然后goto某某其他界面
2.尽量用表格描述，别写段落
比如权限分配，各种状态切换，如果是用文字叙述，几百字都说不清楚；用表格，三五行就解决，一目了然。
3.如果你也懂研发，直接给术语和数据结构
使用程序员熟悉的话语方式，他们更乐于接受！如果可以，把数据字典列出来，表单的每一项（包含隐藏项）格式、限值、校验规则、错误提示；能给出UML参考更好。
码农和产品设计人员，是一对欢喜冤家，好像夫妻之间，需要多磨合，而不仅是一纸没有法律漏洞的协议。
问题十四：
- 如何提升挖掘商业需求的能力？
- 商业需求到信息架构这一步，如何去梳理？
背景：今天在吃饭用美团付款的时候，听到餐厅老板的抱怨，很有意思！老板说，顾客都来我店里消费了，但顾客用美团消费，我不仅得到的钱少了，最后还得给美团提成。然后引导我用微信转私帐给他！有人说，今年的风口是新零售，像便利峰、盒马鲜生、京东也实施开500万便利店的计划；由此想到这是不是真的是一个机遇。
Hozin的回答：
三言两语，聊聊商业。
经过20年发展，中国互联网已经从一个新兴行业逐渐成为传统行业，这种转变的标志就是行业寡头的产生。
从事互联网行业，目前最经典的职场线路：211院校毕业，去BAT从实习生一路做到经理总监，五年就可以找到投资，自主创业。
越来越多的公司B轮死，亦或发展出规模，才发现商业模式存在巨大漏洞。
哔哔哔说了这么多，都是为了回答「如何提升商业需求能力」这个问题。
现身说法，Hozin职场的前四年和互联网完全没关系；一份是金融中介行业，一份是汽车零售贸易，这两份工作都是「商业策划类」职位。
从扫楼陌拜，到客户主动联系续约；从心惊胆战的拿着支票，到身上带着客户的几千万本票坐公交车回公司结费；从六方位绕车磕磕巴巴被客户鄙视，到CSI考核小能手，独立执行国际车展展位方案……非常感谢这4年的传统行业经历！协助策划国际赛事，见证亿元级项目的洽谈签约，有机会管理五个4S店的店头布置，每周给报纸写软文，责编内部刊物，帮老板经营汽车俱乐部，全程参与了3000平米酒楼的品牌包装，菜品设计，亲自做司仪主持开业……与一大群传统行业的前辈保持亦师亦友的关系……这一切仿佛就是略「懂商业」的原因。
所以「懂商业」这件事，最重要的就是「接地气」，不要企图坐在办公室里冥想商业，也不奢望看几个公众号和知乎的文章就懂商业，请迈开双腿走到广袤的商业当中去，扮演一兵一卒，去感悟商业的核心。
一款定义为成功人士座驾的豪华车，大部分买家是把土地刚刚卖给开发商的郊区农民，这就是真实的情况。如果你不切身体会，就无从下手。
商业是什么？就是做买卖，就是供求关系。供大于求，采购方就是爷爷；供不应求，采购方就是孙子。只要你知道利润是怎么来的，盈亏平衡点是什么，你就懂商业了。
如果非要坚持「不接地气」，也有办法，科特勒的《市场营销》系列专著迭代了十几版，通通读完你就知道大家热炒的那些所谓新经济，所谓新商业模式都没逃出资本主义在1970年代建立的基本原理，你也就不会为了一场让乌合之众热血沸腾的跨年演讲而唏嘘不已。
By the way，当大众已经感觉到风口的时候，在资本那边已经过气儿了，一般这个周期是半年。也就是说，资本半年前追逐的模式，就是你今天所见到的风口。生鲜已经倒掉一批，大家还在试错。
问题十五：国内或者国外有没有一些交互比较好的APP推荐呢？
如果你问普通交互设计师，他们几乎一定会给你一大堆的链接和APP产品。当然这是他们的积累，也是他们是财富。眼界的确非常重要，追逐最新的交互形式，前沿的科技，逼格满满的设计，会让灵魂得到愉悦。
但是，在接受过陶冶之后，或许面对真实的项目，往往无从下手。
研究一定要有专深，没有深度，只有广度，这样永远是浮皮潦草，不得要义。
有一个公司的产品hozin研究多年，它的每一次版本迭代都让人耳目一新，没有什么浮华的动效，这个产品的交互设计师们只是做了该做的事情，让这个产品的转化率和增长一度超越脸书和推特。
它就是链接：/houzz.com/
web端，响应式，APP，iPad版本，一气呵成的外秀慧中，朴实惊艳，甚至每一个像素每一个按钮，每一种变化，每一行前端代码都值得玩味。
如果能系统的追踪它的每一次小修小改，搞清楚原理，坚持几年，会学到很多东西。
大家可以搜一下《2017年UI设计趋势》，然后再搜一下《2007年网页设计趋势》，你就会发现，这些所谓的专业文章，除了收智商税，什么都没帮助到你。
坚持长期追踪一两个目标产品，是技能专深的必经之路。
多问问自己它为什么这样设计？为什么抛弃上一个版本的形式？对转化率有什么帮助？为什么过了几个月又改回最初的形式？UI交互为什么能适应功能扩展？坚持几年去研究它吧。
问题十六：如果想要做一款产品，是给盲人拐杖加入危险预测功能，还有专用的app，想问下，这个产品运用金字塔原理应该如何说明？」
Hozin的回答：
题主的这个问题，用金字塔原理验证一下，是个伪命题，故无法正面回答。
在介绍Book#01《金字塔原理》时，Hozin表达过：
《金字塔原理》是一种思考问题的逻辑；
是一种整理思维的方法；
是一种帮助高效写作和表达思想的武器；
本身也是一本关于信息架构的基础书籍。
参考书中提到的纵向关系
参考书中提到的横向关系（演绎推理）
Hozin花费了20分钟时间用金字塔原理推理了一下，见
盲杖本身就包含危险预测功能，无需重复添加。
建议认真的阅读《金字塔原理》，学会准确的提出问题，才可能得到有效的回答。好，现在大家知道这本书有多重要了么？如果不能严谨的提问，就无法得到正确的答复，就是在浪费问答双方的时间。
PS.要感谢小密圈的匿名提问功能
问题十八：请问一下进行概念设计后的东西是怎么联系到信息架构？
Hozin的回答：
一个具体的例子：
图#01【演出】的概念设计草图
图#02【演出】的完整概念设计
图#03基于【演出】概念设计的一种信息架构（【票务部分】的局部）
（以上这些是Hozin在2009年设计的，第一次拿出来）
请先阅读：
《从概念设计到信息架构》2009
链接：从概念设计到信息架构 | HoZiN | 产品思维_信息架构_交互设计
然后请阅读：
《如何理解产品设计中的概念设计、功能规划？》2013
链接：如何理解产品设计中的概念设计、功能规划？ | HoZiN | 产品思维_信息架构_交互设计
依然无法理解？
那就请亲自动手，设计一个概念，然后发出来，Hozin给你一些更具体的建议吧。
大家要明确，如果只看看资料就能掌握一门技艺，所谓【工匠精神】就真没必要存在了。
问题十九：最近想跳槽金融行业，做金融行业的交互设计师，有什么需要注意的？
怎样才能算是金融行业交互设计比较厉害的？
Hozin的回答：
纠正一个错误的概念（抱歉，此处必须用【纠正】这个词汇）
交互设计是一种通用技能，没有所谓【金融行业交互设计】。
Hozin作为非专业人士，分析（吐槽）一下金融产品，以及设计建议。
1.金融行业的简单本质
金融行业复杂么？不复杂！这是一个【以钱生钱】的行业；农业提供食物和各种原材料，工业提供原材料和消费品；金融是一种服务业哦。钱，自己就能繁殖么？NoNoNo，钱需要加上【时间】才会【生钱】。
储蓄、信贷、保险、抵押～～金融的一切业务都有三个要点：
A.某一时刻，钱Into
B.等待一段时间
C.某一时刻，钱GoOut
整个产品的核心，就是这三件事！
金融，归纳成一句话：一进一出，时间让钱生钱
2.金融行业的壁垒
用术语迷惑普通人，故意制造误区，建立不对等的数学认知，居然可以不劳而获！于是，公元前2000年，金融行业诞生了。
金融业是吸血鬼，它让大众误以为升值10%和贬值10%是等效的绝对值（ 11/10=10/9 ？）……欢迎大家Google“金融错觉”这个词儿。
金融从业的壁垒就是了解那些术语，什么现金价值、市盈率、对冲……
3.在金融行业，交互设计师能做什么？
敢消灭错觉么？敢不敢在APP不说年化收益（实际理财只有三个月）？敢不敢让老百姓读懂那些保险条款？
能不能输入金额，然后马上在根据条款时间输出利益金额？非要用户自己算一遍么？非要故弄玄虚么？
你敢消灭金融错觉，那你就厉害了。
如果你不敢，那Hozin收回前面的话，可能真的存在【金融行业交互设计】这个技能，帮助金主维护金融错觉，利用术语壁垒不劳而获。
问题二十：为什么微信加好友之前不可以先聊天,而QQ加好友之前就可以先聊天呢？
Hozin的回答：
聚焦一下，这属于社交产品中的【临时会话】问题。
微信没有临时会话么？其实存在哦！
场景是这样的：
比如痴汉A获知了某个妹子的微信ID，就可以发起申请好友啦
但是，妹子设置了需要验证添加好友！
于是痴汉A，输入了一句验证：妹子你好
此时妹子有一些选择：通过？忽略？还有一个选择是【回复】
妹子可以回复：你是谁？
痴汉A可以继续申请验证：我是老谁家那小谁啊！咱们一起去过夜店的～～
妹子可以继续选择：通过？忽略？还有一个选择是【回复】
这就是【临时会话】哦，当然微信对这种验证做了次数限制。
下面，Hozin作为非专业社交产品人员，分析一下微信是如何保护用户隐私的。
1.来自QQ的经验教训
企鹅时代，QQ号码是可以连续遍历的，甚至是一种公开资源，这已经给用户隐私带来很多困扰。
当然QQ是可以设置【无法通过号码搜索到自己】，但是但是但是，只要知道某个人的QQ号码，就可以窥探Ta的QQ空间，甚至去搜索引擎上检索Ta留下的脚印信息。
在某种层面上，QQ已经被滥用，甚至根本没什么隐私可言。（如果你的QQ号码使用了5年以上，可以搜索一下自己的号码试试，你在互联网留下的脚印，可能你自己都不记得）
2.微信的关系短链
微信是一种熟人社交，从关系矩阵来说，熟人之间一定是短链，这就大大减少了被滥用的机会。
盘点一下两个用户建立微信好友关系的渠道吧
A.痴汉A明确的知道妹子的微信ID（微信号）
B.痴汉A知道妹子的手机（妹子绑定手机并自愿匹配通讯录好友）
C.痴汉A是妹子的QQ好友（妹子绑定QQ并自愿匹配QQ好友）
D.痴汉A搞到了妹子的微信二维码（或者面对面扫码）
E.痴汉A和妹子在同一个群聊对话中
F.痴汉A和妹子都自愿参加了一些魔法功能（摇一摇，附近的人之类的）
G.痴汉B把妹子的微信名片转发给痴汉A
以上，只是建立【临时会话】的可能，当然必须要妹子通过验证，才能建立朋友关系哦
3.微信的OpenID打造极端隐私环境
如果你不想让任何人获取你的微信隐私，那么可以这样做：
A.用手机号码注册微信
B.关闭手机通讯录匹配好友功能
C.不设置微信ID（微信号），没错，微信不要求一定设置这个
D.不要绑定QQ
E.不参加任何摇一摇、附近的人等魔法功能
F.在设置中【添加我的方式】把微信ID（微信号）、手机号、群聊、二维码、名片都关闭
好了，此时，没有任何人能主动加你为好友，没有任何人能和你建立【临时会话】了。
所有的外部行为：关注公众号、支付、聊天等功能都是以加密的OpenID实现～～～
以上就是微信和QQ在【临时会话】方面的差异！
这两个产品的其他差异，简直罄竹难书啊～～～
等大家问到了再一一解答吧。
问题二十一：看了一些市面上分享分析app的文章感觉都是一个套路，请问圈主怎么样分析app，然后学到知识？
系统分析一款APP，请参考Hozin的这篇文章
程序开发有反编译，交互设计有逆向工程。
这种敲骨吸髓式的分析，非常烧脑；彻底分析一个竞品可能需要几天，或者几个星期；不建议一定这样分析。
橘生淮南则为橘，生于淮北则为枳。
两个月没更新过的APP不要分析了，因为根本没有值得分析的地方。
分析一款APP的流程应该是这样的：
1.剥皮
主要是表现层和交互模式。有些APP看一眼桌面图标就没有分析的欲望了，那些设计精美的才值得分析。可以把典型的控件总结一下，逆向工程出设计规范。
2.吃瓤
主要是内容场景、信息架构、功能。内容的种类形式，表单项目有多少，如何设计浏览路径，使用什么样的功能建立了何种对称，通过封闭建立了何种不对称。
3.嚼核
主要是转化率和盈利模式。解决了用户的什么问题，期望用户使用频率，针对哪些痛点和痒点，核心转化率是什么，有多少下载安装量，用户评价如何？
这三个层面所有的【为什么】都搞清楚，然后总结：明显的优点有哪些？明显的缺点有哪些？
这三个层面所有的【为什么】都搞清楚，然后思考：如果我是设计师，会如何设计？
这三个层面所有的【为什么】都搞清楚，然后尝试：换个交互框架会如何？如果增加一个功能应该放在什么地方？
如果是产品人员，甚至可以思考：这个APP背后的运营平台是什么样子的？这个APP背后看不见的功能有哪些？原始需求是什么？产品人员妥协了什么？这个APP赚钱么？
问题二十二：产品的成功如何归功于交互的成功？
PV/UV/DAU/转化率/下载量等数据上去了，怎么证明这些结果不仅仅是产品设计规划和运营的功劳？怎么证明交互在这里面的作用呢？
Hozin的回答：
也曾思考过类似的问题。一个孩子从呱呱坠地，成长为事业有成家庭和睦的好公民，归功于谁？是生Ta养Ta的父母？还是教育Ta的师长？还是供给Ta饭食的农民？还是给Ta衣服穿的纺织工人？
莫非归功Ta自己？那么Ta在襁褓时候不需要哺育？Ta不需要灵魂工程师的塑造？Ta不需要吃饭？不需要穿衣？
有一个相声叫《五官争功》，很有意思，可以欣赏一下。
隐约感到一些尴尬的处境，大家对交互设计的价值存在质疑，或者产品人员的交互水平高于你，或者大家认为界面功劳都属于视觉设计师……那么下面的话就有意思了
1.团队驱动力不应来自leader
所谓领导，只是个鞭策着，是决策的组织者
2.产品驱动力不是团队，而是数据
这一点你意识到了，各种转化才是目标
3.产品都是妥协的结果
参与其中的人都要坚持，又都要让步
4.设计师的价值是多样性解决方案
只有多样性，才能为试错的提供可能性
如果基因不能变异，物种就不可能进化；如果永远在讨论最优解决方案，产品就总是得不到验证，多组织A/B测试，才是交互设计师应该做的，忘记用户研究吧。
问题二十三：如何快速的出交互原稿，用于交流讨论方案？确定之后页面的设计又如何安排？
Hozin的回答：
第一个观点：优秀的设计必然消耗更多的时间。
第二个观点：又快又好，这很难，甚至完全靠运气。
第三个观点：保证不那么糟糕的前提下，尽量快速完成设计，是可行的。
以最快速度完成【60分】的交互设计，工具用纸和笔，或者最熟悉的工具；快速理解需求业务，确定大致有多少典型用例，每个用例大概需要几个界面，界面上大概有什么内容；剩下的就是……下面这些事情：
1.如果是PC端【桌面浏览器端】产品，请打开链接：BP Global这个站点，然后随便打开一些页面，只要感觉和用例差不多，直接套用（局部也可以），画出草图。
2.如果是移动端【APP或移动web】，请打开陌陌，然后随便翻翻，只要感觉和用例差不多，直接套用，画出草图。
3.如果某些用例在这两个目标案例中，找不到对应的参考，恭喜你，这些用例可能就是你的核心业务，花一点时间补全它们。
4.然后你就可以拿着原型参加评审讨论了。
朋友们会非常纳闷：为什么是这两个参考呢？
负责的解释一下：
链接：BP Global（BP Global）从知道它到现在，十几年一直在迭代，但是从未有过颠覆式的改版，换句话，【2006年，这个网站几乎就是这样】。时间已经证明，它最初选用的交互设计框架经得起考验，拿来copy绝对不会低于60分。
陌陌这个社交软件，几乎包含了大部分移动端通用功能，从聊天到群组，从积分体系到FEEDs，从SoLoMo到电商，几乎全包括，拿来copy绝对不会低于60分。（最近移动端的MONO也不错哦）
照此方法，熟练掌握，滚瓜烂熟，一天可以画很多【60分】的交互设计原型。
确认原型之后如何安排设计？问题的后半段模糊啊，是视觉设计么？每个公司不一样，通常Hozin会拉一个界面列表，列表中包含优先级，发给视觉设计人员，然后就可以安心的写交互文档了。
在充分了解需求的前提下，【直接copy其他产品】，就是最快的解决方案。
问题二十四： 自己如何在读完书单之后，去具体实践和练习？
自己自学有点枯燥，有没有可能组织线下的活动创造一些练习的客观条件？或者如果自己想组织这种活动的话，应该如何入手？
Hozin的回答：
重申：学习是一件孤独的事儿。要耐得住寂寞，要舍得下时间；别人出去玩，你看书；别人逛淘宝，你画图；别人玩游戏，你思考……
圈里大家所处的职业阶段不同，每个人自知、自省的能力不同，希望尽量是让每个人都得到一些启发。启发是这个圈子能给你的，但学习是你自己的事。
线下的聚会，讲学，除了装13就是装13，木有用；有任何交互的问题，扔出来，Hozin给你答案，那些嘉宾也可以给你参考；当然不排除一年以后，大家收获满满的技能，咱们组织一些轻松纯玩的聚会。
看书学习，理解方法论要靠自觉；hozin其实非常不喜欢回答有关方法论的问题，很多玄学，实战根本用不到。
实践练习有办法。圈里即将组织针对一些虚拟项目，进行信息架构设计练习，大家自愿参加吧。
Hozin正在写的就是基于一系列虚拟项目，站在实战角度，解决实际的设计问题。
二十五：卡券设计原型点评
小密圈朋友昨天提供了一组原型界面，是某个商铺卡券产品的界面设计方案。Hozin根据提供的4个界面做了一些交互点评。
可以看出这位交互设计师有功底，需要提高的是【交互形式对应交互本质】的认知。
好的地方不说了，只说【可以提高之处】。
硬伤01：距离核心转化太远
突出店铺是没意义的，店铺本身带不来转化，要突出的主题是卡券。同样，进入某一个商品，默认界面也应该是卡券。
硬伤02：隐喻设计较少
移动端界面，屏幕空间较小，能用图标的地方，少用文字；并不是一定都要用图标，而是要把握好隐喻的尺度。
硬伤03：我的卡券，从属关系混乱
【我的卡券】应该在【我的】里，不应该在某个商铺的下属。
硬伤04：将【分类】【筛选】【排序】混淆了
只要把真实数据填进去，就知道现在的设计问题在哪里。
以上只是蜻蜓点水，单纯从交互层面给予的优化。
作为一个产品人员，如果是Hozin设计这个产品，可能出发点和最终结果完全不同。
所以，这个答案只是一半，另外一半【如何从概念设计出发，架构信息，创新交互，输出一个卡券类的产品】，已经开始构思，近期会给出，可能是一个颠覆性的东西哦，请给一点时间吧。
问题二十六：固定地理环境作为社交入口是伪需求吗？
以线下店铺为中心的顾客社交产品，感觉挺新颖的。像这类以固定地理环境作为社交的入口点，该如何分析是不是伪需求？对需求的分析好考验综合能力，按照Hozin提供的阅读顺序进行阅读训练，不知道能不能解决现在的困惑？
Hozin的回答：
AR实景红包，大家都玩过了吧。不知道是否还有朋友坚持在玩。
现实生活的确正在RPG游戏化，每天上班下班就是NPC任务咯，以此类推，未来真的就像《西部世界》了！
固定地点AR社交，是不是伪需求呢？
需求是什么？吃饭是行为，饿才是需求；洗澡是行为，清洁身体才是需求；交友是行为，啪啪啪才是需求；
AR实景社交是一种行为，它的驱动力还是人的各种欲望：经济利益、生理需要、心灵满足……马斯洛的那些，这才是需求。
如果需要痴汉到某个地点签到，那一定是有利益驱动，或者有漂亮妹子等着约会。
请注意，Hozin目前推荐的书籍，都是交互设计相关，并不是给产品经理看的，所以不能解决产品战略方面的困惑。
商业产品应该去读市场营销、商业定位、社会行为、消费心理学、科技趋势这类书籍。
问题二十七：
关于移动web端的导航
1.手机浏览器自带的返回键和页面顶部导航栏里的的返回键是不是有些冲突，如果把页面内的返回键去掉，移动端的导航该如何考虑？
2.移动web导航栏需要和app一样固定在顶部吗，爱奇艺固定导航栏，淘宝携程并没有固定导航栏」
Hozin的回答：
1.请不要用原生APP的思维去设计web！移动Web也是web哦，浏览器是自带返回按钮的，移动端浏览器也自带返回，安卓用户已经很习惯返回的物理键了。设计移动web导航和pc端web大同小异，按照响应式的原则，要藏起来一些东西，请参考链接：Media Queries（Media Queries）里面的各种案例。提示一点，尽量避免在移动端web用面包屑！
推荐响应式做的比较好的是链接：Pack: Connecting thedog lovers of the world（Pack: Connecting the dog lovers of the world.）.
2.移动web导航是否固定的问题，建议固定不固定都可以（具体问题具体分析）。高级的做法是：固定，但是隐藏，上下滑动时，出现。
写文章不容易，请呵护原创。未经授权，请勿转载。
HoZiN：交互老法师，江湖人士，藏经阁扫地的，不在BAT。个人主页：http://hozin.com。
本文由专栏作者 @HoZIN 原创发布于产品社区（www.aiyingli.com），未经许可，禁止转载。
