注：先明确一下这里所说的产品设计师的职责：需求收集、信息架构、交互设计、产品设计文档撰写。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       在中小企业中，许多产品或项目被反复做，反反复复，裹足不前。可以理解小公司的忐忑心态，怕投资商不满意，怕面向市场就倒掉，怕… ，怕的事情很多，给自己背的包袱太多，像蜗牛似的前行，甚至在反反复复中流产。“找到切入点，正视产品发展的客观规律。”这句话是我的忠告。

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

2、找到好的切入点
       在商业规律中有这么一条禁忌：“勿拾人牙慧”，甚至有的书里放出狠话：“拾人牙慧者必死”。总之都在倡导产品要有自己的特点，再退一步讲，就算你没有特点，也必须有一个好的切入点。何为切入点？简而言之，产品怎样去做才能让用户乐于接受。分析市场和目标用户是解决这一问题的有效途径。至于分析什么，这里仅分享一个简单的思路：
       (1)如果市场空白，无竟品。那么我们就应该去调查用户的真实需求，并分析出各需求的强烈程度。需求总是很多，抓住强烈需求、提炼出主要需求。我们再基于这些主要需求去做产品时，起码心里有了底气。 Read the rest of this entry »

       昨天一个朋友给我抱怨说：“他妈的！我们的总监太不成熟了，一点小事就大呼小叫的，生怕领导和周围同事不知道是的，那种口气‘啊！怎么会这样呢，咋整成这样了！’，妈的真让你受不了!我打算要“撤”了。”在设计或开发中，出现问题是很正常的，我们怎们沟通这些问题很重要。沟通是一门艺术，很多时候不只是简单的把问题说清楚，更多的时候我们要关心对方接受了多少？以什么样的口气沟通对方会接受更多一些，或者不至于因出言不逊伤害对方的自尊等等，相信大家心中都会积压一些沟通的情绪问题。

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

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

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

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

二，沟通者需要就事论事的心态 Read the rest of this entry »

由于公司的产品存在许多未知的变数，于是沟通尤其重要！但沟通本身存在的问题很多，简单根据自己的想法归纳了一下.

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

沟通，要有效率！
我以前在一家公司上班的时候，有一个不好的现象就是：动不动就沟通，但动不动就没有没有结果。后来回忆那个时候的工作，大家不是没有热情，是沟通的时候没有针对性或针对性太弱。泛泛的道理是最要命的！如果不是思想交流，工作的时候最好针对实际问题讨论解决方案，扯的太远，会没有结果！虽然扯的时候相当有兴致和深度。 沟通，有明确的目标才能产生效率。 Read the rest of this entry »

从当初的网页设计者，到现在自己主导交互设计，其中经历了大概4年的历程，一直期待着设计的春天，终于设计在中国开始萌芽了，起码在北京、上海、广州、深圳等大城市开始萌芽了，但在现实的软件开发流程中，大多时候还是被编程控制着。于是让坚持设计阵营的同行们心里有“边缘人”、“交通协管”的愤慨！但仍坚持着、推动着这个领域的发展。最近上班老是堵车，在公交上看到交通协管在殷勤的协助交通，突然感觉到现在的交互设计师很多竟然处于交通协管的境地，可以想一下：交互设计师如果没有参与前期需求、概念和框架设计的机会，那么他只能跟在编程后面擦屁股，被命令做软件的改进，太痛苦了！通常的结果就是效果甚微！交通协管也是在弥补交通的不合理所带来的弊端。但交通协管毕竟不是交通设计师，他们就是协助，没有设计的义务。可交互设计师就不同了，交互设计师应该在早期参与设计的，但通常被用来做协管，痛苦也难怪！感慨怎么成了”边缘人“也难怪！被认为”效果不明显也难怪！
Read the rest of this entry »