在移動端，用戶要判斷壹個控件的交互方式，除了控件本身的UI設計帶來的提示，實際點擊控件後才能真正確定。這很像量子物理理論中的“薛定諤的貓”，即在妳實際點擊控制之前，妳永遠無法預測按鈕真正支持的操作模式。
此外，由於移動終端上的所有交互都是基於觸摸的，這種交互行為與PC終端上有很大的不同。PC端除了拖動窗口滾動條來實現界面的滾動效果，基本都是用鼠標指針懸停在目標控件上，通過滾輪或者輕劃來實現滾動效果。所以在PC端的滾動交互中，鼠標指針和UI控件之間並沒有什麽有意義的接觸(如果我們把懸停視為非接觸的話)。
但是由於屏幕物理尺寸的限制，滾動操作和點擊操作成為了移動終端最重要的兩種交互方式。在滾動操作中，手指必須先接觸屏幕表面，然後快速滑動壹定距離並擡起，才能達到滾動效果。因此，在手指按下屏幕的瞬間，位於手指接觸屏幕的點的UI控件極有可能被激活到“活動”狀態，但系統判斷操作行為是“滾動”而不是“點擊”後，對活動的目標控件執行ontouchcancel，即雖然目標控件被激活，但不執行後續的運行結果。
在移動端，如果新內容與用戶點擊控件後反饋和點擊行為發生的時間存在“差距”，用戶可能會對控件是否已收到感到困惑。如果間隙時間長，會直接影響用戶體驗。納爾遜定律中的狀態可見性原則是為了防止這種情況:
控件在被移動終端點擊的瞬間所能提供的效果反饋的定義非常不壹致。
壹些應用程序和壹些模塊提供了類似於PC的活動效果。
Android的材質設計脫離了PC端UI控制交互的束縛，利用觸摸後強烈的反饋效果來表示用戶點擊產生的即時反饋不失為壹個好主意。？
這些差異給移動控件的設計帶來了新的要求:
例如，對於支持移動性的控件，除了在設計中加入“移動性”的隱喻外，可移動的圖標應該是標準的。
如果內容不可點擊，不要將其設計成列表項樣式。在之前的文章中，我曾經在工作中舉過壹個例子。產品經理想把壹組只讀信息做成列表項樣式，這樣的設計必然會迷惑用戶，帶來非常大的用戶體驗問題。
如果平面圖不可點擊，就不要設計成可點擊的。之前在實際項目中，遇到過聚合頁面。樓層圖的設計風格明顯引導用戶點擊樓層頭圖進入詳情頁。雖然沒有添加“更多”按鈕，但是這樣的設計會造成很多體驗問題。
對於從未接觸過移動設備和交互模式的用戶來說，如果要編輯壹個控件，無論是向左滑動進入編輯狀態還是長按進入編輯狀態，都需要壹定的學習成本和過程。但是壹旦用戶掌握了這種交互模式，他們就會在使用時形成壹個關於如何操作這種控件的心智模型。
壹般來說，用戶並不太關註iOS平臺和Android平臺的區別，所以無論是什麽類型的設備，用戶都傾向於使用同壹套思路來解決類似的問題。所以在條件允許的情況下，盡量在可控範圍內實現控制交互方式和交互反饋的統壹，才是對用戶體驗的最大支持。
如果不可控因素太多，盡量按照以下優先級統壹交互反饋:
統壹跨平臺交互反饋>系統內統壹交互反饋>:應用內交互行為統壹>:板內交互行為統壹
移動終端的交互方式是觸摸手勢交互，因此與鼠標操作的PC終端相比，移動終端與現實世界的交互方式更加緊密和壹致。早期準物化風格的UI界面上，相冊、日歷、筆記本、按鈕、開關、拖拽控件等。都是完全抄襲現實世界的物品，現實中都能找到相應的物件。正因為如此，用戶的心智模型更穩定，更符合現實。
以及壹些比較抽象的交互，比如跳，彈，回等。，用戶也形成了固定的心智模式，甚至形成了穩定的空間記憶。壹旦遇到問題，用戶會在屏幕的二維空間中的固定位置尋找相應的控件。
由於移動終端相對於PC終端缺乏鼠標懸停尋找合適交互方式的特性，移動終端用戶只有在手指實際觸摸屏幕時才能真正理解控件所支持的交互方式，因此移動終端的交互方式要求盡可能簡單、直接、可發現的交互方式，那些學習成本高、不符合用戶心智模型和心理預期的交互方式勢必成為用戶體驗的障礙。這也是為什麽除了Demo demo app等少數有特殊場景需求的應用，我們很少看到多指手勢大規模應用的原因，因為隨著控制手勢的手指數量的增加，操作復雜度呈指數級增長。
下圖所示的多指手勢操作極其復雜，不符合用戶的心智模型。用戶不僅在使用過程中學習成本高，而且以後很難記住這些手勢:
移動終端不被強制添加控件的觸摸的主動效果，但是如果壹些控件，例如跳轉到新頁面的列表項，在用戶觸摸屏幕上的控件和新頁面被刷新和加載的時間之間可能有延遲時間。如果這個延遲時間較長，可以考慮加入“主動”效果，增加體驗的流暢性，減少誤操作。