原文：http://scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack
嗨！這篇文章，是我十二月會在歐萊禮出版的新書《設計人們喜愛的產品》（Design Products People Love）的摘要。在這本書中，您可以讀到超過二十位來自 Facebook、Twitter、Slack 等團隊的設計師的訪談，從中學到他們如何工作。
你是否曾經用過死氣沈沈的使用者介面呢？你是否也曾經設計過好像 — 少了些什麼 — 的 UI？
如果是的話，你所遇到的，可能就是我所謂的「壞 UI」（Awkward UI）。
壞 UI 是什麼？可能是少了個載入進度指標、可能是忘記告訴顧客現在有個東西出錯了，如果這時候還跳出一個可怕的錯誤訊息，更可以在壞 UI 這方面加上好幾分。壞 UI 可能是只有少少幾個資料點的奇怪圖表，或是在有新資料的時候，會硬生生的跳出來。
還是不懂什麼是壞 UI 嗎？來舉個活生生的例子：我經常使用 Apple TV（事實上，當我在寫這篇文章的時候，我一邊就用 Apple TV 播放《星際大戰：反抗軍起義》）。每次當我把游標移動到「已購買」的影片上時，就會出現以下畫面：
每次看到這個畫面的第一秒鐘時，我嚇壞了。為什麼？因為我沒有看到載入進度指標（loading indicator）。在畫面中沒有任何載入進度的提示。經過幾秒鐘，我的腦中就浮現各種恐怖的念頭 — 我的電影到哪去了？被刪除了？被偷走了？
不久，在我的心跳稍微緩和之後，我擁有的電影就突然毫無頭緒的都跳了出來。
老天，真是刺激。
與此相較，當我用 Apple 遙控器按下「播放」按鈕後，我看到一個很不錯的載入進度指標，告訴我 Apple TV 正在準備播放《回到未來》。
注意到這兩種體驗的差別了嗎？
產品設計師的任務，就是打造讓人們容易理解的使用者介面，以對抗電腦其實很懶惰這項悲哀的事實。電腦根本就不關心怎樣讓人們了解有什麼新東西、接下來該怎麼做，還有在事情有問題的時候人們該怎麼做。
在電腦的理想世界中，在遇到發生問題的時候，電腦只需要把意義不明的錯誤代碼丟出來，或是發出是恐怖刺耳的警告聲。最好呢，電腦只需要跟你用二進位碼溝通就好了。
但我們講的不是二進位碼這種語言。我們使用流程思考，我們也只生活在物理世界中。如果門開了，你可以看到門在門框中搖晃；如果有東西在移動，你也可以看到移動的軌跡；如果有東西掉下來，你會看到這個東西會在地上彈起來。
如果產品設計師不考慮這些事情，就會做出壞 UI。壞 UI 便是，在操作的過程中，有些不該被打破的規則被打破了。
是怎樣的規則呢？
就是「UI 堆疊」（UI Stack）這項規則，也就是我們現在要討論的主題。
UI 堆疊
在任何數位產品的每個你會操作的畫面中，都有多個不同的面目。
確切來說，有五種面目。
在各種不同的情境下，這五種面目會逐一展現在你的顧客面前。用設計的術語來說，我們管他們叫做「狀態」（States）。而你必須要在設計每一個畫面的時候，都妥當這些不同的狀態。
原因是，遵照 UI 堆疊以及這五種狀態的規則，可以讓你打造容錯、有用、而且人性，最後讓用戶黏著的 UI。
老實說，你最後一次設計只有一種狀態的畫面，是什麼時候？就算你設計的只是個天氣 App，也不可能只有一種狀態。
現實就是，我們活在一個不完美的世界中，而且事情一定會有出錯的機會。伺服器需要時間回應，而你的用戶也總是不按照預期的方式使用你的產品。
所以，身為產品設計師，你必須要在心中牢記這樣的現實。
因此，在你所要設計的產品中，最多就會出現這五種狀態：
- 理想狀態（Ideal State）
- 空白狀態（Empty State）
- 錯誤狀態（Error State）
- 局部資料狀態（Partial State）
- 載入中狀態（Loading State）
當你的顧客在你的產品流程中不斷移動的時候，他們其實也就是在經歷這五種狀態的改變：
如果你想要看看 UI 堆疊是怎麼運作的，可以點選這邊：UI 堆疊的雛形。
說起來你可能會吃驚！我們現在要簡短插播一下 Internet 的歷史。回到 2004 年，Basecamp（之前叫做 37signals）這家公司寫信給我，給了我一篇叫做〈三種狀態的解決方案〉（The Three State Solution）的大作（呃，請不要搞混了，這篇文章不在探討如何解決以巴問題）。他們認為每個畫面都可能會有「標準、空白、錯誤」三種狀態。我受到了強烈衝擊，並且從此永遠改變了我對網頁設計的想法。
但是 Internet 總是在不斷改變。起初，出現了革命性的 AJAX，再來，出現了行動裝置 App，第三，便是出現了科技的大眾消費化。對於 UI 的需求與期待都改變了。在這邊所寫的，是我自己將上述這個超過十年的想法，重新消化之後的版本。
說到這裡，我們來談談理想狀態。
理想狀態
我把理想狀態放在第一位，是因為這是你最希望人們看到的狀態。之所以叫他理想狀態，是因為這就是你的產品潛力發揮到了頂峰的狀態，你的產品可以提供最高的價值，以及充滿了有用、豐富的內容。這個狀態也是你在設計畫面的其他狀態的基礎。你不妨把這個狀態想像成是 App 傳單上的畫面，或是 App Store 裡頭的截圖。
這個狀態會設定其他狀態的基調。因為當你反覆修改你的核心介面設計，整體 UI 也會隨著時間完全改變。這就是修改設計的美麗與危險之處。
而這會對其他幾個狀態，都會有深遠的後續影響。
所有的 UI 狀態的最終目的，就是讓 App 進入這個理想狀態。所以我們會從這個狀態著手，然後當你的設計慢慢可以解決顧客的問題的時候，再來處理其他狀態。
還是不懂理想狀態是什麼意思嗎？我們來看幾個清楚的例子。
空白狀態
空白狀態不該只被僅僅當做是個畫面看待。而是，當你想要向顧客介紹你的產品時，你可以在這個狀態中為他們營造不可思議的第一印象。 — 鼓勵他們行動，吸引他們的興趣，並且提醒他們你的產品可以提供怎樣的價值。
廣義來說有三種空白狀態。首先是用戶第一次開始使用你的產品時看到的畫面；其次是用戶把目前畫面中所有資料都清除掉之後看到的畫面，像是你達到「收件夾全空」（Inbox Zero）成就時的畫面。再來則是，就是沒有資料可以顯示時的畫面，像是找不到符合的搜尋結果時的狀況。
在設計空白狀態的時候，最容易遇到的風險，就是這個畫面很容易影響用戶看到之後的後續想法。很多時候，空白畫面往往會形成一種冰冷、不人性的整體體驗。
教練標記（coach marks），或是覆蓋提示，就我來看，可以說是最不經審慎思考的首次使用體驗。這些提示增加了顧客的學習負擔，包括要學習額外的介面、要有額外的記憶，然後要在這個打斷流程的畫面中一次做完。真讓人難過。
我們來談談首次使用時的空白狀態。
首次使用（Onboarding）
在有資料的狀況下，這個畫面只會在用戶第一次使用的時候出現一次。這個是你鼓勵用戶做出行動的機會，幫助他們了解在離開這個畫面之後，可以得到怎樣的價值。你只有一次的機會可以創造第一印象，而你有機會做好。
我會把這種狀態比做是文學中的「英雄之旅」（Hero’s Journey）。約瑟夫．坎伯（Joseph Campbell）在大作《千面英雄》（Hero With a Thousand Faces）提出這個概念，而這個概念是可以從《奧德賽》到《星際大戰》等神話故事都可以發現的基礎。以下就是「英雄之旅」的基本論點：
「英雄從原本日復一日的平凡生活，開始往超自然的奇妙領域探險；英雄遇到了預言中的力量並且獲得註定的勝利；英雄最後從謎一般的冒險中歸來，並且帶來賜予人們恩惠的力量。」在空白狀態中，驅使你的顧客踏上英雄之旅吧！召喚他們前往冒險，帶領他們前往各種已知的挑戰、以及無底洞的誘惑，然後讓他們轉變成更有力量的個體。
怎麼做呢？以下是幾點建議：
- 把馬牽到水邊。在文案中，你要表現得更加鼓舞高昂，並且清楚說明應做些什麼。比方說，如果你說「在這邊什麼東西都還沒有」，就完全不符合你的顧客的期待，而且第一個畫面就看到這個，實在讓人沮喪。反之，你應該告訴顧客應該要去按哪個按鈕，以及為什麼他們應該按下去，才是比較好的作法。
- 使用產品本身的內容教導顧客該做些什麼。比方說，如果你做的是一套傳訊軟體，那麼你應該做的事情就是在顧客首次使用的時候，自動在顧客的收件夾中插入一則訊息。訊息標題可能寫成「點我打開」，而內文則是講述如何操作、回覆這則訊息。
- 提供一些看起來像是理想狀態的螢幕截圖。這樣可以在顧客的心中燃起希望，知道他們最後可以得到的成果大概是什麼樣子，以及你的產品有哪些潛力。
- 時時觀察、並且回應顧客的進度。如果他們在一個畫面停留太久，你可能就要用即時聊天詢問他們是否需要協助。
這邊是一些我相當喜歡的首次使用空白狀態。
首次使用這個話題大到足以寫另外一本書，而且剛好不久前就有一本。如果你對這個話題有興趣，我強烈推薦 Samuel Hulick 所寫的《首次使用畫面的各種元素》（The Elements of User Onboarding）。
用戶手動清除資料
第二種狀況，則是顧客手動把畫面中的所有資料都移除了。常見的狀態包括，你的顧客把代辦列表中的所有工作都做完了，所有的通知都讀完了，把所有的信件都封存了，或是完成下載了所有音樂檔案。
這種空白狀態則是鼓勵你的顧客的好時機。解除「收件夾全空」成就？太棒了！看看這張漂亮的照片吧！所有音樂都下載完畢？太好了！現在趕快來聽歌吧！已經看完所有的通知了嗎？我們還有你會想讀的其他文章喔！
顧客清除了所有的資料，正是一種用戶與你的產品親密互動的表現。你應該做一些事情，讓顧客繼續留在你的產品的既有流程中，而不要強迫他們非要做出下一步的行動。
找不到資料
如果你的顧客在你的產品中瀏覽或是搜尋資料的時候，他們很有可能會遇到找不到資料的狀況。在這個情境中，就如何推測顧客想要找些什麼、以及如何做出智慧型的建議來說，會是非常好的機會。
Amazon 是所我看過最懂得這一套技巧的廠商之一。透過猜測錯誤拼字以及相關搜尋，Amaazon 很少出現全空的搜尋結果。如果某個關鍵字沒有搜尋結果，Amazon 會自動切換到最類似的關鍵字。
我們要學的是：在這種狀態中，不要讓你的顧客撞牆，而是要給他們一些有用的建議、或是不一樣的途徑。
錯誤狀態
錯誤狀態就是有事情出錯時所出現的畫面。通常，錯誤狀態會比單一畫面來的複雜，因為各種錯誤往往會以讓人訝異的複雜組合的方式出現。錯誤狀態包括各種無法取得資料、或是資料不合法的狀況，包括你的 App 無法與伺服器連線，當你還沒有完成上傳資料就想進行下一部操作，或是還沒有把文章寫入就想離開頁面…等等。
一些錯誤狀態，可以讓用戶覺得他們可以安全地輸入資料。你的產品在顧客遇到錯誤的時候，不應該還原、銷燬或是刪除顧客已經上傳的資料。
我們要來套用一下 Jef Raskin 的說法，他是最早的麥金塔電腦的創作者，也是《人機介面》（The Human Interface）一書的作者。他曾經寫道：「系統應該要把所有用戶輸入的資料都當做聖物，同時 — 借用 Asimov 的機器人第一法則：『機器人不可以傷害人類，或是透過不作為，而讓人類受到傷害』，介面設計的第一法則也就是，電腦不可以對你的工作造成傷害，或是透過不作為，讓你的工作受到傷害。」
看完這個建議，我們就來看看一些糟糕的範例，看看他們如何破壞這條法則。在航空公司的網站上，只要忘記輸入信用卡驗證碼的一小段，就經常馬上重新載入頁面，你剛才專心輸入的文字統統不見了，畫面中只剩下一段用充滿攻擊性的紅色色調凸顯的錯誤訊息。
是！否！或許？
啊，我們終於可以有些具有脈絡的錯誤訊息了。不過我們還可以做得更好，像是透過幽默感，把錯誤訊息變得更有人性。
理想的錯誤狀態，可以在錯誤發生的時候，不會讓用戶輸入的任何資料損毀。如果在錯誤發生的時候，不管怎樣都得重新載入頁面，請幫所有人一個忙 — 把所有顧客在產品中輸入的資料儲存取來。通常，用重新載入頁面處理錯誤所象徵的就是懶惰。看在你的顧客的份上，請確保你自己還有你的開發人員要花上額外的力氣，用溫和且寬容的方式處理錯誤。
此外，我們不要把錯誤狀態搞得很戲劇化，也不要含糊不清。還記得 Windows 的「藍底白字」，還是 Mac 的「五國語文」嗎？或，如果你是電腦老手，可能還記得「放棄、重試、失敗」這個訊息。這些錯誤狀態所代表的都是嚴重的系統錯誤，必須要重開電腦，或是要重試。但我們直到今天都還會記得這些錯誤，原因是這些訊息都造成用戶感受驚嚇、惶恐以及困惑。
微軟的「藍底白字」之所以這麼聲名狼藉，就是因為他真的把用戶嚇壞了。這個藍色畫面 — 雖然比紅色好一點 — 在完全沒有脈絡可尋的狀況下，就突然跑出來，然後充滿了恐怖的專業術語 — 即使這些會是重要的除錯資訊，但就是很恐怖。
這就是為什麼錯誤狀態必須要能夠簡單、友善，並且保存可以讓用戶進行下一步動作所需的資料。怪異的錯誤代碼，二進位數字以及讓人困惑的進階選項，只會讓人們在遇到錯誤的時候，感到恐怖以及心力交瘁。
當然，你的顧客可能會是由火箭科學家或電腦工程師組成。那麼高度技術導向的錯誤訊息，就很適合他們。但是由於世上絕大多數人都是在日常生活中使用軟體，這種錯誤訊息變得愈來愈不適當。
這很簡單，要想把錯誤訊息變得人性化、而不是技術導向，想辦法讓錯誤訊息符合用戶的需要，就是先想想：你自己在事情出錯的時候，你會想要聽到、看到什麼？
因為錯誤太常發生了，所以會是一個非設計不可的狀態之一。但，我可以向你保證，如果你可以在錯誤狀態上，花上與前兩個狀態一樣多的力氣，你的產品用起來一定會充滿無窮的樂趣，而且會更有用，因為你思考過、並克服了大多數的一般瑕疵。
局部資料狀態
完美狀態與錯誤狀態的差別就像日夜一般。但如果畫面中，有的是只有一行資料、只有幾張照片、或是只完成一半的個人簡介呢？
局部資料狀態就是用戶雖然看到的畫面不是空白的，但也只有稀疏幾筆資料。在這個時候，你應該要想辦法讓人們不要感覺沮喪，然後放棄你的產品。
這是一個讓你設計小型互動，讓用戶前往完美的理想狀態的好機會，也是一段你幫助顧客了解產品真正價值的旅程。局部資料狀態其實意味著某種成就 — 顧客已經在你的產品上花了一些時間，然後約略看出了產品的潛力。你要想辦法繼續留住他們。
在這邊可以用上一些遊戲設計的原則。我指的不是像「部落衝突」（Clash of Clans）這些遊戲裡頭，要顧客想辦法蒐集水晶的痛苦經驗，反之，我們應該要在產品中局部資料狀態，建立一種加速度系統（acceleration）。
在遊戲設計的術語中，加速度系統就是用視覺化的方式，告訴玩家他們未來可以變得多強大，並且引導他們經歷一系列的任務，最後達到這項目標。這套技巧可以讓玩家忽略過程的冗長，而只會注意到你的產品的最大價值何在。
「進入加速度階段的玩家所關心的並不是這些為了升級所需的冗長打怪循環，他們就是一直打怪，然後享受前往目標的速率，或這麼說，玩家其實是被未來角色可以變得多麼強大這點而吸引，即使他們也不懂為什麼打怪可以讓角色變強。用更技術性的方式來說，他們認為在角色會變強這點預告之後，一定有一套指數成長的力量結構。雖然這個結構不見得會跟傳統流程相同，但是讓玩家主觀感受到的樂趣都非常相似。」
以下是一些局部資料狀態的範例：
載入中狀態
這個狀態很容易了解，而且不少產品設計師會在事後加入這個狀態。但是在設定期望的時候，我們會發現一項真實存在的負擔。當你的 app 在載入資料、等候網路連線、以及從另外一個畫面過場的時候，你必須額外留意你如何呈現載入資料的進度的方式。你可能會用整頁畫面顯示、使用延遲載入資料分頁、或是，當你想要確認是否某個用戶名稱是否可用的時候，會使用行內載入。
能夠讓載入資料這件事情變得看的到，也一樣重要。很多設計師會把畫面完全留白，然後放置一個會轉動的圖示，代替還沒有出現的內容這項重責大任。這麼做，就是反過來鼓勵顧客象徵性地看著時鐘 — 你應該讓顧客的注意力從真正的載入進度，轉向注意載入畫面本身。
這就是Luke Wroblewski 的信念，Luke Wroblewski 曾經在 eBay 與 Yahoo! 率領過設計團隊，而在他賣掉了線上投票新創公司 Polar 後，現在他是 Google 的一員。
Wroblewski 與他的團隊發現，當他們在每個投票的最後加上了一系列的載入進度旋轉圖示後，Polar 的顧客開始抱怨他們的 App 速度變慢了，顧客說：「在載入或是刷新頁面的時候，看起來還要做很多額外的工作，感覺新版本比舊版本速度慢上許多。」
Wroblewski 於是發現：
「當畫面加入了載入進度圖示之後，我們就等於是讓顧客一直盯著時鐘看。」他說，「如此一來，用戶就覺得時間變慢了，我們的 App 也變慢了。所以，我們想讓注意力放在載入畫面本身，而不是真正的進度上，我們要想辦法告訴用戶，你其實是在往你的目標前進，而不是只在原地等待。」
畫面骨架（Skeleton Screens）
體認到這點後，Wroblewski 緊接著便做出了他所謂「畫面骨架」的這項設計。現在，Pinterest 與 Facebook 在他們的網站與行動 App 中，也都使用這項技巧。
畫面骨架是一項用來處理載入中狀態的創新，這項技巧讓用戶的注意力從真正的載入進度移開，而是注意內容本身。這項技巧就是先顯示頁面的基本框架，然後最後再用成功下載的資料內容填滿框架。這項設計的美妙之處，就在於完全排除了旋轉的載入圖示，並且可以提昇你的 App 的效能體驗。
當 Pinterest 開始採用畫面骨架這套技巧處理載入中畫面的時候，又增添了一些元素。他們從每張圖片中，先抽取出「平均顏色」，然後在載入圖片之前，就先用這個平均顏色填滿照片的背景，於是，就產生了一種你在實際看到照片之前，先獲得這張圖片的預覽的效果。
樂觀預期可以執行成功
「每個在等的人其實都不想等。」Instagram 的創辦人 Mike Krieger 在 2011 年時，就他對這套 App 怎樣提昇執行效率如是說。
事實上，Krieger 可說是提倡產品應該可以「樂觀預期執行成功」的先行者。在假設各種操作都可以成功完成的前提下，應該要讓成功執行的結果儘快顯示在畫面上。
像是對照片按讚，或是留言，從顧客的角度來看都是即刻完成。而 App 是在背景默默地與伺服器傳遞資料，完成這些工作。
這些樂觀的操作，可以有效幫助減少上傳圖片或影音資料的時間。與其是在照片上傳流程的結尾、用戶按下「完成」按鈕之後才開始上傳，Instagram 其實在用戶挑選濾鏡效果的時候，就馬上開始上傳。雖然這不是一種最佳的工程解決方案，而且當用戶返回上一步的時候，這些資料也可能會被丟棄，但是，這麼做可以讓資料上傳變得非常快速。這種「沒人在看就先偷跑」的技術，可以有效為你的產品加速。
你已經分別看了不少跟 UI 堆疊，以及這五種狀態有關的範例。但這些狀態如何合為一體？我們又該如何處理這些狀態轉換時的轉場效果？
這就是 UI 堆疊的威力所在。這些狀態並非存在於真空當中。這些狀態存在於一個垂直的軸線上，你的產品也可以隨持呼叫這些狀態。你不但要分別處理這些狀態，同時還要設計在不同狀態之間切換時，畫面應該要如何變化。
我要用一個即時傳訊 App 的構想，對此加以說明。
為什麼是傳訊 App 呢？因為在這種 App 中，每個狀態其實都並不是這麼明顯，但我想說的是，即便是即時傳訊中都只有短暫的 UI，其實也都符合 UI 堆疊的法則。同時，這種 App 也說明了想要讓畫面從不同狀態之間順暢切換，這項責任有多麼重大。
我們要怎麼處理一套即時傳訊 App 呢？
首先，一開始，我們要處理一條訊息都沒有的狀況。這是我們的空白狀態。
我們的局部資料狀態，則是只有一方傳送了訊息。
接著，我們就要開始接收一條訊息，於是出現了對方正在打字的載入提示。換言之，這就是我們的載入中狀態。
等一下，我們還有另外一種載入中狀態，就是我們在把訊息傳送出去的狀態。接著，就會出現發送確認訊息。
如果我們的訊息發送失敗，我們就會收到錯誤。
然後你不能忘了我們要有一套機制，可以讓我們修正目前發生的錯誤，然後重送訊息。這又是另外一種的載入狀態。
最後，我們達到了理想狀態。雙方都送出、接受到了訊息，而產生了對話。
實際範例
馬蒂還有博士（註：電影《回到未來》裡頭的人物）剛剛交換了電話號碼，然後馬蒂想要透過訊息，告訴博士他剛剛在雙松商場（Twin Pines Mall）看到了什麼。
因為雙方都還沒有傳過訊息，所以我們有機會可以在空白狀態中，鼓勵顧客進行他們想要的行動 — 在這邊，就是傳遞訊息。
但是，在送出訊息之後呢？我們就要小心地讓空白狀態淡出，然後切換到局部資料狀態。 — 在這邊，狀況就是馬蒂只傳了一則訊息出去。
我們快轉到博士收到訊息的時候。他也要送一則訊息出去，但是他還沒把字打完呢！所以就會出現打字中的提示，這就是另外一種載入中狀態。
在打完字、送出訊息之後，我們就做了打字中提示與新訊息內容之間的轉場，並且把之前的訊息往上推。
那，如果馬蒂想要回覆訊息呢？首先，我們要做一些狀態的提示，請注意到當文字框裡頭有文字的時候，「寄出」（Send）按鈕會從灰色（代表無法使用）變成藍色（代表可以使用）。然後，當我們送出訊息的時候，就會出現另外一個用來表現訊息傳送進度的載入中狀態。這則訊息還是半透明的，代表訊息還沒有成功送出，直到成功送出後，才會跳出「已傳送」（dilivered）這段文字。
如果這則訊息沒有成功送出呢？就會出現錯誤狀態。原本代表傳送中的旋轉圖示，變成了紅色的警告圖示，而由於訊息沒送出，所以這則訊息仍然還是半透明的。只要在這則訊息上再按一次，就會重新嘗試送出訊息。這次我們運氣好，於是我們可以把紅色警告圖示拿掉，換成「已傳送」文字。
這裡，可是個真實世界
朋友們，這就是活生生的 UI 堆疊。在這個範例中，五種不同的狀態無縫切換。如果沒有這些轉場效果，那麼在狀態出現或消失的時候，就會讓顧客感到驚嚇與困惑。我們的職務說明並不是要讓人們感到不安與困惑，對吧？
最後，要實作這些不同的狀態，需要設計師與開發人員之間的密切合作。請互相花點時間在對方身上，才能夠一起為顧客創造最好的、全面的體驗。
（如果你喜歡這篇文章，我很希望您可以分享。）
重點回顧
- 不要只就理想狀態設計，而要同時設計其他幾種狀態。你的 App 要解決的是顧客的問題，所以你要思考要如何用各種畫面達到顧客的目標。
- 記得要去讀 Samuel Hulick 的《首次使用畫面的各種元素》。
- 在實作雛形的時候，要在載入中狀態花上一些力氣。載入畫面會是產品整體經驗的一部分，不應該最後才處理。跟開發人員一起找出讓載入進度感覺起來比較快的方式，如果可以的話，能夠載入速度真的變快會更好。
- 花點時間思考會引發錯誤的邊界狀態。你會怎麼處理這些錯誤？什麼才是該給顧客的友善回應？在這邊會有一些成本/效益的考量，不過，你最起碼要處理讓顧客感覺最痛苦的哪些錯誤，並且要時時保存用戶的資料。
