“我们的设计很好，可开发的产品很差！”，这个问题想必困扰着不少公司或团队，在近期的工作中，逐渐体会到一套行之有效的方法–让产品设计师跟踪测试自己设计的产品。设计师不要小看这测试的工作，跟踪测试起来颇有成就，你可以知道你的设计被实施了多少，看着实施符合设计，设计师会很有成就感。我也是被CTO逼着走过了这个过程才逐渐体会到它的好处。

        产品设计师不大可能与程序员一起写程序，但可以跟踪测试开发的产品，并把测试结果直接反馈给大家(程序员、项目经理、产品经理、测试人员)。这应该算是一个管理问题，确切的说是协作流程问题。所以这种做法，必须得到cto等高层管理者的大力推行，否则编程者是不买帐的，毕竟谁都不愿意让人跟在屁股后面指责哪里做错了，高管把产品设计师的测试工作纳入流程，大家照章办事，工作起来会更顺利一些。

测试的时机：
产品开发基本成型，功能基本完备，研发者能提供可测试版本。

测试的相关协作：
发送测试文档给开发者，同时抄送给项目经理、产品经理、测试等等相关人员；遇到争议主动找项目经理、产品经理等相关领导协商。

测试依据的文档：
        做过测试工程师的应该都知道，测试工程师是根据自己编写的测试用例(精简测试用例、详细测试用例)来测试，一般情况下，设计师根据精简测试用例文档来测试就好了，设计师只是要依据某个使用过程来试用并发现问题。当然如果设计师愿意写几个主要使用场景，然后根据自己的使用场景来测试更好，不过要注意自己的使用场景和设计文档保持一致。

让产品设计师跟踪测试的好处：

1、设计师比测试工程师更多关注可用性，可以保证产品的高质量。毕竟设计师对评判产品好坏较强的审美能力。
2、遇到问题可以直接给出解决方案，效率高。
3、可以看到更多的设计问题，便于及时补充和修正设计文档。设计师可以锻炼细节关注能力，积累更多经验。(本条第收获很大呀！)
4、设计师可以很好的参与到开发中去。

分享一下自己做跟踪测试的经验和教训

1、设计师在跟踪测试之前应做足的工作：确保设计文档写的更详细和易读，确保无主要逻辑缺失。最好做出原型并依据原型多体验几遍，或者邀请其他设计师一起来体验，争取在开发前发现更多的问题，确保文档质量。否则，一旦开发出现问题或者开发进度延迟，会把全部责任推到产品设计师身上。开发者会说：“文档没写”或“文档没写明白，看不懂。”遇到这样的情况，设计师百口难辨，设计师的确是有责任的(虽然不是全部)。

2、搞好关系，不要直接指责开发人员或开发中的问题。理智的做法应该是：”客观的表述操作，客观的提出正确的方案。”描述问题时不要有任何情绪，或者可能让合作者产生“逆反心理”的语气。比如：“竟然”“居然”“错误”等，当然适当的夸奖一下也是可以的。

3、在遇到争议时，通过正确的渠道解决问题，主动通过双方主管协商解决，开发人员不会听你的，不要试图说服他们，和他们争论的结果只会让他们记恨你，还有肯能找机会给你穿小鞋，设计师争取避免这个问题。遇到问题要先学会倾听，然后才有可能正确处理问题。否则容易产生误解，让别人误以为你不好合作或不好沟通(但实际上你是为产品质量而挣)。

4、和开发人员、测试人员保持紧密的沟通，提高解决问题的速度；有需求变动或文档改动要迅速反应，并及时通知大家。否则，如果研发没有按照变动来修改，会怪罪你没有及时通知。

……，更多感受还需到工作中去体会。

小结：说了那么多，这样做还得公司高层大力支持并推行为前提；设计师要真正处理好各种关系还得自己实际去体会，毕竟每个公司的情况都不尽相同；设计师可以获得很多，更清楚要向开发者“表达什么？如果表达？”。

一、测试之前我们需要准备什么？

        太简单了，拿出出你的草图(草纸编好循序，以免弄乱) ，准备一只笔和几张草纸，选定你身边的3～5个人(什么人不做限制)，一个小会议室(只要是不被打扰的地方都行，有桌子板凳什么的)。

二、准备就绪，开始我们的测试，逐个约T至小会议室。大致顺序如下：

1）M拿出自己的草稿，说明意图。
2）M按顺序向T展示自己的草图，T根据草图模拟操作(比如：点击XXX，在XXX填写XXX，点击XX按钮打开另一个界面)。最好能在不解释的情况下让T看懂，顺利的情况下T会主动要求操作下一张草图。
3）利用测试间隔，简单的记录发现的问题，并画出被测试者操作草图的路线图。
4）测试完后，”叠加”操作路线图，找到操作规律；总结在测试过程中发现的问题，根据问题出现的概率，判断设计问题。

三、在测试中应注意的问题

1）避免把测试变成说明，M应该尽量少的在测试过程中对T做说明。当T在刚开始就不理解，无法继续测试的时候，M可以尝试着做简单的提醒，以便继续下去，并同时记录下原因；如果在简单的提醒之后T仍无法完成，那就终止此次测试，简单的聊一下T的所想，以便改进设计。
2）避免T在测试过程中过多的发表自己的看法，尽量让T按照草图操作，如果想了解T的想法或者疑问，可以在测试之后，与T简单的交谈一下。

四、此方法的优缺点

优点：
1、成本很低，方法很简单；
2、能发现基本操作的不通顺之处；
3、能发现许多，思考到的细节问题；。
缺点：
1、不能因此而推断真正的用户是如何操作的
2、测试时会因界面不太逼真，无法体现最终效果

小结：说白了就是拿草图找几个人按照操作的思路走一遍，以此来验证思路，查找疏漏；此方法只是在思考的过程中，用一个便捷的方法验证一下自己的思路，以此来改进设计，查找疏漏。