前言

C端产品可以用发散的方式挖掘场景，从而将需求转为亮点。而B端产品基本上是将「线下已有需求」系统化，将复杂的逻辑变为简单可用的，将真正的核心，抽离剥出，达到线上使用标准。所以需要「还原并简化业务」，而非「发散业务」，无法发散获取，只能还原场景，回归场景。

一个故事帮大家快速理解：

什么是回归场景在一次商品管理系统后台的建设项目中，业务人员（运营人员）提出了以下需求：我需要更好的管理商品大类及商品规格，在创建商品活动时候，我能更加的快速完成活动上线时间。

产品经理小李子，快速整理好需求，以及分析用户痛点，以及平台规划，调动好人员支持项目。完成一系列的操作后，把项目交接到交互设计师小王手中。交互设计师，没有多加思索项目的背后的隐藏的内容。找到产品经理核对好需求，并进行探讨--确认了，需要设计商品管理及活动创建。春菜迅速的画好了原型图，初步获得了确认。

然而，到了开发阶段，由于开发日期远高于预估排期，最终实现的方案出现了严重的问题，远远达不到当初业务人员的预期，引起了大量的投诉不好用，最终产生了很大负面影响，并且也不愿意去用了。

回归场景如果从回归场景来看，相比之下那么这一位交互设计师无疑是一位老江湖了。

这位老江湖找到当初提出的需求的业务人员：我这次来找你就是通过您了解，你需要商品管理和创建活动的需求去解决什么问题，以便我回去重新给您构思一个更加有效贴切实际的解决方案！

业务人员接过话题：因为我想通过商品管理，来规划商品上下架的操作及没货的情况，还可以根据市场环境调整一下价格。我继续问道：你之前是如何解决的呢？

业务人员回答：我只能通过微信的方式告诉价格变动或者商品没货了。然后我在根据大量的表格中去找到对应的商品，然后进行编辑，创建活动。所以我的效率很不高，经常挨骂。活动也不能及时的变更，又需要重复上一步去完成更替。

所以问题并不是一定要完成大模块商品管理和活动创建，而是帮助他们解决效率问题！

找到了问题之后，我认为应采用更简单的解决方案，我快速的画出了草图草图，讲解了一番。业务人员听懂我提出的方案后，双手一拍，对，我就是需要这个功能。你太厉害了！

只有回归场景，才能找到业务中真正的问题，从而给出更高效的解决方案。

确定了核心场景需求，一定确认以下四点：

1、场景是否能够让业务闭环；

2、场景之间是否有有明晰的串联逻辑；

3、是否有捷径的路可以走

4、是否是已经是用户理解的版本。

同理心设计

这是从一个大层面去讲解「回归场景」，那么接下来，我通过一些细节讲一下什么是场景化下的同理心设计。

还是商品模块的案例：需求确认完，核心问题确定完成，接下来轮到线框仔上场了。春菜，表示简单。

春菜在商品模块创建的下，设计好表单后，写好交互说明，得意洋洋的交给前端，组织会议，还特意强调了，请后台同学一起参与，这一块的内容会牵扯后台。开发哥哥也表示，这些简单，没问题，可以做。

在实际的场景中：用户在创建表单中，输入内容，一会一个红字，一会一个请输入，表示我还没输入，系统就反馈我是错误的了，我错在哪了？并且加大了我的阻碍，就相当于，你正在走路，时不时的被拌一下的那种感觉。发了很大的火，投诉到了老板那里。

聪明的大家也知道了问题！那就是「表单实时校验」的场景运用问题！

老板也试了一下。单手拍头，我草，你去帮他解决一下吧。你看一下你就知道了。

老江湖看到这表单创建，微微一笑。写出了以下问题：

1、这是强业务类的表单，实时校验就太过分了，同时也加强了用户自我怀疑、不耐烦等的负面情绪。实时校验也增大了后台的负荷。场景运用不明确。

2、缺少同理心，没有站在用户的角度上去设计，没能感受到，他创建表单时候的心情。

3、表单太过精细，不必要的字段过多。没有贴合实际商品的规格信息。

4、没有了解业务人员（运营人员）的工作量。没能从底层解决效率问题。

5、表单名称复杂，不易懂。导致用户频繁理解错。

6、专业操作属性过多。逻辑复杂

7、表单距离按钮控件太远。用户操作路径过长

8、缺少防错提示。不小心刷新网页，缺少防错。手贱点了关闭网页，缺少防错

9、缺少记录字段。既然是创建商品，肯定会有同类型的字段出现，系统需要记忆。帮助用户减少下一次输入。缺少友好性。

好的设计师：是能站在用户的层次上去思考问题，站在专业的角度上，帮助他解决问题。

好的设计师不会甩锅：是他没跟我说清楚，诸如此类的话，我们要学会反思，我为什么不能主动的去跟他探讨呢。

总结：根据场景确定设计原则，站在场景内，能真的懂用户在想什么。

END

原文作者： 交互思维铺子 

原文链接：  如何从场景中提取设计原则

公众号：CJM Studio

本文由 @CJM Studio 整理发布于UI中国 ，未经作者许可，禁止转载。

Powered by Froala Editor