項目要經曆三個階段，如圖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分相比，我們又提升了産品的使用者體驗。