在招交互设计师的时候我常会问一个问题，『你怎么理解交互设计这个工作的？』，很多同学都会讲交互设计在做什么，怎么做得更好……最近因为某些原因，重新思考了这个问题。
什么是产品？
产品（Product），是用来满足人们需求和欲望的物体或无形的载体。 消费者购买的不只是产品的实体，还包括产品的核心利益（即向消费者提供的基本效用和利益）。 产品的实体称为一般产品，即产品的基本形式，只有依附于产品实体，产品的核心利益才能实现。 期望产品是消费者采购产品时期望的一系列属性和条件。
从一个想法出现后到变成一个产品，这个过程是一个设计的过程。那么会有这么几个问题：
- 为什么会有这个产品？
- 用户为什么要选用这个产品？
产品有好有坏，如果都是解决用户问题的，那应该都是好产品才对；既然都解决同一个问题，用户为什么要选这个产品而不选那个产品？
在认真了解『交互设计』这个定义之前，我也像大多数同学那样觉得『交互设计』就是指人与机器的互动设计，通过界面的操作，帮助用户更好的完成任务。简单讲就是让用户觉得好用。随着理解的加深，发现交互设计更深层的定义是，通过设计用户使用机器界面的行为来满足用户目标，从而实现产品目标。
交互设计是对产品在吸引用户使用、提升产品粘性的设计，是为产品目标服务的。
而所有的设计都是基于『信息的有效传达』这个基础上的，用户看不懂，做再多都是徒劳。所以对于一个界面来说，易读易理解是最基础的要求。
信息的呈现方式是交互设计的核心
对于工具类的产品，信息量大是常态，甚至用户为了有『掌控全局』的感觉，希望界面上信息尽可能多。因此分析用户核心需求，把信息的优先级、层次划分出来，对于界面的易读易理解是十分关键的。有些信息可能会在不同的界面中出现，但由于不同页面的核心诉求不同，信息的组织方式也会有所不同，比如只显示汇总后的信息还是显示详情，显示变化趋势还是显示变化过程。
在开发主导的项目中，大多数开发的同学都只是考虑有多少功能点，界面上要显示多少设置项，但不太关心这些设置项之间的关系，别人看到这些设置项时会有什么反应。并且总以『大家都是开发，一看就明白了』作为理由，但事实上除了项目成员，其他人就是看不明白。之前流传过一个笑话，说开发人员最讨厌的两件事情是，别的开发不写文档，以及自己要写文档。虽然是个笑话，却反映了开发者和用户之间的差异，都是同一个人，但角色的转换还是会产生不同的需求。
关于需求
内部项目由于没有上游的产品经理梳理需求，所以也没有需求文档等资料，想做出东西，就得从头开始了解项目的目标、需求，整理相关的内容。而从需求方（开发）得到的信息，大多已经是如何实现的方案，由于思考方式的差异，开发同学更多会想实现的可行性，一谈到需求，总会不自觉的就跟你讨论如何实现，这样实现的限制是什么等，话题总会跑偏，有时争了半天，仅仅是因为他在考虑实现上的问题。就是设计师是从用户需求出发来讨论方案合理性，开发是从技术实现出发来讨论方案可行性，结果就是虽然都是讨论同一个方案，但角度不同，引起争论的点就很奇怪。
这里有趣的现象是，很多时候接到的所谓『需求』，其实并非『需求』，而是一个『方案』。比如『在……加个……功能』、『把……改成……』，这种句式提的都是如何实现的方案，而为什么要这样做的原因可能才是『需求』。如果不深挖下就动手做，可能怎么都满足不了需求，毕竟如果开发知道要怎么做更好，就不需要交互设计了。
好了，为了最基本的生存，我们需要吃，于是就需要交易，于是需要钱，于是需要工作，于是需要完成工作，于是需要想怎么更好的完成工作……这里面起作用的并不只是一个欲望，而是好几个欲望，生存、安全、归属、尊重、自我实现等共同作用，只是不同的人生阶段、不同的生命状态下占比不同而已。
跟开发一个系统一样，再小的系统都需要增删改查的功能，当然也可以只做查，但其他三个功能并没有因此而不需要，只不过变成了人工处理的方式。大部分情况下我们只看到系统的一部分，比如查看文档时我们只希望这个软件能打开这个文档，但打开之后又会变成希望这个软件能编辑，编辑时又会想要能插入图片、脑图、视频、音频什么的，编辑完又会想要能保存，保存时又想支持别的格式……需求总是一点点被激活，而不是被完整提出。
关于组件库
开发的同学总有一种错觉，如果有足够多的组件，就可以自己搞定所有的界面。在确定了组件库后，就可以自由发挥，通过拼组件来实现一个个的系统。
然而问题随之而来，不同的人用同样的组件并无法拼出体验一致的页面。身边大量这类例子，使用同一个组件库，但做出来的界面各式各样，看起来是同个风格，体验则完全不同。这不是最初想要的结果。
我们其实是希望通过组件化的方式，最终不管是谁来做，都能输出一致的结果。就像是给你一堆乐高，再给一份『说明书』，通过这份说明书，不管男女老少都可以拼出一样的结果来。当然这里得有一个前提，就是『组件』已经有了，在这个前提之下，就可以讨论另外的重要问题，『说明书』谁来给？『说明书』怎么得来？
回想按岗位分工的工作流程里，开发阶段拿到的交互稿、设计稿都属于『说明书』，开发的同学按着『说明书』，把相关的组件拼起来，得到最终的页面。这里的『说明书』有两份，一份说明页面信息的组织方式及页面与用户如何进行互动（交互稿）；另一份说明页面的表现形式（视觉稿）。如果再往后延展，还有架构设计方案、接口说明等等文档。
在有了『说明书』之后，理论上来说，只要有相关的开发资源，就能做出一模一样的功能。当然这些都是理想化的，现实中需求不断更替，『说明书』也需要不断更新，但相对同一迭代版本来说，有和无的差别还是很明显的。