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