概念证明。

在一些团队中，对项目的未来方向存在分歧。 原型可以用来证明一个想法或新方法有优点或价值。 原型可以帮助说明一个想法是可行的，以视觉和互动的方式表达它的品质，并且/或者激励团队成员从另一个角度思考问题。

设计探索。

如果设计交互式软件，则探索如何使用某些内容的唯一方法是创建模拟并与之交互。 有时，模型与可用性研究联系在一起，在可用性研究中，原型的部分可以以结构化的方式进行评估。 有时它只是一种向开发人员清楚地表达某些东西应该如何工作或外观的方法。 在许多情况下，设计人员可能只是在进行实验，试图了解什么方法可能有效。 团队中的任何人都可以使用原型来探索设计问题，而设计人员通常是最熟练的。 设计探索应该着眼于解决产品中公认的特定问题。

技术探索。

研究问题实现方法的开发人员经常尝试不同的编码技术，看看它们是否有效。 在每种技术中使用 COM+、动态 HTML (DHTML)、Microsoft Win32 或特定的编码方法会有不同的权衡。 有时，原型代表了对什么技术可以很好地支持某个 UI 功能的探索。

有时，原型的创建是出于这些原因的结合。 如果团队计划得当，他们可以分配时间让开发人员、设计人员或项目经理一起开发原型。 在这种情况下，明确定义每个团队成员应做出的目标和贡献非常重要。 每个人都应该清楚目标是什么，利害关系是什么，以及潜在的结果是什么。

谁参与其中？

任何人都可以非正式地进行原型设计，无论他们的背景或在项目中的角色如何。 制作一个简单而有效的原型很容易，只需从 Adobe Photoshop 中提取一个位图，将其放入 Microsoft FrontPage 网站创建和管理工具中，并添加活动按钮或链接。 这些轻量级原型只能到此为止，对于复杂的交互可能会变得笨拙。

对于大型团队更正式的原型，开发人员或项目经理通常会与设计人员和可用性工程师协作。 他们将一起产生想法，构建一个代表最佳想法的原型，然后进入实验室，看看它在解决用户问题方面的有效性。 如果开发人员能够抽出时间，或者需要技术专业知识，开发人员可能会参与其中。 通常，设计人员或项目经理会编写大部分脚本或编码来构建原型。

什么时候应该建造原型？

根据原型的范围和所需的详细信息级别，原型可以在项目期间的任何时候建造。 大多数情况下，它们是在项目的早期，在规划和规范阶段，在开发人员编写任何生产代码之前创建。 这是探索需求最大的时候，也是所需时间投资最可行的时候。 如果开发人员而不是项目经理或设计人员进行原型制作，那么时间安排就变得更加重要，因为需要确保在原型中投入的工作在开发计划中得到考虑。 任何 UI 版本的规划都应该包括某种程度的原型制作。

在项目后期，较小的原型可以帮助解决棘手的设计和技术问题。 对对话框或网页的行为方式的快速 HTML 模拟有助于回答开发人员的问题，或者让其他团队成员了解所需体验。 在某些情况下，能力强的项目经理或设计人员可以在 Microsoft JScript 开发软件中实现行为，并近似开发人员需要思考的大部分编程逻辑。

根据最终结果的范围和精确度，创建原型所需的时间可能会有很大差异。 一个非正式的原型可能意味着一个人要工作几个小时；更有条理的努力可能需要整个团队数周的努力。

重点应该放在哪里？

在原型中，只构建所需的设计部分。 有不起作用的按钮，或者永远不会更新的文本，这是可以的。 只要能够体验到所需的交互，就可以为其余部分使用烟雾和镜像。 下面是应谨慎关注工作的一些原因：

建造原型的成本。

建造原型所涉及的成本应降至最低。 制作原型的挑战在于认识到有效回答设计问题所需的最小投资。 这就是可用性研究的关键所在，因为它们清楚地确定需要最多工作的 UI 部分。 即使没有可用性研究，也要清楚地定义在原型设计中解决了哪些用户问题，或者改进了哪些任务。

有限的生存期。

原型应具有明确定义的生存期。 最终目标是在团队会议上做演示吗？ 高管评审会议？ 规范审查？ 可用性研究？ 确定设计可解决用户问题？ 一旦满足了这些特定目标的需求，原型就应该放在一边。 基本思维模式是，原型中生成的代码或位图将被抛在后面。 在产品中存在代码或视觉效果的情况下，可能会有例外，但预期情况并非如此。

团队面临不堪重负的风险。

向开发人员和团队成员展示原型是件棘手的事情。 过于复杂或精心制作的原型，带有令人惊叹的视觉效果和动画，可能会让人不知所措。 始终要知道要走多远，以及应该认真对待原型的程度。

什么是作用域？

在确定原型制作工作的重点时，请考虑以下事项：

客户需求。

从了解用户的关键问题或需求（也许是可用性工程师提供的内容）开始，可以了解 UI 设计中哪些部分值得最探索。

可用性研究任务。

如果为可用性研究创建原型，请与可用性工程师讨论哪些特定任务将成为研究的一部分，并围绕这些元素进行设计。

团队意见。

将有关原型的想法汇集在一起时，与团队中的关键开发人员交谈。 对什么是合理的、什么是可能的、什么是下一个版本不需要考虑的情况有一个基本的认识。 在某些情况下，如果这是一个关键点，团队需要受到挑战，那么可以考虑超越他们所说的设计的某个方面的可能性。 然而，不要对原型的每一个方面都这样做，因为在突破极限和压倒团队之间有一条细线。 如果希望通过向团队展示几个版本的愿景来激励团队，那么就去做吧。 但是，如果需求是为下一个版本定义特定的更改，那么就把精力集中在这些更改上。 确保以模块化的方式提出具体的更改，并向开发人员展示构建设计的路径。

广度与深度。

对于较大的原型，需要额外考虑广度与深度的关系。 设计中的每个功能应该只起一点点作用，还是应该选择一个功能作为原型，包含几乎所有的部分和选项？ 尽量不要同时做这两件事，因为结果可能是一个庞大而笨拙的原型，难以修改，也难以丢弃。

灵活的原型

重点制作原型资源的一种方法是集中精力进行智能设计。 通过允许一段原型代码执行许多不同的想法，可以创建更有效的原型。 比起创建 5 个不同的原型，不如考虑制作一个可以切换原型不同属性的原型。

工具栏应位于左侧还是顶部？ 应该在主页上显示 10 个项目还是 20 个项目？ 一个好的原型有一些内置的选项面板，可用于更改原型外观或工作方式的参数。 将这些选项面板隐藏在原型中，尽量避免可用性参与者在测试过程中意外发现它们。

挑战在于保持原型的简单性，但仍然足够有用，可以向团队成员展示，展示不同的选项，并获得反馈。

Beta 版与原型

Beta 版本不符合原型的条件，因为它们是完整的工程成果。 如果在 beta 版的某个功能中发现了关键错误，即使这可能符合产品的最大利益，也不太可能被丢弃。 开发商、测试人员和设计人员已经投入了大量时间，面对错误决策的压力非常大。 Beta 版当然有助于发现错误和缺陷，但在对特定设计方向的价值进行受控研究时很少有用。

工具和技术

有多种不同的工具和技术可用于创建原型，每个工具和技术都有其优点和缺点。 在确定哪个工具或技术是正确的之前，请考虑正在原型制作的设计工作类型和原型制作工作的目标。

Microsoft Visual Basic 或 C#。

这是创建 Windows 样式 UI 原型的最快技术。 Web 浏览器对象使 HTMLUI 与标准 Windows 样式组件的集成变得容易。 虽然使用 Microsoft Visual Studio 经验丰富的开发人员确实能够在 C/C++ 中更快地生成 UI，但这会产生在生产代码中重用 UI 原型代码的诱惑。 要认识到快速而脏的 UI 原型的目标与高质量的工程有很大的不同，需要遵循一定的规则。 请确保清楚正在编写哪种类型的代码，并且团队或经理了解将要丢弃的内容。

Microsoft Expression Blend + SketchFlow。

SketchFlow 是一种可视化工具，用于为 Windows Presentation Foundation (WPF) 和M Microsoft Silverlight 桌面和 Web 应用程序设计、原型制作和创建复杂的用户界面。 可以通过绘制形状、绘制按钮和列表框等控件、使应用程序的各个部分对鼠标单击和其他用户输入做出响应，以及将所有内容设置为独特的样式来构建应用程序。

Adobe Director 或 Adobe Flash。

控制器是设计人员中常用的 UI 原型制作工具。 它最适用于多媒体或非标准 GUI 设计，或需要大量动画的原型。 与 Visual Basic 相比，它的高灵活性使得它对于 UI 风格的 UI 来说很麻烦。 但是，熟练的 Director 用户可以毫不费力地生成 Windows 或 Web UI。

HTML。

FrontPage 和其他 HTML 编辑器允许快速创建简单的原型。 为了表达一个想法，通常可以创建位图来说明用户交互的顺序，并将它们放在 FrontPage 中。 这些图像可用于模拟如何与设计交互。 JScript 和 DHTML 将事情提升到另一个级别，从而允许非常复杂的逻辑和交互。 如果使用 HTML 为网站制作原型，那么刚才为 C/C++ 描述的警告也适用于此，即不要陷入将快速原型代码与生产质量工程混为一谈的陷阱。