敏捷中 UI/UX 的未来

很多刚接触到敏捷的人往往搞不清楚 UI 和 UX 设计在敏捷团队里的位置。在此之前，很多团队都试图保持这些工作独立于团队之外，或者是在前一个 sprint 就完成。最近出现了很多关于欢迎 UI 和 UX 加入到敏捷团队以及精益 UX 的前沿讨论。

来自 CollabNet 的 Luke Walter 提出了对于提前一个 sprint 的讨论

我经常遇到经验丰富的 Scrum 实践者推荐 UI 在开发的前一个 sprint 完成，甚至在 sprint 之外的 backlog 梳理 /sprint 计划会时就产生。作为一个从 2004 年就开始使用 Scrum 的设计者，这持续地困惑着我。虽然这些人毫无疑问会认为，系统的体系结构（高层次软件设计）能够在接下来常规 sprint 的开发工作中通过增量和迭代的方式逐步完成，但他们在 UI 设计表达了相反的意见时却没有体会到其中的讽刺感。

对于 Luke 来说，设计只是另外一个被完成的部分：

设计 - 就像架构和测试 - 只是构建一个潜在可交付产品增量必须要做的简单工作。这项工作可以发生在其他任一个 sprint。

UI 设计 / 信息架构是或多或少相当于系统的软件架构：就比如说它只是一个灰色物质有关的处理器，而后者是与硅和铜有关的处理器。

他也提到了他的一个担心：用迭代的方案来设计会导致增加重做的工作：

正如程序员需要改变重做是浪费的观念，设计师也是一样。

The Ladders 网站的 Jeff Gothelf, 也不是 提前一个 sprint: 的支持者。

标记 “0 迭代” 暗示着我们会跟随“错开的 sprint 模式”，它推广自 Autodesk 的 Desiree Sy 和 Lynn Miller，但我们不，相反，我们选择作为整个 Scrum 团队解决问题，并使得产生构思，设计和开发的阶段尽可能同时开始。

Jeff ，是一个被称为 精益 UX 一个新的运动的支持者。

精益 UX，受到精益和敏捷的启发，使设计更贴近开发过程，使重点不再是交付物，而是实际的软件中的用户体验。

精益 UX 鼓励设计师尽早向你的团队展示你的工作，收集他们的建议并融入下一次迭代的设计。

通过尽早让你的队友更早洞悉设计的工作而不是在设计上离得更远，你能够做到以下几点：

1. 确保您与更广的团队和企业愿景达成共识 ;
2. 让开发者们对应用程序的方向先睹为快（加速开发并让挑战提前浮现出来）
3. 让你的思考更充实具体，因为向其他人用语言表达你的思想会促使你专注你在使用像素时没考虑到的方面。

远离冗长而详细的设计周期，采用非常短的、迭代的、低精度的周期；更早更频繁的接收来自实施团队所有成员的反馈；整个团队的协作是产品成功的关键。

他还解决了对于“群体设计”的恐惧：

实际上，设计者仍然通过收集所有的反馈来驱动设计，他评估对商业和用户最佳的工作，并反复迭代设计。

通过保持精益，经常收集团队的反馈会最小化走错路浪费的时间。仍然是设计师驱动设计，但通过每次迭代和审查，约束是可见的。从根本上来说，如果你花了三个月让一个设计非常完美，但是上线之后发现不满足用户的需求，那么你已经浪费了生命中的三个月，更别说你的团队了。

精益 UX 是一个进化，但不是革命。 随着实践的发展，UX 的设计师也需要提高并保持相关的了解。精益 UX 让设计师跳出交付业务回到体验设计上来。

Jared Spool, 在 精益 UX 有何不同提到：

我体会到有些东西是符合精益 UX 的。这产生于精益初创企业，也是一个我认为有可取之处的动作。

精益 UX 减少产出量并更多关注设计思维。尽管目前还没有新的技能加到我们的 UX 技能列表，存在一种精益 UX 特别的思维方法，不过如果人们不练习是看不到的。

经过多年的不确定性，看起来 UI/UX 正在成为一个完整敏捷团队的正式成员。

查看英文原文： The Future of UI/UX in Agile