Please enable JavaScript.
Coggle requires JavaScript to display documents.
人機 W9 - Coggle Diagram
人機 W9
用例 Use Case
對於個體基於某種目標所做的要求,系統該如何回應
⽤例就是「⼀件能讓使⽤者做的事」
在心理歷程裡,會在行為、介面、回饋看到
在介面上的行動,是單位最小的用例
不包含目的/結果的⾏動,⼀般不被認為是用例
按下返回鍵是行動,不是用例
按下返回鍵回到前一個介面,是用例
⽤例的組織= 活動/任務/⾏動
Big use case,由⼀連串small use cases所組合
打卡
拿出⼿機拍照
選擇三張照⽚
把照⽚分享到FB上
有優先順序和關係
HTA: Hierarchical Task Analysis
層級作業(⼯作)分析,把task分成subtasks
用例的層次
Cloud & Kite level
Summary Use Case
總和性的活動
主要的次級活動
Sea level
User Goal
不同性質的任務
使⽤者的目標
Fish level
Sub-function
使⽤者做的每⼀件事
可能跟隨不同目的
介⾯是use case的容器
為了實現用例而被賦予存在的
介面定義了⽤例的範圍
介面基於某種譬喻
介面彼此關係如何
進⼊這個介⾯的前提
⼤介⾯裡怎麼套⼩介⾯
用例的結構
action
如「點擊」,「雙點」,「拖曳」
object
介⾯元件,實體按鍵
actor
⿏標,⼿指
reaction
介⾯的反應
動詞名詞分析法
「使⽤者可以在觀景窗上轉換前後鏡頭」
容器:觀景窗
動詞:轉換
(這個動詞,配上哪個actor跟action?)
名詞:前後鏡頭
(這是個object?)
反應:
如何組織用例
共同領域
功能範圍類似,隸屬層次相近
共同條件
針對同⼀個object,在同⼀個狀態下
重要性/常⽤程度
對⼀件email,最常做的事是哪些?
有優先順序及關係
有些重要,常⽤
開始⼀封email,刪去email
有些不重要
改email的字體
有些雖然重要,但是不常⽤
更改帳戶
重要性!
:red_flag:圖p.41
既使在同一個頁面,也有組織
界定功能範圍
不同性質的功能區塊
主要/次要的功能區塊
理想中的操作序列
區塊之間的移動
這個介⾯中要盡⼒導引使⽤者完成的事是什麼?
什麼時候跳介⾯?(什麼時候容許使⽤者離開?)
沒離開前,如何處理reaction?
(不希望打斷注意⼒或⾏動)
:star:完形知覺定律
人的注意力有限,加一樣東西會消耗分配給其他東西的注意力
介面設計= 如何引導注意例,順暢的完成最重要的用例
用例自動化
如果有幾件⾏動序列是固定不變的,可以作成macro 「巨集」
作業分析 Task Analysis
需求 「Requirement」
對系統的操作性要求
擴充需求的範圍
方式
行為的
反思的
本能的
社會文化環境的需求及特殊考量
使用場景
物理性環境
思路
product-oriented
做為⼀個產品,市場有什麼要求?
目前產品的功能,表現⽔準如何?
競品分析:和競爭者相⽐,如何?
process-oriented
從使⽤的歷程分析中去找出
不完備的地⽅/未滿⾜的需求
可以增添價值的地⽅
方式
情境式設計contextual design
選擇⼀部筆電,你會注意什麼?期待什麼?
(這個問題,難道不該讓TA帶著他的筆電來訪談?)
Think Aloud 放聲思考
要求使⽤者描述⾃⼰在想/做什麼
藉此了解使⽤者注意力的焦點、需要的資訊
Wizard of Oz 奧茲巫師法
如果這個東⻄還不存在,如何了解需求?
假裝它存在,讓使⽤者與其互動
參與式設計participatory design
藉由使⽤者的參與來取得需求
這不是⼀個「設計」⽅法,這是⼀個「研究」⽅法
聽他們的需求,不要聽他們的答案
必須涵蓋的範圍
要完成這些事,系統必須提供使⽤者哪些⼯具?
介⾯的元件該怎麼⽤?
要完成這些事,使⽤者需要知道什麼?
有沒有在介⾯裡提供這些東⻄呢?
系統必須讓使⽤者做哪些事?
目的
定義「⽤例」以及⽤例的組織
運用活動>任務>行動,將一項活動分解成最基本的行動
使用者不只一種人
一個複雜的系統,stackholders不只一個
狗食做得像骨頭,貓食做得像魚?
每⼀個stakeholder,會有不同的需求,所以要選擇觀點
UI is Communication, CH2
所有的GUI操作系統,都會制定介⾯指南
目的
介紹常⽤的介⾯元件
詳述每⼀個元件的「性格」
選擇使⽤的基本原則