3 分钟产品哲学 | 为什么产品研发团队要做一套自己的组件库?

3 分钟产品哲学,带你一同领略数字化转型的产品设计之道。

组件库 (或者叫 “UI 控件库”) 是设计系统的组成部分之一。如果有能力,产品研发团队应该构建并维护一套自己的组件库。有些工程师可能会问:“为什么要自己做组件库?为什么不用现成的,比如 Bootstrap? ”

产品研发团队的目标是研发产品,而不是研发组件。因为用户并不想要组件库,而且产品团队的条件往往十分有限: 需求不明确,资源不足,进度紧张。每天不是在改改改,就是在修 Bug。为什么要把宝贵的时间和精力浪费在做组件上?


在回答这个问题之前,我想先谈谈 MVP (minimum viable product)

最简可行产品是指以最低成本尽可能展现核心概念的产品策略,即是指用最快、最简明的方式建立一个可用的产品原型,这个原型要表达出你产品最终想要的效果,然后通过迭代来完善细节。

一个 MVP 是一种策略和流程指向制造和销售产品给客户。 它是构思一代,原型,演示,数据收集,分析和学习一个反复的过程。

最简可行产品 – MBA智库百科

你可能看过敏捷专家 Henrik Kniberg 的这幅漫画。面对产品/市场契合度的不确定性,MVP 是一个合理而且非常流行的模式。好产品不是闭门造车设计出来的,而是根据用户的反馈不断改出来的。

如果用户想要代步工具,那么当你卖给他一个顶级的轮胎时,他会满意吗?不会。尽管你可能知道汽车是由轮胎等零部件组装出来,但对于用户来说,这些组件毫无价值。所以,我们应该先做一个滑板,再升级成自行车、最后才变成我们想要的汽车。这样,才可以尽早检验功能、快速试错,打造出用户满意的产品。

但是,这张漫画是不是缺了点什么?


这是设计师 Luke Wroblewski 最近发的一张图。同样是从滑板,到自行车,再到汽车的例子,不同的是,这张图里展示了产品背后的组件,以及它们的种类和数量。用户体验越好,需要的组件就越多,组件的质量也越高。

不熟悉产品研发过程的人,很容易对第一张关于 MVP 的漫画产生误解: 是不是只要拿着滑板到市场里找到客户,签下订单;然后用赚到的钱去买更好的原材料,找一个新的工厂,就可以拿着造好的自行车和汽车去卖了?

作为软件的开发者,你不会有这种误解。因为维护代码的人是你,你知道代码是不会从天上掉下来的,只有锅会从天上掉下来。当你加入一个新团队,最怕的就是前人留下的屎一样的代码。💩 研发团队应该清楚,产品不仅需要做出来,还需要不断维护。而可维护性,是研发团队一直要解决的难题。(除非你的公司满足于只卖滑板,或者研发工作可以外包。)

熟悉 MVP 理论、有经验的产品经理也很清楚,团队不应该先把精力都花在制造最好的汽车轮胎上。我们需要的是,做出一个足够好的小轮子,让滑板动起来,再把滑板拿到市场上寻找客户;但与此同时,产品研发团队必须对自己的小轮子负责。因为如果 MVP 能获得良好的市场反馈,研发团队接下来就必须把这个小轮子升级成自行车轮胎,最后经过研发和测试,改造成足够结实、耐用的汽车轮胎,让更多客户满意。

https://designsystemsrepo.com/

产品研发工作不是一蹴而就的,研发团队需要持续地维护产品。所以,研发团队也需要持续地升级已有组件、扩展组件库的种类和数量。MVP 模式给产品的迭代争取了时间。但是,当我们在打造产品的下一个迭代版本时,我们不能一直忽视打磨组件库的工作。因为组件是产品的一部分;而组件库为团队工作提供了规范,降低了复杂性,提升了可维护性。

原文链接:https://zhuanlan.zhihu.com/p/35791679