设计系统需要维护么?
当然。
在你费尽辛苦完成了设计系统的创建并推广给设计师,设计系统的实践旅途才刚刚开始。关于 Motiff 妙多对创建设计系统的思考,可以查阅 《AI 设计系统创建:一键开启 AI 时代新实践》。
本篇我将为你介绍 AI 时代下我们关于“设计系统维护”的思考。
业务日新月异,持续出现新的模式,所以设计系统不可能是一成不变的。在设计系统被创建之后,定期来维护使得这套系统能够保持更好的使用状态,是大部分实践设计系统团队必须要做的事情。
设计系统是一个活生生的、有资金支持的产品,具有路线图和待办事项,为生态系统服务。——内森·柯蒂斯
正如 Nathan Curtis 提到的,设计系统是一个活生生的产品,随着他所服务的“ecosystem”一起,不断进化。
这个进化包括:
这些工作在 Roadmap&Backlog(路线图和待办事项)的指引下周期性重复,这就是设计系统维护。
一旦设计系统没有得到及时的维护,设计系统逐渐变得年久失修,甚至废弃。
没有得到及时维护的设计系统由于缺少必要的组件或样式将使得用户被迫脱离设计系统工作;
设计系统利用率降低的同时也使得设计系统与设计需要的差距进一步加大,这将使得维护工作更加困难。
避免设计系统陷入恶性循环的方法不只一种。
Brad Frost 倡导的实践“Design system first(设计系统先行)”可以从根本上解决问题,即在进行设计时,先从设计系统入手,思考哪些已有的组件与模式可以满足需要,如果已有的设计系统不能很好的满足需要,那么需要先考虑是否需要改进设计系统,再将改进后的设计系统应用到设计需求中。
“设计系统先行”使得设计系统持续领先于设计需要,每一次设计需求本身就是对于设计系统的一次维护,从源头上防止设计系统与设计实践差距的产生。
但“设计系统先行”使得设计系统使用者(Design system users)和所有者(Design system maker)之间的协作变得复杂,设计系统使用者需要将需求反馈给设计系统所有者并等待设计系统更新,这导致设计需求的产出时间拉长且无法准确预估。而这,是许多团队无法接受的。
及时进行设计系统维护,也是一个不错的解决方案,虽然不能完美消除设计系统与设计需求间的差距,但通过高频次地维护,这种差距将被动态控制在较小的范围内。
但,及时地进行设计系统维护同样不容易。
进行设计系统维护首先依赖所有者与用户的良好沟通,当用户发现设计系统无法满足需求时,可以反馈给设计系统维护团队。后者需要评估反馈是否合理,并决定是否将其纳入到设计系统中,以便满足其他用户的需要。
但在与几乎每一位内测用户的沟通中,我们都发现,无论反馈渠道多么畅通、维护团队的响应多么及时,他们总会在一段时间后发现,设计文件中开始出现设计系统外的新组件与样式,而他们从未收到反馈。因为,总有一些用户选择“默默承受”,自己解决问题。
于是,被迫的,设计系统维护团队开始定期查阅最新的设计稿,发现并总结新出现的组件与样式,并将他们添加到设计系统内。这需要:
而这个过程需要耗费他们大量的时间,最终,设计系统维护从即时总结,变成了年末的重新盘点。
幸运的是,AI 可以把我们从枯燥乏味的工作中解放出来,这便是我们上线 AI 设计系统维护的初衷。
最后,Motiff AI 将选择权留给设计师,你可以根据团队的需要决定是否在设计系统内增删样式与组件,并最终完成一次设计系统维护。
AI 设计系统维护是一个庞大而复杂的工作,我们还在探索一些新的能力。
当前,分析已有设计系统的缺陷依赖对设计系统引用、分离等动作的统计并结合来自用户的反馈。但 AI 可以接受并处理更多更复杂的数据。
我们还在探索更多可能。