萬字長文,教你練就產品設計之九陽神功

15天0基礎極速入門數據分析,掌握一套數據分析流程和方法,學完就能寫一份數據報告!了解一下>>

產品設計面臨困境,有什么辦法可以跳脫現狀,提升產品設計的水平?筆者給出了自己總結的“九陽神功”,與大家分享~~

今天早上,小A被拉去開了個會,領導說要做個XXX功能,小A午飯也沒顧上吃,就開始畫方案。晚上領導看了小A的方案,不是太滿意,離領導的感覺還差個十萬八千里。這是今年小A磨的第5個方案,小A感覺已經堅持不下去了。

小B的方案今天又被斃掉了,今天是小B換的第N家公司,被懟的第273天,雖然小B私底下也會偷偷地噴自己的需求上游,但內心里也確實認可了自己是個垃圾的事實。

小C最近學了很多產品上的術語:“XXX定律、XXX效應、XXX畫布、XXX模型、XXX觸點”……最近發現和小C很難溝通,不說人話,動不動就飆個專業術語,或者搬一個唱爛大街的概念“以用戶為中心”、“數據驅動”、“要滿足用戶特定場景下的需求”,和小C討論問題時,特別累、低效、無趣,感覺他跟背書一樣。

小A磨不出領導想要的方案、小B越來越覺得自己就是個垃圾、小C變的越來越孔乙己……

很多事沒有結果可能并不是我們不夠努力,只是方法出了點問題。

倚天屠龍記里明教光明左使楊逍苦修乾坤大挪移多年,最終只能修煉至第二層;而張無忌只用了半天就學到了第九層。為什么?

相比于楊逍,張無忌之前練過九陽神功,這讓他對乾坤大挪移里面的口訣有著更深刻的理解。

如果你的現狀里或多或少也有小A、小B、小C的影子,別慌,坐下,待我也傳你一套九陽神功。

九陽神功第一式:發現問題

發現問題主要有三種途徑,分別是:應用評論、調查研究、競品分析。

1. 應用評論

應用評論是我們了解產品使用現狀的最直接方式,可以通過七麥數據、蟬大師等平臺搜索自己想要了解的應用,查看各個渠道的評論。

產品設計之九陽神功

“應用評論信息的收集渠道”

重點關注3星以下評論,因為從評論角度,用戶不太會因為這個產品好用而特意去應用商店評論一番,但大概率會因為這個難用,去應用商店吐槽。

當然,也并不是絕對的,有些忠誠用戶確實會因為特別喜歡某個功能,會特意去評價。

通過三星以下評論,可以收集產品的改進點:

產品設計之九陽神功

“通過三星以下評論收集產品的改進點”

通過三星以上評論,可以了解在用戶心目中的核心功能有哪些:

產品設計之九陽神功

“通過三星以上評論了解用戶心目中的核心功能有哪些”

收集完評論后,我們需要對收集的信息進行化簡,首先需要從內容上對相似的評論進行合并同類項,其次將合并后的評論信息抽象出關鍵詞,便于我們后續流程中的記憶。

產品設計之九陽神功

“應用市場評論信息的整理:合并同類項+抽象關鍵詞”

2. 調查研究

調查研究過程中最常見的一類問題,就是研究者在開始前就沒有目標,盲目做一些探索性的研究,導致研究與實踐嚴重脫節:分析師很努力,卻像只蜻蜓一樣每天重復水上漂的工作;產品設計師很努力,卻像個盲人一樣絞盡腦汁地磨方案。

無論是問卷調查、還是用戶訪談,開始之前,必須先確定研究的目標是什么,研究目標就是我們產品根據自身經驗提出的假設。

我自己是網易云音樂的忠實用戶,收藏了一萬多首歌,這導致我很難遷移到其他平臺,那么對于我要解決的收藏是不是也有類似的關系呢?

即針對我要優化的收藏功能,假設可以為:“收藏數量越多,用戶留存率越高”、“有收藏的用戶留存要高于沒有收藏的用戶”。

產品設計之九陽神功

“關于收藏功能的假設”

雖然調研之前,我們自己心里一定要有假設,避免沒有目的的調研。但這個過程中,我們一定要保持一顆謙卑的心態,尊重事實,避免上帝視角,只關注佐證我們的想法的現象。

舉個例子,上學時,老師叮囑我們做完試卷,一定要認真檢查,但當我們真的去檢查時,發現很難查出因為粗心做錯的題目。為什么會這樣?

因為我們先入為主了呀,我們不會質疑自己是否粗心了,只會按照之前先入為主的思維把解題條件再演練一邊,佐證自己答案沒有錯。

工作中我們很多人依然被這種思維毒害,把自己先入為主的思維強加于產品。所謂的調研,只不過是為了佐證自己的觀點沒有錯,最后毒害的結果就是我們沒有結果。

工作中我們看到太多過程很華麗、很努力,結果卻是個大鴨蛋的例子。

沒有結果的產品、設計師就好比敗軍之將,或許外人并不了解我們的結果,只是為我們絢麗的過程所吸引,但在同事面前,依然會被瞧不起。所以在想被同事看得起之前,我們先學會如何尊重事實吧。

在調研過程中還需要注意的是,我們調研的對象或許只是個沒有靈魂的殼子。

特定場景下,我們的很多行為其實都屬于帶有“防御性質”的下意識行為。面試時,我們會努力去扮演所在行業里比較優秀的殼(角)子(色);如果扮演破相了,或與面試官期望中的殼子類型相差過大,那我們就涼涼了。

你問我喜歡網易云音樂還是酷狗,我肯定會告訴你網易云音樂,畢竟可以顯得我審美沒那么低嘛,但我私下里確實在用酷狗聽網易云音樂里沒有的歌。即你獲取的僅是我的殼子,你拿殼子去搭建產品,那一定是形式的,更別談體驗了。

怎么辦呢?

首先,你自己得先脫掉角色化外殼,不能因為自己也是這么感覺的,就給別人也貼上這樣的標簽。

就好像你問我喜歡哪個音樂平臺,其實你已經在角色化預期我了,網易云這么有逼格,你不會去選擇一個low-low的酷狗吧。

其次,你得給調研對象創造出一個容易讓人卸下防御的交流環境。

比如開頭你可以直接說:“雖然我很喜歡網易云給我推薦的歌,和每首歌精彩的評論,但是我也喜歡酷狗很多接地氣的功能”。這時被調研的我,可能會被擊中心聲,于是毫無顧慮地講出那個真實的我。

3. 競品分析

競品分析的目的是借鑒別人好的解決方案,避免因為自己閉門造車,產出一些蹩腳的創新。

發現需求階段,通過競品分析可以發現產品當前現狀問題,幫助我們提出產品假設。

一個案例

通過對比知乎這種問答容器,我們發現競品的問答感更強、內容更有吸引力。

產品設計之九陽神功

“針對問答容器的競品分析”

于是我們出了一版針對這條假設的驗證方案:

產品設計之九陽神功

“針對問答容器的優化前后對比”

面試過程中,我們經常會遇到這樣的四連問 “改之前是啥樣子?有啥問題嗎?你改了哪些?為什么可以這么改?”

競品主要幫助我們回答最后一個問題:為什么可以這么改,它是除了客觀數據之外,最有信服的說服依據。

領導:你為啥要把這個改成這樣?

我:我參考了A、B等競品,發現有幾種設計細節很不錯: 他們通過XXX細節從而讓用戶更有動力去用;他們通過XXX細節從而更方便用戶在XXX的場景下XXX的操作。

我:所以我借鑒了XXX競品期望能夠讓用戶更有動力去用它; 借鑒了XXX競品的XXX細節從而方便用戶在XXX場景下的XXX操作。

這樣的溝通場景會不會比“我覺得”要來的更有說服力呢?更顯得我們靠譜、專業呢?

現實溝通場景下,當別人問我們為啥要怎么做時,我們如果回答“XXX競品也是這么做的”,距離別人信服我們,其實已經成功一半了。

這個思路同樣可以應用在方案稿產出中,把我們參考的競品最好截圖下來,清晰地告訴別人我這處改動是參考了哪個競品的什么細節。

產品設計之九陽神功

“+面板改動說明”

產品設計之九陽神功

“聯想面板改動說明”

九陽神功第二式:研究問題

1. 研究問題的目的是為了更好地理解

生活中因為不理解,導致我們一點兒也不幸福:

打王者農藥過程中,不理解父母的嘮叨,被他們貼上“煩”、“浪費時間”的標簽,于是很匆匆掛完他們的電話;

女朋友沖我們發火,覺得她無理取鬧,給她貼上“不講道理”的標簽,試圖和她講道理,結果把矛盾再次激化;

工作當中,不理解領導為啥總是那么苛刻,給他貼上“昏庸無道”的標簽,于是和領導漸行漸遠,結果把自己整離職了。

1)產品設計過程中因為不了解,導致我們很難做到以終為始

不了解指標的計算公式,只是從數據分析師命名的字面意義去揣測這個指標的表現,佐證自己先入為主的想法,心血來潮,動用幾十號人耗時半個月搞出來了,結果指標不為所動,最后只能不了了之。

對問題還不夠了解,導致我們一不小心把產品做成了功能。

做產品追求的是結果,即我這個方案能不能解決用戶問題?

做功能的目標僅是完成,即按照上面要求我做完了功能。任務完成了,下個迭代計劃是什么,不知道,走一步算一步吧,看上級指示。

上述情況更容易發生在新人身上,主要因為:新人對于業務不熟悉,導致我們沒有能力憑借自己的理解主導整個產品設計;新人迫于轉正、評分等壓力,無暇顧及需求本身,更容易把上級需求意會成命令,命令不容質疑,一旦萌發質疑想法,需要強行自我洗腦;新人羞于暴露問題,習慣在自我舒適區內做一些意會錯的決策。

我的老師有句讓我印象非常深刻的話:“沒想清楚就不要去做,要做就做自己已經想清楚的事情”。初聽這句話,我并沒有深刻的理解,也只是意會成一種命令,就像課堂上老師叮囑我們要好好學習一下,只是耳朵聽見了,內心并沒有聽到。

直到后來,我把老師交給我的方案搞砸了,把一個面向用戶的服務做成了我意會錯的功能,我內心終于聽到了這句話“沒想清楚就不要去做,要做就做自己已經想清楚的事情”。

2)設計細節分析過程中因為不了解,導致我們坐井觀天

微信有個長按語音的設計細節:用戶長按后,上滑會出現兩個選擇“取消發送”、“將語音轉化為文字”。

如果不去了解這個細節,我們會武斷地認為這個細節不好,多了個選擇,讓用戶有多思考了一下,這不符合“Don’t make me think ”原則;全國有1億的人在教張小龍該如何做產品,這次又多了一個。

但如果我告訴你一個故事:微信有些用戶很煩別人給他發語音,讀起來很麻煩,特別是連收多個長語音時。

這個故事告訴我們,對于部分用戶,語音形式確實方便了發送;但也給發送方帶來了顧慮,因為對方讀起來很麻煩,甚至會嫌煩。所以,當用戶發語音過程中有顧慮時,就可以通過上滑方式喚出可以讓自己消除顧慮的操作——“語音轉文字”。

2. 怎么研究問題

1)首先,無論是來源于內心的恐懼還是懶惰,面對自己與問題之間的關系時,一定要主動研究,切忌被動接受。

這里總結了一些如何主動研究的經驗:

要想主動,必須熱愛,如果僅僅當成謀生的工作,是真的很難做好的。

我上學時英語不太好,看文獻很吃力,但我很喜歡聽歌,后來我開始享受在網易云音樂上邊聽歌邊看單詞的過程,這導致我后來再看文獻時,幾乎沒什么壓力。

所以,在主動研究問題之前,最好先培養自己的業務愛好。我們公司是做股票軟件的,我在剛進入公司不久,只做了一件事——開戶炒股。每天的心情隨著股價波動而波動,賬戶一紅,整個人可以亢奮一天;賬戶一綠,害怕得要死,去雪球(股票社區)尋找安慰,研究明天是賣還是繼續拿著,這個過程讓我非常喜歡研究股票類的問題。

不懂的就去問,問一遍沒懂,那就去問第二遍,第二遍還沒懂就問第三遍……直到我們真的理解了,不要怕麻煩別人,只要他對你尋找答案有幫助,就去麻煩。

弱者才會在意面子、自尊這些東西,作為強者的我們,內心其實只能裝下兩個字,它叫“結果”。哪怕有一天,你在追尋結果的道路上真的被傷了自尊,那又何妨呢,你依然是個值得尊敬的強者。

為了確保我們確實理解了對方想法,最好把自己的理解再重復一遍給對方,讓對方確認我們的理解是否還存在偏差。最后我們還要做成會議記錄,把這些確認無誤的點,以郵件的形式抄送給項目相關人員。這樣做的好處是:一方面是把信息及時傳達給項目其他成員,形成團隊共識;另一方面,是當細節開發過程中出現爭議時還可以溯源。

出問題不可恥,可恥的是隱瞞問題,遮遮掩掩、支支吾吾、迷迷糊糊。有疑惑,馬上反饋出來,及時確定;有困難,馬上反饋出來,及時尋求團隊幫助,共同尋找解決辦法。

項目評審中經常出現因為前期評審不仔細,到了deadline的時候,才發現某塊功能做不了,最終導致功能不得不砍的情況。如果我們當初評審仔細一點,早點把問題暴露出來,最終的效果會不會完全不一樣。

2)其次,要想理解先學會拆解,我們該如何拆解問題呢?

我們可以從兩個緯度對第一式中發現的問題進行拆解:

  • 理解問題發生的場景是什么;
  • 理解問題的影響什么。

以競品分析過程中發現的設計細節為例,看看應該如何針對這個競品細節進行研究。

通過對比雪球與知乎兩個社區針對評論內容的設計,我們發現一個現象:

雪球把回復內容也作為評論內容的一種,在信息層級上,兩者是平級的,按照同一個展示規則(最新/熱度)依次展示對應內容。不過由于回復內容與評論內容的上文場景是不一樣的,回復內容的上文場景是被回復的內容,而評論內容的上文場景是被評論的帖子。因此被評論貼在下,需要針對回復內容補充上文場景,帶上被回復內容,讓用戶更容易理解回復內容意思。

而知乎把回復內容作為評論內容的補充,在信息層級上,回復內容屬于評論內容的下一層級,并且出現多個回復內容時,會折疊掉剩余回復。

產品設計之九陽神功

“社區評論容器設計的差異”

3. 為什么會有這樣的差異呢?

題發生的場景

雪球社區大部分活躍內容都比較輕量,類似于微信朋友圈說說,字數不會很多,使用路徑更發散,從A到B再到C…

問題的影響

回復內容與評論內容兩者在信息層級上齊平,更有利于這種發散式使用路徑。

產品設計之九陽神功

“雪球使用場景特征”

問題發生的場景

相比于雪球,知乎社區內容更聚焦,以話題的形式聚合了很多相關的內容,使用路徑相比之下更聚焦,用戶更一般比較關系A話題,不太會去發散B、C之類的。

問題的影響

將回復內容通過評論內容收起,更有利于用戶聚焦關心的A話題。

產品設計之九陽神功

“知乎使用場景特征”

九陽神功第三式:抽象問題

1. 抽象的目的,讓我們更容易發現規律

圖中統計了某項關鍵指標在上線前后兩周的數據情況(數據說明:圖中數據為筆者虛構,非真實項目數據)

左邊是未抽象的數據結果,紅色放大部分表示上線時間節點那天該關鍵指標的表現。我們很難從這張圖上看出上線后一周,該指標到底有沒有比上線前表現要好,乍一看上去,幾乎沒什么變化。

右邊是我們通過折線圖這種數據可視化的方式,將該指標上線前后兩周的數據結果抽象了出來。通過對比上線前后兩周的峰谷值,我們發現上線后該關鍵指標正在突破上線前一周的上軌。

產品設計之九陽神功

“未抽象結果與抽象后結果比較”

這個案例告訴我們:“選擇合適的可視化的方式對研究的問題結果進行抽象,可以幫助我們發現結果背后的規律或尋找到結果背后的機會”。

2. 有哪些抽象方法:用戶畫像、體驗地圖

通過用戶畫像將第二式過程中研究的問題按照一定的線索串聯起來,抽象成一兩個關鍵點,并形成產品設計過程中輔助我們進行UCD決策的依據,最終能讓我們更聚焦自己的服務。

某社交應用構建的用戶畫像,如圖所示主要包含4部分內容:

產品設計之九陽神功

“某生活服務類網站的用戶畫像”

1. 她(他)是誰:叫什么名字、做什么的?

  • Chsirtina是一個自由平面設計師;
  • Maria是一個新聞編輯;
  • James是一個高級工程師。

2. 他們有哪些可以被滿足的價值主張:針對我們服務的領域,用戶的態度是什么樣子的?有哪些相關的場景或特征?

  • Christina:生活也應該是一個創造性的過程;有些錢,雖然不是非常多;白天整個時間幾乎都在努力工作,包括屬于她自己的時間;走路是Christina全天的主要活動方式。
  • Maria:我想永遠保持身心健康,比較熱衷健康概念;會使用一些常用的信息軟件尋找每日活動;比較享受社交組織活動。
  • James:我非常清楚我現在正在做什么,我非常愿意嘗試新事物,非常愿意在這方面付費;喜歡網上和別人聊天;知道健康非常重要。

3. 用戶基礎屬性信息主要包括:年齡、居住地址、教育水平、職業、生活狀況(和室友住在一起?結婚了?單身?)、興趣愛好、最喜歡看的電視、性格。

4. 用戶目標:用戶用這個是為了干什么?

Chsirtina使用這個網站是為了:

  • 晚上,給她一個出門活動活動的理由;
  • 晚上,更方便她了解自己的周圍環境;
  • 晚上,可以找到更安全的地方;
  • 晚上,晚上可以和朋友拓展更多的社交活動。

Maria使用這個網站是為了:

  • 方便朋友聚一聚;
  • 晚上,可以找到安全的步行路線;
  • 通過更多的信息,可以獲得一種安全感;
  • 找到可能感興趣的社交活動參加;
  • 通過行走獲得更多身心的放松。

James使用這個網站是為了:

  • 跟進移動互聯網的最新趨勢;
  • 將更多的時間投入在行走,并取代其他運動方式;
  • 通過這個軟件可以認識一些新的朋友;
  • 晚上步行,感覺很自由;
  • 可以研究這種新的社交方式;
  • 感受一種社交方法并且能獲得一種安全感。

如果說用戶畫像通過一兩個點,幫助我們聚焦自己的服務范圍,那么體驗地圖就是關于這些點的運動軌跡,幫助我們從全局視角去有重點地輸出我們服務內容。

產品設計之九陽神功

“體驗地圖框架”

如圖所示,一個完整的體驗地圖框架應該包含以下幾個部分:

區域A:用戶體驗地圖的描述范圍

Q1. 用戶畫像:她(他)是誰?

Q2. 使用場景:她(他)要干什么?目的是什么?

區域B:可視化體驗過程

Q3. 體驗過程:她(他)要干的這件事可以分為幾個部分?

Q4. 用戶行為:不同部分下對應的具體行為有哪些?

Q5. 用戶想法:不同部分下用戶有什么痛點與訴求?

Q6. 情緒曲線:不同行為下用戶的情緒如何:消極的?中性的?積極的?為了更好地說明情緒,我們可以將調研過程中的視頻、圖片、訪談語音、訪談記錄貼在對應曲線附近。

區域C:機會分析

Q7. 機會點:針對不同部分下用戶的體驗情況,我們有哪些機會;

Q8. 業務輸出重點:針對不同部分下的機會,我們的業務輸出重點是什么?

3. 從用戶畫像到體驗地圖的應用實踐

圖中是劉津老師《從無中生有到快速迭代 產品不同階段設計方法及策略》中關于用戶畫像、體驗地圖的應用案例。

產品設計之九陽神功

“網易保健品商場用戶診斷”

用戶畫像:

我們從用戶畫像4要素對案例中的用戶畫像進行分析:

Q1. 她(他)是誰:叫什么名字、做什么的?

A1. 趙成,投資行業

Q2. 他們有哪些可以被滿足的價值主張:針對我們服務的領域,有哪些相關的場景或特征?

A2. 網購經驗和類型較豐富,主要使用淘寶、京東、1號店

Q3. 用戶基礎屬性信息主要包括:

A3. 男 35歲, 家庭成員包括太太、兒子和雙方父母

體驗地圖:

同理,我們從體驗地圖的8個要點分析案例中的體驗地圖

區域B:可視化體驗過程

Q1. 體驗過程:她(他)要干的這件事可以分為幾個部分?

A1. 可以分為三個部分,分別是:關注健康、學習了解保健知識、購買保健產品。

Q2. 用戶行為:不同部分下對應的具體行為有哪些?

A2. 三個部分對應的具體行為為:

  1. 關注健康,緊急的時候去醫院,平時的時候關注保健;
  2. 學習了解保健知識,通過書籍自主學習,通過網絡廣告、自主搜索、健康論壇等網絡工具了解保健知識,通過電視廣告、健康類節目等電視工具了解保健知識,通過鄰居、同事、家人等口碑方式傳播了解保健知識;
  3. 購買保健產品,在醫院購買,在藥店購買,網購,國外代購。

Q3-1. 用戶想法:不同部分下用戶有什么痛點?

A3-1. 三個部分對應的痛點與訴求分別為:

  1. 關注健康過程中,隨著年齡增大,健康問題越來越嚴重;
  2. 學習了解保健知識過程中發現專業知識晦澀難懂,網絡知識魚龍混雜,營銷廣告難辨真假,口碑傳播無科學依據;
  3. 購買保健產品過程中,醫院排隊麻煩,掛號難,怕假貨、副作用,不會結合身體對癥下藥,擔心吃了無效果。

Q3-2. 用戶想法:不同部分下用戶有什么訴求?

A3-2. 希望對癥下藥,為家人購買合適的保健產品(理性消費、目標明確);關注保健品功效、有無副作用、適用人群、成分、品牌、價格。

區域C:機會分析

Q8. 業務輸出重點:針對不同部分下的機會,我們的業務輸出重點是什么?

A8. 針對上述痛點與訴求,我們可以重點做的有:提供個性化推薦內容,提供對比功能方便選擇,提供個性化導購服務,突出用戶關注的內容。

關于體驗地圖的更多實踐:

產品設計之九陽神功

“某考研APP的用戶診斷”

產品設計之九陽神功

“某智能互動牙刷的體驗故事”

九陽神功第四式:共創問題

第三式中,我們把研究的結果通過用戶畫像與體驗地圖抽象出一個生動的故事,接下來該該如何把這些故事應用到產品設計中呢?

要點1:善于借助團隊智慧

君子性非異也,善假于物也,產品設計中最好的“物”就是團隊。

然而,現實生活中,我見過太多,因為不擅長借助團隊,而導致把功能做出問題的故事了:

  • 新人因為不了解規則,也不敢去問,擅做決策,導致功能上線后出現了問題;
  • 需求上游太過親力親為,過度干涉自己本不擅長的事情,又聽不得團隊的聲音,最終把產品做成了自己的玩具;
  • 需求階段,缺乏討論環節,需求評審簡化成技術評審,等方案開發出來,大家意見才開始來“這這不行、那那不太好”,最后受限于Deadline,只能先上,美其名曰“1.0”,并自我安慰道“我們2.0繼續優化”,現實是沒有下文了。

前三式中我們雖然對問題已經有了非常深刻的理解,按照慣性,我們習慣獨自憋大招,畢竟這樣直接、簡單。但正如我們上面列舉的因為不擅長借助團隊而導致把功能做出問題的故事,單個人的力量是非常有限的,我們必須承認這個事實。

為了更好的結果,這時我們需要借助團隊的力量,幫助我們一起尋找解決方案,這樣做的好處是:

  • 我們可以跳出自己的思維定勢,從別人是視角更加客觀地看待自己的問題;
  • 獲得意想不到的觀點,補充我們之前沒有看到的盲區;
  • 達成共識,避免開發階段頻繁變更需求;
  • 打破各業務線壁壘,充分發揮團隊成員創造性,新人融入更快,團隊成員參與積極性更高。

要點2:做足準備,避免在團隊心目中失去信任

諾曼說過,在我還沒想到解決方案前,我一般是不會提問題的;當然實際工作中雖然不需要我們一定得想出解決方案才能提問題,但至少這個問題我們已經搞清楚了,確定了這確實是個問題。

講個關于沒準備好,就匆匆提問題的故事:

周六在工作群里看到一個測試小哥在幾百人的大群里@產品,質問某個行情指標為什么沒數據!周六休市哪來的行情?連基本的常識都不了解,就去在刷存在感,這和狼來的故事有啥區別?

通過這個故事讓我們更加看到前三式過程中關于問題研究的重要性,它們是我們后續心法的基礎,不得馬虎,必須仔細、細心,否則第四步必定走火入魔,重演“狼來了的故事”,在團隊心目中失去信任。

要點3:除了意識層面,我們還需要一個關于共創問題的機制

為了保證共創問題的機制能夠正常并且持續運轉,我們需要把共創問題建立成團隊機制,規定每個星期有一個團隊成員擔任共創問題機制的主持人,主要職責,在會議當天把前三式過程中研究的結果分享給大家,并做好會議記錄。

產品設計之九陽神功

“每周的共創問題會議”

通過每周的共創問題機制可以幫助我們確定下個迭代的方向,保證需求是在一個正常、可持續的軌道上產生。

光憑這一點,我們就應該認識到建立一個共創問題的機制是有多么必要:對于產品最羞恥的事情,莫過于被開發追問,這一期我們做什么呀,你需求還沒提給我啊。

現實工作中我們正是因為缺乏這一機制導致我們需求管理一團糟,習慣被動接受事情,不擅長主動尋找事情,一旦沒有人告訴我們該做什么時,就開始迷糊了。

為了讓我們與需求之間的關系更正常一點,我們需要問題共創這一環節,并且為了保證該環節能夠持續運轉下去,我們需要在團隊內建立這一制度。

九陽神功第五式:落地問題

1. 落地遠比想法重要的真正含義:我們更應該關注前四式,讓第五式水到渠成

我們經常說:“落地遠比想法重要”并不是指第五式落地環節要比前四式問題研究要重要;相反我們更應該關注前四式過程中的問題研究。

只有抱著扎實的標準去做好前四式事情,第五式才能水到渠成,否則就容易出現我們工作中的各種不靠譜、天馬行空。最終因為種種現實,要么被扼在想法里、要么被閹割成一個雷聲大雨點小的不倫不類功能。

通過第四式過程中的問題共創,我們已經大致明確具體該怎么做了,剩下就是如何把這些文字版的解決方案轉化為用戶可交互的方案了。

2. 如何設計一套合理流程:我不成魔,誰成魔?

要想設計好一套比較合理的流程之前,我們必須成為這套流程里的大魔王。即這個過程中我們應該把主要精力放在如何成為大魔王的訓練當中,而不是把精力浪費在設計執行中;如果用百分數去描述的話,我們應該將90%的精力花在大魔王訓練當中,剩下的10%才是具體的設計執行。

但現實當中,我們卻容易將其本末倒置,畢竟成為大魔王看上去太浪費時間了,而方案又是有具體的deadline的;受限這樣的時間壓力,我們往往會選擇看似的捷徑——設計執行,寧可在那無限期磨,至少這能帶來短期的安全感。

我遇到一些在合理流程方面落地能力很強的人,我發現他們的一個共性就是自己也是這套流程里的骨灰級用戶。

我也遇到過很多落地能力比較弱的同學,我發現他們的一個共性就是離業務太遠;我還發現這類同學并沒有意識到自己離業務太遠的這個問題,反而覺得自己設計專業度還不夠。于是過度追崇學術界那些高大上的理論:“XXX行為模型”、“XXX體驗層次”,試圖把這些模型套在自己的工作思考上。

作為一個過來人可以負責任的說:“醒醒吧,那都是烏托邦的,千萬別被那些模型禁錮住你原本有的問題分析能力”。

面試過程比較傾向對問題本身有深刻理解的候選人,而不是搬弄模型的人。

所以別害了自己,多去走近業務,在業務當中解決問題,久之我們也可以總結出屬于自己的方法,而不是依賴于套用別人方法,不管合不合適。

考你一下:

Q:帳號注冊流程當中如果發現手機號已經注冊了,該怎么辦?

A:讓用戶返回登錄,因為這個帳號已經注冊過程,走登錄流程,如果不記得密碼,直接找回密碼就行了。

這個回答看似合理,但卻少考慮一種業務場景:我這個手機號自己沒注冊過,只是因為某些原因導致之前注冊過,比如這個手機號在被運營商回收前,前機主注冊過、被其他同學注冊過。

這個場景下走登錄流程會很奇怪,因為用戶之前沒有注冊過,合理的流程應該是繼續走注冊流程。

綜合第一個回答,這里合理的邏輯應該是:當發現手機號已經注冊,提供一個彈窗,詢問用戶這個昵稱(顯示最后一個字,其他的加密,保護用戶隱私)是否是用戶之前的帳號,如果是就走登錄流程,如果不是就繼續走注冊流程。

產品設計之九陽神功

“注冊流程”

這個案例告訴我們,要想設計一個合理的流程,必須深入業務,而非追求什么高大上方法。

在我看來,目前市面上的很多設計方法已經演變成一種玄學或彰顯自己很專業的素材,我覺得這不是一個好現象,給真正想要學知識的同學增加了分辨的難度,甚至帶偏。

但無論怎樣,我們一定要謹記,要說“人話”,千萬別把自己整成僅會講概念的“孔乙己”,至少我不希望你變成那個樣子,真的。

3. 如何設計合理的頁面原型:堅持每天的設計細節積累

設計一個合理的頁面原型,道理其實很簡單:我們考慮到了用戶的使用場景,并能基于該場景下的目標,完成原型內一系列細節設計的決策,方便用戶完成目標。

找到用戶的使用場景、了解用戶的使用目標不難,難的是我們如何找到合適的設計細節,并能與使用場景、用戶目標串起來。

我們看到太多因為細節沒串好,帶來的糟糕的體驗:

微信刪除聊天列表時,會直接把我們與該好友的聊天記錄也刪了,而Messenger在刪除的時候,會提供前饋信息“刪除與XXX的聊天后,這個聊天會從你這端永久刪除”,讓用戶決定到底是想要刪除還是僅是隱藏聊天列表。

相比與Messenger,微信刪除聊天列表的細節就沒有串好,用戶原本可能只是想隱藏這個list,結果整刪除了。

產品設計之九陽神功

“刪除聊天列表中的list”

微信轉賬過程中,當輸入金額達到千位時,輸入框下方會顯示數量級角標,幫助用戶確認轉賬金額是否正確;而支付寶轉賬場景下卻沒有串聯該細節,這就導致用戶一旦沒注意,就容易轉錯,畢竟產生失誤最常見的原因就是注意力不集中,而該下意識場景下又沒有幫助用戶確認的反饋信息。

產品設計之九陽神功

“轉賬細節”

4. 如何在場景中串聯細節呢?

1)請堅持每天的設計細節打卡

為什么我會發起每天設計細節打卡,雖然分析方法是一樣的,看上去好像在重復一件很傻的事情,但好的細節積累多了,會潛移默化地提升自己,更容易產出好方案。與一個星期前相比,積累設計細節給我做方案,帶來一個明顯的變化就是,思路比之前開闊多了。

產品設計之九陽神功

“每天積累一個設計細節”

2)發現并描述細節:以圖文或視頻的形式將發現的設計細節表達出來

這個過程主要是為了提升我們的表達能力,怎樣讓對方輕松理解我們在講什么,特別是在方案評審會上,千萬別連自己的方案都講不清,那就顯得太不專業了,誰還信任把事情交給我們做。

其次,在溝通過程中,隨著我們表達能力的提升,理解其他人想法的能力自然也會隨之提升。面試場景下的很多問題,我們其實并不是不會,而是沒理解別人的意思,或曲解了別人想要表達的想法,這就導致我們在一個死胡同里琢磨著怎么出去,事實也很清楚,我們就是琢磨到天荒地老,也出不去。

3)分析設計細節:通過根本原因分析法,分析上述細節背后的隱含的深層原因

根本原因分析的目的是確定問題現象背后隱含的深層原因,而不是直接原因(淺層原因)。

日本長期以來遵循一定的流程,他們叫這個步驟“五個為什么”,由Sakichi Toyoda最早提出來,為了提高質量,豐田汽車公司將“五個為什么”作為豐田生產系統的一部分。現今,它已被廣泛應用于各行各業。

基本上,它意味著在尋找原因時,即使你找到了一個,不要停下來,要問問為什么是這個原因;然后再一次詢問為什么;繼續問,直到你發現真正的、隱藏的原因。

難道要正好詢問五次嗎?

不一定,但使用“五個為什么”步驟,強調即使已經找到一個原因,還要繼續深入探究。下圖是F-22的事故分析中應用的“根本原因分析方法”。

產品設計之九陽神功

“根本原因法:五個為什么”

設計細節中的因果關系是怎樣的呢?

因為好的體驗細節觸動了用戶,用戶下次還愿意來互動;因為好的體驗細節方便了用戶使用,用戶在眾多競品中選擇了我們。

因為糟糕的體驗細節導致用戶很反感,用戶下次再也不來了;因為糟糕的體驗細節影響了用戶使用,用戶在眾多競品中優先拋棄了我們。

產品設計之九陽神功

“從體驗細節到用戶因素”

根本原因分析法在設計細節分析中的應用:從用戶因素角度分析當前設計細節

問題1:你覺得上述細節好嗎?

回答1:好/不好

問題2:好在哪里?

回答2:方便了用戶使用/增加了使用動機

問題3:它是怎么方便了使用/增加使用動機的?

回答3:用設計原理嘗試解釋該問題,首先,這個過程用最簡練、最直白的話表述出來即可,這樣做的好處是方便我們管理這些細節,因為簡練才容易記住,因為直白才便于加深理解,等我們過個階段再來看時,還是能夠快速理解;其次要客觀,保持一顆同理心,千萬不要陷入自我表達,過度分析的危害很大,其中最致命的就是讓我們越來越角色化,一個簡單的細節應用都會被很多條條框框所限制,具體在工作或面試中的癥狀表現為“太學術,落地性差”

產品設計之九陽神功

“根本原因法在分析設計中的應用:三個為什么”

設計細節打卡示范:

打卡任務描述:

產品設計之九陽神功

“設計細節的打卡任務”

優秀打卡案例:

產品設計之九陽神功

“優秀打卡案例”

5. 遵守設計規范,提升執行效率、保證設計質量的穩定產出

建立規范的目的是沉淀設計經驗,下次再遇到時,直接復用即可,而無需從0到1再走一遍。

這樣做的好處除了可以幫助我們提升設計執行效率之外,還可以保證設計質量的穩定產出,不至于哪天因為突發的外在因素,導致產出低水準方案的情況。

如何建立規范呢?我們可以通過Brad Frost的原子理論(Atomic Design)將設計規范拆解成5個設計系統層次,分別為:原子(Atoms)、分子(Molecules)、有機體(Organisms)、原型(Templates)、頁面(Pages)。

產品設計之九陽神功

“設計系統的五個層次”

原子(Atoms)

產品設計之九陽神功

“原子(Atoms)”

如果原子是物質的基本組成部分,那么我們界面的原子就可以作為構成我們所有用戶界面的基礎組成部分。這些原子包括基本的HTML元素,例如表單標簽、輸入、按鈕和其他無法進一步再分解的元素。

如圖所示,原子包括基本的HTML元素,例如輸入,文字標簽和按鈕等。

產品設計之九陽神功

“原子案例”

分子(Molecules)

產品設計之九陽神功

“分子(Molecules)”

在化學中,分子是鍵合在一起的原子團,具有獨特的新特性。例如,即使水分子和過氧化氫分子由相同的原子元素(氫和氧)組成,它們也具有獨特的性能并且行為也大不相同。

在界面中,分子是相對簡單的UI元素組,它們一起作為一個單元起作用。例如,表單標簽、搜索輸入和按鈕可以連接在一起以創建搜索表單分子。

如圖所示,搜索形式分子由標簽原子、輸入原子和按鈕原子組成。

產品設計之九陽神功

“分子案例:搜索表單”

有機體(Organisms)

產品設計之九陽神功

“有機體(Organisms)”

有機體是由分子和/或原子和/或其他有機體組成的相對復雜的UI組件,這些有機體組成界面的不同部分。

如圖所示,導航有機體由logo原子、主導航分子、搜索表單分子組合而成:

產品設計之九陽神功

“有機體案例:導航”

原型(Templates)

產品設計之九陽神功

“原型(Templates)”

現在,是時候和化學比喻說再見了。雖然原子、分子以及有機體等化學語言為我們有目的構建設計系統的組成部分提供了一個非常有用的層次結構,但是最終我們還是得針對用戶輸出合適、有意義的語言。

原型是頁面級對象,可將組件放置在布局中并清楚顯示設計的基礎內容結構。我們可以將前面示例中的導航有機體應用于首頁原型中。

如圖所示,首頁原型由應用于布局中的有機體與分子組成:

產品設計之九陽神功

“原型案例:首頁”

原型的另一個重要特征是它們專注于頁面的基礎內容結構,而不是頁面的最終內容。

設計系統必須考慮內容的動態性質,因此闡明組件的重要屬性(例如標題和文本段落的圖像大小和字符長度)非常有有意義。

通過定義頁面的框架,我們可以創建一個可以說明各種動態內容的系統,與此同時,可以為各種構成特定設計模式的內容類型規劃所需的區域。例如,Time Inc.的主頁模板顯示了一些關鍵組件,同時還演示了有關圖像大小和字符長度的內容結構:

產品設計之九陽神功

“TimeInc.原型的頁面框架定義”

頁面(Pages)

產品設計之九陽神功

“頁面(Pages)”

頁面是原型的特定實例,這些原型顯示了填充實際典型內容后的UI外觀,因此我們可以將主頁原型放入實際內容的代表性文本,圖像和媒體。

如圖所示,頁面階段將占位符內容替換為真實數據內容,以使用戶界面栩栩如生。

產品設計之九陽神功

“頁面案例:首頁”

除了向用戶展示最終界面,頁面對于測試基礎設計系統的有效性也非常重要。在頁面階段,將真實內容應用于設計系統時,這些所有的模式是否會有問題,如果有問題,就需要修改分子、有機體和原型從而更好地滿足內容的需求。

當我們將真正的代表性內容填入Time Inc.的首頁原型中時,就可以檢驗所有這些底層設計模式是否存在有問題。

如圖所示,在頁面階段,我們可以看到填入真實代表性內容后的Time Inc.主頁是什么樣子。有了實際的內容之后,可以檢查組成頁面的UI組件是否契合了填入的內容。

產品設計之九陽神功

“頁面案例:TimeInc”

從原子到頁面的實踐:Instagram

產品設計之九陽神功

“從原子到頁面的實踐:Instagram”

  • 原子:該頁的Instagram UI由少量圖標、一些文本級元素和兩種圖像類型組成(主要圖像和用戶的頭像);
  • 分子:幾個圖標構成簡單的實用組件,例如底部的導航欄和照片操作欄,用戶可以通過照片操作欄喜歡或評論照片;同樣,該頁分子中還有些文本和/或圖像的簡單組合形成相對簡單的組件;
  • 有機體:在這里我們可以看到照片有機體由用戶的信息、時間戳、照片、圍繞該照片的動作以及有關照片的信息(包括喜歡數量和內容標題)組成。這種有機體反復地堆疊在用戶生成的照片流中,成為整個Instagram體驗的基石;
  • 原型:我們可以看到組件在布局環境中融合在一起。此外,Instagram體驗的公開內容框架中突出顯示動態內容,例如用戶的信息條,頭像,照片,被喜歡次數和標題;
  • 頁面:最后,我們看到了一個注入了真實內容的Instagram UI。

從原子到頁面的實踐精髓:從設計規范到用戶界面

養兵千日,用兵一時,維護設計規范就相當于日常養兵,養兵千日的最終目的還是為了最后戰場上的一戰,而高效地產出高水準的用戶界面就是我們日常維護設計規范的目的。

產品設計之九陽神功

“從設計規范到用戶界面”

圖中序號以及連線展示了我們該如何將文字版的想法落地成用戶界面:

  1. 首先,需要理清我們要設計哪些內容,以及這些內容對應的承載容器是否可以復用設計規范里現有的;
  2. 其次,假如可以直接復用,那我們就可以將更多的精力用在原型布局與頁面細節設計當中了;
  3. 再者,假如不能直接復用,我們就需要思考每個容器對應的組件構成有哪些,是否可以直接復用底層設計庫中已有的組件。如果可以,我們再次節省了組件設計的精力,從而能夠將更多的精力留在原型與頁面設計中;如果不可以,也沒關系,更新我們的UI資源,為下次復用提供可能;
  4. 圖中圈的大小代表我們應該花費的精力,圈越大,預示著該環節所應花費的精力越多。如圖中所示,確保我們能夠將更多的精力用在原型與頁面設計當中。
  5. 最后,如果我們是Mac系統,可以借助Sketch的創建組件的功能,將基礎設計系統錄進去,形成我們的設計語言,這樣做的好處是:可以方便我們快速搭建出原型;團隊協同過程中保持產出的一致性。

產品設計之九陽神功

“借助Sketch創建我們的設計語言”

當然如果我們想要把這樣的設計語言與項目連接的更加緊密,還需要把前端同學也拉進來,把這樣的設計語言轉化為前端代碼,從工程角度讓設計語言融入的更深,提升我們項目開發效率與質量。

如圖所示,螞蟻金服把可視化組件這類的分子語言轉化為前端代碼:

產品設計之九陽神功

“AntV設計語言對應的前端代碼”

九陽神功第六式:跟進問題

1. 選擇讓自己更可靠的產出方式

人是不可靠的,要多借助工具讓自己更可靠一點。某次版本迭代中,因為太相信自己的力量,忽視了產出方式的重要性,導致跟進過程中項目失控、延期。

這件事對我打擊很大,也逼迫我去尋找能夠讓自己變得更靠譜的工具,經過一年多的實踐,我總結了兩套非常實用的產出方式:需求規格描述文檔、將交互方案上傳只可實時更新的地方。

1)需求規格描述文檔

建一座大廈前,為了保證大廈能夠按照圖紙建造下去,我們需要一份詳細的工程說明,把圖紙中涉及的每個細節執行下去。

把需求比作大廈,為了保證需求能夠按照設計稿開發下去,我們同樣需要一份詳細的需求規格說明,把設計稿中涉及的每個細節執行下去。

這就是需求規格描述文檔在問題跟進環節中的意義,通過該文檔,我們可以清楚地知道每個細節的執行程度 ,從而讓我們有重點地跟進,直到方案的完美交付。

這里推薦使用Google docs制作我們的需求規格描述文檔:

  • 由于它是在線協作類工具,團隊協同性非常好;
  • 文檔自帶的關鍵詞查詢功能可以便于我們快速定位對應的細節描述,不至于因為過了一星期別人再問某某細節時,發現自己也記不得了,也不知道從哪里找了;
  • 相比與騰訊文檔等其他競品,Google docs編輯自由度要好很多,沒有那么多限制。

具體制作過程中,我們需要對需求內容進行拆解,拆解的目的:

  • 避免遺漏細節,就算遺漏也知道可以在哪里補充;
  • 通過需求內容的上下游,快速定位需求細節,從而方便需求的管理與跟進。

我們將一個需求內容拆解為5個字段,對其進行描述,分別是:

  1. 需求所屬模塊,比如某個需求屬于首頁模塊;
  2. 需求名稱;
  3. 需求list,比如發語音這個需求對應的需求list有:開啟語音、發送語音、取消發送語音、語音發送失敗;
  4. 每個需求list對應的前置條件,比如取消發送語音對應的前置條件為:手勢上滑到高度Y、手勢未上滑到高度Y、松手;
  5. 每個前置條件對應的規則,比如當用戶手勢上滑到高度Y語音氣泡有藍色變成紅色。

產品設計之九陽神功

“需求規格描述文檔(Google docs)”

除了開發過程中的跟進之外,該文檔還有個非常重要的作用:驗收環節中給我們提供了明確的Check List,我們只需要按照文檔中的細節一條條驗收即可,這可比憑感覺驗收要省心、靠譜的多了,所以我將第5項字段又稱為“驗收細節”。

2)將需求文檔上傳至可實時更新的地方

我們必須承認一個事實,即使在開發環節,方案細節變動的可能性還是很高的,可能是做的過程中發現某個細節當時沒考慮到或該細節當時考慮的不合理。

如果沒有一個可以實時更新的地方,意味著我們的每次改動都需要重新走一遍方案提交的流程,上傳這、上傳那,還要一個個去通知:“我方案更新啦,下載最新的哈,把之前下載的刪了吧。”

繁瑣的提交流程還給我們維護文檔帶來了很多心理障礙,導致我們不敢面對問題,具體表現為:方案提交了,就不想再看了,遇到問題口頭溝通就完事了,最后項目有哪些細節自己也不記得了,項目又再次失控了。

除了這個繁瑣的提交流程之外,我們還得面臨著方案未更新到位的風險,畢竟我們也無法確保:通知了,其他人就真的刪掉之前下載的,使用最新下載的。

有可能他還在用舊的,只是因為一時拖延癥,后面就忘記了。最后這個鍋還是我們的,誰叫我們在開發環節還在改細節呢。

制作原型過程中沒有工具的使用限制,我們可以用筆,也可以用Sketch、XD、PS、Excel等軟件,選擇我們最習慣且效率最高的工具即可。

但最終將原型按照一定的邏輯整理成一份詳細且易讀的交互文檔時,就不能像原型階段那樣放飛自我了,選擇什么樣的工具以及輸出什么樣的形式可是有講究的。

產品設計之九陽神功

“交互方案的產出形式”

對比很多工具后發現Axure的目錄功能還是很強大的,它清晰地展示了文檔的脈絡結構,非常方便閱讀。尤其是針對比較復雜的功能,選擇Axure作為文檔輸出工具再合適不過了。

產品設計之九陽神功

“Axure的目錄功能”

其次,為了方便文檔的更新維護,我們最好把文檔輸出成網頁形式,本地修改完,網頁直接更新,保證其他人看到的一定是我們最新更新的,這一點Axure也完美地支持了我們這一操作:

在菜單“Team”中選擇第一個選項“Creat Team Project from Current File”,只要一直點OK就行了;最后我們成功創建了一個團隊版的Axure文件,如紅框內所示,每個目錄的右邊都會有個藍色的點。

產品設計之九陽神功

“將本地Axure文件轉化為團隊版”

如何找到團隊版文件發布的網頁地址呢?

點擊右邊菜單中的“Share”,點擊后選擇第三個選項“Publish to Axure Share”,此時會彈出一個面板,我們可以點擊紅框內的“Copy”,將網頁地址復制粘貼到瀏覽器里,查看文檔的詳細內容。

產品設計之九陽神功

“找到團隊版文件發布的網頁地址”

如圖所示,我們現在就可以在該網址下瀏覽方案內容了:

產品設計之九陽神功

“團隊文件共享網址”

右鍵想要變更的目錄,選擇“Check Out”,或者點擊想要變更頁面右上角中的“Check Out”面板,編輯當前目錄下的內容。

產品設計之九陽神功

“更新文檔”

Check Out狀態下目錄右邊小圓圈會變成綠色:

產品設計之九陽神功

“Check Out狀態下的目錄”

編輯完成后,我們需要右鍵選中“Check In”將變更的內容提交上去:

產品設計之九陽神功

“Check In以變更內容”

刷新以下網頁,我們可以發現,當前內容也同步更新了:

產品設計之九陽神功

“內容已同步更新在網頁上了”

2. 幫助開發一起尋找解決方案

雖然我們大部分產品/設計并不懂技術,但這不影響我們幫助開發一起尋找解決辦法。如果只是因為開發一句:“這個做不了”,就砍掉這個功能,那最后得到的結果一定是差的,給別人的印象就是“標準太低”,別人也會因此不信任我們,更不放心把東西交給我們做。

根據我的磨合經驗,大部分的“這個東西做不了”其實只是個紙老虎,而我們恰恰因為對于未知的恐懼不敢去捅破它。

開發說的做不了,其實并不是指這個功能做不了,而是某個實現技術比較麻煩、復雜甚至確實做不了;這時我們應該了解開發的難點,在不影響目標實現的基礎上尋找可能的妥協空間,避開開發難點。

舉個例子,在做對話改版過程中我們發現結果頁很長,經常超出兩屏以外,這個不良細節導致答案看起來非常費勁,不知道從何看起,一堆答案:

產品設計之九陽神功

“改版前現狀”

于是我們希望通過簡化結果頁答案信息,讓對話內容看起來沒那么費勁。我們對結果頁容器做了一個規則:精煉出一個結果頁組件,如果用戶想要繼續了解,則通過點擊查看更多到落地頁去看。

產品設計之九陽神功

“解決方案1.0”

解決方案1.0遇到的開發難點:落地頁是前端新寫的,前端需要將原落地頁里面的數據傳進來,這個過程涉及很多鉤子函數,一旦沒協議好,就會出現新落地頁渲染不出來的情況。

問題是我們很難窮舉出所有的情況,自測環節依然出現新落地頁打不開的情況,因為這個問題,導致改版遲遲上不了線。

后來我們轉化了思路:控制結果頁容器高度,不超過有效屏幕的2/3, 超過部分自動折疊;如果用戶想要繼續了解,則通過點擊余下內容展開剩余答案。這個思路讓我們避開了新落地頁,并同樣起到了簡化結果頁答案信息的作用。

產品設計之九陽神功

“解決方案2.0”

九陽神功第七式:量化問題

1. 行不行?把數據拿出來練練

一次分享會上,有同學和我說了一個關于數據的看法:“數據給人的感覺更偏理性,比較適用于流程性的功能/業務設計,而對于那種需要付諸情感與創意的藝術設計,理性的數據好像不太適用,甚至有點與藝術設計本身有點脫節,藝術是個人意志的表達,我只需要關注我的工匠精神有沒有得到充分的表達,細節有沒有做透,而數據和我好像有點遠哈。”

其實這個想法是錯誤的,無論我們在做什么設計,必須建立一個認知:任何設計行為都可以被量化,如果量化不了,只能說明我們做的這件事還沒有目標,或者把這件事當成個人玩具在做了。

沒有目標的設計過程是非常糟心的,很容易被別人噴,盡管我們可能不服,覺得這個意見很傻,但就是說服不了,憑啥你說的就對,大家互相不服。

如果這個意見是來自一個需求上游,我們可能連不服的資格都沒有,只能自我安慰道:“畢竟這只是一份工作,何必那么較真呢。”

相比于做事沒有目標,把事情當成個人玩具做的危害更大,從結果層面,不僅會失敗,還會給團隊營造一種獨斷、官僚的風氣。迷之自信只是因為我們身在井底,但這不能成為我們獨斷專行的理由。

既然已經在井底,就應該多傾聽井外的聲音,抱著謙遜的態度去了解真相,而非下屬都是傻子、同事都是傻子,只有我的感覺最專業,我不要你覺得,我只要我覺得。

因此這兩個故事給我們一個啟發:

  • 任何時候要用數據說話,別總是我覺得,我有“我覺得”、他有“他覺得”、你有“你覺得”,到底聽誰的?比誰的職位高嗎?比誰吵的過誰嗎?我們應該讓數據去說話,行不行?把數據拿出來秀一下;
  • 要想學會用數據說話,我們必須要有目標,我為什么要做這件事,把開屏頁設計的好看一點目的是吸引更多的人點進來,所以我的目標是點擊uv至少要達到多少人才說明我這開屏頁設計的確實可以。

講一個用數據說話的案例:以哈啰助力車臨時鎖車不良細節為例,我們該如何將數據融入到我們的產品設計與決策的語言當中

1)問題描述

騎車途中,臨時有事,需要把車臨時停一下,點了臨時鎖車,頁面切換為如下狀態:

產品設計之九陽神功

“支付寶小程序哈啰單車:臨時鎖車”

辦完事回來,不假思索地點擊了“還車”,而不是“解鎖騎行”,導致每次點擊解鎖騎行都需要刻意思考一下。

2)數據分析

我們為了確定這確實是用戶的問題,而不僅僅是我的問題,需要看一下解鎖場景下的誤觸率如何?

誤觸率定義:解鎖場景下,點擊還車的有多少人。

指標計算:點擊還車uv|(用戶類型=點擊了臨時鎖車) / 點擊了臨時鎖車的uv。

如果發現臨時鎖車場景下的誤觸率確實很高(我們自己可以定一個高的標準,比如我們認為超過5%就很高了),我們再去想解決方案。

能不能把鎖車狀態下的頁面中的“解鎖騎行”與“還車”調換一下順序,方便該場景下的解鎖操作,從而降低誤觸率。方案上線后,我們對比一下上線前的誤觸率,看是否有提升?

2. 需要一份便于維護的埋點文檔

和需求規格描述文檔類似,為了讓我們在數據分析階段更可靠一點,我們還需要一份便于維護的埋點文檔。如圖所示,一個埋點文檔至少應該包含3個部分:埋點字段、文檔說明、埋點內容。

產品設計之九陽神功

“埋點文檔(Google docs)”

1)埋點字段

為了更全面地描述埋點內容,我們可以從5個方面對其進行描述:

  1. 事件類型(Event),如“注冊相關的事件”;
  2. 觸發行為(Triggered),如在“注冊相關的事件”中當用戶資料不完整,簽到時觸發了補充資料頁;
  3. 行為變量(Parameters),如在補充資料頁行為當中涉及的變量有用戶的操作類型(user_action)以及是否是首次觸發(if_first_time);
  4. 變量值(Values),如在補充資料頁當中的變量user_action的值有編輯(edit)與跳過(skip);
  5. 版本(Version),備注每個埋點當前的版本,便于后期增刪改查。

產品設計之九陽神功

“埋點字段”

2)文檔說明

隨著每次版本的迭代,我們可能增加了新功能、修改了已有功能或刪掉了之前功能,這就要求我們的埋點文檔也要隨之更新。

哪些是因為增加了新功能而需要新增的埋點?哪些是因為修改了已有功能而需要改動之前的點?那些是因為刪掉了之前功能而需要刪除的點?

用不同的字色與色塊去區分這些埋點類型說明,方便團隊其他成員查閱與理解。文檔說明中最后一項“通用值”指的是事件類型,如“注冊相關的事件”。

產品設計之九陽神功

“文檔說明”

3)埋點內容

根據前面提到的做事目標,反推我們需要哪些埋點,然后把這些點按照埋點字段錄進文檔內。最后對接好負責埋點的開發,將這些點埋進我們的程序中。

九陽神功第八式:檢驗問題

1. 數據指標的5種類型

有了埋點數據之后,需要通過一些公式構建指標與埋點數據之間的關系,從而得到我們想要的指標數值。目前常用的指標類型有:

  1. 事件型,比如一共發起了多少a行為,對應關系:pv(a);
  2. 去重型,比如有多少人發起過a行為,對應關系:uv(a);
  3. 比率型,比如事件x中發起過a行為的比率是多少,對應關系:pv(a)/pv(x);
  4. 人均型,比如平均每個人發起過多少a行為,對應關系:pv(a)/uv(a);
  5. 節點轉化型,比如普通用戶(a)到會員用戶(b)的轉化效率,對應關系:uv(a)/uv(b)

一個小思考

如圖所示,在對話改版中我們確定的目標是“提升用戶與機器人互動意愿”,指標意義是“用戶觸發了一次答案后,還會不會繼續往下互動”,對應的計算方式是“uv(一句以上的用戶數)/uv(總用戶數)”。

同學們可以思考一下,“用戶與機器人互動意愿”屬于數據指標5中類型中的哪一種?

產品設計之九陽神功

“改版背景”

2. 定義北極星指標面板:設計迭代的燈塔

產品設計是一個持續迭代的過程,指望一次性把事情做成很難,我們只能在這個過程中反復發現問題、解決問題,最終才可能蟄伏出一個優秀的東西。

然而現實是,我們很多產品和設計師做完某個功能后就沒下文了,過段時間做了另外一個功能,之后又沒下文了。就這樣,日復一日,年復一年,看似干了很多事情,但卻沒有一件有結果。

我比較喜歡梁寧老師的一句話“求之于勢,不責于人”,意思就是,出了問題,不要一味去指責人不行,而是應該多借助外部力量給團隊賦能,打贏一場仗的關鍵并不是士兵努不努力,而是陣法與策略。

因此,無法持續迭代的問題關鍵并不是某個產品或設計師不夠努力、不夠有責任心,而是產品設計流程出現了問題:我們忽視了燈塔的重要性,導致這個過程中很難以終為始,畢竟我連自己在哪都不知道,更別提要通過什么樣的計劃去什么終點了。

如何在這個過程中建立我們的燈塔呢?

如圖所示,是關于某游戲戰斗平衡模塊的北極星指標面板,通過這個面板,我們每天都可以檢查自己所負責模塊目前處在一個什么樣的水平、距離目標終點還有多遠、針對這個差距,我們還可以做哪些試錯。

產品設計之九陽神功

“某游戲戰斗平衡模塊的北極星指標面板”

九陽神功第九式:復盤問題

1. 成長量變于實踐、質變于復盤

一直以來,在如何提升產品設計能力的問題上,我們可能存在個誤區:看書可以提升產品設計能力、博覽產品設計理論/方法可以提升產品設計能力。

因為這個誤區導致我們很多人正在努力地做“邯鄲學步”的事情:作品集里套些空洞的理論與模型,面試過程中一旦深究,立馬嗝屁;做需求關心的不是用戶,而是某個理論,到底是在做產品還是在寫本自己的書,傻傻分不清楚。

如果上訴情況有我們的影子,狠狠地掐自己一下,讓自己清醒清醒:指望看書、博覽產品設計理論/方法提升產品設計能力是絕對不可能的。

成長的唯一方式只有多在工作中實踐;看書、報班、聽講座等等學習方式只是一種復盤手段,而復盤的前提是我們有一定的實踐。

所以我們看書的過程其實是在尋找與作者共鳴的點,作者幫我們總結了之前的實踐并形成了經驗;但這個過程,如果我們沒有相似的實踐經歷,只是努力學習作者的方法,并試圖套在工作中,那就又邯鄲學步了。

如果這樣,我們再掐自己一下,把書放下,去尋找更多的實踐,等有一天真的有點共鳴了,說明我們已經在成長了,之前的實踐終于質變了!

2. 多停下來,回頭看看

工作中發現很多人并沒有停下來復盤的習慣,把自己當成一個機器一樣不停的做,但就是看不到終點,最后的結局就是大家都累死了,團隊卒,項目黃。

前往目標地的路上必然會遭遇很多沙塵暴,雖然迷眼,但指望閉著眼一條線走過去幾乎不可能,適當停下來,睜眼看看,有沒有走錯方向。

項目迭代階段,通過北極星指標面板復盤本次迭代有沒有達成目標:如果達成了,是因為我們做了哪些實踐,下次如何復用這些經驗;如果沒達成,是因為我們哪些環節沒做好,下個迭代中如何修正,再試一下。

如哈啰助力車誤觸率案例中,如果方案上線后,誤觸率沒有被有效降低,需要再從數據上追蹤用戶的使用行為,找出問題,再構思解決方案,以此循環,直至誤觸率被降下來。

有同學經常跟我說:“我不會總結,只會不停的做”。其實不是我們不會,而是缺乏復盤能力。如何建立并提升自己的復盤能力呢?

業余時間,建議大家多接觸些工作內容以外的新事物,比如周末下午去個咖啡廳看看書、上下班地鐵上刷刷文章、一個月更新一次作品集、半年參加一次講座等等。

我開始建立起復盤能力,是2015年實習那會兒,公司到住的地方需要1個半小時的地鐵,這意味著我每天有3個小時的閱讀時間,結合工作上的實踐,那段時間真的很充實。

總結

九陽神功圖譜

以一張圖譜來總結一下產品設計九陽功招式。該圖譜共有4個象限,從第3象限開始,N順序分別為:事實就是×問題、靈感創意×問題、實事求是×解決辦法、靈感創意×解決辦法

產品設計之九陽神功

“九陽神功象限圖譜”

  • 事實就是×問題:該象限要求我們在研究問題過程中一定要恪守“實事求是”原則,切忌先入為主;
  • 靈感創意×問題:該象限要求我們盡可能地發揮自己的主觀能動性,通過可視化方式,讓問題故事變得更栩栩如生;
  • 事實求是×解決辦法:該象限內我們開始造航天飛機了,它是個非常嚴謹且注重細節的過程:注意不要亂提些天馬行空、無法落地的想法,盡管可能確實很用戶體驗,但在我們還不了解當前實現原理以及當前階段的主要矛盾之前,這些想法可能就是搗亂。所以多去了解工程技術以及當前階段的主要目標,可以幫助我們提出些更靠譜的解決方案;
  • 靈感創意×解決辦法:如何發揮我們的主觀能動性,幫助團隊點亮燈塔,照亮團隊繼續朝著目標前行是該象限的使命。

把各象限內對應的招式補充進去,就是我們的九陽神功招式圖譜:

產品設計之九陽神功

“九陽神功招式圖譜”

九陽神功圖譜修煉精髓

我們可以把它當成產品設計實踐過程中的一本詞典,遇到不知道怎么做時,可以查閱一下當前處在九陽神功的哪一式;參照該招式的心法,結合具體的工作內容,進行產品設計實踐。

在應用產品設計方法時,也可以參照該字典,明確該方法處在哪一招式,從而幫助我們理解該方法的作用,更能靈活地使用該方法,而不再是生搬硬套。

參考資料:

1.Kate Kaplan.When and How to Create Customer Journey Maps.

2.劉津,從無中生有到快速迭代,產品不同階段設計方法及策略.

3.梁寧,產品思維30講-認清人的本性,理解角色化生存.

4.Donald Arthur Norman.the Design of Everyday Things: Human Error? No, Bad Design.

5.Brad Frost.Atomic Design.

#專欄作家#

UE小牛犢,微信公共號:交互實驗獅,人人都是產品經理專欄作家。關注產品思考、用戶體驗分析、交互研究,致力于UX方法論的探索和實踐。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 交互打卡的那個App是什么

    回復
  2. 給偉偉大佬打call!!

    回復
  3. 我能打你很牛皮的嘛,真的厲害 給點贊~~~

    回復
    1. 可以!你的鼓勵是我前行的動力!??

      回復
  4. 謝謝寫得這么詳細,圖文并茂有說服力

    回復
    1. 不客氣,有幫助就好

      回復
  5. dalao

    回復
  6. 詳實的內容,給大佬點贊

    回復
北京赛车投注