阿戈达设计系统本文改编自我今年早些时候在“设计系统大会”上的演讲（观看视频：https://www.youtube.com/watch?v=fpSa8zG1X0o）。我非常高兴收到了大家的积极反馈，并且看到许多团队已经根据我们的方式制定了自己的流程，我深受鼓舞。希望通过这篇文章分享这些内容，我希望能够帮助他们在不断发展中的设计系统中引入结构和清晰度。无论是错过了演讲的人还是更喜欢阅读的人，我希望这篇文章能帮到您。希望您喜欢这篇文章！
Agoda的设计系统始于2018年的一个小型项目，并由开发人员主导，现已发展成一个近20人的跨职能团队。
当我于2022年加入领导系统设计团队时，一个关键的挑战是帮助管理层理解设计体系的价值。随着阿果达设计体系（ADS）的发展和越来越多团队的采用，新的挑战也随之而来，尤其是在应对日益增长的需求方面。
我们已经支持超过60个产品团队，并且有1,600多名设计师和工程师，每周在4个平台上推出超过100个A/B测试项目。随着我们面向消费者的团队中ADS的月活跃使用率接近100%，一个新的挑战出现了：如何处理所有的工作！
找出根本原因随着工作量的增加，我们发现需要更好的方法来优先处理请求。不同团队的需求冲突让我们难以解释为什么一个请求比另一个更重要。
当我们的人数接近20人时，内部协调变得非常困难，导致优先级混乱和一些请求被忽视，这让我们团队和相关人士都感到沮丧。
我们经常遇到的一个挑战是管理快速移动且注重速度的团队的时间预期，这些团队依赖我们。正如乔希·克劳克在他的文章中提到，在其文章《通过构建更慢的设计系统来更快地交付》Ship Faster by Building Design Systems Slower中，他说：“当设计系统团队无法满足产品团队对新功能、组件或模式的快速需求时，团队会感觉自己成了瓶颈。”
我们也经历了这一点，部分是因为许多团队没有意识到我们处理了多少请求，导致了不一致的期望。此外，这缺乏透明度侵蚀了信任，因为团队难以追踪进度和理解决策过程。
为了解决这些问题，我们开发了新的流程和步骤，实施了一个优先级框架，并改善了沟通渠道。下面，我将为大家介绍这些解决方法，并提供一些资源，帮助您的团队。
我们新流程的简介
这是我们ADS中的新请求流程的样子。它从一个请求开始，任何人在Agoda都可以提交这个请求。
然后我们的团队将审核、优先级排序并整理和优化该请求。整理和优化完成后，它可以由我们团队或其他需要此变更的团队接手——相当直接明了。
让我们更深入地看看旅程的每个部分，了解更多。
我们是怎样处理新请求的
我们设立了一个专门用于请求的Jira看板，简化了我们处理新请求的方式。看板根据状态组织所有请求，并按优先级从高到低排列请求。
你可以很容易地看到请求类型和总数，还可以通过状态或平台来筛选，以获得更详细的信息。
我们团队能处理几种不同的请求。
- 功能需求 — 如新组件或现有组件、实用工具或模式的新功能。
- 视觉资产 — 图标、插图、国家旗帜、标志等等。
- 设计令牌 — 新的设计令牌或现有令牌的更新。
- 工具 — 对我们提供的文档平台、Figma 插件及相关技术工具的改进。
任何人都可以提交一个新的请求，我们根据请求类型定制了字段，以便收集重要信息，比如问题描述和建议的解决办法。我们还提供了Figma 模板，这些模板包含设计规格、用例等重要信息，以帮助我们更好地理解请求。
虽然这个过程可能看起来很复杂，但它有助于确保我们完全理解请求者的需求，并且请求确实是必须的。我们还提供了多种途径来收集反馈、分享想法和报告错误——例如，每个组件的 Slack 通道，这些通道是讨论和灵感交流的绝佳场所。
如何安排请求优先级接下来，我将解释我们如何确保无偏见性的透明优先级设定，重点关注业务方面的需要，使句子更自然流畅。
我们根据四个关键标准给请求打分。
- 产品类别
2. 可重用
3、其他解决方法
4. 付出
每个标准都在“高”到“不予解决”之间进行评分，总分决定了最终的优先顺序。我们故意对这些标准给予不同的重要性——例如，可重用性（15分）比低努力（10分）的权重更高，这一点因为其对长期的影响更大。
我们选择根据自己的特定需求定制框架——尽管它与更成熟的框架如RICE评分方法有很多相似之处。Stuarth Smith在他的文章《我们激发设计系统治理的三种方式》中推荐了这种方法，我建议大家阅读这篇文章。
为了说明这个过程是怎样工作的，让我们来看一个例子——一个团队请求对我们的现有日期选择器组件进行一些改进，希望能够选择很久以前或很久以后的年份，而不是只限于当前的年份。
首先，我们评估产品。这个请求是否满足了来自业务关键项目、产品或团队的需求？
假设今年的请求是为一个重要的即将发布的产品或服务而提出的——在这种情况下，它会得到最高分。
2 — 可重复使用性接下来，我们看看这个解决方案是否能在多个平台、功能或团队之间重复使用。
为了公平地评估所有请求，我们不得不明确地定义“可再利用性”对我们来说意味着什么：
- 平台和漏斗：年份选择器在酒店、航班和活动等所有平台上都适用。它也可以用于生日或护照过期日期等，因此其可重用性很高。
- 对最终用户的影响：许多用户可以从中受益，但这不是所有使用场景的解决方案。因此，我们对最终用户的影响评估为中等，因为大多数用户可能会受益，但并非所有用户。
- 对我们支持的团队的影响：我们从组织中的几个支持产品团队中记录了一些使用案例，这也是中等。
- 变更频率：由于其复杂性，预计未来会有许多调整和变更请求，这可能会使该功能的维护成本很高。由于我们通常希望避免这种情况，因此我们将该功能的评分定为低。
总的来说，可重用性大约在中等水平：
第三点，我们已经有能解决问题的办法了吗？
以年份选择器为例，一个简单的下拉菜单或输入框在某些情况下适用。但在其他情况下则保持年份选择在日期选择器内是必要的，因此我们将其评为中等。
4 — 易实施性需要做多少工作？我们优先处理那些容易搞定的问题，因为小的修复也能快速解决团队的障碍。我们更喜欢解决十个较小的障碍，而不是死磕一个大问题。
日期选择器很复杂，不同实现之间有不同的用户体验需求，因此改动此功能需要大量工作。因此，这个功能的得分不高。
最终成绩总分是30分，满分是50分，这个请求的优先级是中等。
这意味着我们可能不会马上处理它，请求方可能需要自己出力做出改变。
值班小组这就是我们如何对请求进行评分的方式，但究竟是谁在做这一切呢？鉴于我们需要提供相当多的支持，我们借鉴了DevOps的做法，实施了一个轮班待命小组，包括一名设计师、一名工程师、一名产品经理和我们的QA。
小队的一个任务是查看新的申请。如果申请需要更多细节或不符合系统要求，我们会把请求退回去，让他们有机会在下周改进后再重新提交。
我们在内部的知识中心详细记录了我们的框架和流程，所有团队都可以在这里学习和提供反馈。
虽然对一些人来说，它可能显得过于复杂或过度设计，但它为决策制定提供了一个坚实的基础，并与利益相关者沟通优先级。当然，它也可以根据您团队的具体情况进行调整。
3 — 处理请求
一旦请求被优先级排序，下一步就是梳理。每两周，我们会召开会议来梳理这些请求，为不同平台的设计和实现创建任务工单。这些工单会分别存储在各个Scrum团队的独立看板上，并链接回原始请求，这样就可以轻松追踪依赖关系，并了解其他团队的贡献情况。
从这里起，团队可以继续按照现有的流程来完成任务。一旦有团队开始处理该请求，我们会将其标记为“进行中”。
利益相关者可以通过查看所有关联票据的状态轻松跟踪进度。他们还可以添加自己为关注者，以接收与请求相关的任何变更或评论的自动通知。
我们很快发现仅仅依赖 Jira 通知效果不佳，因为许多相关人员没有收到更新。于是我们增加了 Slack 通知以确保所有人都能看到。
例如，我们的设计师 Parn 最近分享了关于我们底部弹出层组件的改进，并附上了一个快速的 Figma 视频教程，展示如何使用。这种主动的沟通方式非常受团队们的欢迎！
我们的一些流程和公司传统这是我们请求流程的简单介绍：
• 提交请求的方法：任何人都可以通过Jira工具和Figma模板提交请求。
• 审查流程：在每周的例会上，审查新的请求。
• 整理：我们团队整理请求并创建ticket，然后由Scrum团队来跟进。
• 正在处理中：请求通过Jira和Slack跟踪，利益相关者会通过电子邮件和Slack收到更新。
• 完成：工作完成后，会宣布任何变更，并在整个过程中都会通知委托人。
具有清晰的从头到尾的工作流程，周全的优先级设定以及固定的仪式，我们能够让相关方随时了解情况，管理各方的期望，并更高效地处理工作。
关键要点在结束之前，我想分享几件我们学到的事情以及一些小贴士，帮助你开始自己的旅程。
一个既包容又清晰的过程，才是真正的好过程。有了明确的流程，整个团队可以共同承担引领我们的仪式过程的责任，这让我可以专注于战略工作，同时为团队成员提供成长的机会和空间。
少一些细节讨论该流程已将讨论从讨论个别请求转向完善整个框架，从而提高决策质量，并促进持续提升。
加强与相关方的沟通并加深理解自从引入了这一流程以来，我们设计系统的需求得到了清晰地定义，并且改善了与领导层和其他团队之间的沟通。每季度的调查显示，沟通和透明度有了显著的改善。
取舍和优先考虑的事我们在与领导层的讨论中，一直在权衡更好的设计与更快交付之间的平衡。我们的请求看板展示了系统中存在的差距，表明设计系统一直在不断改进。
带宽与我们的参与我们目前收到的请求是我们能够处理的五倍，扩展贡献能力仍然是一个挑战。虽然我们的优先处理框架确保我们优先处理最重要的任务，但问题是，剩下的这些怎么办？
我们正在积极寻找以规模化的方式引入贡献，同时保持系统完整性的方法，但还没有完全达到目标。
时间线有冲突作为平台团队，我们常常面临将我们的交付与快速迭代的产品团队的时间线对齐的挑战。我们不希望成为阻碍创新速度的瓶颈，但找到正确的平衡仍然是我们仍在努力解决的持续面临的挑战。
新手提示如果你的团队正面临类似的挑战，这里有一些小建议可以帮助你开始一个类似的流程。
1. 设定你的优先级准则尽早让各方利益相关者参与讨论，以建立各方对权衡和公司整体优先事项的共同理解，而不仅仅是您团队的优先事项，而是整个公司的优先事项。这将让您的后续工作更加顺利。您可以参照我们提供的模板作为起点，之后再根据实际情况进行调整。
2. 集中处理请求将所有请求集中在一个地方，以便全面了解系统的整体需求。这也有助于向你的团队说明更多投资的必要性。
我们已经了解到，bug和其他“常规任务”占据了我们大量的工作时间——有时甚至达到50%。但是我们没有将这些任务包含在我们的任务板中，因此其他团队并不清楚我们在忙这些任务。建议将这些任务也加入其中，以确保透明度。
3. 建立日常习惯创建常规，并将工作流程标准化，以高效推进事物。找出需要反馈回路的地方，并将这些反馈回路嵌入到流程中。
4. 与相关方沟通:定期沟通，管理预期，建立信任，让利益相关者了解情况。
5. 不断学习和迭代改进跟踪关键数据点并利用这些数据为你的团队争取需求。不断改进你的流程，根据你的团队的具体挑战和需求来调整。
更多阅读和参考资料- 查看我在此文章相关社区资源的Notion页面——包括请求框架、Figma请求模板和有启发性的文章。
- 我在Into Design Systems Conference上的演讲是此文章的基础，该演讲可以在YouTube上免费观看。
- 我的另一场演讲“我们如何迁移到Figma及其经验教训”也可以在YouTube上观看。
- 通过构建更慢的设计系统更快地交付 作者：Josh Clark，Big Medium
- 让设计系统的治理变得轻松而不是瓶颈，以及后续文章我们如何使设计系统治理充满活力 作者：Stuart Smith
- 全面指南：打造高效且愉快的值班团队 作者：Atlassian
- RICE：产品管理中的简单优先级制定 作者：Intercom
如果你看到这里——非常感谢你的阅读支持，希望对你有帮助 🌟 你可以在Linkedin上找到我，或者关注我的Medium主页获取更多设计系统的内容！
共同学习，写下你的评论
评论加载中...
作者其他优质文章
