大產(chǎn)品小細(xì)節(jié)！5分鐘帶你了解經(jīng)典的費(fèi)茨定律

金蝶云之家體驗(yàn)部交互設(shè)計(jì)師-王梓銘：大家有沒有想過(guò)為什么按鈕越大，越易于點(diǎn)擊 ？為什么相干按鈕必要相互靠近擺放 ？為什么 Win 體系要將「開始」按鈕放在角落 ？這些設(shè)定的背后其實(shí)都有一個(gè)在人機(jī)交互中，特別很是緊張的定律 —— 費(fèi)茨定律。

上期回顧：《大產(chǎn)品小細(xì)節(jié)！5分鐘了解格式塔原則》

一. 概述

首先來(lái)看看費(fèi)茨定律公式：

看起來(lái)很復(fù)雜吧， 但現(xiàn)實(shí)上并不難，我用一張圖給大家詮釋下費(fèi)茨定律是什么。當(dāng)用戶必要拖動(dòng)黃色點(diǎn)到目標(biāo)區(qū)塊中時(shí)：

費(fèi)茨定律中的 D 就是從開始點(diǎn)到目標(biāo)中間的距離，而 W 則是目標(biāo)的寬度大小。根據(jù)公式可以看到，A和 b 都是常量，那么 MT （黃點(diǎn)從左移到目標(biāo)中間所需的時(shí)間）的大小取決于 D 和 W 的值：

• 當(dāng) D 肯定時(shí)，W 越小，MT 越大；W 越大，MT 越小。
• 當(dāng) W 肯定時(shí)，D 越小，MT 越?。籇 越大，MT 越大。

詮釋一下就是：

當(dāng)距離肯定時(shí)，目標(biāo)越小，所花費(fèi)的時(shí)間越長(zhǎng)；目標(biāo)越大，所花費(fèi)的時(shí)間越短。（小而遠(yuǎn)的目標(biāo)區(qū)域意味著用戶必要將黃點(diǎn)移動(dòng)較長(zhǎng)距離，并且為了能對(duì)準(zhǔn)目標(biāo)還必要做一系列的微調(diào)，由于目標(biāo)比較小嘛，所以耗費(fèi)的時(shí)間天然就長(zhǎng)了。）

當(dāng)目標(biāo)大小肯定時(shí)，起點(diǎn)離目標(biāo)中間的距離越近，所花費(fèi)的時(shí)間越短；距離越遠(yuǎn)，所花時(shí)間越長(zhǎng)。（這比較好理解，距離比較近嘛~ 所花時(shí)間天然比較短了。）

二. 啟示與案例

按鈕越大越易于點(diǎn)擊

正如前面提到的，假如你想要讓按鈕的點(diǎn)擊率更高可以嘗試將按鈕做大點(diǎn)，比如如許：

將按鈕放置在脫離始點(diǎn)較近的地方

照舊拿上面兩個(gè)界面為例子，大家有沒有發(fā)現(xiàn)那兩個(gè)大大的按鈕是放在屏幕下方的？緣故原由就是「將按鈕放在底部可以使 D 變小」，要知道用戶完成整個(gè)點(diǎn)擊操作是要先將手指移動(dòng)到目標(biāo)上方，最后進(jìn)行點(diǎn)擊的。那么在這里 D 就是手指開始懸停的位置到目標(biāo)上方的距離。根據(jù)研究注解，人們?cè)谑褂檬謾C(jī)的時(shí)候，75%的交互操作都是由拇指驅(qū)動(dòng)的，而拇指懸停的位置恰恰就是屏幕下方。

PS：關(guān)于用戶是如何使用觸屏設(shè)備的，迎接大家看看這篇讀書筆記——「閱讀」觸類旁通:多終端時(shí)代的觸屏界面設(shè)計(jì) 文中提到的書本，也保舉大家買來(lái)看看。

那么對(duì)于 PC 端設(shè)備，又是如何使用這肯定律的呢？
最常見的使用就是鼠標(biāo)右鍵操作了。點(diǎn)擊右鍵，鼠標(biāo)的右下或右上方就會(huì)出現(xiàn)一個(gè)菜單，鼠標(biāo)移動(dòng)到對(duì)應(yīng)按鈕上，點(diǎn)擊一下即可完成操作。

相干按鈕之間距離近點(diǎn)更易于點(diǎn)擊

對(duì)于一些相干性較強(qiáng)的按鈕，可以考慮將他們放在一路，比如：

• 在設(shè)計(jì) PC 端的翻頁(yè)按鈕時(shí)，就可以將「上一頁(yè)」和「下一頁(yè)」放在互相靠近的位置。
• 在設(shè)計(jì)注冊(cè)、登錄界面的時(shí)候，可以將「注冊(cè)」和「登錄」放到一路，假如想要凸起「注冊(cè)」則可以考慮將「注冊(cè)」按鈕做大點(diǎn)。
• 相干聯(lián)的操作也可以嘗試放在一路，不僅可以在視覺上加強(qiáng)用戶對(duì)他們相干性的認(rèn)知，還可以削減在他們之間的距離 D。

無(wú)窮大的四角與四邊

文章開頭，我提出了一個(gè)疑問：

為什么 Win 體系要將「開始」按鈕放在角落 ？

緣故原由就是屏幕的四角和四邊 W 無(wú)窮大，W 無(wú)窮大的話，MT 就很小了。像 Mac 的 Docker 更是將費(fèi)茨定律發(fā)揮得淋漓盡致，當(dāng)鼠標(biāo) hover 到對(duì)應(yīng)的 App icon 上的時(shí)候，icon 還會(huì)放大，從而加大 App icon 的W 。

估計(jì)大家又會(huì)有個(gè)迷惑，那就是——為什么四角和四邊的 W 無(wú)窮大？

那是由于光標(biāo)沒法移動(dòng)到四角與四邊之外的地方，你再怎么移動(dòng)鼠標(biāo)，光標(biāo)也沒辦法移到屏幕以外的地方，所以他們就進(jìn)入到了「無(wú)窮可選中」?fàn)顩r。

但是，隨著屏幕尺寸越來(lái)越大，而且雙屏幕的配置越來(lái)越常見，這個(gè)設(shè)計(jì)也變沒得那么好用了，由于 D 變大了。同理手機(jī)端的四角與四邊也是「無(wú)窮可選中」位置，由于手點(diǎn)擊屏幕以外屏幕不會(huì)相應(yīng)嘛。（所以各位可以發(fā)現(xiàn)左上角按鈕一樣平常為返回，右上角為確定）但是在手機(jī)上時(shí)候，依然會(huì)面臨屏幕越來(lái)越大，按鈕越來(lái)越不好點(diǎn)擊的題目。

三. 小演習(xí)

最后，我想跟大家一路做個(gè)小演習(xí)，那就是請(qǐng)大家和我一路設(shè)計(jì)手機(jī)的關(guān)機(jī)界面。

明確設(shè)計(jì)目標(biāo)

首先明確設(shè)計(jì)目標(biāo)：設(shè)計(jì)手機(jī)的關(guān)機(jī)界面。

明確束縛與限定

明確了設(shè)計(jì)目標(biāo)后，必要考慮設(shè)計(jì)束縛與技術(shù)限定有哪些？（這里我們不考慮技術(shù)題目）對(duì)于關(guān)機(jī)操作來(lái)說(shuō)，自己是個(gè)特別很是高危的操作，一經(jīng)生效就沒法撤銷了。那么這里的設(shè)計(jì)束縛就有：

• 此操作不能過(guò)于便捷
• 防止誤觸
• 如有需要必要有防待操作

將理論應(yīng)用到設(shè)計(jì)中

根據(jù)束縛，我們開始設(shè)計(jì)方案。在設(shè)計(jì)時(shí)候，我們不妨將我們所學(xué)的費(fèi)茨定律應(yīng)用到設(shè)計(jì)之中，估計(jì)這里又有同窗會(huì)問，費(fèi)茨定律不是教我們?cè)O(shè)計(jì)出易于點(diǎn)擊的設(shè)計(jì)嗎？很顯明與你提到的束縛相違反啊。其實(shí)費(fèi)茨定律不只能正著用，還能反著用。比如我們可以嘗試加大 D 和降低 W。

先嘗試加大拇指到目標(biāo)的距離 D，那么可以得出甲方案。（這設(shè)計(jì)就是許多安卓手機(jī)提供的的方案）

不過(guò)正如前面提到的第三條啟示，相干的按鈕放在一路更便于點(diǎn)擊。但是我們現(xiàn)實(shí)上并不想讓用戶點(diǎn)擊「關(guān)閉手機(jī)」而是盼望用戶點(diǎn)擊「取消」，將兩個(gè)放在一路并不合適，那么我們可以嘗試降低「取消」按鈕的 D 從而減弱用戶點(diǎn)擊「關(guān)閉手機(jī)」的可能，并且根據(jù)費(fèi)茨定律我們可以將「關(guān)閉手機(jī)」的 W 做小，從而得出乙方案。

但是這個(gè)方案還不夠極致，這里我想跟大家明確另一點(diǎn)：D 的距離是可以創(chuàng)造出來(lái)的。

觸屏的巨大之處就在于，它不僅僅有點(diǎn)擊操作，還有滑動(dòng)操作。通過(guò)滑動(dòng)操作也可以創(chuàng)造出 D 出來(lái)。如丙方案所示，完成關(guān)機(jī)操作的總 D 等于「大拇指移動(dòng)到頂部滑塊的距離」加上「按住滑塊滑動(dòng)到右邊的距離」。

為什么許多人會(huì)覺得 iPhone 的體驗(yàn)比絕大多數(shù)的安卓手機(jī)要好，看看這個(gè)關(guān)機(jī)界面就知道緣故原由在哪里了吧 。

四. 總結(jié)

在文章的最后，回顧一下費(fèi)茨定律給我們的啟示：

• 按鈕做大點(diǎn)（W大點(diǎn)）更易于點(diǎn)擊。
• 將按鈕放置在脫離始點(diǎn)較近的地方。
• 相干按鈕之間距離近點(diǎn)（D小點(diǎn)）更易于點(diǎn)擊。
• 屏幕的四角與四邊是「無(wú)窮可選中」位置。
• 通過(guò)費(fèi)茨定律的反向使用，可以降低按鈕被點(diǎn)擊的可能。

迎接關(guān)注微信公眾號(hào)：「UXD-Cloudhub」