程序員說系統體驗

    這篇在腦子翻滾了一成天了，上午開始構思到如今才能動筆。

    在如今的團隊又啓動了系統的體驗升級工做，催來催去的不見成效，因此上週沒忍住，本身又冒出來，把如何作體驗從頭分析了一遍。想一想仍是要裏面的要點寫下來吧，積累起來便於後續使用。

    首先咱們來解決兩個問題，第一個體驗升級工做不是什麼；第二個體驗升級工做是什麼；

    首先，體驗升級毫不是一羣人坐在電腦面前，看着一個軟件界面，而後你們說這個很差看或者這個挺好看，是否是挪一下這個按鈕。這是拍腦殼，是很難拍出好的體驗的。

    而後，體驗升級是什麼呢，是來解決三個問題的，第一個是「認知障礙」；第二個是「操做動線」；第三個是「價值引導」；

    由於我是作後端系統研發爲主的，因此我只分析前兩個，最後一個不分析了。

    在開始分析上面內容以前，咱們先來講說，體驗的好與壞的界定。一個軟件系統的界面設計必定是分好與壞，可是你們每每只能給出很感性的評判，好比很差看、用起來很彆扭等等，這些評價是很難映射到具體的設計中的，因此體驗提高就變成了一件很是難的事，猜別人是怎麼感知你的軟件的命中率必定會很是低。

    因此，我把一個系統操做環節分紅了3個階段來分析，那就是「事前」、「事中」、「過後」。

    事前和過後，是你們特別容易忽視的地方，通常想要提高一個環節，咱們大都徹底針對這個環節的過程去分析和優化；這是不對的，這意味你把它視爲一個點，徹底孤立的點，可是咱們都知道，沒有什麼是獨立存在的。每個環節必定有前置工做和後置工做，甚至有協同工做，把他們都連起來纔是一個完整的動做，因此拋開先後左右只分析當事環節是個低效、低質的動做。

    事前主要是指前置動做和前置任務，舉幾個例子好比：想看微信的消息首先你要解鎖手機、寫文章以前首先要構思、操做收貨首先你要知道收貨這個功能菜單在哪裏、想上架貨物你要把貨拉倒貨架邊上......等等不少吧（爲了適應性高點，因此例子用的都不是軟件系統的），以上的內容很明顯就涉及到認知障礙，全部前置動做都涉及一個問題「我怎麼知道！！」咱們習覺得常的動做並不都是合情合理，因此一我的要作某個動做首先必定是他怎麼知道去哪作，而後緊接着要問怎麼作。再舉個例子，咱們都知道iphone的指紋識別在home按鈕上，可是三星的指紋識別在手機背面的攝像頭邊上，Sony的指紋識別在側面的電源按鈕上，是否是涉及「我怎麼知道！」問題了，打破常識是很是重要的動做，常識是一種約定俗成的協議，可是你肯定你的協議和對方的是互通的嗎？豆腐腦究竟是放糖仍是放滷呢？

    事中是你們研究的最多的，很少說了

    過後主要是指後置動做或者收尾動做，咱們確定都會跟蹤任務的進展，「跟蹤」是一個後置動做。好比吃完飯老是要刷碗的吧，刷碗確實不是吃飯的一部分，可是很強烈的影響了一批人的決策，想到在家作飯要刷碗就乾脆出去吃飯吧或者點外賣。

    因此事前-事中-過後，串起來纔是一個完整的動做鏈，優化動做要全盤考慮，不能只是考慮事中。   

    認知障礙

    上面已經對認知障礙作了一些分析，你們是否是清楚什麼是認知障礙了，認知障礙就是設計者認爲用戶知道可是用戶可能不知道或者不能清楚的知道的部分，更可能是你們在於成長、教育、工做經歷的不一樣因此在認知上生成了不一樣的認知樹，可是又認爲互相是一致的，又涉及設計者缺少同理心，作不到換位思考，因此默認認爲本身想到的東西就全部人都知情了。仍是不清楚的就本身延伸一下，琢磨吧，不贅述了，想深刻的兄弟能夠看一下批判性思惟。

    軟件中如何解決認知障礙呢，這裏咱們不分事前-事中-過後（區分的話要寫太多了）的說有幾種辦法

    第一種將文檔和軟件融爲一體，能夠在每一個控件邊上添加儘可能多的解釋，可是這樣界面看起來確實比較繁雜，可是繁雜的界面也是比徹底不知道如何使用要強。

  也能夠製做很貼近的幫助系統，咱們都知道在微軟的軟件中按F1你必定能夠獲得幫助，若是作過.Net開發的必定很懷念MSDN是多麼強大，因此也能夠用優秀的幫助系統來解決。

    第二種使用圖形化系統，前幾年流行過用各類直觀的符號來製做軟件，既避免了軟件上有厄長的說明又能夠啓到很好的引導效果，並且看起來軟件很高大上、超級簡潔，可是「直觀的符號」這個東西原本就帶有認知障礙。

    不列更多了，你們搜一搜應該都能搜到。

    總而言之，無論用哪一種方法或者各類方法混合使用，要解決最關鍵的問題就是要讓軟件如何「自描述」，善用上下文、不要吝嗇作銜接、作一些文檔、引入一些直觀的符號系統，站在用戶的角度多思考必定能夠解決認知障礙。

    應用軟件設計中特別廣泛且嚴重的問題就是開發者對使用場景的上下文和銜接忽視的特別嚴重，由於每每這一個功能是由一個或者多個開發者開發，上一個相關功能是由另外一個或多個開發者開發的，開發團隊的分工自然就是以一個一個的點在開展。作應用系統的產品由每每關注點又在業務上，因此沒有人來串聯上下文。銜接這個問題是最逗的，基於上面的開發模式軟件系統天生在銜接上就有短板，而後每每產品或者開發者還特別傾向於設想我提供了一個超級自由的場景，因此每每是原本相互關聯的環節反而散列在系統中，沒有任何銜接動做。這種軟件真交付了，用戶就精彩了。其實這是同理心和設計缺少模式的體現，大部分應用系統的產品經理都是說業務頭頭是道，說系統設計徹底不通，這樣是作不出好的軟件來的。

    操做動線

    解決了認知障礙後須要解決的下一個問題是操做動線，動線是從家裝行業借的一個詞，本意是爲了規劃傢俱和活動的分隔，讓家裏的人有合理的移動方式。咱們借用過來放在軟件系統裏，用來規劃操做人員在界面上的處理路徑。合理的處理路徑能夠下降認知障礙提高處理效率。

    下面是咱們某個系統早期設計的動線

 

    你們能夠看到明確的操做路徑，可是這個在落地後仍是有不少不舒服的地方，主要體如今動線過於單一，沒有回饋動線等問題上。設計動線意味着咱們對用戶的操做是有預期的，這個很是重要。有預期就意味着咱們在腦中正式的模擬過用戶的操做流程，並由此對用戶和系統都做出了相應的調整。這樣系統和用戶在操做上有基準可做爲溝通的基礎。

    以上我想就是系統體驗升級的內容吧，原定還要寫插件化和配置化所帶來的問題，仔細思量上面的內容都是關於界面優化話，因此咱們把插件化和配置化後續單獨寫一篇。但願上面我寫清楚了