参考资料--软件项目的设计流程与规范草案.docVIP

前言 第一个应该强迫我们思考的地方：我们在做什么？用户需要什么？ 答：所有参与者——设计师、程序员、信息架构师、项目经理——我们所开发的每一个项目不是基于毫无边际的科学研究，也不是华而无实的艺术创作（当然, 除非它是很特别），在我们开始写第一行代码，描第一个象素的时候，我们就应该清楚的意识到：作为软件界面的网页，作为超文本系统的网页最终需要面向的对象一定是用户（而且是未知的用户，他可能是电脑高手，也可能对电脑一无所知），且无论我们怎么去优化代码，怎么去创作界面，都在追寻唯一的目的——人性化的操作、易用性的用户体验。 而用户到底需要什么呢？ 在最便捷的方式下，甚至是在不需要思考的操作中，能够顺利找到自己想要的信息；在功能复杂的软件上能通过严谨简单的逻辑构架来处理事件和操作相应的功能等等…… 我想，如果不是在应付客户的情况下，用户体验要素一定大于保险公司的服务态度吧。 第二个应该强迫我们反思的地方：我们在做什么？公司需要什么？ 答：所有参与者——设计师、程序员、信息架构师、项目经理——我们都在认真和坚持原则的情况下去效率的完成一件成品（或许我们都还认为这不错，或许最后输出的成品也都还不错），但往往制作过程是经过直线传递的特殊性而导致了流程被动，许多步骤被忽略，诸多问题没有争议，核心的反馈意见没能传递到产品开发团队中去。更让我惊讶的是——项目开发中可重复利用的资源被巨大的浪费，而没有谁去制定一个适用于自身团队的规范，效率下降了，质量也没得到改进，导致项目预算超支。 ——也许问题的严重性并没有这么可怕，但既然能让这一切变得更好，我们又何乐不为呢？团队中的每一个人能准确的去控制工作进度，遵守公用的特征是非常有益的，当然，资源重复利用更是转化效率的第一定律。 而公司到底需要什么呢？一个高效率的团队，一个好的产品——这些都不谋而合。 产品详细开发流程及部门规范： 1.战略层【自身目标与用户需求】系统的需求包括四个不同的层次：业务需求、用户需求和功能需求、非功能性需求。业务需求说明了提供给用户新系统的最初利益,反映了组织机构或用户对 系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中 予以说明。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。 非功能性需求是用户对系统良好运作提出的期望，包括了易用性、反应速度、容错性、健壮性等等质量属性。需求获取就是根据系统业务需求去获得系统用户 需求，然后通过需求分析得到系统的功能需求和非功能需求。项目视图和范围文档就是从高层次上描述系统的业务需求，应该包括高层的产品业务目标，评估问题解 决方案的商业和技术可行性,所有的使用实例和功能需求都必须遵从的标准。而范围文档定义了项目产品所包括的所有工作及产生产品所用的过程。项目相关人员对 项目的目标和范围能达成共识,整个项目组都应该把注意力集中在项目目标和范围上。 确定人员分工及详细的业务流和相关阶段性时间计划。.范围层【对需求的整合】3.结构层【交互。如何、可以、应该……】用户在中穿梭浏览的体验information architecture） 它是一个整理信息，信息系统使用者需求的过程，主要是要将信息变成一个经过组织、归类、以及具有浏览体系的结构。结构Interaction Design） 以用户体验为基础进行的人机交互设计是要考虑用户的背景、使用经验以及在操作过程中的，从而设计符合用户的最终产品。. 框架层【布局】 4.12局部导航（产品中较特殊的子集导航） 4.13辅助导航（产品中关链内容的快捷途径,许多情况下它是以图文形式出现） 无论是全局导航、局部导航还是辅助导航，都是为了用户能在繁琐复杂的信息架构中，更快的达到最终目的地。 4.13 产品地图与内容索引表 产品地图是给用户一个简明、关于产品整体结构的快捷游览方式。产品地图索引通常提供所有一级导航的链接，并与缩进的显示，主要的二级导航链接起来。索引表往往是按字母顺序排列的、链接到相关页面的列表,它常与内容相关。 4.2版式布局与信息排列 在这里，我们将要聚合界面上所出现的全部元素，并且把它们放入相应的“盒子”中。首先，我们必须建立比“盒子”更为重要的父级框架，当然，框架与“盒子”一定是密切相关的。接下来，再将所有出现的内容要素总汇成各个不同的种类。 4.4 可用性设计 大体说来，这里的可用性设计与结构层的交互体验有相同的概念。它们的目的在于加强易用、易学、易理解，使真正成为方便地为人类服务的工具。 表现层【视觉呈现】