从理论到实践，我是如何完成这份交互设计的？.docVIP

从理论到实践，我是如何完成这份交互设计的？ 　　如何将需求落地到设计中？ 　　 　　谋全局者，才有自信谋一隅 　　当设计师进入设计阶段时，会出现典型的负隅纠结，而在产品整体框架和产品协同上缺少大局观。往往在局部形成的设计优势，在全局上不可用或不一致导致了优势丧失。 　　拿一款阅读与发布文章的产品来说，关于网站与app的同步问题，当我们从需求出发开始规划设计时，我们谈的是如何与网站打通进行无缝的阅读与发布文章功能的对接。而当我们进入具体功能设计时，讨论的更多的是键盘的自定义功能是哪些，上传图片数量限制，图片文字编辑如何操作，产生什么问题，怎么解决。 　　讨论到最后，发现我们已经完全聚焦在键盘的自定义上，更深度的聚焦在移动端APP编辑文章中存在的问题，以及解决的各种策略。随着时间的流逝，我们已经不自觉的进入了极为细致，极为缜密的深层交互定义和行为推演中。 　　往往是午饭回来后，相关设计人员才会突然意识到，好像在不同的模块出现了一致性问题，出现了出口入口的流程方向问题，还出现了忽略网站协同，单纯的在思考移动端深层行为问题…而产品在Q（质量）C（成本）T（时间）模型中如何权衡取舍，如何构建具有竞争力的模式，如何通过设计和运营变现，也因为被带入深度的细节讨论忽略了全局。 　　类似以上的案例，在互联网行业随时可能发生，那么如何才能控制宏观与微观设计的切换自由度？ 　　必备的工具如下： 　　1. 三大用户工具 　　新手用户、中间用户、专家用户 　　2. 用户模型工具 　　比如有三种类型用户，A类，B类，C类。A类用户中新手用户的场景和需求，可能的信息与行为；A类用户中中间用户的场景和需求，可能的信息与行为；A类用户中专家用户的场景和需求，可能的信息与行为；B、C类用户以此类推。 　　 　　 　　 　　3. 用户心理模型工具 　　用户心理模型是如何理解他要达到目标所需要的信息和行为的，你提供的信息与行为与他的预期需要针对性的匹配。 　　4. 框架工具 　　将已获取的需求进行信息属性上、或行为属性上、或场景属性上的分组归纳聚合，形成框架图。 　　框架图能够让你在已确认的需求上有组织的分类实施，并且能够快速的看到独立的需求末梢之间存在的内在业务关联或场景关联，进而影响你对设计方案行为的定义。使用框架图也能够在全局上提取出需要保持一致性的模块（反过来说就是设计-视觉-代码可以复用），同时也能够从全局角度看到任务切换导致的各模块间切换与协同。 　　 　　5. 矩阵图 　　涉及到复杂流程状态或多用户权限系统的，使用矩阵图按照需求进行多维度的状态(对应流程状态)或权限(对应多用户类别)进行归纳整理。 　　矩阵图主要用于涉及到多用户角色、属性、权限的系统。当用户角色和对应的用户权限、用户属性出现网状关系时，必须使用一种方法保证信息的可查阅性。当涉及到用户权限时，经常会出现戛然而止或者主观臆断，需要的话，直接将矩阵图打印出来，对着角色-权限-属性进行查询既可。如果有不合理的权限设置，随时更新，保证整个团队对于用户角色-权限-属性都能够在可感知的状态中。注意这些更新是全局联动的，矩阵中一个权限或属性的变更，都有可能引起全局多处的联动更新，此时更需要全局观和对矩阵的深度理解。 　　 　　6. 流程图 　　涉及到复杂流程的，需要将产品状态+用户行为梳理为流程图，将用户必然行为导致的产品状态分化在流程图体现出来，保障产品在各种状态下的流程流向清晰可见。 　　 　　 　　如何将需求落地到设计中 　　假设你接到一个具体需求：用户需要买火车票，请帮助他。 　　你该怎么将需求向设计落地？ 　　首先第1个工具要发挥作用：买票的用户是否存在新手、中间、专家用户？12306已经帮助我们培养分化了这三类用户。 　　接下来使用第2个工具用户模型： 　　买票用户分为A类：偶发需求产生的临时性买票用户； 　　B类：长期不固定目的地出差的用户； 　　C类：长期固定出差相同目的地的用户； 　　D类…… 　　 　　第3个用户心理模型工具：（此处需要强烈依赖调研）将获得的心理模型作为关键信息输入到设计流程，用交互设计服务A、B、C类用户提供准确的信息和行为。 　　第4个框架工具：将调研中获取的用户需求，从用户模型中能看到三类模型在行为上的分化明显，因此我们进行”行为属性”上的归纳。 　　接下来，你要理解买火车票的业务，确认产品框架中重要的、高频的需求集中在什么任务中。不重要的，低频的但不可舍弃的需求集中在什么任务中，从而构建出产品的框架。 　　 　　接着，确认好需求中的用户成分是否涉及到多用户、多权限矩阵。假设我们看到的是主体的C端用户（因国情决定后台票务数据唯一且不可私有化），那么买票的需求自然聚焦于买票本身，而非用户权限矩阵中。 　　接下来，我们针对买票需求进行需求落地，而配套服务和个人数据