在研发团队做交互设计

2018年开始，由于工作内容的调整，我开始接触交互设计的工作，算是半路出家。由于是在研发团队里，整体的氛围跟在设计团队里还是有蛮大的差异的，比如小姐姐很少，气氛没那么活跃等等；再者就是项目类型的差异，内部研发支撑工具，即不是toC，也不是toB。因为项目服务对象的特殊性，更像是一种定制类的产品，对于设计师来说，很有挑战。因其用户的特殊性，当下能找到的toC/toB产品的经验都不大能直接使用；并且在最开始的一段时间里，学习的压力很大，要学习了解一些研发类的知识，要能看懂用例图、序列图、状态图、类图等UML图…准确理解各种专业名词、概念模型，学习软件方法等等理论知识，而这些对于设计师来说，可能是平时根本不会去关注的内容。

关于『交互设计』的定义

在招交互设计师的时候我常会问一个问题，『你怎么理解交互设计这个工作的？』，很多同学都会讲交互设计在做什么，怎么做得更好……最近因为某些原因，重新思考了这个问题。

什么是产品？

产品（Product），是用来满足人们需求和欲望的物体或无形的载体。 消费者购买的不只是产品的实体，还包括产品的核心利益（即向消费者提供的基本效用和利益）。 产品的实体称为一般产品，即产品的基本形式，只有依附于产品实体，产品的核心利益才能实现。 期望产品是消费者采购产品时期望的一系列属性和条件。

从一个想法出现后到变成一个产品，这个过程是一个设计的过程。那么会有这么几个问题：

• 为什么会有这个产品？
• 用户为什么要选用这个产品？

产品有好有坏，如果都是解决用户问题的，那应该都是好产品才对；既然都解决同一个问题，用户为什么要选这个产品而不选那个产品？

在认真了解『交互设计』这个定义之前，我也像大多数同学那样觉得『交互设计』就是指人与机器的互动设计，通过界面的操作，帮助用户更好的完成任务。简单讲就是让用户觉得好用。随着理解的加深，发现交互设计更深层的定义是，通过设计用户使用机器界面的行为来满足用户目标，从而实现产品目标。

交互设计是对产品在吸引用户使用、提升产品粘性的设计，是为产品目标服务的。

而所有的设计都是基于『信息的有效传达』这个基础上的，用户看不懂，做再多都是徒劳。所以对于一个界面来说，易读易理解是最基础的要求。

信息的呈现方式是交互设计的核心

对于工具类的产品，信息量大是常态，甚至用户为了有『掌控全局』的感觉，希望界面上信息尽可能多。因此分析用户核心需求，把信息的优先级、层次划分出来，对于界面的易读易理解是十分关键的。有些信息可能会在不同的界面中出现，但由于不同页面的核心诉求不同，信息的组织方式也会有所不同，比如只显示汇总后的信息还是显示详情，显示变化趋势还是显示变化过程。

在开发主导的项目中，大多数开发的同学都只是考虑有多少功能点，界面上要显示多少设置项，但不太关心这些设置项之间的关系，别人看到这些设置项时会有什么反应。并且总以『大家都是开发，一看就明白了』作为理由，但事实上除了项目成员，其他人就是看不明白。之前流传过一个笑话，说开发人员最讨厌的两件事情是，别的开发不写文档，以及自己要写文档。虽然是个笑话，却反映了开发者和用户之间的差异，都是同一个人，但角色的转换还是会产生不同的需求。

关于需求

内部项目由于没有上游的产品经理梳理需求，所以也没有需求文档等资料，想做出东西，就得从头开始了解项目的目标、需求，整理相关的内容。而从需求方（开发）得到的信息，大多已经是如何实现的方案，由于思考方式的差异，开发同学更多会想实现的可行性，一谈到需求，总会不自觉的就跟你讨论如何实现，这样实现的限制是什么等，话题总会跑偏，有时争了半天，仅仅是因为他在考虑实现上的问题。就是设计师是从用户需求出发来讨论方案合理性，开发是从技术实现出发来讨论方案可行性，结果就是虽然都是讨论同一个方案，但角度不同，引起争论的点就很奇怪。

这里有趣的现象是，很多时候接到的所谓『需求』，其实并非『需求』，而是一个『方案』。比如『在……加个……功能』、『把……改成……』，这种句式提的都是如何实现的方案，而为什么要这样做的原因可能才是『需求』。如果不深挖下就动手做，可能怎么都满足不了需求，毕竟如果开发知道要怎么做更好，就不需要交互设计了。

所以到底什么是需求？

因需要而产生的要求。 ——现代汉语词典

『需要』是什么？

对事物的欲望、要求。 ——现代汉语词典

『欲望』呢？

欲望（Desire）是由人的本性产生的想达到某种目的的要求，欲望无善恶之分，关键在于如何控制。 欲望是世界上所有动物最原始的、最基本的一种本能。 从人的角度讲是心理到身体的一种渴望、满足，它是一切动物存在必不可少的需求。 一切动物最基本的欲望就是生存与存在。 ——百度百科

好了，为了最基本的生存，我们需要吃，于是就需要交易，于是需要钱，于是需要工作，于是需要完成工作，于是需要想怎么更好的完成工作……这里面起作用的并不只是一个欲望，而是好几个欲望，生存、安全、归属、尊重、自我实现等共同作用，只是不同的人生阶段、不同的生命状态下占比不同而已。

跟开发一个系统一样，再小的系统都需要增删改查的功能，当然也可以只做查，但其他三个功能并没有因此而不需要，只不过变成了人工处理的方式。大部分情况下我们只看到系统的一部分，比如查看文档时我们只希望这个软件能打开这个文档，但打开之后又会变成希望这个软件能编辑，编辑时又会想要能插入图片、脑图、视频、音频什么的，编辑完又会想要能保存，保存时又想支持别的格式……需求总是一点点被激活，而不是被完整提出。

交互设计是在做界面的帧动画

因为需求是不断变化的，受当下的场景影响，用户因为操作引起的外部变化会反过来刺激用户，从而让用户产生相应的行为变化，这个过程很快，在你反应过来前就已经完成了，在《关于一致性原则》中有相关的内容，系统1主导着这一部分。我试着把这个过程分解了下，以保存文档这个操作为例。

抽象出来就是

『经验』就类似便签纸，随时都在往里记着东西，也往里寻找内容，而『经验』也是系统1工作的基础，只有当经验遇到问题时，系统2才会被激活来解决问题，解决完又会形成新的『经验』以备下一次使用，不过这并不是永久的，记忆有时效性。

如果把用户每个时间切片所接触到的界面，看成是一个个静态的界面，所有时间切片连起来形成一个交互行为，就像帧动画一样。因此，做设计的时候可以把动态的界面变成多个静态的界面，来表达完整的交互行为。像这样：

在将界面看成不同时间切片下的静态界面之后，对界面的观察角度发生了一些变化，比如我会在某一个时间切片下推导用户当下的状态，从而判断当前界面的内容是否合理，对于一些细小的思考过程也能比较容易发现。很多时候操作是连续的，但有些时候会中断，不管是什么原因引起的中断，都应该能帮助用户更快回忆起之前的任务，从而继续完成后继的操作。

好的体验是『流畅』的，也就是说，虽然设计过程中把界面切开了，但最终目标是要减少在各个界面时间切片下的停留时长，特别是任务流中的界面。

体验的整体性

做为交互设计师，推演的能力就显得比较重要了，毕竟在把东西做出来之前，大部分都是在大脑中进行的。把自己当成用户，代入流程中，一步步推演出用户的需求，再想办法满足用户的需求。

体验或者说感受是个整体的过程，从第一个想法开始，到完成任务离开，整个过程中的所有可见可操作的元素都对这一过程产生作用。就如我们去一家餐厅吃饭，影响我们对这家餐厅评价的除了菜品好坏之外，还有环境、服务员的态度，点菜、上菜的流程等等，甚至与同时用餐的其他客户之间的互动……

虽然说设计阶段要尽可能完整，但实际开发过程中所说的迭代是以功能可用为划分的，这也就导致有些内容不是简单的把界面上的入口隐藏或修改就可以实现，可能会需要对流程进行一定的修改。也就是可能会有分支情况，这就留下了一个坑，当后继没有跟进把这个临时方案改回去时，就可能发展成跟原本的设计越来越大的差异。所以应该在设计的过程中就把迭代的划分考虑进去，以迭代功能的完整性来设计，尽可能让迭代中的交互流程是完整可用的。

关于组件库

开发的同学总有一种错觉，如果有足够多的组件，就可以自己搞定所有的界面。在确定了组件库后，就可以自由发挥，通过拼组件来实现一个个的系统。

然而问题随之而来，不同的人用同样的组件并无法拼出体验一致的页面。身边大量这类例子，使用同一个组件库，但做出来的界面各式各样，看起来是同个风格，体验则完全不同。这不是最初想要的结果。

我们其实是希望通过组件化的方式，最终不管是谁来做，都能输出一致的结果。就像是给你一堆乐高，再给一份『说明书』，通过这份说明书，不管男女老少都可以拼出一样的结果来。当然这里得有一个前提，就是『组件』已经有了，在这个前提之下，就可以讨论另外的重要问题，『说明书』谁来给？『说明书』怎么得来？

回想按岗位分工的工作流程里，开发阶段拿到的交互稿、设计稿都属于『说明书』，开发的同学按着『说明书』，把相关的组件拼起来，得到最终的页面。这里的『说明书』有两份，一份说明页面信息的组织方式及页面与用户如何进行互动（交互稿）；另一份说明页面的表现形式（视觉稿）。如果再往后延展，还有架构设计方案、接口说明等等文档。

在有了『说明书』之后，理论上来说，只要有相关的开发资源，就能做出一模一样的功能。当然这些都是理想化的，现实中需求不断更替，『说明书』也需要不断更新，但相对同一迭代版本来说，有和无的差别还是很明显的。