前言
界面设计是软件设计抉择的一部分而不是规格，并且它远远不止于一张图片，如果把设计稿视作规格往往不足以反映真实需求
Continuous Delivery 在 The Biggest Problem With UI 影片中指出了我多年对产品 UI 开发流程的最大疑惑：为什么 UI 设计与开发的流程总是如此不顺畅不协调？
UI 作为产品规格的一部分总是由设计团队精心设计后交付给开发团队实现，但过程中有太多不协调因素，举我自己亲身经历：
- 不理解 UI 的人很容易将界面设计视为一张张静态图片而不是动态的体验，并且再怎么高还原度的设计稿也无法完全反映真实的使用者体验（还很耗时间制作）。
- 如果开发端对于设计抉择有异议，来回沟通意味着彼此的进度相互阻挡，除了效率低下之外也伤及工作体验。
- 让任一职位独揽所有界面设计决策是不可能且危险的事，满足使用者需求背后需要更多领域的协作，如产品团队、开发团队、用户研究……等，要如何协调不同领域又保持效率？
「有没有办法让团队稳定高效地产出真实满足用户需求的产品？」是本篇文章探讨的核心问题。
开发者眼中的 UI 问题
我是一名前端工程师，工作中会将工作职责分得非常清楚，产品根据需求撰写规格书，UI 再根据规格书设计，开发再根据设计稿实现，看似明确清晰的分工，但却没有想像中协调。
这样的流程让我不被鼓励也不被允许在规格上提出任何意见，当我对于设计抉择有歧异时只能选择默默接受（甚至不知道为什么采取这项决定），或是找时间一层一层向上沟通，但这样的沟通往往会耗费大量时间，只为回过头修改已经被订下的设计抉择，如果每当任何一个疑惑冒出还要开一个请求给 UI 团队或是启动会议……大多数人都会放弃！
当被迫把实践问题的方法局限在上级提供的设计抉择时，总是会忽略掉用户真正的需求与开发上的困难，就像是我很难在短时间内传达我的考量给设计师，并且大多数时候上层也不会有足够的时间去了解这些技术细节。
在职责清晰的工作模式当中，每个人只会关心自己职责内的事情，并没有什么真正的协作发生。
所以 UI 该怎么做？
在 The Biggest Problem With UI 影片的观点中提到，工程师虽然强项不在于 UI，但或多或少都是某种程度的深度使用者，对于 UI 都相较于他人有某种程度的认知。
根据 Team Topologies 观念，UI 团队可以作为 Enabling Team 来弥补 Stream-aligned team 的不足，这使得开发团队有时间获取和发展能力，而不会占用他们的主要目标的时间。
Enabling Team 主要致力于通过专注于问题而不是解决方案来增强团队的能力，从而提高 Stream-aligned team 的自主权。Stream-aligned team 应该可以自行解决 80% 常见问题，可以通过努力来降低跨团队的需求，藉由：
- 经验分享与训练
- 定义良好的 UI 文件与惯例
- 定义可重复使用的素材与组件
总结
我们会认为工程端将每个需求与外观一比一地实现出来就是优秀的，但这只是基础，真正的优秀是能够洞察真实需求并提高整个团队的运作效率，站在大局思考促进团队的成功我认为才算是真正解决问题。