交互作品集制作后总结

文章以自己的作品集为基础，对其中的方法的一些新想法。没有一个完整的逻辑，想到哪写哪。各位看客见谅。

卡片分类法：
卡片分类法是为了优化信息架构，减少产品的学习成本的方法。是从具体的某个功能点，从下往上慢慢归类的一种方法。
但是这种方法可能会改变产品的定位，迷失方向。所以可以考虑结合 从上到下 分析来确定信息架构。
KEY1：选取的功能卡片不要存在“包含与被包含的关系”，这会导致用户分类困难，所以选取的卡片必须是底层的功能。
KEY2：确定的功能不要再细分到信息层级让用户再分，某个功能具体的信息排版可以让用户单独进行信息分类。
KEY3：确保用户明白你写的某个功能的意思。

设计规范：
KEY1：好处：从工作量的角度来说，设计遵循标准设计规范，可以节省开发时间，直接在组件库中调用；
            从交互设计的角度来说，保持了某一平台的特征，让用户使用起来不会有跳出感，符合用户的习惯（针对只使用一种平台的用户）
      坏处：设计规范不能一味的遵循，好的用户体验追求超越用户的期望，所以在资源允许的情况下，应多从用户的角度来分析设计，复杂的
设计是为了用户使用的简单。

业务需求和用户需求的收集和筛选：
KEY1： 业务需求和用户需求是来自于两个不同的视角。首先业务需求来自于产品的视角，考虑的更多的是实现产品的商业价值，这也会影响产品
的大方向走向。业务需求来自于对市场的考核，对竞品的分析，对自身资源的综合考虑，最终来确定业务需求。而用户需求来自于用户的视角，也
就是为了解决用户的某一个问题而出现的需求，考虑的更多是如何方便的解决用户真正的内在需求，这也许不会带来近期的商业价值，但是也有人
说过“KPI是副产品”，我对这句话的理解是：当产品能够真正的解决大部分用户的需求时，它就已经获得了巨大的“商业价值”，在用户的拥护下
，KPI的提高也将顺势而为。无疑，用户需求也将会影响到产品的走向。用户需求主要来自于用户调研，分析用户在某个场景内，在做某件事情的时
侯，内心真正的想法。交互设计在需求分析的过程中的作用就是权衡两者，使产品在能顺利的解决用户需求的同时，实现既定的商业价值。

信息架构：
我对于信息架构目前的理解是：一种符合用户期望的信息分类。
一个好的信息架构不仅能使产品更加好用，让用户看了布局、标签之后，就能无意识的使用产品完成自己的任务。（降低产品的学习成本），还能
兼容业务需求，让用户一看就知道这是什么产品，这个产品想让用户做什么。
KEY1：对于信息架构的梳理，是在大部分需求确定以后，对应的功能需求也列出来。结合使用“自上而下”和“自下而上”两种方法，从上往下梳理产品
业务，从下往上梳理用户习惯（卡片分类）。综合使用两种方法来得出初步的信息架构。同时对于竞品的分析同异之处，也是得出用户习惯和创新
点，了解业务需求的好方法。
流程设计：

目的是为了以用户的心里模型检验使用产品时是否能按照信息架构的指引顺利完成任务。也就是检验用户能否用产品顺利的完成自己
当时的任务，（产品的可用性)这也是一个产品存在的基础。
KEY1：当然，有流程就有简化，怎么简化，就要具体问题具体分析，只要能完成用户在指定的
场景下的内心需求（是需求而不是解决办法，也许用户也不会意识到自己真正的需求。参照亨利福特的说法就是“如果我问人们想要什么，他们会告
诉我‘想要一匹更快的马’”），就用简单优（cu）雅（bao）的方式完成就行。优化好了任务流程能极大提高用户的使用体验，并且借此优化信息
架构。

需求转化为具体设计方案：
KEY1：需求的设计方案讨论需要有方向，不然就在做无用功。实在没有办法统一，不然做出方案，目标用户测试一下，目标用户才是使用产品的人。
KEY2：GSM模型，将业务需求转化到用户行为时，要充分地考虑清楚当前业务需求所对应的业务目的是什么，而这个目的是以什么样的目标来实现的。只有确定
了目标，才能够把目标变成真正的行动（就好像你想要英语口语进步，就会去多说英语，找英语角和其他人交流等）。从这个角度来说，如何让用户完成
业务方所期望的行为，就是要创造用户产生此行为的动机，排除用户产生此行为的障碍（心里障碍、资源障碍等等）
KEY3：并不是所有的需求都是业务需求,很多需求是从用户的角度来考虑的，这时就要在场景、行为、目标这三个维度来进行分析，既然用户已经产生行为
，则交互设计师则要面对自己的本职，就是要解决当前用户行为下的目标，可以是体验目标，也可以是内心需求，从而提升用户的体验。

具体方案中的细节体验：
KEY1：细节决定成败，小到称呼、放大较小的文字、分隔好银行卡号的数字、点击时的按钮反馈，大到信息的视觉分类、排版、信息架构的优化、使用流程
的优化，都是交互设计师日积月累的功底。

后期的测试，反馈：
KEY1：尽快使用，频繁使用用户测试方法（书上说的），为了能获取更多的用户反馈从而改进产品。当然每一次改进可能会耗费开发很多时间，所以在产品
开始构架之前就要做好兼容迭代的准备，在发布之前就要做好各步骤的检验，做好用户体验路径的测试，测试用户在哪些过程中会很高兴，会不高兴，感觉
一般，多问问为什么。让用户说话比大家没有方向的讨论效率要高得多。