TO B产品设计专题(2): 8种填单场景和设计要点(兴奋型3种)

2 评论 2558 浏览 21 收藏 8 分钟

编辑导语:填单是TO B产品设计中最普遍的功能,本文通过剖析8种填单场景,讨论其发生原因、原型实现、设计要素,从而总结TO B产品的点滴设计方法;本文继续分享另外三个场景,我们一起来看一下。

俗语有言:管中窥豹可见一斑。

TO B,我们在路上~~

一、TO B产品8种填单场景KANO模型图

在上篇文章《TO B产品设计专题(1): 8种填单场景和设计要点(基础5种)》中,围绕TO B的5种场景,我们做了详细分析;本文将围绕剩余的“兴奋型”3个场景进行阐述。

二、分享填单场景

1. 为什么要分享填单场景

分享填单是指企业用户通过分享个人单据给他人,从而帮助他人填单的场景,分享填单是从现实生活中引申而来而非意淫的场景。

比如、现实中很多企业用户在填单时,在寻求IT专业客服帮助之前,都会先找身边好友咨询:这个业务应该填哪张单?这个字段你之前是怎么填的?

所以、一个设计一定要先从现实中找到影子,然后再去IT化、智能化。

当然,分享场景这个现实中的影子存在着特别多的痛点,这些痛点极大阻碍了其有序推行广泛发展。

我总结有如下几个痛点:

  • 不知道谁填过:职场人的工作内容具备一定保密性,故而职场人是很难找到发生同样业务的人,这也就从源头掐断了分享的可能;换言之,帮助职场人找到分享人是万事第一步。
  • 不耐总是打扰:分享人的主责工作不是教其他人操作填单,所以通过面对面的去咨询他人一个个问题,分享人心理层非常矛盾:我又不好一口回绝你,我又怕你一直打扰我日常工作。

所以,要是IT系统能够解决“不知道谁填过、不耐总是打扰”这两个痛点,一切也迎刃而解。

2. 分享填单场景流程图

下图为我项目中的一个分享填单场景泳道图,该功能已系统化并推广运行:

3. 分享填单设计要点

下面再为各位总结下分享填单的设计要点,共4条要点:

  • 被分享单据必须做脱敏动作:脱敏可以由系统规则而定,也可由分享人二次脱敏确认分享单据;
  • 找到谁填过功能需做组织架构的限制:限制有助于准确找到分享人提升沟通效率;因为跨中心级去找人,用户即使找到了也不认识这个人,更无法去请求分享。
  • 分享人信息需做脱敏控制,比如控制逻辑为:显示姓名、显示日期、显示手机号、显示单据号、显示关键词;
  • 直接编辑分享单需新建填单页:当填单人已填写了部分内容后,这时使用分享填单功能,分享单据最好不要覆盖填单人已填的单据内容,而应该另起一页作为参考。

三、业务发生源填单场景

1. 为什么要业务发生源填单

业务发生源填单是指TO B产品要设计成以业务发生源头来驱动填单,概念不是很好理解,我们用例子来说明。

就比如下图中,广告费、推广费、展台费全部使用A单据来进行填单;这3类费用就是“业务发生源”,用户可能不知道A单据是怎样填写,因为这需要学习成本,可用户一定知道自己发生了这样一笔业务。

所以,系统会根据权限给用户分配业务发生源,用户只需勾选业务发生源,再补充填写一些业务数据,系统就自动将A单据相应数据进行填充;用户根本不需要去了解系统黑盒子内的所有系统级关联。

这是TO B产品非常大的特点,C端产品用户理解起来非常简单,TO B端产品很多业务用不起来,并不是系统体验有问题,而是系统背后的业务逻辑非常复杂;所以隐藏掉系统逻辑,开放业务发生源入口给用户,这可极大提升TO B产品的使用。

2. 业务现场填单设计要点

业务发生源颗粒度有一定的要求,不能太细造成筛选困难,也不能太粗造成权限无法划分。

业务发生源要和系统有紧密的关联关系,只要选择发生源和补充数据,则系统层面的晦涩难懂的业务字段就自动选中了,这样做可降低单据填写成本;比如广告费业务源维护好后,则A单据中大量偏广告类字段就自动选中;推广费业务源维护好后,则A单据中大量偏推广类字段也会自动选中。

四、AI语音填单场景

1. 为何需要AI语音填单场景

我们不要将目光聚焦在AI语音的能力不足这个现实,而应该将目光投射在AI语音的未来;AI语音的需求不是一个语音能力,而是一个“不用开工资的秘书”。

设想一下,您说一句话“给我订一张6号去北京的便宜点的机票,并且看一下高铁多少钱,哪个便宜就选哪个”,智能机器人依据智能算法而执行你的指令;而不用你操心,这不就是未来?

现在的AI语音只因缺失足够的智能,所以人类才觉得其非常鸡肋;不过万事不可绝对、有一些固化的场景还是具备使用AI语音实践条件的;比如订火车票、比如电器问题排查。

五、从TO B的填单场景设计方法总结的工作方法

  • TO B必须关注多个角色的场景;C的用户是一类用户一类场景;而B有多类人群多个场景;
  • TO B需求必须从现实中找到影子,C可以天马行空;
  • TO B的配置一定要足够丰富,这决定产品是否可用的关键,否则一定会有人以“不满足我”作为借口而拒绝使用产品;
  • TO B产品需考虑使用人的知识边界,因为TO B的使用者都非系统的业务熟悉者;

 

本文由 @ boyka  原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 专题会每周持续更新 感谢各位订阅

    回复
  2. 欢迎大家留言沟通

    回复