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

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

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

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

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

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

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

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

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

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

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

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

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

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

1、先搞明白自己要做什么
       很多小公司，因为看到别人都在做，还不明白要做什么就开始做了，做来做去生成了一堆垃圾。就算你在盲从和抄袭，也应该知道自己在做什么。虽然校内网和海内等在抄袭国外的facebook，但他们很明白自己在做什么，人群定位也较准确，校内网定位于校内学生，很明确，也很准确，并获得了一定成功。虽然我们都在骂当初校内网他们抄袭的太直接（据说源代码都直接抄袭），但这只是品质问题，并没影响到他们成功。

2、找到好的切入点
       在商业规律中有这么一条禁忌：“勿拾人牙慧”，甚至有的书里放出狠话：“拾人牙慧者必死”。总之都在倡导产品要有自己的特点，再退一步讲，就算你没有特点，也必须有一个好的切入点。何为切入点？简而言之，产品怎样去做才能让用户乐于接受。分析市场和目标用户是解决这一问题的有效途径。至于分析什么，这里仅分享一个简单的思路：
       (1)如果市场空白，无竟品。那么我们就应该去调查用户的真实需求，并分析出各需求的强烈程度。需求总是很多，抓住强烈需求、提炼出主要需求。我们再基于这些主要需求去做产品时，起码心里有了底气。
       (2)如果市场有竟品，竟品的分析就显得很重要了，调查用户的真实需求亦不能省略。有效分析点如下：
        a.目标用户的主要需求
        b.对手做了哪些功能，满足了那些功能。可以搞个产品对比列表出来。
        c.对手的发展方向分析
        d.对手的特点罗列
        e.对手的缺点罗列
      基于以上分析结果，我们可以根据自己的资源特点找切入点了。没有竟品，我们会直接考虑基于那些需求去做，做到那些，划分产品阶段及发展方向；有竟品一般我们会先考虑如下切入点：(1)可替代性、(2)差异化、(3)资源或成本优势。做了这么多分析的工作，如果你还是迷茫，那么请你让位给别人吧！

3、客观对待产品的发展过程，沿着相对满意的方案前行。
       注意，这里说的是“相对满意”而非“最好”。很多领导都企图做到完美的方案之后才敢于迈出计划阶段，很多项目因领导者的质疑而不敢前进，拖来拖去，最后导致一个原本不错的项目流产。可这世上没有完美，只有更好。有了这个普遍的共识之后，我们应该勇敢的迈开步伐前行，何况任何产品都要在发展的过程中不断求证和改进。

小结：基于各种客观分析而做产品，也因此敢于迈开产品实施的第一步，甚至迈开推向市场的重大一步！

一，“自我表现意识”是沟通的大忌！

       不管你想不想承认，很多人在沟通的时候，容易依仗自己的优势，来特意表现自己，故意让周围的人感觉自己比对方强（大概是虚荣心吧）。不知道你有没有碰到过这样的情况：在你寻求（或需要）领导（或同时、朋友等）的帮助的时候，没想到他先指责了你半天。比如：

“这样地方怎么能这么做呢？！这样做多不好！”或 “ 你看这里，你怎么能犯这么低级的错误呢！”或“看你这样做多麻烦！看这么多步！多复杂呀！”他先指责了你半天，
“那给点意见呗，或者说点你自己的观点。”虽然被说了很多不是，虽然你很迷茫且心里很郁闷很气愤，但出于礼貌还是很友好的问道，
“我刚才不是说了吗？！！”对方却反问，
……

       没错，都说了，或许也都说的对，但他只是空洞的指责了这么多，却没有理解你想要什么；或许你只是想拿出一个想法和他讨论一下，期望她给点专业的指点；或许你只是想拿你走一下逻辑，一块梳理一下。而现在，你觉得那么可气，就算他说的有些是对的，你仍然不愿意接受，因为这时候你很讨厌他。

二，沟通者需要就事论事的心态

        在我们沟通问题的时候，应该平等的身份来讨论，因该以与事者的心态来讨论。发起沟通者描述问题，参与沟通者思考问题，并以解决问题为目标，发表各种各样的思路、看法、建议等。

       如果你是领导，以领导的身份和下属讨论，那不叫讨论，那叫责备或者“下命令”；举个场景：

“你A处做的不好，应该XXXXX样，你得改一下。”领导
“可我想是XXXX想的，我基于XXXX的考虑，觉得这样会好些。”设计师
“你这样想好吗？回去照我的意见该吧。”领导一边疑问一下，一边坚持自己的观点。
“……”设计师不想再说什么了。

以上场景叫“审核”，如果这个算沟通，不算太成功吧，怎么着也得一块推敲一下。

       以平等的心态来沟通，就必须避免炫耀自己，这个炫耀自己可能包括很多，比如：认为自己比别人强、认为自己是上级等等，但归根结底是自己的“优越感”，在沟通的时候会流露出炫耀的语气，以此给其他沟通者带来不快！并可能因此让其他沟通者从情绪上严重抵触。越是领导，越应该放平心态来沟通，心态放平了，沟通会更有效，也有效的避免了抵触情绪。举个和谐的场景：

“你帮我看一下这个问题”A说，
“恩～，稍等，让我想想……，我觉得XXX会有XXXX的问题，你觉得呢？”B说，
“恩，是哈，你这么一说我觉得也有这方面的问题。看样子得在XX处改动一下”A一边说一边比划了一下，
“我突然有个想法你看好不好，在这里加个XX按钮，然后把XXXX改动一下，感觉这样能解决刚才这个问题，你看看这样会不会有帮助？”B一边说一边比划着，
“有道理，在你这个想法基础上，把XXX改为XXX会更好些”A说，
“是吗，改一下看看……，恩，是好些。”B边动手改一下边说，
“OK了，谢谢～”A说。

       以上场景算是较和谐的沟通吧，起码没有情绪上的问题。把心态放平，就具体问题提出建议，或以解决问题的心态讨论，总比空洞的指责更好。

 三，发起沟通者是沟通的中心

       沟通，每个人都可以成为沟通的中心，因为有问题需要沟通的人被视作沟通的中心，沟通在帮助此人解决问题。沟通的问题是中心，沟通的人也被可以视作中心源，所以我们要认真的倾听发起沟通者的描述，认真揣测发起沟通者想要达到什么意图，这样才能针对要达到的目的进行有效的沟通。

       试想，如果你不管找你沟通的人想要得到什么结果，就很自我的发表一通言论，沟通的结果是什么：搞笑？让对方觉得不快？炫耀了自己？根本谈不上有效沟通！对方的情绪只能是不满、不快或无奈。

小结：在开发团队中沟通基本上是人和人之间的事情，人都是有情绪的；我们在设计或开发中，多数是为了具体问题而沟通，而非为了情绪而沟通，但我们应首先处理好情绪，避免因情绪而带来麻烦，然后才能很放开的去充分沟通问题。

沟通，请别带有情绪！
或许每个人都很忙，任务很重！这时候就得看自身的修养了。沟通是大家取长补短，互相提醒。工作进度和重心的不一样，很容易造成在配合上的不协调，这时候大家可能都有些不平，为什么我要做什么的时候，你们那边还没把配合的准备好？？？“指责”成为通病，也给沟通带来障碍！这时候就应该静下心来想一想：或许别人工作时不知道你那边这两天具体需要什么，简单的沟通其实就可以解决这个问题，灵活的沟通在此时尤其重要。 关于情绪的控制，白鸦写了篇不错的文章： 平和的说服别人。

沟通，要有效率！
我以前在一家公司上班的时候，有一个不好的现象就是：动不动就沟通，但动不动就没有没有结果。后来回忆那个时候的工作，大家不是没有热情，是沟通的时候没有针对性或针对性太弱。泛泛的道理是最要命的！如果不是思想交流，工作的时候最好针对实际问题讨论解决方案，扯的太远，会没有结果！虽然扯的时候相当有兴致和深度。 沟通，有明确的目标才能产生效率。 沟通，在适当的时候。
这点就要具体问题具体对待了。沟通其实也分整体和局部，一般是在一个项目开始的时候有整体的概念，就必须做整体的沟通；在具体实施的阶段就开始一个目标一个目标的沟通，可以称之为局部沟通。在一个小的局部的阶段性的工作开始的时候，最好相关联的人做好沟通，大家把相关联的元素相互配合好！ 在一定程度上避免在实际做的时候频繁的沟通，以至于会相互打扰过度，造成工作效率的下降。沟通，以目标为基础，每块都是中心。
沟通的时候，可以每个都看作中心，大家把各自关心的问题和需要的元素摆出来，各自又都能看到那些和自己是相关联的，相互关联的之间就需要配合去做。相互配合好了，目的就达到了！ 仅根据自己的经验写点感悟，供大家参考。摆正心态，用心去做，相信什么问题都会解决…