JELLY | 从需求调研到设计落地的工作实践

• 细微修改文案（不超过1句话的调整），Notion AI / Summarize 的描述在语序和侧重上会有所调整。

• 文中绿色字体为 Notion AI / Change tone / Professional 参与修正的部分。相同内容使用 Notion AI / Improve writing 效果不佳，逐字未改。

• 本次测试 Notion AI 主要给予了删除废话和语病纠错的帮助。

全文约2680字，预计阅读9分钟。

这是一次漫长的“支线”工作实践中，作为交互设计师与上游产品经理、商品规划合作，与日常需求并行，我们一起从发现问题到解决问题，从需求调研到设计落地。相比未知的结果，过程之中已收获良多，这是促使我在结果未知的情况下，就进行这次阶段复盘的重要原因。在以数据结果为导向的时代，先来看看过程。

背景简介

京东慧采，是面向大型企业客户，为提升企业采购协同效率，打造的专属综合集采解决方案。

其中的企业场景馆，是客户端服务于企业固定场景采购的“频道页”，由人工设置一/二级场景类别与选品规则，在前台以商品列表形式推荐给客户采购员，辅助其选品工作。

上线运营以来，二级场景馆数量不断增加至上百，但客户渗透并不理想。最初的设计预研便以“提升场景馆引流效率”为目标。拆解如下关键动作，输出设计预研报告及优化方案。

• 提升有效场景曝光
• 入口样式优化提升吸引力
• 层级优化减少操作步骤
• 关联推荐增加曝光次数

有关“设计预研”的个人理解：相较被动接收产品需求而进行的界面方案设计，主动前置调研分析，从目标设定到设计方案呈现。在此基础上尝试沟通上下游，推动方案落地。练习拓展岗位角色职能，提升参与度和影响力。

偶然的契机，让貌似结束的工作变成开始。预研中提及的体验问题和对优化方案的验证需求，触发了进一步安排“客户调研”的可能。下面我就从调研开始，复盘本次项目的一些心得收获：

#1

需求层面解决问题不精准，表层设计优化价值有限。

调研的开始，也是臆想的了结。几轮访谈下来，我们的首要结论便是：客户并非因为功能入口深、吸引力度不够，功能解释不完善等问题导致不够了解，从而没能积极参与使用产品功能。更为扎心的是，客户可能是在尝试后才不予理睬的，因为这项产品能力并不能帮助其工作提效产生价值。

那这一切该被彻底暂停吗？显然也不是。访谈同步验证了，企业客户的场景化采购需求是明显的，但我们所理解并提供的场景，似乎与客户需要的采购场景并不对位。

举例说明，我们将满足“办公采购”这样广泛场景的商品“一股脑”放到一起，让客户自主挑选。而客户需要的则是个性化的，可以在规定时间以明确的采购要求（价格区间/库存量/发货地等），快速决策的性价比相对合适的商品。

面对多元细分采购需求无法通过线上满足的现状，客户自然延续线下沟通服务人员的解决方式。相比在线上耐心寻找符合要求的商品，通过给专属客服发送一份要求（带有“物项名称”“物项规格”“单位”“订货数量”等信息的表格），等待接收专业人员制作的推荐商品清单决策下单，自然更轻松便捷一些。

在AI智能还没能充分理解复杂需求并广泛应用的当下，这份耗时琐碎的工作依旧需要人工来完成。从接受客户需求，提报系统、沟通采销，到推荐方案的制作输出都需要人力和时间，客户的耐心有限，运营的工作重点也不在此，运转效率低的同时也易错失商机。

但我们也从中也看到了一个新的目标：如何更便捷地帮助客户生成具体的场景采购方案。

面对产品功能与所服务场景的低匹配度，回顾前期产品界面交互在结构/框架/表现层的分析优化，或许可以让操作丝滑、吸引点击，完成某个阶段的指标，但缺乏真实有效的价值提供，我们又有什么理由留住客户呢。

#2

充分理解并运用需求规律，让产品更加主动与用户互动。

作为面向企业提供采购解决方案的服务工具，产品以往更多的是被动接受客户企业的需求，快速响应支持。

但除保障产品必备属性和无差异属性的基础体验外，为了维持用户对产品的满意度，我们或还需要思考如何主动为用户提供期望属性，甚至魅力属性。

通过调研，我们发现企业除日常零散采购外，同时具有明确的规律性。举例如，固定节假日福利采购，从元旦到春节，与时间关联的采购场景是有迹可循的。当然，具体到不同行业地区，我们发现每月/季度都会有其特定的采购场景任务。

由此，结合时间、场景、行业和地区差异，前置为客户推荐采购方案的产品能力便成为了新的设计目标。远期的采购解决方案智能与自助化生成，尚需要基础设施建设和历史数据学习，回归当下还是需要“人”“机”结合来逐步实现。

结合现有资源能力，客户在线上已经逐步培养了自建“采购清单”的习惯（采购清单：客户自主创建维护的需求表单与商品关系），这里有大量分散但具体的采购需求，也是人工服务所不能遍及的。我们初期的试点便是在自建采购清单的基础上，标记官方场景归类，逐步让基于场景的推荐更有质量，形成质量互补。

另一方面，调整清单列表排序逻辑，由“创建时间”改为“采购时间”。选择日历作为承载容器， 从时间维度帮助客户管理采购待办，更快锚定高优采购任务，为后续在此基础上进行预测和推荐做准备。

表层界面交互像是冰山露水面的一角，背后优化的是更为复杂的产品与业务逻辑。重复第一部分所说，客户需要的是商品。好挑选，好交易，好售后。而这一次的尝试，就是希望服务于客户让其更好地挑选商品。

#3

界面交互方式，是短时资源和能力促成的适时样式。

以”采购日历”界面设计举例，从概念初稿到试点落地，前后变动调整多次。每版设计变动，伴随的是多轮沟通后，功能定位和所提供价值信心的变化。

第1版：仅在可以确切预测的采购期，在首页运营位有选择的进行高优推荐。

第2版：在首页新增专属楼层，按“月”维度提示待办采购，并关联少量推荐。

第3版：强化“采购日历”模式，直接改动原“计划清单”一级页面。新增日期筛选能力，轻量试水。

第4版：要改就彻底一点，列表与清单卡片同步优化，强调“日历待办”属性。

不久的将来，这些界面交互样式或许会由AI生成。展示哪些信息，权重又如何配比，仅需我们根据当下的资源能力做出选择判断即可。

但或许还需要一个前提，就是我们给出的prompts。如果没有“以日历形式组织”、“呈现采购待办”类似的信息约束，我相信AI的想象力是丰富的。就像前面提到的，需求场景定义过于宽泛，即使方向是正确的，就也还不能确切帮助用户达成目标，甚至比原始方法更消耗时间。而咒语的编写，应该还是需要我们去思考：要帮助哪些用户，通过何种行为方式，去达成怎样的目标。

#4

设计师在协作共创中，可以是更为理想化解决方案的提出者。

从个人经验出发，对接多种业务产品，使我们对界面交互样式的积累和理解更为多元丰富。而我们缺少的是对业务和产品实现逻辑的了解，但这或许会让我们以更开放的态度去设想解决方案。

当然，这也需要一个大前提，就是我们确实担任了更为贴近用户视角去思考的协同角色，而非站在自身视角说着以用户为中心的臆想。

在理想状态下，我们与产品经理的互动更多的变成了现实落地成本与理想解决方案之间的相互修正，我想这样的磨合过程对最终方案的产出是有益的。

#5

选择适当的分析工具可以提高沟通协作效率，而不为最终呈现看起来更“专业”。

“选择工具，延展分析，完成输出，一气呵成，至少是个态度，至少在尝试使用工具。” 这看起来很顺畅，但个人闷头输出的结果不出意外会有些局限。

在这次项目沟通中，提供可视化工具图示，让大家在一个共同分析框架下高效思考，和让大家在其中“指指点点”，具体可感地分享个人建议，都能让协同交流变得更加顺畅。

如下，便是我们使用到的一些工具：

指标拆解

涉及各角色分工与合作共识。

系统梳理

涉及各角色分工与合作共识。

体验走查

设计为主，其他角色参与门槛低，针对明显体验问题达成更广范围共识。

问卷调研

汇集多角色验证意向，以用户的声音为指导，辅助达成共识。

数据埋点

个人分析与团队分析无明显差异，仅为沟通背景共识。

写在最后

目前试点版方案正在落地进行中，这篇复盘暂且作为阶段小结。希望上线后，我还有胆量来续写验证结果和新一轮的收获。非常感谢这次业务/产品/设计的共创经历，过程虽漫长，但身心愉快，收获颇丰！