做平台性的
测试工具，通常涉及到各个角色，接触最多的就是测试工程师和开发工程师。
和用户沟通
普通用户抱怨质疑多，方案建议少；但是测试工具的大部分用户是测试工程师和开发工程师。
他们一般都明白自己所需并具备清楚表达的能力，有明确的价值目标，有良好的方向感和情境感，有些自己本身就独立开发过优秀的工具，所以在整个工具开发的生命周期中，他们能承担更多角色，参与更多过程。
测试人员提前介入需求，甚至担任某些模块的PD，参与到产品开发中来，对工具的顺利推广也很有帮助。毕竟，是自个儿亲生的。这批同学是工具最早的用户，他们的工作模式能影响和带动一批用户。
对设计师的要求
测试工具和一般互联网产品有所不同。
传统页面以导航和内容为主，测试工具内容并不复杂，重功能和交互。
区别于导航和内容的罗列, 作为管理和帮助性工具，一个页面通常会集中很多功能；工具所争取减少的每一步操作都是在节约工程师的时间，出于工作效率考虑，需要更丰富便捷的交互操作。
在实际开发过程中，大部分前端问题也是在交互方面。从用户反馈来看，用户对功能性和交互性的要求远远远远高于界面样式。
这就要求设计师必须对系统需求有所了解，包括业务流程、理解专业术语和每一步操作的目的，否则就是盲人摸象。
不懂测试的设计师很难做出符合期望的界面设计。一般这类工具的设计师角色都是由测试或者开发本身承担。缺点就是产出的界面稍逊美观。不过根据我的经验，人民群众其实是不畏惧界面丑陋的，真正能使用的工具才能长久生存下来。
和开发沟通
关于工具交互，用户有很多优秀的建议和想法，不过最终落实还是到开发头上。可惜的是，好的交互一般开发起来都挺费事儿。大家知道，想把用户体验做到极 致，让用户轻松，开发就要“受罪”，要额外做很多在他们看来价值不大的细节工作。程序员有一个信念，这个世界上，没有代码实现不了的事情。如果他说无法实 现，一定是他不想。设计师对于开发工作所用到的知识有所涉猎，不用成为行家，但至少“略懂略懂”，最好有自己动手的能力，能预估开发投入。这样，才能与开 发工程师建立平等对话，提出的需求和设计才不会被人一略而过。《越光宝盒》里面诸葛亮不是有句台词么，什么都懂一点，生活才能更多彩。
说着容易，实际很难，很多事除非开发自己想明白，劝是没用的。团队里最好有个能一语定乾坤的权威人物，实在和开发沟通不了了，找他定夺。
工具开发的过程中，在很多情况下，开发本身就是PD，会倾向于简化项目，尽量少做、做自己熟悉的，使得项目顺利完成，并且bug很少，做出来的也许体验不好，但是绝对“够用”。
其实协同，是你去协同别人，而不是别人来协同你。主动一点，获得更多。