最近突然喜歡聽著小曲蹬著車子，不過我沒有自行車，所以就選用了大眾款藍色哈羅單車，不過有意思的是發現整個用車體驗跟原來有了不少變化，除了車的外觀差異，更讓我印象深刻的是還車時只需要在手機上進行操作即可，不知道大家是否還記得原來的還車過程，這里我幫大家回憶一下；
這個過程本身沒什么問題，但實際上匆匆忙忙的大家忘記手動上鎖還車時有發生，并且當你想起來的時候，手機上也只能干看著扣費，還得折返回去進行鎖車。本人更離譜，有次打開手機發現忘了手動鎖車，一看行程，已經被人騎出去老遠啦～
但這次不再需要手動上鎖來還車了，整個鎖車還車已經借助物聯網技術將操作集成到手機上進行了，這意味著像我這種時常忘記手動鎖車的人有了更好的選擇，現在忘了鎖車還能在手機上亡羊補牢，考慮到最終騎行事件是在手機上完成閉環的，忘記上鎖和離開后無法上鎖也就一下解決了，這便是技術應用與交互鏈路優化設計的美妙之處！
當然，如果你已經養成了手動鎖車好習慣，你可以繼續選擇手動上鎖款，剛好最近也在做一些交互鏈路優化的活兒，索性就我自己的工作場景，展開聊聊這用戶體驗優化必備能力項的一些思路方法吧～
一般來說做交互鏈路優化的核心價值或是目標就那么幾個；
即更加高效便捷好用的意思，這短短三個字就直接包含了大家常掛在嘴邊的易用性、可用性啥的了，好的交互就應該是盡可能的為用戶提供簡單好用的交互，舉個例子，近期在使用阿里云Flow的流水線，期間我也用過其他家的CI/CD服務，相比之下我覺得阿里云Flow的流水線編排反饋就做的更勝一籌，“更方便”加一分
意味著為用戶提供正確的服務、流程、功能、組件、信息反饋乃至視覺效果，為的是提升產品的可理解與易用性，從而達到降低學習成本提升效用，減少跳失率或出錯等負面情況
嗯！花費那么多心思讓產品體驗變得更方便更準確就是為了提升用戶的使用或付費意愿，算是任務路徑優化設計的底層價值吧。
整體我們可以劃分為優化前、優化中、優化后三個階段，對應到三個階段中，對應的工作流程基本由問題定位、優化目標、方案構思、方案驗證、持續改進構成，然后根據階段與流程我會把相關的優化焦點與鏈路優化的關系交代清楚，算是清晰一下鏈路優化工作整體思路與每個階段的工作事項。
以我們B端SaaS產品的優化設計為例，焦點可以簡單的鎖定在
用戶、產品、業務場景
三大層面，我們會關注這三個因素中帶來的反饋來找到和定位問題，最終解決掉用戶痛點或是觸成業務目標，具體點可以拆分出以下焦點事項；
需要關心產品目標用戶的特征，他們是收益的來源也是市場構成的部分，作為產品的經理或業務設計師，肯定是對預期的目標用戶有所了解才對，特別是初期型產品；
當積攢了一定用戶量后，就會開始關注基于數據或定性研究得到的用戶畫像信息，并通過這些更準確的用戶畫像來了解目標市場和進行業務設計決策，而不只是對著市面上競品抄作業罷了。
主要是產品本身的服務體系或業務邏輯相關，前面提到了用戶畫像或分層的一些概念，
實際上現在的互聯網產品中，服務體系或是用戶角色都不會很單一，用戶角色、權益身份、服務場景等等都有差異，設計前的差異化背景或權重厘清就很重要，至少要清楚當前優化的服務線路是為那些人，他們有哪些差異、有哪些狀態情景、有哪些交互要兼容或避錯。
我們關注產品、關注用戶，同時也關注他們之間發生了什么樣的化學反應，所以業務場景必定是本階段中的一大焦點，通過業務場景可以洞察到更多用戶實際遇到或潛在的痛點，以及線上線下等環境帶來的微小差異性，至于如何實踐了，我們可以通過觀察不同類型的用戶是如何使用產品，或是與用戶對話分析來獲取優化指引，哪里用戶卡住了或是吐槽了那就表明有優化空間，這應該算是任務鏈路優化的基礎焦點了吧。
2、情景：用戶出于什么背景原因或目標在什么時機進入該場景？
2、行為：用戶進入場景后要做什么或做了些什么？是否做的順暢？
3、結果：用戶是否達成目標？未達成或達成受阻的原因是什么？
4、反饋：用戶吐槽或建議了些什么，我們獲取了哪些有效的改善訊息？
這個階段中，我們的主要工作可以概括為分析問題、解決問題、驗證問題，其中焦點可能會比較多，這里我挑了一些說一下；
結合前面階段中的場景化來還原問題是什么情景下怎么發生的，產生了什么樣的負面影響，這很重要，我們需要知道用戶的業務訴求是什么，造成出錯原因是什么，產生了多大的影響，以及用戶期望的是怎樣，然后就是如何更好的滿足用戶訴求，同時保障企業的利益，這就是需求分析要做的事情；
主要是考慮復雜且涉及多方媒介的業務場景，要思考這些媒介或端怎么配合用戶完成任務，以什么樣的形式進行交互。就例如哈羅單車的，不僅是要經過手機的交互，還有單車的傳感器與數據交互等，事實上一套完整的服務正是由這些媒介之間的不斷交互，才使得哈羅的租賃服務可以如此靈活，所以在整個服務流程中讓媒介之間更智能、自動、高效的完成銜接與交互，就成了必要的焦點了，如果說你認為這是多余或無效的部分，那么很有可能說明你所處在的產品服務構成還不算復雜，但這不能否定掉交互媒介的重要性。
這個過程中，你至少要清楚服務完成要經過哪些端、那些人、哪些條件、哪些信息構成。
圖：舉個最簡單的例子，晚上你來到街邊攤，想要一份烤冷面，那么你除了要掏錢以外，你還要跟老板確認口味、加料、價格這些信息，這些就是構成任務進程的信息，這些信息可以通過問答式確認，也可以提供招牌信息給食客確認
總之將這些信息更簡練準確的進行交互或傳達，就能實現任務鏈路的優化，事實上應用程序本身就是由各種各樣的信息交織在一起所構成，所以
“做任務鏈路優化不僅是減少操作步驟而已”
。
可以簡單易懂的幫助我們理解和消化業務，以及更好協同，面對復雜的任務流程，可以更好的表達或梳理業務概念與全局結構，在做復雜的任務優化時，就不容易被局部問題牽著鼻子走，而忽略其他影響面，說的直白點，就是這個業務的整體過程你腦子里要有個概念，制作方法其實就是將各個業務或任務拆解成多個單元的形式，并將單元之間的包含或層級關系表達出來
需要考慮技術實現的周期與成本，即開發是否可以實現，需要研發多久，要投入多少成本，我相信產品經理都會關心這個問題，其實就是投資回報率與可行性的問題，產品生產研發的本質是賺錢不是虧錢，不是嗎？
例如說你看見了一個很酷炫的交互效果，也準備應用到自家的產品中，但實際開發的難度大不大，要投入多少時間精力，這個酷炫的交互又能帶了多少產品收益？所以研發實現能力在方案設計的過程中還是要考慮的。
方案落地前，進行一定的內部測試或評審是很有必要的，介于還沒有完成開發上線，可以在優化方案出來后通過Demo的方式找人進行測試反饋，一般自測走查只是第一環，有不確定的一定要拉上其他人一起研討評審一番，如果要找人測試的話，其實只要設定好合適的任務與目標，還原出真實用戶碰到問題的任務過程即可，接著就是觀察測試者是如何使用Demo的，你的新方案是否奏效我想你知道怎么去衡量，就不贅述了。
優化后階段我們主要關注是否優化了個寂寞，是不是又優化出了新問題，優化后還有哪些收尾工作，關聯的需求池與迭代規劃怎么安排。
當一個方案被投入到生產環境中，我們卻無法得知是否比舊的方案更好，這種情況是很糟糕的，故我們在新的方案推出的同時，一定要保障有辦法收集到有效的用戶反饋，這個過程我們可以是采用AB測試、數據埋點監測、灰度采樣、用戶使用性測試等，這都是我們實際工作中采用的有效手段。
始于數據采集，采集后自然是與原始版本的效果進行比對，確認新的版本是有效可靠的，能被用戶認可采納的，同時也能發現新的問題反饋，這需要進一步的跟進與規劃，這是個重點環節。
原始問題是否圓滿結束，是否有新的問題待解決，是否需要分批開發上線或驗證，調整后其他部分是否需要配合改造，這一系列問題將迫使我們持續改進，并將流程再一次的接軌到優化前階段。
PDSA是指“計劃-實施-研究-實施（Plan-Do-Study-Act&Amend）”，屬于一種精益方法，常用于衡量變更的有效性，部分企業的專有云解決方案架構師也叫做PDSA，并且有對應的平臺組織與PDSA執行流程。
PDSA這一流程可以靈活迅速的發起并驗證效果，四個步驟分別如下：
而PDCA則是指“計劃-實施-檢查-行動（Plan-Do-Check-Act&Amend）”，檢查主要就是驗證效果是否有效，有效的則應用或標準化，沒用的則繼續改進，相比下，PDSA的內涵會更廣泛些。
SDCA是指“標準化-執行-檢查-總結（Standardization-Do-Check-Action&Adjustment）”，跟PDCA有些類似，主要差異在于第一步驟；
-
標準化(Standardization)：識別和定義改進過程中需要標準化和優化的關鍵步驟和流程，例如軟件系統的交互規范化、場景模塊化、系統設計、流程統一等，亦或是產品客戶端的操作手冊、新手引導、統一操作流程、測試用例、準入門檻等標準化內容。
SDCA循環法的目標是實現持續改進，可以減少重復性問題再次發生、精簡和標準化執行，形成可靠、準確、高效的結果，是一種結構化的迭代的方法，且適用領域廣泛。
針對任務鏈路優化工作的場景，以下我給出了一些常用的優化方法或工具，并酌情說明了使用場景與小型案例幫助掌握，當然了你也可能都掌握了這些，甚至有更進階的方法或工具，那么也歡迎你補充或留言交流。
其核心思想是在面對多個任務或配置項時，通過分析任務之間的依賴關系和優先級，將那些不需要前置條件、相對輕量級和快捷的任務優先處理，其優勢在于能提高整體效率，還能讓用戶在完成前面步驟后獲得一定的成就感，從而更有動力繼續推進后續事項。
適合復雜流程改造、復雜的表單配置相關、大量的事項處理場景、非線性的多任務處理場景等。
當然也可以根據此原則將前置條件整合處理，這樣在后續的任務路徑中就可以減少相應的條件卡點，例如大量安卓應用第一次安裝啟動時就會向用戶索要存儲、錄音、相機等基礎權限，那么之后使用相關服務時，就不用觸發授權窗口了，不過權限還是要遵循用戶隱私政策法規哈。
就是將復雜的任務進行拆分，通過循序漸進的方式一點一點完成任務，這樣可以減少任務達成的門檻，讓用戶使用更順暢，并且可以在過程中培養用戶的意識，是任務鏈路優化的常見手段之一，也是游戲新手村屢試不爽的教學模式。這個方法的應用案例跟文章快被寫爛了吧，這里就不展開了。
該方法常常會應用到復雜的任務流程引導，如分步驟表單配置、功能進階解鎖、線性任務指導、新用戶引導等場景。
1、制定核心的目標或任務鏈路，確保有效的漸進過程；
4、采用簡潔準確的引導提示，以及適宜的獎勵或反饋機制；
5、結合用戶的使用偏好或認知，要讓推進的過程盡可能自然易用；
通過規劃使多個任務事項穿插或并行開展，本質就是任務事項的拆分管理與資源規劃協調，通過使更多事項同時或盡早進行，來加快任務目標達成，以效率來推動任務鏈路優化的目的，也可以理解成是碎片化時間利用。
多個任務流程進行且涉及審批、協同、傳輸、自動進行等情況時；
在資源規劃協調時，可以通過時間、狀態兩方面下手，重復的、自動的、久等的、卡點的可以考慮先行，然后再處理其他瑣碎事項即可，反正當你事項多，又想省下時間提升效率，就一定考慮下這個方法；
即我們常說的用戶分層，通過提供差異化的服務或任務路徑來對應不同的用戶群體，以減少無效或干擾的流程操作，為目標用戶提供更好的體驗質量與業務場景偏好滿足等。
業務用戶群比較豐富，不同角色的任務場景差異較大，需要更沉浸或專業的交互時。
通過科技技術的應用，可以為用戶帶來更多的便捷與新鮮感，特別是具備商業屬性的技術，會更快地成熟與普及，然后影響到更多人的生活方式。這個過程可以概括為“科技-認知-應用-習慣-直覺”，就像現如今的掃碼支付、人臉識別、指紋解鎖一般，不僅在各種領域都有了應用，并且你一看到相關信息，直覺就會引導你該如何操作。
在當前技術實現還不夠優雅或是遇見過更好的技術應用時，則可以考慮去應用新的技術或是與當前業務做融合創新。
面對各種復雜的操作、選擇、輸入輸出時，盡可能的枚舉出選項或模板，這樣用戶操作會更規范也不容易困惑，對于那些用不了或有特殊含義的內容則通過樣式、組件、提示等進行合理的約束，避免任務流程出錯，也幫助用戶識別與理解，例如報錯信息就要約束用紅色反饋，電話號輸入就要約束為數值輸入等，事實上這應該是交互設計師的基本功吧。
這個是我個人一直以來認為人機交互工作中的根基，適用于絕大多數需要進行組件交互或行為交互的場景。
交互內容是否有任何格式約束、內容模版或是注釋說明；
一個老生常談的方法，可以幫助我們深入問題和洞察底層含義，用法就是面對問題不斷的追問為什么，在任務鏈路優化中，主要可以幫助我們分析和定位問題根因。以過濾偽需求為例，面對老板提出的需求，如果你不去深入一下，你就不會明白做這個需求究竟是解決什么痛點的，那么做出來以后，這個需求就有可能出現沒有解決老板痛點的情況，甚至可能出現新的問題，因為這個需求本就是偽需求。
適用與大多數復雜問題或需求的分析場景，主要是對需求或問題不夠清晰
簡單講就是在解決或優化任務鏈路的時候，帶上人物、目標、行為、環境、時間諸多因素綜合性思考，形成一個更完善而真實的洞察環境，以幫助獲取更多有價值的優化信息，此前有出過一期關于場景化思維的專欄文章，寫的比較詳細，有興趣的可翻閱一下：
ESIA是企業流程優化中比較出名的方法，但也不僅限于企業流程優化，其核心理念就是減少流程中非增值活動，以及調整流程的核心增值活動。由消除-簡化-整合-自動化（Eliminate-Simply-Integrate-Automate）四個步驟構成，只看名字好像有些理論派或假把式，但拆開后的一些具像化步驟或方法還是有用的，作為一款優化工具或流程思路我是認可和采用過的，就像是“CRAP設計原則”一樣，高大尚的字母縮寫名下卻藏著樸實無華的好東西。
「注釋：CRAP設計原則 = “親密性、對齊、重復、對比”設計四大原則」
這個方法我有一個小口訣，大伙兒可以參考下“去掉多余的、留下能懂的、排成有序的、減少人工的”
我們的代碼腳本工具升級，從客戶創建到腳本配置執行的復雜版本，到簡化的極速版本發布，其中整合了用戶主流的腳本工具訴求，然后消除了復雜冗長的配置過程，簡化了操作門檻或功能復雜度，并創建了多條主流自動化的極速版本來支持業務，反饋和數據都有了明顯轉好
是工業工程學中程序分析優化的四大原則，主要由取消-合并-調整順序-簡化（ Eliminate-Combine-Rearrange-Simplify）構成，其實不必糾結這些分析法的刻板步驟或叫法，多看一些你會發現萬變不離其宗，作為優化思路或策略，找到合適的方法并靈活的施展其實更重要，沒有人說必須要按照這些分析法按部就班。
-
取消( Eliminate)：首先是根據規模、階段或目標，考慮哪些是可有可無的，或價值有限的，能換掉的就換掉，能去掉的就去掉。
-
合并( Combine)：在不影響最終目標與質量的前提下，根據某些屬性，將多個工序進行合并或融合。同時也要考慮融合后的體驗與兼容性，如若不然就不要強制合并了。
-
重排( Rearrange)：即將相關的工作流程或內容進行新的順序調整重組，以滿足更合理更流暢的結構，例如減少了流程往返操作的不便、先易后難的配置表單。
-
簡化( Simplify)：不是取消或減少而已，而是經過以上工序后。將剩余的或整體進行簡單化、完整化、便捷化、智能化處理，可以是新技術應用也可以是交互方式的調整不等。
任務鏈路優化的思路或方法肯定還有諸多，例如《簡約至上》中提到的刪除、組織、隱藏、轉移的應用等等，這里不再列舉了，實際上掌握或了解幾條比較實用的就差不多了。
都是一些比較日常輔助工具，只是希望在大家的優化工作中能夠提供一些幫助，如果你已經熟練掌握這些工具的應用，那就請忽略這部分哈，請直接前往最后的篇章總結吧。
○思維導圖：可以快速幫助我們對信息進行樹結構化與邏輯整理，并且可以結合圖文以及功能圖標等來完成管理及計劃，能夠將業務或功能框架快速顯現出來，是很好的輔助工具之一；
○矩陣表格：可以很方便的將信息進行羅列與比對分析，在一些信息介紹或數據分析時常常會用到；
○服務藍圖：可以將完整的服務過程繪制出來，能夠包含人物角色、前后臺關系、階段過程、狀態扭轉、交互觸點等；
○體驗地圖：可以將服務、目標、用戶、交互、反饋進行階段化整合分析，本身是挺好的工具，只是設計師作品集中的用點兒虛，但不影響自己拿來實用；
○泳道圖：可以根據時序對流程進行可視化，可以很好的傳達職能部門或是角色之間的交互過程，也可以細分交互媒介、服務終端等因素之間的關系；
○流程圖：主要就是圍繞一個事件的開始到結束過程的流程可視化，流程圖可以系統化的梳理業務邏輯與交互鏈路，泳道圖也僅是流程圖的一種，相信大家都很熟悉了，就不過多贅述了；
○魚骨圖：是一種根因分析工具，有頭有尾有分支，像魚骨，常用于定位問題發生所導致的根因，也可以用來制定任務目標進程的管理；
○狀態機：一種針對事件狀態扭轉關系的流程圖，用于描述系統的狀態和事件，以及事件引發系統在狀態間的轉換過程，有點像是一系列的if語句，在中后臺的系統設計中常常會有需要梳理狀態的情況發生；
○業務框架：業務框架主要是一種將業務過程和活動進行組織和分類的方法，具有較大的顆粒度與較強的全局性，常用于表達業務框架單元之間的組成與活動關系。而業務模型主要是指業務概念關系的可視化簡圖，前文的流程圖、泳道圖、狀態機等等都可以是業務模型；
○交互自檢：主要用于交互設計的查缺補漏跟避錯，同時在交互鏈路自檢的過程中是可以主動發現問題，并驗證優化是否可行或合理；
○使用性測試：也叫做可用性測試，是對優化結果或Demo進行測試檢驗的過程，通過模擬真實的任務操作過程以達到洞察、探索、比較、效果驗證等目的；
○A/B測試：常用于方案之間的效果比較或驗證，通常都是借助工具引流獲取一批真實用戶的測試反饋，是一款真實有效的驗證手段，不過方案之間的差異不宜過于懸殊；
○數據漏斗：像任務鏈路這種多線程或是節點較多的事件，單薄的點擊率或轉化率的作用是很有限的，這時候就需要在相關任務節點上布滿更多的埋點，將用戶流量與數據轉化的情況用漏斗視圖表現出來，然后就可以針對任務鏈路進行分析或比較了；
本次主要是分享了對應優化工作中的一些技巧與方法，對于文章我很清楚看完和消化需要很多耐心與時間，這不像視覺作品來的那么接和輕松，寫到這里已經大幾千字了，最后鋪一張框架大圖幫那些看完腦袋空空的同學回顧一下；
