介面設計中，互動方式是選擇滑動還是點選呢？

王m爭：在介面設計中，我們如何確定目標元素的互動方式是滑動還是點選呢？

這個改動引發了乙個問題，使用者想檢視下一條答案，要滑動到頁面底部。如果當前的答案字數很多或者配上了，那麼使用者就要滑動好幾次才可以切換答案，這對使用者體驗來說無疑是一種傷害。因為自己畢竟不是知乎內部的員工，不知道這次改動的具體依據是什麼。

參考了朋友圈底下的評論，大家的看法大致可以分為以下三種：

可能會有人說不一定非要滑動到介面底部啊，不是有「下乙個回答」的按鈕嗎，你可以直接點選按鈕切換答案啊。

這是乙個非常好的問題，其實點選按鈕切換答案和滑動切換答案代表了兩種不同的手勢：點選與滑動。

那麼在介面設計中，我們如何確定目標元素的互動方式是滑動還是點選呢？

一、終端滑動還是點選，不同的終端選擇的標準是不一樣的。我們在面試過程中，經常會被問到 pc端和移動端介面設計的區別在**。其實在我看來這兩者最本質的區別在於——內容承載量的不同。

那麼在這種前提下，如何提公升移動端產品的易用性呢？我們可以更多的引入程式設計客棧滑動手勢，為什麼？

因為相比於點選，滑動對於準確性要求不是很高。

例如：在蝦公尺**的歌曲**介面中，如果使用者想返回上一介面，點選螢幕任何區域上滑就可以了。當然你也可以點選介面左上角的返回/收起按鈕，但是明顯費力的很多。而且大屏手機是趨勢，對於習慣右手握持手機的使用者來說，拇指能不能夠得著左上角的按鈕都是乙個問題。

當然並不是所有的滑動手勢都是全屏操作的，在網易雲**中，如果你手指的落點位於唱片的外部，右滑會返回上一介面。如果落點在唱片的內部，右滑會切換歌曲，這就是剛才提到的 ios端左右滑動會和返回手勢相混淆。

以上面提到的知乎為例，其實安卓使用者依然可以左右滑動程式設計客棧切換答案，因為安卓底部有物理返回鍵，不會發生手勢混淆的情況。

二、易感知引入點選/滑動手勢ijohvhox首先要解決的問題就是——如何讓使用者感知到這個玩意是可以點選/滑動的。

點選手勢相對來說要簡單點，因為最常見的按鈕就可以觸發點選事件。而讓使用者感知到滑動手勢的存在是很難的，我是 2016 年 3 月份才發現原來滑動可以刪除微信群記錄。難固然難，但是辦法還是有的。

1. 對隱藏內容進www.cppcns.com行適當展示

以知乎為例，適當的露出下一條答案，不然使用者不知道原來滑動還可以切換答案。

2. 引入現實生活中的隱喻

例如：在 qq閱讀中，夜間模式的開啟/關閉是通過滑動一根燈繩。對於大部分使用者來說，一看到這個燈繩肯定知道這是可以滑動（拉動）的。

三、場景接下來我們主要說一下點選和滑動手勢的使用場景，這裡我選取了幾款我們常用的**類應用。對於一首正在**的歌曲來說，使用者常見的操作有：暫停/**、調整歌曲進度/音量、切換歌曲、檢視歌詞、檢視歌曲/**/歌手詳情、**、/喜歡和分享等。

其中大部分的場景都是由點選手勢來完成，用到滑動手勢的場景只有調整歌曲進度/音量、切換歌曲。其中 qq**、酷我**和蝦公尺**都可以通過向上滑動返回上一介面，有意思的是酷我**依然保留 ios 的返回手勢，也就是說使用者向左/上滑動都可以返回到上一介面。

點選手勢用的比較多，我挑幾個有意思的說一下。

在蝦公尺**中，當你點讚一首歌曲的時候，並不會出現預期的「點讚成功」toast，而是乙個「喜歡就去分享」的浮層。既然你點讚了，必然你很喜歡這首歌，那麼為什麼不分享給更多人呢？

這種互動上的小改動可以增加互動，拉來更多新使用者。

說完好的，再說乙個反面案例。在酷我**中，如果當前歌曲是合唱，使用者點選歌手會出現兩種情況：

這兩種篩選機制中任何一種都是不合理，而且就算是不合理你好歹也統一一下啊，連一致性都沒有考慮到實在是不應該。

最後再給大家舉乙個例子，支付寶和京東金融都有指紋支付功能。開通流程都是一樣的，點選開通按鈕，輸入支付密碼驗證身份。但是在關閉指紋支付功能的時候，支付寶會彈出乙個彈框挽留一下使用者，而京東金融沒有彈框二次確認。

支付寶的操作很像知乎的這次改版，挽留使用者屬於產品的業務目標，但是挽留使用者無形中會傷害使用者體驗——增加了使用者操作步驟。但是當業務目標和使用者體驗相衝突的時候，讓步的往往都是使用者體驗，很無奈。

總結以上就是我對滑動手勢的乙個簡單的分析和總結，如果你有不同的觀點或者看法，歡迎留言。

本文標題: 介面設計中，互動方式是選擇滑動還是點選呢？

本文位址: