Teambition可用性測試記

時間 2019-11-10

標籤 teambition 用性測試简体版

原文原文鏈接

引言：最開始知道Teambition是幾個月前，當時是想找一個團隊協做工具。Teambition是候選之一，它的界面設計給我留下了印象。後來得知其背後年輕的創始團隊仍是讓我有些小驚訝的。此次經過朋友介紹給Teambition作可用性測試也有些興奮。數據庫

從會面到測試設計，再到實施與總結，前先後後持續了3周。在這個過程當中我一直在觀察、思考，發現了閃光點，同時也捕獲了許多細節問題，可謂收穫頗豐。安全

我認爲Teambition網站在可用性（體驗）方面是通過思考的，網站的設計含蓄優雅，力圖經過技術讓Web頁面給用戶相似桌面應用的實時體驗。大量使用隱藏、擴展面板，避免使人厭煩又毫無用處的彈出對話框，讓用戶更容易進入沉浸（"流"）工做狀態。這都是做爲企業應用的優秀特質。工具

在測試過程當中，我發現用戶在建立任務的過程當中都遇到了困難。新用戶把「建立任務列表」看成建立任務進行操做。從表面上看是用戶不理解或不注意「任務列表」與「任務」的區別。但我認爲深層的緣由與用戶概念模型與產品實現模型不一致有關。oop

Teambition產品的思惟模式是這樣的，建立任務前，先要建立任務組（如圖1），以後在組內建立相應任務。這個模式明顯是產品的實現模式，程序邏輯、數據庫結構清晰。學習

（圖1 建立任務從建立任務列表開始）測試

但這卻不是用戶的思惟模式。用戶的思惟模式是這樣的，他有一個或幾個零散的任務，當前只想把任務建好，分配出去。他還不清楚（可能都尚未想）項目以後會發展到多大，會有多少個模塊，總體結構會是怎樣的。當之後任務多了，他可能纔會想要分組。用一個表概括以下：網站

模型spa	行爲方式設計	理由3d
產品實現模型	建立任務結構（列表），建立任務	邏輯清晰，方便開發實現
用戶概念模型	先建立任務，整理、歸類之後再說	關注當前目標

設計產品時，須要更多的使用用戶概念模型去思考。例如，提供默認任務列表，用戶上來能夠直接建立任務（步驟也節省了，操做效率更高），後期用戶能夠在須要時對列表進行進一步的修改、整理。

Teambition界面的對齊與風格統一作得較好，但對比不足。

頁面中首先想讓用戶看到的指引提示信息使用灰底、灰字，如圖2所示。

（圖2 用戶指引信息）

對比不足，就不能凸顯當前元素的首要性，沒法很好的抓住用戶的眼睛，默默的淹沒在其餘元素中。當想清楚「你想讓用戶往哪看？」這一問題，大膽的使用對比。

測試中發現的另外一個讓用戶遇到困難的操做是建立任務，如圖3所示。

（圖3 建立任務頁面）

形成這一困難的緣由有多個，後面還會再次提到。用戶建立頁面從圖3中紅色圈處開始，但這裏的對比也是不足夠的。

在「任務板」頁面（如圖4）中，你以爲一、二、三、4紅圈中的圖標，哪些是能夠點擊的？你以爲五、6兩個六邊形框中的時鐘是控件嗎？橙色框七、8中的灰色文字是否都是標註？

（圖4 任務板頁面中的圖標與文字）

外表相同的圖標，有些是控件，有些僅僅是圖標，用戶又怎麼知道呢？輸入框與標註文字一個模樣，一樣讓用戶疑惑，僅靠文字說明不是最優的方案。

Teambition中設計了一些拖拽操做，在某些場景下使用很方便。但若是可拖拽圖標和其餘圖標如出一轍，用戶又如何去發現呢？用戶拖拽起圖標，又該放置到哪兒呢？拖拽的接收方是否是也應該在合適的時機告訴用戶「我這能接收」呢？

還有對於必填項與選填項若是能經過可視化進行區分，也能方便用戶。

在測試中有用戶在任務建立過程當中，未填寫任務內容，屢次點擊「建立」未果，如圖5所示。

（圖5 建立任務界面）

出現這一情況是一連串的誤解形成，該用戶首先把建立任務列表看成建立任務，其次沒有意識到任務內容輸入框是能夠輸入的，最後點擊「建立」按鈕頁面沒有任何反饋。這裏點擊「建立」按鈕是最後一個指引用戶的機會，但沒有報錯、沒有提示，毫無反饋，用戶屢次點擊後放棄，內心除了疑惑還有抱怨。若在這裏應用能發現用戶沒輸入任務內容，不唐突的給出一個提示（如：幾秒鐘的浮動提示），同時高亮輸入區域，可能還能亡羊補牢。我認爲任何失敗操做都應給用戶有用的反饋。

對於成功操做是否也須要反饋（也稱正面反饋）？這就涉及到Teambition的一項產品哲學，打造相似桌面應用的實時體驗，即用戶在頁面上進行修改、添加、刪除操做，頁面上的數據直接發生變化，無刷新。對於Teambition來講這就是成功反饋，但這是否足夠？我認爲在某些狀況下可能不夠。第1、有些數據變化很微小，容易被忽視，有時還會被遮蔽。譬如，任務列表中已經有不少任務，再添加一條新任務，新任務會出如今列表尾部，徹底可能在用戶的可視範圍外。第2、Web沒法保證徹底實時的頁面更新。在測試中能夠發現上傳文件或進行任務操做後實時更新並非每次都能很及時，有時還須要手動點擊。這就讓用戶懷疑本身的操做成功了嗎？給予正面反饋，消除用戶的疑惑。

至於反饋的方式，拋棄彈出式對話框，選擇不打斷用戶的提示，現今各大網站的最佳實踐已有不少。

從Teambition中右側按鈕（如圖6所示）提及，新用戶容易忽略右側按鈕，尋找一個功能也很困難。

（圖6 Teambition中的右側按鈕）

我分析下來有兩個緣由：

1. 用戶視線跳躍。以建立任務爲例（操做順序如圖7所示），用戶進打開頁面後的注意區域在左上側，「建立任務列表」在右側，用戶視線注意力要橫跨屏幕。

（圖7 建立任務操做順序）

再如要修改任務執行者（操做順序如圖8所示），用戶的視線注意力須要跨越中間的任務詳情區域，太難找了。

（圖8 修改任務執行者操做順序）

2. 不斷變化的按鈕列表，用戶不容易熟悉。對於不一樣頁面、點擊對象，右側按鈕的數量、按鈕功能都不相同。我揣測網站設計師想讓右側按鈕根據當前上下文顯示數量最少，但這會帶來問題。右側的這些按鈕能夠想象成大多數軟件的工具欄按鈕或菜單按鈕。若是你使用軟件的這些按鈕不斷的變多、變少，你會有什麼感受？並且這樣的設計也很難讓用戶記住這些功能的位置，從初學者變爲中級用戶。

個人建議是：

1. 固定右側按鈕，根據上下文disable部分按鈕。

2. 減小右側按鈕的數量，儘量把功能放入到跟合適的上下文中。提供可見便可改的操做，直接修改任務列表名稱，直接在任務詳情中修改執行人，任務列表旁邊直接提供刪除操做等，如圖9藍色框處直接可修改。

（圖9 支持可見便可改）

在任何顯示信息的區域，都去思考是否能直接提供修改的功能，這對用戶最方便。

不一樣程度用戶的需求是不一樣的，初學者須要易上手，中、高級用戶但願高效率，對於工具應用特別是這樣。

在Teambition網站的任何文本框中輸入後回車，直接完成錄入。這個功能對於中、高級用戶很高效，但這也形成了初學者的困惑。測試中用戶輸入完成後很困惑，「肯定按鈕在哪裏？這樣算錄入成功了嗎？」如圖10所示。

（圖10 用戶輸入後不知所措）

在提供回車錄入的同時，若能給初學者留一個肯定按鈕，就能兼顧不一樣程度的用戶。咱們要讓初學者很容易上手，同時漸漸讓他們學會更高效的方法，把他們變爲中級用戶，這樣他們就會愛上咱們的應用。

猜猜看圖11中點擊右上角的「×」，頁面會發生什麼？

（圖11 頁面右上角的叉）

測試中被問到這個問題的用戶，都認爲這樣會離開當前頁面。很難想象這個「×」是用於關閉圖中出於中間擴展區域（任務詳情區域）的。關閉按鈕放在對應模塊右上角是習慣用法，問起爲何不這樣作，聽到的回答說是當時怎麼放都不美觀，就放在整個頁面的右上角。又據說下一版本這個按鈕要改了，但並非放回相關區域右上角，而是徹底去除。關閉擴展區域的方法是在擴展區域外進行任何點擊，設計師說這是一個創新。我認爲創新思惟很是棒，但須要注意的是創新不是爲了知足設計師的創新欲，而是爲了提供更好的用戶體驗。打破習慣用法不是不能夠，但要證實新的用法能帶來足夠大的好處，這須要充足的實驗與思考。

測試中有位用戶先是選中了一個任務，並在頁面上進行探索性嘗試，她無心間點擊了「由我執行」，發現任務的執行者變了，但這並非她想要的，但又忘了以前任務的執行者是誰。她說的話給我印象很深，「爲何沒有撤銷按鈕，一點安全感都沒有」。她但願任何操做都能撤銷，回到上一個狀態，這樣她能更大膽的嘗試各類功能。不少用戶使用科技產品會有心理負擔，擔憂本身的無心操做把系統搞亂了、搞壞了。這使他們在嘗試時縮手縮腳，阻礙了學習過程。

對於獨立的桌面應用我會建議提供撤銷與回退功能，相似Office軟件中的撤銷功能或相似回收箱功能。但多人協做Web應用，提供撤銷並不容易。Teambition提供了操做日誌，能看到對任務的每個操做，這樣用戶能知道本身當前操做前的狀態，如圖12中所示。

（圖12 任務操做日誌）

惋惜這一功能用戶沒能發現。一方面日誌的添加太不顯眼，另外一方面新的日誌條目添加在列表尾部，列表長了就沒法看到。這也是缺少反饋與對比的問題，若是把日誌按時間倒序排列，每次新添加的條目先有一個幾秒鐘的高亮，再恢復正常顯示，對用戶可能就貼心不少。

測試中暴露出的另外一個明顯問題是用戶找本身的任務很困難。有把任務板中整個項目的任務都看成是本身的，也有點擊每個任務費力尋找的。從用戶的這些行爲來看，任務板的設計是有問題的。現有任務板首先按照任務列表分組，組內可選擇「按時間分組」或「按執行人分組」。這樣的設計沒有從大多數用戶的目標出發。

我認爲大多數用戶但願看到的任務列表以下：