注：先明確一下這里所說的產品設計師的職責：需求收集、信息架構、交互設計、產品設計文檔撰寫。
“我們的設計很好，可開發的產品很差！”，這個問題想必困擾著不少公司或團隊，在近期的工作中，逐漸體會到一套行之有效的方法–讓產品設計師跟蹤測試自己設計的產品。設計師不要小看這測試的工作，跟蹤測試起來頗有成就，你可以知道你的設計被實施了多少，看著實施符合設計，設計師會很有成就感。我也是被CTO逼著走過了這個過程才逐漸體會到它的好處。
產品設計師不大可能與程序員一起寫程序，但可以跟蹤測試開發的產品，并把測試結果直接反饋給大家（程序員、項目經理、產品經理、測試人員）。這應該算是一個管理問題，確切的說是協作流程問題。所以這種做法，必須得到cto等高層管理者的大力推行，否則編程者是不買帳的，畢竟誰都不愿意讓人跟在屁股后面指責哪里做錯了，高管把產品設計師的測試工作納入流程，大家照章辦事，工作起來會更順利一些。
測試的時機：
產品開發基本成型，功能基本完備，研發者能提供可測試版本。
測試的相關協作：
發送測試文檔給開發者，同時抄送給項目經理、產品經理、測試等等相關人員；遇到爭議主動找項目經理、產品經理等相關領導協商。
測試依據的文檔：
做過測試工程師的應該都知道，測試工程師是根據自己編寫的測試用例（精簡測試用例、詳細測試用例）來測試，一般情況下，設計師根據精簡測試用例文檔來測試就好了，設計師只是要依據某個使用過程來試用并發現問題。當然如果設計師愿意寫幾個主要使用場景，然后根據自己的使用場景來測試更好，不過要注意自己的使用場景和設計文檔保持一致。
讓產品設計師跟蹤測試的好處：
1、設計師比測試工程師更多關注可用性，可以保證產品的高質量。畢竟設計師對評判產品好壞較強的審美能力。
2、遇到問題可以直接給出解決方案，效率高。
3、可以看到更多的設計問題，便于及時補充和修正設計文檔。設計師可以鍛煉細節關注能力，積累更多經驗。（本條的收獲很大呀！）
4、設計師可以很好的參與到開發中去。
分享一下自己做跟蹤測試的經驗和教訓
1、設計師在跟蹤測試之前應做足的工作：確保設計文檔寫的更詳細和易讀，確保無主要邏輯缺失。最好做出原型并依據原型多體驗幾遍，或者邀請其他設計師一起來體驗，爭取在開發前發現更多的問題，確保文檔質量。否則，一旦開發出現問題或者開發進度延遲，會把全部責任推到產品設計師身上。開發者會說：“文檔沒寫”或“文檔沒寫明白，看不懂。”遇到這樣的情況，設計師百口難辨，設計師的確是有責任的（雖然不是全部）。
2、搞好關系，不要直接指責開發人員或開發中的問題。理智的做法應該是：”客觀的表述操作，客觀的提出正確的方案。”描述問題時不要有任何情緒，或者可能讓合作者產生“逆反心理”的語氣。比如：“竟然”“居然”“錯誤”等，當然適當的夸獎一下也是可以的。
3、在遇到爭議時，通過正確的渠道解決問題，主動通過雙方主管協商解決，開發人員不會聽你的，不要試圖說服他們，和他們爭論的結果只會讓他們記恨你，還有肯能找機會給你穿小鞋，設計師爭取避免這個問題。遇到問題要先學會傾聽，然后才有可能正確處理問題。否則容易產生誤解，讓別人誤以為你不好合作或不好溝通（但實際上你是為產品質量而掙）。
4、和開發人員、測試人員保持緊密的溝通，提高解決問題的速度；有需求變動或文檔改動要迅速反應，并及時通知大家。否則，如果研發沒有按照變動來修改，會怪罪你沒有及時通知。
……，更多感受還需到工作中去體會。
小結：說了那么多，這樣做還得公司高層大力支持并推行為前提；設計師要真正處理好各種關系還得自己實際去體會，畢竟每個公司的情況都不盡相同；設計師可以獲得很多，更清楚要向開發者“表達什么？如果表達？”。