用戶產品:敏捷體驗度量思考與實踐

2021-01-10 人人都是產品經理

編輯導讀:對於一些設計師來說,體驗度量方法已經不是一個新鮮的概念,但是真正運用到工作中還是存在很多問題。本文作者基於自身工作經驗,從一個新的角度介紹普適的體驗度量方法,與你分享。

關於體驗度量方法行業內案例已有一些,但普遍為較為全局,實施與結果輸出成本相對較高,對一些小團隊可能運用起來比較困難。

本文結合過往項目實際經驗,從一個新的角度介紹,相對敏捷且普遍適用的小團隊體驗度量方法,較為完整地還原了從構建,實施,驗證,最終成型的過程思考。體驗度量好像近些年來正在成為行業內的一種新的趨勢,希望這篇文章能對大家在體驗度量方面的工作有所啟發。

Ps: 文章少部分內容對設計圈內成熟的體驗度量經驗分享有所借鑑與參考,在此表示衷心的感謝。

隨著體驗設計行業和相關職業逐漸走向深耕,價值一詞被越來越多地提及。我們進行這次體驗設計度量實踐的原動力,某種意義上講,也是源於我們對於體驗設計價值的新的理解或者說一次新的嘗試。

長文預警,本文主要包含以下內容:

體驗設計價值理解什麼是體驗度量為什麼要做體驗度量及其重要性如何進行體驗度量全文要點總結

01 體驗設計價值的理解

這些年體驗設計價值越來越多的被提起及受到重視,但是大部分設計師或者從業者,普遍還是說不清楚感受不到,弄不明白體驗設計的價值到底是什麼?

我個人目前的理解是:用戶體驗設計與業務價值的強關聯,是其真正的價值體現。用戶體驗不是主觀的藝術,它有一套科學的、可度量的設計方法和策略。

體驗設計的價值是更好的實現產品價值、用戶價值、商業價值、社會價值的交付。也是基於這種理解以及對價值的追求,驅使我們進行了公司內信息流項目的體驗度量工作。

02 什麼是體驗度量

目前行業內好像還沒有特別明確的體驗度量的定義,在《用戶體驗度量》一書中,作者:Tom Tullis & Bill Albert 大概給出了如下定義:

「度量」是一種測量或評價特定現象或事物的方法(需建立在一套可靠的測量體系之上)。「用戶體驗度量」是建立在一套可靠的測量體系上: 使用同一類的測量手段對事物進行測量時,得到的結果是可以相互比較的,所有用戶體驗度量都是可觀測、可量化並以數字的形式表示出來的。

這個定義我個人覺得不是特別直觀易理解,我們可以提煉一下其中的關鍵詞:可靠的測量體系 ,可觀測的量化表達。基於這些關鍵詞,我嘗試給用戶體驗度量一個更直觀且易於理解的定義:

用戶體驗度量是: 通過一套可靠的測量體系 ,量化用戶體驗的過程是讓用戶體驗從「抽象」到「具象」的過程是使用戶體驗從「玄學」到「科學」的重要基礎是更好的實現體驗設計價值及體驗設計體系化的關鍵路徑

03 為什麼要做體驗度量

我想每個設計師職業生涯中普遍都會面臨一些趨於一致的「靈魂拷問&質疑&難以回答的問題」:

你們對產品指標有什麼貢獻?我覺得這個優化沒有競品的好?你怎麼證明你做的更好?你做了這麼多對產品有多大影響?我覺得你做這些沒有意義你們只關心美不美,浪費資源我們看著可不如就競品好為什麼會面臨這些「拷問&質疑&難以回答的問題」?

這個問題曾經其實也困擾了我很久,後來隨著工作時間漸長,自己更多的思考結合與業界各種大神之間靈魂的交流,可以嘗試解答一下這個問題。

原因主要有兩點:

大部分人其實並不知道用戶體驗具體是什麼,因為體驗是一種很主觀的東西,看不見也摸不著,但又確實能感受到它的存在,「一萬個人心中有一萬個阿姆雷特」。

用戶體驗這個命題非常大,設計範疇十分廣闊沒辦法單純地以「好用」和「不好用」作為簡單直接的衡量標準。

所以,當沒有絕對權威及清晰且合適的標準的時候,結果往往就是:別人用自己的「感覺」質疑你的「感覺」,你也會用自己的感覺質疑同行水準。

比如,很多設計師可能沒有辦法理解,某公司一個簡單的品牌升級,需要花費幾百萬的設計費用,在我們看來,這個logo我一天能畫10個。多半是因為我們自己很多時候也看不到設計背後的完整鏈路和其帶來的長遠價值。

那用戶體驗真的是一種「玄學」嗎?

這個答案一定是否定的,不然那些被設計師瘋狂喜愛的、偉大的公司也不可能成功。如:賈伯斯構建起來的商業帝國,目前已經是全球最有價值的公司。

用戶體驗其實是有一套科學的、可度量的設計方法和策略的。設計師的問題在於,如何真正在工作中運用「用戶體驗」的思維,在產品中完成落地,在商業中獲得價值和利益。

設計師不單單是體驗微觀的設計者,更是體驗宏觀的管理者。設計師本質上也可以理解為是在不斷追求更好的構建與管理用戶體驗。

基於以上認識回到本節問題,我們做體驗度量的原因:

現代管理學之父:Peter F. Drucker 有一句名言:If you can’t measure it,you can’t manage it(如果你不能很好地度量它,也就無法有效地管理它)

國內設計圈也有一些普遍共識:

如果不能獲得用戶可量化的反饋結果,就很難談有改進迭代的效率如果體驗設計不能很好的被證明,就很難談設計存在的價值如果體驗設計價值不能很好的被體現,就很難規避「某些」質疑所以這就是我們需要進行體驗度量的原因:為了更好的設計,為了更多的價值。

因為體驗度量可以幫助設計師獲得:

直觀的體驗感明確的資源投入方向良好的用戶體驗管理價值性的探索設計破局點清晰的設計價值體現&進階體驗度量與可用性測試的區別:

有時候我們容易講體驗度量與傳統可用性測試相混淆,但兩者其實是有顯著區分的。

可用性測試:更多的是關注用戶使用產品成功完成某項任務的能力用戶體驗度量:是更宏觀的視角,強調用戶與產品之間的整體交互,以及在交互過程中形成的想法、感受和感知以上,我通過介紹自己對體驗設計價值的理解,及什麼是體驗度量、為什麼要做體驗度量的分析,闡述了體驗度量的基本概念及進行體驗度量的重要意義。下面通過對之前工作中進行的,信息流項目體驗度量評測過程的回顧,向大家講解如何進行體驗評測(從構建到實施)。

04 如何進行體驗度量

找準體驗度量切入點:

度量需要方法,而方法構建的第一步是找準切入點影響用戶體驗的因素有哪些呢?

美國著名學者:Fred D. Davis:

1989年,在技術接受模型(TAM )中,指出了兩個影響技術類產品使用的核心因素:「有用性」和「易用性」

有用性:在使用某一特定系統時,主觀上認為其所帶來的實際作用戶用、價值(有沒有用的問題)。易用性:用戶在使用某一特定系統時,主觀上認為簡單、易理解、愉悅、順暢的程度。「有用性」更多是產品能力本身層面的屬性,關乎功能和商業;而「易用性」則是設計師大多數情況下更能把握和發力的核心,也是大多數體驗度量模型的切入點。所以,信息流體驗度量工作的切入點是:從度量產品的易用性角度切入。

切入點找到了,那有沒有成熟的方法可以直接套用或者借鑑學習?

目前較為成熟體驗度量模型:國際標杆模型Google HEART,國內大廠較為成熟的模型阿里雲的UES,螞蟻金服的TECH, 哈羅出行的體驗度量模型,以及網頁時代的經典PULSE 模型。

在分析中發現,PULSE模型誕生比較早(還是網際網路的洪荒時代)且指標更多關注網頁產品的可用性(只要確保產品能穩定快速運行,不會出現負面的體驗就行了),不是非常適合我們。而Google的HEART模型屬於經典模式,適用於大部分C端產品,其他幾種模式也基本脫胎與它,或對他有所借鑑。所以,我們找到的巨人就是Google HEART模型。

Google HEART模型評測模式: 其定義了體驗評價的5個維度,每個維度定義了對應的指標及相應的度量手段。從而完成抽象至具象的過程,實現體驗評測,檢測。

Google HEART模型評測模式

模式方式清楚了,那「巨人」有什麼 特點呢?通過發分析我們總結了HEART模型如下特點,我把它分成優勢與成本(都是相對而言的):

Google HEART模型特點

模型優勢:全維度、多參數、多角度、系統性的評估方式,評測著眼角度為產品全局且有大廠背書值得信賴。

與此相對應的,此種評測方式也帶來了相應的成本:實施成本較高;結果分析輸出成本高(如項目內無良好且完善的數據統計及分析工具基礎);跨部門協作依存度較高(強調多部門較好的協同配合)。

那HEART模式適用於我們的項目嗎?於是,我們對我們項目的特點也進行了簡單分析:

產品特點:為公司APP內的一個功能模塊項目特點:基礎設施不完善,項目資源相對緊張,節奏快迫切困惑:體驗與頭部競品差異較大,設計急需明確發力點(是內容導致?是使用體驗所致?…)服務特點:內容消費,多為圖文內容(自身內容特徵 ),核心流程較為聚焦設計側特點:人員有限(3UI+1UE),支持常規需求+體驗驅動需求通過對大廠模型與自身特點的對照,我們發現:進行類似HEART模型式的全維度評估,似乎不能較好且有效率的解決我們當前的迫切問題,落地實施對我們當前項目現狀來說也仿佛有點難。

通過進一步分析現有「巨人」模型,發現其除了普遍借鑑、參考了HEART模型外,還有具有一個共同特徵,同時,我們也得到了一個新的認識:

一個共同特徵:

它們各有切入點,也各有其適應場景。雖然方法各具特色、不盡相同,思維卻可歸納。無論模型怎麼變化,表達產品體驗的重要度量指標,總逃不開這三個範圍:用戶感受、用戶行為、系統表現。

一個新的認識:

體驗度量具有較強的業務特點:不同的業務類型、業務階段、業務規模、資源情況都會有與之相配的不同的合適的度量方式。

基於以上理解,得出結論:現成的模型很好,但是我們不合適。

信息流項目需要的是:我們當前需要的應該是與當前項目特點,項目情況,產品特徵、階段性目標匹配的專有評估方法。

所以下一步我們需要制定體驗度量的目標,對當前我們體驗度量的目標進行梳理:

量化並跟蹤信息流核心使用流程的用戶體驗水平量化並跟蹤信息流產品在核心流程上與主流競品的優勢與差距指導設計側體驗優化工作方向,驗證體驗優化結果,推動產品排期解決我們體驗優勢是什麼?好多少。我們體驗劣勢是什麼?差多少的問題基於對項目特點,當前度量目標的拆解,我們分析出適合我們自身的體驗評測方式:

聚焦搜索APP信息流模塊關注用戶核心使用流程的體驗更多著眼用戶主觀感受清晰與競品差距與機會點接下來我們結合前期分析,提煉了信息流核心路徑感官體驗評測的評價維度:

信息流核心路徑感官體驗評測的評價維度

基於信息流內容消費的產品形態特徵,結合項目現階段困惑、目標、資源能力確定評測維度為:

接受度(內容質量、整體使用感受)愉悅度(清晰度,樣式舒適美觀度,特色功能)任務效率(功能易用性、完備度)依據確認的維度,提煉明確了評測的目標物:

核心內容質量(圖文內容為主)主路徑使用感受(易用性,一致性,設計舒適度)核心功能使用感受(評論,贊&不喜歡,分享等整體體驗感受(主觀感受打分主競品的同維度對比根據本次體驗評測特徵(傾向主觀感受評測),結合對業內成熟評測方法的參考分析,確定本次評測的形式:採用專家評估。

我們又參考了一些啟發式評估的經驗數據(如:試驗表明,每個評審人員平均可以發現35%的可用性問題,而5個評審人員可以發現大約75%的可用性問題)

將評測形式進一步明確為:

通過每期招募不少於10名符合要求的「專家」 ,通過一對多前期宣講,投放調研問卷,集中評測的形式進行信息流核心路徑感官體驗評測。

什麼樣的專家是符合標準的:

信息流核心路徑感官體驗評測的評價維度

結合信息流核心路徑感官體驗評測的特點,我們梳理出了適合本次評測專家的標準:

公司內部招募優先被評測項目,項目組內成員設計職能為主,產品職能為輔專家儘量階段性固定(考慮到多次實施成本,及結果的可靠性)基於以上,我們最終確定了信息流核心路徑感官體驗評測的最終形式:

項目組內UX為主體,兼顧產品,運營,開發等角色組成的專家式評估。每期招募不少於10名符合要求的「專家」通過一對多前期宣講,填寫問卷,集中評測的形式進行信息流核心路徑感官體驗評測。

評測形式確定後,下一步我們就要著手進行調研問卷的設計:

根據前期分析推導結合信息流產品特點與近期目標設定調研問卷大框架

明確列表至圖文詳情頁核心主路徑的評測細節點明確主要評測流程:先看、看那些、看多少而後後評明確評測採樣機型:根據後臺機型數據覆蓋,抽取主流用戶覆蓋機型進行評測明確主要對標競品:**,**根據框架指引,最終我們設計了:(經過多輪修改,也借鑑了許多成熟的可用性,易用性相關問卷等)

針對列表:內容、樣式、整體三維度,10題5分制問卷針對詳情頁:內容、樣式、功能、整體三維度,21題5分制問卷

初版問卷示意(非最終版)

完成完整方法設計後,我們立即推動執行了首輪《信息流核心路徑感官體驗評測》:

首輪評測共招募專家13人:UED側7名、產品&運營側6名專家(項目組內)通過2天集中組織的測評,完成首輪信息流核心路徑感官體驗評測,評測部分工作其實,首輪評測除了前面講到的目標,我們還有兩個額外較為重要的目標:

初步驗證整體評測方法的可行性獲取體驗評價體系基準點,作為核心流程體驗優化的參考系(前面提到了,本次評測核心目標之一為:迫切的想解決我們與頭部競品的體驗主要差異問題在完成評測後,我們分析輸出了首輪評測的結果。通過對結果的分析,我們也得到了一些有價值的結論:

量化明確了我們與頭部競品在內容層面的具體差異定位了樣式層面的問題及與競品的差異點,幫助設計師確定下一步工作目標透過功能層面分數對比,看出一些特色功能對用戶的整體感受影響顯著(定位深入探索的方向)在通過第一次體驗評測完成基點貯備與目標確認後,我們針對性推動了核心流程體驗優化工作:

針對性體驗優化行動路徑

由於有量化的評測結論佐證與指引,結合明確的行動目標、清晰的行動路徑,使得整個體驗提升計劃,以較高效率完成實施上線。

經過一段時間線上沉澱後,我們在疫情期間,通過線上組織進行了第二次信息流核心路徑感官體驗評測(線上評測也是不得已而為之的一次有趣嘗試,最終從實施過程及結果上也驗證了,之前對評測專家應階段性固定設定的價值,確實會逐步提升評測的效率與結果可靠性)。

第二次體驗評測的關鍵性結論:

得益於第一次評測的指引,我們發現在第二次評測中我們的產品在:內容 、樣式、功能層面體驗評測分都有非常不錯的提升,也驗證了針對性體驗提升計劃,方向是正確的、結果是成功的。

通過依據對評測結果分析後的針對性回訪調研,也發現了一些之前缺乏關注的體驗問題點。同時 ,通過對功能評分數據的詳細分析:明確圍繞產品某些特定模塊的創新挖掘,為下一步體驗設計突破方向。

自己在心裡其實,是將兩次評測定義為驗證性評測,去驗證我們的方法,我們的思考,我們的假設等等。

總結一下,通過兩次體驗評測或驗證我們都收穫了什麼:

針對性體驗優化行動路徑

我們驗證並實踐了信息流體驗評測方法我們獲得了信息流體驗評測的基點儲備我們量化了產品當前的體驗水平以及與頭部競品的差異基於評測我們最終完成信息流項目的體驗升級計劃的最後一環,並得到了科學的驗證。同時,具象化的解決了項目長期的體驗困惑進一步提升了體驗設計部門在項目組內的「權威性」,變相提升了整體項目組的運轉效率解決了後面怎麼走的問題,明確了創新方向,解決了資源投向的問題,也為項目中的設計決策提供了重要的新參考系同時,經過這兩次評測,我們也有一些思考或者說反思:

評測維度是否完真正徹底整覆蓋核心使用流程有無更加效率的評測方式(線上vs線下,因為前期專家側評估時間周期較長)問卷設計是否非常合理(諮詢用研專家結合專家討論)最終統計方式、結果是否合理且可信需要推動建立固定評測機制,從而產生長效收益基於以上的思考與反思,我們組織了包含評測設計者、執行者、參與者以及用研專家的復盤會,對評測方式進行了如下幾個方面的優化改進:

重新梳理評測維度(結合全新的全新的維度拆解)對核心流程評測維度進行細化優化題目&分數(優化不易理解的題目及題目循序,優化題目總數與分數設置梯度等使之評測過程更符合用戶使用與思考邏輯,降低評測難度。同時,提升評測結果的可靠性與統計難易度)優化評測流程( 對評測流程細化,對每一個環節設定詳細的操作說明與注意事項,如:增加提前使用環節及其實施說明)優化數據計算機制(增加數據清洗環節,增加用戶評測問卷驗證可靠性驗證,,增加數據信度分析)通過以上,我們優化輸出了《信息流核心路徑感官體驗評測》第三版。

同時,基於對評測過程效率的思考,我們嘗試啟用了去中心化評測形式(線上集中宣講,線下一段時間內分散評測集中回收的評測方式)

基於對問卷可靠度的思考,我們設計了精簡版更「普世化」的用戶問卷,同步在線上向真實信息流普通用戶進行投放。考慮到信息流用戶問卷填寫意願普遍較低的客觀事實,及問卷的屬性,結合用戶研究有效問卷回收的經驗值,我們設定了用戶側問卷回收的有效標準:最佳目標500份,不少於200份。

通過參考業內成熟經驗,及用研專家建議結合信息流體驗評測的自身特徵,我們設定了體驗總評分 = 專家分*0.8 + 用戶分*0.2 的計算方式。

完成以上工作後,我們按照既定計劃,組織實施了第三次信息流核心路徑感官體驗評測(結果詳細數據屬於敏感數據 ,在此不做詳細介紹,大家見諒)

說一下第三次評測結果輸出的變化:

體驗分構成變為:與主流競品間的專家側對比分;由專家評分*0.8 + 用戶側評分*0.2 組成的信息流體驗評測分最終各項統計數據結果增加數據清洗與信度驗證規則(設定有效數據要符合信度α值 ≥0.75)我們修改最終體驗計分規則的原因: 經過多輪評測後,我們意識到體驗對比不是最終目的,體驗評測追蹤為最終目的,為使體驗追蹤得分的更具代表性與權威性,參考業內成熟經驗+諮詢用研專家,對得分計算方式進行修改。

通過對比第三輪體驗評測專家側與用戶側分數,我們發現:兩側得分趨勢相同,用戶側普遍略高於專家側評分。結合我們評測方法的自身特點,這樣的結果符合我們前期預期,且評測方法的有效性也獲得了一種驗證。

經過三次體驗評測實踐,評測方法有效性也得到了多維度的驗證:

體驗評測方法的有效性得到了多維度驗證

驗證維度:

三次體驗評測專家反饋與趨勢分析用研專家整體優化與評估專家側&用戶側得分對照分析三次體驗評測信度完整測試與分析驗證結果:

《信息流核心路徑感觀體驗評測》第三版較為可靠,可真實反映APP體驗水平

註:方法有效性驗證,也可通過評測方法的效度分析進行驗證

通過第三次體驗評測,我們又收穫了那些經驗:

專家側去中心化評測方式,由於缺乏有效可控的組織,導致出現較多無效數據適當放寬的評測專家選擇,導致前期宣講成本增高,結果不良數據增多專家側評估形式,更適合有主持的中心化評估方式,可有效保證評測的有效性專家側評估,要保證評測人員多數固定,可逐漸增強評價的結果的可靠性及評價效率根據隨第三次評測同步收集的專家側對評測方式的建議,結合用研專家的意見對評測方法進行最後一輪微調,形成終版《信息流核心路徑感官體驗評測方法》。

由於上面講的三次體驗評估流程比較長,我們簡單回顧一下:

三次體驗度量階段目標回顧

第一次度量:

模型與評測方法驗證;獲得體驗評測基點;理清與主競品體驗差距;明確設計發力點。

第二次度量:

驗證體驗優化方案成效,對評測流程的進一步驗證;研究評測方案的不足與優化 方案;尋找下一步創新的發力點。

第三次度量:

評測方法的最終驗證;制定並落地周期性體驗評測機制;驗證階段性優化與創新全局影響;對體驗的常規監控。

終版《信息流核心路徑感官體驗評測方法》一共由7部分組成:

《信息流核心路徑感官體驗評測方法》構成

我們也設定了信息流核心路徑感官體驗評測方法 「閉環行動路徑圖」:

信息流核心路徑感官體驗評測方法 「閉環行動路徑圖」

下面,我們回顧一下終版《信息流核心路徑感官體驗評測方法》與「主流」評測方式。

評測維度上的對比 :

評測維度對比

與主流評測方式相比 ,我們的評測維度相對更聚焦,更符合我們自身的項目特點及面臨的階段性問題。

評測特徵的對比:

評測維度特徵對比

與主流評測方式相比 ,我們缺乏對產品全局關注度,但是,能夠換來更聚焦的評測,更靈活且實施成本底的評測方法,更高的評測運轉效率,更能滿足我們項目當前階段的迫切需求。

05 本文所講的要點回顧

用戶體驗與業務價值強關聯,才能做到價值體現。

好的體驗是更好的實現產品價值、用戶價值、商業價值、社會價值的交付。

什麼是體驗度量:

「用戶體驗度量」通過一套可靠的測量體系 ,量化用戶體驗;是用戶體驗從「玄學」到「科學」的重要基礎;是做好體驗管理和良性迭代的重要途徑;是更好的實現體驗設計價值及體驗設計體系化的關鍵路徑。

體驗度量的重要性:

設計師是用戶體驗的「構建者」與「管理者」;如果不能很好的度量,就無法有效的管理;體驗度量是設計師深挖價值的有效路徑,是輸出設計價值的靠譜手段。

體驗度量的特點:

體驗度量具有較強的業務特點:不同的業務類型、業務階段、業務規模、資源情況都會有與之相配的不同的合適的度量方式。

不同的 體驗度量有較為一致關注角度:用戶感受、用戶行為、系統表現;方法雖多變,但思維統一,所以我講的如何度量不重要,重要的是如何思考。

體驗度量方法的設計思路:

體驗度量方法的設計思路

梳理體驗度量方法設計的9個關鍵節點:

理清:項目現狀&階段明確:可投入資源制定:階段性目標提煉:有效評測維度設計:評測方法與形式挑選:評測專家&用戶驗證:評測方法效度檢測:評測結果信度構建:閉環評測優化路徑與周期性檢測機制感謝大家耐心閱讀,文筆拙劣,觀者見諒,希望本篇文章能夠對大家日常工作,尤其是準備進行體驗度量工作的同行們有所啟發。

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

題圖來自Unsplash,基於CC0協議

相關焦點

  • 體驗|用戶體驗評測和度量思考與實踐
    關於體驗度量方法行業內案例已有一些,但普遍為較為全局,實施與結果輸出成本相對較高,對一些小團隊可能運用起來比較困難。本文結合過往項目實際經驗,從一個新的角度介紹,相對敏捷且普遍適用的小團隊體驗度量方法,較為完整的還原了從構建,實施,驗證,最終成型的過程思考。
  • 如何度量用戶體驗?-阿里PTECH/UES模型
    TECH模型 提供以用戶為中心的 UBA(用戶行為分析)+APM(應用性能監控)閉環下的體驗洞察,讓產品體驗可度量、可優化、可監控。
  • 項目管理中的敏捷實踐,值得產品經理去學習
    本文作者將以自己所在公司的項目經歷為例,講述公司日常交付項目中主要使用的敏捷實踐是如何幫助團隊實現最大價值的。雖然文章內容對象是以項目經理展開敘述,但項目管理中的敏捷實踐值得我們產品經理去學習。敏捷開發通過逐步細化、迭代前進的方式,分階段地將需求予以實現。比如說,我們先從整體功能規劃中定位出一小部分核心功能,打造能基本運轉、對用戶有價值的最小可用產品(Minimum Viable Product,MVP),然後迅速迭代開發,聽取用戶反饋,及時調整功能規劃。
  • 什麼是敏捷開發
    已經有很多介紹什麼是敏捷開發的文章了,為什麼還要寫一篇呢。我最近也在思考中,主要有2個原因:現在找到的文章,介紹敏捷開發非常簡短,不夠詳細甚至有一些文章,沒有介紹出敏捷的本質作為一名 Scrum培訓師(CST),有必要為大家澄清一下什麼是敏捷開發。敏捷開發調查介紹敏捷之前,先了解一下背景。
  • (英文版)敏捷度量實戰
    來自2015年Manning的好書,雖然2019年了,對於搞IT敏捷管理的從業人士依然有很大的參考價值!
  • 敏捷實戰派 · 用戶故事地圖工作坊3PDU—弘博創新ACP講座
    項目管理協會(PMI)不但在剛剛出爐的第六版「項目管理知識體系指南」 中,大量加入敏捷相關的內容,提點項目經理要學會和敏捷團隊接軌,還另外和敏捷聯盟合作,出版了一 本「敏捷實踐指南」,作為從頭理解敏捷項目管理的入門書。
  • 華為雲MVP黃雋:從排斥到布道者,敏捷的正確打開方式是什麼
    難道敏捷出了問題,或者說敏捷轉型有這麼多痛點,敏捷還適合軟體開發嗎?在敏捷專家黃雋看來,"如果本身對敏捷開發就存在誤解,這很容易導致錯誤的實踐方式。"那麼,敏捷的正確打開方式是什麼?且聽黃雋慢慢道來。"和華為雲幾位敏捷專家分享布道的日子裡,接觸了很多企業用戶、老闆、高校教師和領導,更深刻的了解到企業轉型和高校產教融合的很多痛點,一種要幫助解決痛點的責任油然而生。"黃雋笑言,"隨後,我們就一起創建了'敏捷江湖桃花島社區',專門解決敏捷和DevOps轉型痛點問題。"
  • 成功實踐敏捷開發的26條「軍規」
    【IT168 專稿】    如何才能成功實踐敏捷開發是一個課題。最近Keith Swenson一直在考慮這個問題,並最終總結出26條重要原則,以指導敏捷軟體開發團隊更好地工作。    原則1:第1個用例完全處理好後再開始處理第2個用例。打個比方說,好比「先上這道菜,再開始做下一道菜」。
  • 產品使用體驗如何量化與管理——阿里雲 UES 全面揭秘
    那些不確定的用戶體驗,開始轉化為確定的淨推薦值和大量的體驗問題反饋,給產品改進帶來實實在在的指引,進而又讓產品更加重視對用戶體驗的管理。體驗和產品的故事,從此走向了一個良好的正循環。而過去一年,NPS 已經從一個設計發掘的體驗數值,變成了大量雲產品的核心指標,而從這些舉足輕重的產品中,我們發現並改進上百個用戶體驗問題。但對於設計師來說,度量用戶體驗的命題卻遠未得到解決。
  • 當軟體遇上設計,淺談敏捷UX VS.精益UX
    時至今日,敏捷方法已經成為主流。隨著一些主流設備的成功,比如iPhone推動了體驗設計的飛速發展。設計成功與否不再是由產品經理、設計師決定,也不是死板地按照設計需求清單來,而是直接由用戶決定。 因此,設計師、開發者更加注重將UX融入到敏捷開發中。
  • 什麼是敏捷項目管理
    這幾天看了一本書,「敏捷項目管理」, 覺得書中的一些敏捷方法挺適合現在快速迭代的產品,接下來會挑選一些我認為有價值的東西分享給大家。首先了解下什麼是敏捷項目管理敏捷技術萌芽的產生已經有很長一段時間,最早可以回溯至1930年代沃爾特·休哈特在項目質量方面的計劃-執行-學習-行動(PDSA)方法。2001年,一組軟體和項目專家聚在一起討論他們項目成功的相通之處。
  • 什麼是敏捷開發?
    這顯而易見,我們在項目進程中積累了知識特別是當向用戶交付產品後,用戶反饋:「我要的不是這個啊,我說的明明是……」,這時候你瞬間狂漲知識,並感嘆道「你怎麼不早說呢?」。這中間可能有溝通問題,但更多可能的是,用戶這時才清楚或能夠描述他們要的是啥,更有甚者,我們可能一開始連用戶是誰也未必能準確地定義。
  • 華為雲敏捷 DevOps 實踐:產品經理如何開好敏捷回顧會議
    從敏捷宣言,到敏捷的諸多實踐(如 Scrum),到 DevOps,都一直提倡回顧這種形式。其實回顧這種形式,並不是敏捷 /DevOps 專屬的,華為最早也有類似的活動。有時候團隊碰到域鬱悶,痛苦的時候,還會主動自發的開。所以,回顧,我一直認為這是人類作為一個智慧物種相比其他生物的一個重要區別。我有的時候回通過回顧會議來判斷這個團隊會不會成功。
  • 以購物車為例,產品體驗如何做衡量?
    編輯導讀:對於產品經理來說,提升用戶體驗是實現自我價值的證明,因此體驗度量就很有必要和價值了。本文作者以購物車為例,圍繞如何衡量產品體驗展開三個維度的分析,希望對你有幫助。用戶體驗是人人常掛在嘴邊的一個詞,無論他是業務、運營、研發還是老闆。
  • 資深UX 設計師:用戶體驗設計過程方法論的演變
    到目前為止,仍然有很多的企業將用戶體驗看作是一門視覺學科。正如唐納德·諾曼一直試圖解釋的那樣,這是不正確的。事情直到2013年才開始好轉。精益用戶體驗精益用戶體驗是傑夫·哥德夫(Jeff Gothelf)在敏捷環境中對用戶體驗的實踐問題給出的一個改變遊戲規則的答案。
  • 專訪程顯峰:敏捷在團隊中的實踐與發展現狀
    記者:如能得到準確的數據支持,敏捷實施能夠更好地開展下去,那麼敏捷實踐下的程式設計師工作指標將如何衡量?我是覺得這個數據比較難以衡量的,因為衡量有意義的必須是在某種固定的場景下。比如對於我這裡來講,我可能會要求程式設計師開發一個標準模塊的實踐,但是對於別人來講,這個他可能不太注意。
  • 如何度量產品的易學性?
    學習速率用戶能夠多快地在重複使用中表現地更好?學習速率對於那些即使不會過度但需要重複使用該產品的用戶特別重要,如果用戶逐漸發現自己對這款產品使用的得心應手,會有一定的成就感有一直用下去。(反之,如果用戶發現這款產品越用越難,不論他們付出了多大的成本,都會開始找更好的解決方案。)3. 效率飽和點當用戶熟練使用這款產品時,他能提升工作效率的天花板在哪?
  • JIRA與敏捷:李小龍教給我們的敏捷開發之道
    而敏捷也是如此,它一直都沒有固定的模式、方法,它提供給開發者更多的是一種思路。2.  簡單李小龍說過:「對於我來說,武術非凡的一面在於其簡單……如果你花費了太多的時間去思考某件事情,那你就永遠都不會完成它。你至少每天要有一個朝著目標的明確的行動。」敏捷何嘗不是這樣。3.
  • B端產品|用戶體驗量化的三個案例
    筆者在學習Tom Tullis、Bill Albert的《用戶體驗度量》後,開始思考:針對B端產品,如何在線上環境中,通過對用戶數據的採集、分析,完成對產品的用戶體驗量化?本文給出三個案例進行嘗試,從簡單到複雜闡述三種量化的維度。
  • B類用戶深度訪談方法的思考與實踐
    B類用戶是以組織形態存在,看重的是「生意」功能訴求,以往C類用戶的經驗並不能照搬;本文以訪談實踐帶入對訪談的思考,再由思考去指導實踐。導言針對B類用戶(企業用戶,下同)的深度訪談有什麼特點,難點?針對這些特點,深度訪談時有什麼對策,注意事項?筆者基於工作項目實踐嘗試回答以上問題,歡迎交流討論。