设计体系的出现便是用来应对组织在敏捷、协作和债务处理等方面的需求

总的来说，设计体系的出现便是用来应对组织在敏捷、协作和债务处理等方面的需求。

——敏捷响应需求：在多设备、多平台的现在，组织不可能选择每隔几年再更新一个全新的数字产品，因为这意味着在交互上用户需要重新学习，在战略上这种方式的不确定性因素过大，如果失败就意味资源的大量浪费。

就特性而言，数字产品不同于实体产品，往往需要尽快上市，最小成本检验，尽快迭代，以获取更强的竞争力，而且以往写的代码也不会被磨损，需要定期进行维护；因此这些便对组织满足用户体验的速度做出了要求，因此更多的组织逐渐采用如等以敏捷（Agile）和精益（Lean）思维为基础的敏捷开发（Scrum）、设计冲刺（Design Sprint）等方法。

——复杂的协作鸿沟：对用户来说，只需要点击升级便可获得最新的体验，但这意味着这种体验的即时在线化将体验迭代的简单交给了用户，而复杂就留给了组织；UX设计师、前端工程师、产品经理、内容策略师们、可访问性专家等等组成的组织结构和工作流程都需要得到适应性的改变，才能提供快速迭代的流程去完成版本管理、设计管理、债务管理等工作？

Alex Schleifer（Airbnb设计副总监）也提到这样的情况：虽然工具的提升帮助编码的速率和设计的效率都在提升，但最终使设计生效的是多方面的协作的结果，然而原有方式越来越多暴露出在跨学科沟通上的问题，这些依然阻碍着产品创新以实现更佳用户体验的效率。

——债务大量累积： 这里的债务不是指经济上的债务，在设计上，由于设计人员的个体差别和缺乏系统性机制促进设计经验沟通，设计往往在长期的开发过程中提供了许多定制化的解决方案；在UI上可以体现为不同样式的按钮或颜色等、UX上可以体现为同一软件上的交互逻辑混乱等，这造成了设计债务（Design Dept）。

而技术债务（Technical Dept）亦是如此，为同一个问题，不同的工程师使用不同的代码或是令牌标记，加大了代码设计与维护、拓展的难度；同时，我认为其中还存在一个债务，我将其称之为产品债务（Product Dept），不同类别的产品经理等负责产品定义等职能的人员为同一产品或业务功能提供了不同，但效果相似的产品解决办法。

而且无论你是互联网公司，亦或是传统产品公司，越是庞大的体系，人员就越细分，在整体设计上的知识就越分裂，就越有可能出现同一问题多个定制化解决方案的情况，这会让出现在工程、产品、设计上的债务就越庞大。

这些设计、技术、产品债务让管理、维护都异常艰难；而且只要审视一下我们日常工作的周遭，就会发现债务其实无处不在；那些杂乱的视觉形象应用、那些不统一的工业产品材料与色彩、那些无准则的交互行为、那些不一致的反馈声音、同一数字产品不同的功能模块定义等等……

时至今日，设备和用户的多样性都在激增，以往的标准、工作流程和基础设施都难以支撑；我们用设计和开发应对的问题越来越多，变化也越来越多，但我们一直在定制化和通用化之间无序游离。

可以在一些软件中看到同样的一个功能按钮出现十几种形式，而它们要解决的问题却几乎一样；也可以看到那些拙劣的设计规范中，万物归为一种单调样式，降低了开发成本，却带来用户认知的困难。它们都难以维护，极大地阻碍了组织创造体验、达成商业可持续和创新的效率。

四、组织的应对？996还是一劳永逸？

面对着这些问题，公司只能存在几种选择（Suarez等人，inVison）：

• A-不改变速度雇佣更多的人（通过内部雇佣或业务外包）；
• B-提升员工设计与开发的速度（个人能力的极致压制，996、007）；
• C-改变工作的方式，创建通配式的解决方案，提高设计与代码复用率以提升效率（如模块化）。

大部分组织为了满足快速发展的需要，往往更多采用A和B的方式（例如各种各样的业务扩充，产生了大量对工程和设计人员的需求，如阿里、网易、字节、美团等）。