加载中…
个人资料
  • 博客等级:
  • 博客积分:
  • 博客访问:
  • 关注人气:
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
正文 字体大小:

用户界面设计与开发精解--以用户为中心的设计(UCD)

(2008-09-04 20:21:30)
标签:

用户界面

可用性

产品计划

原型

ucd

ucd培训

用户体验

it

D.计划

     面临特定的、难度较大的任务时,清楚地制定一个计划是最合理的第一步(如图2.7所示)。

     以一种可度量的方法,把重点放在用户界面和可用性过程要素上,有助于发现一些含有较大风险的非过程因素。为了取得成功,须注意以下几点:

◆ 产品计划需要特别说明过程中的每个步骤、用户界面及可用性成果,包括依赖性、假设和技术方法等进度里程碑

◆ 产品计划会标识并提出主要的风险因素

◆ 一个产品计划应尽可能具体描述有利手项目效率的技术(如降低风险的方法和保证满足需求的方法)

◆ 产品计划的执行需要说明并跟踪用户界面和可用性等与计划相关的成果的质量

◆ 管理方法是对前期参与的详细说明。和其他管理任务一样,尤其重要的是要建立一支具有相应技能的适当团队。多样化团队的思想理念是:成员都具有所需能力

◆ 分配责任和义务

 

◆ 确信已建立了产品用户界面和可用性目标和标准

第8章将深入讨论如何制定产品计划。

E.需求

     对最终用户来说,界面、可用性、一致性和集成性等方面的需求是特别细致的,但缺乏特点。与功能特色相比,对用户界面和可用性上的需求有很大的想象空间。因为缺乏计划且思路不清晰,导致了很多非常虚幻的用户界面和可用性结果。需求阶段特别需要做的任务包括:

◆ 描述用户,参见第3章和第10章

◆ 用户任务,参见第10章

◆ 当前的可用性,参见第14章

◆ 用户界面特色,参见第5章

 

◆ 发展趋势,参见第20章

◆ 对用户界面、可用性和一致性等方面的需求,参见第9章.

F.概念设计

     通常,计划和概念设计不会在过程中清楚论述,但它会被认为是用户界面的构架。概念设计从总体上概括了高层的描述、提炼和信息,它为开发人员和最终用户提供一个关于产品、产品结构和产品界面的大蓝图。

◆ 概念是源于实例的一些抽象想法,设计是对系统元素的、深思熟虑的组织形式

◆ 概念设计如同一个描绘产品主要功能、各部件组织和未来用途的轮廓或蓝图

◆ 与产品概念设计相关的开发成果是对以用户为导向的整体介绍和描述产品功能与用户界面的文档

第11章将提供一个虚拟的目标用户模型,但其设计原则和指导方针将在第12章进行描述。

G.设计

     设计是一个基础的、对实体构成元素的设计和安排。用户界面的设计实际上就是收集最终用户对一个软件的可感知功能,包括用户输入、交互和系统对用户输入及交互的回应。设计基于用户界面的应用软件,有很多方法。需要考虑的一个关键是将设计分解成很多小块的、容易理解的成果—如同打磨一颗珍珠一样。由于理解、集成和管理细节的工作量非常大,所以有必要实施迭代和分层设计。目前,为了确保用户可见的基础底层组件彼此正确集成和支持,还要执行用户界面的非用户界面的工作。

扩展性设计将在第16、17、和18章展开描述。

H.原型化

     原型和模拟是对早期设计进行评估的有效工作。模拟,或是模型,是设计的实例化,但没有必要用未来的实现平台来构造。取决于具体的时间限制、设计问题、能力和可用工具的不同,素材板或素材纸的模式将是一种恰当的设计表示方式。原型是使用未来实现平台实现的一个设计实例,包括硬件、操作系统、实现语言和工具。

     不同类型的模拟和原型呈现了用户界面或系统功能表现方法、用户界面表现的逼真度和介质构造等有深度和广度的问题。因为原型的概念涉及到很多方面,所以被赋予了不同的名字:用户界面、功能、低精度(即粗略)、高精度(即细化)、轻量级等。详细定义工具及其限制总是好的。如何构造原形,将在第13章详细讨论。

I.规格说明

     用户界面的规格说明就是指以文档方式对产品设计的实例化。它描述用户行为、软件外观和特殊情况的状态。即使是简单的应用软件,也可能有非常复杂的规格说明。有关规格说明的详情,请阅读第17章

J.构造(编码在单元测试)

     用户界面软件是设计的最终实例化,它经过了很多阶段的演化;例如模拟、原型、构造和文档。同样地,没有用户界面的软件也有很多阶段用于构造和编写文档。过去有句名言说道“软件需要写3遍才能保证正确”,做原型对进入部署环境就取得成功大有帮助。有关构造的详情,请阅读第19章

K.评估

     所有的评估技术都要涉及到产品的潜在用户。为了确保需求得到满足,尽量在早期频繁使用这个技术,这是非常必要的。一种最佳实践的方法是在计划、设计、构造、评估和部署等阶段都有实际用户的参与。这样的方法称为参与法。

     评估技术贯穿于产品的整个生命周期,但发生于较细的、有用户参与的开发周期中的一些离散的点。有关可用性评估方法的详情,请阅读第14章

L.迭代

     为了实现用户界面的既定目标,所有标准都必须清楚,便于管理者和开发人员理解和接受。整个产品团队必须达成真正的个人承诺上的一致,而不是口头上的接受。一旦开始开发用户界面的设计,就可以会为了达到目标而多次迭代。如果达不到目标,整个设计可能会被抛弃。有关迭代的详情,请阅读第15章

M.部署

     当然,产品一旦满足了需求和用户的需要,就会开始为最终的使用进行部署。此时,还有一部分跟踪活动,如评估未参与开发过程的用户以及指导和进行的先期测试。软件也是有设计和开发阶段没有测试或预见、但又执行了用户任务。此外,业务变更也可能产生有新的产品需求。为最终用户完成部署后,再随着基本功能的进展而展开测试是最合适的。有关部署的详情,请阅读第19章

0

阅读 收藏 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 产品答疑

新浪公司 版权所有