原则|如何从场景中提取设计原则？设计原则|表单|业务人员|春菜

编辑导读：只有回归场景，才能从业务中找出真正的问题，并给出实用的解决方案。本文作者从回归场景的意义出发，结合场景化下的同理心设计案例对此展开了讨论，与大家分享，希望能给大家作为参考，并在工作中产生助益。

文章插图
C端产品可以用发散的方式挖掘场景，从而将需求转为亮点。而B端产品基本上是将「线下已有需求」系统化，将复杂的逻辑变为简单可用的，将真正的核心，抽离剥出，达到线上使用标准。所以需要「还原并简化业务」，而非「发散业务」，无法发散获取，只能还原场景，回归场景。
一个故事帮大家快速理解1. 什么是回归场景？

文章插图
在一次商品管理系统后台的建设项目中，业务人员（运营人员）提出了以下需求：我需要更好的管理商品大类及商品规格，在创建商品活动时候，我能更加的快速完成活动上线时间。
产品经理小李子，快速整理好需求，以及分析用户痛点，以及平台规划，调动好人员支持项目。完成一系列的操作后，把项目交接到交互设计师春菜手中。交互设计师，没有多加思索项目的背后的隐藏的内容。找到产品经理核对好需求，并进行探讨–确认了，需要设计商品管理及活动创建。春菜迅速的画好了原型图，初步获得了确认。
然而，到了开发阶段，由于开发日期远高于预估排期，最终实现的方案出现了严重的问题，远远达不到当初业务人员的预期，引起了大量的投诉不好用，最终产生了很大负面影响，并且也不愿意去用了。
2. 回归场景

文章插图
如果从回归场景来看，相比之下那么这一位交互设计师无疑是位老江湖了。
这位老江湖找到当初提出的需求的业务人员：我这次来找你就是通过您了解，你需要商品管理和创建活动的需求去解决什么问题，以便我回去重新给您构思一个更加有效贴切实际的解决方案！
业务人员接过话题：因为我想通过商品管理，来规划商品上下架的操作及没货的情况，还可以根据市场环境调整一下价格。我继续问道：你之前是如何解决的呢？
业务人员回答：我只能通过微信的方式告诉价格变动或者商品没货了。然后我在根据大量的表格中去找到对应的商品，然后进行编辑，创建活动。所以我的效率很不高，经常挨骂。活动也不能及时的变更，又需要重复上一步去完成更替。
所以问题并不是一定要完成大模块商品管理和活动创建，而是帮助他们解决效率问题！
找到了问题之后，我认为应采用更简单的解决方案，我快速的画出了草图草图，讲解了一番。业务人员听懂我提出的方案后，双手一拍，对，我就是需要这个功能。你太厉害了！

文章插图
只有回归场景，才能找到业务中真正的问题，从而给出更高效的解决方案。
确定了核心场景需求，一定确认以下四点：

场景是否能够让业务闭环；
场景之间是否有有明晰的串联逻辑；
是否有捷径的路可以走
是否是已经是用户理解的版本。

同理心设计

文章插图
这是从一个大层面去讲解「回归场景」，那么接下来，我通过一些细节讲一下什么是场景化下的同理心设计。
还是商品模块的案例：需求确认完，核心问题确定完成，接下来轮到线框仔上场了。春菜，表示简单。
春菜在商品模块创建的下，设计好表单后，写好交互说明，得意洋洋的交给前端，组织会议，还特意强调了，请后台同学一起参与，这一块的内容会牵扯后台。开发哥哥也表示，这些简单，没问题，可以做。
在实际的场景中：用户在创建表单中，输入内容，一会一个红字，一会一个请输入，表示我还没输入，系统就反馈我是错误的了，我错在哪了？并且加大了我的阻碍，就相当于，你正在走路，时不时的被拌一下的那种感觉。发了很大的火，投诉到了老板那里。
聪明的大家也知道了问题！那就是「表单实时校验」的场景运用问题！
老板也试了一下。单手拍头，我草，去帮他解决一下吧。你看一下你就知道了。
老江湖看到这表单创建体验了一下流程，微微一笑。写出了以下问题：

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