交互设计7日通

文章作者：姜伟　Email:jamewe@yahoo.com.cn QQ:355905　个人网站：it2media.nease.net。转载请联系原文作者
------------------------
在IT界有个关于软件产品的笑话，说为什么微软产品如此热卖，原因就在于他们总是在自己的产品外包装上写上“易于使用”(Easy-to-Use)这几个字，而不论是否真的如此。
其实微软产品上的标签和其他公司的标签都很类似，但是它一家独大所以才成了众人关注的焦点。
不过软件产品要“易于使用”的确是软件产品的重要目标之一。软件产品本质上还是一种工具，易于使用可以使得使用者提高效率，产生更多的价值。因此，软件的购买者会因此愿意为具有相同功能的软件付出更多的费用。从而使能够生产出更加易用软件的生产者获得更多的利润和市场占有率。
由于一直以来软件产品都是一个需求力旺盛的新兴市场，很多用户往往单纯重视软件功能的多少而忽视了使用性方面的要求，使得软件产品在易于使用方面发展缓慢。近十年来，随着软件产品的丰富和市场竞争的激烈，以及用户对软件产品要求的提高，软件使用性的问题终于被越来越重视。
以前的常识是：无法使用的软件不是好软件。现在大家的共识是：难以使用的软件不是好软件。
如果你是一个软件开发商，那么一定要注意软件的使用性问题。如果你是一个软件生产者，那么一定要让自己的产品易于使用。
就好像我们一开始说的那个笑话一样，直接在软件包装上印上Easy-to-use并不代表该产品就易于使用。那么产品的易于使用表现在哪些方面呢？
我们要考察软件产品的使用性-或者说是否易于使用，一定要站在用户的角度上。（从这个意义来说，从来没有参与过这个产品的人也许更能发现问题）而不是生产者的角度上。生产者可能会“敝帚自珍”，更有可能因为各种条件的因素先天的过滤掉某些很好的提高使用性的方案-比如因为生产时间和成本的压力。
这里先说一个结论，软件产品的使用性评估要从四个方面入手：
1、 可理解
2、 可探索
3、 安全保护
4、 使用效果
我们首先举一个例子。比如我们看到下面这个物体，我们是如何去了解它的。
（这里说的物体不包含中间的钢尺）
首先，我们会观察它（你不要说自己从来不看就拿）和它附近的环境。观察可以让我们对它有个大概了解-形状、大小、材质等。可以看到它是由石头制作而成的，一边薄一边厚。中间有个明显的穿孔。还可以知道它是在什么地方。如果是在博物馆里面，应该知道这个属于文物。
从形状来看，比较象刀片。中间的穿孔应该是用来固定的。（上面是我的理解，其实是因为我开始就知道这是远古的石刀。：）第一次看到这个其实有很多解释）
这些都是眼睛直观的印象。下面我们一般会在眼睛观察之后，对这个物体进一步了解。比如拿起来看看重量，感觉一下每个部分的硬度等。这个过程会加深我们对这个物体的理解。
如果这个时候你发现它边缘比较薄的一面很值得注意（因为你要知道它到底是不是一把刀啊），你就用手尝试一下。当然你希望的是尝试一下锋利就可以了，但是却不希望流血（更不希望一下子自己一个手指头掉下来）
好了，如果这个时候我们确信这个物体是类似刀或者起着刀一样的作用，那么我们接下来会用它割一些东西，确定它的适用范围。上面的两把石刀，如果具有相同的适用范围-比如都只能割草，一个割一刀就可以割倒一把草，另一个却需要三刀，那么可以推测大部分人都会优先选择前面那把石刀。
这个图示的例子大家可以自行探索一下。假如有条件的话。没有条件的可以找一个飞行模拟软件:)
可以看到软件的使用性效果评估的四个方面实际上是同人们了解一个工具的实际过程相吻合的。原因就在于：
1、 软件从本质上来说是一种人们的工具
2、 用户对于软件使用性的评估是按照观察、理解、尝试、使用的过程进行的
可理解、可探索、安全保护、使用效果这四个方面，在真正进行使用性测试的时候，基本上是从感性和理性两个方面去进行的。可理解和可探索从感性角度进行衡量。而安全保护和使用效果从理性（也就是数字化）衡量。
好，我们先说了这半天有关软件可用性的问题，那么这些可用性问题，我们用一个词来表示，就是：软件交互。下面，我们就来谈谈大家最关心的问题，如何对软件的交互进行设计。
要设计软件交互，就要明白交互的目的和要素。
从软件交互-也就是使用性-衡量的几个方面来看，软件交互设计的最终目的是为了用户能够更快更好的使用软件，这个是大家都知道的。另外一方面，在实际的软件开发中，软件开发者往往有一定的其他目标-比如商业目标、组织目标甚至个人偏好-这些目标不一定都能保证最终软件用户的交互性。这个时候就需要一定的妥协。
那么软件交互的要素是什么呢？
软件交互的第一要素就是人。这一点说来似乎有点不可思议。实际上，也是成功软件公司的秘诀。
大家都知道微软OFFICE套件打败LOTUS-1-2-3的故事。微软的开发工程师为了了解大家使用办公软件的习惯或者说办公的习惯，专门到不同的办公室中观察使用者的使用习惯。从而造就了后面的成功。
值得注意的是，微软的开发工程师他们找的是什么用户呢？是在办公室工作的用户。那些不在办公室工作的用户不在考虑之列。按照我的看法，就算是在办公室工作的用户也不都是最重要的用户，那些购买了办公软件或者打算购买办公软件的用户才是最重要的。
软件交互的设计，第一要素就是要找到你的软件服务的和可能服务的人。
要对这些人进行较为清晰地描述：他们的职业、年龄、爱好、对计算机的熟悉程度、文化程度，甚至性别。即使这些都无法知道，起码要知道在你的软件提供的功能中，会吸引那些人。
软件交互的第二要素就是交互元素。我们把交互元素分为4种：交互场景、交互对象、交互方法和交互事件。
下面按照交互的4个要素，分别讨论一下下面的问题：
1、 如何寻找目标用户和发掘用户交互需求
2、 如何辨识和使用交互元素
3、 如何设计和使用交互逻辑
4、 如何通过交互费用对交互进行验证和测试
(一)、寻找目标用户和发掘用户交互需求
我们首先来看，如何确定目标用户。
确认目标用户一般是从商业角度考虑的，也就是说从市场方面看，谁会购买我的软件产品？谁是可能的购买者？谁是潜在的购买者？
在目标用户的确定上，可以参考同类产品的用户群。
一旦确定用户群，就有用户群的特征。比如：
年龄、职业特征、计算机使用经验、同类产品使用经验、爱好等等。
确定了用户群，就可以找到“典型”用户。所谓的典型用户就是属于用户群分类，比较有典型代表的用户描述。对于典型用户的描述可以比用户群更为精确。比如年龄可以精确到年，计算机使用经验可以描述为熟悉windows基本操作(点击、键盘、托拽、鼠标右键)等等。典型用户可以为前期的软件交互定性测试和定量测试以及软件开发后期的确认测试提供样本。
有了用户群描述，就可以进行一些交互挖掘。比如：问卷、投票、采访、直接用户观察等。通过对目标用户群的交互挖掘，可以比较宽泛的了解目标用户对于我们正在开发的软件的交互要求和理解。
这个时期的交互挖掘往往会伴随着软件功能的调查、软件定位的调查一起。因此不会很明确的体现用户对于我们软件的交互要求。
当找到典型用户的时候，我们一般采用三种方式来挖掘用户对软件交互的需求：焦点小组、场景测试和专家小组。
焦点小组一般有如下的组成方式：
中立主持人一名、典型用户5-7名、记录员一名。另外需要准备白板、投影仪、摄像机、文件夹等设备。
焦点小组可以从两个方式进行。一个是对比方式，一个是单一式。
对比方式就是把具有相同功能或者类似功能的多个软件交互模式放在一起，通过投影、讲解、演示等手段，让参与的用户对其进行评价和提出意见和建议。
单一式就是针对一个软件的几个重点功能（一般来说不会是全部功能）的交互方式同参与的用户进行交流。
（二）、如何辨识和使用交互元素。
下面分别就：交互场景、交互对象、交互方法和交互事件分别进行讨论。
我们常把交互场景分为嵌入式、PC和服务器三种。嵌入式主要指使用小型液晶显示输出的设备，PC机主要指带有CRT、键盘、鼠标的个人计算机。服务器在多数情况下和PC机的交互设备差不多，但是用户的专业性要求方面往往有很大差距。
我们主要针对PC机进行讨论。在国内PC机的主要操作系统就是windows，因此以windows为基准讨论交互对象。
Windows下常用交互对象包括：
1、 信息显示对象
2、 命令响应对象
3、 输入选择对象
4、 范围限定对象
5、 表格对象
6、 系统对象
信息显示对象有：标签、动画、即时提示、状态栏提示、进度条。
名称 演示
标签
动画
即时提示
状态栏提示
进度条
信息显示对象主要用于软件向使用者提供反馈信息。
命令响应对象有：按钮、菜单、分割条、超连接文本
名称 演示
按钮 常规 扁平 图形 按下 下拉 单选 多选
菜单
分隔条
超连接文本
命令响应对象主要用于响应用户的鼠标和键盘的命令。
输入选择对象有：文本输入框、微调输入框、选择框、滑动条、页面选择
名称 演示
文本输入框 单行和多行文本输入 IP地址输入
微调输入框
选择框 滚动选择 下拉选择
滑动条
页面选择
输入选择对象主要用于接收用户输入文字、选择已经设定好的选择等。
范围限定对象主要有：群组和分割线
名称 演示
群组
分割线
范围限定对象主要用于从视觉上分开相互之间有逻辑区别的一个或者多个交互对象。
表格对象外形看起来很象我们使用的表格而得名。用于显示和输入大量信息。
系统对象包括：窗口、树列表、列表、系统信息栏
名称 演示
窗口
树列表
列表
系统信息栏
在熟悉了Windows的交互元素之后，我们来看交互方式和交互事件。
交互方式有：键盘输入、鼠标滚动、鼠标点击、语音输入、笔迹输入、影像输入等。其中最常用的是前面三者。
交互事件有：视觉提示、路径选择、声音提示等。路径选择就是当程序可能有多个分支的时候，要求用户确认进入哪一个分支。
（三）、如何设计和使用交互逻辑
在前面我们已经说过交互逻辑的三种情况。对于用户的天然逻辑是首先要遵守的。这个就是所谓的人性化的问题。比如从左到右从上到下，红色表示警戒绿色表示安全，低频率表示正常高频率表示非常等等。
如果违反了用户的自然逻辑，可以通过前期的用户焦点小组和后期的用户测试检测出来。
如果考虑到我们所处交互环境的特点-PC机、windows操作系统，那么还要注意的就是同Windows的操作习惯相配合。比如在中文windows下，按钮的快捷键是在按钮文字的后面，而英文版是在前面。
首先要注意的就是键盘的逻辑。在Windows下的软件交互除非是不和其他任何应用一起运行，否则就要注意键盘的逻辑要按照windows下规范进行。请参考附录(一)中windows键盘定义。
其次就是要注意鼠标的逻辑。现在windows下的鼠标基本都是双键的，中间带有滑动轮的也不在少数。对于单击、右键单击、双击的定义要和windows的当前设置相同，否则会给用户带来困惑。
各个交互元素之间的逻辑，难以条条块块的讲清楚。这里介绍一下几个交互设计的原则，然后给出一些在交互设计中行之有效的方法。
交互设计原则：
1、 以用户为中心的原则
2、 交互一致性原则
3、 简单可用原则
以用户为中心的原则不需多言：按照用户习惯的方式设计交互、提示和引导用户而不是教育用户、以用户的满意度为基本衡量标准。
交互一致性的原则包含下面几个内容：
设计目标一致。如果追求操作简单，那么就要贯彻始终。
外观一致。如果追求视觉效果华丽，那么就尽量避免出现朴素的效果。
行为一致。交互对象在相同的交互方法后产生的交互事件保持一致。
简单可用原则包含下面的几个内容：
简化界面元素。能够分类的就分类，能够隐藏的就隐藏。保持界面控制区域不多于40%，
简化逻辑概念。Windows下流行的向导窗口就是一个很好的例子。
从而使得交互更容易理解更容易控制。
如果大而言之，交互设计中只有一种方法，那就是简化。这一点往往是软件开发者和使用者之间的最大分歧。程序开发者往往由于全盘了解软件的功能和架构，更加倾向于快捷和从开发角度看的合理性和逻辑性。
那么如何进行简化呢？
刚才说了，交互设计根本的方法是简化。因为这个方法太过模糊，我们现在把简化作为我们的目标，而用面向对象的方法来对交互进行设计。
面对对象的方法在软件编制中应用已经很久了，对象-也就是所谓的物体(object)，天然和我们周围的生存环境一致。同时由于我们的交互设计往往使用现有的控件或者是控件的变形体，因此，使用面向对象的方法进行交互设计是从感情和理智上都比较可行的方法。
但是，交互设计里面的对象和程序设计里面的不会完全相同。比如我们不会注重程序设计里面那么多的细节问题：比如它是从那个对象派生下来的。
下面就是我们设计对象的分类图：
首先，我们要声明的是：为了兼容多种交互元素，我们的基本对象、可视对象、交互对象、UI对象之间并不是包含的关系。也就是说，一个交互对象，不一定是一个可视对象。他们存在如下关系：
a、 可视对象、交互对象、UI对象都是基本对象
b、 UI对象都是可视对象
c、 UI对象都是交互对象
下面我们分别解说四种交互对象。
基本对象中的名称用于标示不同的交互对象。(实际上为了我们后面的交互衡量方便，我们还提供了ID作为数据库索引。但是这个ID其实是附加的，不是基本对象必须的属性)。类别用于标示该基本对象的类别。该类别是我们刚才说的交互对象中的某一种。
可视对象包含了更多的属性：位置信息包含了该交户对象的左右上下的值(比如在windows里面就是像素)。状态包括该对象是否可用(Enabled)是否可见(visible)等等。（比如按钮的三态、超连接的4态）
交互对象最重要的标志就是可以响应事件。比如鼠标事件、键盘事件等常见的。还有自定义事件(熟悉编程的人会联想到自定义消息)。交互对象可以通过交互事件的响应接受用户的命令和反馈命令。
我们把UI对象和交互对象分开的原因在于，交互对象不需要关心UI对象所关心的一些属性，比如颜色、字体、形状之类的(当然也不能说完全不关心，不过这里为了更加着重的表明交互设计中最重要的不是类似颜色、字体之类的元素，故意如此)。
扩展信息包括很多内容。比如多媒体按钮的图片、动画和声音；标签的文字等等。
在我们冲向简化这个目标之前，我们先来学习如何用对象方法来表示几个常见的交互元素。
在讨论完这4个问题之后，我们来谈谈下面的问题：
1、 交互和项目立项的关系
2、 交互和软件需求的关系
3、 交互和美术设计的关系
4、 交互和软件设计以及编码的关系
5、 交互和软件测试的关系
现在很多人认为UI设计的输入是软件需求规格说明书。因此，在软件项目推出软件需求规格说明书之前，他们是乐得逍遥自在的。而交互设计是UI设计的一个组成部分，所以更加会等到需求规格说明书推出之后了。
从实际情况看，无论对于UI设计-这里我们局限于其中的交互设计-本身，还是对于使用我们交互设计的项目来说，等待软件需求规格说明书都是一个不明智的选择。
首先，我们可以看到在软件需求规格说明书中往往包含了对目标用户的描述。可惜，这个描述往往模糊不清，无法给交互设计带来明确的指导。尤其要指出的是，在软件规格说明书中，没有谁会把目标用户按照交互设计的要求进行分组和描述。
最好的情况就是，在项目立项之前，交互设计人员就能参与项目。从交互设计和UI设计的角度，对目标用户进行分析。特别是用户使用经验和操作要求，这一点再详细的需求规格说明书也不会明确的。
其次，我们都可以明白，需求规格说明书往往是功能的说明，对于非功能性说明中用户对于软件使用的说明一般埋没在其他说明之中。而实际软件使用中，用户第一个感受到的就是这个软件的交互性。稍有经验的用户往往会提出交互方面的要求，比如：我希望这个功能最醒目或者最好能很快找到这个功能。
也许有的需求规格说明书会写出用户这些要求。但是我见过的需求规格说明书作者最好的处理也不过是把用户这些要求发个邮件给UI设计部门的人，从此万事大吉。因此，交互设计人员和项目规划人员一起工作，对用户需求进行调研，建立UI设计文档，是非常必要的。(这里补充一句：需求规格说明书可以说是把用户的需求转换为软件设计人员能够理解的语言。那么UI设计文档就是把用户的交互和UI需求转换为软件设计人员、开发人员和UI设计人员能懂的语言)
俗话说：千里之行半九百。也有俗话说：好的开始，就是成功的一半。当软件项目立项，这可以算是一个开始。还远远算不上是好的开始。这仅仅表明我们发现了一个机会。但是这个机会是什么，我们能不能抓住还需要对此进行分析。
现在我们的需求规格说明书就是来做这个事情的。需求规格说明书(一般分为用户需求规格说明书和业务规格说明书。现在，我们希望增加UI设计用户需求规格说明书)不会一步到位。
事实上，构建软件的人没有构建大楼的人那么幸运。构建大楼的人一旦建立好底层框架，就少有人要求他重打地基再次来过。构建软件的人往往要冒着在最后一分钟客户修改重大需求的风险。
因此，我们的需求规格说明书现在还是一个靶子。我们的UI设计用户需求规格说明书同样也是如此。我们的设计说明书起码需要明确下面的东西：
(一) 我们的用户特点和经验
(二) 我们用户的交互需求描述
(三) 我们用户的视觉需求描述
(四) 我们软件产品的定位和特点
(五) 用户推崇和厌恶的产品介绍
如果在此之前曾经有过各种UI演示作品，也可以附在说明书中，并且标明用户的意见。
如果在此之前对用户进行了测验，需要把测验过程(简单)、测验结果作为附件。
如果在这个时候能够和软件结构设计人员进行沟通、和开发人员进行沟通，那么就可以预置一些UI设计限制(比如我们的开发人员可能不会使用动态方法生成Flash)
然后还要像正规的需求规格说明书那样，为我们的文档标注版本和修改历史。
下面讨论一下交互和美术的关系。这个问题还真的不容易讨论清楚。这里只是说一下个人的见解。
长期以来，交互设计被隐藏在程序员的背后。美术人员只需要做出灿烂的画面，至于这些画面是否能够成功指引用户，那就成了程序员的任务。而程序员又是被我们大家默认为除了计算机连自己老婆(老公)也不懂的人。他们总被认为是沉默而富有戏剧性的异族，被描述为面色苍白、经常熬夜、超强的逻辑性、熟悉计算机甚于熟悉自己的人(听起来很类似吸血鬼)。
如果程序员真的都是这些人，那么很明显，由这些人设计的交互-如果他们曾经真心希望自己使用自己软件的话-其结果不容乐观。
然后，又有观点认为大部分用户都不是专业计算机人员，因此应该让非计算机开发人士来设计交互(这句算是说对了)。很明显，在一个项目体制内，非计算机开发专业人士就轮到了美术设计人员头上(我很奇怪为什么没有人考虑项目外的人)。而且很多人从UI这个词本身就推算出，交互设计不过是UI设计的一部分。因此由美术人员来进行交互设计再合适不过了。
可怜的美术人员不但要考虑界面美观，还要应付开发者无法实现的责难，现在突然成了软件交互设计的主导。其原因不过是原来的开发者无法应付这个任务！本来他们面对的不过是一个画面，现在这个画面每个部分都会产生不同的结果。而且自己还要设计这种结果。
争论了半天似乎忘记了做软件不是给自己用的。把用户丢在一旁。
如果没有一个即懂软件设计和开发，又明白色彩和图形的设计，还能够倾听用户意见的人的话，我看还不如这样：
从开发人员和美术设计人员以及黑盒测试人员中各抽取部分，组成“用户使用习惯调研小组”，该调研小组的作用就是从项目起始，就跟进用户使用调研，转换个人工作角色-从对项目负责到对用户负责。从中培养：
可以进行用户测试的人
可以分析整理用户交互需求的人
可以对交互设计进行设计和测试的人
好了，现在终于可以谈谈交互设计和软件编码之间的关系了。这个问题也常常听人说起。
不能不说开发者往往受到一定的局限，而且这个局限有的时候看起来很有道理。比如我们这次进行的一个项目，交互方式打破了原有windows控件的常规，很多开发人员看到就大摇脑袋，根本不会再考虑是否易用。
但是交互设计的时候，一定要考虑到开发者确实是受到平台的各种限制。如果不采用标准的控件，开发者的开发量就可能指数上升。可以说一个稍微复杂的交互部分如果无法从现有交互控件中获得支持，那么对于绝大部分项目来说就是一个无法完成的任务。
也就是说，虽然软件可以做到任何事情-不论是否如你所愿-但是对于有时间和人员限制的项目来说，无法完全做到。
当然，不能忽视的另外一个问题就是，在真正的开发项目中，开发者往往夸大或者虚拟面临的困难。因此交互设计者一定要有足够的心理准备。这也是上面为什么要开发者参与用户使用习惯调研小组的原因-他可以提供技术支持。
下图列出了针对一个项目的沟通关系。
最后，我们来看一下，交互设计和测试之间的关系。
现在很多项目都已经开始将测试提前了。一旦需求规格说明书确定，那么随之对应的功能确认测试就开始设计了。到目前为止，我们预想或者已经撰写的UI设计用户需求规格说明书还没有和测试相对应。相呼应的是，很多测试人员会在测试过程中对软件使用提出意见和建议。
如果软件开发团队，没有认识到交互设计对于最终用户的重要性，也就是说对产品的重要性的话(国内很多软件开发者依靠关系活着)，那么针对交互设计的测试就永远提不到日程上。
反过来，我们也可以看到，如果交互设计的问题，在项目进入测试阶段再进行修正，那么会带来很多问题。
首先，绝大多数软件项目团队认可下面的定语：功能必须要实现，如果实现难度高，就简单实现。这里面的简单往往意味着原来的交互设计被废弃掉了。由于有这个思想，因此交互的问题往往不受到修改bug者的重视。很多人宁可在软件上堆积一堆没有用的功能，也不愿意减少几个不重要的功能而让用户更好的使用。
其次，软件交互的问题用户感受是非常重要的衡量因素。这个用户往往不是测试人员能够代表的。衡量因素里面重要组成部分是用户的主观感受。我们的目标用户往往不是测试人员。(这里一定要注意开发团队内领导者的意见，如果没有绝对的把握，不要忽视他们可能的反对声音)，因此需要独立于测试人员进行用户感受测试。
最后，在软件使用效率测试上，测试人员往往可以大发神威。我们在上个例子中使用了一个简单的工具来测试关键任务的实现效率。测试人员利用这个工具和自动化测试工具可以快速进行上百组的测试并且提供相应的数据。
很多人评价ｉｔ方面的书是不是好的时候往往用可行性来权衡。这也是很多ＸＸ日通书籍的卖点。既然本文叫做交互设计７日通，似乎不这么来一下，说不过去。耽误了大家的时间。
我们把软件项目分类为三种。这三种项目按照风险程度高低划分。
第一种风险程度最低，也就是所谓熟领域项目或者升级项目。比如小型办公室的MIS系统，或者在原有项目上20%以内工作量的升级项目。
第二种风险程度居中。也就说熟领域高复杂度。比如一家从事制造业领域多年财务管理系统软件开发的公司为某家大型企业定做财务软件系统。
第三种风险程度最高。也就是说生疏领域项目。比如一家长期开发多媒体演示软件的公司突然要开发一个实时控制项目。
从这三种分类中可以看到，第一种项目技术成熟，工作量基本可控。第二种项目技术成熟，工作量较难估计。因此交互设计人员可以在这两种项目中，更多更好地参与。第三种项目风险性很大，是否能够完成功能要求都不一定，交互设计就成为退而求其次的东西。这个时候，交互人员可以安慰自己说：好东西总是从二代开始的。
以前我们曾经说过，交互设计人员一定要从项目预备立项就参与到项目中来．项目准备阶段可以分为目标明确和目标不明确两种情况．交互人员在项目目标不明确的情况下，参与的作用不大．这个时候市场人员、高级管理人员也处于寻找机会阶段。
一旦目标基本明确，可以初步确立用户范围。交互人员就可以开始前期工作了。
需要明确下面的问题：
１、我们的项目目标是什么？
２、我们的项目特色是什么？
３、我们的项目用户群是什么？
４、我们的项目成本是多少？
下面提供一个比较完整的交互人员项目立项前流程。可以根据项目情况，进行动态的裁减。
１、明确项目的用户群特征
通过和相关部门－例如市场、规划－的沟通，初步明确用户群的特征。一般消费产品对于用户个性化信息需要加以明确。而企业级应用则需要详细描述不同用户角色的特点。
２、进行项目特色调查
根据项目确立要实现的目标和暂定的特色，通过网络、邮件、电话、调查公司等方式对项目特色进行调查。以协助确定交互设计的着重点。调查问卷可以是如下问题：
您平时要是否感到ｘｘｘ的ｘｘｘ需要改进？
如果认为ｘｘｘ需要改进，那么请您从下面的选择中选出ｘ项您认为最需要修改的地方
如果您对此有更多建议请填写在此处
您对ｘｘｘ的更多期望是什么
您认为ｘｘｘ和ｘｘｘ能否满足您对ｘｘｘ的需求？
问题尽量明确，单一。
３、对项目的目标和特色进行调研
我们上面介绍了用户焦点小组的方式。下面我们详细叙述一下对于项目立项前的用户焦点小组的组织流程。
１、通过代理公司或者其他关系寻找目标范围内的用户
这里要注意剔除竞争对手和同本公司有直接商业关系的用户。他们往往会影响焦点小组的讨论方向，甚至泄密。
２、选定用户，和用户确认会议召开时间。
焦点小组一般要６－８个用户参加，因此我们可以通知８个用户，和他们确定焦点小组会议的时间，请他们按时参加。并请他们留下联系地址和方式。可以事先提示参加会得到答谢礼品，这次会议的目的。通过会前的短暂接触留下对每个可能参加用户的初步印象。
３、布置一间环境较为宽松的会议室。
灯光要明亮不刺眼，整体颜色格调要有暖色，可以布置花草等静物装饰。可以在用户到齐之前低音播放舒缓的音乐。
４、准备焦点小组可能用的道具。
比如圆珠笔、写字板、不干胶贴。最好为每个用户增加人名牌，用于标示该用户姓名。如果需要架设相机和摄像机，那么最好不要用布之类的蒙上。幻灯机、笔记本、话筒、录音机也是必要的。如果这些道具可能会造成屋内拥挤，那么最好考虑减少设备或者换一间较大的会议室。一般来说一个人活动范围为２－４平方米会比较舒适。
准备用户情况登记表格和用户同意使用会议内容、文字、语音、视频资料的权利说明书以及保密协议。
准备起码两种饮料和水果。饮料最好没有酒精成分。准备讨论内容的大致说明文件。
５、焦点小组配备人员。
主持人负责介绍会议目的，引导用户发言，记录用户重要发言。如果有了视频、音频记录，那么主持人适时地记录用户发言内容，也会让用户有成就感。
记录员则记录自己认为重要的用户发言，以及那些在会议过程中自己注意到的现象。协助用户填写用户情况登记表、内容权利说明书和保密协议。
一旦有用户迟到或者无法赶来，主持人要根据实际情况组织或者推迟会议。处理好用户的界面。
６、焦点小组讨论过程
会议开始的时候，主持人要简要介绍一下会议的目的，设备的作用，自己和记录员。下面可以让用户相互介绍活跃气氛。
对于讨论的议题，可以通过打印文档、白板等方式，让用户填写。讨论过程中，最好有一个可以让用户动手参与的地方，比如用户把不同颜色的不干胶纸贴到白板上自己认可的选择旁边。
会后要收集用户填写的文档。并请用户签字。
７、焦点小组礼品的发放
会议结束的时候，主持人可以适时的发放礼品。对于表现特别积极的可以发放特别的礼品表示鼓励。
８、焦点小组讨论内容的整理
通过对视频、文字的整理，可以归纳出参与小组讨论的用户对于项目目标和特色的建议和意见。
对于焦点小组的结论，我的建议是科学采用。比如焦点小组结论是大家都喜欢深灰色和深蓝色的组合。那么我们可以考虑优先采用这两种组合作为界面设计的基础色。但是并不能因此就否定其它颜色的组合。
项目立项之后，交互设计人员可以和需求人员同期推出ｕｉ需求规格说明书。这个说明书可以是如下结构：
１、项目的名称
２、项目的目标
３、项目的用户群描述
４、项目的特色
５、项目的交互需求描述大纲
６、项目美术设计需求描述大纲
其中，５和６部分是总体描述交互需求和美术设计需求。前者具体内容可以在用户需求规格说明书版本确立之后，在交互设计说明书中进行细化；后者可以在ｕｉ方案说明书中进行细化。
这份文档需要客户签字，以确保效力。
交互设计说明书。
交互设计说明书用于明确软件整体交互方式和细节问题。交互设计说明书需要遵从ｕｉ需求规格说明书和用户需求规格说明书两份文档。它一般包括下面的部分：
１、版本和更改纪录
２、交互总则。
对于大部分按照windows标准进行开发的项目，只需要介绍一下和windows不同的交互方式就可以了。而对于和普通windows交互方式差别很大的交互设计，就需要明确每个交互动作后，使用到的不同交互元素如何响应。
３、整体结构图
如果交互设计人员不能明确各个功能块在交互中的体现，那么让程序开发者如何遵照实现呢？
４、按照功能块划分的模块交互图
这其中包含了不断细化的对各个交互区域的交互设计。包括控件类型、表现文字、位置、层次等信息。
如果是多人参加的项目，这种不断细化和细化的确认可以保证大家最终对软件交互的理解一致。
由于很多交互和ui效果向关系，如果没有ui效果图会影响程序开发者对交互的理解，那么就需要附上相应的效果图。
5、键盘快捷键定义表。
6、使用到的控件响应标准事件定义表(鼠标、键盘等)
交互文字对照表
对于含有大量文字或者开发多种语言版本的交互设计说明书，需要将说明文字部分独立出来，撰写交互文字对照表文档。这样可以方便开发者的程序开发和多版本语言资源的修改。同时也可以避免出现文字错误。
如果这时已经有了ui方案说明书，那么这里最好能够明确字体和大小。
这些文档写完了之后，会依照程序变化、需求变化进行修正。一旦有了要进行修正，就需要对修正可能引起的工作量以及修正本身有所评估。一旦进行了修正，就需要通知相关人员全体。
我个人的感觉是写这些文档不算累，修正起来就比较繁琐和劳累了。因此最好能够同项目组协同，定义一个修正计划。