所谓的设计系统

[keelii]

是的，我今天就想批判一下那些披着「设计（系统 /语言）」外衣的研发工程师。

设计系统（ Design system ）这个概念应该是从国外最先有的。它的定义是：

A Design System is a set of interconnected patterns and shared practices coherently organized
设计系统是被统一组织起来的一系列紧密关联的模式和可重用的实践。

国内的组件库只有 Antd 在推出的时候声称自己是 一个 UI 设计语言，虽然当时我还不知道什么叫做设计语言，什么是设计系统。但是从工程师的角度我知道它就是 一套组件库。

一直到近两年，越来越多的前端团队以设计系统为排面推出自己的组件库的时候，我就觉得有些不对劲儿了。

哪里不对劲儿了？我在想我们实际上做的事情不就是设计了一套组件库吗，为什么要把设计放在前面。这似乎传达给我们一种信号：

我们应该是设计先行？我们应该优先做设计角度取舍。
相反的，工程层面实现那就应该向设计方向妥协？

我想并不是这样的，或者说不应该是这样的。

设计 永远是最上层的，它们关注的用户的外在、外观感受，它是感性的、多变的，没有唯一标准的。你很难想象用一套设计系统满足所有人的需求对吧？因为我喜欢蓝色，你喜欢红色这是不需要解释的。

工程 永远是最底层的，它关注事物内在的东西、自身属性，它是理性的、不变的，有迹可循的。所以工程层面追求的是一致、复用和效率。没人喜欢一个相同的组件在不同的实现上有不一样的 API 。

在「前端工程师」这个职位名字中，「前端」是个形容词，「工程师」才是名词。

我们得先是工程师再是前端对吧。当我们不由自主地和设计靠拢时，思维模式也受到了影响，似乎只有设计思维才会关注到那些形容词。

当我们在设计一套组件库的时候会遇到很多不一致的情况，在我的经验里面：

来自与设计和实现的不一致要多于纯粹实现层面的不一致。

当我们设计的组件库需要考虑到跨端情况的时候，我们的组件库应该有一套一致的 API 、一致的命名规则。但是从设计角度去决策的时候这件事情变得非常困难。

比如说：日期选择 这个组件，移动端通常叫做 DatePicker ，这个词强调的是用户的动作（ pick ），在 PC 端通常叫做 Calendar ，这个词强调的是组件本身的特征。

但是我们在工程实现层面真他妈不需要这种差别，它就是一个日期选择组件而已。

还有：按钮 组件的类型属性，有的是表形的：default/info/warning/error ，有的是表义的：primary/secondary/danger

再一次，我们在工程实现层面真他妈不需要这种差别。它就是一个简单的按钮而已。

造组件库的人没有想清楚这件事情，用组件库的人却得承受这种不一致。那什么组件库的设计者们没想清楚这件事情？

因为他们的思维也被设计系统带偏了。一味的追求设计上的形式化的一致，却忽略了工程上逻辑的一致。

当这股邪风吹来，没人会在意组件库的工程化设计，没人在意它好不好用，每个人都想复制粘贴快速实现一套组件库，然后再披上设计系统的外衣，为自己的似锦前程添砖加瓦...

[shadowmags]

别的我不懂，这个 DatePicker ，在 PC 端也是这个名字啊

[shadowmags]

DatePicker 和 Calendar ，意义明显不一样。和在哪个平台无关吧

[huntagain2008]

本人非程序员。我想说的和#1 一样，DatePicker 如果放在 dotnet 不都是 DatePicker 吗？也许你说的是 Android 开发里的 DatePicker,然后放在另一个开发平台，说它是桌面端，结果用了 Calendar 。如果真有这样的情况，也只能说明这两种开发平台不是一个标准。我记得某播客主持人说 C#、Java 都是背后有 IEEE 这样的组织，有一套国际标准的语言。那么在 C#、Java 这样的平台下，我以为并不存在楼主所说的“组件库 API 不一致、命名规则不一致”。

[murmur]

大概看明白楼主说什么，不过这种“design”的确方便了后端（ admin 部分）页面和企业应用设计
互联网还得自己有设计师或者外包设计

[cairnechen]

本来想说两句，看了楼主举的例子，还是让他留在这种自我陶醉里面吧

[kop1989]

我个人理解，这些组件库 /ui 框架在设计时，第一目标用户应该是 ui 设计师 /美工。
所以包含了很多设计概念，或者说 ui 概念。

很多大厂也是技术团队先推出内部的 ui 设计工具，然后在提供给 ui 设计师进行设计，最终 ui 设计工具直接生成界面代码 /伪代码。开发负责填入业务逻辑与数据流转。

小公司往往是前端≈开发+ui 设计。但换而言之，作为软件工程的实践者，我们在做交互、做界面的时候，是不是也应该适当的带入产品设计、ui 设计领域的思维来看待自己的作品呢？

[kop1989]

毕竟软件工程是一门工程学科，讲究的是最佳性价比。
那么盲目的追求最高内聚，最低耦合，最大复用，是不是也是一种极端的科学家思维呢？是否有悖了工程学的真谛？

[Perry]

看到楼主这么喜欢用真他妈就觉得楼主特 low

你说的不需要这种差别到底是啥意思，你的意思是 button 不能表形和表义？

[Vegetable]

太尬了，真的太尬了，有时间读一读 Antd 的文档，你也许能有新的理解。https://ant.design/docs/spec/values-cn

[kop1989]

@Perry #8 我揣测他的意思是：“这些组件库明明是给开发用的，为何却包装着一层设计的外壳，导致学习成本上升，程序工作量大，设计复杂。比如 button ，为何要分类成“主要”“次要”。都统一成样式的 backgroundcolor 、borderwidth 不好嘛？如果统一了，我更换 ui 库只要替换引用就好了，代码都不用改了。”

如果我理解错了欢迎楼主指正。

[TomatoYuyuko]

符合楼主期望的应该是 tailwind 这种 css 框架吧
可问题是,用户需要什么我们就给他们喜欢的套皮就完事了,这种套皮也越多越好,前端贴近 UIUX 也不是什么坏事啊,纯纯的往工程上贴,那前端开发交给后端岂不是更好.
用户只会看你的 button 长得多好看,交互起来多 nice,而不是你这个项目代码工程化多 nb.每年前端整那么一堆花里胡哨的"工程化"结果优化了不到半秒的加载速度附带一堆 bug 才是病态的吧

[zoharSoul]

是的,
你看客户端的控件就不讲究这个

[liubaicai]

有同感，各家都推出自己的组件库，其实都差不多

[rioshikelong121]

你通读下 Material Design 的文档就知道所谓的设计语言是怎么一回事了。Ant Design 只能说没有模仿完全。Material Design 是真的有自成体系、跨端的一套逻辑在里面的。

[br_wang]

如果仅仅是 css 框架，其实还是从开发实现角度来看待这个问题。

设计语言的关注的是系统或应用中视觉传达和用户认知的调和问题。

对于设计语言来说，视觉元素都是表义的，是能够通过组合和重复在用户头脑中建立统一认知的。

认知一旦建立，用户使用产品时的心智负担和学习成本就会大大降低。「绿色的通知就是代表操作成功，红色的说明报错失败了」——不用读具体的提示文案用户也能快速做出判断。

而任何对已建立认知的强行修改都会造成用户认知报错，产生负向情绪 。用户从不会认为是自己认知的问题，而是「这个产品 /功能太沙币了」。

看看 iOS 14 时间应用中 DatePicker 样式使用混乱造成的负向反馈（随便一搜的一条，https://www.reddit.com/r/iOSBeta/comments/he4xul/ios_14_changed_the_datetime_picker_in_the/，现在又回归统一了），

再看看 PS5 强行统一各区圈、叉按键功能在主机圈引发的嘲讽。

所以，当有几十个后台，大几百个页面需求要产出，而这些页面又是下游成百上千员工每天面对几个甚至十几个小时的工作环境时，统一的设计语言就太有必要了。

不光是用户侧的考量，开发、设计、需求三方能否在统一的视觉交互认知下，快速沟通、确认方案，进入实现阶段，对于能效高低至关重要。

「是不是好看」真的不是设计语言的核心，锦上添花还差不多。

[Jooooooooo]

这...

思考太狭窄了, 把眼光放开阔点.

而且你这考虑的问题根本不是"系统设计".

[Y29tL2gwd2Fy]

以程序员角度思考设计
真 隔行如隔山

[20015jjw]

本来以为是认真讨论的
进来一看这啥啊

[cenbiq]

我理解楼主所说的，他是想吐槽现在这些所谓“设计系统”是在 copy+换话术，但是设计系统现在不就是处于探索阶段吗，用各种思路、角度去探索也很正常

[2i2Re2PLMaDnghL]

为什么 info 、warning 和 error 是「表形」的？
「信息」、「警告」和「错误」都是什么「形」？