概括：在产品研发中所处的节点（设计过程），交互设计产出物，衡量交互设计产出物的一些标准，设计价值。

工作这几年经历的项目，有从0到1的产品，也有迭代的产品。公司相对开放的环境与较为轻松的工作氛围给了我很多机会去试错、历练。在经历各色项目以及和不同团队合作之后，我发现，交互设计师的扮演角色与设计输出物在不同情况下也有些许的差异。

一.承接来自产品经理的完整的需求，做一个安静的线框仔

有一些业务需求，产品经理已经考虑的非常清楚，输出了完善的PRD文档，文档中的业务流程与功能列表比较详尽，甚至提供了一些关键页面的线框图。交互设计师需要做的是：

梳理功能，为功能分组；

为复杂功能提供功能流程图；

提供界面设计图；

书写交互说明详细文档；

跟进视觉设计（一些有丰富组件的B端业务，视觉设计会省略，由交互设计师代为完成，例如开源的Ant Design）；

跟进开发。

在这种场景中，比较看重设计师的出图能力。交互设计的功能流程与界面设计方案直接关联用户的操作过程与操作页面，往往通过以下几个方便判断设计质量：

使用适合场景的交互控件。这是交互设计方案非常重要的一环，避免过度设计，也要避免过于简单的设计，一切要以适合场景为出发点。例如一个管理员的配置页面，使用表格，增删改查操作会高效便捷，但是如果设计成五颜六色的卡片并辅以各种修饰背景图，就变成了抓错重点的过度设计。再比如，一个用户粘性较高的应用的核心页面，如果功能与操作过于传统死板，则很难打动用户。

功能闭环。用户对数据的增删改操作往往会影响其他页面的数据，联动的修改需要考虑周到；

状态罗列周到。PRD文档中可能只能抓住主要的流程状态，但是交互设计师需要把所有的状态考虑清楚。例如「优惠券」功能，需要考虑领取前、未到使用时间、在使用时间内、即将到期、所购商品不能使用、过期、已使用等状态；

考虑异常。用户凭证丢失，页面超时，断网，数据量过大或过少等异常情况的解决方案需要在交互设计说明文档中详尽说明，必要时提供用例级交互说明。

技术可行。「什么能做，什么不能做」，设计方案天马行空是初级设计师容易犯的错误（包括我自己）。随着经验的增加，设计师会有一些清晰的认识。当遇到开发人员说设计的页面无法实现的时候，请教他能浅显易懂的告知不能实现的原因，大多数情况下都能大致理解开发的意思；

方案呈现工整美观，可阅读性好。低保真方案与设计说明会有多个角色的同事会查看，所以，设计方案的呈现要方便阅读，并有一定的美观性。

二.把设计工作前置，去承担一部分用户研究与需求梳理的工作

有一些需求，产品经理获取的信息不够多，在时间充裕的情况下，他希望设计人员能够辅助完成用户研究与竞品分析的工作，甚至和产品经理一起直接产出需求。当然，一些分工较细的公司，s时间允许的情况下，用户研究会交给用户研究员来做。遇到这种情况，可以根据项目需要选择性承担以下工作：

用户调研。焦点小组，问卷调查（定性/定量）；

用户体验地图。梳理用户的行为路径，找到关键的痛点，寻找机会点，罗列用户的情绪波动；

用户画像。人物描述、用户特征、关键词、用户目标、用户关注点、用户痛点；

故事板。描述用户的使用场景，可以有多个场景的描述；

竞品分析。

在这种场景中，比较看重设计师能真正了解用户的需求，了解产品的价值所在，并能放大产品价值。调研的过程就是了解用户的过程，往往后续的设计可以更贴近用户。但是，我发现了一个有趣的问题，一些做了较为仔细用户调研的项目，设计师的立场有可能出现较为片面的情况，处处以用户的口吻说话，往往会陷入过度为用户着想的境地，反而忽略了更为重要的提升产品价值与商业价值。要知道，有些B端产品，是通过授权费用获取商业利益的，产品要取悦的不仅仅有产品的使用者，还有更为重要的产品购买者，他们可能不会使用核心功能，但会在意一些审批、汇总统计等功能。用户研究的成果只能是参考，需要经过筛选与辩证分析，通过用户研究做出需求分析时一定要抛弃自己用户调研时的角色，站在产品角度出发，更多去考虑产品价值、商业价值。

总结：在产品研发过程中，交互设计师是一个衔接角色，它衔接了产品需求与开发实现，为产品价值负责。交互设计工作是一个权衡的工作，工作中权衡商业价值与用户需求，权衡AB方案的实现难度与预期价值；交互设计工作中在不断填坑与挖坑，给产品经理填坑，给开发挖坑。同时，交互设计工作是一个需要足够耐心才能做好的工作，对复杂场景的应对能力需要足够的项目经验与设计总结。总之，多闭环思考，并对每个项目都以谨慎的态度应对，高级设计师就在不远处。