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