推薦：WEB可用性測試的問題設計
在可用性測試中，最主要的兩個角色，一個是受測(TestParticipant)，另一個是測試員(TestFacilitator)。這回小兔來說說測試員(TestFacilitator)在可用性測試

減少交互

當某個軟件迫使用戶進行交互，它就把自己判定為操作型軟件。軟件的外部模型通過對導航進行操作形成情境模型。但是，不同于真正的操作型軟件，用戶不關心這個外部模型──它只是為了最終看到相關信息的一種手段。

設計者的目標是讓用戶以盡可能少的操作塑造出情境模型。假設將圖形設計，歷史數據和環境關聯等手段被拋在一邊，他們就沒有什么技術手段可以減少交互帶來的負面影響了：

• 形象化操作能將情境模型應用于適當的信息集合中。
• 相關性引導能讓用戶確認模型，而無需建構模型。
• 緊湊的反饋循環能讓用戶無需太多操作便能接近結果。

形象化操作。命令行系統被批評為強迫用戶來學習電腦的語言�，F代的圖形界面可能會更輕易使用，但它相對前者在這方面沒有太大的改進。圖形界面語言是由菜單，按鈕，以及確認框組成的，每一個控制元素都是非情境化的。用戶要通過一個特定的的指令輸入需求──它完全不同于任何人類語言，缺乏形象化的含義且很不自然。

打個比方，看這個男孩如何向別人“演示和描述”他的玩具：

話由于這個孩子的描述能力不強，他只能通過演示來傳達復雜的概念。同樣地，圖形界面的發展并不完善，使得文字提示繁瑣且晦澀，但軟件的動態傳遞是理想的演示方式。用戶可以點擊某處的信息圖形，說：“就是這兒！”，來獲取該處的關聯情境。

兩個最根本的描述情境的條件便是“時間”與“地點”。幾千年來，人們都以這兩個條件為基礎來繪制專門的信息圖表。但仍有許多現代軟件放棄了這一傳統做法，看這家網上熱門的搬家公司：

這些下拉菜單既突兀又沒能顯示充足的信息。地理位置應該從地圖上找，而日期應該從日歷上選。這是重新設計后的效果：

這個設計也并非最理想。地點和日期信息應該能從用戶既有的地圖和日歷上提供。但在滿足這樣需求的平臺普及之前，軟件至少應該提供類似的臨時服務。

作為進一步應用特定情境的一個例子，看一個主流的網上花店設計是如何讓用戶局限在下拉菜單里的： 對比另一個簡單的可視化導向設計：

我們是怎么發展到今天的？

當前的很多軟件都存在交互多，信息少的問題。我能想到的幾個原因是。

首先，我們目前的用戶界面范式，是在另一個技術時代發明的。舉例來說，最初的Macintosh時代，沒有網絡，沒有大規模的存儲，而且很少有跨程序的溝通。因此，它無從獲取它自身環境之外的數據，記憶空間太少以致于無法保留重大歷史記錄。

交互是設計者可利用的唯一手段。因為在當時，計算機無需提供太多的信息，所以，大部分軟件還都是操作型軟件──打字機，繪圖板，分類賬簿。經過二十年的發展以及互聯網爆炸時代的到來，軟件可以提供更多的服務。

現代軟件模擬機械運行機制的第二個原因是，對于那些創建軟件的人來說，計算機就是一臺機器。程序員生活在操作模式中，她操作一臺計算機就如同駕駛一輛車。因此，她下意識的認為軟件也必須像一臺機器那樣被操作，即使它的功能只類似于報紙或書籍。更糟的是，那些設計平臺和圖形界面工具箱的人更輕易從這個角度看問題，因為他們工作于更低的層面。然后，應用軟件設計師在設計大環境的影響下，幾乎被迫投入到對機械模型的研究中去了。

即便有些軟件熟悉到了應該“豐富信息，簡化交互”，卻還是依舊把時間浪費在改良操作方式上，一次又一次的更新版本。對于設計師和程序員來說增加菜單項目和對話框都比重新設計一個動態圖形更輕易，有時，他們的理由是應該盡可能少改變用戶的使用習慣。經過十次改版后，這個軟件很可能改得像個怪物，用戶花費在向下拉動菜單的時間比了解和獲取信息的時間還要長。

軟件不應該這樣發展，但解決這個問題需要對設計流程和技術平臺作大量地重新思考。經過最近設計的一個案例進行具體研究，我將談談面對信息軟件革命我們需要做些什么。

原文地址：http://worrydream.com/MagicInk/

分享：膚淺網頁設計
一直以來，我深信yahoo的網頁設計是很棒的。但是，我的確說不出具體的理由，因為實在有太多的網站比它好看得多。我之所以覺得它好，是因為它是世界第一大站，它