HYXT Blog

we produce valuable software for K12.
clock November 19, 2008 19:06 by author War3

原文出处:http://hi.baidu.com/interaction_design/blog/item/2f610b4e7c0fe0ccd1c86ae6.html 

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

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

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

和朋友们交流一下吧!

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

第一阶段:基础调研

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

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

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


第二阶段:产品分析

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

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

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

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

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


第三阶段:交互设计(功能结构和交互流程设计)

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

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

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

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

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


第四阶段:原型设计(信息架构和界面原型设计)

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

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

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


第五阶段:详细设计(详细设计和交互逻辑表述)

详细设计
完善设计细节、交互文本和信息设计(Message box);

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

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


第六阶段:设计维护(研发跟踪和设计维护)

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

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

产出物:产品语言文档,设计调整维护


clock October 16, 2008 10:38 by author Sky Jia (贾超)

什么是体系架构的生命期?应该考虑到何种程度?它对业务可能有何影响?为了回答这些问题,Dan Pritchett引入了“体系架构保质期”的概念,他将其定义为“开始设计新的系统时,一组模式和技术的适用期限”。他认为体系架构保质期能持续5年左右,经过两到三代以后,任何体系架构至少会有部分的改变。否则,该体系架构就会很陈旧,而且在适应业务需求发展时会引起成本的增加。基于此,Pritchett认为“体系架构通常有10到15年的有效期”。为了支持自己的论点,他给出了自1990年以来发生的技术、体系架构演进的一系列例证。

Pritchett主张,如果没有在体系架构生命期结束的时候更新体系架构,可能会对业务有重大的影响。但他也承认,改变主要的体系架构会导致可观的成本,尤其是“你在供应链里已经拥有了坚实的客户基础,以及超值的业务特性”。正如争论:是否应该避免架构重写?中涉及的几个作者所强调的一样,改变甚至是破坏性的。不过Pritchett认为,不采用新的模式和技术会带来更大的成本。这些技术和模式通常有助于提高开发者的效率、降低部署的成本。拒绝利用这一潜在的竞争优势相当于让竞争对手占尽先机,对业务来说这可是致命的:

被忽略的是,新的模式和平台无论如何都能用来破坏你的业务。如果你拥有成功的业务,许多人也会想分一杯羹。技术就成了他们追赶你业务的工具。他们会以更低的成本或者更具竞争力的特性提供和你一样的服务,这引起的破坏可要远甚于内部体系架构改变所引起的破坏。

在他第一篇文章的续作中,Pritchett提出随着新模式和技术的涌现,主要体系架构改变的必然性上存在一些细微的差别。他曾经讲过,体系架构的生命期依赖于其轻松扩展以适应演进业务需求的能力,他将这一点转换为技术术语,解释为“随着不断风行的新技术而被更新”的能力。“遵循优良构件设计的标准体系架构原则,保持组件间最大限度的松耦合度”能强化这一能力,使得这些构件可以相互独立地实现和演进。基于识别的一些常见错误,Pritchett提取出了一 些要构建更持久的体系架构可采纳的原则

1. 接口协议和实现策略之间的解耦。这将增加“构件在可选实现技术之间移植的灵活性”。Pritchett建议,构件之间定义像XML或JSON之类的、基于文本的接口可以达到这个目的。

2. 注重关注点分离,即使两个关注点的初始大小差别很大。这可以避免如下情形:为现有构件增加一个新特性,随着该新特性逐渐发展,你最终等于把两个组件实现成一个严重耦合、相互纠缠、难于解耦的组件,特别是当“解耦后无法保持客户已经习惯的旧有行为”,更加难以解耦。

3. 避免无意识的供应商依赖,这种依赖需要深入理解供应商的产品、它们对体系架构及其含义的影响。

4. 最小化持久化绑定,避免数据库依赖。对实体的关键访问路径应该仅通过主键,其它访问路径则应该在资源层进行分离,以便将来在其它形式的持久化中能处理这些可选路径。

遵循以上尽可能降低耦合度的规则可以让我们构建灵活的体系架构,这样的体系架构更容易与新技术和新模式集成,从而降低改变的成本、延长体系架构的生命期。

查看英文原文:Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture


Search

Calendar

<<  September 2010  >>
SuMoTuWeThFrSa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

Categories

Tags