經曆了項目的各個階段，我們知道了哪些實踐是可行的，哪些需要改進。這曾是一個不斷學習的過程，如今我們依然還在學習。
本章中推薦的大部分ux實踐對你和你的公司應該會有所幫助。但有些實踐更适合在流程更複雜的大型公司和全球性組織中執行。你可以聽取一些我們的建議，試着在你的公司中執行。你将會知道哪些實踐經驗是有用的，哪些需要根據自己的實際情況做調整。
明确ui需求的優先級 從客戶和使用者的角度考慮ui需求的優先級。運用使用者研究資料和最終使用者ui驗證結果證明優先級的正确性。
讓ui需求變得簡單易懂 決策者需要了解ui需求。通過截圖表達視覺效果，使用簡單易懂的術語。如果你的需求是從可用性測試結果中發現的，還可以播放一段使用者界面令使用者抓狂的視訊，隻需要截選亮點即可。
為ui架構團隊提出需求 在為ui架構提出需求的過程中，使用者體驗團隊應該處于上司地位，并需要強力表達自己對于需求優先級的意見。ui架構團隊是技術團隊的一部分，負責搭建應用程式開發團隊制作使用者界面時使用的技術平台。例如，ui模式就是由ui架構團隊開發的。
彙報ui需求執行的進展 經常向管理團隊彙報ui需求的執行狀況。當改進成果可釋出時，向管理層展示成果。
與ui架構團隊建立良好的個人關系 在使用者體驗團隊和ui架構團隊之間建立穩固的協作模式。如果你與ui架構團隊建立了良好的個人關系，他們會更願意協助你實作那些能夠改善使用者體驗的ui需求。
為每一個真正使用者的需求盡力争取實作 你必須争取實作每一個能夠提升使用者體驗的需求。僅僅是把需求放到清單中，指望它能夠按照你希望的方式實作，這是行不通的。你必須争取實作每一個需求，而且如果你的目标設計無法實作，你應該提出另一種可行方案。
建立合理的模式庫 模式庫裡的樣式數量應該足以讓應用程式層面的設計師和開發人員可以選擇以滿足使用使用者界面的使用者的任務執行需求。
将ui風格指南融入開發工具 将ui風格指南融入開發工具中有助于顯著提高産品品質，提高開發流程的效率，是以有必要讓ui模式成為ui架構的一部分。基于模式的工具可以保證設計與開發的一緻性和全面性。ui風格指南裡的規則應該分為“硬規則”和“軟規則”。“硬規則”可以用硬代碼寫入開發工具。“軟規則”有時候隻是建議或最佳實踐。這些規則在90%的情況下都是可用的，隻是有時候可能有些例外。把這些“軟規則”融入到開發工具中，如果開發人員在開發過程中違反了某個規則，則系統會給他們發提醒資訊。如果這一違規是有意的，開發人員隻需要标記上“例外”的标記就可以繼續工作了。如果此處并不是個例外，他可以馬上解決該問題。ux規則拉近了ui風格指南和開發人員的距離。
規劃好ui架構的疊代 落實使用者需求以優化ui模式是一項富有挑戰性的工作。你必須為開發過程中的疊代預留出足夠的時間。通過最終使用者測試已實作的模式，并不斷改善模式。
邀請開發人員參與可用性測試 開發人員需要接觸真正的使用者，觀察使用者在使用軟體時的感受。
引入自動化ui測試 自動化ui測試可以空出人力去完成更有成效的工作。自動化測試應該用于回歸測試（regression test）。這有助于提高産品品質。3
獲得最高管理層的認同 你必須讓最高管理層認識到以使用者為中心設計的價值，才能夠獲得足夠的資源和預算。如果你無法做到這一點，你或許該考慮另謀高就了。
ucd教育訓練與指導 通過提供教育訓練與指導（例如，現場觀察和“如何寫出好用例”的教育訓練）使解決方案經理、ux設計師和開發人員順利地執行ucd流程。組織中的很多人或許還不是很熟悉ucd方法論，而且即使他們以前可能接觸過ucd，在項目過程中也可能會有新人不斷加入到組織中，是以這種知識的更新必須持續進行。教育訓練必須以實用為目的，佐以大量的例子和實踐。它的目标是在動手的過程中學習。
了解解決方案經理和開發人員的需求 了解解決方案經理和開發人員的需求，幫助他們取得成功。讓他們參與客戶和最終使用者操作的現場觀察，感受以使用者為中心設計的價值。我們曾邀請了一些開發人員和解決方案經理參觀對最終使用者的現場觀察和可用性測試。親身經曆學到的東西總是更透徹，光“說教”是行不通的。解決方案經理一般都有市場研究的背景，但對使用者研究仍不甚了解。使用者研究有助于解決方案經理擷取準确的資料，而且讓他們與開發人員溝通起來更容易。
目标一緻 解決方案經理、ux設計師和開發人員要實作團隊合作、目标一緻。讓共同目标成為ux設計師、開發人員和解決方案經理個人目标的一部分。
保持曝光率，推銷以使用者為中心的設計 定期彙報最終使用者測試結果。展示節選的視訊亮點将最終使用者使用産品的感受傳達給團隊和管理層，并向那些無法親自參與可用性測試的人提供遠端觀察支援。
“一個團隊”路線 建構跨領域團隊，保證掌握所需技能的成員在需要的時候總是在團隊中。為了保證團隊效率和産出的最大化，這個團隊應該包括解決方案經理，ux設計師，開發人員和知識管理部門經理。
讓團隊“共處一室” 如果條件允許最好讓團隊在一處辦公。不同的團隊分布在各地辦公并沒有什麼問題，但是每個團隊裡掌握所需技能的成員都應該在一個辦公地點辦公，如果在同一間辦公室就更理想了。我們的目标是共同的辦公地點，但這不是一夜之間就能改變的。随着每個版本的釋出，我們的辦公地點越來越集中，而且我們一個團隊最多隻允許有兩個辦公地點。雖然這不是最理想的狀态，但我們已經朝着正确的方向邁出了一步。
循序漸進 讓大型組織走ucd路線的思想轉變需要時間，可能需要數年才可以自然過渡，而且過程中總是會有可以改進的地方。
隻要一個産品開發流程 确定統一的總體産品開發流程，将以使用者為中心的設計順利地融入流程。確定沒有單獨的ui流程！
清晰地記錄流程 提供清晰的流程描述，明确需要傳遞的内容。讓每一個人都清楚自己在其中的職責是什麼。想讓流程變得簡單易懂，首先要對每個階段進行綱領性的描述，但如果需要也可以拓展到細節。
明确角色分工 明确不同團隊的角色和職責，避免引起“誰來上司使用者體驗”的争執。
将用例定為傳遞的必要項 在了解使用者的主要目标和任務之前，你不應該開始ui設計。為了獲得高品質的用例，你需要與客戶和最終使用者溝通，回顧現有的應用程式和之前的可用性測試結果，與負責現有産品的客服部門代表面談，詢問使用者反映的ui問題有哪些。
排列用例優先級 專注于提高最重要、使用最頻繁的用例品質。用例的優先級要有所不同。
提供好用的模闆和最佳實踐 為需要傳遞的内容提供模闆，并介紹模闆使用的最佳實踐，讓人們更容易接受。好的例子會讓學習更容易。
确定産品和版本的待處理需求清單 明确産品和版本的待處理需求，清晰地排列出大需求類别的優先級。排列了優先級的清單也有助于确定使用者體驗活動優先級。産品待處理需求涵蓋了未來2～3年裡的高層面需求。而版本待處理項目隻涵蓋了下一個版本的需求。
盡早統一需求 你必須盡早與團隊統一需求。開發人員應該在項目初期就參加進來。這是為了避免解決方案管理部門确定了需求後直接抛給開發部門的情況出現，開發人員從一開始就需要參與概念設計。
為概念設計階段安排充足的時間 你必須為使用者研究和概念項目安排充足的時間。在靈活開發流程中更是如此。我們決定以6個月為一個釋出周期，并為更複雜的概念項目安排3～5個月時間的前導時間。概念項目要與上一版本的開發并行進行。
為疊代做計劃 以使用者為中心的設計是一個疊代開發方法。你必須安排好疊代開發時間。
運作試點項目 如果你想讓某些項目上的改進成為流程中的強制步驟，最好先開展試點項目。多花點時間指導試點項目，以確定良好的效果。成功的項目有助于讓管理層和參與項目的人認可項目的價值。然後再讓他們作為傳播者說服組織中的其他人也采用這一方法。
提供基礎設施，便于使用者開展活動 給團隊提供一個能讓他們更快、更友善地接觸到最終使用者的基礎設施。
讓開發人員參與使用者研究活動 通過參與使用者研究，開發人員能夠更好地了解使用者需求，更看重制場收集的真實資料。開發人員并不用參與每個現場觀察，但至少要出席彙總現場觀察結果的總結工作坊。
讓ux規則成為強制性門檻 定期監測并彙報從開發工具中監測到的ux違規情況。在将産品遞交給客戶之前必須解決優先級較高的ux違規問題。
評估ux目标完成情況 通過關鍵績效名額（kpi）定義ux目标，通過基準可用性測試評估kpi，然後向管理團隊彙報基準測試結果。
持續改進流程 沒有完美的流程。你必須不斷改進流程，不斷評估流程與工作。
![測試基礎第一課[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)