迭代的设计 - UCD大社区

XHTML原型开发－用代码说话

Douis — 2008-11-15 19:05:35

作者：Anders Ramsay and Leah Buley
译者：UCD翻译小组，Li Douis
原文地址： http://www.boxesandarrows.com/view/prototyping-with

如果你正在给标准的网页和应用程序（比如用XHTML/CSS/JS开发的）设计用户体验，那就有充足的理由把XHTML原型（prototype）开发加入你的UX工具集。也许你已经发现传统的线框（wireframes）图功能有限，也许你正在寻找更强大的方法去制作并说明你的设计方案；也许你现在的工作是基于传统的瀑布模型（waterfall model）的（比如，首先创建线框图，然后交给设计，然后交给开发，等等），但你需要更加同步的方法，比如敏捷迭代开发（agile and iterative development）。不管用什么方法，通过XHTML开始你的原型设计将帮你更好的踏上这一旅程。

那么，用XHTML进行原型设计开发到底是什么意思？实际上，它就是使用XHTML及其相关技术去生成并确定你的设计方案的过程。那么一个XHTML的原型看上去什么样呢？这个问题，就像我们后面会看到的，其实取决于原型开发所在的步骤，一个XHTML原型通常看上去跟其他使用XHTML制作的网页是一样的，带有一些演示性的链接和特性。换句话说，也就是你用XHTML开发的东西，不管是客户网站还是企业应用，都可以用XHTML来制作原型。后面我们还会看到，这种方法相对于线框图或其他原型工具来说，都有着很多的优势。

一个迭代的过程

由于XHTML原型开发不是绑定到某个具体设计环节的，使得迭代开发大大增强了它的效果。原因有很多，但也许最显著的原因是原型及后来的程序这两者共同构成了设计说明。我们还会对这一点稍加解释（见“XHTML如何兼作设计说明”），但首先让我们看看XHTML原型开发的全过程。让我们从一个更宏观的设计进程的角度开始。

在这种（迭代）方法中，不会在开发之前对整个应用程序进行设计，而是先设计程序的一个节点（unit），然后使用这个节点充当其他程序节点的起始点。与其他的设计方法一样，整个设计过程始于草图（sketching），草图对原型的开发起到了重要作用。

草图法：一件形式自由的事情

“草图”这个词在这里指代那些不受特定技术限制的、自由的开发形式。包括制作线框图（通常要多次重绘），以及使用特定的工具来修改草图。当使用草图法来帮助思考、或演示给领导看的时候，一旦你的设计思路有了新的改进，你自然会放弃那些已经过失的线框图。但这时候往往已经开发出来一个原型产品了。在我所在的设计团队里，我们发现当使用XHTML开发原型时，线框会显得多余，而且，把草图直接变成原型会省事得多。

原型法：一个明确的回答

原型与草图有着对应关系。借用比尔巴克斯顿的话说，草图会带来一个问题：“这是一个好的创意吗？”－原型会告诉你答案。藉由对创意的具体表现，原型法综合了现有产品开发技术的实际情况和所能达到的用户体验水平，并且提供了一个方法，对你的设想进行明确而清晰的质量评价。

原型开发/打造关联

使用XHTML进行开发的时候，特别是在一个迭代模型中，开发和原型制作往往会纠缠在一起。如果你正在制作一个新应用或新产品的原型，XHTML原型实际上只是未来实际产品的一个草案。但是，当对现有程序进行升级设计的时候，现有产品的版本就能作为新的升级方案的一个起始点。

三个综合层次：结构(Structure)，行为(Behavior)，基础(Foundation)

XHTML原型开发的模型基于实际网站产品的最佳实践模型：首先用XHTML进行基础开发，然后用CSS添加表现层，接下来用JavaScript加入行为层，然后迭代。

我们从结构层开始讨论。

结构层：建立页面的基本结构

XHTML原型开发的第一步是建立一个基本结构。与线框图的制作类似，我们首先要表现出页面上的主内容区，不同的是我们用基于文本的XHTML语言来进行标记。

如果我们的草图或线框貌似这样…

我们的XHTML可能貌似这样：

…
XYZ Application

My Account


Account options


Account details


Account Help


[footer]

… 
(We're only displaying the relevant snippet of the XHTML here.)

接下来，我们添加预先定义好的详细内容元素，为相应的内容使用恰当的XHTML结构。

比如，如果我们的详细草图貌似这样…

我们会把AccountHelp主题列表显示成一个无序列表（比如使用ul标记）：


…

Account Help


     How do I lorem ipsum?
     
 How do I dolet amet?
     
 How do I lorem ipsum?
     
More help…


…

通过继续给页面添加详细的内容，我们实际上制作出了一个该页面的结构化的内容目录。它可以作为其他原型产品的一个基础。线框主要是在一个特定的布局形式之中体现页面的信息架构，但我们的方法则是纯粹的结构和层次，依我看来，能更好的表现一个网页上的真正的信息架构。

通过使用XHTML来直接定义信息的架构，我们还可以轻松的定义出与可达性（accessibility）相关的属性。比如发现那些使用屏幕阅读器来遍历网页的用户是怎样体验网页以及相应的内容区块的。另外，我们也更容易定义那些在线框图中容易忽视掉的元素，比如表单中的标签（Label）标记。

如果想要在浏览器中查看这个结构层，那基本上会看到一个非风格化的网页，而且会看上去比较无趣。虽然基础层并不以支持表现层见长，但基础层的质量会影响它所支持的表现层，所以结构层的质量也会严重影响网站的整体质量。但事实上，对样式的忽略却恰恰是使用XHTML的重要优势所在。

改进表现层

有了一个恰当的结构，我们就可以开始侧重于如何展示内容了。再看看以前的那些草图，我们已经具备了一定的布局概念，那么就可以开始往结构里面添加内容了。在不同的团队里，开发和制作外观（look and feel）的方法有很大不同。当你使用设计样稿（design comps）开始尝试外观设计时，特别是当你也同时负责整体的品牌设计时，重新设计样稿是比较划算的，就好像重绘线框图一样。正如草图有利于线框图，设计样稿也利于最初的外观设计。但现实工作中那些制作完整的表现层往往脱离了技术实际，最后不得不进行剪裁并批量的应用到网页上，就像给建筑物的外墙刷漆。而且这种静态的绘制软件外观的方法难以兼顾到网页上所有的动态元素。但是，如果使用XHTML来开发原型，则可大大提升外观实现的水平。用户可以参加到设计中来，用户提供的快速而丰富的反馈意见，可以帮助我们逐步改进页面的表现层。

以前在绘制（illustration）软件的时候，有些问题是难以显露的，但现在则会变得很明显。包括那些设计方案与浏览器之间的问题。比如设计是否应当居中这类基本问题，以及那些更复杂的问题，比如如何设计以适应不同窗口尺寸和浏览分辨率的问题。举例来说，对于较小的窗口尺寸，是否允许部分内容跑到视图外面？或者让内容自动适应窗口的尺寸？当使用绘制法来处理外观问题时，这类问题常常无法发觉，从而损害到用户体验。

添加行为层：少作无用功

用XHTML开发原型时，你是在整个网站的大环境下进行设计。这些设计会不断的加入你的实时更新的UI库。你不再是面向一个具体的功能点进行设计，而是由Google来通知你哪些人已经设计开发了类似的东西，并使用这些已有的东西作为你的解决方案的出发点。这些东西可以无所不包，从日期选取器到WEB控件，再到那些刚刚诞生的顶尖级UI创意。此外，XHTML原型开发可以很轻松的集成或模拟WEB2.0功能，比如内置控件和内容聚合（syndication）。如果你不懂JavaScript或其他相关技术，你可以跟开发人员合作来集成你的方案。当然，有时从网上找不到符合你的设计需求的解决方案，这种情况下，还是回过头来画草图，并且跟你的团队好好合作吧。

迭代：发现，改进

原型法的真正强大之处是在迭代过程中发挥出来的，也就是用户与你的原型产生交互的时候。在最近的一个项目中，我们设计了一个草图方案，用户可以从一个库中拖拽视频文件放入播放列表。看着那份静态的草图，貌似简单又简练。但是当用户真正开始使用的时候，拖放视频的缩略图时，他们却发现这种动作极为不爽，尤其是拖放大量视频时。换句话说，原型让我们得以发现那些隐藏在线框图后面的设计问题。

随之而来的核心问题，就是使用静态图形来讨论交互方案。静态图形等于是强迫用户用自己去想象，在想象中一切功能都极为完美。但是用XHTML，我们则把这种对用户认知能力的挑战降到最低，让他们去实际体验和感受一个几乎就是真实产品的东西。

只要用户作出了反馈，那么团队就开始进行下一次迭代。另一个在原型法中用于评估质量的角色加入进来：迭代的速度有多快？迭代耗费的时间越长，原型的价值就越低。用XHTML做原型开发时，迭代可以近乎神速，这首先是由于原型易于呈现给用户，因为它仅仅是一个发布文件然后发送URL的问题。其次，XHTML是基于文本的，它的迭代（比如修改文本或更新基本功能）仅仅需要几分钟。就算高级的设计修改，通常也不会超过几个小时。

XHTML如何兼作设计说明

XHTML的一项最牛的本领，就是自描述性（self-describing）。XHTML标记在告知浏览器如何显示数据的同时，还可以变成程序员的设计说明。举例如下：

这个标记

会被读作

用时髦的话来讲，我们写的是“语义有意”标记（semantically meaningful markup）。也就是说我们选用的标记、命名的ID和Class是可以传达其实际意义和功能的。

注释仅对个别人可见

XHTML作为设计说明的另一个好处在于，ID和Class名可以兼作注释参考。换句话说，在你的说明中，ID为“账户选项” 的内容区的注释将会显示在标题“账户选项”下面。

使用线框图时，常见的做法是在页面的顶部按编号列出模糊、杂乱的注释。这种注释会给非技术性读者造成困扰和负担。但XHTML的注释则只放在标记中，只有感兴趣的程序员才会看到。而且由于XHTML文件自身的信息很丰富，实际上注释只需写成简短的要点即可。

更标准，无干扰

线框图的最大缺点之一是缺乏标准的标记。也就是说你和我彼此看不懂对方的图。这就迫使视觉设计师和程序员们不得不去翻译我们的大作，其结果就是作者与读者间产生了误解。为了弥补这个问题，我们需要制作极为详细的线框图，还得添加长长的注释去解释图的含义，说明图的元素如何工作。这样，慢慢地就会累积起大堆的说明文档，而且变成无法维护的极端“劳动密集型”工作。一旦无法及时更新，整个团队就会放弃这种设计说明，接下来就会发生各种糟糕的事情。与线框图相比，XHTML提供了标准化的注释，任何了解XHTML的用户都可以直接阅读。更重要的是，你的读者（开发人员）是使用流畅的日常语言来阅读的。而且那些不关注XHTML的读者也可以只选择阅读他们关注的部分，要做的就是打开浏览器而已。

使用标准的注释也就意味着你不会被限定在特定的线框软件或原型软件中，你可以用各种方法，不管是一个简单的文本编辑器还是各种各样的XHTML编辑工具。同时XHTML语法精炼，不象线框图那样繁琐，再加上你只需要编写文本文件即可，只需要通过浏览器就可以看到效果，这就能够帮助你工作的更快捷、更高效。

事半功倍

如果你是XHTML新手，你将会发现XHTML能让你事半功倍。只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写XHTML。（有两个好推荐：htmldog.com / w3schools.com）而且更妙的是，你不必耗费心思钻研那些时髦的UX工具，就可以深入的领会这种帮你实现创意设计的技术。

分而治之

从蓝图到草图，对线框图的一次次重绘将导致一系列连锁效应，页面或程序设计的工作分配和时间计划都将受制于它。当一个粗糙的设计描画出来后，团队中的一个人就不得不独自奋斗一阵子，把每个页面的草图设计都制作成细节丰富的线框图。但XHTML模式则提供一种分而治之的方法。在我的团队中，我可能负责初始部分的XHTML以及一部分CSS，而其他成员则在我的基础上修改XHTML，加入更多的高级CSS，还有JS。如果解决方案是团队共同提出的，那为什么不让团队所有人来共同设计呢？换句话说，与其用某人的观点来代替团队方案，为什么不让团队每个人都贡献自己的专业知识呢？通过使用XHTML，我们能够利用密切集成的CSS和JS，帮助团队成员使用一套整体思路来贡献自己的能力。

何去何从

当然，本文仅仅是在刺激那些对XHTML原型法感兴趣的人的欲望。如果你想更深入的探索这种方法，特别是那些正置身于传统瀑布模型进程中的人，我建议你们采取一种“小步走”策略。也就是说，先用这种方法做原型，然后与你的团队一起试验一个小型项目，以此作为基础。如果你的经验跟我差不多，你也会发现它对你的UX工具箱是一种异常强大的补充－一个跨越“体验vs技术” 鸿沟的更有效的方法！

迭代设计不是反复返工

奇遇 — 2008-08-31 22:50:59

很关注白鸦要写一个《Design IT.》这样的话题，跟风说说迭代设计。

我们对迭代开发大概都不陌生，应该也知道这里的迭代是开发的一种方式，尤其在摸索着前进的时候，总会回头修改自己的过错，并且在完善过去的基础上继续前进。设计也需要迭代，设计也需要机会成熟，在我们具体做设计时，不免总会有这样的感慨。对于自己没有接触过或者面对全新的产品的时候，我们不免要有一个认识的过程，这时候很难一下子把所有的工作做完善了，总会存在这样那样的问题。

需要迭代没有错，但我们应该尽量避免无休止的返工。在做设计时，我们都知道首先要有一个明确的目标，如果我们改变了当初的目标，那就不应该再称为迭代，应该称之为重新开始。迭代是针对某个事情而言，如果你开始在做A产品，后来你觉得做A产品没有前途，于是改变了想法，开始要做B产品了，你不能说做B产品是对A产品的迭代。在很多小公司，太多的人打着“迭代”的旗号反复返工，最后一事无成，还胸有成竹的说，做产品需要迭代，我们不可能不做调整。可无目的的乱改变，最好还是不要玷污“迭代”这个词了。

记得几年前我去一家公司面试，有机会和他们的老员工聊了聊，大概如下：

“我们做事情很认真，总是想把产品做完美了”他（那个老员工）很兴奋的告诉我

“哦，那你们进度一等很慢吧？”我反问道

“不对！我们进度很快，我们老板要求三天内把要做完这个商城，包含设计和实施”他很自豪自己的能力。

“三天？这是一个商城哎，你们考虑各种界面的逻辑了吗？要怎么运营？你们的目的是为了什么？”我很好奇他们有这么快的速度，不禁反问道。

“看，这个是我们这次要完成的界面，之前我们实施了两个了，觉得不好就扔掉了，现在要重新做，时间非常紧！你同意过来的话，我和老板说说去，现在咱们就开始做吧！”他很着急的对我说。

“先不这么着急吧！？你们这个界面为啥要做成这样？会不会做完这个还要重新做？咱们没有目标永远都做不出东西来”我很诚恳的说。

“管不了那么多了，我们必须高效的工作，迭代式的设计开发，我们这样效率很高！”他同样很自豪的说。

“这样叫迭代？应该叫返工比较合适吧？你们会无休止的返工下去，你们还没搞明白要做成什么样。”我反问道

“哎，你不理解，你去和老板谈吧～”他开始没有耐性了

后记：后来和他们老板聊的时候，事实上他们不是在做迭代，只是要在某个时间内做完那个活，然后还要再重新思考该怎么做，他们没有搞明白要做的是一个啥产品，一个无头的苍蝇而已！

设计的迭代总是在无意识的进行了，设计产品很难是一蹴而就，因为你的工作总是基于上一个阶段的结果，和以前做过的工作有些重叠；比如你在出一个设计方案，可能你的方案要做好几稿才能确定，每一稿的改进想比都是基于前一稿的基础上在进步，或者做不同的考虑，这个思考的过程本身就是一种迭代的工作。从大的层面上讲，设计的每个阶段都会基于上一个阶段的结果，毫无理由的做出一个设计稿，恐怕不是一个成熟设计师的风格，只是“拍脑门的主”罢了。

相关话题：迭代的设计源地址：http://www.ui123.com/blog/?p=108

用户体验要素模型和UCD流程

大智 — 2008-08-28 11:42:16

这是一个著名的模型，把UCD过程中的每个工作步骤和内容都完整而流畅的概括进来。很大程度上帮助我理清了UCD相关的混乱头绪。以这个模型为基础，我整理了一个比较可行的UCD流程。

当然迫于条件的限制，我们不可能有机会去做用户研究相关的工作，通常是从竞争对手的分析中来获得关于用户的理解和灵感。用Jesse James Garrett的话说，在相同领域做相似的事情的研发团队，所服务的用户必定具有某种程度的相似性。按照产品分析和设计套路倒推，解剖优秀产品的设计策略，可能是快速建立用户认识的窍门。可能有人觉得理解用户是市场的事，显然这是片面的。其实理解用户能够在以用户为中心的设计过程中帮助设计决策，如果没有这个认识，很可能会在后面的设计决策和讨论中陷入个人英雄主义的表演和政治博弈之中。当然，寻找用户还能使我们收获更多的领域知识，整理对手的优缺点，并能在后续的概念设计、交互设计和原型设计中提供极大的参考价值。

这个流程不是一个快速开发的流程，虽然在用户分析中投机取巧节省了一点时间，但是在交互设计阶段需要消耗相当的努力和创造激情，当然还有时间和成本。在急于看到成果和关心“成本”的队伍中，很容易被一笔带过或敷衍了事，很多人习惯以看到界面设计框线图作为设计成果的标志，呵呵，画框线图其实是很简单的。缺少慎重的交互分析基础的框线图，很容易浮于形式而缺少内涵。

和朋友们交流一下吧！

六个阶段，每个阶段又有关键的工作内容和要求。

第一阶段：基础调研

竞争产品分析
寻找市场上的竞争产品，挑选3-5款进行解剖分析。整理竞争产品的功能规格；并分析规格代表的需求，需求背后的用户和用户目标；分析竞争产品的功能结构和交互设计，从产品设计的角度解释其优点、缺点及其原因，成为我们产品设计的第一手参考资料。

领域调研
结合上述分析基础和资料，纵观领域竞争格局、市场状况，利用网络论坛、关键字搜索等手段获得更多用户反馈、观点、前瞻性需求。

产出物：相应的对比分析文档和领域调研报告

第二阶段：产品分析

产品定位
从软件提供者的角度分析产品推出的意义和重点关注的方面，实际考量、丰满决策层的idea，明确列出产品定位，通过讨论修缮取得决策层的认可；

用户分析
结合竞争产品的分析资料，采用定性分析的方法，获得对产品目标用户在概念层面的认识；

产品概述
以软件提供的身份，以最简短的文字，向用户介绍产品，突出产品对用户的价值。避免功能点的简单罗列，而应该在归纳总结的基础上突出重点；

功能需求规格整理
在归纳关键功能的基础上，结合竞争产品规格整理的领域认识，从逻辑上梳理需求规格列表，重在逻辑关系清楚、组织和层级关系清晰。划定项目（设计和研发）范围；

产出物：用户分析文档和产品概述、功能规格列表

第三阶段：交互设计（功能结构和交互流程设计）

产品概念模型分析
从产品功能逻辑入手，结合对常见软件的经验积累和竞争产品的认识，加上对用户的理解，为产品设计一个尽量接近用户对产品运行方式理解的概念模型，成为产品设计的基础框架；

功能结构图
在产品概念模型的基础上丰富交互组件，并理顺交互组件之间的结构关系；

使用场景分析
模拟典型用户执行关键功能达到其目标的使用场景；

交互流程分析
模拟在上述概念模型和功能结构决定的产品框架之中，支持使用场景的关键操作过程（即鼠标点击步骤和屏幕引导路径）；

产出物：产品设计文档的交互设计部分

第四阶段：原型设计（信息架构和界面原型设计）

信息架构和界面原型设计
设计产品界面中应该包含的控件数量和类型、控件之间的逻辑和组织关系，以支持用户对控件或控件组所代表的功能的理解，对用户操作的明确引导；所有界面设计成为一套完整的可模拟的产品原型；

设计要点说明
对界面设计的重点添加说明，帮助涉众对设计的理解；

产出物：产品设计文档的原型设计部分

第五阶段：详细设计（详细设计和伪代码编写）

详细设计
完善设计细节、交互文本和信息设计（Message box）；

设计和逻辑说明
对界面控件/控件组/窗口的属性和行为进行标准化定义，梳理完整的交互逻辑，用状态迁移图或伪代码形式表示；

产出物：产品设计文档的详细设计部分

第六阶段：设计维护（研发跟踪和设计维护）

语言文档整理
设计通过评审之后，把产品中所有的交互文本整理成excel文档，预备研发工作；

研发跟踪维护
进入研发阶段后负责为研发工程师解释设计方案、问题修改、文档完善、Bug跟踪等；

产出物：产品语言文档，设计调整维护

Design IT. (1)，迭代的设计

白鸦 — 2008-08-27 16:18:44

从大的发展来看，
网站就是一块试验田，一块在错误中成长、在错误中变强变大的试验田。这决定了互联网产品的成长路线，一定是一个反复修正和迭代的曲线。
很多，多年前的产计，当时未能取得成功，又得还一败涂地。拿到今天，稍加包装就成了最热门最合适的设计。究其原因，我认为大多数都属于“时机问题”，当初那些产品设计，面临的很多环境并不成熟。究其错误，我认为大多数都属于过于“激进”，在互联网这个世界，如果你要从一开始就做彻彻底底的去创新，基本没有成功的可能。
回顾互联网历史，我们不难发现，几乎所有成功的产品都是一个不断在演变的产品。包括yahoo、google、myspace、facebook、taobao、QQ等等，乃至MS。

回到产品设计本身，
早期“阶段性”的流程方式给我们产品开发和设计，带来了无尽的“返工”和低质量设计。往往前一个“阶段”的细节失误，就能导致后一个阶段的彻底垮工。
特别是我们从目录网站走到内容网站，又走到了今天的社区，网站本身的跌代性和反复修改变得越来越快。“阶段性”的流程方式无法“多团队同时协作”，导致的低效率，越来越凸显。

于是我们开始针对“产品更新快”、“迭代频繁”、“多团队协作”，等特性需求而改进的一些产品设计流程。这样的流程从大体上可以分成三个要点：按阶段发展相互依赖 + 表现层和底层相对分离 + 循环渐进反复迭代。

可以尝试用这样的一张草图来表现这种“流程”：

1、产品团队是核心。
产品团队发起项目，做前期的整体调研和评估，确定产品的定位、方向，以及大的产品概念设计。
在这个基础上将所面向的用户群进行大致划分，对不同用户群体的需求进行概要分析和总结。
最后产出：产品的整体框架，重要需求点的业务逻辑。

2、表现层和底层相对分离。
对于研发来说，产品的产出物都是数据。产品架构就是他的底层数据结构，业务逻辑就是他的数据逻辑。（研发我只懂皮毛，具体内容不一定完全正确）
对于设计来说，之前对于用户群的划分、对于需求的分析将演变成未来网站的内容设计；产品架构将演变成网站的信息架构（栏目、布局、导航等），业务逻辑是未来交互设计的依据。
最后，研发的前端的接口和设计的前端开发相结合。

3、这样做最大的好处在于：
业务发展到一定时候，当底层需要升级或者改进，表现层可以不用变化；
如果表现层的设计需要“改版”，底层可以不用变化；
只有当产品方向有变，或者业务逻辑发生变化，才会牵扯到底层和表现层同时变化。

4、按阶段发展相互依赖。
单看产品+研发，或单看产品+设计，每一个从上至下的过程都必须具备先后的阶段性，上一个的过程决定了下一个过程的大致范围，下一个过程影响并补充了上一个过程的详细内容。
比如，没有大的产品框架就没有具体的信息架构，在具体的信息架构设计过程中，又会修正并补充整体的产品框架。
再比如，没有需求分析，就不能有具体的内容设计，在具体的内容设计过程中，又会细化需求并有可能合并或者拆分已经修改需求。

5、循环渐进反复迭代。
这一点和第四点有很大的关系，理解这一点可以先看一下Jesse James Garrett 在《THE ELEMENTSOF USER EXPERIENCE》一书中（这是一本每个产品设计者都应该阅读的入门好书，中文叫《用户体验的要素》，由Angela翻译，因为我很讨厌这个书名里莫名其妙多了一个“的”字，所以以后我只会引用英文书名。），关于“迭代”的解释：

JJG在把体验分成了战略、范围、结构、框架、表现五个层面。我认为这五个层在细化的过程中，已不很适合如今的互联网产品设计，而且内容过于粗略，属于概念性质的东西，很难应用到操作层面。但，他在这里讲述这五个层在具体应用中的迭代关系，可以应用现在的设计中。

Angela是这样翻译的：“你应该计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。… 在我们知道基本形状之前，不能为房屋加上屋顶。… 要求每个层面的工作在下一个层面可以开始之前完成，会导致你和你的用户都不满意的结果。… 一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成”。

拿到这里会有一点小变动，应该这么说：不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作。（这也是为了我在前面给“完整”“整体”“大致”等关键词加粗的原因）
比如，不要把需求整理的非常详细以后再去内容设计，只要在内容设计该结束的时候完成需求整理；不要在开始信息架构设计的时候完全确定内容设计，只要在信息架构该确定的时候完成内容设计。也就是说“需求整理在信息架构开始的时候完成即可”。

（当然，这种做法一个更大的问题会出现：文档维护比以往阶段性的方式更繁复。这一点，后面会详细谈到。）

不可分割的“用户调研”
细心的人可能已经看出，上面的设计并没有加入“用户”的内容。没错，上面的图只是在说“设计”，并没有提到用户调研。
用户调研应该贯穿于设计的任何一个环节，在整个设计过程中既起到“引导”的作用，又起到“校验”的功效。加入了对用户的研究以后，整个“迭代的设计过程”才会变得完整和丰满。

事实上这边文章应该属于“迭代设计”的一半内容，在以往的培训中我会加入用户调研部分进去（比如，这张图白板左边是上面的内容，右边就是用户调研加入进去之后的“产品设计”过程。右边的一半内容都是用户调研）。这篇文章就不细说了，《Design IT.》系列正式完成的时候再补充进去。

PS:
《Design IT.》将是一个很长期，很完整的系列。从设计方法，到产品市场、到具体的设计，到最后的测试和产品类的线上运营。
欢迎有兴趣的朋友对每篇文章进行指正和补充。（为了保证更高质量的评论，我将关闭这个系列文章的评论。请在你自己的博客用“文章”回复，或者将你的文章发布到UCD大社区里。咱们可以把这些文章都聚合成话题）

相关话题：迭代的设计源地址：http://uicom.net/blog/?p=773