项目名称：长春中医药大学迭代二
端口：PC端；web app端
项目类型：定制化项目，升级和新功能开发
我所做的工作：pc端信息梳理，产品流程重新梳理和设计，交互细节优化；web app 交互细节优化。
设计师：我 & LML
此次项目工期很赶，是需要在四月就完成开发和交付。由于交互的工作需要涉及到和产品经理反复沟通需求、确认交互设计方案，需要同研发那边开展原型评审，因此留给设计的时间很紧。为了在短短的几天时间内完成交互设计的工作，我和L加班加点，整整花了一个星期的时间终于完成交互设计部分的工作。
其中来回反复沟通需求的时间大概花了4天，评审花了1天，设计花了2天。
确定需求在整个设计流程中真的很重要很重要很重要（重要的事情说三遍）
真正设计花的时间其实不会是最多的，只要需求沟通的够清楚，设计目标越明确，设计出来的东西其实越接近产品和用户。
想起我做的另外一个项目，由于产品经理需求不是很确定，常常在沟通确定后我设计一个解决方案，他也认可，但是因为需求不定，产品经理又爱天马行空，完全提出一个新的需求也是常有的事，这导致来回浪费了很多时间。
在项目中碰到的几个问题统一梳理一下，其中也有自己做得不够好的地方，希望下次改进：
1.信息架构的梳理，能化繁为简
此次项目是定制化项目，是结合数字化教学平台已有的功能，针对长春中医药大学的需求进行一定调整而成的产品。数据分析的功能是数字化教学平台已有的功能，综合评价是学校提出的具体需求。单单通过原型去看，会发现很多相近的名字出现在脑海，给人很混乱和难以梳理清楚的感觉。但是从信息架构图中可以看到二者之间存在重合、包含与被包含的关系。问题一下就明了了。
为了资源最大被利用，可以将二者整合到一起，既能复用系统已有的部分功能，也能满足学校个性化的需求。
2.当两个设计师各自有自己的想法并且坚持己见时怎么办？
在前期需求沟通时，遇到这样一个场景：考生报考国家级中医药技能考试后具有考试资格，保密员在设置考试时，需要选择考生，那么问题来了，对于一个“固定”的已报考考生名单，是系统自动读取不需要用户选择还是用户可以在名单的基础上进行微调设置呢？根据产品经理从学校了解到的需求，老师希望要求能对考生名单进行修改，可以再次选择哪些学生能参加考试。
有两个声音：
L认为不需要给用户编辑学生名单的权限，考生名单的修改可能会导致数据容易出现问题，如果用户有误操作，影响会比较大，应该直接读取考生名单；编辑功能可以给后台管理员，由管理员对数据进行增删改查。
而我认为通常学校中担任管理员角色的很可能是信息部的工作人员，对考生名单的修改同样存在数据的误操作问题；管理员提供的考生名单是具备考试资格的名单，不是实际参加考试的名单，直接在名单上做删减，对数据的完整性有破坏；其次，考生名单从生成到用户在调用这个数据时，中间存在空档时间，如果管理员这边可以修改，那么会存在用户在不知道数据可能会有变动的情况下，完成考试的安排，那管理员端数据的变化将导致用户这边的设置无效。
我们两个针对这个问题进行了充分的“辩论”，各自为自己的方案举证啊，为对方的方案提出反面案例啊，总之从误操作的可能性，误操作后果，后果原因的追溯等等方面反复讨论（旁边产品经理看着我们两个交互设计师的不分上下的讨论，一度插不上一句话...但是，请原谅设计师对细节问题的偏执）。
后面我们对方案进行了折中，给用户编辑的功能，但是增加选择之后的文案提示，让用户明确知道自己的操作结果，减少误操作的可能性。
通过这次对一个小问题的讨论，感觉更多的是收获，虽然讨论的过程，感觉两个人濒临吵架翻脸的边缘，但是在这样的一个高压的环境下讨论，我们思维飞速运转，考虑各种情况，以期能够找到一个更贴近用户的解决方案。不同的声音背后的出发点是一致的，就是为设计师心中的用户提供更好的体验。因此，有不同的声音是好事也是常见的事，关键是我们最终的目的是求同存异，争取在不同中求得一个最优方案。
3.确定需求、确定流程再开始设计有多重要？
此次项目中，存在一个优先级很高、全新的一个功能，就是保密员安排考试。安排考试的过程很复杂，涉及到考试信息、考试时间安排、考场与学生的配置、考官设置等问题。产品经理提供需求是凌乱的。他也根据自己的理解提供了一个考试安排的流程，简单来说就是：考试信息设置-考场及考官设置-考生信息设置及排考-完成排考。但依然存在很多不明确的地方：如，上午安排考试的最大容量是不是固定的？报考人数不确定的情况下，如果安排考场和考官，在数量上如何去匹配？技能考试是实操考试，每轮考试实际操作中的时间很难按预期来，这中间的时间差怎么控制？在需求评审会上，大家针对这些问题和漏洞进行了头脑风暴，统一认识到现有的方案是漏洞百出的，需要大改。
由于临时接触到需求，对需求的了解还不够熟悉。考虑到工期很赶，在对需求还存在疑问的情况下，我开始了在产品经理原有的方案上的修修补补，主要针对会议上暴露出来的问题最多的考试时间安排模块集中考虑解决方案。花了大半天时间针对局部问题设计出解决方案后，却发现整个路程依然是模糊的，流程不够清晰的问题依然没得到明显解决。
第二天，L看到整个流程，大惊到流程怎么如此胡乱，犀利地提出在大流程上存在着顺序倒置的问题。原有的流程是先设置基本信息，考试区域，再根据考试区域配置考场老师，最后才由系统来分配学生。但是问题是：一次考试，往往学生报考人数是确定的（只要报考成功就能考试），而考场、考试时间轮次、监考官数量是变动的，会根据报考人数而变动。但是目前的流程却是相反的，这样子混乱的流程怎么能开始设计呢？
听了L提出的观点，才反思到自己没有首先把全局的问题考虑清楚就急于进行设计，这是交互设计的大忌。交互设计最先应该梳理的就是流程问题，而不是沉浸在设计形式的实现上。这些观念我们常常心里清楚，但是在实际操作中却容易受到外界环境的干扰，而导致出现舍本逐末的问题。
经过讨论，我们明确了主流程，再反复跟产品经理明确需求，沟通细节，确认了整体优化的方向，才最后开始方案的设计。设计出来的方案，也得到了我们自己和产品经理的肯定。
4.交互细节把控，考虑得全面一点，再全面一点
在项目设计中，除去对主流程的设计，对交互细节的把控也很重要（当然不能太过于陷入细节），尤其是移动端的设计。下面是在移动端设计时遇到几个典型问题，以及当时的解决方案。
（1）首页设计
产品经理提供的原型中首页存在的问题主要是信息的展示没有主次之分，甚至主要的功能还被次要的信息弱化；其次，首页除了展示信息，还有引导用户开始操作，增加使用软件的欲望。因此优化的版本主要在这几个方面进行了优化：
1°明确主要功能是学生在这个平台刷题，因此抽题练习在首页的占比可以加大，把抽题联系单独放出来，凸显出重要性，让用户进入考评系统就可以一目了然看到这个功能。
2°增加做题数据展示，让用户知道自己的做题情况，可以激发他继续做题或者开始做题的欲望。
（2）练习记录的列表在设计上存在的问题主要有：
图标按钮所表达的功能不够直观；未完成和 已完成的数据划分不明确；列表信息缺乏学生关注的信息。主要做出以下优化：
1°重新分析用户使用未完成、已完成数据列表的场景，梳理未完成、已完成列表数据的展示逻辑。确定为，所有未完成的练习包括重测所生成的练习，均以一条独立的数据展示出来；在已完成列表中，只要练习已完成，即使练习之下有未完成的重测练习记录，都作为整体展示出来。
2°按钮确定使用文字按钮，主要考虑到重新测试和继续练习这两个功能难以找到相匹配的图标按钮来展示。
3°增加练习正确率的信息，让用户可以在列表中就能对练习的得分率有所了解，从而做出判断是否需要重测。
总的来说，在确定整体流程后具体到每一个小的功能的设计时，考虑得再细也不为过。
