产品开发中伺候老板要讲究技巧交互设计

由细臼分享时间：2023-09-17 08:58:25 收藏本文

【简介】感谢网友“细臼”参与投稿，下面是小编为大家整理的产品开发中伺候老板要讲究技巧交互设计（共7篇），仅供参考，喜欢可以收藏与分享哟!

篇1：产品开发中伺候老板要讲究技巧交互设计

之前写过如何处理“老板说”，但是大家在实际突发事件中，对于老板的封口气势仍然难以招架，如果真以走流程之类的言语挡回去，自己都替老板火冒三丈，特举出下面这种情况，跟大家说说应对上的一些策略。

场景：周末你正在家裸奔

事件：老板电话告知他的一个idea，需要你处理

通常同事们的应对方式：

回答一：您这需求还有好多地方没细化，数据没验证，做不了。。。。

（老板后遗症：唉！我的人效率真低，水平太差。。）

回答二：%……&￥@#，哦，啊。。嗯，咳！。。 *&￥&………R%。（脑子里一锅浆糊，老板的事必须做，老板没让我跟别人说，先做了看吧）

（老板后遗症：马上就能做，看来我的人平时太闲了。做出来乱七八糟，跟我讲给他的完全不靠谱）

应对方法：

电话中：

1. 听明白老板要做啥，问清楚做的原因

2. 围绕老板的目的，丰富讨论。婉转地补充和归纳实现中老板没想到的、想错的地方。另外，建立老板对你承担任务能力的信任：）

3. 电话中不要轻易决定动手。越有价值的feature，实现绝不是很简单的事。所以你们的讨论，也只是刺激思路、发现问题的充分拓展。实现的时候没有备忘录，是不可能没有遗漏的。

4. 讨价还价。如果你不敢拒绝老板什么都答应的很顺利，那么换个角度，你是老板的话，会有个什么印象。这个人现在有时间。。。这个人现在是闲着的。。。这个任务很简单（也就是不费功夫）。。。进而。。。，进而就是，你在实现中没有退路！即使你很忙，也许让老板觉得你能接临时任务，又不影响其他工作，那肯定是工作量不饱和！

电话后：

这里是不能偷懒的，

表现你重视老板的需求，就要仔细想想老板交待的事，在纸上、白板上、文本工具中整理下，

你设计的实现方案和过程，与老板需要的对比

看看疏漏和必须细化的地方，坑有哪些

能实现的程度和质量，需要花多少工夫，影响到手头上的哪些工作

需要通知到谁，或者需要谁协助你给你些输入，帮你分担些啥，哪些是哪些协作角色该做的。

整理好以后，写成邮件发给老板，抄送给你想到的那些同事。

想想这样做会获得什么？

最重要的：为自己争取到了执行缓冲时间

从老板那里：获取确认和肯定。老板大都是具备煽动演说能力的人，也许是他情绪膨胀，文字能让人冷静。也让他看到你是认真的，还能帮他组织实施。记住，老板只给idea是很正常的，要不花钱雇我们干啥。实施能力的强与不强，就在于你是能组织运作整个事，还是只是貌似很reasonable地做驴。

从相关同事那里：稍微大点儿的公司，产品实现可能就分成产品角色、开发角色和维护角色。很明显，完成这件事，不全是你的职责。但是老板只讲给了你怎么办？

如果你能完整并周全地传递给协作同事，他们也会承担份内之事，他们会增进对你的信任，喜欢与你的沟通；

不如其他同事专业的地方，同事也会给你反馈，帮你确认方案；

还有些事，可能根本是老板的头脑发热，与你的同事讨论过与现有计划有冲突和弊端，没准你的同事就帮你把这事挡了。。。。

坚持对每一次这样的突发事件使用相同的方法，如果你的老板让你做特紧急或者特秘密的行动，他会习惯地嘱咐：这件事一定要马上做。。。其他事你先放放。。。不要告诉别人。。。。！@

照顾好自己，理解老板、理解同事，协调，协调！

来自：www.laobingqun.com/space.php?uid=325&do=blog&id=1242

篇2：有关产品创新交互设计

德鲁克所阐述的创新机遇之七大来源：

一、意料之外的事件;

二、不协调的事件——现实状况与设想或推测的状况不一致的事件;

三、基于程序需要的创新;

四、每个人都未曾注意到的产业结构或市场结构的变化;

五、人口统计数据(人口变化);

六、认知、意义及情绪上的变化;

七、新知识,包括科学和非科学的

要做的事情是：

1、有目的、有系统的创新从分析机遇着手；

2、创新必须多看、多问、多听，既要关注数字，也要关注人；

3、创新必须简单有效，目标明确；

4、有效的创新始于细微之处；

5、成功创新的目标是取得领导地位，

有关产品创新交互设计

，

避免的事情是：

1、不要太聪明；

2、不要过多花样，不要分心；

3、不要为未来进行创新。为现在进行创新！

创新的三个条件是：

1、创新是工作，要把创新当做工作那样去对待；

2、创新者必须立足自己的长项；

3、创新必须与市场紧密相连，以市场为中心，以市场为导向。

德鲁克最后提出，企业家和创新者要做“保守的创新者”，“成功的创新者都相当保守，他们不是专注于冒险，而是专注于机遇。

原文链接：jary.findesign.cn/?p=3208

篇3：产品&设计&色彩交互设计

设计师得到产品设计需求的时候，经常会碰到一个色彩的选择问题，产品经理最初也可能会提一些自己的意见，如

A：我觉得做一个蓝色的不错，就做蓝色的吧！

B：喜庆一点的，红色没错的！

C：这个颜色太压抑了，亮一点怎么样

D：这一块颜色好花啊！

作为设计师应该怎么去回答呢？

先简单分析一下ABCD,4位所要表达的潜台词，

A：对该产品从个人主观或个人经验所做出的色彩上的推荐

B：喜庆的！而不是真的要求用红色或者其他

C：设计图的感觉偏移了产品初衷和产品气质，觉得这不是想要的

D：主体不突出被干扰

在最早设计的时候，我一般都会问产品经理最终要求，产品表现需要达到的目标和效果，而不是讨论色彩排版细节，这样才能先找到根本，避免CD所出现的情况，早期对产品的理解，对后期设计过程有着重要的指导意义！只有理解产品价值，然后通过正确的方法，就能准确定位产品色系，不会出现大的偏差。

色彩定位方法论, 准确定位色彩方法有很多，如色彩心理选择法、图片映衬法、调查问卷数据分析法等多种形式,下面简单讨论一下常使用的几种方法:

1.色彩心理选择法

我们视觉所感知的一切色彩，都具有色相、明度、和纯度三种性质。不同的色相明度纯度，给人不同的心理印象，色彩上从心理感受的大方向到小方向的细分，逐渐无限的接近最适合用户心理的色彩区块，

根据色彩心理属性来筛选色彩，大家都知道，色相就是色彩的相貌，如红、橙、黄、绿、青、蓝、紫、色相在心理上有强烈的冷暖的区分，

如红、橙、黄让人想到阳光、火焰和太阳给人温暖的感觉即暖色系，青、蓝、让人想到大海蓝天，给人清爽凉快的感觉即冷色系，在设计的时候最早考虑的是产品气质和宣传效果，需要给人什么样的心理感受。

如果需要给人热情、活力的感觉就选择暖色系，如果需要给人冷静、高雅、庄严的话就选择冷色系，进行第一轮的筛选。

第一轮筛选后，比如选择的是冷色系，也就是色环右边的绿蓝紫区间，然后根据产品气质和色彩心理进行匹配缩小选择范围，调整小范围的色彩偏向，明度饱和度的微小差别，最后找到和接近最适合的色彩！

2.图片映衬法

在拟物化场景图片中寻找适合色彩，进行设计，例子：阅读器概念设计过程，虽然图形概念最终没有采用，但是设计过程思考方式可以进行参考。

最早设计的时候寻找了一些读书馆场景图片资料，然后在场景图片中取用3种色值作为软件主体颜色进行设计。

从图片中取用3中色值，进行场景化模拟！

最后实现效果:

3.调查问卷数据分析法

即设计师提出多种色彩方案，以交互常用的调查问卷、用户访谈等方式进行数据收集，根据数据分析进行删选最适合的色彩，这种方式准确率高，缺点就是时间成本和人力成本都消耗比较多！

篇4：产品感悟一二交互设计

蛋王的BLOG八百年不更新，大仙表示很欣慰；大仙的博客好久未更新了，我表示很欣慰；其实我们都很懒，作为“高级打杂”的产品经理，我们确实可以“名正言顺”地说我们很忙，

1、理理我的一些产品经理书籍：

启示录：前段时间，看到很多同行在不同的地方推荐《启示录》，于是果断地下单购买，并满怀期待地等待书送达。书送达后翻了翻，确实不错，然后读故事书般看完了。

人人都是产品经理：这书很不错，入行必备，实战型，有案例，收获不少。可惜的是阿里的色彩太溶，不够典型。

结网：这本书让你明白产品经理应该怎样做，偏理论，入门级读物，看完让你对这个职位有了一些清晰的认识，入行必备。

沸腾十五年:让我看得津津有味，堪称互联网教科书，让你了解互联网这个行业的兴起和趋势，给你一个大局观。最让我感叹的时，看到介绍的一些项目，有我所经历过的，现在看成败，感叹颇多。

很感谢苏杰、狒狒、王坚，感谢他们的总结和整理，对于我们这个新兴的行业提供了一些标准和参照物。

理理书籍，整理后给个推荐指数（凭记忆），也算是给后来人一个参考。

目前在看的一些书籍：《创业邦》《IT经理世界》《谁说菜鸟不会数据分析》《精通web analystics2.0》。关注产品运营、数据分析。

2.功夫在诗外

很喜欢纯银的博客，一些关于行业、心得、沉淀，《运气与浮云》《杂念.职场》《杂念.行业》，这几篇看得心有戚戚焉，

功夫在诗外，产品经理本身就是一段心灵的修炼过程。沟通、思维、决策、分析和解决问题的方法和能力。最近也正在把生活融入产品，把产品融入生活。

最近很少写关于一些工作和技能的文章，技能上已经到了临界点，现在欠缺的是火候，是一份为人处事的出容。

关于工作上的事，也一直在总结。最近积累和总结的一些方向：电子商务、社会化电子商务、产品经理、移动互联网、手机应用商店、WAP产品设计、Symbian产品设计、Android产品设计、Iphone产品设计。这也是最近1年来的最大收获：电子商务和移动互联网。

产品经理需要阶段性的总结和沉淀，我经常隔段时间就会花一些时间来整理自己的一些体会。

3、关于成功

成功的要素：天赋、努力、机遇。自觉得天赋不算很高，所以唯有通过不断的努力来弥补。机遇也有，但是很可惜，去年的2次机会都没抓住，所以现在需要更加的努力，在下次机会来时能做好准备。

做喜欢的事，把工作当成自己的事业。成功，需要厚积薄发，需要等量变引起质变。

有时在想这1年来的得失，最大的收获是进入了移动互联网。1个光杆司令（虽然有电子商务产品经理、无线产品经理、产品助理等3个岗位编制，但人真不好找）支持了公司1整年来的业务，策划了1个WEB站，2个WAP站，2个客户端，前段时间写半年考评时内牛满面。

4.现在&未来

现在，专注产品运营，努力把产品线运营起来。

未来，继续深入移动互联网和APP，这是最好的时代。

篇5：管理者，请你远离产品开发/设计部门交互设计

先说一个身边真正发生过的故事，可能大家会对故事情节感觉非常熟悉，

一家小型电子商务公司，管理者就是公司的创始人，他有些技术开发背景。因为产品面向海外市场，他也比较关注产品设计与可用性。由于他对自己的技术、设计能力的自信，总是对开发部与设计部成员的能力持怀疑态度，经常插手他们的工作。

一次，开发人员就新产品需求、设计文档的要求，提出开发方案A。这位管理者看后，以其经验判断认为不理想，并给出方案B。开发人员觉得方案B有些问题，但一时又没有找到有说服力的例证，无奈只好以此方案进行开发。

果然，在开发过程中，由于管理者仓促间所提出方案，在设计上确实存在不合理的疏漏，导致项目出现了一些问题。当开发人员想方设法将问题一一解决后，突然发现，这个DEBUG后的开发方案B，已经变得与他们最初提出的方案A并无二致。

而此时，该项目已经严重超期，那位管理者还为此非常不满，认为是开发人员能力的问题导致的。此后，管理者对开发工作的介入变得更多，而开发人员也开始变化，一部分对领导的这种超权行为越来越不满意，矛盾变得更加激化，后面工作中的沟通变得更加困难；另一部分则变得越来越没有积极性，领导要求怎么做就怎么做。

刚好看到UCDChina.com中的一篇文章《管理者不应直接参与产品的开发与设计》，感觉说得太有道理了。上面这个故事，可以用来充实文章的论据。

其实团队管理者关注团队产品的成败，是非常正常的心态。他们插手设计、开发工作，无非是希望把产品更得更好，动机是无庸质疑的。尽管如此，还是不建议管理者过多的介入具体的开发与设计工作，即使是领域专家型的管理者，过多的插手具体设计、开发工作，也得不到预期的结果，可能对于项目来说，往往事与愿违，由此产生的恶性干扰多于良性的指导，这是得不偿失的。

为什么会这样？原因很多：

1、因为管理者与团队成员的权重不同，有管理者参与的项目，往往不能非常公平地对待其它项目涉众。尽管，管理者本意是以其对项目的理解和自身的经验，为设计、开发团队提供一些指导和建议，至少也会增加一种思路。但往往事与愿违，管理者介入后，一般会导致所有项目涉众的思维模式，会被管理者所左右，就因为他是团队的管理者。

大家想想，是否经常遇到这样的情况，设计、开发人员深思熟虑后形成的方案，经常因为管理者的一点儿质疑，而被否决；而管理者的灵光一闪，都可能形成一个决策，如果其它团队成员想到推翻它，必须经过周密、详实的举证与论述，这本就不公平，对项目也绝对没有好处，这会影响到团队成员的思路，甚至导致他们逐渐推动思考的动力。

2、因为技术背景与对项目的关注点不同，管理者与设计、开发人员会处在不同层面，看问题角度肯定是不同的。其实，能从多个不同角度看待产品，这本来是好事，可以把问题考虑得更全面一些，

但如果以管理者的角度，去干扰设计、开发中的问题，那就是另外一码儿事了。

《论语•泰伯》：“子曰：不在其位，不谋其政。”

这句话说得非常好，这不是推卸责任意思，而恰恰是出于更负责的角度考虑。为了便于理解，这里把“位”理解为“职位”。

每个职位有不同的职责，职责会影响人的立场，不同立场、知识背景的人理解、处理同一个问题，其结果肯定是不一样的。也许管理者认为自己可以做到“换位思考”，即便如此也是搁靴搔痒的状态，其结果绝对差强人意。比如，管理者明白不能让UI设计师去考虑代码优化的问题，那又为什么自己去犯同样的错误呢？

正所谓术业有专攻，专业的工作还是让专业的人去做，那才可能达到令人满意的结果。

3、有人说，在IT行业，许多管理者都是优秀程序员或策划、设计师出身，这种领域专家型的管理者插手做具体设计、开发工作，应该有对项目、对团队成员有帮助。

其实不然，前面提到的两点问题，对于这样的管理者也依然存在。而且，文章开头提到的那位管理者也曾经是开发人员，本身也是位不错的产品设计师。为什么团队成员在他的指导下，项目进展依然不顺利呢？

从事过产品设计、程序开发工作的朋友应该很清楚，这样的工作需要投入大量的时间与精力，这是一个反复尝试与迭代的过程。好的设计与优秀的编码，绝对不是通过纸上谈兵或灵光一闪就可以得到的（当然，这个世界是有天才存在的，也许他们拍拍脑袋就可以把产品设计得非常完美，程序编码也可以没有任何BUG，但毕竟这种天才少得没有说服力）。有的时候，即使写好伪代码，也不能百之百的确保业务逻辑没问题。

而团队的管理者，往往事务缠身，他们没有精力（也不应该）深入于其中任何一项具体工作，那样就会犯下过于关注细节的管理大忌。而浅尝辄止的心态，恰恰又是做好设计与开发工作的大忌。这样看来，管理者兼顾设计、开发工作，并取得好的结果，根本是一项不可能完成的任务。

当然，领域专家型的管理者是可遇而不可求的，他丰富的经验与思路都是对团队成员有帮助的，但仅此而已，具体的设计、开发工作还是应该让设计师和程序员来做。

基于上面分析，如果管理者仍执意要插手设计与开发工作，就必须保证自己的观点（或决策）是100%准确与全面的，这样才不会对项目有负面影响。

当然，这样的要求是不合理的，也没有人敢做此承诺，所以，管理者们还去做好本职工作吧，那里才是发挥你们特长的地方。好的管理者，要懂得放权，要对团队成员应该有足够的信任，相信他们的工作能力，也相信他们的工作态度。正所谓：用人不疑，疑人不用。

如果管理者实在想参与设计、开发工作，那就干脆转行吧。

本文出自：blog.sina.com.cn/s/blog_564cabe30100bxmb.html