到底什么是好的B端产品设计?

0 评论 4636 浏览 24 收藏 13 分钟

作为一名B端产品经理,你知道如何做好B端产品设计吗?或者换个问法,什么样的设计,才称得上是好的B端产品设计?也许,你可以抓准“结构”,在结构层进行更完善的产品搭建。本篇文章里,作者就“结构”在B端产品设计中的关系发表了他的看法,一起来看看吧。

之前写过一篇文章《到底什么是B端产品的用户体验?》,用提问的方式道出了我个人对B端产品用户需求层次的理解。

用户体验是肉眼可见的一面,在B端产品里,还有看不到的一面——系统结构,它直接决定了产品重构的生命周期,直接决定这个系统设计的好与坏。

为何要如此夸夸其谈?

乔布斯小时候,他爸爸做一个橱柜,背面也用好木头。乔布斯十分不解:“背面又看不见,为什么还这么重视?”爸爸说:“看不见的地方与能看见的地方一样重要。”后来,乔布斯做苹果电脑时,要求里面的线路必须整齐。工程师把看不见的地方做得精致,已经超脱了产品本身,而是艺术之品,是对另一种追求。

同样,软件产品背面的木板也理应炮制有方,理之有序。即使我们作为凡夫俗子无法理解高境界的艺术境界去追求极致,至少也该对系统系统的重构周期尽可能长做出结构优美的设计。

一、什么是结构?

字典释义:由组成整体的各部分的搭配和安排。

如果您有阅读我的历史文章《系统是什么?》会知道,结构实则就是系统三大件(系统目标、组成部分、关系)中的关系,它随处可见:天体之间是万有引力,自然界是物质和能量交换,经济领域是价值交换,建筑领域是力学,系统领域则是逻辑等等。

二、结构为什么对B端产品如此重要?

到底什么是好的B端产品设计?

图1 结构示意

1. 结构对系统形成稳定支撑

建筑结构基于力学的精密应用,承载摩天大楼历经风雨不塌;系统结构基于逻辑学的精密应用,承担B端产品的经久迭代可用。

这似乎也是架构师的核心使命:通过对复杂环境的信息收集,对信息进行分类归总,并赋予它们最优逻辑联系,最终建立秩序,从而支撑产品即使应对复杂外部环境的变化,也能支持持续的优化和升级。图1,左右两侧都构建出了支撑结构。

2. 结构是一种化繁为简

熵增定律:要让一切的无序变得有序,必须做功,如我们身体需要摄入能量支持新陈代谢做功,来保持有序(健康)状态。

系统设计一样,起初是一堆无序信息,经由智力做功,对其分类、归总、建模,终而形成简单且易于理解的结构,做功能效越高,结构越抽象越简单,且蕴含的势能也越大。

图1中,通过三条与边垂直的相交,且保持120°的直线形成内部结构,完全可以支撑“承重”,优美、简单、清晰;右侧的“承重结构”,但纷繁复杂,难以理解,明显是没有智力做功,或做功效率低下的结果(我们的系统何尝不是慢慢从左侧变成右侧)。

3. 结构有助于统一上下文

清晰简单,易于理解,会便于交流与思想同步。团队的配合的最高境界是“默契”。而结构何尝不能达到这个境界?给定一个输入,通过结构的逻辑链路就可以通过结构大致推断出一个输出,何须反复澄清?

4. 结构有助于查找问题

结构清晰,意味着构件的职责分工清楚,构件之间的逻辑关系明确。系统一旦暴露问题,通过表象就可直达问题根源,容易定位。

三、怎样才算是好的结构?

从图1中,结构的好与坏一目了然。

左侧,三条长度相等,相交120°,形成完整的“承重结构”,实用而美观。我们作为系统“设计师”,也多少要有一点艺术的极致追求,赋予系统结构些许的赏心悦目。

1. 清晰的系统目标

做系统一定不是为了做而做,而是有意义驱动,这个意义构成了系统目标,或者说是此系统的第一性原理。反过来说:如果目标不清晰或有所偏离,从根上就不正确,基于此构建的系统也必定是无效的,更无优美可言。

有时会存在目标尚不晰的情况下边干边看,来争取时间的场景。这时,需要依靠敏捷迭代来逐步保证目标的正确性(关于系统目标这部分,建议延伸阅读历史文章《“第一性原理”在B端产品设计中的运用》有更深入的讲解)。

2. 构件职责单一

“单一职责”原则,您应该多少有听过。无论是大到经济领域的专业分工,小到系统构件的单一职责,都是在讲避免“眉毛胡子一把抓”导致哪方面都做不好的情形。一个构件一个职责,十个构件便是十个职责,通过数个构件职责的相互关系便可以达成系统的整体目标。

这背后的原理也很简单:低维简单问题易于高维复杂问题。将高维复杂问题进行切割,到我们能够妥善处理的粒度,多个简单问题妥善解决后,复杂问题也就随之解决(来源于还原论)。

3. 构件关系简单

与其说简单,不如说弱依赖。在系统设计时,十分忌讳“强依赖”(A宕了,B就停止工作了),它是系统设计的灾难。

构件之间,尽可能做到少依赖、弱依赖:尽可能在A宕掉的时候,B还能自闭环地正常工作,这样客户的业务才可能不受阻碍,系统才会有一定的柔性。

想做到2和3极度不易但并非不能达到。在1的指导下,不断循环2和3,直到纳什均衡(没有任何可以改进的空间),其结果便是构件职责分工清楚,构件之间的依赖极少或者极弱。

四、怎么做好结构?

做好结构,基本等于做好系统。还是离不开系统三要件:系统目标清晰、构件职责单一、构件关系简单。

既然好的结构是严密的逻辑推导,那么也不得不使用科学的方法帮助实现。这里就不得不提及应对复杂系统设计的方法论:领域驱动设计(DDD,Domain-Driven Design),这并不是什么横空出世的新鲜玩意儿,这是Eric Evans在2003年就提出的一个近20年的设计思想,其核心目的是解决复杂软件架构设计。

对于复杂的B端产品,DDD的设计思想再合适不过,但要领会其中的要义,也并非一日之寒。

DDD包含战略和战术两大部分内容,对于B端产品经理,建议掌握战略部分:商业逻辑、核心业务流程设计、用例设计、实体识别状态图设计、领域模型设计、限界上下文识别机映射的设计。

由于DDD是套体系方法论,限于篇幅,本文仅能对推导逻辑,进行简单介绍,建议延伸阅读此大佬的系列文章,当然也可私信交流,若有必要,我也可以后续撰专文介绍。

DDD战略设计实战方法逻辑:

1)商业画布确定商业逻辑

商业模式画布理清供与需的匹配关系。

  • 根据细分客户(CS)的价值诉求,确定供给的价值主张(VP),价值主张成为连接供需关系的衔接点。
  • 发挥核心资源(KR)及重要合作伙伴(KP)的能量,,策划自己的关键业务(KA)。
  • 关键业务需要涵盖,触达细分客户的渠道通路(CH),以及客户关系(CR)的手段及方式,达到让客户接触到价值主张,并持续认可,甚至增值的目的。
  • 支撑这一切活动的底层离不开ROI的科学测算,包含收入来源(RS)和成本结构(CS)。

2)明确系统愿景

在1的内容中,梳理出这件事情的利益干系人,每个利益干系人都有在这个系统中的角色及心理目标,整合这些目标,形成系统愿景。并将愿景拆分成不同阶段实现。

3)串连核心场景

有了1和2,可以策划解决方案。识别出几个关键的场景,将它们串连形成闭环的解决方案。

4)拆解每个核心场景

3中识别出来的关键场景理应都是自闭环的场景,所以也理应有自己的运作业务、角色以及用例,尝试用流程图和用例图两个视角将其表达出来。

5)识别核心业务时标对象及状态流转

在拆解核心场景时,一定会涉及到业务单据,将其记录下来,若单据有跟随时间、事件、动作发生状态转移,则需要绘制出它的状态图。

6)理清业务对象之间的关系

除了5中的业务单据,还有其他的的业务对象,识别出来后,通过领域模型(Domain Model)表达出他们之间的关系,以让开发同学一目了然。

7)限界上下文与上下文映射

这部分较难,且更偏重技术的服务拆分,也是DDD中“高内聚,低耦合”思想的重要呈现。但对产品经理而言,是“nice to have”,并非必须,有兴趣的产品经理可以进一步掌握。

1-6,更偏商业逻辑到用户相关的业务信息的梳理。这部分的清、干净、闭环地呈现,对架构师往后的设计以及工程师的编码工作具备十分具有指导意义。也就是说,1-6的优美,引导着整个系统结构的优美。

五、总结

万物皆系统,系统内部定有工作结构。天造系统,窥其结构,十分优美,经久不衰;人造系统,理应学习,讲究结构,方可存活长久。

无论是系统延续需要,还是设计者的造诣追求,结构都应该精致优美。

科学的方法是保证这一切得以实现的基础。个人认为DDD是目前较为合适B端复杂产品设计的方法论,但理解不易。

欢迎我们一起学习探讨,愿企服领域有了我们发展更好。

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

题图来自 Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!