WEB设计经验

【 tulaoshi.com - Web开发 】

作为设计主管，Peter Stern 已经领导 microsoft.com 重新设计了主页并且开发了五个不同的交互工具，这些工具被用于下载中心、产品目录、配置文件中心、 搜索 和注册等联机功能。 他为几个内部工具设计了用户界面，并且正致力于创建将于今年晚些时候发布的下一代主页。

从头衔上，您可能认为我主要关心的是 microsoft.com Web 站点几千个网页的版面设计。的确，这些确实是我所关注的。视觉上的吸引力是重要的，但是这仅仅是工作的一小部分。而最终的目的是确保整个站点运转正常。

我的意思是，人们通常在访问 microsoft.com 时，并未将它当作艺术作品来赞赏。而是为了获得有关产品的信息，或者有一些技术问题需要咨询，或是阅读有关开发商的期刊。所以网站的设计应该尽量清楚和有条理，以便他们能够容易地找到所需信息。

设计站点

在进行 Web 设计时--在设计过程中--形式应该服从功能。这种方法应用于我们站点的整个设计过程中。当然，我们有最新的 Web 工具，并且能够将各种可视的小配件上载到网页上。但是我们认为这样做将不利于为访问者提供有效的服务。

事实上，我经常发现一些站点未将重点放在功能上。常见的错误包括：

用户界面元素不一致。例如，同一个控件在不同的页面上功能不同，或者同一个功能对应几个用户界面控件。

导航栏位置不一致。决定站点的哪些页和功能需要在站点的任何页上都可被访问到。这就是应该保持一致性的“全局导航栏”。

不太注意或根本不注意基本的图形设计原则。例如排版式样、色彩和版面的设计。

相关元素和功能的随意分组。注意将元素放置在网页上的位置和目的。这可帮助访问者从其它相邻的选择和位置来推断某个链接的功能。

使网页过于庞大以至使访问者需要通过典型的调制解调器速度的 Internet 连接进行长时间的下载。这并不是说不应该使用图形，但是您需要对它们进行精挑细选，然后用适当的压缩和颜色索引优化它们。

现在的 Web 站点仍然存在很多问题，这并不奇怪。毕竟，Web 设计“艺术”相对来说还是个新生事物。在四、五年以前，Web 页甚至是普通的。那时，人们好像认为他们的 Web 站点将会吸引访问者只是因为它们存在--并且，可能在某些情况下这种方法确实有效。但是这些站点一般很难看，并且更重要的是，它们真的难以使用。接下来便进入“看看我们能做些什么”阶段，在网页中加入了大量的动画、声音文件以及其它附加件，导致访问者需要长时间地进行下载，但是并未获得多少实实在在的内容。

如今的 Web 设计师们已经吸取了前人的经验和教训。好的站点倾向于简化和快速，同时在功能上有所提高。这是 Microsoft 的目标，而且我们最先承认自己所犯的错误（参阅“Microsoft 的 Web 简史”看一看以前的主页设计）。

设计错误并不总是显而易见的。有时在设计上对一个小元素的移动或更改将有很少或根本没有影响。但是，在其它情况下，它可能确实会对页面功能有所影响。而且如果说我们从过去几年学到了一些东西，那就是小的改动会使 Web 页的运行方式有很大的不同。

明确的流程

若要避免类似问题，我们为新服务（例如“搜索”）的创建或关键的 Web 页（如主页）设计了一个明确的流程。 每个项目都是在一定的基础上开始的，即我们有一个受益于我们站点上的页面、部分或用户界面元素的产品或服务。在早期的产品计划阶段（第 1 阶段），我被要求设计一些初级模型：大致描述页面、部分或功能的草图。然后产品项目组检查产品计划建议，看看此项服务是否可以为 microsoft.com 的访问者真正带来一些实惠。

如果答案是“可以”，那么此项目会获得批准，我们开始写项目说明书（第 2 阶段）。我们在第 1 阶段的草图和概念基础上创建并提出一个更为完整的计划。这时，我们一般还会开始可用性测试（一般会有书面的模型）以了解潜在用户将对计划中的设计做出何种反应。 在最后开发阶段（第 3 阶段），我们创建运行计划服务的 Web 原型，并且进行全面的可用性测试以及内部复查。然后完成站点的代码，修改程序错误，最后站点通过实际运转的 Web 站点向客户发布。

正如您所见到的，可用性在整个流程中扮演着重要的角色（参阅“创建有效的 Web 界面需要认真计划”）。我们可以为用户运行某项任务计时，这样我们就可以在产品以后的版本中对比相同的测试。我们可以使用这种方法进行度量，以确定一个功能的重新设计是否为客户带来任何真正的价