问完这 18 个问题，你离优秀的交互设计师就不远了

设不接到需求就埋苦，也不产品一我不二，一先思考再动手、动手思考的过程。

在这个过程，有些思考如不够全或者深入，有可能导致做出来设计有漏洞，既影响品质量，也自己专业进阶益。

为了能磨好每一次计，整理了一些问题来帮助思考，各位交互设计师也可以试着在工作用以自问。这些问题如能找到答案，那离优秀设计出也不远了。

十个问题，了四组，不见得全面，但也能贯穿计始终。

需求

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（尤其一新设计的、不常见的互方式）。当，个问题建议设计做完最想，以免前期给自己设太，影响设计挥。

面对这些问题，就像「吾日省吾身」一样，问自己反思，既问题又解决问题，才有助于进益。

不过这些问题挨儿自问一遍其实也比较花时间，建议可以用比较复杂或者棘手的需求。且也不一每次全过一遍，根据实际况，酌增删就好。

欢迎关注作者微信公众号：「略设小计」