如何使交互稿的体验更好

　　在自己的时间和精力较多的情况下，可以尝试优化一下自己的交互稿体验，并逐渐可以养成思维和习惯；而当自己时间和精力有限的情况，保证设计方案的质量才是关键。
　　上周偶然的机会，看到老大在帮别的团队筛选简历，看到了一个同学的简单交互稿，只有界面信息的排版和页面跳转流程，缺省了很多交互稿应有的内容。后来，想起之前和同事聊起交互稿到底该如何表现的问题，就想着可以稍微总结关于交互稿的一些问题。
　　其实，想做一份“看起来”比较专业的交互稿是非常容易的。只需要拿到一份比较专业的的交互稿，进行学习和模仿就好了。这也是我刚刚开始工作时采用的方法。我曾经认识一个非常想学交互设计的学生，因为并没有太多面对面的接触，我也选择了这种方式，给了她一份自己的交互稿，让她学习。
　　然而，“看起来”比较专业的交互稿只是表象，其实交互稿是交互设计的基础，而体验才是我们关注的核心，很多时候我们都不愿意称自己为画线框图的人，我们讲思维、将方法；但是，能够带来优秀体验的交互稿不单单在传递思维、方法，还会大大的节省我们的沟通时间；提升我们的工作效率；也能够在不知不觉中提升我们的影响力。
　　也许，不同的团队有着自己的交互稿设计规范来提升体验，而我们团队在设计师们的不断变革和优化中，逐渐积累了一些提升阅读者体验的要点，希望能够彼此学习。
　　交互稿体验要点总结
　　1。不同复杂度的需求应有不同的设计
　　我们会在工作中遇到不同复杂度的需求，因此，我们也应该有着不同的交互稿展现，比如一个非常简单的优化，不会涉及太多修改和分析，就完全不需要过多冗余的内容；而一个复杂庞大的需求，就需要复杂的分析和展现。因此，在我们进行交互稿的设计之前，就需要对需求的复杂度有清晰的认知，进而能够明确该采用什么方式来展现设计内容。
　　举例说明：图11至13中的三个需求的交互稿分别对应着，简单，适中和复杂的需求。简单的需求可预见的无需太多的更新迭代，有着比较明确的优化迭代，可能无需太多角色（可能不涉及视觉和产品），则无需太多的复杂信息，用最简单的信息传递想要优化和修改的体验问题即可；针对稍微复杂的优化，则需要一些必要的信息，比如可能需要有需求背景、流程图、更新记录等；而非常复杂或者全新的产品，可能会涉及到更多的内容，如图13所示，将会在以下的注意点中提及。因此，优秀体验的交互稿也是根据不同场景和情况、不同需求相应的变化的，而不是一成不变的。
　　2。需求简介和涉及的各角色的展示
　　需求肯定需要一个名称来标明是什么需求，最好能够清晰明了，并且标注相应的版本，以方便未来需要用到时候能够清晰的查看到。
　　针对稍微复杂点的需求，可能会牵扯到各种角色，一般的移动端产品大致包含：产品经理、交互设计师、视觉设计师、iOS开发，AOS开发，web开发，服务器开发，iOS测试，AOS测试，web测试，服务器测试等。而图2中的需求简介能够无形中提升体验：当某个角色因为某些问题，需要找到相应的人时，无需再去需求列表中寻求，在交互稿中也能一一查看。另外，需求来源的标明也能够让各个角色清楚的知道需求的重要程度和优先级，比如图2中的需求来源于“老板”。
　　图2交互稿中的各角色的说明
　　3。清晰的更新记录，可直达更新内容，并有清晰指示
　　设计其实是个过程，没有完美的设计，只有更优的设计。在不断的设计过程中，不可避免的会涉及增添、删除、修改，因此，清晰的更新记录不仅能够帮助各个开发、测试等角色清楚的明确修改的内容并及时跟进查看；也可以让自己更明确的总结和回顾在需求中自己的那些经历，进而避免下次做设计的过程中遗漏和修改。图3中即为笔者自己的交互稿中的更新记录案例。
　　图3交互稿中的更新记录
　　另外，图3中的更新记录的条目，都需要点击链接直达增加、修改的地方；当然，删除的则不需要链接直达。而在修改或新增的内容页面内，最好能够明显标出，方便阅读的角色能够直接看到，如图4所示，用红色明确的标识出时间和状态（补充）。
　　图4交互稿页面内明确标识修改时间和内容
　　4。需求介绍、背景和分析，帮助各角色理解需求
　　很多需求不单单是一个名字就能完全说明的。交互设计师在进行设计和研究的时候，往往会进行需求的分析和明确，而这样的过程，如果可以的话，在交互稿中适当的展现，能够让团队角色更清楚的了解需求，也能够无形中让开发和测试们加入了需求的分析中，而不单单只是实现需求。
　　而这些在交互稿中的展现，也一定是有目的性的，没必要将全部的分析内容都放入，也要有筛选的放入。全部内容展现，一方面阅读者无从看起，另一方面自己也辛苦。而笔者建议一般放入的内容有：需求背景、需求说明和分析、产品目标、用户目标和风险点即可。
　　5。交互设计方法的内容，无形中说服各角色理解设计
　　交互设计师不单单只是线框图的呈现和一些细节说明，我们的方法论中有人物角色、场景、流程、信息架构、数据等等，这样才是我们做设计的整个过程。选择性的将这些内容放入交互稿中，其实在培养其他角色用户思维的同时，又能够无形中说服开发工程师们帮助理解和实现我们的设计。
　　另一方面，流程图、信息架构图、业务逻辑图等之类的图表，能够方便开发和测试理清开发和测试逻辑，无形中提升了他们的工作效率，就像第6点所提到的一样。
　　6。采用不同方式，可视化的表达，达成体验原则
　　交互设计师的体验原则有很多，比如一致性，易理解等等。而我们也可以在交互稿中使用很多不同的方式来达成这样的原则。在这些原则中，最重要的一项就是易理解。而可视化、分类归纳等方式也是比较好用的方式，如图5所示，通过状态的归类区分的方法来使开发和测试很快明确不同状态的提示条的规则。
　　图5绑卡送优惠券的提示条的交互说明
　　而笔者在工作中，还会使用一些其他可能的方式来达成体验原则，比如图6中的表格状态分类、图7中的流程图和线框图结合的方法。我们每个人在画交互稿的时候，多去考虑一下阅读者的体验，可能就会想尽各种办法来满足他们。
　　图6通过表格来进行分类显示
　　图7线框图和流程图相结合的显示
　　7。一个页面只讲一件事情和流程
　　一般我们团队的设计师，都不会将一个需求的所有设计放入一个页面中，而是每个页面只讲一个流程和一件事情，而这件事情或流程必须是有始有终的，而不是中途就断掉的；如果一定要中途断掉，也最好能够引导到其他页面（通过文字或直接将页面显示出来，或者直接可跳转）。
　　一个页面讲一件事，不单单是我们做设计的方法之一。也是我们在设计交互稿时，使其他角色更专注某一条流程的方式；否则，会使阅读者的思维和设计师的思维都变的混乱，也会影响我们自己的设计。
　　8。追求交互说明的阅读体验
　　我们往往要写一堆堆的交互说明，少则几条，多则十几条甚至几十条。而开发和测试们看到这些密密麻麻的字时，自然不愿意阅读。如果我们还不能够把间距、字体粗细、字体大小、字体颜色、段落分类做好，将使他们更不愿意阅读我们的交互稿。所以，需要在写交互说明的时候，就考虑他们的感受，也要用不同的方式来写，比如图8中的隔行间距，字体粗细、颜色变化等。
　　图8交互说明的字体大小、颜色、间距、粗细等
　　而在标注上，我们可以采用很多标注形式，比如大标题的标注是1，二级可以是圆点、abc等等，再到三级再进行变化；而不是一成不变的从1写到99。
　　9。考虑不同角色的不同需求
　　交互稿有很多角色要看，开发要照着交互稿逻辑进行开发、测试要照着交互稿的规则写测试用例（如果不全，我们得补）、视觉要看着交互稿中的界面进行视觉创意等。
　　因此，我们在设计时要尽量考虑不同角色的需求，这是在交互稿中的方方面面中都要注意的，比如图8中第4条，针对视觉，写出视觉需制作两种图标；而有些时候，我也会在适当的地方标明视觉可进行创意发挥；而在开发和测试层面，则需要严谨的逻辑和易理解的方式。
　　10。通过遍历方案和界面，关注极端情况
　　交互设计自查表是一个好东西，可以让我们很方便的关注到极端情况，但是我感觉实行起来还是没那么容易的。而我现在采用遍历的方法来走查我的界面和方案，即通过交互设计的思维去关注极端情况。一个界面，从场景和流程上看会有这些问题：它是怎么出现，如果出现不了怎么办；界面中的每一个元素是怎么出现的、如果出现不了怎么办；界面中的每一个元素的状态是如何的、是否有多种状态；界面中的每一个元素的操作是如何的；界面中的每一个元素操作后的状态是如何的等等。而每一个元素、每一个页面都这样过一遍，会减少很多极端情况的丢失，如图9所示，通过遍历写交互说明。
　　图9通过遍历来写PC端群空间动态详情的交互说明
　　而遍历不单单能用在写交互说明上，再深一步还可以用在设计方案本身上，比如为什么要有这个元素或信息；这样的元素和信息能带给用户什么；用户能不能理解；可不可以有其他方式；能不能更简洁等等。但往往这个层面的遍历会耗费大量的时间和脑力，所以包括我在内的很多人应该都会忽视，还希望自己未来能更多的尝试这种方式来审查设计方案。
　　结语
　　其实还有很多能够提升交互稿体验的方法，比如图9中”A7动态详情页”这样的标注会使每个页面更清晰，但会增加和耗费我们在设计交互稿的时间；曾经，视觉团队反馈，可以将所有界面放入一个页面，这样可以更方便视觉设计师查看等等。
　　其实，很多方法和规范是死的，人是活的；在什么样的场景下，满足什么样的需求才是王道；而我们的交互稿的初级目标是可用，终极目标才是体验更好。在自己的时间和精力较多的情况下，可以尝试优化一下自己的交互稿体验，并逐渐可以养成思维和习惯；而当自己时间和精力有限的情况，保证设计方案的质量才是关键。