從哈羅單車上鎖聊聊任務鏈路優化設計的思路
在外出的時候,又是因為路線有點遠的情況下,碰到路邊的共享單車,是不是會為了圖方便打開手機掃一掃立馬走人呢?但是到結束的時候,會發現偶爾有忘記手動鎖車的情況,這就非常不妙了。面對這種問題,筆者整理分享了一篇關于建議優化設計的思路的文章,大家一起往下看看吧!
一、起因
最近突然喜歡聽著小曲蹬著車子,不過我沒有自行車,所以就選用了大眾款藍色哈羅單車,不過有意思的是發現整個用車體驗跟原來有了不少變化,除了車的外觀差異,更讓我印象深刻的是還車時只需要在手機上進行操作即可,不知道大家是否還記得原來的還車過程,這里我幫大家回憶一下;
這個過程本身沒什么問題,但實際上匆匆忙忙的大家忘記手動上鎖還車時有發生,并且當你想起來的時候,手機上也只能干看著扣費,還得折返回去進行鎖車。本人更離譜,有次打開手機發現忘了手動鎖車,一看行程,已經被人騎出去老遠啦~
但這次不再需要手動上鎖來還車了,整個鎖車還車已經借助物聯網技術將操作集成到手機上進行了,這意味著現在忘了還車還能亡羊補牢,并且還車也很輕松,考慮到最終騎行事件是在手機上完成閉環的,忘記上鎖和離開后無法上鎖也就一下解決了,這便是技術應用與交互鏈路優化設計的美妙之處!
人嘛,總是怕麻煩,想走捷徑想偷懶才是常態,而任務流程或是交互鏈路優化就是幫大家更輕松更方便的完成任務操作,這不妥妥的用戶體驗優化必備能力項嘛~,那就簡單聊幾句優化設計的思路吧。
二、任務鏈路優化有何價值
一般來說做交互鏈路優化的核心價值或是目標就那么幾個:
1. 更好用
即更加高效便捷好用的意思,這短短三個字就直接包含了大家常掛在嘴邊的易用性、可用性啥的了,好的交互就應該是盡可能的為用戶提供簡單好用的交互,舉個例子,近期在使用阿里云Flow的流水線,期間我也用過其他家的CI/CD服務,相比之下我覺得阿里云Flow的流水線編排反饋就做的更勝一籌,“更方便”加一分。
2. 更準確
意味著為用戶提供正確的服務、流程、功能、組件、信息反饋乃至視覺效果,為的是提升產品的可理解與易用性,從而達到降低學習成本提升效用,減少跳失率或出錯等負面情況。
3. 提升意愿
嗯!花費那么多心思讓產品體驗變得更方便更準確就是為了提升用戶的使用或付費意愿,算是任務路徑優化設計的底層價值吧。
三、任務鏈路優化的流程
出于不同的行業差異,優化流程的細節可能有差異,但基本上可以通過五個階段來概括;
1. 找到問題
在一套服務系統中,當用戶反饋難用、麻煩、任務卡點、不如傳統服務模式時,那就意味著有優化的空間,設法洞察問題、定位問題就可以開展工作了。
2. 優化目標
通常進行任務流程優化的目標基本上就是降本增效、解決卡點、體驗升級,通常根據實際問題也會有更詳細的優化目標用于執行推進。
3. 方案構思
出于問題與目標而進行的優化方案構思,這其中包含了優化策略、方案原型、版本兼容等問題,主要是為找到優化的好辦法。
4. 方案驗證
嚴謹些,設計者不能由個人主觀認定方案一定可行,新的方案最好經過用戶驗證或量化測試來保障效果,并且測試驗證的過程中遇到的新問題,也應該留意并放到持續改進中。
5. 持續改進
事實上這是一個不可避免的過程,原因有三:
- 優化一部分后就可能會出現新的問題。
- 問題可能沒辦法一次改到位,只能分批持續推進。
- 最后則是伴隨業務發展需要持續地做出改變來響應。
所以分好優先級后慢慢改吧,也許隨著業務發展變化,有些問題就不是問題了。就像網絡段子一樣,當初一個需求十分緊急,但是研發排期太滿,半年后這個需求還在,看來這個需求也不是十分緊急嘛~
這里再補充兩個近期在用或接觸到的優化流程~~~~~~
6. PDSA 或PDCA
PDSA是指“計劃-實施-研究-行動(Plan-Do-Study-Act&Amend)”,屬于一種精益方法,常用于衡量變更的有效性,部分企業的專有云解決方案架構師也叫做PDSA,并且有對應的平臺組織。PDSA雖然不能很好幫助產品做創新或直接解決問題,但在流程優化解決的實施與驗證管理方面是好手,這一方法的四個步驟分別如下:
- 計劃(Plan):明確業務目標,聚焦核心的業務流程,識別潛在的改進點,定義問題與有效改善的可量化指標。這一步驟可以結合競品分析、市場調研、SWOT等手段來分析梳理。
- 實施(Do):根據現有的情況與目標,設計出可行的解決方案,然后發起執行與指標監控,之后則比較效果來衡量有效性。具體做什么則需要結合流程鏈路優化來,例如刪減操作步驟、整合頁面信息等。
- 研究(Study):收集數據相對于初始的業務狀態進行數據比對與分析,看看對應的可量化指標是否有所好轉以及是否有新的發現,例如效率、成本、門檻等指標。
- 行動(Act & Amend):根據研究分析的結果,確認哪些是可行哪些是不可行的,并做出下一步的行動計劃,并通過反饋與研究洞察對業務流程進行持續的改進優化。
而PDCA則是指“計劃-實施-檢查-行動(Plan-Do-Check-Act&Amend)”,檢查主要就是驗證效果是否有效,有效的則應用或標準化,沒用的則繼續改進,相比下,PDSA的內涵會更廣泛些。
7. SDCA循環法是一個持續改進模型
SDCA是指“標準化-執行-檢查-總結(Standardization-Do-Check-Action&Adjustment)”,跟PDCA有些類似,主要差異在于第一步驟:
- 標準化(Standardization):識別和定義改進過程中需要標準化和優化的關鍵步驟和流程,例如軟件系統的交互規范化、場景模塊化、系統設計、流程統一等,亦或是產品客戶端的操作手冊、新手引導、統一操作流程、測試用例、準入門檻等標準化內容。
SDCA循環法的目標是實現持續改進,可以減少重復性問題再次發生、精簡和標準化執行,形成可靠、準確、高效的結果,是一種結構化的迭代的方法,且適用領域廣泛。
四、優化過程的焦點
這里先放AI的答案:
看起來也沒啥大毛病哈,那么接下來圍繞下圖的概念說說我認為的焦點。
1. 目標用戶
通常完成一套服務的交付會涉及各種角色,那么就需要根據用戶的特征或偏好提供差異化的服務與內容交互。一般需要人工操作的部分往往更容易出問題,通常借助用戶研究、用戶測試都能獲取到一些有用的信息來指引任務鏈路優化。
2. 服務體系
即提供什么樣的服務解決什么樣的需求,之所以說服務體系是因為現在的產品很少通過單個或極少的服務來打造一個產品,這就意味著要對用戶進行合理的分類管理,對標提供合適的服務與版本,減少不必要的服務或是混亂的服務帶來的產品臃腫與任務鏈路混亂,例如招聘軟件的招聘與應聘視角分離。
3. 使用場景
場景化或情景洞察一直是產品設計的重點,可以洞察到更多用戶實際遇到或潛在的痛點,以及線上線下等環境帶來的微小差異性,這對任務鏈路優化有很大幫助,作為焦點一定不為過,至于如何實踐了,我們可以通過觀察線下傳統服務的過程,或是采用用戶測試的方法進行觀察與分析獲取優化指引,哪里用戶卡住了或是吐槽了那就表明有優化空間。
4. 交互媒介
指在整個服務發起到結束過程中所經歷的人群、設備、通信、內容、第三方服務等,就以哈羅單車的租賃過程為例,其中主要的核心媒介就包含了“用戶、手機、應用、網絡通信、商家服務器、自行車、付費服務”,那么以這些作為焦點有什么用呢?事實上一套完整的服務正是由這些媒介之間的不斷交互,才使得哈羅的租賃服務可以如此靈活,所以在整個服務流程中讓媒介之間更智能、自動、高效的完成銜接與交互,就成了必要的焦點了。
5. 構成信息
幾乎進行任何服務都離不開特定的構成信息與交易,舉個最簡單的例子,晚上你來到街邊攤,想要一份烤冷面,那么你除了要掏錢以外,你還要跟老板確認口味、加料、價格這些信息,這些就是構成任務進程的信息,這些信息可以通過問答式確認,也可以提供招牌信息給食客確認,總之將這些信息更簡練準確的進行交互,就能實現任務鏈路的優化,在應用程序的交互設計中,常常表現為用正確的描述語、正確的交互組件、正確的視覺表達、正確的反饋等,事實上應用程序本身就是由各種各樣的信息交織在一起所構成,所以“做任務鏈路優化不僅是減少操作步驟而已”。
6. 業務模型
本來是沒有業務模型這一環的,但考慮到實際的業務場景中會有很多復雜的部分,常常盯著這些細小的部分往往容易一葉障目,而業務模型的優勢就是鳥瞰全局,并以簡單易懂的圖像進行表達,這個過程可以讓我們更好的理解業務的概念與邊界,可以看到各種界面與交互媒介之外的業務本質,幫助我們在優化過程中清晰重點與方向,以達成結果為導向,避免在細枝末節上投入過?;蚰限@北轍。
五、一些還不錯的思路方法
1. 無前置輕快任務先行
當有多個任務進程需要處理時,就可以參考此原則來優化任務操作的路徑,有點先易后難的意思,當多個任務之間沒有前后的依賴關系或限定要求時,那就先處理輕小快捷的事項,當用戶已經完成部分事項后,剩余事項就更容易推進了。
當然也可以根據此原則將前置條件整合處理,這樣在后續的任務路徑中就可以減少相應的條件卡點,例如大量安卓應用第一次安裝啟動時就會向用戶索要存儲、錄音、相機等基礎權限,那么之后使用相關服務時,就不用觸發授權窗口了,不過權限還是要遵循用戶隱私政策法規哈。
2. 漸進式交互
就是將復雜的任務進行拆分,通過循序漸進的方式一點一點完成任務,這樣可以減少任務達成的門檻,讓用戶更加專注,并且可以在過程中培養用戶的意識,是任務鏈路優化的常見手段之一,也是游戲新手村屢試不爽的教學模式。
3. 并行規劃
通過規劃使多個任務事項穿插或并行開展,本質就是任務事項的拆分管理與資源規劃協調,通過使更多事項同時或盡早進行,來加快任務目標達成,以效率來推動任務鏈路優化的目的。
在資源規劃協調時,可以通過時間、狀態兩方面下手,重復的、自動的、久等的、卡點的可以考慮先行,然后再處理其他瑣碎事項即可
4. 群體劃分
即我們常說的用戶分層,通過提供差異化的服務或任務路徑來對應不同的用戶群體,以減少無效或干擾的流程操作,例如常見的會員與普通用戶就會享受到兩種不同的服務體系。
5. 技術創新
通過科技技術的應用,可以為用戶帶來更多的便捷與新鮮感,特別是具備商業屬性的技術,會更快地成熟與普及,然后影響到更多人的生活方式。這個過程可以概括為“科技-認知-應用-習慣-直覺”,就像現如今的掃碼支付、人臉識別、指紋解鎖一般,不僅在各種領域都有了應用,并且你一看到相關信息,直覺就會引導你該如何操作。
6. 約束與枚舉
面對各種復雜的操作、選擇、輸入輸出時,盡可能的枚舉出選項或模板,這樣用戶操作會更規范也不容易困惑,對于那些用不了或有特殊含義的內容則通過樣式、組件、提示等進行合理的約束,避免任務流程出錯,也幫助用戶識別與理解,例如報錯信息就要約束用紅色反饋,電話號輸入就要約束為數值輸入等。
7. 5why分析法
一個老生常談的方法,可以幫助我們深入問題和洞察底層含義,用法就是面對問題不斷的追問為什么。
8. 場景化分析
簡單講就是在解決或優化任務鏈路的時候,帶上人物、目標、行為、環境、時間諸多因素綜合性思考,形成一個更完善而真實的洞察環境,以幫助獲取更多有價值的優化信息,此前有出過一期關于場景化思維的專欄文章,寫的比較詳細,有興趣的可翻閱一下:通道: http://www.aharts.cn/pd/5588700.html
9. ESIA分析法
ESIA是企業流程優化中比較出名的方法,但也不僅限于企業流程優化,其核心理念就是減少流程中非增值活動,以及調整流程的核心增值活動。由消除-簡化-整合-自動化(Eliminate-Simply-Integrate-Automate)四個步驟構成,在任務鏈路優化中也是一個不錯的思路或策略。
10. ECRS“分析法
是工業工程學中程序分析優化的四大原則,主要由取消-合并-調整順序-簡化(?Eliminate-Combine-Rearrange-Simplify)構成,此前在做一套代碼流程優化過程中,此方法給我帶來了不少幫助。
- 取消( Eliminate):首先是根據規模、階段或目標,考慮哪些是可有可無的,或價值有限的,能換掉的就換掉,能去掉的就去掉。
- 合并( Combine):在不影響最終目標與質量的前提下,根據某些屬性,將多個工序進行合并或融合。同時也要考慮融合后的體驗與兼容性,如若不然就不要強制合并了。
- 重排( Rearrange):即將相關的工作流程或內容進行新的順序調整重組,以滿足更合理更流暢的結構,例如減少了流程往返操作的不便、先易后難的配置表單。
- 簡化( Simplify):不是取消或減少而已,而是經過以上工序后。將剩余的或整體進行簡單化、完整化、便捷化、智能化處理,可以是新技術應用也可以是交互方式的調整不等。
任務鏈路優化的思路或方法肯定還有諸多,這里不再列舉了,實際上掌握或了解幾條比較實用的就差不多了。
六、一些還不錯的分析工具
說完了以上內容后,再補一些常用的優化工具,當然了,主要是我個人常用或覺得實用的一些。
1. 整合分析類
○思維導圖:可以快速幫助我們對信息進行樹結構化與邏輯整理,并且可以結合圖文以及功能圖標等來完成管理及計劃,能夠將業務或功能框架快速顯現出來,是很好的輔助工具之一。
○矩陣表格:可以很方便的將信息進行羅列與比對分析,在一些信息介紹或數據分析時常常會用到。
○服務藍圖:可以將完整的服務過程繪制出來,能夠包含人物角色、前后臺關系、階段過程、狀態扭轉、交互觸點等。
○體驗地圖:可以將服務、目標、用戶、交互、反饋進行階段化整合分析,本身是挺好的工具,只是設計師作品集中的用點兒虛,但不影響自己拿來實用。
○泳道圖:可以根據時序對流程進行可視化,可以很好的傳達職能部門或是角色之間的交互過程,也可以細分交互媒介、服務終端等因素之間的關系。
○流程圖:主要就是圍繞一個事件的開始到結束過程的流程可視化,流程圖可以系統化的梳理業務邏輯與交互鏈路,泳道圖也僅是流程圖的一種,相信大家都很熟悉了,就不過多贅述了。
○魚骨圖:是一種根因分析工具,有頭有尾有分支,像魚骨,常用于定位問題發生所導致的根因,也可以用來制定任務目標進程的管理。
○狀態機:一種針對事件狀態扭轉關系的流程圖,用于描述系統的狀態和事件,以及事件引發系統在狀態間的轉換過程,有點像是一系列的if語句,在中后臺的系統設計中常常會有需要梳理狀態的情況發生。
○業務框架:業務框架主要是一種將業務過程和活動進行組織和分類的方法,具有較大的顆粒度與較強的全局性,常用于表達業務框架單元之間的組成與活動關系。而業務模型主要是指業務概念關系的可視化簡圖,前文的流程圖、泳道圖、狀態機等等都可以是業務模型。
?2. 監測洞察類
○交互自檢:主要用于交互設計的查缺補漏跟避錯,同時在交互鏈路自檢的過程中是可以主動發現問題,并驗證優化是否可行或合理。
○使用性測試:也叫做可用性測試,是對優化結果或Demo進行測試檢驗的過程,通過模擬真實的任務操作過程以達到洞察、探索、比較、效果驗證等目的。
○A/B測試:常用于方案之間的效果比較或驗證,通常都是借助工具引流獲取一批真實用戶的測試反饋,是一款真實有效的驗證手段,不過方案之間的差異不宜過于懸殊。
○數據漏斗:像任務鏈路這種多線程或是節點較多的事件,單薄的點擊率或轉化率的作用是很有限的,這時候就需要在相關任務節點上布滿更多的埋點,將用戶流量與數據轉化的情況用漏斗視圖表現出來,然后就可以針對任務鏈路進行分析或比較了。
八、最后
本次的分享更多是從系統設計本身出發,實際上人總是最不可控的因素,在整套任務鏈路優化的過程中,也可以多考慮人工部分的管理與培訓優化,想象一下一家電商店鋪,什么都還挺好的,結果你跑去咨詢客服的時候,人家愛搭不理,你問一點他答一點,就是不一次說清楚,你能舒服嗎?
寫到這里已經幾千字了,不打算找案例展開講了,最后再為那些不愛看字的朋友們濃縮式總結一下。
等待少點引導多點,能一次說清楚的就不要云里霧里,能簡短操作的就不要搞復雜,能給選項能給規范的就不要讓用戶瞎填,一次做不完的就分幾批做,交互組件要匹配不要生搬硬套,能給自動方案的就不要讓用戶瞎折騰,能用先進實惠的智能技術就不要技術落伍了。
如果覺得寫的還不錯,期待點贊收藏或分享,我將再接再厲~
不定期更新,歡迎關注或評論區留言,下期見!
專欄作家
泡泡,人人都是產品經理專欄作家。專注產品交互領域的體驗設計師,擅長思考和UI呈現設計,喜愛交流探討~
本文原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自Pixabay,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
兄弟 該更新了
??我拖更了這么久了嘛
湊一條評論