有言道“一图胜千言”，可敏捷的世界里却没有铭记这句话。至少，很多敏捷团队中的设计人员这么想。在某些团队中，设计人员必须创建小的设计增量，而这个过程不一定能产生最好的结果。对于其他团队来说，“线框”是官僚体系的产物，阻碍了开发工作的高效推进。

Booshtukka提到，在当前的情境下，很难怪罪设计人员对于敏捷的不忿。敏捷流程希望让设计人员以小步增量的方式交付设计。创意因此面临困境。

这根本没有意义：创意本身是一个整体。假如有人要你画一栋房子，但是要一点一点地画。首先，画出烟囱；然后是窗户；然后画做为背景的山；然后是正门。你非给逼疯了不可，而且，你在画下一笔的时候，必须要改变之前的部分，以保证整个作品符合常理。

Sam在敏捷可用性论坛上发起一个类似的讨论，以理解“线框”的相关性和重要性。William Pietri回应了Sam，提到这在很大程度上应该由团队和个人来决定，决定他们是否需要线框，以及细节所应达到的程度。他认为：

对于这些问题，我觉得没有统一的答案。我们在寻找的，是个人差异、团队差异和最小浪费之间的交集。对我来说，达到目的的唯一方式是不断微调具体流程，看看如何尽量减少不良影响，同时仍能产出出色的工作成果。

Gene Arch和Paul Spencer提到：根据他们的经验，线框有其固有的价值，在很多时候，它可以帮助他们预见困难情形。对于他们来说，他们的设计人员与产品负责人一起工作，为下个sprint设计优先级最高的内容。

Pat Cheugn引用了文章“HTML线框和原型：都是收益，没有痛苦”，他认为：对于设计人员来说，就应该使用线框。在他看来，线框的好处在敏捷世界中更为彰显。

产生HTML线框和原型的确能让开发团队尽可能接近最终产品。它有助于过滤坏主意，并让好想法涌现出来……特别是在线框能够展示出用户流程和页面流程的情况下……

最大的收益来自于：线框能够开绿灯，告诉大家一切都已准备齐备，可以开始实现后端编码。从纸上到电脑不需切换，也不用从PSD文件切换到HTML，很多CSS风格都已经定义完成，而且实现也很快，因为HTML线框总是以范围的方式定义的。

Sascha Brossmann回应了类似的讨论，并认为：在敏捷环境中进行用户体验设计活动，最重要的原因，是要在开始开发之前把握更清晰的全局，并不断更新。他补充道：如果线框能够先于开发一个迭代创建出来，这也会很有帮助。Yoni补充说到：

我发现：（保真程度不同的）互动原型是敏捷环境（也包括其他环境）中最有效的交付物。提供这样一个人工产出，对于开发人员来说更为熟悉，而且在交付之后也不需要更多解释和手把手的指导，沟通的沟壑也在不意间降低了。

William提出一种有趣的方法，用来验证线框对于团队的需求和意义。他认为：开发人员和设计人员对于线框的认识总是存在差异。如果设计人员能够展示出线框的意义，这将会很有帮助。

要想说服开发人员你的方法的价值所在，你要试着在某些用户故事中尝试各种方法，并在回顾会议中谈论发生的事情。如果你能发现他们没有看到的东西，想办法展示给他们看。

Jérôme Gravel-Niquet补充了他们团队认为有效的方法。他认为：

• 从用户故事的基本描述中，我们迅速创建出了线框。
• 线框完成后，我们在访谈中展示给最终用户并收集反馈，并会根据反馈调整线框。
• 当我们有了坚实后盾（用户和委员会审核通过）并充满自信之后，我们马上就会设计界面。
• 有了这些东西，我们会创建文档，解释不同的交互和功能（用wiki的方式）。
• 作为擅长整合的用户体验设计人员，在开发人员着手用户故事之前，我也会尽量整合界面和其相关的互动。

因此，大家一致同意线框的意义。它能帮助团队内部、以及与利益相关者之间取得更好的效果。关键在于做刚刚够好的工作，并保证流程轻量级。保证线框的高质量也很重要，因为在Alex Jones看来，概略的线框相当于用户体验的comic sans字体。

查看英文原文： Wireframes or No Wireframes

来源：http://www.infoq.com/cn/news/2010/06/agile-wireframes