项目要经历三个阶段，如图2-4所示。在第一个阶段，我们有意将开发流程与ucd流程分开进行。解决方案管理团队负责通过外部驱动研究方法定义目标解决方案，与此同时，开发团队并行开发技术平台。从一开始，bydesign用户体验团队就同时协助解决方案管理团队和负责开发技术平台的ui架构团队。用户体验设计师与解决方案经理紧密合作，一起定义应用程序的目标设计。同时，我们也必须确保在ui架构中能完美地实现出ui模式，撰写详尽的ui规范文档，并在开发阶段协助框架开发人员。在第二阶段，我们得让已实现的解决方案更接近目标设计。等到了第三阶段，我们就开始转入精益开发（lean）与敏捷开发（agile development）模式。刚开始时，我们并没有明确地区分每个阶段。但随着经验的积累，情况逐渐清晰起来。每个阶段我们都学到许多技术、流程和全球性组织管理的经验，而且团队在这些方面的表现也大大提升了。
尽管当时没有现成的技术，我们也必须开始设计。我们的目标是打入新市场，吸引新客户群。解决方案经理和用户体验设计师的首要目标是解读市场需求和用户需求。他们为新解决方案提供目标设计。
他们设计了上千个界面，用html制作可点击的原型，这些原型在外观和使用感上与真正的应用程序相差无几，但这一过程并不需要写代码。然后我们让上千名分布在世界各地的用户验证这些界面，通过不断迭代改进解决方案。我们还与管理团队、执行董事们花了好几天一起检查html原型的界面。虽然这一过程比较耗费时间，但是相比等到商业目标确定以及框架编程也完成后才开始测试的代价要小得多。我们从中得出一个经验：一个html原型胜过千言万语。因为这是一种所有开发人员、解决方案经理、董事会成员、经理以及来自各种文化背景的人都能理解的语言。
我们希望产品能吸引那些以前不用sap产品的新客户、新用户，而不是仅仅利用现有的sap客户群。因此，我们必须建立自己的基础设施，接触那些还没使用sap产品的用户。我们通过市场研究公司找到符合要求的用户，并借助外部的可用性实验室开展用户活动。
合理性测试（the sanity check）
在这个阶段设计ui原型是个难题。在设计用来描述目标设计的ui设计风格指南时，需要假设许多技术的可行性。然而，随着项目的进展，我们有些技术并没有足够的时间去实现。我们必须一次次地更新ui设计风格指南，不断提高它与技术框架的一致性。在这种情况下，让参与项目的每个人都及时了解最新变化又成了另一大难题。为此我们建立了一个维基站点提供最新信息并定期开展信息交流会。解决方案经理和ux设计师在将ui原型移交应用程序开发人员之前必须根据这些变化做出相应调整。我们希望ui原型能呈现出最好的品质，它必须尽可能精准地呈现出我们最后想要的效果。为了确保ui 原型能够与设计风格指南保持一致，我们决定在开发流程中添加一道“合理性测试”门槛。
在解决方案经理和ux设计师将ui原型移交给开发部门之前，原型要先经过我和sap的用户体验部门高级副总裁丹罗森伯格（dan rosenberg），也是用户体验方面的专家，召开正式审核会议来决定。我们对设计风格指南了然于心而且也熟悉大部分技术细节。在这一阶段进行质量测试至关重要。合理性测试是必须通过的一道门槛。它强调了ui设计风格保持一致的重要性。在合理性测试阶段，我们将不同的ui原型标记为“红灯”“黄灯”“绿灯”三个状态。“绿灯”代表ui原型与设计风格指南一致，开发部门可以开始开发。“黄灯”表明ui原型在移交开发部门之前还需要做些细节上的改动。“红灯”意味着未通过，即ui原型与设计风格完全不符合，需要重新修改后再次进行合理性测试。刚开始执行、记录合理性测试的时候相当吃力。我们看了上千个界面。进行合理性测试的时候，我们不能深入到很细节的方面，而只是指出一些明显的问题。但我们的努力是值得的。我们定位问题的速度越来越快，而且随着时间的增长，ui原型合理性测试中出现的“绿灯”越来越多。
我们定期将合理性测试的总体结果汇报给管理层，这让用户体验有了更多的曝光机会。在当时的情况下，进行合理性测试是一个正确的选择，它是一个很好的工具。如今我们已经不再需要进行合理性测试了，因为得益于稳定的ui风格指南，ui原型质量已经大大提升。
基于模式的用户界面
从一开始我们就很清楚地认识到为了提高开发的一致性，我们必须将ui模式整合到开发环境中。这是正确的决定，因为大多数开发人员都不想花时间去读ui设计风格指南。
我们对企业软件的常用模式做了大量研究，从中提取出ui模式。在开始sap business bydesign项目之前，我们在另一个sap产品中就已经初次接触过ui模式。第一个产品的客户和用户使用这些ui模式时给予的反馈对提高business bydesign ui模式库的质量起到了很大的帮助作用。
ui模式是针对用户完成的某些任务而设计的。举一个ui模式的例子—目标工作列表，如图2-5所示。这个模式支持用户完成搜索商业目标、定位目标、预览数据或者开始实现目标等任务。同一个ui模式里的所有ui元素和元素间的交互方式都是预先设定好的。这样就开发人员不需要再操心这些问题。最后呈现给用户的是一个具备基本搜索与高级搜索功能的搜索区域。用户单击“搜索”按钮之后，所有的结果将出现在搜索区域下方的表格中。当用户选择了表格中的一项后，相关的商业目标细节就会出现在预览区域。
刚开始的时候，我们并不确定有多少ui应该采用基于模式的设计流程，有多少应该采用“自由风格”才能够迎合用户的需求。开始我们估计70%的ui可以套用模式，30%采用自由风格。然而当我们设计完所有的页面后，我们终于有了答案：90%的ui都套用了模式，10%采用了自由风格。但这个比例并不是一定的，因为这一结果很大程度上取决于你的模式数量以及你要搭建的应用程序的类型。例如，图2-5所示的“目标工作列表”ui模式在我们的解决方案中用到了350次。这也表明使用ui模式会带来的高回报。
另外，我们也不是很确定每个ui模式应该留给开发者多大的自由发挥的余地。如果严格限制模式，解决方案可达到高度一致，但你将无法通过优化ui让用户更好地完成任务。所以我们决定多给开发人员一些自由度。然而，在有些情况下灵活度稍微有点过头了，以至于我们不得不在项目后期花大量的时间处理细节上的一致性问题。
在第一阶段，解决方案管理部门主导产品定义。他们负责具体的需求定义。ux设计师负责用户体验设计，但整体的解决方案仍是由解决方案管理部门负责。他们负责推动将设计移交给开发部门的这一环节，并与开发部门沟通。而ux设计师需要参与到任何需要他们的环节。ux初步制度化的一个标志是：开发人员只有从解决方案管理部门拿到ui原型后才可以开始开发。
我们在第一阶段面临的挑战是在不清楚技术局限的情况下开始设计解决方案。我们在ui架构的规范文档的基础上建立了ui设计风格指南。我们在设计时抱有的预期是：一年内，在ui架构的基础上实现ui规范，并且能够及时移交给应用程序开发人员。一年后，第一版的ui架构完成，开发人员开始实现应用程序的界面。从用户体验的角度看来，第一版的sap business bydesign并不完美。因为技术平台团队与应用程序开发人员无法在有限的时间内开发出与目标原型相同的界面。我们必须在下一版本中做出改进。
引入关键绩效指标（kpi）评估产品表现
项目开始的时候，我们设定了每个版本应该达到用户体验kpi目标值并在版本末期评估产品表现。我们通过基准可用性测试评估用户使用效率，有效性和满意度。我们很清楚不可能在第一个版本就达到最终目标。我们为第一个版本设定了6分的可用性kpi目标值（总分是10分）。然而，我们选择了一些关键用例对他们进行基准可用性测试，结果显示：第一个版本的kpi只有4.8，甚至没有达到我们为第一个版本设定的目标值！我们将这一结果上报给管理层，显然我们需要增加项目投入。同时，我们也计划了改进措施以期用户体验在下一版本上有重大提升。用户体验是下一版本需要最先考虑的问题，开发人员也需要集中精力提升用户体验。
在第一阶段，我们有意将目标解决方案的设计与技术平台的开发并行进行。一方面，解决方案经理、ux设计师在设计解决方案（不断迭代），并且有最终用户参与全过程。另一方面，技术和应用程序开发人员同时在搭建新的软件架构，并开发第一版sap business bydesign。他们的表现都相当出色，但这也意味着第一个版本快发布的时候将必然存在对接问题。
因此，第二阶段的目标就是让已实现的解决方案更靠近目标设计。
“ui润饰篇”
我们开展了一个ui润饰项目，目的是根据最终用户的反馈和内部反馈，提升已实现的多个应用程序的用户体验。尽管我们已经在开发工具中融入了ui模式，但由于一开始ui模式被赋予更多的灵活度，开发人员仍可能开发出不一致的界面。公司任命开发团队的一名经验丰富的同事和我接手负责这个项目。我认为这种共同负责项目的方式很好，双方可以将开发与用户体验方面的专业技术得以结合。
我们成立了一个核心团队，团队成员来自应用程序开发部门、用户体验部门、ui架构部门和技术部门。我们让所有必要的参与方都坐到一张桌子边上，一起制定出一个各方都认可共同方案。我们待在房间里整整两天，最后终于得出了一个方案。
发现问题 ux团队负责发现并监控已实现解决方案的所有ui问题。
排列优先级 核心团队根据客户和用户的反馈一起排列问题的优先级。
解决问题 技术团队负责解决技术问题；ux团队解决ui设计风格指南的相关问题；应用程序开发团队解决应用程序相关问题。他们必须像一个团队一样合作才能解决问题。
记录 ui架构团队和ux团队负责补充ui润饰准则并传达给开发人员。
实现 应用程序开发团队负责在所有的应用程序实现ui润饰风格指南，与之保持一致。
ui问题可分为三类：技术问题、应用程序问题和ui设计风格指南问题。我们从核心团队中为每种类型的问题指定了一名相关负责人。
在完成了项目部署并全体通过了计划后，我们开始了痛苦的执行阶段。我们把所有的ui问题集中到一起，然后把它们按优先级排列，确定要优先解决的问题。
我们决定让组织和管理层都能看到其中高优先级的问题。每个月我们都会创建一份ui润饰报告，描述问题解决的具体情况。我们画了一个时间轴，标明了可以向客户发布修正版本的时间点，这是ppt里最重要的一页。另外，我们每个问题都只用一页ppt，附上图片以及一两句描述的话。为的是让执行总监迅速了解要解决的问题，这一点很重要。我们遇到的难度最大的问题是，技术团队决定要开发一种新功能后，所有的应用程序开发人员需要将这一功能潜入到他们各自程序的ui中。那时，我们已经完成了数千个页面。即使假设我们只需要在部分页面中实现这个新功能，开发每个页面只需几个小时，开发团队也得安排大量的人力和时间去修改那些受到影响的界面。不过，那些单靠技术团队就能解决的修改执行起来就容易多了。他们只需要将其加入到新版本中，而不需要其他所有应用程序开发人员做出相应调整。
我们花了不少时间解决了大多数关键问题。这一过程对技术开发人员、应用程序开发人员和ux设计师而言都十分痛苦。技术平台实现某个新功能，ui架构团队与ux团队就得马上制定出一套ui润饰准则。准则包含两个部分：ui设计风格说明以及如何实现该功能的细致的技术说明。
另外，我们还需要估计应用程序开发人员实现某个新功能的工作量，获得各个开发团队的认可，让他们参与其中。这是往往是一场资源与时间的争夺战。但bydesign管理团队十分重视改进过程，所以大多数情况下我们都能成功。每天我们都在为每一个ui问题积极争取资源。
ux团队和开发团队确立了一个共同执行方案。我们给应用程序的每个模块指定一名开发人员作为ui润饰工作的首要联系人。另外，我们也给每个模块指定了一名ux设计师。开发人员负责根据ui润饰准则的要求实现新功能；而ux设计师主要负责测试，看开发人员是否正确地实现了准则，以及在开发人员遇到问题时协助他们。尽管这样的工作对ux设计师而言相对枯燥，但是为了让产品质量达到目标，这也是必不可少的。我们建立一张庞大的excel表用于监控和追踪页面的所有ui润饰问题。开发人员根据准则将新功能实现到界面后，就会在excel表格中将状态改为“已实现”。之后ux设计师进行测试，再将状态改为“通过”或“不通过”。刚开始的时候参与的人都觉得不太适应这个新流程，但几周后就进展得越来越顺利。
我们每周都会发布一份报告，将每个应用程序模块里的ui润饰测试结果汇总。通过这个周报我们可以很清楚地看到哪些区域的进展与原计划一致，哪些不一致。它是一个很好的工具，既客观地显示了每个应用程序区域的进展又给负责不同模块的团队制造了小小的竞争。最后，我们执行并测试了上千个ui润饰问题，测试覆盖率达到了100%。这对整个组织而言都是一个巨大的成就。
通常情况下，ux设计师都不会从事这方面的工作，但我们的ux团队花费了一半的精力去完成它。然而，我们的努力是值得的！这个项目也同时让我们与开发人员的关系更近了一步。而且，人们对ux团队的信任也借此得到了提升，因为我们顺利地解决了问题，也踏踏实实地做了很多具体的工作。有时候为了达到你的目标，你得下定决心做些不一样的事。
你所在的公司并没有把ui问题摆在合适的优先级？如果这样，以下是我给的一些建议：
将这些问题披露给管理团队和组织。
为解决问题准备充足的预算与时间。
渗透—积极推动项目进度，不断让管理层看到项目的进展。
找到合适的人参与其中。
确立一个好的执行计划。
坚持到底！
“分担痛苦篇”
第二阶段开始的时候，第一版的sap business bydesign面市。我们在纽约举办了一个大型午餐会，邀请用户上台分享这个创新的解决方案是如何帮助他们改善业务的。真正的用户越来越频繁地开始使用我们的系统。我们做了很多现场观察，了解用户如何使用我们的新解决方案。大多数用户都很大方，给予了很多帮助。他们准许我们录下他们实际的操作过程。观察用户使用系统的真实情况可以帮助解决方案经理、ux设计师、知识管理部门经理以及开发人员更清楚解决方案需要改进之处。
一位在人力资源部门工作的女士负责招聘员工。她50多岁，在这一行业积累了丰富的经验。她的任务是把一名新员工的劳动合同的信息输入系统，同时还得保证效率。然而，系统却没法按照她习惯的操作方式帮助她完成工作。
当输入完员工具体信息后，她切换到下一个操作页面，需要输入合同有效期限。她看到屏幕上出现了有效期这一栏，“从”某个时间“至”某个时间有效，这两个都是必须填写的。“从”这一栏系统显示了当前时间。而“至”这一栏系统显示的是“31.12.9999”。它表示合同永远有效，她对系统给出的这个日期比较困惑，所以她把“31.12.9999”删掉了。接着她收到了一个错误提醒，说她需要输入一个日期。因为这一栏是必须填写的。她让系统的反应完全搞晕了。然后她又重新输入了正确的日期，最终顺利进入到下一个页面。这个操作花了不少时间，房间里有人为此忍不住笑了。终于，填完了下一个页面后她把所有信息都输入了系统，本以为这样就可以保存数据了。但系统只弹出了一个“错误”框，没有任何解释。她完全迷惑了，然后关掉了界面。
这时那些在看录像的人沉默了。有人说他之前压根没想到这会引起这么大的问题。也是在这一天，高级管理层再一次意识到了用户体验的重要性，有必要把它作为开发团队关注的焦点问题。两天后，系统的这一问题得到了解决，因为要解决它其实花不了多大工夫。执行了这个修正后，使用这个界面的用户，特别是那位女士，对此都十分满意。
一个图片、一段视频要胜过千言万语！人们需要了解用户是如何使用系统的，他们遇到了什么问题。然而准备这样一段视频来说明你的观点也要费很大的工夫，所以你只能选择那些重要的案例。但是通过录像人们可以感受到用户的情绪，体现了用户体验设计的价值。这是ppt上的一个列表无法传达的感染力。
“ui流程改进篇”
从一开始我们就在组织上下强制执行以用户为中心的设计。大部分事情进展得很顺利，但我们也发现一些需要改进的地方，改正后可以让整个流程更加高效。
第二阶段初期，我们成立了一个由ux设计师和解决方案经理组成的小团队，让他们分析目前流程中存在的问题并提出一些改进的建议。这么做很值得。他们发现了一些问题，主要有以下几种类型：质量关注度、用户参与、用例定义、“一个团队”路线、团队角色定位、ui验证、原型制作和ui工具。团队为每个问题提出了改进的建议，并且说明了实施这些变化的好处。
他们把这一结果展示给解决方案管理部门的高级副总裁（senior vice president，svp），他很喜欢这些提议并帮我们推动它们的实施。然后团队又把这些提议展示给开发部门的svp，也得到了他们的支持。我们决定开展试点项目，验证我们的流程改进提议。
试点项目的效果很好，ux部门以外的其他人也对以用户为中心的设计和我们的流程改进建议给予了肯定。这里我列出了一些解决方案经理和开发人员的评价。
公司决定实施以实地调研和用例为导向的解决方案定义流程，这种办法投资回报比高得让人难以置信。
“一个团队”路线能更快、更高效地产生出技术可行的设计方案。
解决方案规划图和用例让我们在项目初期就能保持对需求理解的一致，快速、高效地设计出线框图。
当时负责这块内容的执行董事也很喜欢我们的想法和方式。他让我和一位开发副总裁负责定义以后的开发流程。此后，开发流程改进成为了bydesign管理团队的主要议题，我们也得到了许多关注与支持。
让两个人（一位来自开发团队，一位拥有ux背景）共同推动开发流程是个明智的决定。为了让所有的利益相关者参与到项目中，我们确实花了一些时间。解决方案管理团队、ux团队、信息管理团队、翻译团队、开发团队、运营团队和服务部门的人都需要参与到流程设计中来。
我们从这次经历中学到的最重要的一点就是：ucd流程并不是独立于开发流程存在的。
相比于将ucd活动和产品开发流程分两套文档描述的办法，我们只有一套产品开发流程的描述文件，其中无缝整合了ucd活动和产品开发流程的相关内容。这样一个小改动有助于我们把ucd设计流程更好融入到我们的组织中。在此之前，很多人都认为ucd设计只是从事用户体验的人才需要做的事。我们都知道这种看法是错误的，但是组织中的确有很多人持有这种观点。我们将两个流程描述文件合二为一。组织中所有的人都在用相同的流程文档、模板和用例。像用例、线框图这样的ucd元素在项目中都被定为交付的必要项。大家渐渐了解用例不只是对ux团队重要，其他团队也需要通过它来了解解决方案想要达到的效果。
所有的需求（包括ui需求）都要记录下来并排列优先级。ui相关的需求要通过线框图和ui规范文档来描述。
他们是开发团队执行的基础。单个应用程序层面的ux设计师不需要再描述ui模式的具体交互模式，因为我们在ui设计风格指南里已经系统地描述过了，而且ui模式也在开发工具中体现出来。应用程序的ux设计师只需要描述和应用程序相关的那一部分ui模式，例如，表格要用哪一列、要用ui模式中的哪一个配置选项（例如在表格中预设多少行可见）。
确定了流程描述文件后，我们让所有的利益相关者都看了一遍，这花了我们一些时间。等到大家都通过后，管理团队正式通过了这一新流程并决定从下一个版本开始执行。这对我和ux团队而言是一个巨大的里程碑。我们又发挥了自己的影响力，推动组织进入下一阶段的流程。为了定义这么一个端对端的流程，我投入的精力比预期要多出许多。其中，ucd流程只是整体项目中的一小部分，为了完成项目我还得处理信息管理流程、翻译流程和运营执行流程的问题。尽管这些远远超出了ux团队的职责范围，但我觉得我们的努力是很值得的。
在第二阶段，我们更深入地将用户体验制度化了。组织上下对用户体验的认识加深了, 我们还把以用户为中心的设计流程成功地融入到整体开发流程中。此外，在ui润饰项目中的紧密合作大大拉近了ux团队与开发团队的关系。开发人员遇到ui设计相关问题的时候，他们会主动找ux设计师探讨。第二阶段接近尾声时，产品的可用性kpi值达到了6.8分（满分10）。与第一阶段末期的4.8分相比有了大大的改善。
我们在第二阶段做出的改变大大提升了流程效率，同时改善了解决方案的用户体验。第三阶段的目标是进一步改善流程，让组织运转更有效率。我们决定让整个组织向精益软件开发（lean software development）转型。我们把精益开发初期阶段的一些核心概念和scrum概念引入开发部门。我们必须找到一个更加实际的方法，调整精益软件开发让它更好地与ucd流程融合， 在利用精益软件开发的优势的同时，精心引入用户参与的环节。这需要ux从业者重新思考过去的做法，重新调整用户体验方法论，让它更顺利地融入到整体软件开发流程。
我们在第三阶段做出的最重要的改变就是“一个团队路线”（one-team approach）和“共处一室”（co-location）。当负责不同领域的团队在一个工作地点甚至在同一个房间工作时，他们的效率是最高的。与要解决的问题相关的团队成员都聚到了一块，其中包括解决方案经理、ux设计师、技术文档开发人员、开发架构师、开发人员等。这不仅给了团队更多的灵活度，也加速了决策流程。团队对问题有了共识，并且一起完成了用户研究。通过这种方式让原本来自不同背景的人有了共同语言，沟通起来就简单多了。
我们还引入了待处理需求列表，列出下一软件版本要优先解决的问题。需求列表里所有的待处理项是按重要度降序排列的。每个版本都会有一个这样的列表，这让资源分配的决策变得更透明。在资源有限的时候，特别是用户研究员和ux设计师人手有限时，大家就能轻松决定应该优先做哪个项目。团队还可根据列表的排名决定哪个议题需要大量的客户和用户验证。
引入scrum后给ux团队带来的主要挑战是它的开发周期很短。我们的开发冲刺（sprint）是两周，所以开始新设计的时间很短。同时，我们进行最终用户验证可用的时间也比以前更短了。如果我们希望将某个可用性测试的用户反馈加入到下一冲刺的待处理项目列表中，我们分析测试结果、提出改进建议的速度就必须很快。
弥补冲刺周期太短的方法是引入一个专注于需求和设计的零冲刺阶段（zero sprint）。零冲刺的周期通常是2～4个星期。这让团队成员在代码编写开始前能有一段时间规划更高层面的总体设计，但如果要进行可靠的实地调研、市场研究和用户研究，则零冲刺需要更多时间。你需要有一个足够长的产品定义阶段来进行用户研究和完成任务的高层面的总体设计。为了避免代价高昂的后期改动，总体信息架构需要在开发团队开始编码前完成。细节设计可以安排在开发前的一个冲刺或者更早，但我们也要保证设计留有一定的自由度，因为它还需要根据与开发冲刺并行的用户验证冲刺的结果做调整。
在第三阶段，我们不仅改善了开发流程，还改进了ui开发工具，以便更好地融入ui准则。
“ux规则篇”
在第2阶段的ui润饰项目中，我们花了大量的精力对已实现的用户界面进行测试和质量检查，大大改善了用户界面的质量以及它与ui准则的一致性。然而，我们为此付出了许多人力物力，这次我们想换个做法。
我们一直在想怎样才能提高组织在这方面的效率，于是就有了“ux规则”。
我们已经成功地把ui模式融入到开发工具中以保证一致性，但ui模式仍需要给开发人员留有一定的自由度。许多ui准则只是建议，我们无法将这些准则用硬编码写入开发工具。我们还给开发人员提供了ui风格指南，向他们解释什么时候要用什么ui模式，还解释了那些无法用硬编码写入ui模式的ui准则。
我们很清楚大多数开发人员都不会细看ui风格指南，有些甚至可能从来都没看过。最后我们总结出：我们必须想办法把ui准则也融入到开发工具中。如果你看了ui 风格指南，你会知道ux规则有两种：硬规则和软规则。硬规则是所有应用程序开发人员都不能违背的规则。以我们的项目为例，每个屏幕都需要有“关闭”按钮，开发人员不能省略这个按钮。软规则实施起来难度更大。举个软规则的例子，每个表格不得超出7列。没错，有时候确实存在多出几列会更合适的例外情况，但你得把它们当成例外来对待。
为了更好地说明我们是如何把ux规则融入到开发工具中的，我需要先解释下ui开发工具是如何运作的。ui开发工具是基于模式并由模式驱动的工具。开发人员开始搭建界面时必须先选择要使用的ui模式。他还需要实现业务逻辑、查询、后端服务。例如，在ui开发工具中，开发人员必须确定哪些查询是用户可用的，哪些字段要在表格中显示，哪些字段要在预览区域显示。这一过程通过配置完成，你也可以称之为ui建模（ui modeling）。界面和后端数据在逻辑上是完全分离的。开发人员要做的就是把内容排到模式中，然后把ui与后端连通。上述配置在设计阶段就完成了。ui配置和运行阶段（runtime）是分开的，这样带来了更多的灵活度，并且可以很容易就切换到另一种运行环境中，并使用另一个ui技术。ui模型存储为xml格式，因此我们可以开发一套工具去检验xml文档，查看它是否遵循了ux规则。这种办法应用在对软规则的检查中。
我们的一名开发人员开发了一个引擎，该引擎能够检测应用程序开发人员创建的ui模式（xml）是否违反了ux规则。一旦发现了违规，开发人员就会在开发工具中收到一条警告消息。他可以选择改正模式让警告消息消失，也可以点一下按钮说明此处是个例外。所有的例外情况都会汇总到记录中，因此我们就能看到哪些规则的例外情况最多。这说明ui风格指南中的对应规则可能需要修改。发给开发人员的警告信息还包含了一个维基页面链接，解释为什么要遵守这一规则。点开这个链接后，开发人员还可以进入到ui风格指南里的对应章节了解更多信息。将规则融入到开发工具、在工具中加入ui风格指南链接，有助让开发人员更加关注ui准则。
我们从ui风格指南中总结出了大概300条规则，并把它们归类为“硬规则”和“软规则”。这些规则的质量必须是完美无瑕的。显然，如果开发人员收到的警告消息完全没有意义，他们就会认为这个工具不好用，并降低对该工具的信任度。我们引入规则时必须经过深思熟虑，并且在大量真实的ui模型中测试ux规则。
我们把部分ux规则融入到开发工具中，并给bydesign管理团队展示开发人员如何在开发环境中使用ux规则。他们很喜欢这种方式，并让我们继续这一项目。我们在应用程序开发团队的一个模块中进行了试点项目，看看开发人员对ux规则的接受程度如何。试验的结果很好。随后我们把越来越多的规则融入到开发工具中，进行大量的测试后发布给开发人员。ux规则有助于提高解决方案的质量，最后还帮ux团队和开发人员省去了许多人工测试的麻烦。
我们最后终于让管理层认识到ux规则也应该成为评价软件版本kpi的正式指标之一。如今开发人员必须先解决所有违反ux硬规则的地方，然后我们才可以把软件递交给客户。这对ux团队而言又是一个里程碑，我们又向用户体验制度化迈出了巨大的一步。在第三阶段结束的时候，可用性kpi得分是7.3分（总分是10分）。与第二阶段结束时的6.8分相比，我们又提升了产品的用户体验。