『顶级』一个PRD的诞生 | 教新手设计一个顶级表单定制后台PRD( 七 )


为什么要这样做?
想必你也知道了——这毕竟是一个表单系统,表单系统的基石就是字段,字段在未来的扩充肯定是相当频繁的。
这张表看起来现在还没什么,但是如果不去这样设计它,那么你每一次迭代这个系统,都要花一半的时间去修改每个具体页面所展现的字段。真要这样头铁,那么恭喜你,你离人类的本质越走越近了。
 『顶级』一个PRD的诞生 | 教新手设计一个顶级表单定制后台PRD
文章图片
你说,你没有我这么多的后台设计经验,不知道字段表需要拆出来单独维护,不知道要把频繁更新的功能放进中转页,也不知道不同层级的模块要怎么拆分、怎么互相连接?再看一眼这一章的标题:“有坚不摧”的对象继承链条。
没有任何文档撰写套路是无坚不摧的。如果有一篇文章在你的feed里冒出来,告诉你“掌握这20个技巧,就能让你设计一个专业的XXXX原型”,那么你应该赶紧点进去屏蔽这个人,然后再举报这篇文章,然后再返回你的feed点击“我不感兴趣”。
你唯一能做的,就是每次反省自己原型设计的问题,每次迭代的时候看一看自己做了多少无用功,把每个周末的时间都花在完善自己的文档上,力图让它达到你现在的100分。然后等下一次迭代的时候,轻蔑地看它一眼,说一声“垃圾原型,50分鉴定完毕”,存个版本,然后开一个新的文档,把有用的东西复制进来,把没用的结构打散扔掉,然后再力图把它变成新的100分……
结语
在结语部分,我们先用一张关系图来回顾一下,前两章我花了那么大的篇幅来讲原型的绘制,我到底讲了什么。
 『顶级』一个PRD的诞生 | 教新手设计一个顶级表单定制后台PRD
文章图片
是的,我检查了很多遍,我仔细检查了右图的每个方块、每条连线,最后我才说服自己相信,这张关系图已经完整、没有遗漏地,表达了我在前面两个章节煞费口舌地描述的所有模块之间的关系。
我统计了一下,那两个章节我写了大概4400字,其中用来表述模块之间的关联关系的,我们算它有3000字。而图表里面的汉字是128字。图表里除了汉字之外,就只剩下方块、位置、线条这些图形关系了。所以,图形带来的文字表达效率之比是24比1。
——你需要注意的是,我画的是关系图,而不是流程图。流程图是具有方向性的,本质上只是更简洁的文字。而关系图是没有方向性的,从任何一个局部都可以顺着线条向外推导,推导出任何你想讲述的故事。
关系图是简洁、低调和安静的,但正如老刘说的:“记得大三的一次信息课中,教授挂出了两幅大图片,一幅是画面庞杂精细的《清明上河图》,另一幅是一张空旷的天空照片,空荡荡的蓝天上只有一缕似有似无的白云。教授问这两幅画中哪一幅所包含的信息量更大,答案是后者要比前者大一至两个数量级”。
这就是我在文章开头提到的,我多么希望我能掌握《降临》里外星人使用的表意文字。为了讲清楚我的产品设计思路,我讲了很多的话,你花了很久的功夫来阅读。但是实际上,我真正希望你掌握的,是这门安静的语言,是纯粹图形化的思维。我指的不光是前面的原型绘制部分,其实更包括后端逻辑文档的部分,它们都可以被图形化。
事实上,在我写完这篇教程之前,我根本不知道原来我要讲这么多的话。整个产品的设计过程里,我的脑子里基本是不存在语言的,只有一个个的形状像狄拉克海那样,从虚空里不断潮起潮落。你把它们摘下来,不断地重组它们,当你把它们捏成一团一团之后,你会发现,你已经完成了对一个产品的整个设计过程。
当你越来越适应这种图形化思维之后,你会发现,你能比别人快很多倍地构思一个复杂的系统出来。唯一的缺点是,你的图形思维模块会侵占你的语言中枢——更说不过那些喜欢讲ppt的人了。
【 『顶级』一个PRD的诞生 | 教新手设计一个顶级表单定制后台PRD】题图来自Unsplash,基于CC0协议


推荐阅读