一. Iphone應用程式概述
可分成三類
1. 公用程式—讓使用者快速取得特定類型的資訊，或執行經嚴格定義的工作
Ex: 天氣、股票、交通報導
特性
(1) 最少的設定
(2) 簡單的流程和版面
(3) 標準的使用者介面元件—因快速使用，不會花時間學習新的Icon
2. 產出式—有更完整的功能
Ex: 多數的應用程式都可以歸納到此類
特色
(1) 階層式結構
(2) 快速鍵和捷徑
3. 沉浸式—玩遊戲、看影片或執行專業工作
特色:
(1) 將重點放在內容上
(2) 自訂使用者經驗—例如電玩，有一些獨特的操作遊戲行為
4. 選擇應用程式的類別
(1) 許多應用程式可能包含多種的應用程式類別，並非只能單純的歸為某一類
二. [ 使用者研究簡介 ]
1. 透過使用者研究我會學到甚麼
(2) 使用者需求
(3) 使用者環境
(4) 認知
(5) 痛點
(6) 語言和術語—了解特定領域的語言與術語
(7) 規範—了解特定領域的社會行為歸範，避免觸犯
2. 常見研究方式
(1) 觀察
(2) 實地訪談
(3) 訪問專家
(4) 電話訪談
(5) 街頭訪談
(6) 焦點團體訪談—並不建議，因為參與者很容易受到其他團體的影響
(7) 日誌研究
(8) 市調
3. 選擇研究方式
(1) 初期階段適合觀察型的方式，較後期則可運用觀察與原型
4. 規劃研究
(1) 目的與目標
(2) 研究日期
(3) 使用者背景個人資料
(4) 方法
(5) 列出要研究的問題，以及如何進行
(6) 角色—研究的分工，例如有人是觀察者，有人是主持人等等
(7) 裝備
(8) 報告內容
5. 徵人與選擇合適的受測對象
6. 引導訪談進行
(1) 在正式訪談之前，需要先測試過相關的測試是否可以問出正確的問題
(2) 一些技巧
甲、 問開放式的問題
乙、 尋找具體的例子
丙、 調查—有一些使用者沒有說出來的內容，也含有重要的見解。
丁、 使用者容易誤認為在”測試他們”，並進而美化描述，只為了避免證明自己很蠢，但這會讓訪談結果有偏差，必須讓受測者明確知道，我們是在測試產品，不是測試使用者
三. 分析使用者研究
1. 程序概述
(1) 分享資源 (2)分析筆記 (3)紀錄的含意及想法 (4)報告發現 (5)建立設計工具 (6)修改PDS
2. 分享資源—透過視覺化的方式來分享資源
3. 分析筆紀—
(1) 將筆記整理成便利貼中，並將之分類歸納，討論人數不要太多
(2) 如果某一個分類明顯大於其他分類，可能是該分類可以再細化，請將他細化
(3) 分類完成後，排出發現的優先順序
4. 紀錄的含意及想法
(1) 含意: 讀者團隊想遵循的最佳實作規範或設計原則
(2) 想法: 想加入實際設計的功能或概念 (請用不同顏色的便利貼)
5. 報告發現
(1) 將上述的所有討論與結論，寫成一份快速文件，以防止未來遺忘
(2) 也可利用報告發現後的時間，快速跟相關人進行動腦會議，並將之紀錄下來
6. 建立設計工具
常用的方式
(1) Persona (http://miin1130.pixnet.net/blog/post/28459588)
(2) 情境集
●通常包含以下數項資訊
(2.1) 動機
(2.2) 使用環境描述
(2.3) 環境上可能讓人分心的情況，以及如何處理此分心情況
(2.4) 主要目標為何，如何達成
●常見問題
(2.5) 我需要寫幾個情境
● 取決於代表性人物的數目和應用程式的複雜程度
● 寫下重要的情境，而非所有的情境，若事後發現遺漏某些重要情境，再回頭擴充就可以了。
7. 修改產品定義聲明
經過以上的研究，就不再會寫出如下的產品定義聲明
[ 協助人們尋找藝文活動的一件工具 ]
而是
[ 協助”市區內藝文界人士”，”尋找、分享和評論”藝文活動的一款應用程式 ]
人物主角與主要功能就更清楚了。
四. 評估競爭對手
1. 不只評估前幾名的競爭對手上，而要包含到任何有突出表現之使用者經驗
2. 評估方式
(1) 排序表 – 利用表格方式進行比對
(2) 2*2圖表 – 利用二維四個相象的原理來找出不同產品定位
(3) 法則式評估
●法則 – 可依本身需求進行評量
EX: 嚴重性評量表 (0,1,2,3,4)
Ex: 十個使用性法則
(1) 應用程式狀態的可見度--應用成是應該透過合適的反應回饋讓使用者一直都知道現在在做甚麼
(2) 應用程式和真實世界的符合程度
(3) 使用者控制項及自由度--使用者常常會錯誤地選擇應用程式功能，故需要有清楚標示的緊急退出
(4) 錯誤預防--刪除易於出錯的狀況，或檢查它們並提供還員選項給使用者
(5) 一致性和標準
(6) 認出而非回想--降低使用者需要記憶的事項
(7) 使用的彈性和效率
(8) 美學和極簡設計
(9) 協助使用者找出及診斷錯誤，並從中還原--錯誤訊息應該以簡單易懂的文字來表達，並要精確地指出問題和解決方案
(10) 求助和紀錄-- 求助應該要與使用環境有關、簡潔並具體
●情境
決定要測驗的情境
●實驗室 vs 實地
需要考量下述情況
(1) 環境 (2)同時發生的活動—使用者在使用此應用程式的同時，是否會同時做其他事 (3) 相關實體設備 (4)時間 (5)網路情況 (6)使用者資料
●捕捉 & 紀錄發現
(4) 競爭對手使用性標竿測量
類似法則性評估性做法，但改用計量方式統計，常見的紀錄計量
●錯誤的數目
●工作完成的時間
●是否成功完成工作
五. 探索應用程式概念
1. 建立方便共享資訊與討論的環境
2. 腦力激盪
3. 記下寫法
4. 選出有前途的想法
5. 將概念畫成草圖
六. 建立應用程式概念的原型
1. 建立原型的方法
(1) 紙上原型
可用於探索 – 應用程式的概念、工作流程、資訊的組織、用語、其他功能(有些功能可能需要補強或是乾脆拿掉)
(2) 裝置上的靜態圖像
將原型轉成靜態圖像，使使用者更易理解，但缺點是仍缺乏互動，還有成本較高
(3) 裝置上的互動
幾乎可以探索所有的使用者體驗問題，但成本更高。至於最大的問題，則是有可能因有較高成本投入，所以，如果一開始就用此方式，有可能變成這可能是接近最後的結果，而失去探索其它的可能性
(4) 影像 (拍攝成影片來說明)
優點是可以看到接近真實情況的使用案例，但缺點是，這比較是其他使用者只能關看影片，無法進行互動體驗
(5) iphone SDK
快速實際開發程式，暫不考慮使用上的特殊案例
七. 對應用程式概念進行使用性測試
1. 使用性測試的方法
(1) 傳統式使用性測試
要求使用者利用產品去完成指定任務，逐一觀察他們
(2) RITE法 (快速反覆測試暨評估法)
類似傳統方式，但更有效率就可以取得成果，但缺點為如果為難以短時間修改的部分，則無法使用此方式。
(3) 紙上原型測試
2. 使用性測試的時間軸
● Step 1. 規劃使用性測試
● Step 2. 可平行作業 (1)徵人測試 (2)討論指南
● Step 3. 試驗性會談
● Step 4. 引導
● Step 5. 分析
●Step 6. 簡報
3. 規劃使用性測試
(1)目的和目標
● 初期階段研究
評估目前設計中的流程與互動上的使用者體驗問題，並改善設計
● 在開發前的基準
評估該應用程式在設計上的整體使用者經驗，包含流程、互動設計或轉換等細節
● 特定功能或流程的研究
(2)研究日期和時間
(3)使用者個人資料
(4)確定研究方法
(5)研究問題
(6)角色(主持人、觀察員、紀錄)
(7)原型用品
(8)裝備和地點
(9)報告內容
4. 徵求參與者
5. 起草討論指南
確認當進行測試時，整個流程該怎麼進行，包含此次研究簡介、背景訪問、實際測試、後續問題、總結
6. 實驗性會談
在正式測試前，需要做先導測試，確認之前的指南是有效的，可以順利完成正式的實驗，並取得必要的結果
P.S. 我個人曾經做過類似實驗，此步驟非常重要，因為使用者可能會有意料外的情況，導致整個實驗結果失敗，先導測試可以避免此情況發生
7. 分析使用性測試結果
個人補充 -- 可以將問題整理出來，分門別類，排出問題嚴重程度權重，並統計實驗出來的結果，如果嚴重而且很容易造成使用者問題，要優先處理
8. 簡報
9. 游擊式使用性測試
10. 測試版測試
八. 後續數章，則偏向iOS相關的設計指南或色彩學等相關內容，此類資訊在網路上很容易取得，也更完整，就不多做介紹了
留言列表
