使用者理所當然會傾向於直覺與方便的操作，所謂直覺操作，亦即使用者可以根據過往生活經驗，不用額外輔助知識就能在未知介面中達成任務。
有些工具與介面，我們認為是方便使用者使用，但是因為功能過於高度重複以及不能完全輔佐使用者達成任務，導致該工具與介面被使用者棄用。
功能覆蓋
我們透過一些例子了解這是怎麼運作的：
假設給定一個小工具，該小工具可顯示公告等相關訊息；而此小工具的公告訊息來源來自某個系統。若今天某系統最常被使用來觀看公告系統，但使用者必須經歷多於操作小工具的步驟才可觀看公告，那麼這個小工具是有用的。
亦即：若假設$A$ 為某系統， $ A’$ 為某系統的小工具，彼此之間的功能隸屬為 $A’ \subset A$；若是使用者操作歷程的方便度為$A_{convenience} < A’_{convenience}$，則$A’$在這條規則，是一個成功設計的工具。
在這裡的註記，我們不使用$\subseteq$ 的概念，因為此概念可代表左右可代表一樣的集合，但是就失去我們的主系統與小工具的意義了。
要注意的一點，上面的規則並不代表這是一個「全面」成功的設計工具；再一個例子：
伴隨作用
若是今天使用者習慣有伴隨的作用，亦即使用者習慣於操作$x$ 動作後會再進行 $y$ 操作；今天小工具給予顯示公告等相關訊息，使用者習慣於看完公告後觀看作業項目，但是小工具並未給予此項目的顯示功能，迫使使用者必須進入到系統觀看作業項目；在此，就不是一個成功的設計，因為使用者可以選擇直接進入系統觀看，而避免使用小工具，尤其是小工具的操作經驗與系統操作經驗不一致時。
所以：使用以上的註記法，若是使用者有一連串的習慣行為動作集合記為$B$，而 $B$ 為有序集合，每一元素為該用戶使用到的功能；如果 $B \not\subset A’$ 但是 $B \subset A$ ，那麼此小工具 $A’$ 在此規則中，不能帶給使用者流暢的體驗。
範例
今天設計一套系統，擁有公告訊息、繳費等一般使用者會使用到的功能，今天系統設計部門，由於操作系統需要一點精力與時間，所以部門決定設計一個小工具，希望可以帶給使用者更大的方便性，我們分幾個情境來看：
管理方發布公告，而使用者也只看公告而已
這種情況有可能發生在：系統的繳費功能較少用到，但是管理方通常用系統發布公告，那麼小工具可以只設計顯示公告，供使用者觀看。
管理方發布公告，而公告內容通常需要要求使用者觀看後繳費
考慮到若是使用者觀看（ $x$ 動作）後就想繳清費用（ $y$ 動作），那小工具應該提供繳清費用的功能。
管理方發布公告，但是大家都不鳥
那你應該檢討你自己了。
後記
另外值得注意的是，我們並不鼓勵將所有的系統功能都移植到小工具上；普遍來說，由於系統上並非所有都是使用者常用功能，若是皆為常用功能，則考慮點並非另造小工具，而是考慮該系統 UX 改善。
Share this post
Twitter
Google+
Facebook
Reddit
LinkedIn
Pinterest
Email