關于「撤銷」有很多設計細節可以講，所以我花了兩周時間，將其濃縮成 3000 字，幫助各位產品設計師更好理解撤銷的設計細節。

撤銷的目的是幫助用戶取消當前的操作行為。

撤銷可以對用戶使用產品起到一種安全保障作用，讓用戶在界面中自由地探索而無需擔心操作所可能導致的嚴重后果。

或者用戶刪除了一個視頻，撤銷可以幫助用戶恢復他所刪除的內容；以及用戶進行了一步操作，覺得不太好，就通過撤銷來回退到上一步操作。

與之對應的叫「重做」，就是當用戶撤銷了當前的操作，但是想了想，還是行進到剛才已經操作的步驟好了。既給了用戶安全感，還給了用戶反悔的余地。

類似于下象棋的時候，你覺得這一步走得不好，所以悔棋了，雖然對家沒說什么，但是你心里又覺得過意不去，畢竟落子無悔真君子，所以你又把棋子放回去了（真是不怎么恰當的比喻呢）。

這樣做的目的是提升用戶使用產品的信心，增強對產品的控制感；鼓勵用戶放心地探索，快速建立起自己熟悉的操作路徑。

所以關于撤銷，我們可以從下面幾點來聊聊：

• 依次序撤銷
• 選擇性撤銷
• 撤銷在界面中的運用
• 與撤銷沖突的元素

依次序撤銷

它的意思是，依次撤銷之前的操作。

在尼爾森可用性原則里，就有一條類似的原則存在，即 User control and freedom（允許用戶自由操控）。

很多人把這條原則解讀為「撤銷原則」，本質上是沒什么問題的，因為撤銷確實需要讓用戶自由操控。但是早期的撤銷，并不「自由」，而僅僅只是讓用戶在一定范圍內「可操控」。

比如早期在一些產品里，執行多步操作，但往往只能撤銷一次，要想繼續撤銷是不被允許的，所以它的操控自由度就很低。那時候如果把這條原則解讀為「撤銷原則」，顯然是不合理的。

于是，后來逐漸延伸出多次撤銷的功能。

我記得最早使用 PS 的時候，在 PS 里面就有關于撤銷次數的范圍設定，但是我忘了具體范圍的上限與下限是多少了。

使用的方式是，比如我設置參數為 10，那么之后我的撤銷也只能操作 10 次，要想繼續撤銷，就會告知無法繼續了。

現在的很多工具產品應該是沒有這些限制了，比如 Sketch，Word 都是可以無限次撤銷直至最初始狀態或剛打開文件的狀態。

相對早期撤銷的使用邏輯，后來可多次撤銷的操作在自由度上，確實是好了那么一些。

它就是在「單次撤銷」的基礎上，給了用戶「多次撤銷」的機會，并讓用戶回到自己滿意的位置。

但是這里的撤銷，它還不夠自由，因為它是「依次撤銷」—— 每一步撤銷用戶都得經歷。

選擇性撤銷

當撤銷隨著用戶場景的變化而進化之后，才真正具備了比較自由的操控方式。

讓撤銷具備「選擇屬性」，必須與另一個元素做一個結合，那就是「歷史記錄」。

繼續拿 PS 舉例。

大家看到上面這張圖，當你在 PS 的畫板里完成了一系列操作之后，發現后面有一些東西做得不是很好，想回去重做，但是依次撤銷又覺得不好把控，于是就通過操作歷史，來選擇具體回退到哪一步。

相比于依次序撤銷，選擇性撤銷的自由度更高，也更符合其對尼爾森可用性第三條原則的解讀。

或者再通俗一點的例子，瀏覽器。

假設這時候你打開了 5 個網頁，關掉了其中 3 個，但是突然想起第 1 個關掉的網頁還有值得收藏的內容，于是依次撤銷 3 次，才打開第 1 個關掉的頁面。

而現在有網頁歷史記錄，就可以直接幫你打開之前關閉掉的所有網頁中的其中一個。

解決了用戶每一步都要經歷的問題。

當「撤銷」與「歷史記錄」結合之后，「選擇性撤銷」的出現還能解決掉「依次序撤銷」的一個關鍵問題：撤銷重做之后，無法復原。

通俗點講，就是當用戶撤銷到之前的操作，進行了新的操作行為，那么原來舊的那條線路就被廢棄了?？磮D：

當用戶操作到第 5 步，然后撤銷至第 3 步，再執行一次新的操作，那么步驟 4 與步驟 5 就會被廢棄。

大家知道很多設計師都會做版本記錄，因為 PS 的歷史記錄雖然在撤銷操作上方便了很多，但無法復原之前的操作邏輯依舊不能滿足一些設計師的訴求。

畢竟不廢棄的話，撤銷操作的邏輯就會很復雜；且通常「選擇性撤銷」伴隨解釋，說明用戶清楚知道自己當前行為會造成何種后果。但它并不能解決用戶操作過程中實際存在的這類問題。

而「選擇性撤銷」的「版本記錄」可以解決這個問題，來看下面這個例子。

結合歷史/版本記錄，比如用 Notion 或石墨寫了一篇文章，它們都會有版本記錄，過程中會根據時間維度與內容變更維度來判斷是否進行保存，那么當用戶想回滾到之前的那段內容，只要對這些版本進行點擊查看，然后選擇具體撤回到哪一步即可。

比如我今天（2019.11.05）早上花了半小時最后對文章做了一次整理，添加了圖片，它就會記錄其中的操作變化，且可進行選擇。這里無論如何撤至哪一步，其它內容都會有留存，不會消失。

也許這已經不是通常意義上的撤銷，但它確實是撤銷的升級版。

這樣看起來是不是自由操控度要高很多呢？

到這里，我只是講了「撤銷」的特性，下面來聊下它在界面設計中是如何應用的。

撤銷在界面中的運用

我們現在在很多產品里都能看到撤銷，在網頁里與移動 App 中，它的使用形式雖然多樣，但本質上并沒什么區別。

大多就是單次撤銷，因為用不到多次撤銷，多次撤銷更多是在工具里被使用。

比如油管的撤銷使用：

當用戶對一個視頻進行「不感興趣」的操作時，視頻內容會變成右邊這樣，可撤銷。這個內容會一直存在直到用戶刷新頁面時才會消失。

類似的還有淘寶網頁端的購物車，當刪除添加的任一商品后，其也會在附近位置出現可撤銷的操作。

在網頁產品中，撤銷的運用大多是這樣的。

我們再來看移動端產品對于撤銷的應用。

在 iOS 中比較常見的是微信的搖一搖手機撤銷正在鍵入的內容：

這類撤銷較為被動，經常是在無意間觸發，所以不是我們主要要聊的。

而有一類產品，撤銷會以 Snackbars 的形式出現，如圖：

當這類郵箱產品，刪除了某封郵件后，在底部就會出現這樣的提示，告知用戶可撤銷上一步行為。

更多的還是工具類產品，比如修圖類產品 Snapseed：

它有單次撤銷，也可以重做，還能多次撤銷，多次撤銷就是點擊「查看修改內容」之后，右圖出現的樣子，它會把所有步驟都呈現出來，給予用戶選擇具體撤銷至哪一步。

其實更多的也就是這樣了，但是，為什么呢？為什么在非工具類產品里撤銷很少見呢？難道用戶從來不會誤操作或操作之后反悔？

下面一節來解答。

與撤銷沖突的元素

先放結論：當某個功能具備撤銷屬性時，切勿再使用二次確認對話框，反之同樣成立。

撤銷與二次確認，是兩種東西，雖然有時候解決的是同一個問題，但是它們的屬性是完全不同的。

舉個例子：

上面這張圖，左邊是在執行操作前彈出的確認框，右邊是執行操作后彈出的提示框。

二者的區別很明顯，二次確認的刪除提示框更具警示效果，后者作為提示，較為弱化，且通常是在用戶操作完成后彈出。對于用戶來說，在非工具類產品中，前者更好的抑制了用戶的沖動行為或誤操作行為。后者作為提示類控件，不具備警示效果。

所以它們不應該同時出現，且它們雖然是解決同一個問題，但是是完全不同的情況。

于是，在大多數產品中我們很少看到撤銷的使用，因為大部分需嚴謹的操作都會有二次確認，并不嚴重的操作也就不需要任何提示。即使是上述提到的郵箱刪除，沒有二次確認也是因為它有撤銷作為提示且還有回收站允許用戶檢查確認。

所以，除非是場景與之密切相關的，比如社交產品內容發送后的撤回功能。

微信早期的撤回，只是撤銷，它并不具備「重做」屬性，現在撤回，內容會重新出現在輸入框讓用戶重新編輯。

它們之間的差異是：它并不會產生嚴重后果，但確實會產生小問題。比如誤操作發出信息，或發出后發現話術并不嚴謹。

所以這一段內容只是想告訴各位：二次確認操作與撤銷操作是兩種不同的東西，雖然看起來是解決同一個問題，但它們的差異也是非常明顯的。必須謹記。

另外還有個提示：心細的同學會注意到文章里或其他產品里出現的「撤銷」通常也會寫成「撤消」。在別的領域里這是兩種不同的內容，但在產品設計領域里，目前并沒有對這兩者做明確的區分，所以暫時不用過于糾結。

總結

這篇文章講了很多內容，我在這里梳理下：

• 撤銷分為依次序撤銷與選擇性撤銷；
• 依次序撤銷有單次撤銷與多次撤銷，以 PS 為例；
• 選擇性撤銷大多在工具類產品里被使用，它與歷史記錄結合，解決了依次序多次撤銷部分內容被覆蓋的問題；
• 在非工具類產品里，被使用更多的是單次撤銷，是因為場景限制；
• 撤銷與二次確認不可同時出現，它們看起來是解決同個問題，但之間存在較大差異。

所以當你設計的產品要用到撤銷時，也要注意這些細節問題。

這就是本篇文章的所有內容了。其實這篇文章里包含的內容有很多，而且有很多爭議點我都沒放出來，直接一筆帶過給出正確結論了。寫這種大部頭文章太累，要思考的點很多，需要幫助讀者從多視角排雷，很可能導致初學者在讀文章過程中出現閱讀吃力的問題。所以之后還是會挑一個點來寫吧。

文章來源：優設

我們通過門鈴聲兒得知門外有人來訪，也能通過電話鈴聲得知正被人呼叫。短信通知也有著類似的作用，包括各類產品的消息推送。

但不同的是，消息推送的重要性隨著「通知」被濫用而變得不那么重要了。它們變得不像門鈴或電話鈴聲起到的作用性那么大，包括短信現在也大多是垃圾信息。

而且，通知越來越多地通過各種方式去觸達用戶。比如消息未讀的紅點提示，或者顯示消息的數字統計，以及手機使用過程中的頂部提示與聲音或震動的提醒，等等。

但我們還是無法抑制點擊圖標的沖動，這僅僅是因為它具有未讀的計數或紅點提示，即使我們已經知道當中的內容并不重要。

而我要說的是，當通知內容變得次要且被濫用之后，它仿佛成了一種違背設計原則的功能 —— 中斷用戶當前行為。因為它打破了用戶與產品之間的層級關系，破局至產品之外來吸引用戶的注意力，這是一個非常打擾的行為。如果我在看書，突然收到一條并不重要的消息，那我一定會非常反感。

所以，為了不被「紅點」支配，以及不讓通知所打擾，我會把手機里所有產品的消息推送都給關了。

但是，以上內容并不能說明通知的無用論。同樣有許多用戶還是沉迷于通知的使用上，它所控制的是用戶對于某個產品的控制欲，擔心錯過某條消息，就好像我在豆瓣寫了篇隨筆，就想看別人給我點贊評論的消息，但我又不可能一直盯著，所以通知這時候就起到了一個很好的作用。

以至于對于優秀的產品人或設計師，包括運營來說，利用好通知，就能掌握用戶心理，巧妙的將用戶留在產品中。它們甚至有助于與打算放棄產品的用戶建立聯系并促進互動。

那么，我們應該如何更合理的設計通知呢？下面我們通過「通知的組成部分」以及「通知的使用類型與規則」來詳細做一次拆解。

通知的組成部分

關于通知的簡單定義：它是一種吸引用戶注意的功能模式，讓用戶獲悉新事件的信息動態。產品將其發送給用戶并與用戶產生交流。

因此從這個定義中我們可以知道，通知有兩種形式，分別是被動只讀型和操作反饋型。

被動只讀型，是指該信息可讀，但不可進行操作；操作反饋型，是指用戶可對該通知進行操作，如某寶訂單支付成功后的地址信息確認通知。

所以在梳理組件的時候也要注意掉這個差異。

1. 消息中心

這里的消息中心，是一個信息匯總中心，但并不一定是信息來源。意思是，信息來源可能是有很多用戶在你的文章下面點贊了，而這個點贊行為被匯總到了消息中心，再用消息中心指引作者去到文章頁面查看具體詳情。

所以它是一個匯總表。但也有可能它就是信息來源點，比如一些系統通知，告知要升級，因為它沒有其他功能可承載，所以只會在消息中心里出現。

或者類比 iOS 系統的通知中心，如果通知是 App 推送的，那么它會指引用戶進入某個 App；如果通知是系統行為，如勿擾模式，「6:00 前來電和通知將會靜音」這個通知，是只可在通知中心進行操作的。想要更改，就需要手動打開設置。

2. 通知指示符

它可以是點，也可以是計數器，只要表明目前消息中心有新的信息就可以。我個人一直覺得這就是讓我們多數人養成強迫癥的罪魁禍首。

3. 信息標題

它主要是指該信息來自于誰或屬于什么子類型，比如用戶互動點贊消息，評論消息，系統消息等等。用戶可以通過標題來獲悉該信息類型，再通過內容摘要來判斷內容是否重要。

當然，這里的摘要如果過長，就需要省略處理，引導用戶進入消息源或消息中心。

4. 推送時間

推送時間是一個看起來簡單，實際上也好像不是很復雜的邏輯。只要說明該通知的發送時間即可，但是需要注意的是時間段問題。比如幾分鐘前，幾小時前，幾天前，這里的邏輯是按照時間推進規則持續增加來告知用戶該消息的推送時間節點的。也就是過得越久，時間概念就越大。

5. 通知圖標

上面講到消息類型，我們也經常會在各類產品中發現不同通知的類型會匯總在各自的類型下。包括用戶所接收到的信息，通常也會告知用戶該信息屬于什么類型。有時候，標題可能會更細，但是用戶通過圖標可以判斷該信息屬于什么類型，甚至都不需要仔細查看標題與內容。

但是，并不是所有產品的信息都可以通過圖標來判斷，有時候圖標只是一個大方向，如果手機鎖屏，相對于用戶來說，這條通知只是告訴用戶該信息是由什么產品推送，而并不能指向至該產品的什么類型的信息。所以在使用的過程中，同樣需要根據業務的場景，謹慎地選擇圖標。

6. 閱讀指示器

它就像是上面提到的紅點，這里指的是進入 App 的消息中心之后，所顯示的內容。

7. 操作行為

這里的操作行為分兩種，分別是 App 外與 App 內，它們之間的操作邏輯是不同的。iOS 系統通知的清除操作，只是在系統的通知中心將該信息清除，進入具體 App 后，這條消息還是會存在。而在 App 內刪除該條信息，則該信息才會真正消失。

所以從上面可以看到，通知推送，是有兩大類別的，分別是 App 外與 App 內，它們之間的邏輯關系與展示形式會有所差異，需要根據具體情況進行設計分析。

8. 小結

對上面的內容進行總結，可以得到這樣一幅畫像：

大部分系統或產品的通知組成，都可以通過此圖概括，唯一不同的是，它們會隨著不同的業務而發生變化。

比如豆瓣的推送消息告知用戶近期有新的電影上映，那么通知來源要么是電影模塊的功能詳情頁，要么是通知中心的系統消息；而通知類型就是內容更新；詳情則根據具體內容來組合排列；最后送達至用戶。

而其中的差別就是，如果是通知中心推送的，用戶點擊之后則是進入通知中心列表。如果是具體功能推送的，那么用戶點擊進入的就是具體功能頁面。如下圖所示：

從這里可以看出，通知是有具體模式的。

一旦確定了通知的主要目標，以及想要解決的問題，包括它們如何對業務產生作用以及對用戶形成吸引力，就可以確定通知的具體樣式了。

在這一節里只要知道通知的組成部分與通知模式如何指引用戶進入 App 即可。后面我來帶大家理一遍邏輯，以及在設計通知時要注意哪些問題。

通知的使用方法

聊完上面的內容之后，我相信大家對通知的組成與使用模式已經有了全新的認識，但也僅此而已，我們還是不知道一個優秀的通知功能應該從哪些方面去提升用戶體驗。這里面所包含的不止是表象，還有內在的規則邏輯。所以從這一節開始，我們仔細來梳理一遍。

從我們平時使用到的，以及上文提到的，可以大概先梳理出幾類常見的通知類型。

1. 用戶信息類通知

這種類型的通知有很多，比如微信消息發送，知乎私信，手機短信等等，它們主要由用戶主動生成發送至其他用戶被動接收，作用就是促進用戶與用戶之間的互動關系，以提升用戶使用產品的頻率與時長。

這種通知，可給予用戶操作也可不給予操作，不操作就是讀取，并回復；操作就是可對該用戶的信息進行屏蔽、已讀、刪除等設置。

這是最常見的通知類型，在多數社交產品與有社交特性的產品里都能看到。

說明

之所以給予用戶信息的操作行為，是因為用戶信息可分為感興趣的與不感興趣的，它主要取決于人。不感興趣的人，頻繁的發送信息，會影響用戶對產品的好感度，畢竟有很多用戶消息并不是用戶想要接收的，所以在社交產品里，用戶可刪除好友，或拉黑好友；在有社交屬性的產品里，用戶可拉黑賬戶，以達到不被騷擾的訴求。

如果沒有到達刪除好友的程度，也可對該好友的信息進行屏蔽，甚至對該好友信息做已讀而實際上未讀的處理；或者對重要信息做未讀而實際上已讀的處理。

當然，用戶還能對群消息做更復雜的設置。這就是產品對這類通知的一種優化方式。

2. 系統推送類通知

我們經常會在手機上收到一種系統類通知，或者在 App 中也會收到類似的系統通知。大多是關于系統升級，密碼更新等。

這類通知多數是用戶被動接收，且對于系統與用戶來說是較為重要的。當然也有不重要的，比如 App 更新說明的通知，告知用戶新功能有什么變化，或系統更新了什么等等。

對于這類通知，用戶大多無法進行設置，因為它們比較強制，沒有可以商量的余地，類似于告知用戶：我們有新的消息，比較重要，你來看看，即使你不打算更新或執行也來看下。

說明

系統類通知，通常來說較為被動，要么強制用戶執行操作，要么就是提醒用戶系統近期做了更新，或者是一些并不重要的信息提示，比如勿擾模式。

強制類系統通知不能頻繁，否則會給用戶造成控制欲反制的副作用。類似于本身用戶使用產品需要對產品享有控制權，現在反而被產品控制了。這是不行的。

3. 通用推送類通知

這類通知就是第一節中提到的那些，比如點贊/評論，內容更新等等，這類通知如果是忠實用戶，那么或許不會反感它的頻率，當然還是需要適當。但如果是普通用戶，那么造成的影響就是直接關閉該 App 的所有通知。

我們現在的很多人，之所以開始反感通知的主要原因，就是這類通知所造成的。內容不斷更新，隨著時間的推移，每天推送多條對于該用戶來說無用的通知。包括只適合一些符合條件的用戶參與的活動通知也推送給所有人，那么用戶就會逐漸對這類產品的通知失去興趣，造成無法彌補的損失。

即便像某團一樣，經常彈出開啟通知的彈框，也依然無法召喚回用戶。這就是很典型的下場。

說明

通用型通知，如果是業務很復雜的產品，就必須建立通知推送的功能模塊，給予用戶進行選擇接受哪類信息的權力。允許用戶進行相應的設置，如活動類推送可拒絕接收。

在很多產品中都已經置入這樣的推送模塊設置，如下圖。

這類內容就是針對于產品的具體業務進行細分。

比如興趣精選，私信消息等做好類別劃分。用戶可對自己感興趣的通知做選擇性的推送接收。

另外就是，在相同賬戶的不同設備之間，推送應該同步推送與被處理。不能這邊推送了，那邊沒推送，或者這邊處理了，那邊沒被處理。

4. 智能推送類通知

不知道大家是否有印象，在使用如大眾點評等產品時，只要你切換了城市，產品就會推送通知告知用戶該城市有哪些值得游玩的景點與品嘗的美食。

雖然這類通知還算不上多少智能，但至少在用戶群體中是存在這類訴求的。而這類訴求有時候并不能主動感知，因為用戶可能會想不起來通過哪類產品來查找附近美食。當這么一條通知出現的時候，正好解決了用戶的問題，反而提升了用戶對于產品的好感度。

現在很多產品的通知都逐漸智能化，不會像以前那樣，三更半夜發來一條無關緊要的通知。而出現這類問題的主要原因還是在于產品、設計、運營，在這方面沒有下過功夫，只將通知作為一種普通的工具來使用。導致用戶開始排斥通知，將其強制關閉。之后，就很難再讓用戶開啟了。同理心效應，當做這類功能的時候，可以回想一下自己是如何被其他產品打擾的。

隨著大數據的發展，我相信未來的通知系統會更加全面，且能做到千人千面的模式，不過在此之前，各位產品設計師，還需要對通知下一番功夫才是。

5. 小結

我們還可以繼續舉例說明，但是基本大同小異，所以到這里為止，我再對上面的內容做一次總結，梳理出一個好的通知應該是如何設計的。

干擾最小化：通知本身具有強制性和干擾性。它的目的是把用戶的注意力吸引到產品上來，所以要認真思考發送通知的內容、時間、頻率；不要提醒用戶當前屏幕上已經處于展示狀態的內容；也不要推送與用戶無關的系統信息。

跨設備：當用戶讀過了某條信息，這條信息應該不再做展示。同理，用戶也應該能夠在其它更適合接收消息的設備上找到已讀信息。用戶通知應該在所有設備上進行同步。

允許設置：允許用戶在「設置」中禁止或調整通知的形式。如案例一，通過選擇推送內容，來影響接收推送的頻率。案例二，可選消息提醒的形式是紅點+數字，或僅是紅點。

時效性：良好的通知應盡可能實時推送。而不是等這件事情都過去很久了，才推送給用戶知道。

支持匯總：把同類型的通知合并為一條，并顯示信息未讀數量。也可以考慮一鍵展開通知，顯示信息詳情。

可操作性：把通知和操作結合在一起，讓用戶不需要打開首頁就能對特定通知進行常規操作。操作應該清晰明了，且僅在未重復默認操作時提供。同時操作應該是有意義、實時、和內容對應的，并且能讓用戶完成某個任務。如案例一，可以在不打開郵件的情況下，直接對通知進行管理、查看和清除。案例二中的操作針對的是未讀郵件，可便捷地在通知板面進行回復、刪除、標為已讀或垃圾郵件。

總結

對本篇文章的拓展總結：

• 通知具有召喚屬性，但是頻率過多就會變成打擾，所以要注意通知的頻率與內容重要性；
• 設計師或產品經理應該將通知的內容分類梳理出來，以便維護或新增必要需求可能需要用到的推送信息。
• 通知一般為兩種類型，一類是推送只讀型，一類是操作反饋型；設計師需根據不同類型的通知做好對應的設計，針對具體問題具體分析；
• 想要利用好「通知」，也需要對業務有詳細的了解，再代入本文所列舉的注意點，就可以設計出一個體驗更佳的通知模式。
• 通知規則不會脫離本篇文章的范圍，所以只要詳細研讀，必會有所收獲。

文章來源：站酷

先問一個問題：怎么樣衡量一個設計好與不好？工作中實踐越多次，越會發現華麗的設計稿并不是體現設計師專業能力的唯一標準。普通設計師和高級設計師區別在于，設計方案是否具備完整設計思路；設計對于業務有沒有真正的價值體現；以及設計方案的推動落地的完整性到底有多少。設計越往后走，越考驗產品思維，設計思維，以及設計推動能力。這是產品設計師需要關注的核心三要素。

設計師在工作中接到設計需求會不自覺的第一時間想著如何去進行視覺表達，視覺表達確實非常重要，也是公司對于設計師的核心價值的定位之一，但視覺表達只是其中設計專業本職工作中的一個環節。設計師還要應該能夠站在產品、設計、技術等不同維度去思考設計方案的可行性。產品打磨-視覺呈現-落地執行，在這三個核心點里面設計師分別有不同的定位和價值所在。 

  一. 產品“雙標”滿足   

產品打磨包含產品規劃，內容組成，界面布局，交互梳理等等…所有環節的工作是為了符合產品最終的目標。產品所有的能力會核心圍繞兩個點：1商業變現 2用戶需求滿足。這兩個目標在產品執行的環節有時候會有一些沖突，在產品打磨階段設計師通過怎樣的方式，做到既滿足產品商業目標又滿足用戶體驗需求？可以按照以下幾個步驟進行分析尋求切入點： 

這里用騰訊動漫付費模塊舉例說明： 項目背景是騰訊動漫產品要做付費體系升級設計，接到需求先有由產品源頭一步步深入，逐步展開設計方案的規劃。 

 01 產品目標確認  

通過對項目背景的解讀和產品方案的深入了解，以及總結當前存在的一些問題，可以明確得到項目中產品核心目是什么。付費升級核心原因是付費轉化低，用戶付費意愿不夠強烈。此次升級的核心目標是促進內容消費，提升付費率。 

 02 分析用戶路徑  

確認目標之后從哪個模塊兒開始進行首要需要考慮的。對于現有現有功能的升級，建議核心從產品本身著手，可以根據用戶行為分析，獲取用戶常規使用路徑，找到用戶使用場景下的核心目的，從而去挖掘用戶在付費路徑下的訴求點，根據訴求點找到付費升級的觸點。這里我們羅列了用戶閱讀產品的路徑。 

 03 觀察用戶核心需求是否被滿足 

 用戶在每個場景下都會有“痛點”和“癢點”。比如在閱讀前，核心目是想快點看到漫畫內容；閱讀過程中，想要及時宣泄對漫畫的故事情節的感受；閱讀后，希望找到更多相關內容或者能夠和內容有更多的互動。目前產品在這三個關鍵的路徑節點都存在一些問題，閱讀前對于付費缺乏正向引導，閱讀過程中互相行為較少，閱讀后沒有更多延展內容可供消費等。 

 04 洞察設計切入點  

根據用戶在閱讀 “前 中 后” 關鍵路徑的節點的不同情緒反饋，我們可以做出找到相應情感滿足切入點，并且制定解決方案 

 05 制定設計方案  

將之前找到的設計情感切入點用交互和視覺的形式呈現出來，盡可能完整的表達清晰。下面展示是關于付費升級優化的完整視頻DEMO。整個方案采用趣味情感化形式為核心設計思路，逐步去引導用戶付費。讓用戶在趣味互動中完成產品的商業轉化目標。 

https://v.youku.com/v_show/id_XNDM0NDg1MzY2MA==.html

 二. 設計呈現的“差異化”   

視覺呈現是設計師們都比較擅長的工作，但不同專業高度要求下方案最終呈現出的效果是完全不一樣的。好的設計方案，需要在設計上做出明顯的“差異化”，這里的差異化是指要區別于常規輸出一般的水平。差異化的可以從多個點入手：

優質的設計美感：

美感是作為設計師首先需要培養的技能之一，也是在后續職業生涯的一直需要用到的技能。設計師被神職化的很大一個原因就是因為設計師的美感比一般人要好，有懂得欣賞美、鑒別美、以及創造美的能力。單一從視覺層面，設計作品是合格品還是精品，最終取決于畫面的精美程度。項目不分大小，再小的一個項目都可以做出精致品質，這也是體現設計師專業度的核心衡量之一。

完整設計思路：

設計方案的完整性也能夠很好的設計師專業度的差異化，幾張圖的設計稿和一個有完整設計思路的設計方案在品質上自然是明顯差別的。設計師不光需要將設計呈現出來，更需要有嚴謹的設計思路并且表達出來讓受眾到你的設計想法。設計前期分析、中期執行、后期落地以及迭代優化，能夠讓設計師有意識的鍛煉和提升自己的設計思維，對于設計師能力提升有必然的幫助。 

獨特創意：

設計差異化呈現上，創意是一個非常好的切入點。行業大趨勢的前提下，現在同類產品越來越趨于同質化，受眾使用產品的時候都會有一些常規認知，關于功能的、交互操作的、內容組成的等等，淘寶和京東、大眾和美團、甚至QQ音樂和網易音樂在產品使用體驗上都有高度重合的地方，這些已經在用戶心智中形成習以為常的認知感受。如果能夠在用戶的常規認知里，用創意手法呈現出超出他們預期的內容使其驚喜，產品設計就會有明顯差異化體現。 

善用情感化：

具備美感的設計能讓作品看起來有高級感，但更為高級且有效的是能夠引起用戶情感共鳴的設計。設計是主觀的，對于設計每個人都有自己的想法，也正是因為主觀的設計感受，能讓設計在情感化打造方面可以有很多的嘗試方向。能夠引起受眾主觀情感上的共鳴和認同的設計，會形成產品的核心記憶點之一。設計師對于情感化設計往往會有一些誤區，認為圖形可愛，色彩羨慕，動效流暢且能夠形成一套視覺體系，就能夠算情感設計。真正的情感設計是需要從用戶角度出發，挖掘用戶的認知領域和喜歡，從而去進行符合用戶情感訴求的呈現。 

三. 方案推動的效能管理 

設計方案輸出只是整個產品生產流程中的一個核心環節，產品上線后體驗如何最終取決于落地實現的程度。在方案落地支持過程中，效率協調和實現能力是保證設計方案貫徹一致執行的關鍵因素：

 協作  

產品設計師工作協調分為內部協作和外部協作。內部協作即設計師之間的溝通協同，主要內容是如何保持設計語言一致性，除了制定設計規范，還可以建立公共控件庫，線上調用?？丶炷軌蚴乖O計師協作無學習成本，設計師輸出設計稿效率也能夠大大提升，同時保一致性。

外部協作主要是和下游的技術同事直接的工作對接，設計方案的交接方式以及開發獲取信息的效率很關鍵。在開發接收設計方案的時候，盡能力降低獲取成本以及理解成本。比如設計稿的標注，在標注上設計師一般會花很長時間，開發也需要逐步查看，偶爾還會有標注遺漏的地方。我們團隊會直接采用插件，設計稿及時同步，并且開發可以自己隨時查看每個元素的標注信息，便捷。

這里推薦兩款協調軟件：一款是InVision可以在sketch里進行控件協同調用，所有想用的元素直接源文件調用，不需要再問同事要源文件！另一款是Zeplin技術同學可以直接查看元素屬性以及間距等，設計師解放雙手不再需要標注！

官網鏈接： 

https://login.invisionapp.com/auth/sign-in   

https://zeplin.io/

實現能力   

專業技術之間的壁壘，也會成為設計方案實現的阻力。同樣的界面，設計人員用設計軟件實現，技術人員用邏輯代碼實現，實現的方式和成本存在很大的差異性，所以往往設計師認為很簡單的需求在開發層面的確非常難實現。當然，不是所有需求都是無解的，設計師在技術實現層面還是可以做一些事情：

01 方案前置溝通

設計一個新的功能的時候，如果有非常規的設計方案，可以提前和技術人員溝通實現的難易程度，讓技術人員有前期預判和預演的時間。并且，可以將設計做成簡易DEMO方便技術人員快速理解，避免雙方存在信息不對等的情況。

02 搭建開發控件庫

開發控件庫和設計規范一樣，是最基礎但應用最為頻繁的模塊兒。開發控件庫可以將最基礎的元素形成固有規范，所有開發實現都用同一套規范，以確保實現的高度一致性，同時也能夠提升實現效率和設計還原。設計可以輔助開發一起制定開發控件庫，確?？丶旌驮O計規格的一致性。

03 尋求技術語言共通性

盡量將設計方案轉化為技術能夠理解和復用的形式進行對接。除了靜態設計稿的標注，設計和技術實現最大的難點在于動態交互的實現上，對于動態設計，將設計方案轉換為代碼文件交付給技術實現，這樣能確保功能的正常實現同時減少后期設計還原性的偏差。

以上初步總結的關于產品設計師在設計過程中從前期產品規劃到中期設計執行再到后期開發落地應該注意的一些核心點：

第一條，設計方案既要滿足產品目標又同時要兼顧用戶體驗；

第二條，優秀的設計師，會保持設計方案的“差異化”；

第三條，設計師職責除了確保設計方案完整性，更重要的是推動設計方案的完整落地。

在產品設計過程中，設計師需要關注還有很多關鍵點，這里也歡迎大家一起補充交流，正是這些關鍵點，將設計師的思維逐步打開，使其成為一個具有全鏈路思維的設計人才。 

文章來源：UI中國

交互手勢是用戶操作的重要部分，交互手勢的設計好壞非常影響用戶體驗，那么，交互手勢的設計上對于容錯性和邏輯性需要注意什么？

隨著用戶體驗被愈發的重視，更多的 APP 偏向于使用多手勢優化用戶的操作流程，降低使用阻力。

點擊某個確定的按鈕的手勢操作雖然被普遍使用并被用戶熟知，但是增加更快捷的手勢操作可以大大增大操作熱區，提高操作效率，如下圖。

然而，我們可以發現由于不同產品的設計師對于用戶體驗的理解不同、交互層面的思考不同，導致設計的交互手勢也不同。

有時同一種操作在不同的 APP 中交互手勢也是不統一的，這無疑增加了用戶的學習成本和記憶成本。

舉個例子，iOS 端的得到和有書的播放頁的打開和關閉方式。

得到有兩種方式打開和關閉頁面，用戶可以通過點擊控件或上滑控件打開播放頁，通過點擊收起按鈕或下拉頁面關閉播放頁。但是有書只有一種方式打開和關閉，用戶只能通過點擊控件打開播放頁，通過點擊返回圖標關閉播放頁。

這讓習慣了使用得到的我去使用有書時，感覺非常別扭，每次都嘗試用得到的手勢去操作但是都失敗了，失敗后我下一次并沒有記住仍然用手勢去操作，如此反復令我相當沮喪。

容錯性

容錯性是一個很大的話題，今天我們僅僅在交互手勢層面上討論。

上面的例子中，有書并沒有設計滑動手勢去打開和關閉播放頁，那么我以我的經驗去進行的滑動滑操作在有書這個產品中就是錯誤的和不被產品識別的。但是這種手勢又廣泛存在于大量的音頻播放 APP 中，如喜馬拉雅、荔枝 FM 等。

一旦用戶從這些 APP 遷移到了有書，本來養成的操作習慣在有書就失效了，用戶就會感覺“這個 APP 很難用，用起來很不舒服”，進而可能放棄有書轉而投向其他產品懷抱。

與手勢設計類似，這也是為什么現在的同種類型的 APP 的信息架構設計越來越同質化，當我們打開淘寶、天貓、京東時我們有時感覺就像是同一個 APP ，本質上也是為了降低用戶的遷移、記憶和學習成本。

如下圖所示，提高手勢的容錯性對用戶的意義。

很多優秀的產品考慮到了上述問題，設計了多手勢來優化用戶體驗。

舉個例子，在 APP Store 的首頁點擊一個推薦卡片后進入詳情頁，由于詳情頁是直接由卡片放大轉場的，不同于傳統的新頁面右側進入和從底部彈出。

在用戶的使用習慣和認知中新頁面如果從右側進入就可以通過右滑返回，從底部彈出的話就可以下拉返回。因此，當用戶面對卡片放大進入新頁面這種全新交互時可能會疑惑如何返回，對此理解不同的用戶可能會嘗試右滑，也可能嘗試下拉。

APP Store 的設計在此就有很好的容錯性，用戶可以通過三種方式返回首頁，分別是、右滑返回、下拉返回和點擊叉號返回，這不但降低了用戶的記憶和學習成本，也便于不同習慣的用戶使用。

針對不同的場景，手勢的使用也會有不同。

一個很好的案例是知乎的評論：知乎的評論的關閉方式有三種，分別是下拉、右滑和點擊叉號。

用戶觀看評論的場景有兩種，第一種是只想看一下精選評論然后關閉，第二種是被評論吸引后一直往下看。當用戶單手操作不方便點擊叉號時，下拉對應的是第一種用戶；右滑對應的是第二種用戶，不管用戶看了多少屏的評論，隨時可以通過右滑關閉評論（因為用戶翻閱了很多屏評論后需要下拉到第一條評論時，下拉關閉評論手勢才會生效，所以第二種用戶一般不使用下拉去關閉評論）。

可能你會心生疑惑：“第一種用戶也可以使用右滑來關閉評論呀”，確實可以，但是對于人的操作習慣來說，上下滑動會比左右滑動更方便。

還值得討論的是蘋果自 iPhone 6s 開始加入的新交互方式 3D Touch，它允許用戶通過更大力度的重按呼出情景菜單快捷地使用高頻功能而不用先打開 APP，對于追求效率的用戶來說簡直不要更方便，但是對于不支持 3D Touch 的機型則無法使用情景菜單。

因此，在生活中我發現這樣的現象，很多使用慣了3D Touch 的用戶換到無 3D Touch 的蘋果機型后很不習慣，總是嘗試去重按但是是無效的。

其實在很多安卓手機上也有情景菜單這一功能，它巧妙地將卸載也加到了情景菜單中，因此用戶只需要通過長按就可以獲得所有需要的功能，而不是像蘋果那樣長按是卸載而重按是情景菜單。

我猜測蘋果為了適配所有機型，提高容錯性，從今年的發布會的 iPhone 11 和iPhone 11 pro 開始，取消了 3D Touch，轉而使用 Haptic Touch （有震動反饋的長按）代替。當你長按某個圖標時，感受到震動后松開，即可呼出二級菜單；如果震動后仍不松開，則進入到卸載 APP 時的抖動狀態，使得之后的即使不支持 3D Touch的機型可以使用便捷的情景菜單了。

對于不支持 3D Touch 的老款機型會不會在 iOS 13 更新后也可以使用 Haptic Touch 呢？

如果一致統一的話，容錯性將大大提高，我們將拭目以待。

不僅僅是 iOS ，Android 的版本 Android 10經歷了 6 個測試版迭代后正式發布，我們發現交互手勢是 Android 10 的一個巨大亮點。Android 10 在第三版內測系統開始引入全局手勢操作，用戶啟用后，屏幕底部便不會再出現虛擬按鍵和導航欄，只會剩下一個指示條，上滑返回主屏、側滑返回上一層的操作邏輯也均和 iOS 保持一致。

這可能標志著安卓手機一直以來在國內各家廠商的各種創新手勢的割裂生態中即將重歸統一，并和 iOS 保持一致。

這種妥協將大大提高在用戶使用一款新安卓手機時的容錯性，同時降低了今后用戶在兩大系統之間的遷移成本。

邏輯性

再談談邏輯性，在交互手勢的層面上，如果用戶能夠通過某個手勢進行某個操作后，按照邏輯，用戶也可以通過反向的手勢或對應的手勢進行逆向操作。

比如，在微信首頁下拉調出小程序頁面，之后可以通過上拉返回首頁。點擊加號呼出更多操作，再次點擊加號收起更多操作。

如果違背了用戶的心理模型和邏輯性，用戶就會感覺到混亂和不適。

這里舉一個反例， Uki 的個人主頁可以通過點擊或下拉底部的固定底板收起更多信息，但是收起后只能通過點擊展開更多個人信息而不能上拉，不符合邏輯與用戶的心理模型。

如下圖所示，邏輯性對用戶的意義。

有的時候，我們會發現為了提高容錯性，我們會犧牲一部分邏輯性。

就像上文提到的知乎關閉評論彈出框，邏輯上它是從底部彈出的，但是不但能夠下拉關閉還可以右滑關閉。盡管右滑關閉有些違背用戶的心理模型，但是確實給用戶帶來了很多操作上的便捷。

如何設計

1. 是否需要加入多手勢操作的考慮因素

我們需要考慮的因素包括使用頻率、危險程度和特殊體驗。

1. 使用頻率：當一個功能的使用頻率足夠高時，我們加入多手勢操作去提高用戶操作效率才是有意義的。一個低頻的功能的特殊手勢操作很容易被用戶遺忘。
2. 危險程度：如果一個操作不可撤銷且存在危險性質，我們最好不要加入多手勢操作。此時我們需要用戶更加專注，如果加入多手勢操作可能會增加誤操作的概率。
3. 特殊體驗：當我們需要加入特殊的模擬體驗時，此時我們可以加入多手勢操作。如探探左滑無感右滑喜歡，給用戶帶來的“翻牌子”感覺是點擊操作無法替代的。QQ 閱讀下拉擬物繩燈進行日間和夜間模式切換，這種存在我們記憶中的交互方式能夠喚起我們的情感。

2. 評估所選手勢的考慮因素

1）考慮不同平臺的硬件系統和操作系統特性

由于硬件與操作系統差異，iOS 系統支持很多手勢，但是安卓系統在手勢支持方面就不如 iOS 豐富。

安卓硬件設備的差異比較大，不同安卓手機廠商會在安卓系統的基礎上自定義系統的手勢操作，因此對于手勢的支持也有較大的差異。對于這種情況我們需要熟悉相應平臺的規范，做到心中有數。

2）考慮所選的手勢的學習成本和記憶成本，用戶是否已經被教育

如下圖所示，盡管設備支持的手勢數量多不勝數，但是日常使用 APP 時，大部分用戶習慣使用的手勢很少，比如單擊、雙擊、滑動、上拉、下拉、雙指擴張和收縮等。除此之外的手勢教育成本和學習成本很高。

一般比較通用的功能是沒有必要在此處創新的，但是如果一些特殊的操作確實需要加入時，我們就需要考慮下面的問題。

a. 如果沒有教育成熟，考慮加入教學或搭配簡易的操作方式

對于我們需要加入的手勢操作當前用戶并未被教育成熟時，我們需要考慮加入手勢教學，具體的手勢教學類型下一部分會詳細討論。

然而，大部分情況下用戶的記憶是短期的，教學內容可能會被快速遺忘，下次用戶使用 APP 時仍然不會使用特殊手勢。此時我們應該將一些比較難以記憶的手勢操作搭配一個簡單的手勢操作。

比如 QQ 閱讀的下拉擬物繩燈切換夜間模式的手勢操作設計，其考慮到了有些用戶在現實生活中并未見過擬物繩燈，并不知道是要進行下拉才能觸發操作。因此，QQ 閱讀貼心地搭配了一個簡單的點擊操作，用戶通過點擊繩燈也可以切換夜間模式，如下圖。

b. 考慮所選手勢是否可能導致沖突和誤操作，如果導致了，考慮如何避免和折中

最常見的手勢沖突情況就是 APP 的手勢與操作系統的全局手勢沖突。

解決方案有兩個，一是避免設計與全局手勢一致的手勢操作，例如 iOS 的在屏幕邊緣右滑返回、全面屏機型的底部上滑退出應用等全局手勢操作；二是仍然設計與全局手勢沖突的操作，但是將全局手勢部分禁用或以其他的方式區分開。

如下圖有書播放頁的案例，由于進度條滑動控件過于靠左，導致使用 iOS 全局右滑返回手勢時有時會產生誤操作，即本來想要右滑返回卻不小心滑動了進度條。

這種情況下我們可以標注一個右滑手勢禁用區域給開發工程師說明情況，將此情況避免掉即可。

誤操作指的是，我們設計的手勢操作與 APP 內的其他操作或系統全局手勢操作接近導致用戶觸發了非預期的操作。比如 iOS 端的知乎被吐槽的一個右滑返回手勢操作，經過研究發現，由于 iOS 端的知乎在瀏覽回答的頁面設計的右滑返回的熱區過大，導致用戶上滑瀏覽的時候如果手指的滑動角度變化幅度過大一不小心就觸發了右滑返回，再次進入回答后又需要翻頁很久才能找到之前離開的地方，很影響體驗。

我覺得知乎可以減少熱區，將熱區調整為 iOS 全局的右滑返回區域即可，如下圖所示。

當然，產品設計需要平衡與取舍，如果減少了熱區是否會影響其他用戶的體驗還需要考慮和調研，兩者并無絕對的對錯

3. 讓用戶了解并使用新手勢

當新手勢無法直接讓用戶感知時，我們需要加入一些手勢教學幫助用戶快速上手使用。

1）手勢教學方式

a. 浮層和動畫引導使用靜態或動態的手勢圖片或氣泡示例告訴用戶使用哪種手勢進行操作

相比于靜態，動態比靜態更為直觀和易學。

b. 內容隱喻通過微妙的視覺線索暗示用戶此處可以通過某種手勢進行操作

由于教學內容難免具有干擾性，對于高級用戶來說是不必要的，但是對于初級用戶又是必要的，因此以這種內容暗示的方式使教學極為輕量化，在低干擾的情況下使得用戶學習了手勢操作。

如下圖，嗶哩嗶哩在打開第一篇文章時會平移顯示下一篇文章的框架，暗示用戶可以通過左右滑動切換文章。

再比如陌陌在打開點點功能時，會在用戶進入頁面的時候播放一個動畫，暗示有很多卡片疊加在了一起，用戶可以通過滑動切換卡片。

2）教學的出現時機

a. 操作前當產品中設計了不容易感知的新手勢，在用戶操作前，通過教學讓用戶了解和學習新的手勢。

b. 錯誤操作后對于一些與用戶的心理模型和習慣不一致的手勢，提前預測用戶可能輸入的錯誤手勢，在用戶錯誤操作后進行提示，規范用戶的操作方式。

如下圖，由于知乎舊版本是通過左右滑動切換回答的，新版本調整為上下滑動后，需要糾正用戶使用習慣。因此，當用戶仍然使用左右滑動時，會出現浮層提示用戶正確的手勢進行教學。

結語

以上是日常思考和總結，有不恰當之處歡迎指出。希望本文在大家進行手勢設計的過程中能夠幫助做出合理的決策。

文章來源：人人都是產品經理 

Sandy現任阿里影業—淘票票體驗設計專家，2015年加入阿里巴巴，深耕B端行業產品，服務于電影產業鏈中的投資、宣發等角色。2017年起接觸C端用戶產品，推行價值導向和問題導向。2019年開始實踐線上線下全鏈路設計。

活動筆記：

阿里影業的服務涉及的面很廣，涉及到b端與c端全流程的體驗服務，包括面對片方的制作和宣發、發行、乃至面向用戶的售賣與放映，在每個節點都有涉及。而淘票票，經歷了四年的產品迭代，以一年一個版本的速度的進行優化。15年的理念是做一個好用的購票工具，16年新增了營銷，17年加強營銷，18年新賽道探索。到了2019年，改版應該進行新的思考：怎樣做？做什么？怎么做？做對了嗎？

此次淘票票9.0版本是根據用戶現有的習慣與市場的變化，由設計師發起的一次自下而上推進的改版。以下是淘票票9.0的設計策略與設計目標：

1. 內容設計賦能
   新服務，擴展觀影決策節點，幫助用戶發現好電影。
2. 購票流程體驗打磨
   新體驗，解讀用戶行為，體驗走查，打磨核心購票鏈路體驗。
3. 年輕化
   新用戶，關注用戶群體的變化，搜索年輕用戶群的品牌認知，提升年輕用戶滿意度。

接下來將對三點設計策略進行逐一的講解。

1. 新服務—內容的賦能

根據內容類型和場景進行劃分，結合內容特點和用戶喜好，打造全場景運營，例如提供影訊、通稿、片單、榜單、熱點、解讀、文章和活動等等多元化內容。通過提供不同的內容展現給用戶，將內容進行解構、把觸達的場景進行細化、優化設計的表達，從而達到幫助用戶可以更好的理解電影的目的。

2. 新體驗—打磨購票流程的體驗設計

設計前，首先應當熟知兩種設計思維導向：

• A.當設計目標是幫助企業完成商業目標時，是以價值為導向。
• B.當設計目標是為了提升用戶體驗，則是以思維為導向、問題為導向。

而這次9.0淘票票改版采用的是以問題為導向，期間經歷了五個流程：

2.1 找問題

首先出去找問題，找問題的方法有很多，如：用戶研究、定性、定量、業務數據和體驗走查，收集業務、用戶、客滿不同視角的疑似問題。

• 會通過支付寶、淘寶、百度糯米來比較價格高低，對比價格需要反復推出
• 進入不同的影院和場次，不太方便
• 希望看過的電影能夠產生一些紀念價值
• 不清楚80元和40元的座位有什么區別
• 不明確片尾是否有彩蛋
• 購票平臺的評分對自己沒有參考價值
• 電影院的地址、停車場是否免費等信息不夠準確
• 買完票到取票之間，需要反復確認訂單信息、分享訂單信息，但是訂單入口
• 藏得有些深
• …

2.2 看現象

找完問題之后，基于數據的支撐，去看用戶有哪些習慣的變化，看到目前的現象后再進行數據解讀。

• 影院頁和選座頁返回率高
• 越來越多的用戶購買當日的電影票
• 多數用戶選擇更短的買票路徑
• 大多數用戶去過的電影院在3家以內
• …

2.3 定位問題

基于使用場景和使用效率，進一步定位問題所在。

2.4 分析原因

分析出癥結，以便推進最終的解題環節。

• 癥結1：平臺服務與用戶決策心理脫節
  現有的流程是線狀的：選影片-選影院-選場次-選座-下單。但是用戶實際的心理決策是網狀的，用戶可能在選時間的時候考慮影評好不好，會在選場次的時候考慮價格是不是合理的。
  
• 癥結2：認知過載
  理想狀態是在傳達信息后，在用戶感知、接收和決策后，希望得到用戶方的正反饋，但是現實往往是用戶認為認知負擔過重，反饋失效的情況。其中信息傳達、顏色的設置最直觀的感受是“亂”。決策流程上最直觀的感受是“打擾”，提醒用戶是否確定要買某時候的票、提醒用戶確定退出選座頁不保留剛才選的座位，所有的提示的設計，都是采用一種打擾的方式進行詢問的。
  

2.5 解題

解題1：場景化探索。

以解決問題為目標，達到優化用戶體驗的目的，對場景進行預判、探索，把場景分為三個典型的場景：

• 典型場景1：短時決策–例如距離開場時間較短，對價格不敏感，希望找到距離合適的影院，快速完成購票決定。
• 典型場景2：追求體驗–對影廳的要求較高，希望找到放映效果最好的影廳。
• 典型場景3：價格敏感–找到符合自己價格預期的影院。

解決：針對第一種場景，選坐頁可以快速找到選場次的功能，淘票票提供常去影院、附近影院的選擇，減少用戶決策時間。針對第二種場景，部分觀影者不知道價格更高的IMAX廳、杜比廳的觀影效果，價格比普通廳貴了50塊錢，那么這個錢值在哪？淘票票使用視覺映射和科普的手段，例如當點擊進入杜比廳后，下拉可以呼出信息，了解相關的影廳，給予科普；而且界面設計不同，更貴的影廳視覺效果好，界面上也提供用戶更強的視覺沖擊。

解題2：用戶視角信息重構，進行信息降噪，減少認知負擔

認知負擔=信息呈現類型x信息量

以上公式可以看出，假設設認知負擔為定值，當信息量增多的時候，需要減少信息呈現類型，適當進行信息降噪與信息結構化。降噪是把想要突出的信息更加突出；信息結構化是把同類型的信息以結構化的呈現出來，讓用戶自然對信息產生親密性。

對于信息傳達，改變之前比較打擾的提示彈窗，現在淘票票會把所有信息都放在頁面中，用一種更輕量的方式提示用戶，不再打擾用戶。信息重構則是把需要用戶確認的信息放在最頭部，例如退票、改票，其次界面羅列的是優惠信息，最后才是影城卡營銷和賣小食的信息區域。新舊改版對比圖很好呈現出淘票票有效減少認知負擔所做的優化。

3. 新用戶—提升年輕用戶群對品牌認知

基于調研，淘票票的用戶群體趨近年輕化。改版中所制作情緒版、圖標、元素、字號、空間結構等視覺語言，注重和品牌元素的結合，產生出新的視覺語言與品牌形象，從而更加貼近年輕人的心理與喜好。

4. 體驗度量

根據heart模型進行設置，選出適合9.0版本的衡量維度：S，T，A。以體驗目標出發，符合業務目標進行探索。不一樣的體驗目標使用不一樣的度量方法。對于內容而言，需要衡量的是用戶的接受度，用戶需要看到它，接受它，并且需要知道用戶是否覺得有用。而對于核心購票流程，該流程則是比較偏向工具，度量方式則是任務完成度、完成任務時所花費的時長、信息有沒有被有效的傳達給用戶等來衡量的。最后對于視覺方向，用戶的想法會比較主觀，通過滿意度和推薦度來衡量。

現場問答：

提問者1：觀影者通常會在朋友圈、豆瓣和推薦來決定要看的影片，基本不會在淘票票上尋找值得看的影片，為什么淘票票會做這方面的探索？為什么要做內容決策這件事？

回答：從想看電影到下單的過程哪個地方淘票票是沒有做好的、做到的，根據定性調研，發現一半以上用戶都不會在淘票票上進行決策。但是淘票票還是希望嘗試一下，希望用戶可以在淘票票上完成完整的購票觀影體驗。從數據顯示，用戶心智還是不好但是有一些提升。而且豆瓣經歷了10年從pc到app，保留了用戶的歷史等數據，沒有辦法讓用戶直接轉到淘票票進行觀影決策，這也不是淘票票希望看到的。淘票票也希望可以和競品和合作方去提升觀影決策，達到共贏的目的。

提問者2：淘票票改版之后，有一個衡量它的改版效果S、T、A的度，有沒有考慮要做NPS？

回答：淘票票一直有在做，從這次改版之后來，淘票票所有用戶群指標提升了應該有五個百分點，然后年輕用戶的百分點在八個以上。NPS是一個非常關鍵的衡量用戶滿意度的指標。

追問：NPS是不是適合淘票票這個產品？還是適合于所以互聯網產品？

回答：NPS在集團內它的重視度是很高，基本上阿里系所有的產品都會有指標。

提問者3：我之前是淘票票的用戶，曾經用過淘票票做觀影決策，看下面的電影評價，結果發現電影評價是虛高的，就是說其實電影沒有那么好，但是評論會傾向性的選擇一個好的評論放在下面，經過這次經驗之后，就再也不用淘票票作為觀影決策了。想了解現在淘票票的評論機制，它是怎么個呈現的方式？是不是會優先選擇就是比較好的評論放在首評？或者是有一些什么樣的計算方式？另一方面對于現在的評論失真的這種情況，有沒有想到一些改進的措施？是最近有沒有做過一些改版之類的，就是關于這種內容方面的？除了剛才講的那些界面，視覺方面的，想了解內容方面有沒有一些提升？

回答：第一點，用戶群的不同。對于影評這個來決策，淘票票可能跟豆瓣用戶群有非常大的差異，豆瓣是影迷聚集地，愛電影這幫人的一個粉絲聚集地，圈子比較小，想要進入這個圈子有一定的成本。但是像淘票票它服務的是大眾場景，服務的有外賣小哥，也有大城市去打工的用戶，也有三四線在國企里那種的員工，淘票票服務的用戶是大眾的，所以對于評分虛高這件事，不是說它好或者不好，也就是不能單純的絕對說好還是不好，可能大眾的心智就是這樣的。用戶不像一個資深影迷，看到速度與激情會認為是大爛片，可能反而覺得好，非常值得去看。第二點，關于這種影評的一個分發策略涉及到產品策略，不是很方便講。但是淘票票在這方面一直有優化的，并且現在也是在持續優化，希望影評可以真正為用戶去提供這個觀影決策。第三點，淘票票的用戶其實不只是c端用戶，它還有還有影院還有片方，但是水軍應該不會有，至少淘票票平臺是非常不鼓勵這種情況，而且會有一定的反作弊、返水的機制。

提問者4：因為是以設計推動的一次改版，想了解一下推動的過程？第一就是因為平時改版都是產品的來做的，那這一次由設計來去推動的話，那設計跟產品之間的這個協作關系是什么樣的？然后改版歷時半年，是淘票票的設計歷程中是常態嗎？如果不是的話，平常的這個改版的節奏是什么樣的？

回答：第一點，設計要不斷的去跟產品、運營溝通，去跟不同角色溝通，溝通可能是最重要的一點。當所有人都達成共識了，確實有這樣的問題需要改，那全部門所有人就會去團結，去把這個事情搞出來。搞出來之后再去向上一層一層的去向上匯報。匯報的可能要經過很多輪，不斷有反饋的意見下來，因為本身視角輸入的也不夠全，接受到的聲音也沒有上游接觸的多，所以團隊會去接受意見，然后重新的進行。一輪review下來大概三四個月的時間，然后再去跟開發團隊溝通為什么要去升級設計語言，怎么樣去幫開發提效？怎么在下一次10.0改版的時候更容易。第二點，團隊第一次歷時半年進行改版，之前沒有停下腳步來去深耕用戶體驗，所以有一些坑或者一些彎路。平常的改版中基本上是兩周發一個版本，非常小步快跑的。對于設計如何跟產品團隊去協作？剛剛也有講過，達成共識之后，然后把這個事兒做起來，提需求、進版本，從需求池里評估需求優先級進版本。交互設計跟產品經理這個角色沒有絕對的一個邊界，可能都是去不斷的去觸碰，只要去配合合作的好，把這個產品去做出來，不用管處在一個什么樣的一個崗位。

提問者5：最開始的時候有問到淘票票和貓眼之間的一些對比，想了解在改版完之后和平時的工作中，是怎么會去了解和競品？怎么去比較？有沒有一些關注的量化的一些指標？

回答：不管服務于什么樣的產品，都會做競品調研。會關注市場的變化、競品的變化。對于設計團隊來說，其實主要的是關注的是用戶行為、功能和視覺界面。包括上了哪些個新的功能？在不同的渠道是怎么樣去運作的？運營思維是什么樣子的？淘票票團隊有在研究競品，有在做競品的一個分析，衡量的指標也主要是滿意度、推薦度，因為沒有辦法去看競品的數據，只能通過用戶反饋去看競品跟淘票票的差距。

 文章來源:uxren

有些產品經理會陷入這種誤區——需求評審做完了，自己就可以放羊不管了。而本文則認為需求評審完，產品經理還要做這六件事。

需求評審完，產品經理還要干的6件事

1. 確認需求評審的遺留問題并同步各方

2. 制定詳細&責任到人的項目計劃

3. 完成文案設計

4. 按照項目計劃，協同各方，往前推進，關鍵環節必須與各方確認。關鍵環節包括：

• 1）交互評審
• 2）視覺評審
• 3）推進聯調進度
• 4）推進測試進度
• 5）項目showcase
• 6）項目發布

5. 準備項目review

6. 開始下個需求的方案設計和需求文檔準備

這六件事具體怎么做？

產品經理A：需求終于評審完了。有種放飛的感覺，可以休假，去浪了！

產品經理B：你說真的嗎？為什么我評審完，還一直在被開發、測試、法務、財務窮追不舍？

產品經理C：你說真的嗎？為什么我評審完，從來都是我在窮追不舍開發、測試、法務、財務？

產品經理D：你們開玩笑的吧？就我這么慘！我不但要緊追不舍開發、法務、測試、法務、財務，還要被老板、被客戶窮追不舍。

產品經理A、B、C：哥們，來講講，最喜歡聽慘兮兮的故事了。你的傷痛最能撫平我的內心。

產品經理D：好吧。需求評審只講清楚了產品的骨架、細節，讓各方開始投資源。評審完，產品經理還有一堆事要推進，沒法放羊。

要跟的事情主要有下面6件：

1. 確認需求評審的遺留問題并同步各方

需求評審總有一些遺留問題要進一步確認，而后同步給各方。我不是圣人，有時候有些問題或者細節沒想到，評審的時候，大家提出來了，得趕快明確。

有時候需求評審中還有很大的bug沒想到，必須快速解決，要在開發沒動工前，都捋順。要不然變成需求變更，或者上線后被推倒重來，欲哭無淚。

我這種求生欲這么強，也沒人罩著的，必須狠命把需求做到95分以上。100分也不太敢說，畢竟眾口難調。

2. 制定詳細&責任到人的項目計劃

產品經理還得身兼項目管理，項目管理從來都是事有輕重、事無巨細，難以假手他人。雖然我會盡可能調動大家的積極性，讓大家自驅管理項目，但還得牽扯不少精力。

項目管理的關鍵點：明確項目計劃、關鍵節點、每個關鍵節點的負責人、驗收方案。

比如什么時候交互評審、視覺評審、聯調、showcase、發布？分別是誰主要牽頭負責，哪些人需要參與。

為了防止項目延期，每個節點都還得提前趕。真是操碎了心。

3. 完成文案設計

文案從來不是隨便寫寫。文案是和客戶交流的重要途徑，整幾個客戶看不懂的文案上去，后面客戶咨詢搞死人！

文案設計除了客戶視角之外，也不是自己想怎么寫就怎么寫，還要和法務、客服團隊溝通。因為文案被客戶投訴的案例，又不是沒有。

還有啊，我的產品有3種語言，簡體中文、繁體中文、英文，雖然每種語言有專門的文案設計師，但得跟他們說清楚，也要花不少時間、精力。

當然，也有很多產品經理，不管文案這種小事?？晌矣X得文案體現了產品經理最基本的素養，是產品的底子。

4. 按照項目計劃，協同各方，往前推進，關鍵環節必須確認

關鍵環節有6個：

1）交互評審

一般來說會由交互設計師發起，開發、測試、法務、財務都要參與。

這樣能保證大家在說同一件事情，避免我要的是頭牛，結果開發給了頭驢。

如果設計師項目參與度低，交互評審還得我自己上。哪里缺人，我就得到哪補坑。

2）視覺評審

一般來說，交互和視覺評審會一起。

有時候項目很復雜，或者交互、視覺分工明確，那就得分開了。

通常由視覺設計師發起。同樣，如果視覺設計師參與度低的話，我還是得補坑。

3）推進聯調進度

聯調是很容易扯皮的環節，大家來自不同域、不同職能團隊，各有各的小九九，所以得盯著，避免聯調成為坑王。

4）推進測試進度

進入到測試就意味著開發的七七八八了，當然有時候為了壓縮項目周期，開發、測試會階段性并行。

除了測試進度，還得關注測試發現的問題，可能開發還得返工，也可能會發現需求評審中大家都沒有注意到的問題，得及時補救。

5）showcase

Showcase，說白了就是項目驗收。

驗收前，得先列出來要驗收哪些內容，主流程、分支流程、逆向流程、重大關鍵節點。Showcase，也有可能發現新的問題，但基本上要避免在showcase環節發現重大問題，不然就得重大需求變更了。

showcase有時候由測試主導，有時候沒資源，我得自己上。

6）項目發布

如果一路順利，就該發布項目了。

項目發布計劃雖然也是之前就定好的，但要考慮的方方面面也還挺多的，可以看之前的文章《項目發布要考慮的因素》。

總而言之，要和各方溝通好，要保證項目順利發布呦。

5. 準備項目review

項目終于上線了，可我得天天得看客戶反饋，看數據，跟客戶聊，跟業務聊，準備復盤review。

產品狗似乎永遠都在準備復盤、復盤中、復盤后反思的路上。

6. 開始下個需求的方案設計和需求文檔

項目通常是并行的。在需求評審完后，我已經開始下一個需求的研究、設計了。

開發資源從上一個需求釋放出來的時候，產品經理肯定得把下一個需求方案設計好，開始新的需求評審，妥妥的做好資源銜接。資源一旦釋放出來，下次想要資源，難上加難啊。

產品也需要持續迭代，讓客戶感受到，我們的產品在成長、進步，給人希望。

文章來源：人人都是產品經理

區分取消與關閉，可以很大程度上避免丟失用戶已操作的內容。在關閉視圖之前保存用戶的更改，使用文本標簽而不是「X」圖標，并在破壞性操作之前提供確認對話框。

讓人迷惑的「X」圖標

很久以前，「X」這個符號是用在地圖上，標記「寶藏的藏身地」。但在今天的數字化界面中，「X」符號不再用來標記位置，而是被用來取消進程，或者關閉某個臨時頁面/彈框。但是如何確定「X」代表的是「取消」 還是「關閉」？有的時候可以確定，有時卻模糊不清難以界定。

其實，主要的問題在于「X」圖標缺少了文本標簽。當同一個圖標在不同的界面，卻代表不同的含義，該圖標的可用性就會受到影響，因為用戶判斷不了到底是什么含義。

為什么要區分「取消」與「關閉」

當用戶單擊/點擊「X」按鈕來關閉模態彈框或視圖時，系統會完全取消該過程并清空之前所有操作，這讓人沮喪，甚至抓狂。因為用戶通常認為「X」圖標表示取消或者關閉，所以區分這兩種可能性對于交互的成功至關重要。

在某些情況下，區分取消 or 關閉并不重要。當一個彈窗占據你的大部分屏幕時，點擊「X」按鈕（盡可能快地），既可以關閉該模態，也可以取消它可能觸發的任何進程。

但是，如果頁面中包含正在運行的計時器，正在播放的音頻，正在選擇多個選項標簽，或其他類型未保存的內容，那就很有必要說明「X」圖標所代表的意義。因為用戶可能打算讓計時器或音頻繼續運行，或者希望立刻應用這些選好的選項標簽，或保存正在進行的工作，同時希望關閉該視圖繼續其他操作。

例如：絲芙蘭在結賬過程中，使用模態窗口來展示用戶可以添加到購物車的免費商品。在以下示例中，單擊「 ADD（添加）」按鈕選擇商品后， 該按鈕直接被變成了「 Remove（移除）」，看起來似乎商品已經被添加到購物車中了。但是，實際上當用戶單擊右上角的「X」圖標后，該商品并不在購物車中。他需要再重復這個步驟，最后點擊「Done（完成）」按鈕，商品才會被加入購物車。

Sephora：單擊右上角的「X」會取消選擇這些試用商品整個過程。用戶必須先單擊「ADD」，再單擊「Done」才能將商品添加到購物車。

如何避免丟失用戶正在操作的內容

要避免丟失用戶正在操作的內容，首先需要確定用戶的意圖，是取消還是關閉，并提供明確的選項。有以下幾種方法：

• 主動要求用戶確認他們的意圖；
• 使用明確的文本標簽而不是模糊圖標；
• 顯示兩個不同的按鈕：「X」圖標表示關閉視圖（可以自動保存頁面內容/操作），而「取消」則代表放棄該過程。

1. 要求確認

如果用戶在已經執行操作的模態彈框或頁面視圖中，點擊「X」圖標，app 則可以在關閉視圖之前，直接詢問用戶是否應用該操作，來確認其意圖。此解決方案非常適合會破壞用戶工作的破壞性取消操作。例如，過濾器視圖可能會被意外關閉，并且關閉會導致用戶丟失其選定的選項。

這個問題在移動端界面上很常見，因為過濾器視圖占用了很大的屏幕空間，這使用戶很難或不能判斷是否已經應用了那些選擇。為了防止這種潛在的錯誤，在關閉過濾器視圖之前，跟用戶確認是否要應用這些選擇并關閉視圖，抑或是清除這些選擇。例如：下圖中，當用戶選擇后，點擊「X」圖標時，Lowes 會出現如下確認彈框。

左 ：點擊「X」圖標或返回箭頭，所有的選項都會被取消，并將用戶帶回上一個頁面。右：點擊「X」后，出現一個確認對話框，確認用戶是應用還是取消篩選，然后再返回結果列表頁。

同樣，當用戶關閉正在進行的課程時，語言學習應用Duolingo 會顯示一個確認對話框，課程進行中不能中途離開，除非確認「退出」。至少，該 APP 向用戶傳達了這一限制，同時他們也可以選擇「取消」來繼續課程。點擊「X」按鈕將結束當前課程。為了防止出錯，結束前會出現一個確認對話框。

缺點：

• 雖然確認對話框在避免「X」圖標有歧義方面很有效，但它卻添加了額外的步驟；
• 用戶在按下「X」圖標之前還是不知道它到底做了什么，代表什么意思，因此他們可能會對這個操作感到疑惑。

2. 使用文本標簽

不要完全依賴對話框來讓用戶確認模糊的「X」圖標，而是使用明確的文本標簽。文本可以消除歧義，并清楚地傳達將發生的操作：取消與關閉。

Yelp 的篩選頁面在屏幕頂部提供了標有「Cancel（取消）」和「Reset（重制）」的按鈕，在底部提供了一個大大的「Apply（應用）」按鈕。類似地，Etsy 中的 Filters 視圖提供了「Clear（清除）」和「Done（完成）」兩個按鈕。

注意：Etsy 使用「Done」而不是「Apply」，因為過濾器一經選擇就可以被應用，而這里是關于開關切換與否的建議。

（左）Yelp：Cancel、Reset 和 Apply 這三個文本標簽既直接又清晰，這樣用戶就不太可能不小心關閉視圖而丟失他們過濾器中的選擇。（右）Etsy：Clear 為用戶取消提供了一種清晰的方式，而點擊 Done 則返回到「產品列表」頁，其中的選擇已經應用。

3. 關閉并保存

如果必須使用「X」圖標而不是文本標簽（比如為了以節省空間，或者正在遵循團隊的設計語言），請謹慎使用，并在用戶完成前保存操作/內容。另外，可以提供一個單獨的「取消」按鈕，讓用戶在進程之外有一個緊急出口，并消除「X」在兩種含義之間的歧義。

例如：Gmail 會自動保存在非模態窗口中填寫的郵件信息到草稿（Drafts）。這樣的好處是，用戶在需要折疊或關閉該窗口時，仍然保存原來的內容以便于下次繼續編輯。將鼠標懸停在消息窗口右上角的「X」圖標上時，會顯示一段提示：Save & Close（保存到草稿并關閉）。此外，點擊窗口右下角的「垃圾桶」圖標可以刪除該郵件，這個圖標離頂部的「保存和關閉」選項很遠，可以防止用戶誤點。

Gmail：Hover 透露，「X」圖標是用于關閉窗口而不是刪除草稿，它允許用戶保存并關閉消息窗口而不會丟失剛剛正在編輯的郵件。

對于長進程或傾向于在后臺運行的進程（如計時器），默認自動保存也是一種很好的解決方案。

例如，Glow Baby 中，后臺運行喂食或睡眠計時器時，用戶還可以瀏覽 APP 的其他區域。因為這些計時器一般會運行很長一段時間。此功能還能讓用戶在 APP 中做其他的任務操作，例如記錄之前換尿布的時間、瀏覽文章、逛論壇等。點擊計時器視圖中的「X」圖標也只是關閉窗口并不會取消正在運行的計時器。

Glow Baby：（左）點擊運行計時器視圖中的「X」圖標，在不停止計時器的情況下取消視圖，從而允許用戶繼續使用 APP 記錄其他類型的事件、參與社區討論、閱讀文章等。（中）運行計時器的狀態顯示在屏幕頂部的狀態欄中。（右）在計時器暫停時點擊「X」圖標，彈出「放棄」或「取消」按鈕以確認用戶的真正意圖。

請注意：在關閉前保存中間工作或維護正在進行的過程是主動的，但有時可能會與用戶的意圖相反。如果用戶打算通過單擊「X」按鈕取消其選擇，那自動應用這些選擇可能會令人困惑和沮喪。

這就是為什么還必須有一個單獨的「取消」按鈕，給用戶一個出口，而不是強迫他們必須關閉時自動保存。

結論

雖然「X」圖標會造成模棱兩可，而且經常導致可用性問題，但它不太可能馬上從所有接口中消失。設計人員應該注意「X」圖標的多重含義，消除「關閉」和「取消」之間的歧義，并提供確認對話框或自動保存等保護性措施，避免丟失任何用戶正在操作的內容。

若存在疑問，請記住：先保存，再退出。

小思考

為什么手機驗證碼登錄微信/淘寶時，驗證碼輸入錯誤，二者都是用的模態對話框提示用戶，而不是用 Toast 呢？

• 微信和淘寶的用戶群體都很龐大，幾乎橫跨所有年齡層。Toast 出現又自動消失的交互體驗，用戶會感到不可控，尤其是對大齡、老齡的用戶不夠友好。
• 也有悖于 iOS 人機交互指南中提到的「用戶控制」這一原則，我想這也是 iOS 設計語言沒有 Toast 這種控件的原因之一吧。
• 而模態對話框雖然干擾性較強，但用戶可以隨時控制，在使用過程中是用戶掌握主導權。

補充：Toast 這一控件，原是 Android 系統的控件。但自 Android 5.0 推出原質化設計后，Toast 就被弱化，而是將 Snackbar 作為官方推薦的控件。如今在 Material Design 中更是找不到 Toast 的蹤影。主要原因還是 Snackbar 在交互友好性方面比 Toast 要好，例如：支持手勢交互、支持與 CoordinatorLayout 聯動等。

因為現在大多數的PM/交互/UI設計師，在設計產品的時候都是以iOS為基準 思考產品上的各種功能邏輯、交互狀態，而很容易忽略了某些功能在Android里并不能“一稿適應兩端”，部分產品差異在安卓上是不一樣的。

所以本文就講下Android和iOS 10大產品/交互差異，希望你在日后的產品設計時，可以考慮到更多層面的知識點（可能在某些安卓高級機型里并不通用）.

01 虛擬商品 支付規則和方式的不同

1. 支付規則

對在于一些虛擬商品的支付上，如vip會員、xx幣，xx豆。iOS和Android就存在不同的支付規則：Android基本無限制，無抽成。而iOS限制比較多，而且要抽成大約30%的手續費。

舉個例子：同樣充值30元，Android端會得到300金幣，而在iOS中，只有210金幣。正因這個抽成規則的不同（沒辦法，這是蘋果硬性規定的），才會出現各種平臺的虛擬貨幣，在Android和iOS中的充值比例是不一樣的，如快手：

所以對于虛擬商品在iOS端的抽成規則，在產品設計時一定得考慮清楚，因為這關系產品的商業和盈利模式。通常有2種解決思路：

A. 讓用戶承擔30%的抽成

a. 同樣的價格，iOS用戶得到的商品少些

如同樣充值30元，Android端會得到300金幣，而在iOS中，只有210金幣。像快抖音、陌陌等各種貨幣充值。

b. 同樣的商品，iOS用戶支付更高的費用

如3個月的vip會員，Android端定價是58元，iOS端則可以設為68元。如優酷、騰訊視頻的vip會員價格。

B. 公司自己承擔30%的抽成

如iOS端充值30元，公司實收21元，但iOS用戶能得到和Android一樣的300個金幣（理論上是有這個解決思路，但現實中很少有公司去實現，畢竟抽成成本就擺在那里）.

另外還需要注意的是：因為抽成規則的不同，對于同一個ID的賬戶余額，在Android和iOS端中是不能通用的。因此在產品設計時需要將這個點告知用戶，預防用戶犯錯、以及惡意刷幣。

2. 支付方式

Android由于開源的特性，因此對接的都是第三方支付平臺，如微信支付、支付寶、銀聯卡等。

而iOS出于系統的封閉性和安全性考慮，只能調用蘋果自己的支付系統：登錄APPle ID，然后用授權的支付方式（支付寶、銀聯卡）進行付款。

02 狀態欄交互的不同

“狀態欄”也就是我們手機界面最頂部的電池欄，它除了可以在不同背景里切換顏色外，在交互的觸發上，Android和iOS中也各不相同。

• iOS：用戶在Y軸滾動了很長內容時，點擊狀態欄可以快速回到初始位置。
• Android：無論用戶滾動了多長內容，都是點擊無任何效果。

雖然這一交互差異是iOS專有的，但它卻啟發我們一個新的設計思路：在必要的時候，狀態欄可以為產品承載新的交互狀態。如網易的LOFTER（iOS端），用戶離開音樂播放界面時，狀態欄就用于顯示音樂信息和操作入口，方便用戶在瀏覽其他內容時可以快速關閉音樂時，極大提升了用戶的操作效率。

03 下載方式和狀態的不同

這種大多應用于運營的“拉新”場景，為了能新用戶得到好處（紅包、優惠券、更好看的內容等）。通常會讓新用戶下載產品APP領取。而由于Android與iOS的下載方式不同，會帶來不同的交互狀態和產品邏輯。

Android

可以在當前頁面（后臺）下載，也可以在應用商店下載；過程中可以顯示進度，且允許用戶暫停下載；下載完成后調起安裝頁面，用戶可以取消安裝，也可以自動安裝…

正因為Android下載軟件的各種便捷性，所以才會帶來各種交互狀態：未下載、下載中、暫停中、已下載但未安裝、已安裝。這些都是交互設計師需要特別注意的，每個不同的狀態背后都會不同的產品邏輯。

iOS

只能跳轉到App Store里下載，所有下載流程和狀態都是在那完成的，可以脫離開活動頁面，相比于Android的下載方式就簡單很多。跳轉的方式可以是全屏幕，也可以是半屏。

04 軟件更新方式的不同

Android

由于安卓的開源特性，當有新版本時都會提示用戶更新，且每個產品內部都帶有“版本更新”入口。而更新的方式可分2種：

1. 引導更新：彈出提示讓用戶更新APP，用戶點擊“更新”按鈕前往應用商店更新、或者在當前頁面更新并顯示下載進度。
2. 強制更新：也是先提示用戶更新，只不過用戶點擊“更新”按鈕，即調起軟件安裝頁面。（前提是產品已在用戶處于wifi模式下，將安裝包已下載完成）

iOS

而iOS端出于對用戶體驗的考慮，是禁止向用戶提示版本更新信息的。這也是為什么絕大部分的iOS產品，都是沒有“版本更新”入口的原因（像QQ、支付寶、百度網盤等大廠產品）。即使有，點擊了也直接跳轉到App Store查看版本情況。

且下載渠道都固定在App Store里。理所應當的，軟件的更新方式也只能在App Store里進行，無法做到與Android的一樣做到后臺下載、后臺更新。

05 文字發送指令 位置的不同

在手機鍵盤里輸入文字時，iOS由于系統的限制，對文字的發送指令只能在鍵盤上來完成，因此iOS用戶的交互操作都全部集中在鍵盤右下角。

而Android端就靈活很多，不僅可以在鍵盤上執行發送指令，也可以在輸入欄/搜索欄周邊新增操作入口。

06 退出浮層列表的不同

長按一張圖片后，都會彈出一個列表浮層，因為iOS手機只有一個“Home鍵”而已，為方便用戶退出浮層才增加了“取消”入口。

而Android手機本來就有“返回”虛擬鍵，安卓用戶的退出/返回行為都習慣于通過虛擬鍵觸發，所以多做一個“取消”的意義性不大。

07 刪除方式的不同

iOS端一直教育著用戶使用“左滑”刪除列表信息，所有的刪除功能都是支持“左滑”來實現的。

而Android系統大部分只能通過“長按”來觸發編輯狀態，其中就包括了刪除功能。不過現在也有極少數的產品，正在逐漸打破這兩端間的“刪減”界限，比如網易郵箱（Android）就做到了左滑刪除信息。

08 消息推送機制的不同

當我們第一次打開產品、允許了獲取消息通知的權限后，所有的信息傳輸都會基于服務器進行推送。而兩端在這塊的推送機制又有所不同：

iOS

所有新信息都會實時推送到你的手機里，即使你關閉了軟件，還是一樣會收到提示。就算使你處于斷網狀態，信息也會先儲存于蘋果服務器，等你聯網時再一次性把收到的信息推送給你。既釋放手機內存，又不會讓用戶遺漏有新消息。

Android

而安卓則不同，你若退出了產品，數據的推送只有等你再次打開產品時，才會通知你有多少新信息。雖然減少了對用戶的干擾性，但也增加了服務器數據儲存的壓力，還容易耽誤用戶接收新消息。

09 復制文字后，剪切板狀態的不同

也就是我們手機的輸入法鍵盤，在微信聊天內、手機短信里復制了一段內容后，由于Android與iOS的平臺特性差異，會給兩端用戶帶來了不同的交互差異。

iOS

復制完文字后，打開輸入法鍵盤會顯示來自剪切板的文字內容。用戶只需點擊，即可將文字復制在搜索欄、輸入欄等需要文字填寫的操作區域里，無需觸發“粘貼”操作。

Android

而有些安卓機（如小米/錘子/樂視等)，無論你復制了什么信息（文字、數字、網址等），都很難實現輸入法里的“剪切板”功能。用戶需要觸發“粘貼”功能，才能輸入將剛剛的復制內容。

而對于特定的信息類型：如網址。用戶復制網址往往都帶有極強的目標性、搜索性，一些瀏覽器產品會預判用戶這一操作行為，將復制的網址前置展示出來，以抵消Android端對于復制文字帶來的系統限制。如QQ瀏覽器（安卓端）就有2種解法方法：

• 方法1：利用安卓系統的消息權限，在手機界面的頂部彈出網址欄提示，無論是在微信還是短信中，復制網址后都能快速地觸達目標。
• 方法2：復制網址后打開搜索功能，會將網址自動定位并粘貼到搜索欄中，便于用戶查詢。

而UC和百度也有類似的解決辦法：將復制后的廣泛信息（文字/數字/網址/郵箱地址等等）嵌入在搜索框下方，用戶點擊就能搜索。

這也是一種妥當的解決方法，因為用戶可復制的信息類型特別廣泛、目標不是很清晰。無法準確判斷出用戶一定會有搜索訴求。所以才將復制后的信息放在搜索框下面，而不是自動粘貼到搜索框中，既考慮了用戶目標，又兼顧了操作效率。

總結

以上就是Android與iOS的差異總結，若有描述得不當請多指教！下面是總結文件。

文章來源：人人都是產品經理