做平臺性的測試工具，通常涉及到各個角色，接觸多的是測試工程師和開發工程師。

　　和用戶溝通

　　普通用戶抱怨質疑多，方案建議少；但是測試工具的大部分用戶是測試工程師和開發工程師。

　　他們一般都明白自己所需并具備清楚表達的能力，有明確的價值目標，有良好的方向感和情境感，有些自己本身獨立開發過的工具，所以在整個工具開發的生命周期中，他們能承擔更多角色，參與更多過程。

　　測試人員提前介入需求，甚至擔任某些模塊的PD，參與到產品開發中來，對工具的順利推廣也很有幫助。畢竟，是自個兒親生的。這批同學是工具早的用戶，他們的工作模式能影響和帶動一批用戶。

　　對設計師的要求

　　測試工具和一般互聯網產品有所不同。

　　傳統頁面以導航和內容為主，測試工具內容并不復雜，重功能和交互。

　　區別于導航和內容的羅列， 作為管理和幫助性工具，一個頁面通常會集中很多功能；工具所爭取減少的每一步操作都是在節約工程師的時間，出于工作效率考慮，需要更豐富便捷的交互操作。

　　在實際開發過程中，大部分前端問題也是在交互方面。從用戶反饋來看，用戶對功能性和交互性的要求遠遠遠遠高于界面樣式。

　　這要求設計師必須對系統需求有所了解，包括業務流程、理解專業術語和每一步操作的目的，否則是盲人摸象。

　　不懂測試的設計師很難做出符合期望的界面設計。一般這類工具的設計師角色都是由測試或者開發本身承擔。缺點是產出的界面稍遜美觀。不過根據我的經驗，人民群眾其實是不畏懼界面丑陋的，真正能使用的工具才能長久生存下來。

　　和開發溝通

　　關于工具交互，用戶有很多的建議和想法，不過終落實還是到開發頭上。可惜的是，好的交互一般開發起來都挺費事兒。大家知道，想把用戶體驗做到，讓用戶輕松，開發要“受罪”，要額外做很多在他們看來價值不大的細節工作。程序員有一個信念，這個世界上，沒有代碼實現不了的事情。如果他說無法實現，一定是他不想。設計師對于開發工作所用到的知識有所涉獵，不用成為行家，但至少“略懂略懂”，好有自己動手的能力，能預估開發投入。這樣，才能與開發工程師建立平等對話，提出的需求和設計才不會被人一略而過。《越光寶盒》里面諸葛亮不是有句臺詞么，什么都懂一點，生活才能更多彩。

　　說著容易，實際很難，很多事除非開發自己想明白，勸是沒用的。團隊里好有個能一語定乾坤的權威人物，實在和開發溝通不了了，找他定奪。

　　工具開發的過程中，在很多情況下，開發本身是PD，會傾向于簡化項目，盡量少做、做自己熟悉的，使得項目順利完成，并且bug很少，做出來的也許體驗不好，但是“夠用”。

　　其實協同，是你去協同別人，而不是別人來協同你。主動一點，獲得更多。