顯示具有 usability 標籤的文章。 顯示所有文章
顯示具有 usability 標籤的文章。 顯示所有文章

2014年1月30日 星期四

初次使用 paper prototyping 做使用性測試

雖然時常看到有人推薦用紙筆畫 app 介面做使用性測試, 但是要自己動手畫重覆的東西, 實在是提不起勁。前陣子聽阿修介紹 Paper Prototype, 也有同事動手畫了幾頁, 實際跟著流程走一次, 感覺還不錯。剛好我有在 iPad 裡裝 POP, 當場用 POP 結合同事做的紙張雛型, 互動效果出乎意料的好。

最近想幫爸媽做一款「待做事項」的軟體, 順便練習從頭開發一款 app 要經過的流程。中午花了大概一小時畫草稿加上用 POP 制作雛型, 過程滿順暢的。下面是部份原稿和 POP Android 版的畫面。

和爸媽分別測試後有找到一些小問題, 不過確定大方向應該可行。後來找我哥測試, 原以為應該會更順暢, 但是因為我哥使用 iPhone, 我是針對 Android 畫的草圖, 結果不容易融入情境。再加上我哥不是我的目標對象, 主要操作流程和他的期望不同, 也影響測試的流暢度。

歸納一下目前對使用 POP 做 paper prototyping 的看法。

目的:

  • 做使用性測試。了解使用者是否了解如何操作。功能是否有滿足使用者的需求。

注意事項:

  • 需要篩選目標使用者。
  • 測試前要做情境描述, 使用者才能進入狀況 (看著草圖想像要做的事)。
  • 盡量觀察使用者的反應, 少開口提醒。

優點:

  • 制作速度快, 適合早期討論, 甚至能在開會中當場做。
  • 易於專注在操作流程, 不會討論配色、字型、畫面排版等細節。
  • 任何人都可以製作, 工程師和設計師以外的人也可藉此展示自己的想法。

限制:

  • 只適合能融入情境的使用者。也許可透過幾次體驗後克服。
  • 還是有可能插題討論圖示, 所以也不能畫得太糟。

總結來說, 現在我覺得用 POP 做 paper prototyping 滿快的, 但若是只用紙張互動, 一來我做得比較慢, 二來使用者也比較難聯想。我自己不適合用純紙張版本的 paper prototyping。

附帶一提, 做得過程中要自己用紙筆畫出概要, 才留意到一些 Android UI 的小細節。還有實際測試流程不像影片裡那樣順。看了再多資料, 還是得親身走一遍才行。

2010年11月21日 星期日

網站定位對使用性的影響

前陣子讀《Don't make me think》提到, 網站設計的最高原則就是 --- 別讓使用者思考如何用, 這意味著網站頁面必須有明確的進入點, 頁面上任何元件都要能自我解讀。所以, 複雜的產品通常不是好主意。

今天剛好看到YUI3設計中的激進和妥協裡的評論提到:
前端開發這個行業的產生時間本來就很短,相比傳統的企業級的應用軟件開發是相當的初級的,本質原因是因為web開發的複雜程度遠不如ERP,我在實習的時候參加過一些ERP的開發,光一個訂單管理的小模塊所需要的報表就有成百上千個……我們可以說J2EE艱辛慘淡,但絕不會死,而且會在更加專業和尖端的企業開發中有著更加旺盛的生命力。
因此框架一定是在業務複雜到一定程度後的必然選擇,這是無可迴避的。 問題是,web產品的使用者不是受過良好培訓的業務員、不是企業管理者、不是操作員和工程師,而是千千萬萬傻乎乎的初等網民,網民水平不提升,我們甚至不敢做出太複雜的產品,那麼……
讓我有這樣的想法, 公司內部用的網站是個工具, 公司不用擔心使用者看不懂怎麼用而拒絕使用, 公司可以藉由「教育使用者」而大幅減少網站設計的難度和開發時間。另一個相似的例子是, 網站只是協助服務的工具, 使用者不會因網站難用而拒用這個服務。比方說年代售票難用到爆炸, 但若只有這個購票方式時, 也只好繼續使用。而年代售票唯一要確定的事, 是線上刷卡這段有做好, 不能算錯帳。只要這點沒出包, 那怕大刺刺地寫著「請等個數十秒」的訊息, 使用者也得乖乖等待。

但若網站本身就是核心服務, 像是相簿、Blog、書籤、搜尋、入口網站這類服務, 就要仔細分析和改進使用性。這算是從另一個角度來解讀網站使用性的重要程度吧, 世上沒有絕對重要的事, 什麼事都要看情況決定。

在 Fedora 下裝 id-utils

Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...