协同活动的核心是有许多逻辑关系要求某些部件（即某些活动）按照多种可能顺序中的某种特定顺序装配在一起，设计过程从三个活动开始，目的是建立系统需求的本质特性，
协作需求对话”是开发人员和用户或客户之间，为建立所开发系统的需求而进行的一场特殊对话或谈判。在这三个活动以及以使用为中心设计过程中，“任务建模”居于核心位置。
这项活动的目的是为角色和任务模型所支持的工作，开发一个清晰完整的描述。任务建模与另一个设计开发活动“领域建模”相互作用，“操作背景化”和“标准和风格定义”是两个有些复杂和特殊的活动，
它们紧随“协作需求对话”活动之后，与其他所有建模和设计活动并行执行。因为软件开发的最终目标是得到一个可用的工作系统，所以设计和改进活动必须最终导致对工作系统的建造和测试。
并行和迭代的“集中建造”活动和“体系结构迭代”活动组成了以使用为中心开发的实现阶段。“集中建造”是在基本用例模型指导下逐层开发工作系统的过程。
而“体系结构迭代”则是在把后续各个层次逐个增加到系统的过程中一种用来维护良好的内部软件体系结构的方法。我认为，在还不清楚要做什么或需要对什么进行标准化的时候，
就试图对什么东西制定标准，是不合逻辑的。应当从对工作和设计需求的理解出发来遵循适当的标准和风格指南。当然在实践中，一些标准和风格定义可能在某个项目开始之前就已经存在了。
“标准和风格定义”是一项并行活动，它对从“协作需求对话”到“可用性检查”这些其他活动提供输入，同时也从这些活动接受输入。用户界面标准和风格指南必须持续地对设计施加影响，
但同时也必须根据建模和设计活动的结果对其自身进行评审和修改。用户在以使用为中心的设计中起着重要作用，用户或用户代表参与这个过程的若干活动，如“协作需求对话”、“领域建模”、
“任务建模”、“标准和风格定义”以及“可用性检查”。这些活动可以采取混合的方式，或者让用户和开发人员一起工作，或者让用户对开发人员的工作进行评审并提供反馈意见。
因此，虽说软件主要是根据用户的需求来研发，但这个过程应当是用户参与，而不是以用户为中心。简单来说，协同活动就是致力于软件可用性的一组活动，将这些活动以不同的方式加以组装，
收集用户需求，调整开发战略来构成从概念到成品软件的一条路径。不能像以前一样自己闷头敲代码，哪怕自己作为用户去使用一下，也能发现更多问题并进行优化，
当然寻找更多用户进行沟通也是必要的。