本文主要給大家講解：「確認」、「下一步」等這類存在于頁面中的按鈕在擺放時，對頁面 or 產品造成的影響有哪些。

這類按鈕在頁面中的主要形式有以下三種：

固定于底部

固定于底部且跟隨鍵盤運動

跟隨列表移動(用戶體驗講解)

固定于底部

當「下一步」or「確認」等按鈕固定于頁面底部時，從統籌全局的角度來說，頁面的布局會比較清晰，不同頁面之間的整體性更加一致，符合設計的統一性原則。

所以將按鈕固定于頁面底部，是很多設計師在設計此類界面時會使用的方法。

但是這并不能說明這種方法好，假設：這三個頁面中的列表是需要填寫或編輯的，則按鈕置于底部就會在操作上顯得不是很方便。

首先，對列表可編輯欄進行修改時，頁面下方會彈出鍵盤，而鍵盤的出現會將確認按鈕遮擋住，導致用戶無法點擊。所以產品在開發時就需要注意將鍵盤的「Done」或「完成」鍵與頁面的「下一步」按鈕做聯動。但其實有些鍵盤是沒有「Done」或「完成」鍵的，所以這里對開發成本來說是更大的，當然這不是最重要的。

重點是，對于一些用戶來說，點擊鍵盤上的「完成」鍵是比較生疏的，包括我自己，其實都很少直接去點擊鍵盤上的「完成」鍵。就像大部分人一樣，在完成編輯后的第一反應不是點擊鍵盤的「完成」按鈕，而是點擊鍵盤的「隱藏」鍵或頁面空白處，希望鍵盤消失，從而顯示出「下一步」按鈕，然而這樣的操作并不友好。

所以從這點考慮，如果在產品列表頁面的操作過程中，列表類型屬于查看類的話(即不可編輯)，那么統一將按鈕置于頁面底部，是沒有問題的。

而如果在產品列表頁面的操作過程中，存在需填寫或編輯的情況，那么將按鈕固定于底部，就不是非常明智的選擇了。

固定于底部且跟隨鍵盤運動

我最開始設計的方案其實就是這一種：將按鈕與鍵盤綁定，一開始固定于底部，進行編輯時，鍵盤彈出，就將按鈕一起帶上來。

這樣不僅很好的解決了上面提到的「按鈕被遮擋」的問題，而且操作過程中也非常方便，無需編輯就固定在底部，需要編輯就隨鍵盤移動到上方。無論列表怎么變化，按鈕的位置永遠是那兩個地方，不會變動。

可惜，我是一個有極度強迫癥的人，所以當我遇到極端例子的時候，我又開始糾結這個方案的可行性。如下圖：

是不是似曾相識?我在畫草圖的時候，遇到這樣的情況，立馬能聯想到平時用 App 碰到類似的場景：按鈕露出一丟丟，填寫完成后，不是想著先把鍵盤隱藏或者是點擊鍵盤的確認鍵，而是用自己纖細的手指去點按鈕露出來的那一部分，然后經常點錯。

所以我繼續開始想方案了。

跟隨列表移動（用戶體驗講解）

按鈕跟隨列表移動，是我想了許多方案后定下的，雖然也存在瑕疵，但已經是我能想到的方案中最好的一種了。

瑕疵就是：使用這個方案雖然能解決鍵盤彈出的問題，但其實還是會出現遮擋現象，如圖。

但相較于跟隨鍵盤移動的好處是：符合用戶的操作體驗。

我相信第三個方案(跟隨列表移動)是絕大部分人在設計時都能想到的，但是很多人一定不知道這么設計的原因。

在設計這個流程的時候，其實有一個誤區，也就是我開頭提到的，即：頁面遵循設計的統一性原則。

導致設計師在設計的過程中，希望將頁面元素盡可能的統一化，包括圖標、按鈕、位置等等。從而忽略了其實每個頁面都是一個「單獨的個體」，我們需要的是讓用戶在每一個頁面都能順利的完成操作，而不是從設計者的角度來說「頁面布局」的統一性。

所以根據列表的閱讀順序，我們從第一行開始讀到最后一行，從視覺流的角度來說，按鈕在接近列表下面的位置時，對于用戶來說是接收的最快的。

同時，我在設計的過程中，否決了將「確認」按鈕置于右上角的方案。

因為在這類列表頁的操作下，用戶去確認列表信息是非常重要的過程，所以將「下一步」或「確認」按鈕置于右上角，只有是在列表頁的內容并不重要的情況下才會如此設計。

總結

本篇文章主要說的是：按鈕的位置對頁面的影響，不要被一致性原則所束縛，而要懂得靈活運用。

所以頁面中的任何一個元素的擺放，影響的都不僅僅是頁面的布局，更多的其實是用戶在操作過程中的體驗。

其實工作中有很多類似的小問題，很多人只是理所當然的覺得是這樣，沒有去深究過為什么，而這些細節往往是產品是否成功的關鍵。

歡迎關注作者的微信公眾號：「呆呆U理」