B端产品不止是业务结构庞大,信息复杂,同时其业务的精确性也有很高的要求,服务于B端的业务,不能够出信息错误,填错一个信息,就会引发巨大的问题。本文为你讲解,大型B端业务中的设计方法。 一 、业务细节 1. 业务配置细节 任何一个行业都有他的业务单元,每一项服务是不一样的。 比如一艘船要换船员,要换现金,那么这就是服务单元;比如你在阿里云买服务器是不是要选CPU、内存等配置? 也就是说,将现有业务进行整理,将具体的业务细节配置梳理清楚——每一个指标是怎么填的?填什么单位?什么时候填?有什么限制?什么时候又不能填了? 比如船都出海了,你还能要求换船员吗?就不能了,这就是有这个船是否在港的限制。 具体的配置内容会很多,这时候就需要你的信息结构能力。 如果业务很大很复杂,那就进行拆分,将大业务,拆分成一个一个小业务。然后再把每一个小业务,花时间理解透彻,确定好业务流程和内容。其他的小业务也是这样梳理,拆分到你可以控制的范围,最后再把业务组装起来。 如果你能处理好每一个小业务,那么组装起来之后,你就会理解整个业务。 2. 关键节点 每一项业务都有他从开始到结束的流程,期间一个节点到下一个节点是如何操作的,就是关键节点。比如:船要卸货,那么就要有卸货许可,你得拿到这个许可,有效,才会让你卸货。 根据关键节点,你肯定要对不同的业务设计功能,这也是做这个大型B端业务的重点。同时,你在设计界面的时候,一定要标识清楚业务的状态,当前用户需要做什么?你不能等着用户去做,你得提示他进行下一步。 关键节点就是业务过程中的判断节点,会根据这个判断得到下一步的结果,这个部分在业务梳理过程中会发现,同时在与业务进行沟通的时候,也会得到这部分信息,记得记录下来。 3. 业务状态 这就说到业务状态了,业务是完成还是没完成?中途遇到什么问题了?要预付款吗?有意外情况吗?你想呀,在实际航海过程中,这样的问题数不胜数,你得有很好的状态呈现,即时反馈对不对? 用户使用产品的时候,一定会关心当前的状态,就像是你在淘宝买了商品,你会关心是否付款,物流情况,退款、退货情况等等。 同样的道理,做B端业务的时候,产品设计到一定程度的时候,很多小的业务提示,需要很好的呈现,其中包含: 业务状态(类比电商预定状态、有哪些商品) 当前服务状态(类比当前订单状态) 服务配置状态(类比商品大小、颜色、款式、数量等状态) 服务中途的状态变化(类比物流状态) 订单支付状态(类比电商支付状态,但是周期不一样) 4. 用户掌控感 用户原本都是在线下完成业务的,你突然要用线上的,掌控感肯定没那么强,所以必须要让用户感到有掌控感。 比如:编辑是不是可以撤销?订单什么时候可以取消?我什么时候要付钱?用户如果中途取消订单或者取消订单里面的一个服务,怎么办? 尽可能的考虑实际情况,从实际情况出发,不要把互联网这一套搬过去,这样会让用户觉得很难用。 B端业务实际中会遇到很多情况,在进行产品设计过程中,天然的和线下操作是不同的,不同点在于: 很多以前线下通过邮件、电话、口头、文件、签字等传达的信息,线上必须进行全覆盖。 因为线上话之后,一切信息都需要通过软件呈现,所以,以前线下没有的,为了业务完好的在软件中完成,还需要根据实际情况配备。 基本原则:凡事有回音,事事有反馈。 二、产品效率 1. 如何设计高效率的B端产品? 我们都知道,B端业务复杂,功能多、流程多,但是用户还是很重视效率,这个时候怎么办?你就得把用户高频和低频的需求分开,主线流程要清晰,常看的状态一定要摆出来,有些功能藏起来了,用户需要的时候,就要放出来。 比如:订单的金额,就必须呈现出来,但是具体细节要藏起来,用户可以随时进去看,有变动的时候要提示出来。 这是什么设计思路?也就是,用户需要的时候才出现。 用最简单的表达做B端产品: 能不说的废话,就不要说(比如:明明不需要提示文案,非要写一句文案,反而让用户迷惑) 能减少的操作,一定要减少(比如:为了创建一个内容,非要用户先去命名,但是完全可以不用的) 主题流程一定要明确(比如:整体流程设计成类似电商的购物流程,而不是自己重新设计一套流程) 能隐藏的信息,就隐藏(比如:用户当前完全用不到的配置信息,呈现出来,反而迷惑) 2. 如何评估产品效率? 从流程上看,用户的操作步数是不是最简单的步数? 从界面呈现上看,有些业务表单特别多,这个时候表单设计是否科学就很重要。 从时间上看,进行可用性测试,看用户的操作时长,看用户操作完一个订单需要多久? 用户操作错误情况,看用户误操作的次数,用户误操作一定是产品设计问题。 让一个完全外行的人,使用你的产品,看学习成本有多高? 如果以上5点,都达到一个良好的情况,那么恭喜你,你的产品经理为你节省了大笔资金和时间,至少是百万级别的。 交叉分析法 我在当时整理业务时用到的方法,因为最开始并不了解这个业务,一直弄不明白怎么才算一个Case,不像电商,加入购物车、结算、填地址信息就好了。 所以,我想办法做了一个分析: 这是一个元数据的运用,这个概念是出现在《web信息架构》这本书里面的核心概念,就是:你这个关键信息是如何构成的?构成方式有哪些? 当时就搞不懂,到底是以港口为主线,还是以船为主线,最后我们看图中绿色的点就可以看出,以船为中心是一条直线,也更吻合船东的操作。 所以,最终得出了这个公式,并设计成了这样的信息结构,以航程为核心,每一个航程附带上订单的结构。 最后的话 我始终认为产品经理的能力是通用的,不管业务怎么变,仍然是这套方法论,只是优秀的产品经理更加灵活,更加能够看到事物的本质。 更多相关阅读 如何设计大型B端产品?前人的经验,帮你少走弯路(上)