手遊UI互動動作設計研究：點選、滑動與拖拽

好的互動設計方案究竟應該是怎樣的？

互動動作的直覺形成於『人與實物』的互動中。

在物理世界：接觸物體一定有感覺。

在遊戲裡：與物體互動一定可以看到變化。

本文從互動動作入手探討移動遊戲中關於互動設計方案和理念。

一 點選


首先確認這篇文章的大前提：我們設計遊戲裡的互動動作，無論是否強調沉浸感，都並沒有在故意給使用者提高難度（QTE、射擊瞄準這一類操作難度是來源於關卡而不是互動）。那麼，如何選出不屬於hard模式的互動動作？

重要但基礎的事情說一遍就可以了——

不能反直覺。

那麼下一個問題，怎麼做才能『不反直覺』？

狸花絕不抄書，簡單直接地寫出來，使用者的直覺是哪裡來的——

互動動作的直覺形成於『人與實物』的互動中。

重要喵？基礎喵？需要三遍喵？

/*不按順序*/一個一個來，首先是點選動作，接下來是滑動……


最基礎最經典的動作，來源於觸控真實物體的本能行為。

……誒好像發現了貓玩Fruit Ninja的理論支援。


這裡暫時只寫關於觸控式螢幕的點選，PC端的滑鼠單雙擊晚點再說。

在我們真實的物理世界中，想『開啟』一個物體，首先要接觸到它，所以我們對於UI中的『按鈕』——那些看起來像是可以『開啟新頁面』的物體，第一反應也會是摸它一下。點選是個不需要教學的動作，即使是在新手引導環節，我們也只需要告訴使用者『點哪裡』，以及把按鈕做得有夠像是一個按鈕。

吹一波觸控式螢幕技術的劃時代意義，它實現了點選與物體最直接的對映。

建立了『點選按鈕=觸控物體』的認知之後，我們可以看到這會帶給使用者什麼樣的預期——

在物理世界：摸到物體一定有感覺。

在遊戲裡：點選按鈕一定可以看到變化。

於是出現了『按鈕狀態』這個概念，就是常見的Normal、Hover、Pressed、Disable四種狀態。

互動視角下，以這個規則響應點選的都是按鈕～

卡牌、道具、你們的美少女立繪都是一樣的喵！


有的版本里，取代Hover的是Highlight，但狸花認為Highlight是用於吸引使用者注意力的視覺表現，不屬於按鈕狀態。/*再說PC端也可以有Highlight，數量是不可能對齊的強迫症退散*/

這裡面Normal沒什麼歧義，Hover在觸控式螢幕不存在（如果我講到PC端會寫它的），Pressed是手指點下去的那個瞬間，通常會做色彩變化或者縮放動畫。

這個動畫存在感微妙/*世間事物大抵如此*/，它很少被注意到，但沒有就覺得哪裡都不對。

遊戲介面有時候物體比較多，就會出現一些很小的按鈕，點選瞬間完全被手指遮擋，這個有必要時可以稍微延長動畫到點選過後（手指離開按鈕）才結束，來提醒使用者『你點的是這裡！』

於是狸花想說的重點是Disable狀態，通常翻譯為不可點選/禁止——

講真我們做得到禁止使用者點選它麼？

準確地說，Disable實際表達的是『點選也不會有反應』狀態。

這個狀態的存在可以減少使用者點選按鈕卻得不到理想反應的次數。我們來喵一眼最經典的禁止狀態應用場景：


再喵一眼遊戲裡常見的一種情景：


前者是線性的，填完上一條、看向下一條、填完最後一條、看到按鈕——點它，完美。

而後者呢？

現在是幾點——去看看系統時間，有組隊嗎——看看隊伍皮膚，我多少級——看看人物的等級……使用者取得對應資訊的位置是分散的。

這就意味著如果我們在這裡放了一個禁止狀態的按鈕，使用者不會去點它，而是去一一對照排查我為什麼不能點它。

那麼不如給它一個Normal的按鈕，在被點選以後，告知使用者不符合要求的是哪一條。


小結：如果上面案例只有時間和等級兩個限制，使用者滿足了等級之後，只看按鈕狀態就能意識到是否在開放時間，灰色的按鈕+提示語當然也是可以的。不過，灰色按鈕給使用者的普遍認知是不用去點，提示語被觸發的概率也會下降。

二 滑動


滑動螢幕，對應的物理世界的行為是挪移物體。此處是指推拉平移，『拿起來搬到別的地方去』的更接近拖拽。

2.1滑動的方向

動作本身有橫豎兩種，細分就是上下左右四個方向。按照物理世界裡，推拉物體的習慣來說，如果我想看到一屏以下的內容，那就要把頁面向上滾，手指也就要向上滑動。


滑鼠和手指在使用者看來是明確地兩個物體，適用不同的心智模型，一般不會搞錯——但狸花曾經有一個支援觸控板手勢的膝上型電腦，截止它被刷系統之後手勢失效，狸花都記不住它的滾動是按照手指還是滑鼠方向來的……（鑑於不同的心智模型，如果是狸花來做，會選擇同步觸控式螢幕手指的動作習慣）

2.2滑動區域的數量

從前，有一隻策劃，想加多部分系統郵件的獎勵物品。原稿長這樣：


然後狸花認為一個彈窗（郵件頁面是一個點選外圍可以關閉的層）出現兩個滑動區域，並且一橫一豎，使用者需要識別區域並改變動作。同時，橫屏小範圍的左右滑動不太適合單手控制。郵件系統的功能性大於沉浸感，動作最好簡化——於是做了這樣：


如果頁面是全屏的，上文的改動可以不必做，因為我們通常會把整個螢幕的滑動視作不需要關注『區域』的全域性手勢，內心計數自動-1。如果是上下滾屏，內嵌左右滑動區域也足夠容易識別——而內嵌上下滑動就比較微妙。這取決於我們對於無形邊界的腦補。


此外，由於多數使用者習慣右手單手持機，並且我們的閱讀順序是左到右上到下，使用向上和向左的滑動，稍微優於向下和向右。

2.3稍微有點奇葩的分類討論——連續/斷開的動作和頁面。

連續的滑動頁面就像是在拉開的抽屜裡翻東西，或者扯捲紙（破案了，狸花真的是貓）。手指的動作當然還是有次數的，但物體的移動帶有慣性，不會立刻停止。手指滑動的速度和距離會影響物體，可以不用動很多次就飛快地滑過大段，中間的物體可能看不清楚。適合粗略地翻動列表獲取資訊，或者找足夠明顯的物體。


面對正在移動的物體，我們通常會在螢幕上按住（或者是反向短暫地滑動一下）來讓它停下來。這也是源於物理世界裡讓實物停止運動的那個反方向的力。


手機遊戲裡使用物品為什麼要多一步，而端遊不用？（原因有很多，比如手機上沒有懸停顯示物品描述的功能）……這裡狸花想說的是，需要預防的『誤觸』不只是點錯位置，也有像『用來停止滑動的點選動作』這樣動機上的。


同理，kindle 的手機APP不支援上下滾屏，和它點選有字的任意位置都會退出閱讀，會不會有聯絡？/*事實上，點選書頁退出閱讀本身就容易誤觸，使用者體驗一言難盡……*/

斷開的滑動行為對映物理世界的翻頁，是清晰的『手指動一下、頁面動一下』的動作。不會因為慣性而一下翻過多頁，手指滑動的距離也不影響物體移動的距離。動作的速度會影響物體移動的速度，不過僅限於兩頁之間。

適用於我們希望使用者看清楚每頁內容的滑動區域（比如輪播宣傳圖什麼的）。以及新頁面的進入/退出。

用於新頁面進退場時請保持方向一致……左滑開啟對應右滑關閉這樣……我們翻書頁也是向左翻過來就向右翻回去的對吧。


小結：不處於列表的頂端或者底端時，使用者沒有截然分明的『當前這個、上/下一個』的意識。如果是迴圈列表並且沒有提示，可能狸花會在很多圈之後才發現並停下動作。


三 拖拽


拖拽對應的真實動作就是拖拽，就是『把物體從這裡拿到那裡』。

多麼簡單直接的心智模型……

所以狸花有一個未解之謎……為什麼拖拽動作在遊戲互動裡至今沒有普遍使用。用來換卡牌、調整編隊、拼字拼圖……很多場景都是合適的，尤其在需要按順序的情況下，拖拽效果拔群。有人說因為完成拖拽需要的手指移動時間長過點選，相比點選更麻煩，說得也對。但是在表達『互換』行為的時候，使用拖拽比點選更貼合直覺，比如這個——


在PC端有一種做法，滑鼠點一下拿起物體，物體跟隨滑鼠移動，再點一下放下物體。這就是一個被簡化的，不需要保持按下狀態的拖拽。然而觸控式螢幕沒有懸停。


只使用點選要這樣做，涉及到的狀態變化多過拖拽，狸花不認為它更好用。

3.1拖拽的方向

拖拽不一定是上下左右移動的，我們把它分類為有終點的拖拽和向外拖拽就可以了。


有終點的拖拽可以用於表達挑選、取回，或者『多個物體合成一個』的情景，拖拽終點有重要的意義。同時，拖拽的距離和方向是被限定的。

PS：不建議這種拖拽支援雙向操作……

向外拖拽可以用於丟棄物品，經典案例即『拖拽刪除』——尤其是『拖拽到皮膚之外刪除』。這裡的拖拽終點是一個範圍，沒有明確的落點，拖拽距離會成為一個取值範圍（皮膚外到螢幕的極限），方向也不是一定的。


小結：想知道為什麼現在通用的是『長按-拖拽刪除』……拖拽到刪除區域在手機螢幕上並不容易誤觸，即使刪除屬於重要操作，二次確認也足夠反悔了？畢竟長按本身比拖拽還要不常見……

3.2拖拽的距離

一般遊戲使用者遇到需要拖拽的介面，會是一手持機一手拖拽的。也有少數豎屏遊戲裡，使用者會單手拖拽。但無論哪種都是距離越長，物體意外脫手的概率越大。


所以請儘量減短拖拽的距離/*也不要矯枉過正到幾乎相連，拖拽終點會被手指擋住的*/，尤其是不要讓起點和終點不在同一屏……拖拽滾屏的體驗可以在手機上拖動app模擬一下，手指在裝置邊緣真的很容易滑脫。

拖拽終點的實際區域最好略大於視覺效果，在物體進入終點區域後自動放到正確的位置……幼年狸花就是用這個標準來篩選可以玩的拼圖遊戲的……

最後，拖拽路徑儘量一一對應，畫出來呈現平行線段組，或者收於一點。不要在起終點的路徑上放別的終點。


綜上所述L形介面就別拖拽了！

3.3拖拽衍生物：模擬搖桿

模擬搖桿真是個偉大的發明……雖然它長得完全不像方向鍵但是意外地很好懂！……關於它的心智模型來源於手柄這一點狸花存疑，用過手柄的人數至今還少於玩手遊的吧……

我們與模擬搖桿互動的動作是一種連續的拖拽。與之前的所有拖拽相比，區別在於物體的位置和手指的位置不同步，這個對映關係可以大概描述為，拖拽的方向=物體移動的方向，拖拽的時間×物體速度=物體移動的距離。

然後狸花發現，拖拽的距離在這裡消失了。沒有用上。

通過狸花對自己和其他使用者的觀察，在需要人物快速逃離某個地點時，大家的動作都很相似——用力拖拽搖桿，甚至連手機一起向目標方向傾斜。此時都會拖出遠大於以往的距離。搖桿的中心點相對四個方向邊緣的距離，是有極限取值範圍的，也就是說使用者能夠拖拽的距離，在現有的動作習慣下是一個範圍。


那麼搖桿的拖拽距離有無可能作為係數加入物體移動的對映？狸花期待答案。

小結：模擬搖桿可以支援360度的方向變化，我們也習慣了用它控制人物轉向，那如果用它來控制建築物旋轉，會否優於常見的90度轉向按鈕？

下篇將介紹縮放、書寫、旋轉等互動動作設計方案。


作者：狸花踏雪
專欄地址：https://zhuanlan.zhihu.com/p/89879263