CTT 534 Thiết kế giao diện LN11 UI evaluation vi

When?n Thiết kế tương tác và đánh giá là quá trình liên tục, xem xét các khía cạnh sau: q Why: kiểm tra xem người dùng có thể dùng sản phẩm ko, họ có thích sản phẩm ko q What: thiết kế

CTT534 – Thiết Kế Giao Diện

HK II 2015 – 2016

Đánh giá thiết kế giao diện

Bài giảng có tham khảo các nguồn tài liệu sau

- MIT CS Course 6.813/6.831

- USC’s CSCI 588

3 5/24/16

Qui trình áp dụng cho đồ án

1 Phân tích người dùng và nhiệp vụ

2 Phác thảo sơ lược

3 Prototype ban đầu

Đánh giá – Why? What? Where? When?

n Thiết kế tương tác và đánh giá là quá trình liên tục, xem xét các khía cạnh sau:

q Why: kiểm tra xem người dùng có thể dùng sản phẩm

ko, họ có thích sản phẩm ko

q What: thiết kế ý tưởng ban đầu, làm prototype và sau

đó là chi tiết, hoàn thành prototype

q Where: trong môi trường tự nhiên hoặc có thiết lập

q When: xuyên suốt quá trình thiết kế; sản phẩm hoàn thành có thể được đánh giá để thu thập thông tin mô

tả về sản phẩm đó

5 5/24/16

Một vòng thiết kế đảm bảo tính khả dụng

q Phát triển và đánh giá các ý tưởng thiết kế ban đầu cùng với người dùng

q Qui trình phát triển liên tục cùng với người dùng

n Cách ứng xử của hệ thống có khớp với yêu cầu nghiệp vụ của người dùng ko?

n Có vấn đề gì với thiết kế hiện tại hay ko?

q Kiểm thử chấp nhận (acceptance testing) giúp xác định hệ thống có thỏa mãn các yêu cầu hiệu năng của người dùng mong đợi ko

Mục đích của đánh giá

n Đánh giá hiệu quả của tương tác với người

dùng

q Tính khả dụng và sự thỏa mãn của người dùng

n Đánh giá phạm vi của chức năng hệ thống

n Xác định các vấn đề cụ thể trong bản thiết kế

hiện tại

q Xác định các khía cạnh thiết kế gây ra nhầm lẫn hoặc kết quả ko mong đợi

7 5/24/16

Các phương pháp đánh giá

q Do chuyên gia thực hiện

q Field studies

q Formative evaluation

q Controlled experiment

9 5/24/16

Các hướng dẫn/heuristics về tính khả dụng

n Nhiều heuristics dựa vào

q 10 heuristics do Nielsen đề nghị

q Các luật của Norman trong Design of Everyday Things

q 8 luật vàng của Shneiderman

11 5/24/16

Các heuristics của Nielsen

Các luật của Norman

13 5/24/16

8 luật vàng của Shneiderman

Đánh giá heuristics

q Chi phí thấp hơn và hiệu quả hơn các phương pháp khác

q Duyệt lại (review)/thanh tra (inspect) giao diện

q So sánh giao diện với các heuristics đang có

q Ghi nhận lại bằng văn bản những lỗi về tính khả dụng

q Lí giải và biện hộ cac lỗi dựa vào các heuristics

15 5/24/16

Hướng dẫn đánh giá heuristics-1

q “Dialog A có button ‘Hủy’ trong khi nút cùng chức năng như vậy trong Dialog B lại có tên là ‘Đóng’” (Tính nhất quán)

q Đừng bao giờ bảo “Tôi ko thích layout này” (“I don’t like the layout”)

q Dĩ nhiên, ko phải tất cả heuristics có thể áp dụng cho 1

giao diện người dùng

Hướng dẫn đánh giá heuristics-2

q Nhiều người sẽ tìm ra nhiều vấn đề khác nhau hơn là chỉ

có 1 người

q Cùng 1 vấn đề có thể xuất hiện nhiều lần (duplicated)

q Nielsen đề nghị cần có 3-5 người đánh giá

pháp đánh giá khác

q Mỗi phương pháp sẽ tìm ra các lỗi khác nhau

q Đánh giá dựa vào heuristics có chi phí thấp hơn

17 5/24/16

Đánh giá website HCMUS

Đánh giá prototype

q Bản phác thảo

q Prototype trên giấy và prototype trên máy

q Code minh họa (demo code)

q Phản hồi

q Vấn đề thiếu thành phần (“Missing-element”)

q Trợ giúp và tài liệu hóa

19 5/24/16

Quá trình đánh giá chính qui

q Người đánh giá đưa ra độ nghiêm trọng cho các vấn đề tìm thấy

q Đội đánh giá và đội thiết kế thảo luận trên kết quả và đưa

ra các giải pháp đề nghị

Mức độ nghiêm trọng

q Cosmetic/trivial: tầm thường, ko quan trọng, độ ưu tiên

thấp

q Minor: lỗi nhỏ, ko nghiêm trọng, độ ưu tiên thấp

q Major: lỗi lớn, khá nghiêm trọng, độ ưu tiên cao

q Critical: lỗi cực kì nghiêm trọng, độ ưu tiên cao nhất

nhân tố sau

q Tần suất: tần suất xuất hiện của lỗi?

q Ảnh hưởng/tác động: có khó giải quyết ko?

q Sự dai dẳng: lỗi lặp lại nhiều lần ko?

21 5/24/16

Viết đánh giá heuristics-1

q Để giảm thời gian cho cả đội thiết kế và đội đánh giá

Viết đánh giá heuristics-2

q Tiêu đề của lỗi

q Mô tả lỗi

q Heuristic

q Mức độ nghiệm trọng

q Đề nghị và các hình chụp (nếu có)

23 5/24/16

q Người dùng có tìm thấy chức năng trên giao diện?

q Người dùng có biết phải làm gì ko?

q

25 5/24/16

Field studies

q Quan sát các hiệu ứng xảy ra trong môi trường thực tế

q Ko thể nói giao diện là tốt cho đến khi đưa cho người dùng

sử dụng và họ thấy thỏa mãn với nó

q Khó để dự đoán những gì người dùng thật sự muốn

n Vấn đề được xác định là những thứ phát sinh khi người dùng

sử dụng ứng dụng

q Tính khả dụng có thể được đo lường thông qua các kiểm tra bằng cách tính toán hiệu năng sử dụng từ phía người dùng

27 5/24/16

Field studies (tt)

q Tốn thời gian, chi phí thực hiện

q Có thể ko tổng quát hóa được

Qui trình thực hiện

29 5/24/16

1 Chuẩn bị đề xuất kiểm tra

n Đề xuất kiểm tra (test proposal)

q Mục đích kiểm tra (test objective)

q Các thành viên tham gia kiểm tra (test participants)

q Môi trường và nguyên liệu kiểm tra (test environment

q Lượng giá kiểm tra (test measures)

n Dữ liệu kiểm tra cần được thu thập và phân tích

2 Chọn thành viên tham gia

q Người dùng phải tham dự vào quá trình đánh giá sản

phẩm

q Các tác vụ liên quan, kiến thức chuyên biệt về nghiệp vụ

31 5/24/16

2 Chọn thành viên tham gia (tt)

q Quá nhiều người

n Hao tổn chi phí – quan sát quá nhiều người dùng làm tốn thời gian và chi phí

n Vấn đề lớn thường được phát hiện bởi 1 nhóm người

n Các vấn đề nhỏ và cần sự đo lường chính xác thì cần nhiều người dùng tham gia

2 Chọn thành viên tham gia (tt)

q J Nielsen chỉ ra rằng các kiểm tra thực hiện với 5 người dùng sẽ phát hiện ra ít nhất 80% vấn đề về tính khả dụng

q 3 test với 5 người thì tốt hơn 1 test với 15 người

33 5/24/16

Xem xét khía cạnh đạo đức

Ethical considerations

q Áp lực thực hiện à lỗi chắc chắn xảy ra

q Cảm giác ko đầy đủ, thỏa đáng

giảm bớt sự căng thẳng đó:

q Cần có sự đồng thuận thực hiện từ tester

q Giúp tester cảm thấy thoải mái, tránh áp lực

q Để họ biết, họ có thể ngừng việc test nếu muốn

q Nhấn mạnh rằng chúng ta đang test hệ thống, ko phải

đang test tester

q Thu thập dữ liệu một cách ẩn danh nếu có thể

Xem xét khía cạnh đạo đức (tt)

n Mục tiêu của việc test, là để xác định các vấn đề trong tính khả dụng, ko phải để kiểm tra năng

lực của người dùng

35 5/24/16

3 Chọn các mục cần kiểm tra

q Việc có mục tiêu và hướng dẫn test rõ ràng làm cho việc

đo lường trên kết quả tester cũng dễ dàng hơn

hợp nhất với thiết kế của bạn

phải đánh giá người dùng!

4 Tiến hành test

n Các phương pháp đánh giá

q Thanh tra (inspection)

q Quan sát trực tiếp (direct observation)

q Các kĩ thuật truy vấn (query techniques)

n Phỏng vấn/bảng câu hỏi/bảng khảo sát

37 5/24/16

Thanh tra (inspection)

q does the system “feel right”?

q Phát hiện ra các vấn đề lớn, ngay từ các phiên bản đầu

q Hỗ trợ kĩ thuật walkthrough mà lấy tác vụ làm trung tâm

q Ko đáng tin cậy vì hoàn toàn chủ quan

Quan sát trực tiếp (direct observation)

dùng tương tác với hệ thống

q Người dùng hoàn thành tập tác vụ định trước

q Người dùng đi qua các nhiệm vụ cơ bản

39 5/24/16

Kĩ thuật truy vấn (query techniques)

Kĩ thuật truy vấn: Interview

q Tập câu hỏi chuẩn bị trước

n Có cấu trúc, ko cấu trúc hoặc kết hợp

q Ko chính qui, chủ quan, chi phí thấp

người dùng

vấn đề quan tâm được phát sinh

41 5/24/16

Interview (tt)

q Vài câu hỏi giúp khởi đầu thuận lợi buổi interview

q Phỏng vấn hậu quan sát (post-observation interview)

hỏi tiếp theo đó

q Tránh để người dùng dẫn dắt buổi test

Interview (tt)

n Post-observation Interview

q Có người dùng thực hiện test có quan sát

q Tạo bản ghi video của test

q Phỏng vấn người dung với bản ghi video đó

n Người dùng cho nhận xét về các sự kiện đã xảy ra trong quá trình sử dụng hệ thống

q Chẳng hạn, tôi đã dung button này bởi vì…

n Người dùng thường đưa ra đề nghị cụ thể

q Chẳng hạn, nên làm button này nhỏ lại…

43 5/24/16

Interview (tt)

q Có thể thay đổi để phù hợp ngữ cảnh

q Phát hiện vấn đề một cách đầy đủ hơn

q Làm lộ ra góc nhìn/quan điểm của người dùng và tìm ra

các vấn đề ko tiên đoán trước được

q Cực kì chủ quan

q Tốn thời gian

Kĩ thuật truy vấn: Survey

q Ko cần sự xuất hiện của người đánh giá

45 5/24/16

Survey (tt)

n Câu hỏi đóng-mở (open-ended questions)

q Xác định quan điểm tự nhiên

n Bạn có thể đề nghị giúp vài cải tiến cho hệ thống này?

q Đừng giới hạn câu trả lời và kì vọng của người đánh giá

q Tốt cho thông tin chủ quan chung

n Nhưng khó phân tích chặt chẽ

47 5/24/16

Survey (tt)

n Rating scalar questions

q Yêu cầu người dùng đánh giá 1 phát biểu cụ thể dựa vào thang đo số

“Hệ thống dễ dàng phục hồi sau sự cố”

Ko đồng ý 1 2 3 4 5 Đồng ý

q Thang đo thường tương ứng với mức độ đồng ý hay ko

đồng ý với phát biểu

n Thường chọn thang đo 5-7 mức

q Dễ phân tích nhưng cần thiết kế tỉ mỉ

Survey (tt)

n Câu hỏi nhiều lựa chọn (multi-choice questions)

q Người trả lời sẽ đưa ra các chọn lựa từ tập xác định

“Có cách rõ ràng nào để quay về điểm bắt đấu hay menu chính ko?”

A Có, rất rõ ràng

B Có thể có, nhưng khó xác định

C Không, tôi ko thấy

49 5/24/16

Survey (tt)

n Ranked questions

q Người trả lời sắp xếp thứ tự các item trong danh sách

q Hữu dụng để khai thác sở thích người dùng

q Thuộc dạng chọn lựa bắt buộc (forced choice)

Hãy sắp xếp mức độ hữu dụng của các phương pháp nhập liệu

text sau trên thiết bị di động

(1.hữu dụng nhất, 2 hữu dụng tiếp theo, …, 0 ko hữu dịch)

keypad

bàn phím QWERTY

bàn phím ảo trên màn hình có thể touch

Survey (tt)

q Nhanh và áp dụng được cho nhóm đông người dùng

q Ko cần sự có mặt của người đánh giá

q Chất lượng giới hạn của phản hồi

51 5/24/16

n Chọn thành viên tham gia

n Gán tác vụ cho mỗi thành viên

n Xem quá trình thực hiện tác vụ của các thành viên

53 5/24/16

Think aloud

mà còn biết được người dùng đang nghĩ gì

mình khi đang thực hiện tác vụ Chẳng hạn:

q Họ đang cố làm gì

q Sau họ chọn hành động này

q Cách họ hiểu hệ thống đang làm gì

q – “tell me what you are thinking”

q Note, audio, video

Think aloud (tt)

giới công nghiệp

q Đơn giản – yêu cầu sự giám định ít (little expertise)

q Thấu hiểu suy nghĩ người dùng

q Cho thấy hệ thống được sử dụng thế nào

55 5/24/16

Ví dụ

http://www.youtube.com/watch?v=Aa-svs5mQD8&feature=related

57 5/24/16

Controlled experiment

Controlled experiment (tt)

pháp khoa học và framework lí thuyết

q Nghiên cứu các mối liên hệ bằng cách sử dụng các biến

59 5/24/16

Controlled experiment (tt)

q Chuẩn bị đề xuất

q Chuẩn bị môi trường

q Chọn thành viên tham gia

q Xác định các dạng, các thuộc tính cần dùng

q Xác định chiến lược đánh giá

1 Chuẩn bị đề xuất

n Test proposal bao gồm

q Mục đích kiểm tra (test objective)

q Các thành viên tham gia kiểm tra (test participants)

q Môi trường và nguyên liệu kiểm tra (test environment

q Lượng giá kiểm tra (test measures)

n Dữ liệu kiểm tra cần được thu thập và phân tích

61 5/24/16

2 Chuẩn bị môi trường

3 Chọn thành viên tham gia

cho cộng đồng người dùng mong đợi, xem xét các khía cạnh sau:

q background, kinh nghiệm với tác vụ, trình độ học vấn…

ràng

63 5/24/16

4 Xác định các dạng thức và thuộc tính

q Paper mockups

q Special usability testing

q Remote usability testing

q

tham gia

5 Chiến lược đánh giá

các bước chính sau:

q A state lucid and testable hypothesis

q Đưa ra giả thuyết rõ ràng, có thể test được

q B identify independent variables that are to be manipulated

q Xác định các biến độc lập

q C choose dependent variables that will be measured

q Xác định các biến phụ thuộc để đo lường

q D select subjects and assign subjects to groups

q Chọn chủ thể và gán chủ thể vào nhóm

65 5/24/16

5 Chiến lược đánh giá (tt)

các bước chính sau:

q E control for biasing factors

q Điều kiển các nhân tố thiên lệch

q F apply statistical methods to data analysis

q Sử dụng các phương pháp thống kê để phân tích dữ liệu

q G interpret experimental results

q Diễn đạt kết quả thực nghiệm

5 Chiến lược đánh giá (tt)

n Giả thuyết (hypothesis)

q Ví dụ, test menu

“Ko có sự khác biệt về hiệu năng người dùng (xét trên khía cạnh thời gian và lỗi) khi chọn 1 item đơn từ 1

pop-up hoặc chọn 1 pull-down menu có 4 item, bất

luận chủ thể trước đó đã có kinh nghiệm sử dụng

chuột hay sử dụng các kiểu menu khác”

67 5/24/16

5 Chiến lược đánh giá (tt)

n Các biến độc lập (independent variables)

q Những thứ ko phụ thuộc vào hành vi của người dùng

q Chẳng hạn, trong ví dụ test menu ở trên:

“Ko có sự khác biệt về hiệu năng người dùng (xét trên khía cạnh thời gian và lỗi) khi chọn 1 item đơn từ 1

pop-up hoặc chọn 1 pull-down menu có 4 item, bất

luận chủ thể trước đó đã có kinh nghiệm sử dụng

chuột hay sử dụng các kiểu menu khác”

Biến độc lập:

-Loại menu: pop-up và full-down

-Loại chủ thể: chuyên gia và người mới sử dụng

5 Chiến lược đánh giá (tt)

n Biến phụ thuộc

q Là các biến phụ thuộc vào hành vi (behavior) hay phản

ứng (reaction) của người dùng đối với các biến độc lập

q Những thứ cụ thể mà bạn thiết lập để đo lường/quan sát

q Chẳng hạn, trong ví dụ test menu ở trên:

Biến phụ thuộc:

-Tốc độ: thời gian chọn 1 item

-Tỉ lệ lỗi: số lỗi gây ra

-Dễ học: thời gian để sử dụng menu thành thục

69 5/24/16

5 Chiến lược đánh giá (tt)

n Chủ thể (subjects)

q Những người thực hiện tác vụ

q Hãy cẩn thận trong việc chọn lựa chủ thể và gán chủ thể vào các nhóm

5 Chiến lược đánh giá (tt)

n Phân tích dữ liệu thống kê (statistical data

n Sử dụng các phương pháp kiểm tra giả thuyết (chẳng hạn,

student t-test, ANOVA)

71 5/24/16

5 Chiến lược đánh giá (tt)

n Phân tích dữ liệu thống kê

q Trình bày dưới dạng biểu đồ, bảng biểu hoặc đồ thị

5 Chiến lược đánh giá (tt)

n Thể hiện kết quả thực hiện (interpreting

experimental results)

q Bạn nghĩ rằng kết quả đưa ra ý nghĩa gì

q Hàm ý của chúng đối với thiết kế của bạn

q Làm sao để tổng quát hoát kết quả

q Các giới hạn và phê bình

73 5/24/16

Tổng kết

q Thực hiện xuyên suốt trong quá trình thiết kế giao diện để đảm bảo tính khả dụnge

q Chuẩn bị đề xuất kiểm tra

q Chọn thành viên tham gia

q Chọn thuộc tính sẽ kiểm tra

q Thực hiện kiểm tra Kĩ thuật:

n Thanh tra (inspection)

n Quan sát trực tiếp (direct observation)

n Kĩ thuật truy vấn (Query techniques)

q Đo đạc các kết quả kiểm tra