大學美術史（選修）的第一堂課上，那老師開門見山的說：知道大家認真聽課的不多，下節課能來多少也不知道，這裡介紹一個自學閱讀的辦法，方便你們抱佛腳，在我看來大部分書籍講的實質性內容都很少，這就需要擰乾提純，發現一本書有用之處最有效的方法是看目錄，大家能消化掉美術史這本書的目錄就能考60分了。對於其它休閒類書籍你大可從目錄裡面選擇自己有興趣的章節閱讀，感興趣的章節對你來說就是乾貨，整個目錄你都不感興趣的話，那這本書就杯具了…不知道其他同學的感觸，我後來閱讀一直用這個方法，此技巧甚至可以列入我大學所學有用知識前十強，其它九強已然忘卻。
其實一本書寫好之後放在那裡就是按照作者意圖設定的靜態結構存在，但是讀者看書時沒有必要建立和作者一樣的結構，對個人來說是完成一個任務的過程。任務如果和結構吻合是好事，如果不吻合那就痛苦了，很多人很可能還沒看到有用的地方就合上這本書終止任務了。新華字典就有一個嚴謹的結構，使用者需要認證學習才能掌握使用方法（也就是了解字典結構）進而完成查字典的任務；兒童識字卡沒有自己的結構，甚至可以一頁頁拿下來，同時兒童的任務也是最簡單直接的，認識一個字和另外一個字都是獨立的任務，不需要建立聯絡。
這位老師介紹的方法實際上把我們從執行閱讀任務依附於書籍結構的習慣中解放出來。書籍的結構和讀者的任務是可以不對等的，你願意讀哪一頁就哪一頁。這可以類比到APP的結構與使用者的任務，APP都是按照固定結構上線的，使用者在使用過程中完成的確是一個個獨立的任務，這就是為什麼雲閱讀後臺常看到：離線下載後去哪裡檢視啊？搜尋去哪裡了？這類反饋的原因，因為使用者不關心你是什麼結構，只要在完成任務過程被終止了他們就會抱怨。當然了設計師也會對著悲慘的資料說：此按鈕如此明顯怎麼使用者就不知道去點選呢？網易雲課堂的課程詳情頁右上角有個大大的按鈕“參加該課程”，But資料顯示使用者就是不去點它，理由很簡單，使用者執行自己的任務時不會想到用它，你就是弄個閃電雷鳴的提示效果都不會大，傳言設計師後來在目錄中加入“課時預覽”就好多了。
使用者很坦然，微信滿足不了他們約炮的慾望，可以改去陌陌。但是設計師就忐忑了，網易雲閱讀的產品結構滿足不了使用者的閱讀任務時就會流失他們。所以作為設計師要最優化的解決APP結構與使用者任務間的關係，如何優化？我們先理解一個APP結構是個啥；再來看看被解構的APP如何組裝起來已滿足使用者任務。
第一、解構APP。設計師都可以輕易的知道“APP是由頁面組成的”，但這又是一個毫無意義的結論，那麼我們來嘗試站在“頁面”這個角度巨集觀和微觀的看一下，借用一個口語就是——向左看向右看。
1、向左看，APP的世界裡有三個頁面：聚合頁、列表頁、正文頁。聚合頁匯聚了各個模組的入口，從這裡使用者可以選擇要去的地方，比如網易雲閱讀的首頁，裡面有使用者訂閱各大資訊源；列表頁就是純粹某項內容的列表展示，如果你進入網易雲閱讀的某個訂閱源就可以看到這個頁面了；內容頁是最底層的內容展示頁，使用者在內容不能再往下走層級了，當然了橫向串動或者向上跳是可以的，對應的就是你在網易雲閱讀裡面看某篇資訊詳細內容。
2、向右看，一個頁面總是由三個元素組成，主內容、頁面工具、頁面操作。主內容必然存在，即使是空態都會展示個哭臉之類的。拿書籍正文頁來說，這本書的文字就是主內容；頁面工具用來改變一些展示方式，如：字型大小、夜間模式、亮度；頁面操作含資訊的處理路徑，如：評論、分享、加書籤、檢視書籍詳情、複製、剪下。
這三個頁面組合在一起，僅內容頁不夠時加上列表頁，不夠再有聚合頁。每個頁面自身的內容、工具、操作又會有序的組合，這樣就形成一個封裝好模組，這個模組對外以節點方式溝通，多個模組組合在一起就形成一個結構化的APP。這裡舉一個艾菲爾鐵塔的故事：艾菲爾鐵塔，組成零件有18038個，重10000噸，施工時共鑽孔700萬個，使用鉚釘250萬個，設計圖紙5300多張，其中包括1700張全圖，在18世紀的時候施工僅用了2年2個月。因為事先嚴格的編號，施工過程沒有做過任何改動。所以當我們面對一個APP設計時，不要擔心它的複雜，並不是複雜，而是由此帶來的混淆狀態和無條理性讓我們擔心，APP能複雜過300米高的鐵塔嗎？
第二、APP解構後的各個模組及頁面自己的內容、工具、操作如何通過組合來更好的吻合使用者任務，是互動設計師發揮的地方之一。常用的手法是使用者研究，去研究自己設想的目標使用者，其實獲得這些資料和結論後要用在結構上同樣需要費一番心思，相當於準備了做菜的材料和知道了吃飯人的口感偏好之後如何把菜炒出來。
1、放羊，讓使用者決定模組間的組合與穿插。卡片分類法就是一例，雲閱讀的各個模組歸類時就用過，其中本地書上傳模組的入口就被認為應該在書城裡出現（我們實際放在“我”這個模組裡）；APP頁面工具佈局時，有時侯過份強調一致性、統一性，會忽視使用者任務的隨意性、連貫性，雲閱讀的使用者在任何頁面隨時想使用夜間模式，總沒人希望在家裡關書房的燈需要去客廳按下開關吧，所以雲閱讀的winPhone客戶端就在首頁Appbar中放入夜間模式開關，同樣的功能在正文頁與設定的列表頁都有；有個小區建成大概有六年了,樓與樓之間有草坪和大道,但沒有小徑.如此一來,人們自覺不自覺地會抄近道,踩踏草坪.於是管理人員豎起牌子嚴厲提醒大家:請勿踐踏草坪，但根本不奏效。時間一長，草坪上就形成了許多不規則的小徑。管理人員生氣了，把小徑重新整理成草坪，並在出口和入口處攔上繩子，起初似乎好一點，後來又恢復原樣。如此幾番折騰，他們終於悟出了道理：沿著自然形成的小徑鋪上石板，讓人們心安理得地行走。草坪有了小徑的點綴，也顯得更有情趣（這個案例引自網際網路）。APP產品中放羊放的比較好的還有註冊這個功能模組，現在新舊APP都允許用各大社交平臺帳號登入，在這之前是每個APP都強制使用者搞一個帳號，說白了就是為方便推送廣告，但也直接攔截掉了至少一半潛在使用者，得不償失。現在使用者愛用什麼社交帳號登入隨意，而且這種方式瞬間成為標配，就是結構追隨任務的例項。放羊的方法是使用者最樂意看到的，但是產品方很不樂意，設計者也容易被弄暈，有時候一個功能模組需要在另一個功能模組的三個頁面都放入口，這個還好點，關鍵是一些使用者永遠不需要的模組怎麼辦，放到哪裡都不是使用者希望的？這就要用到下面的濫竽充數了。
2、濫竽充數，對於使用者不希望的模組，可以悄悄得植入以實現產品目標。就是讓使用者看著這個產品很順眼、很好用，但是裡面確實有產品植入性的東西。比如雲閱讀的猜你喜歡模組，在使用者讀完一篇文章和每個訂閱源詳情後都跟著猜你喜歡。這些推薦都是追隨型別相關性出現的，如果你正在閱讀的是三胖幹掉姑丈的新聞，我們就會猜你喜歡早期三胖機關槍掃射銀河樂隊這類事件。當然，濫竽充數讓使用者識破的例子也很多。很多APP中的頁面底部廣告就是典型例子，這個頁面操作讓人不惜關掉網路以換取安靜純粹的看書；雲閱讀首頁右上角總是掛一個訊息提醒的Icon（屬於頁面操作），碰巧如果你的郵箱悲催的被各種垃圾郵件干擾，這個Icon會不厭其煩的給你彈出氣泡，這個氣泡對你其實沒什麼用，因為你不care這些郵件，然後很多使用者就來詢問哪個地方有個關閉通知的按鈕（反饋系統看到的）。有時候濫竽充數沒做好的同時設計師還不忘給使用者閃個Tips，彷彿吼著說“看，我在這兒”，鬼才願意看到。新功能Tips提醒也是同樣討人厭的濫竽充數，更新或下載一個APP後總是各種提示諸如“點選這個釋出動態、這裡新增好友”，真的等使用者任務到了要用此模組且不知道怎麼辦的時候，結構確給不出回答。另一個場景是這樣的：你選擇用掃一掃加一個朋友的微信，到“新增好友”模組卻找不到掃一掃，而對方此時虔誠的舉著個二維碼略帶蔑視的看著你，經過一番周折你可能終於在“發現”模組裡面找到了掃一掃（也可能換其它方法），雙方一陣嘖嘖，你內心估計會嘀咕一下微信：這是咋整的！我們避開業務層面的（掃一掃功能增多了）討論這個現象，使用者的任務確實就是在“新增好友”時需要用到掃一掃，這就是說，這個悄悄移位的的舉措一下子就讓使用者感覺到不適了。
3、照葫蘆畫瓢，遵守使用者在其它APP上的既有習慣，組合各個模組和佈置頁面內容、工具、操作。雲閱讀4.0版本的模組的結構有好幾個方案，最後用的是最大眾化的底部導航，使用者熟悉這種互動方式是選擇此方案的原因之一。教育使用者這種事就像第一個吃螃蟹的人——付出的多收穫卻不一定豐厚。米聊大家還記得莫，國內移動網際網路即時通訊最早期試水者，微信將其秒殺後，模組結構卻基本被沿襲下來（當然了也可能是巧合）；再比如下拉重新整理這個已經全民皆知的習慣，最早來自Twitter，而且也獲得了專利，現在APP中遇到列表頁需要重新整理內容時不用下拉重新整理試試？這種頁面工具我們們大可不必去創造新輪子。在所有的APP裡“設定”模組其實像一個垃圾桶，設計師覺得不重要又不好去掉的東東都在裡面堆積（相對來說產品經理更擅長做這件事），這樣做的好處就是使用者的任務實在走不下去了設定可以來彌補，使用者用的不舒服卻沒其它辦法時就會來設定裡淘淘寶試試運氣（從使用者反饋中可以看到這些習慣），所以頁面工具在設定中基本都要有，正文頁有夜間模式工具、設定中也要有，設計時諸如此類往往需要照葫蘆畫下來。
4、騎驢看賬本，邊上線邊改。現在的APP幾個月不換個結構出個版本都不好意思和別人說這個專案還活著。雲閱讀winPhone端有一個模組是離線下載，之前離線下載完成後的資訊分佈在各自訂閱源內，使用者就跑來吼了，下好了不知道去哪裡看，這不是浪費人家流量莫；然後就多出一個模組：離線資訊，設計師在離線資訊聚合頁中放了個離線下載的入口（頁面操作）被各方否決，理由是這個會串到離線模組裡去，而且首頁Appbar原來就有離線下載入口，於是就沒有加；上線後使用者又不樂意了，離線資訊裡面想去下載不知道怎麼辦，最後我們又順速補上這個入口，因為使用者任務在這裡需要而且也是常理，結構最好滿足它。細算一下為了這個事情就有三個版本，不過騎驢看賬本還是蠻管用和常用的，這裡對廣大使用者的期望就是你們要多吐槽啊，不管通過什麼途徑，你們一句有時侯頂我們設計十句。
以上說了四種方法，那麼神馬時候這個APP算是有譜了呢？當設計師一時描述不清APP結構時，說明很吻合使用者任務了。以張三丰與張無忌的對話舉例（電影版倚天屠龍記）：
無忌，你記住了沒有？
嗯，沒記住…
這套叫什麼拳？
不知道…
你老爸姓什麼？
我忘了。
好！只要記著把這兩個混蛋打得不成人形就是了~
還有一個和描述不清APP對立的現象是這樣的，公司新人接觸一個APP時總能提出巴拉巴拉一大堆不符合使用者任務的問題，這時候深陷其中的設計師會禮貌的回答：“嗯，這個我們會考慮的。”當然了大多數情況下是不會改的，這可能是設計師已經忘卻最初目標，這類現象很常見，畢竟80%的APP都不是很成功。
其實不管是解構還是重構APP，都需要時刻知道自己從哪裡出發的：勿忘初心。
特別感謝網易識字的視覺美眉魏同學的配圖（最後一章），前面的撮圖都是我自己畫的。