1. 產品經理誕生的背景和價值

1.1 產品經理誕生的背景

1.中國網際網路的發展：

a) 第一階段（1987——1998），探索和基礎設施建設階段

b) 第二階段（1999——2005），web1.0階段，即網際網路普及階段

c) 第三階段（2006——2011），web2.0階段，即網際網路快速增長和多元化整合發展階段

2.移動網際網路的發展：

a) 第一階段（2000——2002），中國移動網際網路的初級階段，文字資訊、圖案和鈴聲

b) 第二階段（2003——2005），WAP時期，以內容為主

c) 第三階段（2006——2008），互動娛樂時期，有功能性應用

d) 第四階段（2009——2011），SoLoMoCo，各種應用在手機上廣泛應用

1.2 產品經理的價值

1.產品是企業價值的載體，企業通過產品交換來實現商業價值，企業是否成功，很大程度上取決於產品是否優秀甚至卓越

2.產品經理是公司價值鏈中最重要的一個環節，是直接面向客戶、帶領團隊創造價值的領軍人物，一個成功的產品經理不但能引導產品的發生，而且能引導公司的發展

2. 產品經理的新視角

2.1 產品經理定義

1.產品經理是驅動和影響設計、技術、測試、運營和市場等人員推進產品生命週期的經理人

2.在產品生命週期的不同階段，驅動者是動態變化的：在研發期，產品是驅動者，產品上線之後，運營或業務部門是驅動者

3.產品經理分類：

 

2.2 產品經理是代孕媽媽

 

2.3 最牛的產品經理

主要體現在影響力、核心需求把控力、創新力和痴情力

2.4 產品經理的職責

1.明確產品的目標使用者群及其特徵

2.獲取、評估和管理使用者需求

3.完成產品需求文件、產品原型和流程圖

4.精通使用者體驗、互動設計和資訊架構技能

5.專案管理、需求變更管理和需求驗收

6.產品運營資料的分析和總結

7.提供運營、市場和銷售等支援

2.5 產品經理的能力

1.產品經理能力

 

2.6 產品經理常犯的錯誤

1.自我感覺良好

2.知其然，不知其所以然

3.老闆的話是聖旨

4.需求變更頻繁

5.不善於溝通

6.不重視需求文件和原型

7.為了做產品而做產品

8.專案管理混亂

9.不做計劃和總結

2.7 產品經理與專案經理的區別

1.產品經理重在策劃，做正確的事。其所策劃的產品是否符合使用者和市場的需求，是否解決了目標使用者的需求，評估哪些需求是否該做，科學定義需求優先順序，產品上市是否能給公司帶來商業價值，是否實現公司商業目標

2.專案經理重在執行，正確的做事。執行到位，在時間、成本和資源的約束條件下完成既定的目標

3. 產品經理的進階之道

3.1 產品經理十問

1.職業規劃是神馬？專業還是管理？

2.最缺的產品技能是什麼，如何彌補？

3.心目中的產品團隊應該是怎樣的？

4.做產品時最大的困惑或問題是什麼？

5.有做階段性計劃和總結的習慣嗎？

6.一個月看幾本書？都看哪方面的書？

7.曾經在同事面前做過技能或知識的分享嗎？

8.經常參加一些線上或線下產品經理活動嗎？

9.有研究產品並撰寫調研文章的習慣嗎？

10.有產品經理的氣場、影響力和說服力嗎？

3.2 產品經理道與術

寧願選擇一流的實施三流的想法，而不選擇一流的想法三流的實施

3.3 推薦書籍

1.人人都是產品經理 

2.結網 

3.就這麼做產品

4.贏在使用者

5.使用者體驗的要素

6.Don't make me think 

7.Designing web interfaces

8.互動設計精髓3.0

9.玩賺你的網站

10.觸動人心：設計優秀的iPhone應用

11.誰說菜鳥不會資料分析

12.資料探勘

13.產品經理手冊

14.產品經理的第二本書

4. 產品定義、型別、氣質和戰略戰術

4.1 產品定義和價值

1.產品是能夠提供給市場、供使用者使用或消費的、可滿足某種慾望和需要的任何東西，產品是滿足使用者需要的複雜利益的集合。

2.產品的五個要素：

a) 產品的內涵：為使用者提供的基本效用或利益，滿足使用者的本質需求——核心價值

b) 產品的形式：指實現產品的內涵所採取的方式，包括功能、內容、設計等——期望價值

c) 產品的外延：指使用者在使用或購買產品時所得到的附加服務或利益——附加價值

d) 產品的理念：產品的信念和宗旨——期望價值

e) 產品的終端：web、桌面客戶端、收集、平板電腦等——期望價值

3.使用者買的不是你做的產品，使用者買的是你做產品的信念和宗旨。

4.營銷學之父菲利普科特勒說：星巴克賣的不是咖啡，是休閒，是一種氛圍；法拉利賣的不是跑車，是一種近似瘋狂的駕駛快感和高貴；勞力士賣的不是表，是奢侈的感覺和自信；希爾頓賣的不是酒店，是舒適與安心；麥肯錫賣的不是資料，是權威與專業。

5.微創新：

a) 產品設計，從小處著眼，貼近使用者需求心理

b) 產品功能，一定要專注，不求大而全

c) 產品更新，小步快跑，不斷試錯

4.2 成功產品定義

能引導和創造使用者需求、創造或改變目標使用者生活方式、擁有良好使用者體驗、為企業帶來贏利、創造商業價值的產品

4.3 產品型別

1.主要產品型別：

a) 工具型

b) 媒體型

c) 社群型

d) 遊戲型

e) 平臺型

2.在產品市場格局中佔有一席之地的公司產品型別是一個動態發展的過程，單一形態的產品型別大都往多個形態的產品型別過渡和發展

a) 工具+媒體

b) 社群+平臺

c) 工具+平臺

d) 媒體+工具+社群+平臺

e) 平臺+社群

f) 遊戲+社群

g) 工具+社群+遊戲+媒體+平臺

4.4 產品氣質

產品的氣質來源於天賦、內功和外功的完美結合

4.5產品戰略和戰術

1.戰略就是計謀、謀略、計劃、打算等；戰術是按照戰略計劃的具體實施過程，即技術、技能、技巧

2.戰略分析

a) 行業分析

i. 確定行業規模（生存空間）

ii. 競爭者結構分析（併購）

iii. 與上游談判價格的能力（擴大規模）

iv. 與下游談判價格的能力（行業強）

v. 進入者分析（競爭壁壘）

vi. 替代品威脅

b) 產品選擇

c) 行業定位

d) 核心競爭力

3.預測行業發展趨勢：

a) 根據行業歷史

b) 逆向思維法

c) PEST分析法

4.產品戰略指的是產品的研發、運營、市場、銷售等全域性性規劃和策略

a) 觀念，即願景

b) 定位，做什麼產品，核心價值

i. 產品方向

ii. 產品型別

iii. 產品價值

c) 競爭，差異化、關鍵競爭要素，成本優勢

d) 模式，商業模式、贏利模式

e) 規劃，指產品研發、上市、運營推廣的路線圖

i. 波士頓BCG矩陣評估與分析：放棄瘦狗、捉住金牛、維持明星、投資問題

ii. 麥肯錫三層面法：吃著碗裡的，看著鍋裡的，瞄著田裡的

1. 企業大部分利潤來源的核心業務

2. 有增長潛能的正在崛起的業務

3. 未來長遠發展選擇的業務

5.阿里巴巴——商人的網站，小企業做生意的地方；iPhone——移動瀏覽器及“殺手級”的觸控式螢幕介面；Facebook——真正使用的社交網路；Pandora——超級簡單的個性化電臺；twitter——所有人不到一分鐘就能寫微博；flipboard——social magazine；zite——personalized magazine；知乎——一個真實的網路回答社群，幫助你尋找答案，分享知識；點點——收集、整理、分享你的興趣愛好

6.產品線（Product Line）指一群密切相關的產品，這些產品功能相近，使用者群與渠道類同

7.產品事件中，關於產品組合管理的資源投入，按7:2:1的投入比例進行

5. 商業需求文件

5.1 專案背景

1.商業需求文件主要包括：

a) 專案背景，闡述為什麼做

b) 專案時機，為什麼是現在做

c) 專案規劃，闡述怎麼做

d) 專案的收益、成本、風險及對策，闡述專案預期的收益，需要花費哪些成本，專案面對的各種風險及可能的應對之策

2.產品提案：

a) 既有產品提案：指的是已經上線運營一段時間後的產品，出具資料運營報告，分析當前產品存在的突出問題，亟需解決

b) 創先產品提案：全新的產品或者是在既有的產品的基礎上衍生出來的新產品，出具相關的調研報告

i. 使用者調研

1. 目標使用者

2. 使用者細分（麥肯錫八法細分使用者）

3. 使用者特點（人口統計資訊、性格、愛好、需求特徵等）

4. 使用者行為（頻率、習慣、消費等）

5. 使用者核心需求

6. 使用者場景（使用者如何使用，在什麼地方、什麼時間使用）

ii. 市場調研

1. 國內外這個產品領域的市場現狀

2. 市場規模、行業發展趨勢

3. 行業調研報告

iii. 競爭對手

1. 標杆競爭對手、競爭對手產品佔有的市場份額

2. 競爭對手的主要優勢

3. 產品差異化策略

3.麥肯錫八法細分使用者：

 

4.提案目標：

a) 吸引、留住使用者，提高KPI

b) 系統或技術、產品架構調整

c) 拓展新業務市場、佔領細分市場份額

d) 運營、市場、銷售支撐等

5.商業價值：

a) 增加收入，提高市場佔有率，創造營收

b) 提高使用者基數和粘度

c) 市場造勢，提升品牌價值

d) 產品差異化，抑制並擊敗競爭對手

5.2 專案時機

合適的時間，合適的人做合適的事

5.3 專案規劃

1.核心功能點：用一句話概括核心功能點

2.產品架構圖：

a) 資料庫層

b) 資料服務層

c) 應用層

d) 表現層

e) 使用者層

3.階段規劃：每個階段應該完成哪些主要功能，要達到什麼樣的目標

4.主要功能規劃：產品主要有哪些功能模組，對主要功能進行描述

5.產品路線圖

5.4 商業模式

1.商業模式越簡單越好

2.商業模式：

a) 廣告模式

b) 會員服務

c) 遊戲模式

d) 收入分成

e) 增值服務

5.5 收益、成本、風險及對策

1.收益預估：包括收入、使用者、品牌、降低成本、投入/產出比等

2.產品定價策略：

a) 新產品定價策略：

i. 高定價：

1. 優點：短期內取得較大利潤，競爭時採取降價，可限制競爭者加入，符合消費者從高到低的心理

2. 缺點：不利於開啟市場

3. 適合品牌價值和產品質量比較高以及在業界指定了行業規範掌握話語權的企業

ii. 低定價：

1. 優點：迅速開啟產品銷路

2. 缺點：投資回收期太長，且價格變動餘地小

iii. 中定價：

1. 優點：價格穩定，贏利目標可按期實現

2. 缺點：比較保守，不適合競爭激烈的市場環境

b) 心理定價策略：

i. 尾數定價（零頭定價）：適用於基本生活用品

ii. 聲望定價（整數定價）：適用於價格交規的耐用品或禮品，以及消費者不太瞭解的產品

iii. 招徠定價（特價定價）

iv. 系列定價（分級定價）

v. 吉祥數定價

vi. 習慣定價

c) 折扣定價策略：

i. 數量折扣

1. 累計數量折扣：鼓勵顧客經常向本企業購買，成為可信賴的長期顧客

2. 一次性數量折扣：鼓勵顧客大批量購買，促進產品多銷、快銷

ii. 現金折扣/提前支付折扣：鼓勵顧客儘早付款，加速資金週轉，降低銷售費用，減少財務風險

1. 折扣比例

2. 給予折扣的時間限制

3. 付清全部貨款的期限

iii. 功能折扣/交易折扣

iv. 季節折扣/季節差價

d) 差別定價策略：

i. 使用者群體

ii. 產品功能

iii. 季節時間

iv. 地理位置

3.產品定價方法：

a) 成本導向定價法：

i. 成本加成法：單位產品價格=單位產品成本*（1+加成率）

ii. 目標利潤法：單位商品價格=總成本*（1+目標利潤率）/預計銷量

iii. 編輯成本法：單位產品價格=（總的變動成本+邊際貢獻）/預計銷售；邊際貢獻=預計銷售輸入-總的變動成本，使用於產品供過於求，賣方競爭激烈的情況

b) 需求差異定價法：

i. 因地點而異

ii. 因時間而異

iii. 因商品而異

iv. 因顧客而異

c) 競爭導向定價法

i. 隨行就市法

ii. 差異定價法

4.成本預估：

a) 人力成本預估

b) 非人力成本預估

5.風險：

a) 政策風險

b) 技術風險

c) 法律風險

d) 市場風險

e) 決策風險

f) 資本風險

6.風險對策：

a) 規避：技術風險

b) 轉移：決策風險

c) 緩解：市場風險、資本風險

d) 接受：政策風險、法律風險

6. 市場需求文件

6.1 使用者描述

1.使用者描述：

a) 目標使用者群

b) 使用者需求痛處

c) 使用者特徵

d) 使用者動機

e) 使用者角色建模

2.馬斯洛需要層次擴充套件：

 

3.使用者角色建模：

a) 使用者角色定義

b) 使用者角色價值

i. 專注使用者

1. 不可能建立一個適合所有人的網站

2. 不為1%的需求騷擾99%的使用者

ii. 引起共鳴

iii. 統一意見

iv. 創造效率

v. 提升決策質量

c) 使用者角色建立步驟

i. 發現使用者

1. 問題：目標使用者是誰？使用者規模有多大？他們的主要行為有哪些？

2. 方法：定量資料收集

3. 輸出：調研報告

4. 資料來源：面對面訪談、觀察法、二手資訊、調查問卷、行業調研報告

ii. 提供背景

1. 問題：使用者之間的差異有哪些？

2. 方法：檢視材料，將使用者群標記分組

3. 輸出：目標使用者群概述文件

iii. 證實驗證

1. 問題：使用者角色資訊（喜歡/不喜歡，內在需求，價值觀）、環境資訊（工作場所、工作條件）、場景資訊（工作策略和目標、資訊策略和目標）

2. 方法：定性資料收集

3. 輸出：調研報告

iv. 聚類使用者

1. 問題：是否抓住了主要使用者群？還需要考慮其他的使用者群嗎？這些使用者群是否同等重要？

2. 方法：聚類分類

3. 輸出：使用者群分類描述

v. 建立使用者角色

1. 問題：基本資訊（姓名、性別、照片）、性格（內向、外向）、背景（職業）、對待技術的情緒與態度、個性特徵等

2. 方法：聚類分類

3. 輸出：使用者群分類描述

vi. 定義情境

1. 問題：使用者角色的需求是什麼？是在什麼樣的情境下產生的？

2. 方法：尋找情境及其產生的需求

3. 輸出：需求和情境的分類

vii. 驗證和認可

1. 問題：你知道其他人喜歡這個使用者角色嗎？

2. 方法：知道使用者角色的相關人員閱讀使用者角色資訊並就此發表意見和反饋

viii. 統一認識

1. 問題：我們如何將使用者角色資訊分享給團隊的相關人員？

2. 方法：組織會議、傳送電子郵件、舉辦活動等

ix. 建立場景

1. 問題：在設定的情境中，既定的目標下，使用者使用技術的時候會發生什麼

2. 方法：敘述式指令碼，使用使用者角色描述和情境形成場景

3. 輸出：場景、用例、需求規格說明書

x. 更新使用者角色資訊

1. 問題：使用者角色資訊發生變化了嗎

2. 方法：可用性測試、新使用者資料

3. 輸出：專人負責更新使用者角色資訊

4.使用者場景指使用者在什麼時間、什麼地點使用或消費產品

6.2 市場描述

1.佔比加權法估算：

a) （5~7個主流品牌銷售額之和）/權重數=市場總容量約數，權重數基本為幾大品牌市場佔有率之和

b) 區域越小，資料越準確

c) 適用於成熟產品進入成熟市場

2.核心精算估算：

a) 儘量將容易失真的部分控制在營銷策略中無關緊要的部分

b) 操作過程可控制，信度和效果都很好，調查的規模適中

c) 適用於消費時間、場所相對集中的產品

3.替代品類比法估算：

a) 根據產品功能上的代替性，列出最近的4種產品，計算著4種產品的容量，接著分別乘以替代率，然後相加得出平均值

b) 能夠比較準確的反映市場狀況，並與營銷策略關係極大

c) 適用於新類別產品

4.統計調查法估算：

a) 市場需求容量=區域市場總人口數*區域人口品均收入*區域人口中目標人群的佔比*目標人群購買同類別產品的支出比例

b) 潛在市場容量=潛在購買率（城市或農村的調查值）*人口數*自然變動因素（人口增長等）*人口社會變動因素（人口城市化等）

c) 邏輯性強，精度可控制，對市場整體把握性強，但成本較高，規模較大，操作熱暖的專業性要求高

d) 適用於鋪市面廣、銷售點分散、消費時間分散的產品

5.歷史資料分析法估算：

a) （N為年份）

b) 精度不高

c) 適用於已經在區域市場比較成熟的產品

6.3 需求描述

1.需求描述即闡述需求點，包括功能需求和非功能需求及其優先順序

2.非功能需求：

a) 安全需求

b) 效能需求

c) 相容性需求

d) 資料統計需求

e) 幫助需求

f) 財務需求

g) 法律需求

h) 運營需求

i) UI需求

6.4 產品規劃案例

7. 需求分析與管理

7.1 需求定義

在使用者購買力既定的前提下，需求就是使用者想要的、能夠解決問題或達到目標的慾望集合

7.2 需求本質

需求的本質：名望、權利、利益

7.3 需求分類

1.娛樂休閒

2.歸屬感

3.溝通

4.意見領袖

5.利益

a) 啟用產品的超級影響者：1%規則：只有1%的粉絲會對品牌進行社會化的傳播和分享

b) 將最好的內容預留給超級影響者

c) 利用好部落格和論壇

d) 區分一般影響者和超級影響者

6.獲取知識和資訊

7.自我情感表達

8.愛和被愛

9.社交

10.分享

11.安全

12.尊重

7.4 需求與產品

產品包括兩塊：功能和內容

7.5 獲取需求

1.獲取需求的主要方法：

a) 行業調研分析報告、業內專家、資深專業人士

b) 定性的使用者訪談

c) 定量與定性結合的調查問卷

d) 運營資料分析

e) 將自己變成目標使用者

2.一對一使用者深度訪談：

a) 確定訪談目的

b) 選準訪談物件

c) 營造良好的訪談氛圍

d) 訪談流程要有策略

e) 驗證使用者真實需求

f) 記錄使用者訪談成果

3.焦點小組訪談：

a) 訪談前的準備工作

i. 明確訪談的目的，要解決什麼問題，需要驗證哪些問題

ii. 訪談物件的甄選，新使用者、中度使用者、老使用者各佔相同比例

iii. 確定訪談的時間、地點、人數、獎勵措施以及訪談參與人

iv. 細化訪談的問題指令碼，整理出我們需要訪談的核心問題列表，形成文件

b) 訪談中執行工作：整個過程儘量避免訪談物件的回答出現比例失衡，記錄下訪談回答的核心觀點

c) 訪談後整理工作

4.日記分析法

5.調查問卷：

a) 調研流程：

i. 定義問題，明確調研目標

ii. 確定調研設計方案

iii. 設計調查問卷

iv. 確定抽樣方案、樣本容量

v. 收集資料

vi. 分析資料

vii. 撰寫調研報告

viii. 後期跟進

b) 調查問卷設計流程：

i. 闡明調查問卷的目的

ii. 確定資料收集的方式

iii. 確定問卷答案格式

iv. 問題的措辭

v. 問卷的流程與佈局

vi. 評估問卷的流程和佈局

vii. 測試並修正

viii. 實施

6.需求採集表

7.6 評估需求 

1.KANO模型：

a) 基本型需求：

i. 可以消除使用者的不滿，不能增加使用者滿意度

b) 期望型需求：

i. 若得到滿足或表現良好，增加使用者滿意度；得不到滿足或表現不好，不滿也會顯著增加

c) 興奮型需求：

i. 當特性不充足時，並且無關緊要的特性，則使用者無所謂；當產品提供了這類需求中的服務時，使用者對產品非常滿意，提高使用者的忠誠度

2.KANO需求歸類矩陣

 M代表Must-have，基本型需求；L代表Linear，期望型需求；E代表Exciter，興奮型需求；R代表Reverse，相反的需求；Q代表Questionable，可疑的結果；I代表Indifferent，無關緊要

 

3.做減法：

a) 根據產品定位

b) 根據產品價值

c) 根據產品場景

d) 根據產品迭代

7.7 需求優先順序定義

先做重要且緊急的需求，後做重要不緊急的需求，接著做緊急不重要的需求，最後做不緊急不重要的需求

7.8 管理需求

需求管理表

 

8. 產品需求文件

8.1 產品需求文件內容

1.MECE是mutually exclusive 和collectively exhaustive，相互獨立，完全窮盡

2.版本號格式：主版本號.子版本號[修正版本號[.編譯版本號]]

3.專案初版時，版本號為1.0或1.00；當專案在進行了區域性修改或BUG修正時，主要版本號和子版本號都不變，修正版本號加1；當專案在原有的基礎上增加了部分功能時，主版本號不變，子版本號加1，修正版本號復位為0；當專案在進行了重大修改或區域性修正累計較多，而導致專案整體發生全域性變化時，主版本號加1

4.內容包含：

a) 版本號和修訂歷史

b) 名詞術語定義

c) 功能需求總表

d) 流程圖、順序圖、活動圖

e) 功能需求詳細描述

f) 非功能需求

g) 文件的更新和維護

5.UML（unified modeling language）有用例圖（use case diagram）、類圖（class diagram）、物件圖（object diagram）、順序圖（sequence diagram）、協作圖（collaboration diagram）、狀態圖（state chart diagram）、活動圖（activity diagram）、構件圖（component diagram）、部署圖（deployment diagram）

8.2 產品原型

1.產品原型設計就是將產品的概念細化成為可見的產品具體形態

2.常用工具：紙質、word、excel、ppt、visio、photoshop、uidesigner、axure rp pro、mockup

8.3 頁面互動圖

8.4 需求文件質量評估標準

1.正確性

2.可行性

3.必要性

4.優先順序

5.明確性

6.可證實

7.完整性

8.一致性

9. 使用者體驗

9.1 使用者體驗的必要性

使用者體驗（user experience）關注的是使用者怎麼使用產品，使用者解決問題、完成任務、達到目標之後的滿意度如何

9.2 使用者體驗的層次

使用者體驗層次從低到高：有用——能用——可用——用的爽——品牌

9.3 使用者體驗的要素

 

9.4 使用者體驗的分類

1.感官體驗：

a) 設計風格潮流：清新、簡約、簡潔、精簡，更有人情味與趣味的設計風格已經逐漸成為趨勢和潮流

b) 產品LOGO衝擊力：

i. 合乎時代潮流

ii. 強烈的視覺形式感和高度藝術性

iii. 易於識別和記憶

iv. 具有高度的概括力

v. 符合行業特徵

vi. 具有現代感

vii. 簡潔、生動、形象

viii. 具有擴充套件性，為重大事件節日專門設計

ix. 信賴度很高

x. 給人親切、和藹的感覺

c) 產品執行速度快且穩定安全

d) 頁面佈局合理

e) 頁面色彩統一

f) 圖片、音樂和視訊質量高

2.互動體驗：

a) 導航

b) 搜尋

c) 任務流

d) 主次

e) 直接

f) 統一

g) 少做

h) 反饋

i) 對稱

j) 簡潔

3.情感體驗：

a) 尊重

b) 驚喜

c) 親和

d) 滿意

e) 共鳴

f) 細緻

4.價值體驗：

a) 核心價值

b) 期望價值

c) 附加價值

5.信任體驗：

a) Footer

b) 隱私保護

c) 權威推薦

d) 成功案例

9.5 使用者體驗的度量

網站轉化率（conversion rate）是指使用者進行了相應目標行動的訪問次數與總訪問次數的比率

9.6如何提高使用者體驗

1.新手上路提示

2.適當引導使用者

3.貫穿生命週期

4.超出使用者預期

5.正確對待反饋

6.可用性測試

7.資料分析和挖掘

8.多用和多研究

10. 使用者體驗設計

10.1 概念設計

概念設計要描述出使用者的整體任務有哪些，各個任務節點之間的關係和關聯如何

10.2 資訊架構

資訊架構（information architecture），主體物件是資訊；重點關注的是如何將資訊傳達給使用者，使使用者在較短時間內找到需要的資訊，主要關注資訊的結構粒度、組織方式、歸類以及展現形式

1.組織系統：如何組織資訊

2.標籤系統：如何表示資訊

3.導航系統：如何瀏覽資訊

a) 全域性導航

b) 區域導航

c) 情境導航

d) 輔助性導航

e) 定製化導航

4.搜尋系統：如何搜尋資訊

5.可擴充套件性

10.3 互動設計

1.場景設計

2.任務分解

3.任務流互動：

a) 基於流程的互動：以使用者目標位導向進行設計，注意區分新手、專家、和中度使用者對任務流的熟悉程度，根據使用者的使用場景，揣摩實現模型和心智模型

b) 基於介面的互動：

i. 主次原則：到底放什麼，取決於要重點引導使用者操作的功能和通過資料分析得出的功能相結合

ii. 直接原則

iii. 統一原則：保持統一，降低使用者的認知難度和操作成本

iv. 少做原則：儘量準確把握使用者的心理預期，揣摩使用者的心智模型，進而實現使用者的心理預期

v. 反饋原則：儘量對每個操作能做到人機互動反饋，讓使用者清楚自己目前的狀態，減少疑惑，有時候還能起到引導使用者操作的目的

vi. 對稱原則：原始狀態-使用者操作-使用者取消操作-恢復到原始狀態，給使用者反悔的機會，提高使用者操作的容錯性

vii. 簡潔原則：為使用者著想，文案簡潔易懂，具有自我解釋性和引導性，符合語言表達習慣。幫助使用者診斷、識別和恢復錯誤，告訴使用者大概的原因和解決辦法，做適時的提醒

10.4 視覺設計

1.避免視覺噪聲

2.主次、對比、相似性、分層

3.視覺流：

a) 對角線對稱

b) 垂直軸對稱

c) 從左到右，從上到下

4.配色和排版：

a) 顏色搭配：主色調+輔助色最好不超過三種，有層次感

b) 顏色引導使用者

c) 排版：分割、區塊和強調

5.風格一致

11. 可用性測試

11.1 可用性測試的必要性

11.2 可用性測試的方法

1.卡片分類法：

a) 用於研究 使用者如何理解和組織資訊

b) 方法：將資訊（概念、條目、內容、小分類）寫在一張張卡片上，然後歸類

c) 分為開放式卡片分類法（opened card-sorting）和關閉式卡片分類法（closed card-sorting）

2.錄屏攝像

3.眼動跟蹤

4.A/B可用性測試

5.運營資料

6.可用性測試工具：userfly、clicktale、crazy egg、usabilla、feedback army、five second test、intuitionhq、user reel、navflow、adduse、notebox、user testing、fenggui、silverback、concept feedback、clixpy、user echo、upshot、kissinsights、verify

11.3 可用性測試的流程

1.準備階段：

a) 明確可用性測試的目的

b) 安排可用性測試的日期和時間

c) 選擇可用性測試方法

d) 確定可用性測試物件：

i. 招募什麼樣的人

ii. 招募人數

iii. 如何招募

iv. 指定測試任務清單

v. 確定相關參與人

vi. 確定供測試用的產品物件

vii. 準備測試裝置和地點

viii. 指定可用性測試議程

ix. 預測試

2.實施階段：

a) 原則：

i. 儘量不要打斷使用者的操作

ii. 儘量讓使用者獨立完成

iii. 測試環境和場景人物應當儘量符合使用者使用產品的真實環境

iv. 充分尊重和鼓勵使用者，給使用者正面反饋

b) 主持人：

i. 說明本次測試的產品、測試的目的、測試的大致步驟以及可能花費的時間

ii. 宣佈測試議程，包括歡迎詞、開場白

iii. 對於測試相關的解釋說明，建議使用者邊做邊說

iv. 請求使用者簽署保密協議，說明任務，測試物件提問，測試總結

c) 記錄員：主要負責記錄使用者在執行每項任務時做了什麼，說了什麼，碰到什麼問題

d) 觀察員：負責使用者執行每項任務時填充任務場景、使用者操作的步驟等

3.總結階段：

a) 收集資料進行分析

b) 定義問題優先順序

c) 列舉問題清單：

i. 問題名稱

ii. 問題優先順序

iii. 問題描述

iv. 原因分析

v. 解決方案

12. UED團隊

12.1 團隊組建

1.團隊負責人

2.使用者研究員

3.視覺設計師

4.互動設計師

5.前端工程師

6.文案工程師

12.2 工作流程

 

13. 產品流程

13.1 策劃階段（Plan）

1.主要工作與交付物

2.需求達到的預期KPI

3.需求說明會

13.2 執行階段（Do）

1.設計階段

2.開發階段

3.測試階段

4.上線準備階段

13.3 檢驗階段（Watch）

1.資料檢驗階段

2.策劃會議階段

14. Scrum敏捷開發

14.1 Scrum敏捷開發介紹

1.開發宣言：

a) 個體和互動勝過過程和工具

b) 可用的軟體勝過完備的文件

c) 客戶合作勝過合同談判

d) 響應變化勝過遵循計劃

2.敏捷開發原則：

a) 最先要做的是通過儘早、持續地交付有價值的軟體或產品來使使用者滿意

b) 即使到了開發後期，也歡迎改變需求

c) 經常交付可以工作的軟體，交付時間間隔越短越好

d) 在整個專案開發期間，業務人員和開發人員必須天天一起工作

e) 圍繞被激勵起來的個人構建專案

f) 在團隊內部，最具有效果且富有效率的傳遞資訊的方法是面對面的交談

g) 工作的軟體或產品是首要的進度度量標準

h) 敏捷過程提倡平穩的開發節奏，發起人、開發者和使用者應能保持一個長期、恆定的開發速度

i) 不斷地關注優秀的技能和好的設計會增強敏捷能力

j) 簡單化是根本（不做過度設計和預測）

k) 最好的架構、需求和設計出自於自組織的團隊

l) 團隊會定期對前一個迭代進行反省總結，以便調整自己的行為，提高開發效率

14.2 Scrum敏捷開發流程

1.三個角色：

a) 產品負責人（product owner）

i. 制定產品戰略、規劃、使用者調研、進行需求分析和評估等，評估決定做哪些功能後，出具產品backlog，確定產品的功能

ii. 決定釋出的日期和釋出內容，給迭代定下目標

iii. 為產品的利潤負責，尋求投資回報率最大化

iv. 根據ROI（商業價值/工作量）確定功能優先順序，必要時可將風險考慮在內

v. 指定sprint 計劃，每個sprint開始前，根據實際情況調整功能和優先順序

vi. 驗收開發質量，接受或拒絕接受開發團隊的工作成果

b) 專案的直接管理者（scrum master）

i. 領導團隊實踐scrum，協助產品負責人實現專案利益相關人的價值最大化

ii. 確保團隊能勝任工作並保持高生產率

iii. 保證各個角色及職責的良好協作

iv. 解決團隊開發中的障礙

v. 作為團隊與外部的介面人，遮蔽外界對成員的干擾

vi. 保證開發過程按計劃進行，組織每日立會、sprint 評審和sprint計劃會議

c) 團隊（team）：5~9人

i. 團隊要跨職能（包括開發人員、測試人員、UED等）

ii. 團隊成員儘可能保證全職

iii. 盡全力確保達到sprint目標

iv. 高度的自我組織和管理能力

v. 向產品負責人演示產品功能，接收產品負責人對產品功能的驗收

vi. 團隊穩定，在sprint之間調整成員，團隊成員的構成在sprint內不允許變化

2.四個會議：

a) Sprint會議：應考慮到團隊的接受力、開發的速度、技術水平和商業條件

i. 制定sprint目標

1. 分析和評估產品負責人提供的產品backlog

2. 哪些產品backlog被選中應該放到這個sprint來實現

3. 什麼時間出具潛在的可交付物，達到什麼樣的目標

4. 團隊的接受力怎麼樣

ii. 建立sprint backlog

1. 考慮如何實現這個sprint目標，從產品backlog選中要實現的產品backlog

2. 進行任務拆分

3. 建立sprint backlog

4. 給sprint backlog的任務估算工作量（通常1-16小時）

b) 每日立會：每天早上上班開始，15分鐘左右

i. 昨天我完成了什麼工作

ii. 今天我打算做什麼

iii. 我在工作中遇到了什麼困難

iv. 每日立會不用於解決問題

v. 任務狀態包括：to do（要做的任務）、doing（正在做的任務）、tested（已經測試過的任務）、reviewed（通過驗收的任務）、finished（完成的任務）

c) Sprint評審會議：產品負責人評審和驗收團隊開發的產品功能

i. 回顧sprint策劃會議定下的sprint目標

ii. 團隊展示sprint中完成的功能，通過現在演示的方式展現功能和架構

iii. 產品負責人驗收產品功能是否與產品需求相符，根據驗收的結果，接受或拒絕團隊提交的可工作的產品功能

iv. 產品負責人根據驗收的結果，更新產品backlog

v. 團隊成員都要參加，可以邀請所有人產品

d) Sprint回顧會議：團隊定期進行自我檢視和反省，發現什麼是好的，什麼是不好的，需要什麼行動

i. 收集資訊，找到問題的根本原因，討論解決方法，制定行動方案

ii. 每個sprint都要做，一般控制在15-30分鐘

iii. 全體人員都要參加，專案管理者、產品負責人、團隊和可能的客戶或其他相關人員

3.三個物件：

a) 產品backlog

i. 一個排序的、估算的、漸進的需求列表

ii. 一般情況下，使用使用者故事來表示backlog條目

iii. 理想情況下，每個需求項都是對產品的客戶或使用者有價值

iv. Backlog條目按照商業價值排列優先順序，優先順序越高的條目越詳細

v. 優先順序由產品負責人排列

vi. 在每個sprint結束的時候要更新優先順序的排列

vii. 多團隊情況下，使用同一需求列表

viii. 確保下一個或兩個sprint的產品backlog條目是可行的

ix. 團隊需要花5%-10%的時間來做這件事情

x. 不育系產品負責人在沒有優化backlog之前進入sprint計劃會議

b) Sprint backlog

i. 要在sprint中完成的任務清單

ii. 能把產品backlog變成可用產品功能的任務

iii. 任務用小時估計，通常1-16小時

iv. 管理sprint的

相關推薦