最近接手了一个之前由同事小C在做的项目，是我司服务官网首页改版的后台页面设计，说只要出一下视觉稿即可。我心想后台页面结构较简单、模块可复用，有现成的交互稿的情况下三四天肯定能搞定。出乎意料的是，全部做完花了十几天，总共80多个web页面，关键是交互工作基本上重新做了一遍。
这其中必定是有较大的工作习惯与方法的差异，以下就是我对本次工作的回顾，无关对错，只是自己对交互设计的一点个人见解。
先上其中一页交互稿：
如上图所示，如果是以用户视角，应该基本可以理解这个页面的基本功能、页面跳转等情况了。但交互稿的使用者不是用户，不能进行笼统地概括，而应在顾全大局的前提下做好最细致的工作，让我们的下游工作伙伴（视觉、前后端、测试等）能清晰地理解业务规则、界面元素，可以顺利地进行他们的工作、减少沟通成本，从而提升工作效率助力项目顺利上线。
以下是我认为这份交互稿存在的几个问题：
1）职责未尽
如图1所示，列表显示规则、保存反馈提示等信息，都是基本的数据展示与操作反馈，也都关切到产品的用户体验，这些信息由我们交互设计师来定义和提供会更合适。同时也让下游伙伴不用再浪费时间精力去咨询产品同学了，减少了沟通成本提高了工作效率。同时，如果我们能把每个细节思考清楚、主动承担起一些貌似应该是产品做的工作，那设计师在团队中的作用会越来越大，能得到大家更多的认可。
2）交互说明不足
如图2所示，各表单项的填写与校验规则不够细致，如果我是前端工程师会有如下疑问：
1）产品名称：是必填项，那为空时怎么提示？不能重复，那重复时怎么提示？
2）产品图标：有格式及文件大小的要求，如果用户上传不符合要求的文件怎么办？
3）是否需要登录、是否为诺诺产品：是下拉单选还是多选？有几个选项？如果只有是或否两个选项的话，把选项直接平铺出来不是更方便选择吗？另外有没有默认选中某一项呢？
...
我们所设计的界面都是需要前端工程师用一行一行代码还原出来的，有些字段的校验（比如上方的产品名称不能重复）还需要后端提供接口一起配合校验，所以实际开发过程中他们思考的会比我们仔细、碰到的问题也更多。如果我们的设计稿没有考虑仔细，就势必会增加后期的沟通成本，不利于团队协作，同时也会降低我们设计师自己的专业性。
3）虚增实体
奥卡姆剃刀原理“如无必要，勿增实体”，在交互设计领域很适用，尤其是2B注重效率的后台产品。我们要保证每个出现的元素、页面都是合理的，是有助于用户完成任务的。如图3所示，一个产品的信息已经在表格中可以完整展示了，没有必要再设计一个“查看页”（如图4），增加了下游的工作量外，对用户来讲也是一个视觉负担。
4）页面形式缺乏考虑
弹窗有结构简单、减少页面跳转等好处，但是当表单项较多时，使用弹窗的形式会有很多兼容性问题，特别是一些小屏电脑上，用户操作时的视野会受限，不利于把控整体的填写进度。可以考虑新开一个页面，使用面包屑导航指示当前所处位置。
5）操作行为的可用性不足
如图5所示，「删除」是可以批量操作的，但「查看」和「编辑」操作只能针对单条数据进行，每次想要查看或编辑时，需要选中一条数据后再将鼠标移至页面顶部点击这两个按钮，可用性会大打折扣，所以放置的位置还需要斟酌一下。建议放在每条数据的最后面，直接点击按钮进行这条数据的操作。
以上简单说了我认为有优化空间的几点，总之我们最后交付的设计稿，应该是一份可用性高、满足业务需求和用户需求的产出物，还能让我们的工作伙伴顺利进行他们的工作。
下图是我以自己的工作习惯和方法重做的设计稿（交互+视觉）：
结语：交互设计师所需要涉猎的知识领域很广，大到心理学、人体工程学，小到需要考虑操作反馈、字段命名，还要对技术实现方法有所了解，这个过程中需要我们勤于思考、虚心学习，多积累工作经验。以下是个人经验认为一份靠谱的交互稿至少需要具备的几点：
1）高可用性：交互设计作为承接上下游的关键一环，需要分析业务需求找到合理的解决方案 ，同时要兼顾用户体验，保证产品的可用性。如果不去思考，只是把产品的PRD复制过来修饰补充一下，其实是远远不够的。
2）清晰的结构：给页面加上有规则的序号、准确的标题，能使设计稿井然有序、引导使用者查看。至于是否需要线条箭头来指示页面流程要看具体元素、页面的所属关系，一些特别的分支流程是很有必要的，但大多时候也不用为了使用而使用，纵横交错的线条其实也是视觉噪音。
3）考虑周到：对于一些特殊情况，比如字段长度超出如何展示、异常情况的处理等，我们都需要去考虑。这个需要平时积累经验，也可以多做流程图绘制的练习，对一个流程进行不断的是否追问，是会怎样，否又如何提示，直到将整个流程都走完基本就不会有遗漏了。
4）详尽的交互说明：对于出现在页面上的元素、字段，除了一些容易理解而且是写死的（比如表头标题）、以及和团队成员达成一致的内容，其他的我们尽量标注交互说明，越详尽越好。
——以上
谢谢阅读，欢迎一起探讨：）
