这是一个创建于 2547 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚才说服失败了，同样内容，在设置和显示的时候方式不同，我觉得这样做毫无意义，还要增加工作量，用户也难以理解，但是感觉自己有点着急，说服产品失败了。
喝了口水冷静了一下，做了个笔记，以后遇到这种情况该怎么处理：
1.沟通前先全局考虑好，做到有理有据。
2,不要指责设计，比如：这里重复了，表现不一致，很不直观，用户看不明白等等。这样的指责会让对方产生抗拒心理，从感性上就不愿意同意你的说法。
3.沟通的时候，产品说出他的设计理念之后，先表示赞同，降低对方的抗拒心理，然后先从实现逻辑的方面来说出这样的一些缺点，可以适当夸大（这里表现不一致，跟之前的代码冲突，要在很多地方增加转换逻辑，代码会变得难以维护），最后再给出建议（所以我们可不可以这样，让表现一致起来，我这边的逻辑也比较清晰。），并表示并不影响用户使用（这样可能用户也直观一些）。
4.如果沟通不畅，产品不太愿意改，注意语气态度，不要急，这时候越冲越难以说服对方，只会产生反效果。
5.如果都说了，产品还是表示一定要这样做。那就喝口水冷静一下，生气发火也没卵用，专业点，开始干活。
我也不是说我的想法就一定比产品正确，但就觉得写自己认为很不合理的东西心里会不爽，大家平时遇到了是怎么办的？
喝了口水冷静了一下，做了个笔记，以后遇到这种情况该怎么处理：
1.沟通前先全局考虑好，做到有理有据。
2,不要指责设计，比如：这里重复了，表现不一致，很不直观，用户看不明白等等。这样的指责会让对方产生抗拒心理，从感性上就不愿意同意你的说法。
3.沟通的时候，产品说出他的设计理念之后，先表示赞同，降低对方的抗拒心理，然后先从实现逻辑的方面来说出这样的一些缺点，可以适当夸大（这里表现不一致，跟之前的代码冲突，要在很多地方增加转换逻辑，代码会变得难以维护），最后再给出建议（所以我们可不可以这样，让表现一致起来，我这边的逻辑也比较清晰。），并表示并不影响用户使用（这样可能用户也直观一些）。
4.如果沟通不畅，产品不太愿意改，注意语气态度，不要急，这时候越冲越难以说服对方，只会产生反效果。
5.如果都说了，产品还是表示一定要这样做。那就喝口水冷静一下，生气发火也没卵用，专业点，开始干活。
我也不是说我的想法就一定比产品正确，但就觉得写自己认为很不合理的东西心里会不爽，大家平时遇到了是怎么办的？
 |
1
notoys 2017-11-23 17:06:07 +08:00
我觉得吧你觉得不合理的地，别人可能认为合理，尝试着心平气和的把对方说服呗。如果你的理由不够充分的话，就老老实实根据产品的来咯；如果产品的理由不够充分，硬要你改的话，那恭喜你遇到了一个“优秀”的产品。总之，让双方达成一致是目的，而不是为了证明谁对谁错。
|
 |
3
mantout 2017-11-23 17:33:13 +08:00
 |
 |
4
Jackliu 2017-11-23 19:41:42 +08:00
菜鸟产品路过
|
 |
5
cqcn1991 2017-11-23 21:19:58 +08:00
你这个说得比较抽象，不是很好理解实际哪个更好
这本质上是怎样合理做产品决策，大概是这几个思路 1. 合理评估决策 对于一个产品决策，重要的是决策的理由是什么，哪个更好的达到了我们的目标 比如一个首页有两个设计，都很好看，但是我们的目的是尽可能快的帮用户了解产品，那么就不是单纯的好看了 2. 结果的未知性 对于一个功能，未必我们的设想就是正确的 比如，小程序出来前，多少人看好？扁平设计刚出来，多少人不喜欢？ 所以不会带着结果去推过程（“我是对的，所以我要说服他”），而是客观的陈述产品决策理由，有更好的就用就行了 3. 实现成本 对于小的需求，很有可能实现成本很小，这个时候纠结细节可能比较浪费精力，快速实现就行了 很有可能我们纠结这么多，用户根本无所谓；很有可能我们实现了，自己使用了，才发现可能存在第 3 种方案 好的产品是迭代出来的 其实更重要的，是更高层次的东西，也就是 Meta-决策 1. 团队产品决策的方法论 2. 复盘与反思 有分歧的产品决策，有没有记录和复盘，看是否达到了预期效果。没有达到效果有没有反思 这里建议读下 Sprint, 里面有 hackthon 的决策方案，怎么评估大家的 idea, 不能决定做哪个怎么办 |
 |
6
johnnydepp 2017-11-23 22:18:43 +08:00
揍他。
|
 |
7
LewisW 2017-11-24 08:53:04 +08:00 via iPhone
拿刀过去说
|
 |
8
Creabine OP |
 |
9
dilu 2017-11-24 14:39:20 +08:00
告诉他实现不了
|
Select Language