起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識產品設計中的指揮官命令
指揮官命令是指讓執行的人明白，如果只能做一件事，那應該是做哪件。
最近跟一個產品經理交流，他跟我吐槽：“我讓設計師檢查一個效果，確定之后再上線，結果你看看，上線之后是這個效果”。
我看了一下，的確有些奇怪，一個明明應該很突出的功能，最后的效果卻需要用戶需要保持下拉狀態才能看見全貌。
我隱隱覺得事情有些嚴重，我就問她是怎么描述的。
“首頁進來，這個卡片默認收起（露出一小部分），往下滑動列表，卡片全部呈現出來。用戶再往上滑，卡片再次收起?！?/p>
聽起來不覺得有問題啊，我在界面上實操一下之后，我笑了“這不全怪設計師”。
我仔細體驗了一下，目前的動效符合他描述的所有要求，但是不滿意的地方，是在一個小小的隱含的細節，當用戶下滑列表時，用戶此時看見卡片展開，很可能是想看卡片內容。可當他手一松開，結果卡片卻收起來了……（用戶：我想看，卡片：不，你不想）
問題在于
產品經理只描述了方案，沒有描述目標。導致設計師只注重了卡片動效的功能表達，沒有注重用戶體驗的隱含訴求。
如果這個任務用指揮官命令，可能應該是這樣的——保證用戶在需要時可以看見卡片的詳情。(當然，沒有站在體驗的角度進行設計驗收和開發，也是巨大的隱患)
哦，說到指揮官命令，其實是我最近聽到的一個故事——
故事
說美國陸軍一支部隊執行一個任務。這個任務是：明天六點鐘要登山一個山丘，在山丘上做好防御工事，掩護運輸隊通過，然后幫他們斷后，再行進到另外一處地方補給。
第二天該部隊一上山，發現山上有人了，所有的情形跟預先制定的計劃完全不一樣了，這支部隊就不知道該怎么執行這個任務了……
哈哈哈，他們好傻是吧～
故事之所以成為事故，是因為這個美國陸軍指揮官為了計劃的周密，給部隊下達了一個近乎完美的解決方案，卻沒有明確告知指揮官命令。但是當環境變化時，第一個任務就無法完成，這個時候執行部隊就無法繼續執行任務了。
如果指揮官的任務是這樣描述呢“你們的任務是保護運輸隊通過，你們可以……”。部隊在接到這個命令時，很清楚最終目的，中間發現了敵人、天氣變化等，就靈活應對，最終實現保護運輸隊通過就是完成了任務。
什么是指揮官命令？
讓執行的人明白，如果只能做一件事，那應該是做哪件。（這里的執行人指完成具體任務的人）
如何正確下達指揮官命令？
我們不能將自己腦袋中的方案視為珍寶，然后讓產品設計師按方案執行。你會發現，他們最終出來的方案簡直就是文不對題。你會煩躁為什么這么簡單的事情要折磨這么久…
是目標，而不是方案
指揮官命令不是一個方案，而是一個清晰的目標/效果；
一個，而不是一堆
保證一個任務只有一個首要目標，當然任務可以拆分，被拆分的任務也可以有各自的首要目標；
讓執行者做這個任務時，只需要記住一個目標，就能很好的完成任務。
舉個栗子
目標：“某某模塊的操作效率整體提升20%”
目標：“某某模塊提升數據加載速度，減少彈出框的錄入方式，增加批量處理功能……”
差異在于，如果數據加載速度已經到了目前技術可達到的極限，執行者還可以考慮其他方式來達到產品操作效率提升的目標，比如異步加載之類的方式。不然，有一個完不成的任務都會給整個產品的推進帶來巨大影響。而且心中銘記一個目標，在執行時方向更明確，不管是產品、設計、還是開發都能更好的保證目標的達成
執行者需要了解指揮官命令嗎？
有些指揮官做成了指揮家，他們儼然把自己當成了執行人員背后的神。他希望所有人的一舉一動都是受他操控，來集體完成他心中的方案。在他眼里，這些執行人員只是代替了他的手…
這種模式除了在流水線作業的工廠可能有一點作用，在互聯網企業中這樣做非常糟糕?？赡軙驗橐粋€人的眼界，拉低了整個產品的檔次。
而且在這個瞬息萬變的時代，產品中每一個功能都有很多關聯因素和環境因素需要考慮，不了解目標的執行人員根本就無法做好事情。
如果我是“執行者”
作為執行者的我們，往往會陷入一種困境，就是指揮官沒有說清，只給我一個方案，讓我照做。我能怎么辦？還不只能一步步照做。特別是一些很強勢且不講道理的老板/需求方更甚。
這里分享個人的一些心得：
再問一層，尋找頂層邏輯
所有方案一定都有它的頂層邏輯，而只需要一層層往上挖，就能找到頂層邏輯，指揮官命令就能被找到。不用擔心領導嫌你問題多，就算再嫌棄也比出了方案之后找你麻煩來得更輕松。
向上管理，不然背鍋的只是自己
不能完全按領導的方案來做事情，領導需要人來替他思考。不然就算你按照領導的方式來做，也得不到好的結局。頂多得到一個“努力倒是挺努力，就是沒什么想法”的標簽。
你要記住，你的上司是會不斷變化的。不能把自己的成長寄托在某一個單獨個體之上。這種畸形的成長會影響你之后的所有做事方法，甚至局限你的思維。
再舉個栗子
“給我把彈窗都干掉，我不想看見它”
“哦，為什么你這么看不慣彈窗呢？”
“你看，我在做XX的時候，不斷地打斷我！”
“嗯，總是打斷用戶操作的確很不好。這應該不是最主要的原因吧？”
“你想啊，我們的用戶一天可能需要處理幾百份這樣的資料，彈窗彈來彈去都要煩死了”
這個時候，指揮官命令差不多快現出原形了——提升用戶大批量操作的流暢度
之后，所有方案圍繞指揮官命令，而不是干掉彈窗。
這樣，成功避免了這次你真的去掉了彈窗，下次他還會來給你吐槽“說你干掉彈窗，你就真的只干掉彈窗啊，你給一個專業人員設置那么多分開步驟干嘛？嫌他不夠累嗎？還有你把彈窗全部干掉了，我們現在退出關閉時的確認都沒了，你不帶腦子干活的嗎？”
結語
正確的下達指揮官命令，可以加快團隊的作戰效率和準確性，避免各環節人員只是為了做而做。
如果你的團隊出現了需求、設計的反復修改，或者執行人怎么做都達不到領導要求的時候，記得認真推導一下指揮官命令到底是什么，你弄明白了嗎～
本文由 @得勿 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
無論什么時候，盡量讓自己輸出“目標”，而不是“方案”。不然容易導致溝通上的誤解。
?? 只有目標相同，才能讓自己和團隊走向同樣的終點。
產品和設計經常掐架的重點在于，產品覺得設計師不懂產品，光好看有什么用，然后設計師會覺得產品又不懂設計，為什么要整那么多內容，low死了。
把方案輸出者拉到一個相同的目標上來交流，才能對等溝通，甚至最后的方案還有可能會讓你眼前一亮（方案可以有，但只是補充/僅供參考）。
不要把產品經理看得太高，這個命令用的不恰當，這個“命令”用的就成了沖突的根源，你可用任務。
是的，“指揮官命令”是引用了故事中的一個詞語，實際情況中應該不是“命令”而是任務 ??