热门观点:大多数公司在他们实际上永远不会使用的设计系统上浪费了 6 位数的资金。
我们已经无数次地见证了这样的故事。领导层在看过 Shopify 的 Polaris 或 Atlassian 的文档后,对设计系统充满了憧憬。他们想象着自己拥有一个组织精美的组件库,拥有完美的间距标记和配色方案,其完美程度足以让瑞士设计师叹为观止。
六个月和 20 万美元之后,他们的开发人员仍在从头开始构建一切。
听起来很熟悉?
伟大的设计系统骗局
通常情况下,情况是这样的:一家公司决定需要一个设计系统。他们组建团队,投资工具,耗费数月时间,打造出你见过的最华丽的 Figma 库。领导层在全体会议上展示了这个系统。所有人都鼓掌。
然后……什么都没有了。
残酷的现实:
- 开发人员完全忽略了组件
- 新功能采用一次性样式构建
- 设计系统成为浪费潜力的美丽纪念碑
- 六个月后,“系统”看起来与实际产品完全不同
我们审计过一些公司的设计系统,这些公司花费了 15 万至 30 万美元构建复杂的组件库,但开发人员的采用率约为零。
为什么花哨的组件不等于系统
问题不在于组件的质量,而在于大多数公司构建的是库,而不是系统。
组件库是:
- 精美的 UI 元素集合
- 孤立存在的文档
- 设计师喜欢并且开发人员容忍的东西
- 压力之下被抛弃的可有可无
设计系统是:
- 一套解决实际开发问题的工具
- 保持一致且不令人烦恼的治理
- 开发人员真正想要使用的文档
- 开发工作流程的重要组成部分
区别是什么?一个存在于 Figma 演示文稿中。另一个存在于你的代码库中。
真正有效的系统的四大支柱
在见证了无数设计系统的成功和失败之后,我们发现了成功设计系统与价值 20 万美元的镇纸产品之间的区别:
1. 清晰的治理(有人真正拥有这个东西)
大多数设计系统失败是因为没有人真正负责。它们被当作一个附带项目,每个人都参与贡献,但却无人维护。
实际有效的方法:
- 一个人(或小团队)负责整个系统
- 添加/更改组件的清晰流程
- 定期审查以保持最新状态
- 必要时有权说“不”
危险信号:您的设计系统会议有 12 个人,但没有人可以做出决定。
2. 不会让人想死的记录
我们见过一些设计系统文档,读起来就像机器人写的技术手册。“主按钮组件利用语义颜色标记来确保所有断点都符合可访问性……”
停!停!
好的文档可以回答:
- 我如何使用这个东西?
- 我什么时候应该使用它(什么时候不应该使用它)?
- 如果我需要不同的东西怎么办?
- 如果这个坏了,我该去哪里?
出色的文档显示:
3. 与实际开发工作流程集成
大多数系统都死在这里。它们的构建方式与开发人员的实际工作方式相悖。组件在 Storybook 中看起来很棒,但要将它们集成到实际产品中,需要三次 Slack 对话,并且需要向 CSS 之神献祭。
有效的系统:
- 组件作为实际包发布
- 它们与您现有的技术堆栈集成
- 更新不会破坏一切
- 使用起来比从头开始构建更快
不具备以下条件的系统:
- 需要从文档复制并粘贴代码
- 需要不断定制才能工作
- 每次框架更新都会中断
- 实施时间比定制解决方案更长
4. 实际维护所需的资源
很少有人谈论这一点:设计系统是活的。它们需要滋养、呵护,偶尔也会进行修剪。太多公司建立了一个系统,宣称取得了成功,然后却发现它一年后就变得无关紧要了。
维护包括:
- 当设计模式演变时更新组件
- 在团队需要时添加新组件
- 修复错误(是的,设计系统有错误)
- 保持文档最新
- 在团队中推广采用
虚假系统的真正代价
当设计系统失败时,代价不仅仅是构建它们所花费的金钱,还包括随之而来的一切:
技术债务不断增加:每个开发人员都构建自己的解决方案,从而造成无法维护的不一致的混乱局面。
设计分歧:如果没有共享组件,您的产品看起来就像是由委员会设计的(因为它确实是)。
开发速度变慢:团队花时间重新创建相同的组件而不是构建功能。
用户体验受损:不一致的交互会让用户感到困惑并影响转化率。
我们看到一些公司花费 30 万美元来设计一个失败的系统,然后在两年内又花费 50 万美元来处理随之而来的不一致问题。
成功究竟是什么样的
我们遇到的最成功的设计系统不一定是最漂亮的。它们是开发人员首先想到的,因为它们解决了实际问题并节省了时间。
成功的系统特点:
- 六个月内 80% 以上的开发人员采用
- 由于基本组件已处理,因此新功能发布速度更快
- 所有产品均具有一致的用户体验
- 设计更新通过系统自动传播
- 团队争相贡献组件,而不是避免使用它们
案例研究片段:一位客户在实施了合适的设计系统后,功能开发时间缩短了 40%。这并不是因为组件本身有多棒,而是因为开发人员不再需要从头开始构建基本的 UI 元素。
关于建筑系统的残酷真相
大多数公司还没有准备好采用设计系统。他们自以为已经准备好了,但实际上并非如此。
当满足以下条件时,您就准备好了:
- 您有多个具有共享模式的产品/功能
- 您拥有专门的维护资源
- 领导层确实了解他们购买的是什么
- 您愿意执行标准(即使不方便)
当出现以下情况时,您还没有准备好:
- 你认为设计系统会神奇地解决你所有的设计问题
- 你期望它在初始构建后就“完成”
- 你不愿意改变团队的工作方式
- 你之所以要建它,是因为竞争对手已经有了
更好的方法
不要从第一天开始构建一个庞大的系统,而是从你实际遇到的问题开始:
从小处着手:构建团队经常使用的 3-5 个组件
证明价值:表明使用系统比不使用系统更快
根据使用情况进行迭代:在团队需要时添加组件,而不是在它们看起来很酷时才
添加投资于采用:在宣传上花费的时间与在构建上花费的时间一样多
底线
设计系统并非在于拥有漂亮的组件,而在于拥有一种可扩展的方式,能够更快地构建一致的产品。
如果你的开发人员没有使用你的设计系统,那么你面临的不是系统问题,而是策略问题。
能够做到这一点的公司不仅可以节省成本,还可以更快地推出更好的产品,并打造用户真正喜爱的体验。
兰亭妙微(蓝蓝设计)www.lanlanwork.com 是一家专注而深入的界面设计公司,为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计,以及相关的软件开发服务,咨询电话:01063334945。
