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