以大廠的主流產品為優化實操對象，其實是一個很大的挑戰，發現并優化其中存在的問題，對于理解用戶體驗設計有著巨大的幫助。

前言

用戶體驗（User Experience，簡稱 UE/UX）的概念大家早就不陌生了，其在互聯網產品中的重要性不言而喻。各大設計平臺上關于此類的文章層出不窮，相關的概念解釋及理論知識相信大家都看過不少，此處就不再啰嗦。相比之下案例實操類的作品卻并不多見，寫這篇文章的目的就是想分享一些案例實操的經驗和心得，從實際出發，更直觀的感受 App 產品中的用戶體驗。

本文重點在于尋找產品功能層面上的不足，從細節處提升產品的易用性，而非 GUI 或視覺層面的重設計。

為了帶給大家更多的共鳴，本文選出的案例都是大家身邊最常見的 App，相信至少有一款是你手機中常年存在的產品。

目錄

• 鐵路 12306（優化內容：精確查詢車票、智能推薦常購車次）
• 百度貼吧 （優化內容：消息模塊優先級研究、重新定義消息通知中的樓中樓回復顯示規則）
• 美團外賣 （優化內容：在用戶不知道點什么外賣時，幫助其發現想吃的美食）

案例一：鐵路 12306

產品功能不用多說，大家年年都在用，甚至很多經常出差、或者短途回家探親的小伙伴們，每個月都要用其購票。本次優化內容為產品核心功能：查詢車票及查詢結果列表。

1. 用戶痛點

車票查詢結果頁面，所有符合出發地及目的地的車次，默認按出發時間由早至晚順序排列，頁面底部也提供了更多篩選排序功能方便用戶更快找到期望車次。乍看之下沒有問題，但其實在實際使用中，當前提供的功能并不能很好的滿足各類用戶的出行購票需求。我們可以簡單的模擬一個情景來感受一下。

2. 現狀分析

查詢前后反饋給用戶的信息不一致

12306 的查詢車票功能，選擇的出發地和目的地都并非精確查詢，而是范圍查詢。比如當用戶點擊目的地后，在搜索頁面中輸入“濱海”，雖然列表中出現的是濱海相關的各個火車站點，但在執行查詢車票操作時，并非精確查詢兩個車站之間的車次，而是兩個車站所屬城市之間的車次。

范圍查詢的做法可以理解，因為很多站點之間沒有直達車次，用戶任意選擇站點后，精確查詢的結果可能是未查詢到相關車次。對車次信息不熟悉的用戶，只能換一個站點再次嘗試，直到試出可行路線為止，這會大量增加用戶查詢車次的時間成本，所以 12306 采用范圍查詢，將站與站之間的查詢擴大為城市與城市之間的查詢，保證用戶只進行一次查詢操作就可以找到通往該城市的車次。

但由于前后信息的不一致（搜索時顯示車站名稱，查詢后顯示抵達該城市的車次），很容易導致用戶產生搜索結果誤差較大，甚至是搜索功能有 bug 的錯覺。

信息量級較大，而時間段查詢功能隱藏過深

查詢結果列表中展示當天全部的車次信息，經常超過上百條，頁面底部的工具欄中，一級菜單只能切換發時最早和發時最晚，也就是正序和倒序兩種。而按時間段查詢功能被放置在了篩選菜單最底部，非常隱蔽，甚至在部分手機的屏幕上一屏顯示不出來，需要用戶向上滑動才能看到。經過對身邊同事朋友的調查，發現不知道此功能的用戶竟占了大多數，足以說明該功能存在著設計缺陷。此外，由于 12306 采用了固定時間分段的方式，即使知道該功能的用戶，使用起來也并不十分方便。

3. 優化方案

增加查詢條件的精確度

查詢車票頁增加分時段查詢和按站查詢功能。將隱藏過深的按時間段查詢功能提至臺前，作為常用功能應更直觀的展現給用戶，使任何用戶都能夠第一眼看到，大大減少在列表頁滑屏操作的次數。同時將固定時段改成滑塊方式，選擇時段更靈活準確。而按站查詢功能可以解決用戶前后獲取信息不一致的問題，對于比較了解行程車次信息的用戶，通過勾選按站查詢，可以精確查找出更符合自己預期的數據。

查詢結果增加常購車次、時間段查詢形式統一

勾選了“按站查詢”后，查詢結果會精確篩選出對應車站的車次信息，減少無關項的干擾，便于用戶快速找到想要的車次。同時在列表頂端增加“常購車次”，根據用戶的歷史訂單數據，推薦起始-到達車站均相同的車次，對于經常去同一城市出差或回家探親的用戶，有很大概率會再次購買相同車次，智能推薦可以極大的減少用戶的時間成本。將頁面左下角篩選菜單中的按時間段查詢改為滑塊形式，與前頁統一。

4. 驗證方案

將已確定的優化方案代回原案例，進行情景再現，從情感層驗證方案的可行性。同時模擬用戶的操作行為，統計各行為最終的總操作次數，從數據層對方案的可行性進行二次驗證。

情景再現

用戶操作統計

目標用戶：有確定的目的地站點，且對時間有一定要求，出發時間為中間時段，即除早上和深夜外的時段。

記錄 <從進入 App 首頁開始，至找到目標車次為止> ，用戶可能的操作次數。

• A：優化后方案，正常操作查詢車次（任何用戶都一樣，不區分是否新手）
• B：未優化方案，資深用戶，熟練使用篩選功能查詢車次
• C：未優化方案，普通用戶，僅使用發時最早/發時最晚查詢車次
• D：未優化方案，小白用戶，直接在列表中滑屏查詢車次

5. 優化方案整合及總結

本次案例優化方案主要增加了“按站查詢”和“常購車次”功能。

• 查詢車票選項增加“按站查詢”和“發車時間”；
• 選擇發車時間從固定分段改為無級滑塊選擇，更靈活；
• 列表頁增加“常購車次”，對回家探親和經常往返固定地點出差的用戶提供極大便利。

鐵路 12306 屬于工具類 App，用戶僅在有購票需求時才會使用，與生活類 App 最大的區別就是用戶不會花費大量的時間去學習和使用，所以產品的功能一旦被埋藏在深處，就很容易被用戶忽略。而在車票查詢的過程中，選擇發車時間和目的地車站是非常重要的操作，甚至在大多數情況下是必要因素，應當在查詢頁面就提供給用戶，而不是隱藏在結果頁面的某個菜單中。如果說將“選擇出發時間”和“選擇車站”放在搜索頁是為全體乘客服務，那“常購車次”就是為經常去同一地點出差或回家探親的乘客服務，在出發地、目的地、時間均相同的情況下，乘客購買相同車次的概率很高，智能推薦可以極大的減少用戶的時間成本，進一步提升“工具”的效率。

通過上述情感層和數據層的對比驗證，可以確定本次優化方案具備可實行性，在多數情況下有利于提升產品的用戶體驗。且方案實現難度較低，執行成本可控，對用戶操作的影響跨度也非常小，用戶學習成本低，應用價值較大。

案例二：百度貼吧

百度旗下最大的社交平臺，也曾經是全網最大的社交平臺，而隨著移動端興起，微博知乎抖音最右等平臺逐漸發展壯大，貼吧 App 的部分用戶被分流。為了維持市場競爭力，貼吧也經歷過多次大的版本更新，從產品結構到 UI 界面都在不斷迭代優化，提升產品的用戶體驗。本人 2012 年入駐貼吧，吧齡 9 年，目前 13 級以上貼吧超過 30 個，自認為算是貼吧的資深用戶之一，那么就來聊一聊我眼中的貼吧存在哪些問題。

本次優化內容主要為：消息模塊中“評論回復”及“系統推送+私信”的優先級研究。

1. 產品分析

在做產品分析的時候，選擇一個相似的競品作參考，對比分析各自定位的不同和功能的優劣，有助于幫助我們制定出更合理的解決方案。在各大社交 App 中，與貼吧最為相似的莫過于知乎了，案例二將主要針對這二者進行對比分析和制定優化方案（注：上一個案例中沒做競品分析是因為 12306 屬于國家推出的集商業化和公益化為一體的便民產品，并非單純以商業化為目的，不需要與其它售票軟件做市場競爭）。

△ 上圖為百度貼吧和知乎的關鍵詞維恩圖 (Venn Diagram)。

從整體角度看，二者在解決用戶需求上存在大量交集，均以解決用戶在情感歸屬上的需求和對共同興趣愛好的信息消費需求為目的，為用戶提供一個網絡社交平臺，使用戶在與他人的溝通交流過程中，獲得精神上的滿足感，或者解決自身遇到的問題和困難。但細節上，兩個產品的初始定位、模式、功能、內容等，均有著很大不同。

產品定位不同導致的核心內容差異

百度貼吧創立于 2003 年底，產品的創立理念為：結合百度自身的搜索引擎，建立一個在線交流平臺，讓那些對同一個話題感興趣的人們聚集在一起，方便地展開交流和互相幫助。貼吧以“交流”為核心，用戶關注自己感興趣的貼吧，通過發貼的方式開啟一個與興趣相關的話題，吧友們在貼子中平等的溝通交流，暢所欲言，以此獲得心理滿足感。久而久之，在自己熟悉的貼吧里暢談，成了用戶的情感歸屬。

知乎創立于 2011 年初，創立之初的理念為：打造中文互聯網高質量問答社區和創作者聚集的原創內容平臺，由各路大牛經深思熟慮寫出一篇篇干貨，幫助了非常多的人。不同于貼吧的“交流”，早期知乎以“問答”為核心，有人提問有人回答，構建了一個學習互助、探求真理的平臺。在后續開放注冊后，知乎內容的質量變的參差不齊，產品發展策略開始向娛樂化社區偏移，而在此基礎上衍生出了新的核心：“講述”。回答的內容從行業攻略和資源分享發展為對故事的講述（套用一句網絡戲稱：知乎，分享你剛編的故事～當然這只是句玩笑話)。用戶使用知乎的目的分化為尋找答案和看故事，但無論哪種用戶，其關注核心都在于“回答”本身。

二者對比可以發現，貼吧的核心在于評論回復，用戶通過與他人交流產生情感歸屬，是事件成立的必要因素。而知乎則更偏重于回答，強調的是內容的講述和傾聽，交流可以更好的促進事件的成立與發展，但并非核心。

用戶交流模式的差異（評論回復&私信）

說完了產品定位不同導致的核心內容差異，接下來說一下二者用戶群體之間交流模式的差異。

貼吧的交流模式中，當兩個人產生對話形成交流，雙方或有著相同觀點，互相支持認可；或持不同觀點，試圖說服對方。而不管是哪種情況，用戶都希望自己的言論能被更多人看到和認可，以此來獲得心理的滿足感，所以需要以回復的方式發布在貼子中。試想如果換成私信方式，若互相認可，雙方隔著網線來一波單對單的商業互吹，似乎略顯尷尬；若互相爭論，則常常雙敗結局，沒有旁人的支持誰也說服不了對方，爭到最后勞神費力，也無法獲得更多的滿足感。在實際情況中，當兩位吧友產生矛盾，常出現的情況不是私聊溝通，而是另開一貼@對方來一波祖安式對線，不明真相的吧友們紛紛點進來騎墻吃瓜，貼子里充滿了快活的空氣，好不熱鬧……同時由于一些歷史版本的原因，很多用戶對貼吧私信功能的印象并不友好，這進一步降低了該功能的使用率，具體緣由以后有機會再詳細解釋，此處暫不做過多闡述。

知乎的交流模式中，由于存在大量攻略及分享類內容，用戶經常抱有求助或探知的目的在瀏覽，在詢問和解答的過程中，會產生大量的單對單對話，而此時雙方對話的目的都是為了直接快速的解決問題，是否有旁人觀點的加入并不重要，并且相比評論的非即時通訊，私信的即時通訊特性可以更方便地溝通交流。并且，很多私信聊天記錄中包含著大量關于知識解答、經驗分享、事件記錄等重要內容，用戶存在反復查看的情況。

綜上所述，評論回復功能適用于無約束的閑談交流，而私信功能更適用于求知、學習、請教等單對單的溝通。這也是貼吧和知乎的最大區別。私信功能在知乎平臺上扮演著非常重要的角色，其使用率和重要性遠高于貼吧。

2. 發現問題及優化方案

兩個產品當前版本的消息界面截圖如下所示。對比可發現，二者在功能及排版上均存在極高的相似度，但根據前文分析的結論，兩個產品中不同類型消息的重要級別是不同的，理論上不應該出現幾乎相同的界面。

問題 1：核心內容被折疊，一級頁面缺乏吸引力

貼吧和知乎的消息模塊，均將私信和系統消息放在一級頁面，而評論、點贊等，以金剛區入口的形式收起在二級頁面中。知乎如此做法與產品的定位并不沖突，私信功能確實扮演著重要的角色，放在一級頁面更方便用戶查找歷史聊天內容，系統消息放在一級頁面也可以增加曝光率和點擊率，有利于運營活動的開展。

但貼吧不同，私信功能的重要級很低，而評論回復的重要級遠高于私信，將用戶最常用的功能放在二級頁面中與產品定位不符。其實在上個版本的貼吧中，評論確實是放在一級頁面的，新版本更新后學習知乎的做法將評論收入了二級頁面。這么做的目的可以理解，將大量評論消息收起，運營內容和系統消息就可以更久地保留在用戶視野中，增加點擊率和轉化率。但需要注意的是，第一，運營內容在一級頁面僅展示一行標題文字，即使長時間保留在用戶視野內，也不具備強吸引力，對點擊率的提升有限；第二，知乎如此做法有著產品邏輯的支撐，在不影響用戶體驗的情況下提升運營內容的點擊率有利于提升產品的商業價值，而貼吧這么做就有些強行照搬的意思了。為了少量提升運營點擊率犧牲作為核心內容的評論回復，是否值得，還需要更仔細的斟酌。

優化方案：將作為核心內容的評論回復從二級頁面中取出，放在消息模塊的首頁展示，將不常用的私信功能收起至金剛區入口的二級頁面內。同時為增加運營活動的曝光率，直接將活動圖片放在一級頁面中展示，提升視覺吸引力。對頭像及賬號昵稱添加行事件，點擊跳轉至運營賬號主頁，顯示全部歷史消息。

優化后的頁面，用戶查看評論回復更方便，同時極大的提高了運營消息的曝光率，從用戶體驗和商業價值兩個方面均有所提升。

問題 2：消息組件的內容與用戶預期不符

貼吧消息由四部分內容組成：用戶、回復內容、所在樓層的內容、操作。

知乎消息由五部分內容組成：用戶、回復內容、被回復的內容、對應問題或回答、操作。

通過對比可以發現，二者消息組件的主要區別在于 Link 鏈接區。知乎的 L 區包含兩部分：L-1 被回復的評論內容，L-2 該回復對應的問題或回答。L-1 區內容與 C 區相對應，用戶即使不點開詳情也可以清晰的看懂回復對話，同時由于知乎的核心內容就是回答本身，L-2 區的鏈接可以方便用戶查看對應的問題和回答，非常符合產品邏輯。

再看貼吧，貼吧的 L 區放棄了貼子主題的鏈接（對應知乎 L-2），因為這本就不是貼吧的核心，無可厚非。但 L-1 區的內容選擇顯示“被回復的評論所在樓層的內容”，這不符合用戶的常規認知。在通常情況下，“回復”與“被回復的內容”是連貫和不可分割的整體，在 Link 鏈接區顯示與“回復”沒有直接關系的“所在樓層的內容”，會造成用戶認知偏差。

最直觀的感受就是：

大家看到這個對話的第一反應是不是一臉懵逼，完全理解不了該對話因何產生，同時也會產生疑問，為什么我的消息通知中會有張三對層主的回復？

但實際發生的對話是：

所以，為了避免這種用戶認知偏差，將貼吧 L 區顯示的內容改為“被回復的評論內容”，也就是：

使“回復”和“被回復的內容”成為一個有機的整體，更符合用戶預期，很容易就能看懂對話。

3. 優化方案整合及總結

將頁面優化和消息組件優化整合在一起，形成完整的優化方案。

• 將二級頁面中的“回復”消息取出，直接在一級頁面展示；
• 優化消息組件中 Link 鏈接區，顯示被回復的評論內容，而不是與回復無關的所在樓層的內容；
• 將使用率較低的“私信”功能放在金剛區-私信的二級頁面中，并提供私信設置功能；
• 未讀消息以紅點標記區分，消息的文字內容最多展示兩行；
• 將運營活動與消息組件融合，在列表中直接展示宣傳圖片，提高曝光度和點擊率。

優化后，用戶收到新的消息通知，點擊至消息模塊可以直接看到全部回復，而不需要再額外點擊一次金剛區的消息按鈕，這對單手操作的用戶提供了很大便利。消息組件中，回復內容和被回復內容一一對應，完美符合用戶預期。運營活動以相同的組件形式展示在一級頁面中，用戶能直接看到活動宣傳圖片，提高點擊欲望。

案例三：美團外賣

隨著互聯網的發展，點外賣成為了大量打工人的干飯首選。曾經的外賣三巨頭：美團外賣、餓了么、百度外賣三足鼎立。之后百度外賣被餓了么收編改成餓了么星選，定位為高端美食，用戶量相對較少，剩下的美團外賣和餓了么是當前全網用戶量最大的兩個外賣平臺。由于二者在功能和界面均上具有高度相似性，本案例僅選取美團外賣 App 做實操展示。

本次優化內容為：新增“發現新食”和“干飯單”功能，為外賣不知道點什么的用戶服務。

1. 用戶痛點

外賣行業已經發展了超過 6 年，點外賣憑借其送貨上門的便捷性和紅包折扣的價格優惠，成為大量打工人解決吃飯問題的首選方式。而用戶在點外賣時經常出現的困擾是：我要吃什么？對于大多數人來說，工作和居住地點都比較固定，更換頻率較低，通常以年為單位計算。而長期在同一地點工作居住，可選的外賣商家是有限的，一般在 1 到 2 個月左右就基本吃遍了周邊的外賣，每次點外賣都會頭疼點什么，光挑選就會耗費大量時間。

2. 現狀分析

功能較全面，但過于程序化，僅對目標明確的用戶有良好表現

用戶點外賣分為兩種情況：一、有明確的目標，知道自己想要什么；二、沒有明確目標，使用美團外賣僅為了解決吃飯問題，對于具體吃什么沒有固定要求。

針對第一種用戶，美團外賣提供了非常全面的篩選功能和推薦機制，用戶可以從美食種類、配送距離及時間、排序方式、人均價格、商家特色及品質、優惠活動等多個緯度對商品列表進行篩選排序，精準定位目標產品。同時平臺會根據用戶的歷史行為和購買記錄，推薦其可能感興趣的商家和美食，便于用戶快速找到目標產品。

但針對第二種用戶，當目標不明確時，篩選、搜索和智能推薦功能并不能很好地滿足用戶需求。前文中已經說過，大量打工人都是通過點外賣解決午飯晚飯，由于工作地和居住地更換頻率較低，同一地點的外賣商家很難保持長期不重復的飲食供應。而人類生理上存在超限抑制，長期食用某種食物會導致體內對應的營養物質過剩，從而對該食物產生厭煩心理。相信很多小伙伴都有過這種經歷：打開外賣軟件，看著那些吃過無數遍的食物毫無食欲，也不知道自己想吃什么，時間慢慢流逝，最后隨便點個“不是那么討厭”的食物湊合了事。

缺少用戶主動偏好收集

接下來我們對智能推薦功能進行分析，美團外賣的智能推薦標簽主要包括以下五個緯度：最近常看、口味相仿、猜你喜歡、周邊熱銷、大量用戶買過。

可以看出，智能推薦是通過對用戶行為數據的分析，自動選擇出用戶可能感興趣的菜品，而由于食物的特殊性，推薦結果可能偏差較大。但如果是由用戶主動選擇的偏好菜品，可以精準符合用戶預期。舉個簡單的例子：小劉很愛吃糖醋排骨，每隔一段時間都會點一次，由于點的次數多，智能推薦就會經常給他推薦糖醋排骨，天天吃用不了幾次就膩了，所以這并不是問題的解決方案。那么不妨讓小劉把糖醋排骨列在自己的偏好清單上，時間久了清單上記錄了很多菜品，每一樣都是小劉喜歡的食物，當想不出該吃什么的時候就看看清單，更容易激發食欲。

二者對比：

智能推薦無論什么時候都強制推薦給用戶，有時反而會加深厭煩心理，難以保證準確率；而記錄偏好清單不僅能精準匹配用戶偏好，還可以由用戶選擇在需要的時候進行查看，不需要的時候避免打擾，合理控制節奏。

3. 優化方案

針對上述分析結論，我們的目標用戶是長期使用外賣軟件解決吃飯問題，但疲于挑選、缺乏目標的用戶。我們所要做的是：讓用戶用最小的成本收集他喜愛的食物清單，并且在用戶不知道想吃什么的時候，幫助他找到更多能令其產生食欲和新鮮感的美食。

主動收集用戶偏好清單，增加“干飯單”功能

訂單記錄著用戶曾購買過的全部商品，是主動收集用戶偏好的最佳渠道。在訂單詳情中，用戶很少關注菜品的原價，且對于未參與折扣的菜品來說會浪費屏幕空間，遂將原價去掉，加入“添加偏好清單”按鈕。而對于“用戶偏好美食清單”，我們為其取一個接地氣的名字：干飯單（文案僅為示意，實際工作中應與產品運營確認）。

當用戶完成了一筆訂單后，再次進入訂單頁面會出現評價彈窗，跟蹤用戶的用餐體驗，此時也是收集用戶偏好食物的好時機。將訂單中的菜品顯示出來，用戶可以直接添加至“干飯單”。

值得一提的是，評價詳情頁面已經有大量操作，再加上添加至干飯單會導致操作過多，增加用戶的思考成本，從而降低用戶體驗。干飯單功能本身就是為用戶提供便利性的設計，并非產品邏輯閉環中的必要元素，并不需要在所有環節都設置該功能。

將喜愛的美食添加至干飯單后，用戶下次不知道點什么外賣時就可以查看自己的干飯單，有助于產生“靈感”。在美食頻道-商家列表中增加“我的干飯單”按鈕，交互形式與購物車相同，當用戶滑動頁面時，按鈕隱藏至屏幕邊緣（底部）以避免遮擋列表內容，停止操作約 1 秒后，按鈕從屏幕邊緣浮出。點擊按鈕跳轉至干飯單頁面，記錄的全部都是用戶喜愛的美食。

如此一來，干飯單功能完成了商業閉環：在完成訂單后，主動收集用戶的偏好美食，記錄在干飯單上，當用戶不知道點什么外賣時，可以點開干飯單看看自己喜愛的各種美食，也許突然就有了靈感，有助于激發食欲。

發現未品嘗過的新菜品，增加“發現新食”功能

除了主動記錄用戶的偏愛美食外，我們還需要幫助用戶發現新的菜品，進一步解決“超限抑制”問題。細心的同學會發現，美團外賣為用戶提供了“新商家”功能，可以篩選出附近新入駐的外賣店鋪，但新店鋪=未嘗試過的新菜品嗎？我們來分析一下。

首先，美團外賣對新商家的判定時間是 15 天，只要是 15 天內入駐平臺的商家都會帶有“新店”標志。而 15 天的時間對于外賣忠實用戶來說很可能已經點餐超過十次，有很大概率已經在部分“新店”中下過單，那么對該用戶來說，“新店”其實并不新了。

其次，老店鋪也有可能推出新的菜品。比如去年 4 月麥當勞的新品麥麥脆汁雞上線后，使用“新商家”功能只能找出近 15 天開業的新商家，但發現不了這款新菜品，使用戶錯失良“雞”。

為了幫助用戶更精準地找出新的美食，我們引入“發現新食”功能，篩選出用戶尚未瀏覽過的店鋪，和推出了新菜品的店鋪。入口設在美食頻道-商家列表的底部，與“我的干飯單”功能并列。

4. 優化方案整合及總結

本次案例優化方案增加了“發現新食”和“干飯單”功能，對原版功能未做改動。

• 在外賣商家列表頁增加新功能的入口，交互形式與購物車相同，滑動瀏覽時隱藏，停止操作后出現；
• 發現新食：發掘外賣店鋪近期推出的新菜品，和用戶尚未瀏覽過的店鋪（無論是否為新店）；
• 干飯單：記錄用戶喜愛的美食菜品，在不知道點什么外賣時幫助用戶找到靈感；
• 添加干飯單入口之一，在評價彈窗中收集用戶偏好；
• 用戶首次進入訂單頁出現新手提示，告知用戶“干飯單”功能的使用方式；
• 添加干飯單入口之二，在訂單詳情頁中收集用戶偏好。

發現新食與干飯單，一個從未知出發，發掘用戶沒吃過的美食和店鋪；一個從已知出發，精準記錄用戶喜愛的菜品。再與原有的智能推薦搭配使用，三管齊下，可以更全面地幫助用戶找出想吃的美食，解決不知道該點什么外賣的用戶痛點。

結語

本文針對 12306“查詢車票”、百度貼吧“消息通知”、美團外賣“發現美食”分別做了詳細的分析和優化方案。三個案例總結下來，會發現分析的文字占了大量篇幅，最終改動的內容卻不多，而用戶體驗設計正是如此細致而嚴謹地存在于產品的每一個角落。細節雖小，想要做好卻需要大量的研究和學習，每一個微小的改動背后，都有著堅實有力的理論依據和數據分析。

希望通過本篇文章分享給大家，在產品設計中如何提升每一個功能細節的用戶體驗。文章中截圖全部來自 iPhoneX 本人賬號下的真實數據，所做的優化調整也都是基于原產品的 UI 設計規范執行。用戶體驗設計沒有絕對正確的標準和模版，我們也無法保證所有的“優化”都能帶來正向的數據變化和良好的市場反饋，我們所能做的就是在執行前做好分析研究工作，任何改動都絕非一拍腦門的事，只有充分考慮產品功能定位、面向人群、預達目標、執行成本等等眾多因素，最終的優化方案才更有可能被用戶接受和認可。

2021，設計之路無止境，唯有繼續前行。