做设计不是接到需求就埋头苦干，也不是产品说一我不说二，而是一个先思考再动手、边动手边思考的过程。

在这个过程中，有些思考如果不够全面或者深入，就有可能导致做出来的设计有漏洞，既影响产品质量，也对自己的专业进阶无益。

为了能打磨好每一次设计，我整理了一些问题来帮助自己思考，各位交互设计师也可以试着在工作中用以自问。这些问题如果能找到答案，那就离优秀的设计产出也不远了。

十八个问题，分了四组，不见得全面，但也能贯穿设计始终。

需求

1. 为什么要做这个需求，需求背景是什么？

要搞明白用户在怎样的活动场景下遇到了问题，然后产生了需求。这是从根本上去了解一个需求，也是最后验证产品功能的地方。

2. 谁提出来的，是否是原始需求？

工作中设计师收到的需求有时候是二三手需求，经过多节点传递后，信息就容易失真。如果无法直接触达用户，最好能联系到提出第一手需求的人。

3. 用户有没有未表达出来的需求？

用户有时候只是描述困惑和问题，而不会专业地描述他们的需求。即使有描述也可能只是在表达表面层的问题，优秀的设计师需要能够透过表面看到实质问题。

用户场景

1. 这个功能用户是怎么使用的，流程是怎样？用户平时怎么理解它，具体的场景是怎样？

对于这个问题的挖掘其实非常重要。我们做产品做设计，其实就是帮助用户解决在某个场景下活动中出现的问题。能够清楚地知道用户使用产品的习惯、方式和流程，了解他们对于产品的理解（用户心理模型），能非常好地帮助我们在设计中有的放矢，而不至于去设计「我们觉得用户会怎样使用」的产品。

2. 什么人会用这个功能？

很多产品大大小小功能非常多，整个产品面向的用户有 100 个的话，其中某些小功能可能面向受众只有 10 个，而这 10 个人还和其他的用户画像可能并不完全一样。那么做某些功能设计的时候需要重新思考，这 10 个人的用户画像特点是什么。

例如：一个主要面向 HR 用户的人事管理系统，其中的某些功能公司的高层管理也会用，比如查看公司的组织架构。高管使用时的诉求和一般的 HRBP 是不一样的。那么就这个功能，我们也需要再去了解一下这些高管用户。

3. 有没有找合适的用户测试过，用户调研中有没有什么新的发现，用户对于这个功能有什么未被满足的期望？

如果不能接触到最初产生问题提出需求的用户，可以找身边和目标用户画像重叠度较高的同事/朋友帮忙做非正式用研，一方面可以多了解他们在使用中的问题，另一方面可能会有新的发现和收获。

4. 使用频次、重要程度怎样？

一个功能或控件在使用频次和重要程度上的定位，会影响到它在产品/页面中的位置、视觉突出程度、设计研发成本等。

5. 对产品中其他功能是否有影响？

有些功能并不是完全独立存在，很可能不管是操作上还是数据上都和其他（页面的）某些功能有牵连，那在做这个功能设计的时候，也要考虑设计出来会不会对与之有关联的功能使用有影响。

例如：比如微信里，用户把联系人 A、B 和 C 分组为「家人」，然后发一条朋友圈对「家人」可见。那么如果用户一段时间后在「家人」的标签里加入了 D，那么 D 还能看到之前那条朋友圈消息吗？

6. 竞品是怎么解决的，如果找不到竞品，那么具有类似功能的产品是怎么解决的？

做设计也会偶尔没有思路，或者陷入某个点出不来，再或者做出来后大家总觉得不满意，这种时候都可以找优秀的竞品看看。如果没有直接竞品，也可以就某个功能找有此功能的产品看。

控件

1. 是否能用现有控件完成？如果新增控件的话，必要性大吗？有没有其他地方会复用？

管理设计资源非常重要，一般成型的设计规范和控件资源尽量复用，避免没有节制地添加新的控件和规范，不然容易影响到开发成本以及后期的控件维护。

2. 这个控件在操作时的各种状态以及引起的各种变化是不是都想过了，通顺吗，全面吗？

作图的时候我们常常只做一些关键页面来评审和讨论，评审通过后继续细化的时候才发现有些控件的变化状态以及引起的页面变化没有考虑到，甚至会对已经通过评审的一些功能有很大影响。所以建议大家有自己的交互自查表，可以对照着检查控件的每种情况、每种变化等都是否考虑全面，在页面上能否跑得通。

例如：设计一个列表要考虑到数据的展示、数据排列规则、新增和删除数据的样式、超出一屏的情况等等。

3. 自己想当然增/删/改的部分，实际场景中会有可用之处吗？

完成一个需求的时候，可能会根据自己的一些想法，额外增/删/改点现有的功能，不是不可以，只是也要考虑一下，这种设计师自发的改动，放在实际场景中，是否真的适用，如果是的话那当然好，但如果不是就可能白费力气了。

4. 会不会引起误操作，会的话怎么避免？

控件的大小、位置、间距、颜色设计不得当的话都可能会引起用户的误解或者操作不便，从而导致误操作，尽量从设计层面来避免。

交互控件科普专题，强烈建议基础不好的设计师学习 ➡️https://www.uisdc.com/zt/interactive-control

检查

1. 设计完成后有没有找合适的用户测试过？

有时候自己做的设计怎么看怎么 OK，即使是很有经验的设计师，有时候一个功能做久了就不容易跳出来发现问题。做完后找身边的同事/朋友帮忙看一看，说不定他们第一眼看出的问题和疑惑能给你新的启发。

2. 这样是不是就够了？

很多需求我们可以用常规的方式去解决，最后得到的也很可能是一个中规中矩的方案，说不上不好，但也说不上多好。这时候可以再想想有没有体验更好、操作更便捷的方案，而设计师的进阶有时候就是从这里的「多想想」开始的。

3. 自己有没有先演示试用一下，看看实际效果能否跑得通？

做完设计稿不自己验证一下就直接给开发是不太负责的。其实现在软件联动很方便，像 Sketch 上做完图，可以直接导入 Principle 或者手机里点击查看效果。确保能点击的地方点击后效果无误后再交付给开发，也能避免后期返工。当然，如果是非常小的改动或者设计，自己确信可以脑补运行效果无误也 OK。

4. 设计文档写清楚了吗，有没有一些细小的改动需要特殊强调一下以免开发注意不到而遗漏？

设计图搞定后，就要补充完交互文档，这里会涉及更多的细节问题，交互逻辑说明甚至视觉标注等都要再三检查是否做到了完整和通顺。另外，如果有一些在原页面/功能上的细小改动，建议可以用自己的方式强调一下，以免开发注意不到给漏掉。

例如：已经上线的某个页面上只需要修改某个标题文字，开发很可能注意不到，我一般会在旁边加个颜色反差大的箭头以及文字说明指示一下。

5. 和开发沟通过吗，开发可实现吗？实现起来超出预计成本吗？

有时候因为产品形态的不同，一些我们觉得想当然的效果，在开发看来并不是那么容易实现。比如我们在 APP 上司空见惯的一些效果，在 H5 页面上实现起来就不一定容易，有时甚至会因为一些技术限制实现不了。所以在做完设计后可以让开发提前 review（尤其一些新设计的、不常见的交互方式）。当然，这个问题建议设计做完最后再想，以免前期给自己设限太多，影响设计发挥。

面对这些问题，就像「吾日三省吾身」一样，常问自己常反思，既能提出问题又能解决问题，才能有助于进益。

不过这些问题挨个儿自问一遍其实也比较花时间，建议可以用在比较复杂或者棘手的需求上。而且也不一定要每次全过一遍，根据实际情况，酌情增删就好。

————————————————
版权声明：

遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://www.uisdc.com/18-interaction-questions#