2023年B端设计｜需求转化设计

B端设计｜需求转化设计需求与设计是不行分开的，当然指的是用户需求，产品会将用户需求转化产品需求，而设计需要在用户需求过程中有更多的参加感，才能为设计更加恰当的内容，并削减返工。

一、设计执行过程

工作中设计侧理解的需求实际任务指标，是经过加工，呈现出很直观的任务要求点，比如这里加一点，那里加这种交互规章设计模式，组件控件什么的。

需求和设计实际上也隔离开的，中间是产品的转述，而常修改的缘由大多在此处。设计师的目的应当是加入产品中间商，做一手的需求参加者。

二、需求转化过程

先来说下，从需求转化设计执行的一个基本过程，整个过程中，真正独立设计页面是很小的部分，大多数整理【需求】和【开发】。但也可以说设计是穿插在整个过程中的。

三、需求设计问题

补充需求，即在现有的的需求基础上新增额外的需求内容，而新需求常消失的阶段在【设计模块】及之后，也有在此之前补充，但影响不大，由于前边流程都在对需求整理阶段，新增需求没啥大的影响。

影响比较大的是在【设计模块】之后，后几个阶段穿插进来的需求，会遇到几个问题：

是否需要调整设计页面；前端是否需要返工；前后端接口是否转变。始终以来的操作就是设计重做，前端重做，后端可能改接口，硬需求下，后两种操作可能无法避开，而设计这一侧可以考虑下，能否在当前页面承载新需求，极少的改动，同时削减前端的返工？

四、需求设计要求

接收完整需求

对需求的理解：在沟通的同时，摸清业务的脉络，搞清晰基本框架结构和节点，不仅仅是了解业务，而是在听懂需求的同时，不断完善设计构思框架；快速反应需求与设计画面框架的结合：在构思框架的同时，同步将理解后的需求在大脑中与组件相匹配，节点部分登记来；以过平常规操作补充需求做法：以阅历之谈，常规操作方式，最简洁最易被使用者接受，能做简洁笔画勾画，可待后续进行完善。在当前需求下预制可能消失的新需求，不影响现有结构？这个是需要设计师思索的一个点。

五、解决方式

前面几篇文章已有提到，拆解了各个设计模块的设计内容，介绍了在B端设计中的数据表格、表单、控件等设计思路和样式。这些思路的来源是：

将需求场景分类，划分到各个设计模块中，这点是基础步骤；为在可能后加的新需求中，在表格、表单等组件做预设扩展空间。六、操作步骤

场景分类：

上边提的表单、表格，组件都有说到。这里的原始需求放在设计上就是将基础组件扩展，留下扩展空间（需要和前端提前沟通）。

比如说：

多级弹窗；列表嵌套层级表格、表单；树状结构嵌套列表、表单、表格；问卷基础表单、问卷题型（题目条件简单性以及题目之间的关联性）。这几个场景类型里各自消失的衍生问题如何解决：

1.多级弹窗

这里要说到对使用弹窗的要求：一种是多级弹窗之间操作功能是相对分割的，一种弹窗之间是相互关联需要对比数据的。

前者可以用一般弹窗也就是叠加，类似win系统中病毒一样的，可以解决无限多级弹窗。亦或是蒙层叠加掩盖，只显示当前弹窗内容。

后者需要对比的，可以采纳浮层+抽屉，相互叠加，数据比照。右图：

2.列表嵌套表格、表单

医疗数据中，基础的数据列表形式，不能实际业务需求，在考虑基础设计模式，后续新需求的考量也是需要建立在基础设计模式上，因此在设计时需要留下扩展空间，而不至于重构。

场景：

列表呈现的数据，左右上下扩展数据，可通过滑动模块完成设计。只需查看数据部分关键字段还需要重复点击进入详情是不行取的。

需要对列表内部进行扩展，扩展的选择一种是表格（表格又可进行切换调整），一种是表单（表单又可进行模块划分）。因此扩展空间增大了。

3.树状结构嵌套列表、表单、表格

同理医疗数据讨论的简单性，树结构应用在导航，层级关系的基础场景内。简单业务要求树结构担当更多的功能。因此面对后续需求还是需要从内部扩展（与前端沟通）。

在信息结构的层级关系下，需要查看每一个层级的详细的具体信息，而常规的树结构与详情左右分割，不被允许，关联性不够。

4.问卷基础表单、问卷题型（题目条件简单性以及题目之间的关联性）

基础问卷类型，线上有供应的问卷星、腾讯问卷等都可以满意的。自己开发一套，是由于数据的平安的，由于需求是变动，所以在基础上需增加更多的组件类型模块内容。

题型之间有关联性，当前题型的设置的条件才能触发链接到指定一题，或跳转一题，那原本的题型还需增加设置项。

七、总结

对B端设计来说，理解需求、沟通需求、转化需求，是项必需具备的增长力量。需求争论的过程中构建需求房子框架，基本的心理建设模型应当建立起来了，未知的地方也应当打上标签了，后续的就是一点点将疑点清楚化。