起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識產(chǎn)品設(shè)計階段中的設(shè)計準則
產(chǎn)品設(shè)計是與時俱進的，而產(chǎn)品設(shè)計的準則也是如此。
我目前的團隊自去年底組建以來，經(jīng)歷過多次的團隊協(xié)作迭代，逐漸找到適合自己開發(fā)模式。每個開發(fā)團隊的項目性質(zhì)不同，或是因為項目初始成員的特質(zhì)影響，會逐漸形成自己團隊的特殊文化與適合產(chǎn)品設(shè)計的標準。
在 Medium 上有一篇產(chǎn)品經(jīng)理寫的文章，作者根據(jù)自己多年的經(jīng)驗，將產(chǎn)品開發(fā)團隊分成了下列六種：
- 用戶中心團隊：例如 medium
- 增長型團隊：例如?booking.com
- 功能型團隊：例如 Atlassian
- 設(shè)計中心團隊：例如 Apple
- 技術(shù)中心團隊：例如 Google AI
- 初始團隊：原文指的是具有滿腔熱血但還沒有明確 KPI 的團隊，常見于新創(chuàng)團隊或是黑客馬拉松項目（Hackathon Project)
雖然每個團隊專注的焦點不同，產(chǎn)品設(shè)計的標準也有可能不同，不過產(chǎn)品設(shè)計的通用性「準則」，應該是可以應用到多元的團隊上。
雖然這幾年開發(fā)團隊不斷朝著扁平化發(fā)展，一個產(chǎn)品的好壞不再是產(chǎn)品經(jīng)理的全權(quán)責任，但產(chǎn)品經(jīng)理在產(chǎn)品設(shè)計的整個階段，仍扮演了十分關(guān)鍵的角色。也因此，產(chǎn)品設(shè)計的通用準則，對產(chǎn)品經(jīng)理而言，不僅要熟記于心，更要靈活運用這些準則，培養(yǎng)使其成為一種直覺。
探索問題階段
1. 想解決人們的什么問題？
這是一個一開始也是最后的問題，這個問題的關(guān)鍵角色，永遠不會是問題本身，而是使用產(chǎn)品的「人」。
2. 為什么這個問題值得被解決？
聽起來有點玄，但實際上并不是所有問題都值得「被解決」。
跟大家分享個小故事：我們現(xiàn)在使用的鍵盤叫做 “QWERTY 鍵盤”， “QWERTY” 就是鍵盤左上邊數(shù)來的字母排列順序。你可能會想，這個鍵盤的排列方式是希望能幫助打字更快、更有效率，很抱歉，剛好恰恰相反。
QWERTY 鍵盤推出時，還是 1800 年打字機的年代。當時技術(shù)發(fā)展有限，打字機的響應速度比不上人類打字的速度，因此常常出現(xiàn)打字機故障的情況。 QWERTY 鍵盤的設(shè)計，其實是為了降低打字效率，特意將最常用的幾個字母分開，在當時也成功解決了打字機卡死的問題。
隨著技術(shù)不斷進步，許多人想解決 QWERTY 鍵盤降低打字效率的問題，也的確推出了更符合人體工學、能提高打字效率的鍵盤，但一推出到市面上，最終都是以失敗收場。因為人們早已習慣 QWERTY 鍵盤，甚至有除了鍵盤輸入以外的信息輸入方式。也因此，「QWERTY 鍵盤降低打字效率的問題」，就不是那么值得需要被解決了。
3. 這個問題是否是一個真正的問題（本質(zhì)的問題）？
我們團隊曾遇過一個真實的案例：業(yè)務主管跟你說他想要做一個實時監(jiān)控業(yè)務員定位的功能，如果 IT 團隊將這個功能實現(xiàn)了，會發(fā)現(xiàn)實時監(jiān)控不但對于數(shù)據(jù)傳輸量的要求相當高，也非常耗費業(yè)務員的網(wǎng)路流量，而且業(yè)務主管平時工作忙碌，幾乎不可能「實時」監(jiān)控。
其實業(yè)務主管提出這個需求的背后，是想了解業(yè)務員是否確實執(zhí)行工作，而實時監(jiān)控，只是業(yè)務主管基于這個本質(zhì)的問題所提出的一個可能的解決方案，但卻不一定是個合適的解決方案。
4. 這個問題是否簡單、清晰，足夠被其他人理解？
換句話說，如果一開始就無法清楚定義問題，那又怎能產(chǎn)出具體有效的解決方案呢？
執(zhí)行階段
（1）全局在前，細節(jié)在后
深入一個解決方案之前，確保已經(jīng)嘗試過其他的方案。最快的驗證方式，就是當團隊其他成員提出「怎么不試試 XXX」建議的時候，就代表想的還不夠全面。
（2）原型圖快速驗證方案
如果產(chǎn)品已有明確的目標使用者，在進入開發(fā)之前，可以通過簡單的原型圖先讓這群使用者進行測試（可用性測試 Usability Testing），藉此快速驗證方案。
（3）設(shè)定產(chǎn)品的預期結(jié)果
包括任何質(zhì)化或量化指標，比方說減少 20% 的操作時間、提升整體使用滿意度……等等。
（4）排序功能開發(fā)優(yōu)先級
一個完整的功能里，一定有最重要、次重要以及較不重要的排序（MoSCoW 優(yōu)先級）。過去強調(diào)全面、完整功能的瀑布式開發(fā)流程，在現(xiàn)代快速迭代的數(shù)字世界里已逐漸被敏捷思維所取代。
舉個例子：當 A 團隊還在為那從 90 分進步到 95 分的功能苦惱而遲遲無法推上線時，競爭對手 B 團隊早已將 80 分的產(chǎn)品推上線，雖然 80 分的產(chǎn)品讓終端使用者不是很滿意，也有不少抱怨，但 B 團隊收集到了真實使用者提出的問題，并進行改版。
當 A 好不容易將 100 分的產(chǎn)品推上線，卻發(fā)現(xiàn)市場早已被 B 占據(jù)，而且 B 的產(chǎn)品經(jīng)歷多次改版，更符合使用者的需求，當初 A 團隊堅持的 100 分產(chǎn)品也不是當今市場的 100 分了。
（5）快速試錯，迅速調(diào)整
以更包容的心態(tài)來面對錯誤的發(fā)生，檢視個人或是團隊在面對錯誤發(fā)生時，是否有足夠快速的應變能力，能迅速調(diào)整方向，并且記錄問題、總結(jié)歸納，不再犯同樣的錯誤。
（6）階段性反思總結(jié)
無論產(chǎn)品成功或失敗，團隊反思是整個執(zhí)行階段中最重要的一個環(huán)節(jié)。團隊反思，絕不是互相抱怨的批斗大會，而是一個階段性任務完成時，讓團隊彼此都能夠沈淀思考，調(diào)整步驟繼續(xù)邁步向前的機會。
尤其在跨功能的團隊里（cross-functional team），可以更好了解各個團隊成員在協(xié)作中遇到的挑戰(zhàn)、當下的解決方式，以及未來可以如何調(diào)整合作的方式。
團隊反思的時間可以是在一個大的開發(fā)版本上線前后發(fā)起，通過 1-2 小時的會議，有明確的主持人、會議記錄者，分別感性與理性的兩個時間段。感性的時間里，讓大家說說過去的開發(fā)過程中看見好的、不好的以及要感謝的地方；理性的時間里，明確的提出問題點，讓團隊一同來思考解決方案。
驗證階段
（1）設(shè)定驗證指標
在產(chǎn)品上線之前，就必須將驗證指標設(shè)定好，并確保團隊每一位成員認同各項指標。
（2）設(shè)定反效指標
這個驗證方式是 Facebook 產(chǎn)品設(shè)計副總監(jiān)（Product design VP）Julie Zhou 提出的，驗證一個指標是否成功，就把不成功的指標條列出來。
（3）找出問題比調(diào)整方向更重要
產(chǎn)品上線后，如果發(fā)現(xiàn)偏離指標的情況，無論是好的或是壞的方向，首先厘清問題發(fā)生緣由，再來調(diào)整策略。
作者：Yvonne Wu，微信號：yvonneyvonnewu? 領(lǐng)英：Yvonne Wu
本文由 @YvonneWu 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。轉(zhuǎn)載請標明原作者與出處。
題圖來自 Pixabay，基于 CC0 協(xié)議
- 目前還沒評論，等你發(fā)揮！
