07 设计标准——好的设计需要表达
7.1 什么是原型
原型并不是简单的图形化的需求文档；既包含静态的页面样式（线框图），也包含动态的操作效果（交互说明）；原型的使用者有产品经理、视觉设计师、前端工程师、开发工程师、测试工程师，可能还有商务、法务人员等
7.2 标准的原型应该包含什么内容
·简要说明与信息结构：变更日志（同需求文档，现实情况往往是做一部分评审一部分，评审后定期更新）；版本说明；信息结构
·任务流程与页面流程：任务流程与需求文档中的业务流程并不一样，业务流程更偏向业务限制、后台逻辑等，并不过分注重用户的操作逻辑，而任务流程则需要关注如何操作、界面如何反馈等，从而引导用户完成用户目标
·线框图 & 交互说明：交互说明主要有以下几种类型：
1.限制：包含范围值、极限值等。范围值主要指数据的取值范围，比如界面上出现下拉菜单、筛选按钮、滑块等控件时，必须要标注清楚它们的选择范围；极限值主要指数据的显示限制，比如最多应该显示多少字数，超过时如何显示，是否折行等
2.状态：包含默认状态、常见状态、特殊状态等。默认状态主要指默认显示的文字、数据、选项等，这些内容需要注明，否则开发人员可能难以意识到这是用户填完的效果，还是默认就有的；常见状态主要指针对某一个模块，经常遇到的一些状态，比如一个普通的签到领积分模块一般会出现3种状态：未登录状态、登录后未签到状态、登录后已签到状态；特殊状态一般指非正常情况下的样式、文案、说明等
3.操作：包含常见操作、特殊操作、误操作、手势操作等。常见操作主要指正常操作时得到的反馈状态；特殊操作主要指一些极端情况下的操作，用户一般不会这么操作，但一旦遇到极端情况，还是要想好应对措施；误操作主要指当用户操作错误时的情况，不过在设计时还是要尽量避免用户犯错的机会；手势操作主要指用户使用移动产品时的操作方式
4.反馈：用户操作后得到的反馈动作，包含提示、跳转、动画等。提示主要指操作后，系统反馈给用户的文字说明等；跳转主要指点击某个链接后页面跳转到哪里，设计师需要在原型上注明跳转时是“原页面刷新”还是“新页面打开”，如果是做手机应用的话，需要注明跳转时的转场方式，此外还需要注明在界面的不同位置以不同手势操作时会跳转到哪里（如下图）；动画主要指用户操作后，系统通过动画的方式反馈给用户，在移动应用中动画反馈的形式更为常见
总而言之，写交互说明时要记住2条内容：除静态页面外，还需考虑各种动态情况；除正常情况外，还需考虑特殊和错误情况
7.3 你真的会画线框图吗
·通过明暗对比表达：要注意深色并不意味着比浅色更重要，要看色块之间的对比关系，在深色块上使用浅色是希望把它突出出来
·不使用截图与颜色：不建议在线框图上使用截图和色彩，否则会对视觉设计师造成不必要的干扰。可以告诉视觉设计师需要营造什么样的分为，达到什么效果，而不是直接告诉ta要做什么具体的元素
·合理的布局：建议在确定界面布局时，提前和视觉设计师沟通商量，避免不必要的返工
·遵守栅格规范：运用固定的格子设计版面布局。建议在确定栅格布局时，也提前和视觉设计师沟通商量好
·标记第一屏高度：重要的操作按钮一定要在第一屏内完全显示，否则用户第一眼看不到，就有可能放弃这个页面，从而严重影响转化率，同时也不要为了保持第一屏高度而让内容过度拥挤
·表达清楚UI逻辑：当设计内容元素较多、逻辑层级较复杂的页面时，为避免混乱，需要提前整理一下这些内容，以保证样式符合它们所代表的重要程度，给用户一个合理的视觉引导。一般来说操作的优先级大于链接，链接的优先级大于文本
·考虑视觉实现后的效果：交互设计师在检查自己的设计稿时，不能光看“表面”现象，而要多想一想，视觉设计师按照你的设计方案是否容易设计出很好的效果（在做之前多沟通、多思考）
·了解视觉趋势
7.4 写交互说明的诀窍
·尽量使用真实、符合逻辑的数据内容（虽然在做交互时上面的数据都是假设的，但是还是要注意数据与真实的相似性，不能随便写，否则会让开发人员疑惑数据之间的逻辑对应关系）
·不遗漏特殊状态的描述：交互设计师想得多一些，前端或开发人员久会省心很多
·避免过长的说明：
·避免流水账式的说明：流程图代替文字说明；用表格罗列各种状态；巧妙组织文字说明；制作动态效果
·关于重复出现的模块：可以把重复的模块独立出来单独起名（模块化思维）
·如原型有修改，不要口头沟通，而要更新交互说明并告知大家：不然容易造成团队成员信息不对称
7.5 关于设计规范
1.设计规范是对设计的具体细节、技术要求，是设计工作的规则和界限，是一种模板化应用的方法
2.分类：从纵向考虑，设计规范可分为交互规范和视觉规范，交互规范一般要先于视觉规范；从横向考虑，设计规范可分为产品战略级方向的大规范及单个项目中的设计小规范
3.时机：一般在以下这几种情况下可以着手去制定一些规范，从而指导和完善后面的工作：（注意规范是知道设计的工具，而不是设计后的总结，况且整理规范也是需要不少时间和人力成本的）
·大型且重要的产品；
·产品结构、页面类型、UI组件相对较单一，可复用的内容较多；
·项目人手充足、时间较充裕；
·品牌风格、主题风格已确定完毕，品牌备忘和梳理势在必行；
·产品线日益丰富，后续设计一致性和可循环的要求被提高；
·产品结构壮大，新人不断涌入，沟通和执行效率亟待提升
4.制定规范一般遵循从大到小的原则，主要从全局考虑，而不是过于教条
08 项目跟进——保障设计效果的实现
8.1 做设计评审的主导者
评审前的充足准备：
·事先考虑所有可能的方案；
·准备各种设计依据（前期的数据分析等）；
·做好会议邀请工作：与有话语权的人达成一致，而不是把所有有问题都抛到会议上解决，越是重要的事情，越要尽可能少的人参与讨论，这样才能快速下决定。需要提前撰写一封正式的邀请邮件，并附上自己的设计稿，在邮件正文中除了告知会议的时间和地点外，还可以简单陈述一下设计理念，参考的数据和资料，同时提醒大家务必要提前熟悉设计方案，想好要提的问题。还要提前设定好每个环节的时间
·如何在评审中掌握主导权：主导流程（推进设计也是设计师的重要工作之一）；提高效率，控制话题（偏离主题的讨论和对于某个细节的持久争论是会议效率的两大杀手，在设计方向和大的功能点上达成一致，对于细节的问题可以求同存异，收集有价值的反馈后再来考虑）；区分和收集有价值的反馈意见（收集哪些客观的、明确的、可以操作的反馈意见）；评审后的分析与跟进（修改完善后将最终设计方案发送给项目组成员）
8.2 如何审核视觉稿
1.对交互稿理解是否正确
2.拒绝毫无发挥的视觉设计：过于遵从交互稿，完全没有发挥的视觉设计同样不合格。视觉设计不仅要把交互稿的逻辑和信息正确传达出来，还要发挥出视觉设计师的创造力，把界面设计得更加美观，更加有氛围
3.关注视觉层次是否足够清晰
4.关注交互细节和状态标注
5.在审美方面不要过分干涉
8.3 开发阶段，设计师该做些什么
1.勤于沟通：一定不能把设计稿打包发给工程师后就甩手不管了
2.统一的规范和标准：设计师在标注页面时，一定要与前端采用相同得规范和标准
3.设计走查：产品上线前，交互设计师需要对测试环境下的Demo进行交互走查，如交互动作、操作及其反馈、交互控件的各种状态等等，视觉设计师童谣需要对产品进行走查，如视觉样式、是否有色差、尺寸间距等等。交互设计师也可以配合测试工程师撰写测试用例
09 成果检验——设计优劣可以判断
9.1 可用性测试
9.1.1 设计测试任务该注意些什么：
·给出使用目标，而不是直接的操作：用户在实际使用产品时，考虑的是使用目标，而不是具体的操作和功能。引导性过强的人物设计很难达到测试目的。比如，“有篇文章你很喜欢，以后还想再找到它，你会怎么做呢？”，而不是“请你找到喜欢的文章，点击收藏按钮”
·尽量选择最重要、最频繁的任务进行测试：测试过程应尽量控制在1小时之内，除去测试前的欢迎和说明工作，一般测试任务时间为30~50分钟，选择5~8个功能点进行测试，已涵盖产品的核心操作为主
·符合正常的操作流程：为了使用户感到自然，任务的顺序应该符合正常的操作流程
9.1.2 测试用户的选择：
·选择有代表性的用户：邀请的用户应该尽可能地能够代表真实用户，另外还需关注产品使用经验和行为。如果有充足的时间和精力，可以调用产品数据，获得用户资料，邀请符合目标用户的外部用户来测试；如果是时间紧迫的快速测试，也可以直接邀请不同部门和产品线的同事或朋友
·用户数量的选择：5名左右的用户可以发现大约85%的问题，随着用户数量的增多，发现的新问题会逐渐减少。一般小的功能点，测试3~5名用户即可，新产品或较大的改版和重要功能，可以测试5~10名用户
·测试过程中的注意事项：切忌引导性过强；操作行为永远是重点；不要忽视现场反应（细微反应等）；考虑使用场景（最好能走进真实场景去测试产品）；感谢被测者，并给予一定报酬
·问题的分析与改进：零散的结果不便于分析和比较，量化的标准可以更加直观的分析结果，整理时可以按照问题频数、严重等级、优先级和违反的可用性准则这几项标准进行记录
·另活运用可用性测试：可用性测试的门槛可以很低，不一定要等产品完全开发完毕才开始，也不一定要由专业的用研人员来做。有条件的话，可以在设计过程中进行多次简易的可用性测试，用于发现流程上的问题，在设计已经非常完善的时候，使用高保真原型或在内测环境下再次进行较正式的可用性测试，发现细节层面的问题
9.2 A/B测试
·设定衡量标准：一般由产品经理根据产品要求来确定，如PV、UV、点击量、转火率、跳出率、二次返回率等数据作为衡量标准；对于电子商务类网站，也可以考量下单数、支付数、支付金额等。要在测试前提前与开发工程师沟通，从产品日志中提取相关数据
·对同一个用户呈现相同的页面：需要保证同一个用户在测试期间看到的都是同一个方案
·保证两个版本同时测试：时间不一致会导致环境变量太多
·单一变量：若变量有很多，而两个方案差异较大，则变量之间会存在很多干扰，很难通过A/B测试比较出各个变量对结果的影响程度
·A/B测试的延伸——灰度发布：如果想对网站进行改版，又不确定用户会不会喜欢新的版本，可以采用灰度发布——一种能够平滑过渡的发布方式，将旧版本作为方案A，新版本作为方案B，让一部分用户继续使用旧版本，一部分用户切换到新版本，然后管擦和用户反馈和产品数据，如果反应很好，可以逐步扩大范围，直至全部升级
9.3 定性的用户反馈和定量的产品数据（上线后）
·收集和读懂用户反馈：对于线上产品，可以放置一个“用户反馈”入口；对于新产品以及重大的改版，可以通过电子邮件、首页链接等方式主动发放调查问卷，收集意见；如果产品有在线客服或产品论坛等功能，也可以让客服把每天咨询最多的问题汇总起来，或直接“潜伏”到论坛中看看用户的吐槽，获取第一手反馈资料；对于移动应用来说，还有一个最方便的途径——应用市场的评分、评论信息……
·分析用户反馈
·用数据检验产品目标：可能是点击量、转化率提升了多少，也可能是销售额、网站营收要达到什么样的数字等
