1、 交互和项目立项的关系
2、 交互和软件需求的关系
3、 交互和美术设计的关系
4、 交互和软件设计以及编码的关系
5、 交互和软件测试的关系
现在很多人认为UI设计的输入是软件需求规格说明书。因此，在软件项目推出软件需求规格说明书之前，他们是乐得逍遥自在的。而交互设计是UI设计的一个组成部分，所以更加会等到需求规格说明书推出之后了。
交互和项目立项的关系
从实际情况看，无论对于UI设计-这里我们局限于其中的交互设计-本身，还是对于使用我们交互设计的项目来说，等待软件需求规格说明书都是一个不明智的选择。
首先，我们可以看到在软件需求规格说明书中往往包含了对目标用户的描述。可惜，这个描述往往模糊不清，无法给交互设计带来明确的指导。尤其要指出的是，在软件规格说明书中，没有谁会把目标用户按照交互设计的要求进行分组和描述。
最好的情况就是，在项目立项之前，交互设计人员就能参与项目。从交互设计和UI设计的角度，对目标用户进行分析。特别是用户使用经验和操作要求，这一点再详细的需求规格说明书也不会明确的。
交互和软件需求的关系
其次，我们都可以明白，需求规格说明书往往是功能的说明，对于非功能性说明中用户对于软件使用的说明一般埋没在其他说明之中。而实际软件使用中，用户第一个感受到的就是这个软件的交互性。稍有经验的用户往往会提出交互方面的要求，比如：我希望这个功能最醒目或者最好能很快找到这个功能。
也许有的需求规格说明书会写出用户这些要求。但是我见过的需求规格说明书作者最好的处理也不过是把用户这些要求发个邮件给UI设计部门的人，从此万事大吉。因此，交互设计人员和项目规划人员一起工作，对用户需求进行调研，建立UI设计文档，是非常必要的。(这里补充一句：需求规格说明书可以说是把用户的需求转换为软件设计人员能够理解的语言。那么UI设计文档就是把用户的交互和UI需求转换为软件设计人员、开发人员和UI设计人员能懂的语言)
俗话说：千里之行半九百。也有俗话说：好的开始，就是成功的一半。当软件项目立项，这可以算是一个开始。还远远算不上是好的开始。这仅仅表明我们发现了一个机会。但是这个机会是什么，我们能不能抓住还需要对此进行分析。
现在我们的需求规格说明书就是来做这个事情的。需求规格说明书(一般分为用户需求规格说明书和业务规格说明书。现在，我们希望增加UI设计用户需求规格说明书)不会一步到位。
事实上，构建软件的人没有构建大楼的人那么幸运。构建大楼的人一旦建立好底层框架，就少有人要求他重打地基再次来过。构建软件的人往往要冒着在最后一分钟客户修改重大需求的风险。
因此，我们的需求规格说明书现在还是一个靶子。我们的UI设计用户需求规格说明书同样也是如此。我们的设计说明书起码需要明确下面的东西：
(一) 我们的用户特点和经验
(二) 我们用户的交互需求描述
(三) 我们用户的视觉需求描述
(四) 我们软件产品的定位和特点
(五) 用户推崇和厌恶的产品介绍
如果在此之前曾经有过各种UI演示作品，也可以附在说明书中，并且标明用户的意见。
如果在此之前对用户进行了测验，需要把测验过程(简单)、测验结果作为附件。
如果在这个时候能够和软件结构设计人员进行沟通、和开发人员进行沟通，那么就可以预置一些UI设计限制(比如我们的开发人员可能不会使用动态方法生成Flash)
然后还要像正规的需求规格说明书那样，为我们的文档标注版本和修改历史。
交互和美术的关系。
长期以来，交互设计被隐藏在程序员的背后。美术人员只需要做出灿烂的画面，至于这些画面是否能够成功指引用户，那就成了程序员的任务。而程序员又是被我们大家默认为除了计算机连自己老婆(老公)也不懂的人。他们总被认为是沉默而富有戏剧性的异族，被描述为面色苍白、经常熬夜、超强的逻辑性、熟悉计算机甚于熟悉自己的人(听起来很类似吸血鬼)。
如果程序员真的都是这些人，那么很明显，由这些人设计的交互-如果他们曾经真心希望自己使用自己软件的话-其结果不容乐观。
然后，又有观点认为大部分用户都不是专业计算机人员，因此应该让非计算机开发人士来设计交互(这句算是说对了)。很明显，在一个项目体制内，非计算机开发专业人士就轮到了美术设计人员头上(我很奇怪为什么没有人考虑项目外的人)。而且很多人从UI这个词本身就推算出，交互设计不过是UI设计的一部分。因此由美术人员来进行交互设计再合适不过了。
可怜的美术人员不但要考虑界面美观，还要应付开发者无法实现的责难，现在突然成了软件交互设计的主导。其原因不过是原来的开发者无法应付这个任务！本来他们面对的不过是一个画面，现在这个画面每个部分都会产生不同的结果。而且自己还要设计这种结果。
争论了半天似乎忘记了做软件不是给自己用的。把用户丢在一旁。
如果没有一个即懂软件设计和开发，又明白色彩和图形的设计，还能够倾听用户意见的人的话，我看还不如这样：
从开发人员和美术设计人员以及黑盒测试人员中各抽取部分，组成“用户使用习惯调研小组”，该调研小组的作用就是从项目起始，就跟进用户使用调研，转换个人工作角色-从对项目负责到对用户负责。从中培养：
可以进行用户测试的人
可以分析整理用户交互需求的人
可以对交互设计进行设计和测试的人
交互设计和软件编码之间的关系。
不能不说开发者往往受到一定的局限，而且这个局限有的时候看起来很有道理。比如我们这次进行的一个项目，交互方式打破了原有windows控件的常规，很多开发人员看到就大摇脑袋，根本不会再考虑是否易用。
但是交互设计的时候，一定要考虑到开发者确实是受到平台的各种限制。如果不采用标准的控件，开发者的开发量就可能指数上升。可以说一个稍微复杂的交互部分如果无法从现有交互控件中获得支持，那么对于绝大部分项目来说就是一个无法完成的任务。
也就是说，虽然软件可以做到任何事情-不论是否如你所愿-但是对于有时间和人员限制的项目来说，无法完全做到。
当然，不能忽视的另外一个问题就是，在真正的开发项目中，开发者往往夸大或者虚拟面临的困难。因此交互设计者一定要有足够的心理准备。这也是上面为什么要开发者参与用户使用习惯调研小组的原因-他可以提供技术支持。
交互设计和测试之间的关系。
现在很多项目都已经开始将测试提前了。一旦需求规格说明书确定，那么随之对应的功能确认测试就开始设计了。到目前为止，我们预想或者已经撰写的UI设计用户需求规格说明书还没有和测试相对应。相呼应的是，很多测试人员会在测试过程中对软件使用提出意见和建议。
如果软件开发团队，没有认识到交互设计对于最终用户的重要性，也就是说对产品的重要性的话(国内很多软件开发者依靠关系活着)，那么针对交互设计的测试就永远提不到日程上。
反过来，我们也可以看到，如果交互设计的问题，在项目进入测试阶段再进行修正，那么会带来很多问题。
首先，绝大多数软件项目团队认可下面的定语：功能必须要实现，如果实现难度高，就简单实现。这里面的简单往往意味着原来的交互设计被废弃掉了。由于有这个思想，因此交互的问题往往不受到修改bug者的重视。很多人宁可在软件上堆积一堆没有用的功能，也不愿意减少几个不重要的功能而让用户更好的使用。
其次，软件交互的问题用户感受是非常重要的衡量因素。这个用户往往不是测试人员能够代表的。衡量因素里面重要组成部分是用户的主观感受。我们的目标用户往往不是测试人员。(这里一定要注意开发团队内领导者的意见，如果没有绝对的把握，不要忽视他们可能的反对声音)，因此需要独立于测试人员进行用户感受测试。
最后，在软件使用效率测试上，测试人员往往可以大发神威。我们在上个例子中使用了一个简单的工具来测试关键任务的实现效率。测试人员利用这个工具和自动化测试工具可以快速进行上百组的测试并且提供相应的数据。
