产品设计中的指挥官命令

4 评论 3927 浏览 5 收藏 9 分钟

指挥官命令是指让执行的人明白,如果只能做一件事,那应该是做哪件。

最近跟一个产品经理交流,他跟我吐槽:“我让设计师检查一个效果,确定之后再上线,结果你看看,上线之后是这个效果”。

我看了一下,的确有些奇怪,一个明明应该很突出的功能,最后的效果却需要用户需要保持下拉状态才能看见全貌。

我隐隐觉得事情有些严重,我就问她是怎么描述的。

“首页进来,这个卡片默认收起(露出一小部分),往下滑动列表,卡片全部呈现出来。用户再往上滑,卡片再次收起。”

听起来不觉得有问题啊,我在界面上实操一下之后,我笑了“这不全怪设计师”。

我仔细体验了一下,目前的动效符合他描述的所有要求,但是不满意的地方,是在一个小小的隐含的细节,当用户下滑列表时,用户此时看见卡片展开,很可能是想看卡片内容。可当他手一松开,结果卡片却收起来了……(用户:我想看,卡片:不,你不想)

问题在于

产品经理只描述了方案,没有描述目标。导致设计师只注重了卡片动效的功能表达,没有注重用户体验的隐含诉求。

如果这个任务用指挥官命令,可能应该是这样的——保证用户在需要时可以看见卡片的详情。(当然,没有站在体验的角度进行设计验收和开发,也是巨大的隐患)

哦,说到指挥官命令,其实是我最近听到的一个故事——

故事

说美国陆军一支部队执行一个任务。这个任务是:明天六点钟要登山一个山丘,在山丘上做好防御工事,掩护运输队通过,然后帮他们断后,再行进到另外一处地方补给。

第二天该部队一上山,发现山上有人了,所有的情形跟预先制定的计划完全不一样了,这支部队就不知道该怎么执行这个任务了……

哈哈哈,他们好傻是吧~

故事之所以成为事故,是因为这个美国陆军指挥官为了计划的周密,给部队下达了一个近乎完美的解决方案,却没有明确告知指挥官命令。但是当环境变化时,第一个任务就无法完成,这个时候执行部队就无法继续执行任务了。

如果指挥官的任务是这样描述呢“你们的任务是保护运输队通过,你们可以……”。部队在接到这个命令时,很清楚最终目的,中间发现了敌人、天气变化等,就灵活应对,最终实现保护运输队通过就是完成了任务。

什么是指挥官命令?

让执行的人明白,如果只能做一件事,那应该是做哪件。(这里的执行人指完成具体任务的人)

如何正确下达指挥官命令?

我们不能将自己脑袋中的方案视为珍宝,然后让产品设计师按方案执行。你会发现,他们最终出来的方案简直就是文不对题。你会烦躁为什么这么简单的事情要折磨这么久…

是目标,而不是方案

指挥官命令不是一个方案,而是一个清晰的目标/效果;

一个,而不是一堆

保证一个任务只有一个首要目标,当然任务可以拆分,被拆分的任务也可以有各自的首要目标;

让执行者做这个任务时,只需要记住一个目标,就能很好的完成任务。

举个栗子

目标:“某某模块的操作效率整体提升20%”

目标:“某某模块提升数据加载速度,减少弹出框的录入方式,增加批量处理功能……”

差异在于,如果数据加载速度已经到了目前技术可达到的极限,执行者还可以考虑其他方式来达到产品操作效率提升的目标,比如异步加载之类的方式。不然,有一个完不成的任务都会给整个产品的推进带来巨大影响。而且心中铭记一个目标,在执行时方向更明确,不管是产品、设计、还是开发都能更好的保证目标的达成

执行者需要了解指挥官命令吗?

有些指挥官做成了指挥家,他们俨然把自己当成了执行人员背后的神。他希望所有人的一举一动都是受他操控,来集体完成他心中的方案。在他眼里,这些执行人员只是代替了他的手…

这种模式除了在流水线作业的工厂可能有一点作用,在互联网企业中这样做非常糟糕。可能会因为一个人的眼界,拉低了整个产品的档次。

而且在这个瞬息万变的时代,产品中每一个功能都有很多关联因素和环境因素需要考虑,不了解目标的执行人员根本就无法做好事情。

如果我是“执行者”

作为执行者的我们,往往会陷入一种困境,就是指挥官没有说清,只给我一个方案,让我照做。我能怎么办?还不只能一步步照做。特别是一些很强势且不讲道理的老板/需求方更甚。

这里分享个人的一些心得:

再问一层,寻找顶层逻辑

所有方案一定都有它的顶层逻辑,而只需要一层层往上挖,就能找到顶层逻辑,指挥官命令就能被找到。不用担心领导嫌你问题多,就算再嫌弃也比出了方案之后找你麻烦来得更轻松。

向上管理,不然背锅的只是自己

不能完全按领导的方案来做事情,领导需要人来替他思考。不然就算你按照领导的方式来做,也得不到好的结局。顶多得到一个“努力倒是挺努力,就是没什么想法”的标签。

你要记住,你的上司是会不断变化的。不能把自己的成长寄托在某一个单独个体之上。这种畸形的成长会影响你之后的所有做事方法,甚至局限你的思维。

再举个栗子

“给我把弹窗都干掉,我不想看见它”

“哦,为什么你这么看不惯弹窗呢?”

“你看,我在做XX的时候,不断地打断我!”

“嗯,总是打断用户操作的确很不好。这应该不是最主要的原因吧?”

“你想啊,我们的用户一天可能需要处理几百份这样的资料,弹窗弹来弹去都要烦死了”

这个时候,指挥官命令差不多快现出原形了——提升用户大批量操作的流畅度

之后,所有方案围绕指挥官命令,而不是干掉弹窗。

这样,成功避免了这次你真的去掉了弹窗,下次他还会来给你吐槽“说你干掉弹窗,你就真的只干掉弹窗啊,你给一个专业人员设置那么多分开步骤干嘛?嫌他不够累吗?还有你把弹窗全部干掉了,我们现在退出关闭时的确认都没了,你不带脑子干活的吗?”

结语

正确的下达指挥官命令,可以加快团队的作战效率和准确性,避免各环节人员只是为了做而做。

如果你的团队出现了需求、设计的反复修改,或者执行人怎么做都达不到领导要求的时候,记得认真推导一下指挥官命令到底是什么,你弄明白了吗~

 

本文由 @得勿 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 无论什么时候,尽量让自己输出“目标”,而不是“方案”。不然容易导致沟通上的误解。

    来自浙江 回复
    1. 👍 只有目标相同,才能让自己和团队走向同样的终点。
      产品和设计经常掐架的重点在于,产品觉得设计师不懂产品,光好看有什么用,然后设计师会觉得产品又不懂设计,为什么要整那么多内容,low死了。
      把方案输出者拉到一个相同的目标上来交流,才能对等沟通,甚至最后的方案还有可能会让你眼前一亮(方案可以有,但只是补充/仅供参考)。

      来自广东 回复
  2. 不要把产品经理看得太高,这个命令用的不恰当,这个“命令”用的就成了冲突的根源,你可用任务。

    来自浙江 回复
    1. 是的,“指挥官命令”是引用了故事中的一个词语,实际情况中应该不是“命令”而是任务 😉

      来自广东 回复