Đừng bắt tôi suy nghĩ

(Tái bản năm 2014)

 Ấn bản đầu tiên

Dành cho cha tôi, người luôn mong muốn tôi viết 1 cuốn sách,

Dành cho mẹ tôi, người luôn khiến tôi cảm thấy rằng tôi đủ khả năng viết được 1 cuốn sách,

Dành cho Melanie, người đã chịu cưới tôi - Điều may mắn kỳ diệu nhất tôi có được trong suốt cuộc đời này,

Và dành cho con trai Harry của tôi, người chắc chắn sẽ viết ra những cuốn sách hay hơn cuốn này rất nhiều
nếu nó muốn.

Ấn bản thứ hai

Dành cho ông anh trai tôi, Phil, người cả đời sống tử tế đúng đắn.

Ấn bản thứ ba

Dành cho tất cả những độc giả trên toàn thế giới, những người đã đọc và yêu thích cuốn sách này trong 14
năm qua. Những lời tốt đẹp của các bạn, dù là qua email, qua các blogs hay trực tiếp, đều là niềm vui lớn
trong cuộc đời tôi.

Đặc biệt là cái chị gái đã kể rằng cuốn sách này khiến cô ấy cười sặc sụa tới mức sữa phun ra qua đường mũi
khi đang vừa đọc vừa uống sữa.
MỤC LỤC

LỜI TỰA: VỀ TÁI BẢN LẦN NÀY

Mở đầu: Đọc phần này trước
E hèm e hèm. Disclaimer đây.

CÁC NGUYÊN TẮC CƠ BẢN

Chương 1: ​Đừng bắt tôi suy nghĩ
Định luật đầu tiên của Steve Krug về Tính khả dụng.
Chương 2: ​Cách người dùng sử dụng trang Web trên thực tế
Đọc lướt, Chấp nhận thỏa hiệp, và Mò mẫm.
Chương 3: ​Nhập môn thiết kế biển quảng cáo
Thiết kế để đọc lướt, không phải đọc kĩ.
Chương 4: ​Động vật, Thực vật, hay Khoáng chất?
Tại sao người dùng lại thích những phương án vô não?
Chương 5: ​Loại bỏ từ ngữ thừa thãi
Nghệ thuật viết càng ít càng tốt cho website.

THỨ BẠN CẦN LÀM ĐÚNG

Chương 6: ​Biển chỉ đường và Vụn bánh mì?
Điều hướng mang tính thiết kế.
Chương 7: ​Nguyên lý Big bang trong Thiết kế Web
Tầm quan trọng của việc chỉ cho người dùng đi đúng hướng ngay từ bước đầu tiên.

KIỂM TRA LẠI XEM ĐÃ ĐÚNG THẬT CHƯA

Chương 8: ​Người nông dân và ông chăn bò đáng ra phải là bạn thân
Tại sao phần lớn các cuộc tranh cãi về Tính khả dụng đều chỉ tổ phí thời gian?
Chương 9: ​Usability Testing giá rẻ, chỉ 1k mỗi ngày
Giữ cho các bài test đơn giản thôi - để bạn có thể test cho đủ

CÁC THẮC MẮC RỘNG HƠN VÀ CÁC ẢNH HƯỞNG NGOẠI QUAN
Chương 10: ​Mobile: Không chỉ đơn thuần là tên 1 thành phố thuộc bang Alabama nữa.
Chào mừng tới thế kỉ 21 - Bạn có thể bị chóng mặt đấy.
Chương 11: ​Tính khả dụng như một thường thức ở đời
Tại sao Website của bạn nên là Thạch Sanh.
Chương 12: ​Tính dễ tiếp cận và bạn
1 con moè bay qua, trên lưng nó có gắn 1 miếng bánh mì nướng đã phết bơ.
Chương 13: ​Hướng đi cho những tâm hồn lạc lối.
Áp dụng Tính khả dụng lên vạn vật xung quanh bạn.
Lời tựa: Về tái bản lần này
Tôi viết cuốn sách “Đừng bắt tôi suy nghĩ” lần đầu tiên vào năm 2000.

Tới năm 2002, tôi bắt đầu nhận được 1 vài email từ độc giả, họ hỏi (1 cách rất lịch sự) xem tôi có muốn cập
nhật cuốn sách không. Thường thì các góp ý là “Tôi không phàn nàn gì cả, chỉ muốn giúp bạn thôi", “Sách bác
nhiều ví dụ bị lỗi thời rồi bác ạ", etc..

Lời phản hồi thông thường của tôi là “Vì tôi viết cuốn sách vào đúng cái đợt bong bóng Internet thịnh hành,
nên nhiều trang web mà tôi dùng làm ví dụ đều đã biến mất trước khi nó được xuất bản rồi”. Nhưng tôi không
nghĩ là lời phản hồi này giúp cho các ví dụ đó rõ ràng hơn là bao.

Cuối cùng, vào năm 2006 tôi có 1 động lực cá nhân khá lớn để cập nhật cuốn sách. Nhưng khi đọc lại để xem
mình nên thay đổi cái gì, tôi vẫn nghĩ “cái này bây giờ vẫn đúng hết mà". Tôi thật sự không tìm ra cái gì để mà
chỉnh sửa cả.

Nếu đã là 1 bản sách mới, thì phải có cái gì đó khác biệt. Nên tôi đã thêm vào 3 chương mà hồi năm 2000 tôi
chưa có đủ thời gian để viết hết, và ngồi chơi xơi nước thêm 7 năm nữa.
(Đối với tôi thì viết lách rất vất vả, và cứ không phải viết là tôi sướng. Tôi thà đi rút tuỷ răng còn hơn là phải
viết sách)
Vậy thì tại sao tới bây giờ lại có thêm 1 bản mới? Có 2 lý do:

#1: Cuốn sách đã hơi lỗi thời

Đến cái tầm này thì đúng là thế. Dù sao thì cũng 13 năm trôi qua rồi còn gì, mà 13 năm trên cái thời đại
Internet này thì cảm giác như cả trăm năm ấy (Đấy mọi người thấy không, thời buổi này có ai dùng mấy cái từ
như “Thời đại Internet” nữa đâu)
Phần lớn trang web mà tôi dùng để làm ví dụ, như trang web chiến dịch tranh cử của Thượng nghị sĩ Orrin
Hatch năm 2000 giờ trông rất cũ kĩ rồi. Như chúng ta có thể nhận thấy, các trang web ngày nay trông phức tạp
và cầu kì hơn nhiều.

Gần đây, tôi lo rằng kiểu gì cũng sẽ tới lúc cuốn sách này nó cũ đến độ nó sẽ không giúp ích gì cho người ta
nữa. Nhưng tôi biết điều này chưa tới, vì:
- Nó vẫn bán ổn định (cảm ơn trời), mà không có dấu hiệu chậm lại. Nó thậm chí còn trở thành 1 cuốn
sách được yêu cầu phải đọc trong rất nhiều khóa học, điều mà tôi không bao giờ mơ tới.
- Những độc giả mới từ khắp nơi trên thế giới tiếp tục tweet về những điều họ đã học được.
+ “Chẳng quan trọng ta phải click bao nhiêu lần, miễn là mỗi lần click là 1 sự lựa chọn rõ ràng,
không cần suy nghĩ"
+ “Chúng ta không đọc Web, chúng ta chỉ lướt Web thôi"
 - Thi thoảng vẫn có người kể rằng “Tôi đưa cuốn sách cho sếp tôi, mong rằng hắn sẽ hiểu thứ tôi muốn
kể. Xong hắn đọc thật, và hắn mua cho cả team/công ty luôn!” (Tôi rất hạnh phúc)
- Người ta thường xuyên khoe rằng họ xin được việc phần là vì đọc cuốn sách này hoặc vì nó ảnh
hưởng tới lựa chọn nghề nghiệp của họ.

Nhưng tôi biết kiểu gì thì cái quá trình lão hoá sẽ khiến cho người ta không thèm đọc cuốn sách nữa, vì cùng
cái lý do khiến cho việc rủ thằng con trai tôi xem phim đen trắng hồi bé rất khó khăn, mặc dù phim nó rất hay.
Rõ ràng là tôi cần phải thêm các ví dụ mới vào cuốn sách rồi.

#2: Thế giới đã thay đổi

Bảo là máy tính và Internet và cách chúng ta tương tác với chúng đã thay đổi rất nhiều là còn nói nhẹ, nói rất
nhẹ.

Tình hình đã thay đổi ở 3 phương diện:

- Công nghệ đang phát triển như cắn thuốc. Hồi năm 2000, chúng ta lướt Web trên các màn hình lớn,
dùng chuột và bàn phím. Và hồi đó chúng ta thường phải ngồi trên bàn ghế đàng hoàng. Giờ thì ta sử
dùng những loại máy tính siêu nhỏ có thể mang đi mọi lúc mọi nơi, với camera tĩnh sắc nét, bản đồ ảo
diệu có thể định vị chính xác vị trí của ta, và cả 1 thư viện sách và nhạc đồ sộ trong đó. Và lúc nào
cũng có kết nối Internet. À mà cái đó là điện thoại nữa đấy. Chậc, tôi có thể dùng cái “điện thoại" của
tôi để làm những thứ như:
Cũng chẳng phải xe hơi bay được (thứ mà đáng ra tới giờ là phải được phát minh ra rồi), nhưng cũng ấn
tượng đấy chứ.
- Bản thân các trang Web cũng đang trở nên tốt hơn. Kể cả khi tôi dùng máy tính Desktop để làm
mọi thứ tôi vẫn hay làm trên mạng (mua hàng, lên lịch di chuyển đi lại, kết nối với bạn bè, đọc tin tức,
chơi cá cược, etc..) các trang Web tôi dùng thường tốt và hữu ích hơn phiên bản đi trước của chúng
khá nhiều. Chúng ta đã quen với các tính năng tự động gợi ý và tự động sửa lỗi, và chúng ta sẽ khó
chịu nếu không thể đóng phí đỗ xe hay cập nhật bằng lái xe qua mạng.

- Tính khả dụng đang ngày càng phổ cập. Vào những năm 2000, không mấy người hiểu được tầm
quan trọng của tính khả dụng.
Giờ đây, nhờ 1 phần công rất lớn của Steve Jobs (Và Jonathan Ive nữa), hầu như ai cũng hiểu rằng
tính khả dụng là rất quan trọng, kể cả khi họ không biết nó là cái gì. Tuy nhiên giờ thì họ sẽ gọi nó là
Trải nghiệm người dùng ( User Experience - UX ), một thuật ngữ khái quát cho mọi hoạt động hay
ngành nghề đóng góp cho việc cải thiện trải nghiệm của người dùng khi sử dụng 1 sản phẩm nào đó.
Thật là tuyệt khi giờ đây người ta đã ưu tiên việc thiết kế lấy người dùng là trung tâm, nhưng tất cả
 những mớ JD cầu kỳ hoa mỹ, những công việc trừu tượng, công cụ thiết kế phức tạp đi kèm với cuộc
cách mạng này đang khiến cho rất nhiều người cảm thấy khó hiểu về những thứ gì cần phải làm.

Tôi sẽ nói thêm về 3 điều này trong phần còn lại của cuốn sách.

Đừng hiểu nhầm…

Ấn bản này có các ví dụ mới, một số nguyên tắc mới và một vài điều mới tôi đã học được trong vài năm trở lại
đây, nhưng nó vẫn là cùng một cuốn sách, với cùng một mục đích: Đây là một cuốn sách giúp chúng ta thiết
kế các trang web tuyệt vời, dễ dùng.
Và nó cũng vẫn là một cuốn sách về thiết kế mọi thứ mà con người cần tương tác sử dụng, cho dù đó là cái
lò vi sóng, ứng dụng di động hay máy ATM.
Các nguyên tắc cơ bản vẫn giữ nguyên ngay cả khi bối cảnh công nghệ đã thay đổi, bởi vì Tính khả dụng có
liên quan đến con người và cách họ hiểu và sử dụng mọi thứ, chứ không phải liên quan đến công nghệ. Và
trong khi công nghệ thường thay đổi nhanh chóng, mọi người thay đổi rất chậm.
Hoặc như Jakhôngb Nielsen đã nói một cách khéo léo:
“Năng lực của bộ não con người không thay đổi từ năm này sang năm khác, vì vậy những dữ liệu từ việc
nghiên cứu hành vi của con người vẫn có ích trong thời gian rất dài. Những gì người dùng thấy khó khăn hồi
20 năm trước cũng sẽ khó khăn ở thời điểm hiện tại.”
Tôi hi vọng bạn sẽ thích ấn bản mới này. Vài năm sau đi đường trên xe hơi bay mà gặp nhau thì đừng quên
vẫy chào tôi nhé.

Steve Krug, 2013

Mở đầu: đọc phần này trước
E hèm e hèm. Disclaimer (thông báo miễn trừ trách nhiệm) đây.

“Tôi không thể nói với bạn những điều bạn chưa biết. Nhưng tôi có thể làm sáng tỏ một vài điều.”
JOE FERRARA - 1 thằng bạn thời cấp 3 của tôi

Tôi có 1 công việc ổn. Tôi là chuyên gia tư vấn về Usability (Tính khả dụng). Công việc của tôi bao gồm:
- Người ta (khách hàng) gửi cho tôi 1 cái gì đó họ đang phát triển. Có thể là các bản thiết kế cho 1 trang
web mới mà họ đang xây, hoặc là URL của 1 website mà họ đang phải thiết kế lại, hoặc là 1 bản nháp
(prototype) của 1 app nào đó.
- Tôi thử sử dụng sản phẩm đó, tương tác với sản phẩm giống như 1 người khách hàng thực thụ.
Sau đó tôi sẽ ghi chú lại những phần mà người dùng dễ bị vướng mắc khi sử dụng, và những thứ có
khả năng gây hiểu nhầm (đây gọi là Review về Tính khả dụng)
Thi thoảng tôi cũng đưa sản phẩm cho người khác dùng thử và quan sát xem họ vướng và hiểu nhầm
ở chỗ nào (đây gọi là Testing về Tính khả dụng)

- Tôi họp với khách hàng để mô tả các vấn đề mà tôi thấy có khả năng khiến người dùng khó chịu (vấn
đề về Tính khả dụng) và giúp họ quyết định xem vấn đề nào là quan trọng nhất để khắc phục và cách
khắc phục tốt nhất là gì.
 Tôi từng hay viết các bài report dài lê thê, mô tả cụ thể về những tìm hiểu của tôi, nhưng sau này thì
tôi nhận ra nó chẳng đáng thời gian và công sức. 1 buổi thuyết trình trực tiếp cho phép khách hàng đặt
ra những câu hỏi và thắc mắc - 1 thứ mà bản report không thể có được. Và với những khách hàng làm
việc theo mô hình AGILE hay LEAN, thì cũng chẳng có thời gian mà viết report.

- Họ trả tiền.

Là một chuyên gia tư vấn, tôi được làm việc trong các dự án thú vị với rất nhiều người thông minh, tốt bụng.
Tôi được làm ở nhà suốt và tôi không phải ngồi trong các cuộc họp căng thẳng mỗi ngày hoặc phải giải quyết
với drama nơi công sở. Tôi có thể nói những gì tôi nghĩ, và mọi người thường đánh giá cao nó. Và tôi được trả
lương cao.
Trên hết, tôi cảm thấy rất thoả mãn với những thứ mình làm, bởi vì khi chúng tôi hoàn thành, sản phẩm đầu ra
hầu như luôn luôn tốt hơn nhiều so với khi chúng tôi bắt đầu.

Tin xấu là: Chắc team bạn cũng không có 1 chuyên gia về Tính khả dụng đâu

Hầu như mọi team phát triển sản phẩm đều cần ai đó như tôi để giúp họ xây dựng Tính khả dụng vào các sản
phẩm của họ. Nhưng đen đủi là, phần lớn trong số họ không có đủ khả năng để thuê một chuyên gia về Tính
khả dụng.
Và thậm chí nếu họ có thể, thì số lượng chuyên gia cũng không nhiều chút nào. Có hàng tỷ trang web (riêng
iPhone đã có rất rất rất nhiều app rồi - tôi cũng không hiểu sao Apple có thể tự hào về điều này. Có 1 số lượng
vừa phải app ngon nghẻ trên 1 platform là 1 điều tích cực. Nhưng có bạt ngàn app lom dom trung bình trên 1
platform chỉ khiến cho việc tìm ra các app ngon khó khăn hơn nhiều) và chỉ có khoảng 10.000 chuyên gia tư
vấn về Tính khả dụng trên toàn thế giới. Bạn tự tính tỉ lệ mà xem.

Và ngay cả khi bạn có một chuyên gia trong team của mình, người đó khó có thể kiểm tra tất cả mọi thứ mà
team tạo ra.
Trong vài năm qua, làm cho mọi thứ trở nên hữu dụng hơn đã trở thành trách nhiệm của mọi người.
UI Designer và Developer hiện nay thường những việc như thiết kế tương tác (interaction design) (quyết định
điều gì xảy ra tiếp theo khi người dùng nhấp, chạm hoặc vuốt) và kiến trúc thông tin (information architecture)
(tìm ra cách tổ chức và xâu chuỗi mọi thứ).
Tôi viết cuốn sách này chủ yếu cho những người không đủ khả năng để thuê (hoặc mướn) một chuyên gia tư
vấn về Tính khả dụng.
Biết một số nguyên tắc cơ bản về Tính khả dụng sẽ giúp bạn tự mình nhìn thấy các vấn đề và từ đó tránh tạo
ra chúng ngay từ những bước đầu tiên.
Miễn bàn rồi: Nếu bạn có đủ khả năng, hãy thuê chuyên gia mà làm cho khoẻ. Nhưng nếu bạn không thể, thì
tôi hy vọng cuốn sách này sẽ giúp bạn tự làm điều đó.
Tin tốt là: Tìm hiểu về Tính khả dụng không khó lắm

May mắn thay, phần lớn những gì tôi làm đều là những lẽ thường hiển nhiên, và bất cứ ai chỉ cần 1 chút hứng
thú là có thể học cách làm điều này.
Tất nhiên, giống như rất nhiều lẽ thường hiển nhiên khác, thi thoảng phải có người khác chỉ thẳng ra cho bạn
xem thì bạn mới hiểu được. (Đó là lý do tại sao công ty tư vấn của tôi có tên “Lẽ thường Cao cấp", khẩu hiệu
của công ty là “Cái này cũng chả khó lắm!" )
Tôi suốt ngày phải nói với mọi người những điều họ vốn đã biết rồi, vì vậy đừng ngạc nhiên nếu bạn thi thoảng
lẩm bẩm “cái này mình cũng biết mà" khi đọc những trang sách tiếp theo.

Tin tốt nữa: cuốn sách này không dài

Tôi đã rất nỗ lực để giữ cho cuốn sách này không quá dài, hi vọng đủ ngắn gọn để bạn có thể đọc nó trên 1
chuyến bay dài. Tôi làm điều này vì 2 lý do:
- Nếu nó ngắn, nó sẽ dễ được áp dụng hơn. (​ Đây cũng là 1 nguyên tắc về Tính khả dụng luôn - nếu
thứ gì đó yêu cầu đầu tư lớn về thời gian, hoặc trông có vẻ thế, thì khả năng cao nó sẽ khó để áp dụng
hơn)
tôi viết cái này cho các ông đang ngập mặt trong dự án - designer, developer, ông chỉ đạo sản xuất,
ông quản lý dự án, team marketing, và cả những người đầu tư, và cả những cá nhân xuất sắc 1 mình
 cân hết mọi đầu việc. Tính khả dụng không phải công trình cả đời của các bạn, và bạn không có thời
gian cho 1 bản hướng dẫn dài lê thê.
- Bạn không cần biết tuốt. Cũng giống như mọi lĩnh vực, có nhiều thứ bạn có thể học về Tính khả
dụng. Nhưng nếu bạn không phải là 1 chuyên gia về Tính khả dụng, thì cần phải có 1 giới hạn cho
những thứ bạn thấy đủ hữu ích để học. (Tôi luôn thích 1 trích đoạn trong cuốn “A study in scarlet"
(Cuộc điều tra màu đỏ) của Conan Doyle, khi bác sĩ Watson rất ngạc nhiên khi biết là Sherlock Holmes
không biết rằng Trái đất bay xung quanh Mặt trời. Dựa vào sức chứa có hạn của bộ não con người,
Holmes giải thích rằng, ông ta không chấp nhận có những sự thật vô ích trôi lổm nhổm xung quanh
những sự thật hữu ích: “Cái đó thì ảnh hưởng gì tới tôi? Ừ thì ông bảo là chúng ta xoay quanh Mặt trời
đi. Kể cả khi chúng ta xoay quanh Mặt trăng thì nó cũng chẳng ảnh hưởng gì tới tiền ăn sáng của tôi
hay công việc tôi làm)

Tôi thấy rằng những đóng góp có giá trị nhất mà tôi thực hiện cho mỗi dự án luôn xuất phát từ thực tế
là tôi chỉ giữ trong tâm trí một vài nguyên tắc chính về Tính khả dụng. Tôi nghĩ rằng có rất nhiều lợi ích
cho hầu hết mọi người trong việc hiểu các nguyên tắc này hơn là trong một list dài dằng dặc các
hướng dẫn “Nên" và “không nên" chi tiết. Tôi đã cố gắng cô đọng lại chỉ 1 vài điều mà tôi nghĩ những
người tham gia quá trình thiết kế nên biết về Tính khả dụng.

Những thứ không có trong cuốn sách này

Để các bạn khỏi tốn thời gian tìm, sau đây là những thứ sẽ không có trong cuốn sách này:
- Các quy tắc nhanh gọn và chắc cốp về Tính khả dụng.
Tôi ở trong ngành khá lâu, đủ lâu để biết rằng không có 1 câu trả lời “đúng” nhất định nào cả cho hầu
hết các câu hỏi liên quan tới Tính khả dụng. Thiết kế là một quá trình phức tạp và câu trả lời thực sự
cho hầu hết các câu hỏi mà mọi người hỏi tôi là “Còn tuỳ". Nhưng đúng là tôi nghĩ rằng có một vài
nguyên tắc hướng dẫn hữu ích cần lưu tâm, và những nguyên tắc đó chính những gì tôi cố gắng
truyền đạt qua cuốn sách này.
- Các dự đoán về tương lai của công nghệ và Web.
Thành thật mà nói, tôi mà đoán cũng chả khác gì bạn đoán đâu. Điều duy nhất tôi chắc chắn là (a) hầu
hết các dự đoán tôi nghe gần như chắc chắn là sai, và (b) những thứ sẽ quan trọng trong tương lai sẽ
đến từ những chỗ rất bất ngờ, mặc dù khi nhìn nhận lại thì chúng có vẻ hoàn toàn hiển nhiên.
- Nói xấu về các trang web và ứng dụng có thiết kế tệ.
Nếu bạn thích xem thiên hạ soi mói và chỉ ra những lỗi thiết kế rõ ràng, bạn đang đọc nhầm sách .
Thiết kế, xây dựng và duy trì một trang web hoặc ứng dụng ổn không dễ dàng chút nào. Nó giống như
chơi golf ấy: Rất ít cách để đẩy trái bóng golf vào lỗ, còn để đẩy bóng lọt ra ngoài thì nhiều vô kể. Bất
cứ ai chỉ cần làm đúng được 1 nửa thôi là tôi cũng nể lắm rồi.
Kết quả là, bạn sẽ thấy rằng các ví dụ tôi sử dụng trong cuốn sách có xu hướng đến từ các sản phẩm
tốt nhưng có 1 chút sạn. Tôi nghĩ bạn có thể học hỏi nhiều hơn từ việc nhìn vào các thiết kế tốt hơn là
các thiết kế cùi.

Giờ bàn tới Mobile!

Một trong những vấn đề nan giải mà tôi gặp phải khi cập nhật cuốn sách này là nó từ xưa tới nay vẫn luôn
luôn là một cuốn sách về thiết kế các TRANG WEB có thể sử dụng được. Mặc dù các nguyên tắc mà cuốn
sách nhắc tới có thể áp dụng cho việc thiết kế mọi thứ mà con người phải tương tác (bao gồm cả những thứ
như phiếu bầu cử và quầy bỏ phiếu, và thậm chí các bài thuyết trình PowerPoint), trọng tâm của nó rõ ràng là
về thiết kế Web và tất cả các ví dụ là từ các trang web trên mạng. Cho đến gần đây, đó là những gì mà hầu
hết chúng ta đang xây dựng và làm việc.
Nhưng hiện nay có rất nhiều người thiết kế Mobile app và thậm chí những người làm việc trên các trang Web
phải tạo ra các phiên bản có thể hoạt động tốt trên cả các thiết bị di động. Tôi biết họ sẽ rất quan tâm đến việc
tất cả những nguyên tắc trong cuốn sách này áp dụng với công việc của họ như thế nào.
Nên tôi đã làm 3 thứ:
- Thêm vào các ví dụ liên quan tới Mobile ở bất cứ chỗ nào có thể thêm được
- Thêm hẳn 1 chương mới về những vấn đề về Tính khả dụng dành riêng cho Mobile
- Và thứ quan trọng nhất: Thêm “cho Mobile” trên cái Phụ đề của trang bìa
Và như bạn thấy, ở những chỗ mà thêm được, thay vì “website”, tôi đã sửa thành “website hoặc mobile app".
Tất nhiên, trong hầu hết các trường hợp, tôi vẫn sử dụng các từ khoá tập trung vào Website để giữ mọi thứ
không bị cồng kềnh và rối rắm.

Thứ cuối cùng, trước khi chúng ta bắt đầu

Một điều rất quan trọng, thực sự là thế, đó là: Định nghĩa của bản thân tôi về Tính khả dụng.
Bạn sẽ thấy rất nhiều định nghĩa khác nhau về Tính khả dụng, thường được chia thành các thuộc tính như:
- Hữu ích: Nó có làm được thứ mà người dùng cần làm không?
- Dễ nắm bắt: Người dùng có thể tự mình tìm ra cách sử dụng nó không?
- Dễ nhớ: Họ có phải tìm tòi nghiên cứu lại mỗi lần họ sử dụng nó không?
- Hiệu quả: Nó có hoàn thành đúng mục tiêu nó được thiết kế để làm không?
- Hợp lý: Liệu nó có làm được điều đó trọng một lượng thời gian và effort phù hợp?
- Hấp dẫn: Người ta có thích nó không?
và gần đây thì thậm chí cả:
- Thú vị: Sử dụng nó có vui vẻ, tiện dụng không?

Tôi sẽ nói về những điều này sau. Nhưng với tôi, phần quan trọng của định nghĩa về Tính khả dụng là khá đơn
giản. Nếu một cái gì đó có thể sử dụng được, cho dù đó là một trang web, một cái điều khiển từ xa hay một cái
cửa xoay vòng thì điều đó có nghĩa là:
Một người có khả năng và kinh nghiệm trung bình (hoặc thậm chí dưới trung bình) có thể tìm ra cách
sử dụng thứ đó để hoàn thành thứ cần làm mà không gặp khó khăn vượt quá công sức học hỏi.
Hãy cứ tin tôi nhé: Nó thật sự đơn giản có vậy thôi.
Tôi hy vọng cuốn sách này sẽ giúp bạn xây dựng các sản phẩm 1 cách tốt hơn và dễ dàng hơn, và thậm chí
thỉnh thoảng có thể cho phép bạn về nhà ăn tối đúng giờ với vợ con, nếu nó giúp bạn giảm tải được những
cuộc tranh luận bất tận về thiết kế.
CÁC NGUYÊN TẮC CƠ BẢN
Chương 1. Đừng bắt tôi suy nghĩ
Định luật đầu tiên của Steve Krug về Tính khả dụng.

Anh Michael, tại sao cái màn lại được kéo lên?
Kay Corleone, phim Bố già, phần 2

Mọi người thường hỏi tôi:

“Điều gì là quan trọng nhất mà tôi nên làm để tạo ra một website hay mobile app dễ sử dụng?”

Câu trả lời rất đơn giản, không phải là “Những thứ quan trọng thì chỉ cần 2 lượt clicks là phải đạt được rồi”,
hoặc “Nói ngôn ngữ của người dùng” hoặc “Hãy đồng bộ trong thiết kế”. Mà đó chính là:

“Đừng bắt tôi suy nghĩ.”

Tôi đã bảo mọi người là đây là quy luật đầu tiên về Tính khả dụng của mình từ rất lâu rồi.
Nó là nguyên tắc áp đảo các nguyên tắc khác, là cán cân tối thượng khi bạn cần quyết định xem 1 bản thiết kế
có sử dụng được hay không. Nếu não bạn chỉ có chỗ cho duy nhất 1 nguyên tắc về Tính khả dụng, thì hãy
dành cho nguyên tắc này.
Ví dụ này, nó có ý nghĩa rất cơ bản thôi, đó là khi ta nhìn vào 1 cái Website, nó phải rõ ràng. Hiển nhiên. Mang
tính tự giải thích. Tôi có thể “hiểu” nó - biết nó là gì và cách nó vận hành ra sao - mà không cần phải suy nghĩ
về nó.
Thế ý tôi là phải rõ-ràng tới mức nào đây?
Ừ thì, rõ-ràng tới mức, ví dụ nhá, cô hàng xóm nhà bạn, người mà chả có tí kiến thức hay sở thích gì về cái
chủ đề của Sản phẩm của bạn, và cổ đã phải chật vật mới biết cách dùng nút Back, có thể nhìn vào cái
homepage của bạn và nói “À đây là cái _______” (Nếu may mắn hơn thì cổ sẽ nói “À đây là cái_______ mà.
Cái này xịn phết!” Nhưng cái này để sau bàn tới)
Nghĩ theo cách này:
Khi ta nhìn vào 1 sản phẩm không bắt ta phải suy nghĩ, những thứ trong đầu ta sẽ là những câu nói mang tính
trần thuật, kiểu như “OK, cái _____ nó đây rồi. cái ________ thì ở kia. Đây rồi cái tao tìm nó ở đây.”
Còn khi phải nhìn vào 1 sản phẩm mà bắt ta phải suy nghĩ, những thứ trong đầu ta sẽ là những câu hỏi,
những thắc mắc:

Và khi bạn đang thiết kế 1 sản phẩm, việc của bạn là loại bỏ càng nhiều câu hỏi càng tốt.

Những thứ khiến ta suy nghĩ

Trên 1 cái Website có đủ thứ có thể khiến chúng ta dừng lại và suy nghĩ 1 cách không cần thiết. Lấy ví dụ khi
ta đặt tên mọi thứ đi. Các nguyên nhân điển hình là những cái tên được đặt theo kiểu dễ thương hoặc hài
hước, tên có định hướng Marketing, tên dành riêng cho công ty, và những cái tên mang tính kĩ thuật lạ hoắc.
Ví dụ, giả sử một người bạn nói với tôi rằng XYZ Corp đang cần tuyển vị trí giống như của tôi, nên tôi thử qua
Website của họ nghía qua 1 cái xem sao. Khi tôi lướt qua Web xem có cái gì click được không, cái cách họ đặt
tên cho phần danh sách công việc tạo ra 1 sự khác biệt không hề nhỏ.
Lưu ý rằng những điều này luôn liên tục nằm ở đâu đó giữa “Rõ nghĩa với tất cả mọi người" và “Hoàn toàn mơ
hồ", và trường hợp nào cũng có sự đánh đổi.
Ví dụ, “Nhận việc" nghe có vẻ quá cứng nhắc với công ty XYZ, hoặc là họ buộc phải dùng “Bữa tiệc công
việc!” vì lý do cá nhân nội bộ nào đó trong công ty, hoặc đơn giản bởi vì cái cụm từ đó đã được dùng trong các
văn bản in ấn của công ty ngay từ đầu. (Thường thì sẽ luôn có 1 cách giải thích hợp lý, và 1 ý đồ tốt (nhưng bị
thực thi sai hướng) đằng sau mỗi vấn đề về Tính khả dụng). Ý chính mà tôi muốn nói, đó là cái việc Đánh đổi
đó nên được đẩy gần hơn về cái cán cân “Rõ nghĩa” như ảnh trên.
Một lượng thắc mắc không cần thiết khác nằm ở việc các link và nút chưa đủ rõ ràng để nhấp vào. Là một
người dùng, tôi không bao giờ muốn dành dù chỉ một phần nghìn giây để suy nghĩ xem cái của khỉ này có thể
nhấp vào được hay không.

Có thể bạn đang nghĩ, “Ừ thì nó cũng không quan trọng lắm. Nếu bạn nhấp hoặc nhấn vào nó và không có gì
xảy ra, thì cũng có sao đâu?”
Vấn đề là mỗi một thắc mắc đều làm tăng thêm khối lượng nhận thức mà chúng ta có trong tâm trí, qua đó làm
phân tán sự tập trung của ta khỏi thứ mà ta định làm. Những sự phân tâm này có thể nhỏ nhưng lại bị cộng
dồn vào, đặc biệt nếu đó là một thứ gì đó mà ta thường xuyên phải làm, ví dụ như quyết định xem mình sẽ
nhấp vào cái gì.
Luật bất thành văn, người ta không thích phải chật vật giải câu đố để làm 1 thứ gì đó. Họ thích giải câu đố
nhưng phải ở đúng hoàn cảnh, khi mà họ muốn được giải trí hoặc thách thức, không phải khi họ đang muốn
biết cái tiệm giặt sấy khô mấy giờ đóng cửa. Việc team dựng web không bận tâm để làm cho mọi thứ đơn giản
và dễ dàng, có thể làm tiêu hao đi niềm tin của người dùng vào trang web và đội ngũ phát triển nó.
Một ví dụ khác từ thao tác thông thường: Đặt vé máy bay
Cứ cho là những cái lảm nhảm này chỉ diễn ra trong 1 vài tích tắc thôi, nhưng bạn có thấy cái quá trình nó
phiền phức, với 1 mớ thắc mắc không? Và ở cuối còn có 1 cái lỗi khó hiểu nữa. Một trang web khác thì cho tôi
danh sách các lựa chọn thành phố rất hợp lý dựa trên những gì tôi nhập vào, nên thao tác trơn tru luôn.

Không thắc mắc, không lảm nhảm trong đầu, không lỗi gì hết.
Tôi có thể kể ra cả tá các thứ mà người dùng không cần phải nghĩ tới, như:
- Tôi đang ở đâu?
- Tôi nên bắt đầu từ đâu?
- Cái ______ nó ở đâu nhỉ?
- Thứ quan trọng nhất của cái page này là gì?
- Sao cái đó lại được đặt tên như vậy?
- Cái này là quảng cáo hay là 1 phần của trang web nhỉ?

Nhưng giờ bạn không cần thêm một cái checklist nữa, bạn đã có đủ nhiều checklist lquan tới design rồi. Điều
quan trọng nhất bạn có thể làm là hiểu được nguyên tắc cơ bản trong việc loại bỏ các câu hỏi/thắc mắc cho
người dùng khi họ sử dụng sản phẩm của bạn. Khi làm như vậy, bạn sẽ bắt đầu để ý đến tất cả những điều
khiến bạn phải suy nghĩ trong các trang web và ứng dụng bạn sử dụng. Và cuối cùng, bạn sẽ học được cách
nhận ra và tránh những thứ đó trong sản phẩm của mình.
Bạn không thể làm cho tất cả mọi thứ rõ ràng

Mục tiêu của bạn là làm cho mỗi page hoặc screen trở nên rõ ràng, tới mức chỉ cần nhìn vào nó, 1 Người dùng
Trung bình​ sẽ biết nó là gì và làm thế nào để sử dụng nó. Nói cách khác, họ sẽ hiểu nó mà không cần phải
suy nghĩ về nó. (bản thông tin về Người dùng Trung bình thực tế được lưu giữ trong một hầm kín tại Cục Tiêu
chuẩn quốc tế tại Geneva. Chúng ta sẽ bàn luận về cách tốt nhất để tái hiện và mô phỏng một Người dùng
Trung bình sớm thôi.

Tuy nhiên, đôi khi, đặc biệt là khi bạn làm một cái gì đó mới lạ hoặc mang tính đột phá hoặc vốn bản thân nó
đã phức tạp, bạn sẽ phải chấp nhận với phương án “Tự-giải thích" thay vì “Rõ ràng". Trên một trang web có
tính Tự giải thích, bạn chỉ cần suy nghĩ một chút là hiểu được cách nó hoạt động rồi. Yếu tố đồ hoạ của mọi
thứ (như kích thước, màu sắc và bố cục), các cái tên được chọn lọc kĩ lưỡng, những mẩu text nhỏ nhưng
được tinh chỉnh cẩn thận, etc.. tất cả các yếu tố này sẽ phối hợp với nhau để tạo ra 1 cảm giác dễ hiểu cho
trang web của bạn.
Quy tắc ở đây là: Nếu bạn không thể thiết kế ra 1 sản phẩm “Rõ ràng", ít nhất bạn cũng phải làm cho nó
“Tự-giải thích" được.

Tại sao những điều này lại quan trọng thế?

Lạ lùng là không phải vì cái lý do mà người ta thường nêu ra:

Đúng là cạnh tranh khốc liệt thật. Đặc biệt là trên nền tảng mobile, nơi mà có bạt ngàn các phương án ngon bổ
miễn phí khác cho chúng ta lựa chọn, và người dùng chẳng mất gì khi chuyển từ cái này sang cái khác.
Nhưng con người ta không phải lúc nào cũng dễ thay đổi như thế. Ví dụ:
- Có thể là vì họ không có cách nào khác ngoài bám lấy sản phẩm cũ, khi đó là sự lựa chọn duy nhất
(ví dụ: 1 hệ thống mạng nội bộ của công ty (trac,chatwork), hoặc 1 ứng dụng ngân hàng điện tử cố
định của công ty (Vietcombank), hoặc đó là cái chỗ duy nhất có bán cái thứ kì dị mà họ muốn mua)
- Bạn sẽ phải ngạc nhiên khi biết người ta có thể trụ lại với các website mà làm họ khó hiểu lâu tới mức
nào, thậm chí còn tự trách mình low tech thay vì trách cái website.
- Cũng tồn tại cái tâm lý “Đâm lao thì phải theo lao. Mình đã chật vật ở cái thao tác này 10’ rồi, thôi thì cố
mò thêm 1 chút cũng được".
Bên cạnh đó, ai bảo là cứ nhiều cạnh tranh thì sẽ khiến cho trải nghiệm người dùng đỡ khó hiểu hơn?

Thế thì tại vì cái gì?

Làm cho sản phẩm của bạn rõ ràng hơn giống như lắp đặt hệ thống ánh sáng tốt hơn trong 1 cửa hàng: nó chỉ
đơn thuần là làm cho mọi thứ có vẻ sáng sủa hơn. Thật tiện lợi và dễ dàng khi sử dụng một sản phẩm không
bắt chúng ta suy nghĩ về những thứ lặt vặt. Còn việc băn khoăn vật lộn với những thứ linh tinh không quan
trọng có xu hướng làm giảm năng lượng và sự nhiệt tình của chúng ta, và cả thời gian nữa.
Tuy nhiên, như bạn sẽ thấy trong chương tiếp theo, khi chúng ta kiểm tra cách người dùng sử dụng Web trên
thực tế ra sao, cái lý do tại sao việc giúp cho người dùng phải nghĩ càng ít càng tốt (hoặc không cần phải nghĩ
gì luôn) nó rất rất quan trọng, đó là việc phần lớn người dùng sẽ dành rất ít thời gian để lướt web, ít hơn
chúng ta tưởng tượng rất nhiều.
Kết quả là, để các trang web có thể đạt hiệu quả, thì chúng phải vận hành ngon nghẻ ngay từ những cái nhìn
đầu tiên. Và cách tốt nhất để đạt được điều này chính là tạo ra các trang web rõ ràng, hoặc ít nhất có thể
tự-giải thích.
Chương 2. Cách người dùng sử dụng trang Web trên
thực tế
Đọc lướt, Chấp nhận thoả hiệp, và Mò mẫm

Tại sao mọi thứ luôn nằm ở cái chỗ cuối cùng mà bạn tìm tới? Bởi vì khi
tìm ra nó rồi thì bạn còn tìm thêm làm cái gì nữa!
Câu đố cho trẻ con

Trên tất cả những lần tôi xem người ta sử dụng sản phẩm, thứ làm tôi chú ý nhất chính là sự khác biệt giữa
cách chúng ta nghĩ người dùng sẽ sử dụng Website và cách họ sử dụng Website trên thực tế.
Khi chúng ta tạo ra Website, ta hành động như thể mọi người sẽ xem từng trang một, đọc tất cả các đoạn text
được căn chỉnh cẩn thận, tìm ra cách ta tổ chức mọi thứ và cân nhắc các lựa chọn trước khi quyết định nhấp
vào 1 cái link nào.
Những gì họ thực sự làm (nếu chúng tôi may mắn) đó là lướt qua từng trang mới, đọc qua loa một số đoạn
text và nhấp vào cái link đầu tiên mà họ thấy hay hay hoặc giống giống với thứ họ cần. Lúc nào cũng sẽ có 1
phần to đùng của trang web mà họ thậm chí còn chả thèm để mắt tới.
Chúng ta đang coi sản phẩm của mình như những “tác phẩm Văn học điển tích" (hoặc ít nhất là “Sách hướng
dẫn sử dụng”), trong khi thực tế khách hàng nhìn vào sản phẩm của chúng ta như cái cách họ nhìn vào những
“biển quảng cáo trên đường khi phóng xe qua”.
Thực tế bạn có thể thấy nó sẽ phức tạp hơn thế này một chút, và nó phụ thuộc vào loại trang web, mục đích
của người dùng, liệu người dùng có đang vội hay không, v.v. Nhưng quan điểm đơn giản này lại gần với thực
tế hơn nhiều so với hầu hết những gì chúng ta tưởng tượng.
Khi thiết kế các trang web thì việc chúng ta hình dung 1 người dùng lý trí, có sự tập trung cao cũng là dễ hiểu
thôi. Việc ta cho rằng mọi người đều sử dụng Web giống như cách mình sử dụng Web cũng là lẽ tự nhiên, và -
giống như mọi người khác - chúng ta có xu hướng nghĩ rằng hành vi của chúng ta có quy tắc và tính hợp lý
cao hơn nhiều so với thực tế.
Tuy nhiên, nếu bạn muốn thiết kế các trang Web hiệu quả, bạn phải học cách chấp nhận 3 sự thật về việc sử
dụng Web trên thực tế.

Sự thật #1: Chúng ta không đọc các trang web, chúng ta chỉ lướt mắt qua chúng thôi (scanning)

Một trong số rất ít sự thật được ghi chép rõ ràng về việc sử dụng Web là: mọi người có xu hướng dành rất ít
thời gian để đọc các trang Web. Thay vào đó, họ đọc lướt qua (hoặc đọc quét qua) chúng, tìm kiếm các từ
hoặc cụm từ bắt mắt.
Tất nhiên, ngoại lệ là các trang Web có chứa các tài liệu như tin tức, báo cáo hoặc mô tả sản phẩm, nơi mọi
người sẽ phải đọc kĩ chúng - nhưng ngay cả khi đó, họ vẫn thường chuyển qua chuyển lại giữa 2 phương
pháp đọc (đọc kĩ và đọc lướt).
Tại sao chúng ta lại chỉ đọc lướt?

Vì ta thường đang có việc gì đó cần phải làm. Chúng ta sử dụng Web về cơ bản là để làm 1 cái gì
đó, theo 1 cách nhanh chóng. Kết quả là, người dùng Web có xu hướng hành động như những con cá mập:
Ta phải tiếp tục di chuyển, hoặc không thì sẽ thua. Chúng ta chỉ có thời gian để đọc vừa đủ mức cần thiết.
Vì ta biết chắc rằng mình không cần đọc tất cả mọi thứ. Trên hầu hết các trang Web, chúng ta
thực sự chỉ quan tâm đến một phần nhỏ thôi. Ta chỉ tìm kiếm các cụm thông tin có liên quan tới sở thích hoặc
thứ đang cần làm, nên phần còn lại của cả trang Web nó cũng chả liên quan. Đọc quét qua mọi thứ là cách
chúng ta tìm ra các cụm thông tin liên quan đó.

Vì ta đọc lướt rất giỏi. Nó là một kỹ năng cơ bản: Khi bạn học đọc, bạn cũng học cách đọc lướt luôn.
Chúng ta đã dành cả đời để đọc lướt đủ các thể loại báo, tạp chí và sách, hoặc nếu bạn ở độ tuổi dưới 25, có
lẽ là Reddit, Tumblr hoặc Facebook - để tìm những phần thông tin mà mình quan tâm đấy thôi.

Hiệu ứng này rất giống với phim hoạt hình Far Side kinh điển của Gary Larson, về sự khác biệt giữa những gì
chúng ta nói với mấy con chó và những gì chúng nghe thấy. Trong phim hoạt hình, chú chó (tên Ginger)
dường như đang chăm chú lắng nghe khi chủ nhân của nó nói 1 cách rất nghiêm túc về việc không được
nghịch rác. Nhưng từ quan điểm của chú chó, tất cả những gì người chủ nói chỉ là “ Blah Blah Blah Ginger
blah blah blah blah ​Ginger ​ Blah Blah Blah …”
Những gì chúng ta thấy khi nhìn vào một trang Web phụ thuộc vào những gì chúng ta đang nghĩ tới trong đầu,
và nó thường chỉ là một phần nhỏ của những gì trang Web đang chứa.
Giống như Ginger, chúng ta có xu hướng tập trung vào các từ và cụm từ nào có liên quan tới
(a) thứ chúng ta đang cần làm.
(b) sở thích cá nhân hiện tại của chúng ta.
Và tất nhiên, (c) các từ khóa đã in sâu vào hệ thống thần kinh của chúng ta, như là “Free”, “Sale”, “Sex”, etc..
và cả tên của chính chúng ta luôn.

Sự thật #2: Chúng ta không chọn phương án tối ưu, chúng ta chỉ chấp nhận thỏa hiệp vừa đủ.

Khi thiết kế trang web, ta thường cho rằng người dùng sẽ quét qua toàn bộ trang Web, xem xét tất cả các
phương án có sẵn và chọn cái nào tốt nhất.
Mặc dù vậy, trong thực tế, chúng ta chả bao giờ chọn phương án tốt nhất, thay vào đó ta chọn cái phương án
hợp lý đầu tiên mà ta nhìn thấy, đây một chiến lược được biết đến với cái tên “Thỏa hiệp vừa đủ”.
(Nhà Kinh tế học Herbert Simon đã nghĩ ra cái tên này trong cuốn sách Hình mẫu con người: Xã hội và Lý trí -
từ khóa này là sự kết hợp giữa từ thỏa mãn và từ đủ dùng )
Tôi đã quan sát hành vi này trong nhiều năm, nhưng tôi chỉ thực sự hiểu được tầm quan trọng của nó sau khi
tôi đọc cuốn “Ngọn nguồn sức mạnh: Cách chúng ta đưa ra quyết định” của Gary Klein.

Nhóm quan sát viên của Klein tiến hành nghiên cứu đầu tiên của họ (về các Đội trưởng đội cứu hỏa tại hiện
trường đám cháy) với mô hình đưa ra quyết định dựa trên logic thường được chấp nhận vào thời điểm đó: Khi
đối mặt với một vấn đề, một người sẽ tập hợp thông tin, xác định các giải pháp khả thi và chọn ra giải pháp tốt
nhất.
Nhóm nghiên cứu bắt đầu với giả thuyết rằng vì rủi ro cao và áp lực thời gian cực lớn, các Đội trưởng đội cứu
hỏa sẽ chỉ có thể so sánh hai lựa chọn, một giả định mà bản thân nhóm nghiên cứu cho là khá thuyền thống.
Hóa ra, các Đội trưởng đội cứu hỏa đã không so sánh bất kỳ giải pháp nào. Họ chọn cái giải pháp đầu tiên
xuất hiện trong đầu và tự kiểm tra các vấn đề phát sinh. Nếu không tìm thấy bất kỳ vấn đề nào, họ cứ thể triển
luôn kế hoạch hành động đó.
Vậy thì tại sao người dùng Web không tìm kiếm 1 sự lựa chọn tối ưu?
Vì ta lúc nào cũng đang vội. Như Klein chỉ ra, “Tối ưu là 1 việc khó làm, mất thời gian. Chấp nhận
thỏa hiệp với cái gì vừa đủ thôi nó tiện hơn nhiều”
Đoán sai cũng chẳng hại gì. Không giống như cứu hỏa, hình phạt cho việc đoán sai trên trang web
thường chỉ là 1-2 lần click nút Back, khiến cho việc thỏa hiệp vừa đủ là một chiến lược hiệu quả. (nút Back là
nút được sử dụng nhiều nhất trong các trình duyệt Web.)
Kể cả khi bạn có cân nhắc giữa các lựa chọn thì khả năng thành công là không cao. Trên các
trang web được thiết kế kém thì bạn có mất công tối ưu hóa lựa chọn của mình cũng chả có ý nghĩa gì. Thà
cứ đi đại 1 nước rồi Back lại nếu mà nhầm còn nhanh hơn.
Đoán vui hơn.​ Nó đỡ tốn công hơn là cân nhắc các phương án, và nếu bạn đoán đúng thì sẽ nhanh
hơn hẳn. Và nó bao gồm 1 yếu tố cơ hội - cái viễn cảnh thích thú của việc tình cờ tìm ra 1 cái gì đó bất ngờ và
hữu ích.

Tất nhiên, điều này không có nghĩa là người dùng không bao giờ cân nhắc các phương án trước khi họ click.
Nó phụ thuộc vào những thứ như luồng suy nghĩ, sự gấp rút khi cần làm cái gì đó và mức độ tự tin của họ vào
trang web đó.

Sự thật #3: Chúng ta không tìm hiểu cách mọi thứ vận hành. Chúng ta chỉ tự mò mẫm.

Một trong những điều mà bạn sẽ ngộ ra ngay khi bạn thực hiện bất kỳ cuộc Usability Testing nào - cho dù đó
là test các trang web, phần mềm hoặc thiết bị gia dụng - là cái tần suất vô tội vạ mà người ta thường sử dụng
mọi thứ mà không hiểu ( hoặc hiểu sai hoàn toàn ) cách chúng nó vận hành.
Khi gặp bất kỳ loại công nghệ nào, có rất ít người dành thời gian để đọc hướng dẫn. Thay vào đó, chúng ta cứ
tồ tồ đi tới và tự mò mẫm, tự phịa ra các giả thuyết có vẻ có lý (nhưng 1 cách mơ hồ) về cái mình đang làm và
tại sao cái mình làm lại đúng.
Làm tôi nhớ đến đoạn cuối của cuối sách Hoàng tử và gã ăn mày (Mark Twain), khi mà vị Hoàng tử thật phát
hiện ra rằng cái gã ăn xin giống y hệt mình kia đã sử dụng Dấu triện hoàng gia của Anh Quốc để làm 1 cái cục
đập hạt khi anh không ở đó. (Thì đúng là nó lại quá hợp lý với gã, cái con dấu kia suy cho cùng cũng chỉ là 1
cái cục kim loại to, nặng, cầm đầm tay)

Và thực tế là, cứ làm như thế lại xong việc. Tôi đã chứng kiến rất
nhiều người sử dụng phần mềm, trang web và sản phẩm tiêu
dùng một cách hiệu quả theo những hình thức hoàn toàn khác
biệt so với những gì mà các nhà thiết kế dự tính.
Lấy trình duyệt Web làm ví dụ - một phần quan trọng của việc sử
dụng Internet. Đối với những người xây dựng trang Web, nó là
một ứng dụng mà bạn sử dụng để xem các trang Web. Nhưng
nếu bạn hỏi người dùng trình duyệt là gì, phần lớn sẽ trả lời kiểu
như “Uh nó là cái mà tao dùng để search hoặc đọc cái gì đó”
hoặc “đó là công cụ tìm kiếm”. Hãy tự kiểm chứng: hỏi một số
người quen của bạn xem trình duyệt Web là gì. Bạn có thể ngạc
nhiên đấy.
Người ta sử dụng Web tràn lan mà không biết rằng họ đang sử dụng trình duyệt để xem trang web đó. Điều
họ biết là mình cứ gõ từ khóa vào thanh search rồi kết quả nó trả về. (Thường thì cái thanh search đó có chữ
Google bên cạnh. Rất nhiều người nghĩ Google chính là Internet) Nhưng điều đó có quan trọng gì, họ cứ tự
mò mẫm và sử dụng web ổn đó thôi.

Tại sao điều này lại xảy ra?

Vì nó không quan trọng với mình. Với phần lớn chúng ta, cũng chẳng quan trọng việc ta có hiểu
cách mọi thứ vận hành hay không, miễn là ta có thể sử dụng chúng như thường. Nó không phải là việc mình
thiếu trí thông minh, chỉ là mình không quan tâm thôi. Nó chả quan trọng với ta.
Vì nếu ta tìm được cách nào dùng được, ta sẽ dính với cách đó. Một khi ta tìm được cách sử dụng
nào khả thi, bất kể nó cùi ra sao - thường thì chúng ta sẽ không cố gắng tìm thêm cách khác nữa. Ta sẽ dùng
cách khác nếu tình cờ khám phá ra nó, còn thường thì hiếm khi ta chủ động tìm 1 cách mới.

Xem các nhà thiết kế và nhà phát triển sản phẩm quan sát cuộc Usability Testing đầu tiên của họ thực sự rất
giải trí. Lần đầu tiên, khi thấy một người dùng nhấp vào thứ gì đó hoàn toàn chả liên quan, họ bị shock thật sự.
(Ví dụ: khi người dùng bỏ qua cái nút Tải Phần mềm to đẹp bắt mắt trong thanh điều hướng, với suy nghĩ, “À,
tôi đang tìm phần mềm, vì vậy chắc tôi sẽ click vào cái phần “Hạ giá” vì kiểu gì chả có phần mềm trong mục
đó, rẻ được chả tốt hơn à” . Người dùng cuối cùng cũng sẽ tìm ra thứ họ muốn, nhưng tới lúc đó thì cái tổ
quan sát chả biết có vui nổi không nữa. Tới lần thứ 2 điều này xảy ra, họ phải gào lên bất lực “Cứ click vào nút
“Tải phần mềm” đi mà!”. Tới lần thứ 3, họ im lặng, bạn có thể thấy mặt họ viết rõ thông điệp “Thôi thế nào
cũng được, ai quan tâm đâu?”
Và đó là 1 câu hỏi tốt: Nếu người ta đã có thể tự mò mẫm nhiều tới vậy, thì việc “hiểu cách vận hành” có quan
trọng nữa không? Câu trả lời là nó vẫn rất quan trọng, vì kể cả khi tự mò mẫm cũng xong việc, thường thì nó
vẫn tốn nhiều thời gian và đầy lỗi.
Mặt khác, nếu người dùng “hiểu cách vận hành”:
- Họ sẽ tìm ra thứ họ cần nhanh chóng hơn nhiều, tiện cho cả 2 bên.
- Khả năng người dùng có thể hiểu toàn bộ những gì trang web của bạn cung cấp, không chỉ các phần
mà họ tình cờ mò ra là lớn hơn.
- Khả năng bạn có thể định hướng người dùng tới những khu vực mà bạn muốn họ nhìn thấy cao hơn.
- Người dùng sẽ cảm thấy thông minh hơn và có khả năng kiểm soát nhiều hơn khi họ sử dụng trang
web của bạn, điều này sẽ khiến họ trở lại dùng tiếp vào lần sau. Họ sẽ bỏ cái trang web cùi bắp, bắt
người ta tự mò mẫm của bạn để chuyển sang 1 trang web của người khác, nơi mà họ có thể cảm thấy
mình thông minh và high-tech, ngay và luôn.

Nếu đời ném gạch vào mặt bạn…

Đến bây giờ bạn có thể đang suy nghĩ (sau khi biết được thực tế phũ phàng của người dùng và cách họ sử
dụng trang Web): “Thế thì tao đi vào circle-K làm việc cho lành. Ít nhất thì ở đó nỗ lực của tao cũng được
người ta công nhận.”
Rồi xong sao nữa, ta phải làm chi?
Tôi nghĩ câu trả lời cũng đơn giản thoi: Nếu người dùng sử dụng web của bạn như là đang đọc biển hiệu
quảng cáo trên đường, thì bạn chỉ cần thiết kế cái biển quảng cáo đó sao cho đẹp thôi.
Chương 3. Nhập môn thiết kế biển quảng cáo
Thiết kế để đọc lướt, không phải đọc kĩ.

Nếu bạn / không biết / Biển hiệu này / của ta

Bạn chắc chắn / chưa đi quá xa / Kem cạo lông Burma!
Thứ tự biển hiệu quảng cáo bên lề đường, 1935, hãng Burma-shave.

Đối mặt với thực tế rằng người dùng của bạn sử dụng trang web vù vù như chạy giặc, có một số điều quan
trọng bạn có thể làm để đảm bảo họ sẽ nhìn thấy và hiểu được nhiều nhất có thể những gì họ cần biết và
những gì bạn muốn họ biết:
- Lợi dụng các tập quán chung.
- Tạo ra hệ thống phân cấp thị giác hiệu quả.
- Chia trang thành các khu vực chặt chẽ, có hệ thống.
- Làm cho những thứ click được phải thật rõ ràng.
- Loại bỏ các tác nhân gây phân tán.
- Định dạng nội dung sao cho phù hợp với việc đọc lướt.

Các tập quán chung là bạn tốt.

Một trong những cách tốt nhất để làm cho hầu hết mọi thứ được hiểu nhanh hơn, dễ dàng hơn là tuân theo
các tập quán có sẵn, các khuôn mẫu thiết kế được sử dụng rộng rãi và chuẩn hóa. Ví dụ:
- Biển báo Dừng lại. Tất nhiên tài xế phải nhìn thấy và nhận ra biển báo Dừng lại ngay tức thì, ở 1
khoảng cách xa cũng nhìn ra, trong mọi điều kiện thời tiết và ánh sáng,... nên việc các biển báo Dừng
lại phải trông giống nhau là rất quan trọng. (Một số chi tiết cụ thể của biển báo có thể khác nhau tùy
theo từng quốc gia, nhưng nhìn chung chúng có độ tương đồng khá lớn trên toàn thế giới.)

Tập quán này bao gồm 1 hình khối rõ ràng, 1 chữ cơ bản mang ý nghĩa “Stop”, 1 màu nổi bật và có độ
tương phản tốt với thiên nhiên xung quanh, và ở 1 vị trí, chiều cao, kích cỡ theo tiêu chuẩn.
 - Hệ thống điều khiển xe hơi. Tưởng tượng phải đi 1 chiếc xe thuê mà cái chân ga không được đặt ở
bên phải của chân phanh, hoặc còi không được đặt trên bánh lái.

Trong vòng 20 năm trở lại đây, 1 vài tập quán chung trên các trang Web đã thay đổi. Là người dùng Internet,
chúng ta ít nhiều sẽ hình thành tập quán chung về những thứ như:
- Cái gì nằm ở đâu trên 1 trang web. Ví dụ, người dùng sẽ hình dung cái logo của website thường nằm
ở top-left (ít nhất là ở những nước mà người ta đọc từ trái qua phải) và cái cụm điều hướng cũng sẽ
nằm ở top, nhưng là ở phía bên còn lại.
- Cách mọi thứ hoạt động. Ví dụ, hầu hết các trang web thương mại điện tử đều có dùng biểu tượng
cái xe đẩy (shopping cart) và 1 chuỗi những biểu tượng quen thuộc khác để đại diện cho những thứ
như cách thanh toán, địa chỉ nhận hàng, etc..
- Hình thức đồ họa của mọi thứ. Nhiều thứ trên 1 trang web có giao diện được tiêu chuẩn hóa, như cái
icon mà bạn nhìn cái là biết nó sẽ link tới 1 cái video, cái icon tìm kiếm có hình kính lúp, và icon tùy
chọn chia sẻ lên các trang mạng xã hội.

Các tập quán chung cũng đã phát triển cho các loại trang web khác nhau - Thương mại, trường đại học, blog,
nhà hàng, phim ảnh và nhiều hơn nữa - vì tất cả các trang web trong mỗi ngành đều phải giải quyết cùng một
chuỗi các vấn đề.
Những tập quán này không phải tự nhiên mà có: Tất cả đều là những ý tưởng tốt của ai đó. Nếu một ý tưởng
đủ hay và thực tiễn, các trang web khác sẽ bắt chước ý tưởng đó và cuối cùng người ta sẽ nhìn thấy nó nhiều
lần ở nhiều chỗ tới mức nó không cần giải thích nữa.
Khi được áp dụng đúng cách, các tập quán chung giúp người dùng sử dụng web dễ dàng hơn, vì họ không
cần phải liên tục tìm hiểu xem mọi thứ là gì và cách chúng nó vận hành ra sao, khi họ đi từ trang web này tới
trang web khác.

Bạn cần bằng chứng về việc các tập quán chung này đắc lực như nào không? Nhìn cái trang web này xem
bạn có hiểu nó là cái gì không - kể cả khi tiếng Nhật bạn 1 chữ bẻ đôi không biết - tất cả là nhờ trang web đó
được thiết kế theo các tập quán đã có sẵn.

Tuy nhiên, có một vấn đề với các tập quán chung: Mấy ông designer hay ngại dùng cái này.
Khi chuẩn bị phải tuân theo một tập quán chung nào đó, các designers thường sẽ có mong muốn mãnh liệt
cho việc tạo ra 1 thứ gì đó mới, phần lớn là bởi vì họ tin rằng (niềm tin này không hề sai trái đâu nhé) họ được
thuê để sáng tạo và làm thứ khác biệt, chứ không phải đi theo lối mòn. Chưa nói tới việc những lời khen ngợi
từ đồng nghiệp, các giải thưởng về thiết kế, và các job offer ngon nghẻ hiếm khi dựa trên các tiêu chí như “sử
dụng tập quán chung 1 cách thuần thục” / “đi đúng lối mòn”.

Thi thoảng, dành thời gian để phát minh lại mô hình bánh xe cũng cho ra được 1 thiết bị lăn lăn mới mang tính
cách mạng. Nhưng trong phần lớn các trường hợp còn lại thì nó chả đem lại điều gì mới.
Nếu bạn định đổi mới, trước tiên bạn phải hiểu giá trị của những gì bạn đang thay thế (hoặc lời bài hát của
Bob Dylan: “Để sống được ngoài vòng pháp luật, bạn phải trung thực”) và thật dễ dàng để coi nhẹ các giá trị
mà tập quán chung mang lại. Ví dụ điển hình là Scroll bar. Bất cứ khi nào một ông designer nào đó quyết định
tạo ra 1 kiểu scroll bar mới lạ - thường để cho nó nhìn đẹp hơn - kết quả luôn chỉ ra rõ ràng cái sự thật rằng
ông designer đó chả bao giờ biết được sự phát triển của hệ thống scroll bar tiêu chuẩn ngày nay đã bao gồm
hàng trăm ngàn giờ nghiên cứu và tinh chỉnh trước đó.

Nếu bạn không sử dụng một tập quán chung khi thiết kế web hiện có, bạn cần chắc chắn rằng những gì bạn
đang tạo ra cần phải
(a) hoạt động tốt y như các tập quán chung có sẵn, nghĩa là nó phải rất rõ ràng và mang tính tự giải thích, tới
mức không mất thời gian công sức để học cách dùng nó
hoặc
(b) bổ sung thêm nhiều giá trị cho sản phẩm tới mức nó đáng để bỏ 1 chút thời gian công sức để học cách sử
dụng.

Lời khuyên của tôi là: Đổi mới khi bạn biết chắc ý tưởng của bạn là tốt hơn, còn không thì cứ tận dụng các tập
quán chung.
Đừng hiểu nhầm tôi nhé: Tôi không bao giờ cố gắng ngăn cản sự sáng tạo. Tôi thực sự thích các bản thiết kế
Web sáng tạo và độc đáo. Một trong các ví dụ ưa thích của tôi là Harlem.org. Cả trang web đó được xây dựng
với tấm ảnh nổi tiếng của Art Kane về 57 nghệ sĩ Jazz, chụp ở Harlem vào tháng 8 năm 1957. Thay vì sử
dụng text links hay menu, bạn có thể điều hướng và tìm kiếm ngay trong bức ảnh.
Cái này không chỉ thú vị và sáng tạo, nó còn rất dễ hiểu và dễ sử dụng. Người thiết kế website còn đủ thông
minh để hiểu rằng cái phương pháp này dùng 1 hồi sẽ chán, nên họ cũng thêm vào 1 định dạng điều hướng
theo đầu mục (category) kiểu truyền thống: Bạn có thể tìm kiếm thông tin về các nhạc sĩ Jazz theo tên, nhạc
cụ, và phong cách chơi nhạc của họ.

Nguyên tắc cơ bản là: Bạn có thể - và bạn nên - sáng tạo và đổi mới kiểu gì cũng được, làm cho sản phẩm
lung linh hấp dẫn và có thẩm mỹ ra sao cũng được, miễn là bạn đảm bảo rằng nó vẫn có thể sử dụng được.
Và lời cuối cùng về tính đồng nhất.
Bạn thường hay nghe ‘tính đồng nhất’ dưới 1 quan điểm tính cực. Chúng ta thường thuyết phục được khách
hàng chỉ bằng việc nêu ra: “nếu làm thế sẽ không đồng nhất”.
Tính đồng nhất luôn là 1 tiêu chuẩn phù hợp mà bạn cần phải mang lại cho sản phẩm của mình. Nếu hệ thống
điều hướng của bạn lúc nào cũng ở 1 vị trí, thì tôi không cần phải suy nghĩ về nó hoặc mất thời gian tìm xem
nó ở đâu. Nhưng cũng sẽ có các trường hợp đặc biệt, khi mà sản phẩm sẽ rõ ràng hơn nếu bạn làm cho nó
khác biệt đi 1 chút, 1 cách có chủ ý.
Đây là thứ bạn cần ghi nhớ:
SỰ RÕ RÀNG QUAN TRỌNG HƠN SỰ ĐỒNG NHẤT

Nếu bạn có thể làm cho thứ gì đó rõ ràng hơn hẳn bằng cách khiến cho nó khác biệt đi 1 chút (1 chút thôi
nhé), hãy làm như vậy đi.

Tạo ra hệ thống phân cấp thị giác hiệu quả.

Một cách quan trọng khác để làm cho sản phẩm của bạn dễ nắm bắt trong thời gian ngắn là đảm bảo mọi thứ
trên trang web - tất cả các yếu tố của 1 giao diện - diễn đạt 1 cách chính xác sự tương quan giữa các yếu tố
đó: cái nào là quan trọng nhất, cái nào có vai trò giống nhau, cái nào nằm ở bên trong cái nào. Nói cách khác,
mỗi trang web cần có 1 hệ thống phân cấp thị giác thật rõ ràng.

Cái gì càng quan trọng thì phải càng nổi bật. Các yếu tố quan trọng nhất thường sẽ to hơn, đậm
hơn, có màu sắc nổi bật hơn, có nhiều khoảng trống xung quanh hơn, hoặc ở gần đầu trang hơn - có thể là
kết hợp của các yếu tố trên.
 Cái gì có liên kết về mặt logic, phải được liên kết về mặt bố cục. Ví dụ, bạn có thể chỉ ra rằng
những cái này có liên kết với nhau / giống nhau, bằng cách nhóm chúng nó vào cùng dưới 1 cái tiêu đề, hoặc
cho chúng nó có cùng 1 style, hoặc đặt cả mớ vào 1 khung rõ ràng, tách biệt so với phần còn lại.

Cái gì được xếp gần nhau sẽ cùng thuộc một cái gì đó rộng hơn. Ví dụ, 1 mục có tên “Sách về
máy tính” sẽ xuất hiện bên trên 1 dãy tựa đề từng cuốn sách riêng lẻ, cho ta biết rằng các cuốn sách đó thuộc
về mục đó. Và mỗi tựa đề sách sẽ bao gồm tất cả những thứ cấu thành nên cuốn sách đó.
Cũng chả có gì mới về hệ thống phân cấp thị giác cả. Nhìn tất cả các trang báo mà xem. Trang nào cũng dùng
các phương pháp làm nổi bật, xếp nhóm, tạo cụm thông tin, để đưa ra cho người đọc những định hình cơ bản
về nội dung các trang báo mà không cần họ phải đọc lấy 1 chữ. Cái ảnh này đi liền với câu chuyện này, vì
chúng nó cùng thuộc chiều dài với cái tiêu đề này. Bài viết này là quan trọng nhất, vì tiêu đề của nó to nhất và
nó nằm ở 1 vị trí nổi bật trên trang báo.

Tất cả chúng ta đều phân tích thứ bậc thị giác mỗi ngày, nhưng nó xảy ra nhanh đến mức chỉ khi nào chúng ta
không thể phân cấp thông tin được thì mới nhận ra là mình đang làm điều đó - chính là khi các gợi ý về thị
giác (hoặc là do sự sắp xếp bất hợp lý của chúng) bắt chúng ta phải nghĩ.

Một hệ thống phân cấp trực giác tốt giúp chúng tôi tiết kiệm công việc bằng cách xử lý trước trang cho chúng
tôi, sắp xếp và ưu tiên nội dung của nó theo cách mà chúng tôi có thể nắm bắt gần như ngay lập tức.

Nhưng khi trang web không có 1 hệ thống phân tích thứ bậc thị giác rõ ràng - nếu cái gì trông cũng quan trọng
như nhau - chúng ta buộc phải quay lại quy trình đọc lướt trang web để tìm các từ khóa quan trọng, và tự hình
thành nên suy luận về cách mọi thứ được sắp xếp và ưu tiên. Quy trình này mất công sức hơn khá nhiều.

Đọc 1 trang web với hệ thống phân cấp thị giác mà chỉ hơi lỗi lỗi thôi - chỉ cần cái tiêu đề bài báo trải dài hơn
phần nội dung của nó, sang cả nội dung bài viết khác thôi - cũng gây khó chịu y như khi ta đọc 1 câu văn lủng
củng vậy.
Hệ thống phân cấp thị giác cùi bắp này thể hiện rằng mọi đầu mục của trang web đều thuộc về khu vực “Sách
về máy tính”.

Đặt lại tiêu đề ở đúng vị trí của nó khiến cho sự tương quan về thông tin rõ ràng hơn.

Kể cả khi chúng ta vẫn có khả năng hiểu đúng ý của trang web, việc này vẫn đẩy người dùng vào 1 trạng thái
băn khoăn nho nhỏ, và buộc họ phải suy nghĩ khi không cần thiết.
Chia trang thành các khu vực chặt chẽ, có hệ thống.

Lý tưởng nhất, trên bất kỳ trang web nào được thiết kế tốt, người dùng có thể chơi một biến thể nho nhỏ của
chương trình trò chơi truyền hình của Mỹ thời xưa ( Kim tự tháp 25.000 đô la - người chơi phải đưa ra các gợi
ý về cùng 1 chủ đề để cho người kia đoán. Ví dụ, nếu các gợi ý là “dao thái thịt”, “nồi niêu xoong chảo”, “gia
vị”. etc… thì chủ đề sẽ là “Dụng cụ đầu bếp”).
Liếc nhìn xung quanh trang web, người dùng có thể chỉ vào các khu vực khác nhau của trang và bảo “Đây là
những thứ mình có thể làm được trên trang web này!” “Đây là các bài viết lên top trong ngày hôm nay!” “Đây
chính sản phẩm công ty này bán ra.” “Đây là những thứ chúng nó muốn mình mua! “Đây là hệ thống điều
hướng giúp mình lướt tiếp phần còn lại của trang web mà không bị lạc!”

Việc chia trang thành các khu vực được xác định rõ ràng là rất quan trọng, vì nó cho phép người dùng quyết
định nhanh chóng khu vực nào của trang để tập trung vào và khu vực nào họ có thể bỏ qua một cách an toàn.
Các nghiên cứu về hành vi di chuyển của mắt người dùng khi họ lướt qua trang web cho thấy rằng: người
dùng chỉ cần lướt mắt qua 1 chút là đã có thể quyết định nhanh chóng xem phần nào chứa thông tin hữu ích,
và họ gần như không nhìn các phần còn lại, kiểu như các phần đó không tồn tại luôn vậy. (Cái này gọi là
Banner blindness - dùng để nói về khả năng bỏ qua hoàn toàn các khu vực trên trang web mà người dùng
nghĩ là quảng cáo)
Làm cho những thứ click được phải thật rõ ràng.

Vì người dùng khi lướt website hầu như chỉ có đúng 1 thứ để làm, đó là tìm coi mình có thể click vào phần nào
nữa, nên việc làm cho những thứ click được trở nên rõ ràng hơn là rất quan trọng.
Khi chúng ta xem một website, ta sẽ để ý nhiều kiểu gợi ý về mặt thị giác, thứ sẽ giúp ta xác định những thứ
có thể click vào (hoặc gõ vào được, với trường hợp màn hình cảm ứng). Những thứ như shape (nút, tab,
etc..), vị trí (trong thanh menu, etc..) và định dạng (màu text, gạch chân hoặc cả 2, etc..). Chúng ta cũng dựa
vào thực tế là con trỏ trong trình duyệt Web sẽ thay đổi từ hình mũi tên sang hình con trỏ ngón tay khi bạn
lướt chuột vào 1 thứ gì đó click vào được, nhưng điều này đòi hỏi người dùng phải di chuyển con trỏ chuột
xung quanh 1 cách có nhận thức, và đây là một quá trình tương đối chậm. Ngoài ra cách này cũng không hoạt
động trên màn hình cảm ứng vì nó không có con trỏ chuột.

Quá trình tìm kiếm các gợi ý sử dụng dựa trên ngoại hình của 1 thứ gì đó không giới hạn ở mỗi các trang
Web. Như Don Norman giải thích 1 cách đầy thú vị trong tác phẩm kinh điển mới được cập nhật gần đây của
ông “The Design of everyday things”, chúng ta thường xuyên phân tích hoàn cảnh và môi trường (như nhìn
vào cái tay cầm mở cửa) để tìm ra các gợi ý này (phân tích để quyết định xem cái tay cầm này nên kéo hay
đẩy). Đọc cuốn này đi. Bạn sẽ nhìn vào mấy cánh cửa 1 cách khác hẳn luôn.
Việc xác định xem cái gì click vào được trên 1 trang web vốn đã là 1 vấn đề lúc nổi lúc chìm từ khi những
trang web đầu tiên được thiết kế.

Tuy nhiên, hiện tại, vấn đề này lại nổi lên trong thiết kế di động, như bạn sẽ thấy trong Chương 10​.
Nói chung, bạn sẽ ổn thôi - nếu bạn giữ một màu đồng nhất cho tất cả các text link và button, hoặc đảm bảo
rằng hình dạng và vị trí của chúng nó được thể hiện rõ ràng rằng “cái này có thể click được, mời bà con vào
click”. Đừng phạm những sai lầm ngớ ngẩn như để text link và tiêu đề (không click dc) cùng 1 màu là được.

Loại bỏ các tác nhân gây phân tán.

Một trong những kẻ thù lớn nhất của các trang web được thiết kế theo kiểu dễ nắm bắt, đó là sự nhiễu loạn về
hình ảnh. Người dùng có mức độ chấp nhận khác nhau với sự phức tạp và phân tán; một số người không có
vấn đề gì với các trang web nhiều thông tin, nhưng rất nhiều người thấy mấy trang kiểu này hết sức khó chịu.
Có người còn thử dán giấy nhớ trên màn hình của họ để che đi các animation hay các hình ảnh động mà
khiến họ mất tập trung khi lướt web.
Thường có 3 kiểu nhiễu loạn về hình ảnh:

Nhiễu loạn vô-duyên. Khi mà cái gì trên trang web đó cũng gào lên bắt bạn phải chú ý tới nó, hiệu
ứng sẽ có thể rất quá đà. Nhìn đâu cũng thấy cực nhiều lời mời gọi mua sắm! Nhiều câu slogan giật gân,
nhiều kiểu font chữ, màu sắc sáng chói! Banner dạng chuyển động cầu kì, pop-up quảng cáo hiện lên ‘tinh
tinh!’ 1 phát, và còn 1 tỉ kiểu quảng cáo ồn áo khác để thu hút sự chú ý của người dùng.
Sự thật là, không phải cái gì cũng quan trọng được. Kiểu nhiễu loạn này thường là kết quả của sự thất bại
trong việc đưa ra các quyết định về phân cấp ưu tiên cho các yếu tố thị giác.
 Nhiễu loạn vô-tổ-chức. Có 1 vài trang web trông như thể 1 căn phòng vừa bị trộm, đồ đạc ngổn
ngang khắp mọi nơi. Nhìn phát là biết ông designer không hiểu được tầm quan trọng của việc dùng Grid để
căn chỉnh trong thiết kế sản phẩm.

Nhiễu loạn vô-biên. Chúng ta đều đã nhìn thấy các website - đặc biệt là Homepage - mà có quá nhiều
thứ trên đó. Hiệu ứng này cũng giống với khi cái hòm thư email của bạn bị ngập trong mớ newsletter từ các
trang web linh tinh: Rất khó để tìm ra những tin nhắn mà bạn muốn đọc. Cuối cùng bạn sẽ bị rơi vào hoàn
cảnh mà dân kĩ sư hay gọi là ‘Tỉ lệ tín hiệu trên nhiễu thấp’: Quá nhiều thứ khiến ta bị phân tán, và thông tin
hữu ích bị sự tràn lan này che khuất mất.
Khi bạn thiết kế 1 trang web, tốt nhất là cứ ghi nhớ trong đầu rằng ‘tất cả mọi thứ là sự phân tán’ (cách tiếp
cận nổi tiếng “có tội cho tới khi dc chứng minh vô tội”) và loại bỏ đi mọi thứ không cần thiết. Trong bối cảnh
thời gian và sự chú ý của người dùng là rất hữu hạn, tất cả mọi thứ không liên quan tới giải pháp và mục tiêu
chính của sản phẩm sẽ bị đào thải.

Định dạng nội dung sao cho phù hợp với việc đọc lướt.

Phần lớn thời gian người dùng vào trang web của bạn chỉ để lướt qua xem có thứ mà họ cần tìm không.
Vậy nên cách mà nội dung text của bạn được sắp xếp sẽ khiến cho việc đọc lướt của họ đơn giản hơn nhiều.

Bạn thích đọc cái nào hơn?

Sau đây là những thứ bạn nên làm để khiến cho sản phẩm của mình dễ đọc lướt:

Sử dụng nhiều tiêu đề. Các tiêu đề được viết cẩn thận, chu đáo xen kẽ trong nội dung text có tác
dụng như một bản mục lục / tóm tắt về nội dung của toàn bộ trang web. Nó cho bạn biết mỗi phần nói về điều
gì, hoặc nếu các tiêu đề có hơi vắn tắt trừu tượng, thì ít nhất nó cũng khiến bạn tò mò. Kiểu gì thì kiểu, nó
cũng giúp bạn quyết định xem mình nên đọc, đọc lướt, hay bỏ qua.
Nói chung, bạn nên sử dụng nhiều tiêu đề hơn và đầu tư thời gian công sức để tạo ra chúng.
Ngoài ra, hãy chú ý đặt định dạng tiêu đề cho hợp lý. Có 2 thứ rất quan trọng về style của tiêu đề mà người ta
thường bỏ qua:
Nếu bạn sử dụng nhiều hơn một mức tiêu đề, hãy chắc chắn rằng giữa 2 thằng tiêu đề chính và tiêu đề phụ có
một sự khác biệt rõ ràng, không thể không nhận ra. Bạn có thể làm điều này bằng cách chỉnh kích thước theo
mức độ tiêu đề, hoặc chỉnh kiểu font chữ.

Quan trọng hơn nữa: Đừng để tiêu đề của bạn lơ lửng giữa 2 body text khác nhau. Hãy đảm bảo là tiêu đề
của nội dung nào thì gần với nội dung đó, thay vì gần với nội dung trước đó. Sự khác biệt này là rất lớn.
 Giữ văn bản ngắn gọn vừa phải. Người đọc coi những đoạn text dài ngoằng là - theo cách gọi của
Caroline Jarrett và Ginny Redish - một bức tường chữ. Chúng nó nhìn mà phát nản, làm trải nghiệm đọc của
người dùng trở nên khó khăn hơn và khó tiếp thu thông tin hơn.
Có thể ngày xưa đi học bạn được dạy là mỗi đoạn văn cần phải có mở đoạn, thân đoạn, kết đoạn, các kiểu đà
điểu, nhưng đọc thông tin trên mạng lại khác. Kể cả những đoạn text chỉ có 1-2 câu thôi cũng chả sao.
Nếu bạn check thử 1 đoạn văn dài nào đó, thường bạn sẽ thấy đoạn văn đó hoàn toàn có thể tách ra làm
nhiều phần nhỏ được. Hãy quen với việc tách nhỏ các đoạn văn dài.

Sử dụng các bullets (gạch đầu dòng). Cứ ghi nhớ thế này này: Cái gì mà tách ra thành cách gạch
đầu dòng được thì cứ tách. Cứ check các đoạn văn của bạn xem có chuỗi nội dung thông tin nào được phân
tách bởi dấu phẩy hoặc chấm phẩy, là bạn sẽ tìm ra ngay mấy ông ứng viên tiềm năng để chuyển thành gạch
đầu dòng.
Và để người dùng dễ đọc hơn nữa, nên có spacing đàng hoàng giữa mỗi gạch đầu dòng.

Làm nổi bật các từ khóa chính. Phần lớn công đoạn đọc lướt trang web chính là việc tìm ra keyword
và cụm từ khóa chính.
Những keyword quan trọng nhất thì chuyển hết sang bold - điều đơn giản này giúp cho người dùng dễ nhận ra
chúng hơn nhiều (còn nếu bản thân keyword đã là text link rồi thì rõ ràng là không cần nữa). Nhưng đừng
highlight quá nhiều thứ, nếu bạn không muốn mánh này mất đi hiệu quả.
Nếu bạn thực sự muốn tìm hiểu về cách tạo ra nội dung trang web dễ đọc, dễ lướt (hoặc là tạo ra bất kỳ thứ gì
liên quan đến viết nội dung cho màn hình nói chung), hãy nhấc ngay cái mông lên và đặt mua cuốn sách
“Letting Go of the Words.” của Ginny Redish, ngay và luôn đi.
Tiện thể thì, đặt mua luôn 1 cuốn cho những người bạn đang làm editor, content writer của bạn, hoặc bất cứ ai
đang có công việc viết lách content trên mạng. Họ sẽ mang ơn bạn cả đời.
Chương 4. Động vật, Thực vật, hay Khoáng chất?
Tại sao người dùng lại thích những phương án vô não?

“Chẳng quan trọng ta phải click bao nhiêu lần, miễn là mỗi lần click là 1
sự lựa chọn rõ ràng, không cần suy nghĩ"
Định luật thứ 2 của Steve Krug về Tính khả dụng.

Mấy ông Web designer và các chuyên gia về UX đã dành hàng năm trời để tranh luận về số lần tối đa người
dùng có thể click (hoặc tap) để đạt được mục tiêu mà không bỏ cuộc. Một số trang web thậm chí còn có các
quy tắc thiết kế - quy định về số lượng click/tap tối đa (thường là ba, bốn hoặc năm) để truy cập bất kỳ phần
nào trong trang web đó.
Về mặt bề nổi, số lần click/tap để đạt được mục tiêu có vẻ như là một phương pháp đo lường hiệu quả.
Nhưng theo thời gian, tôi phát hiện ra rằng điều quan trọng không phải là bao nhiêu lần click/tap mình phải làm
để thực hiện 1 task nào đó (mặc dù đúng là nên có giới hạn), mà là mỗi lần click/tap của mình khó khăn tới
mức nào - lượng công sức bỏ ra để cân nhắc giữa quyết định đúng-sai có nhiều hay không.
Nhìn chung, tôi có thể tự tin nói rằng: người dùng không ngại việc phải click nhiều, miễn là mỗi click đều rõ
ràng và không có rủi ro, và họ cảm thấy tự tin rằng họ đang đi đúng hướng - bám theo thứ thường được
gọi là “mùi thông tin" (Định nghĩa này tới từ bài nghiên cứu “Săn lùng thông tin" của Peter Pirolli and Stuart
Card, trong đó họ chỉ ra sự tương đồng giữa những người đang tìm thông tin (informavores) và động vật lần
theo con mồi). “Mùi thông tin” thường nằm ở những cái link mà người dùng có thể nhìn phát là biết “đây đúng
là thứ mình tìm" khiến cho họ yên tâm mà click/tap vào, tin rằng việc này sẽ đưa họ gần hơn tới việc hoàn
thành mục tiêu. Những link với từ khoá mơ hồ sẽ không làm được điều này.

Tôi nghĩ quy luật cơ bản có thể là cái gì đó tương tự như “3 lần click rõ ràng, không cần suy nghĩ bằng với 1
lần click phải cân đo đong đếm”. (Tất nhiên cũng tồn tại các ngoại lệ. Ví dụ, nếu tôi phải làm đi làm lại 1 task,
hoặc nếu trang web mất nhiều thời gian để load, thì việc có ít lần click hơn rõ ràng sẽ khiến trải nghiệm người
dùng tốt hơn)
Câu hỏi mở đầu kinh điển trong trò chơi đoán chữ ‘20 Câu hỏi’: “Động vật, Thực vật hay Khoáng chất?” - chính
là 1 ví dụ tuyệt vời của 1 trường hợp chọn mà không cần suy nghĩ. Miễn là bạn chấp nhận tiền đề rằng bất cứ
thứ gì mà không phải là thực vật hay động vật - bao gồm cả những thứ đa dạng như đàn piano, đá cuội hay kể
cả bánh kem, sẽ được liệt vào danh mục ‘khoáng sản’, thì bạn gần như không phải suy nghĩ chút nào để trả
lời các câu hỏi đố. (Nếu bạn chưa bao giờ thử trò chơi này, bạn có thể chơi thử 1 phiên bản xuất sắc của
game này trên website ​www.20q.net​ . Tạo ra bởi Robin Burgener, trang web này dùng 1 dạng thuật toán mạng
thần kinh để đoán ra ý đồ người chơi, khiến cho game thật sự rất thú vị)
Đáng tiếc thay, những sự lựa chọn trên Website chẳng bao giờ được rõ ràng như vậy.
Ví dụ, 1 vài năm trở lại đây khi tôi muốn mua 1 sản phẩm văn phòng để dùng tại nhà (như 1 chiếc máy in
chẳng hạn) phần lớn các trang web trên mạng bắt tôi đứng giữa 2 lựa chọn căn bản như sau

Tôi sẽ thuộc về phần nào? Tôi đã phải nghĩ kha khá ở bước này, và kể cả khi tôi đã chọn 1 cái rồi, tôi vẫn
không hoàn toàn chắc chắn rằng mình đã chọn đúng.
Nó cũng giống như cái lúc tôi đứng trước 2 cái hòm thư, 1 cái tên là “Thư đóng tem", cái còn lại tên là “Thư
đóng tem bằng máy”, tay cầm 1 cái thiệp văn phòng. Làm sao tôi biết cái của khỉ này nó là đóng tem hay đóng
tem bằng máy? Nếu tôi bỏ nhầm hòm thì sao?

Đây là 1 ví dụ khác nữa:

Tôi đang đọc bsao online. Cái trang web này cho tôi 1 mớ các options khác nhau

Bây giờ tôi lại phải đọc lướt hết tất cả mớ text này và tìm hiểu xem tôi là kiểu gì: Subscriber, Member hoặc
không là gì cả. Và sau đó tôi sẽ phải lục lại số tài khoản hoặc mật khẩu mà tôi đã sử dụng để đăng kí trang
web này hoặc là cân nhắc lại xem cái này có đáng bỏ công sức ra để đăng nhập lại không.
Tới tầm này thì câu hỏi mà t đang đặt ra cho bản thân không còn là “làm thế nào để mình trả lời các câu hỏi
này?” nữa, mà là “cái bài báo này nó có thực sự đáng đọc tới thế không?”
Báo New York Times khiến cho cùng 1 vấn đề đơn giản hơn nhiều, bằng cách không ném ra tất cả những
thông tin chi tiết khiến người dùng bị loạn. Họ chỉ bắt người chọn đưa ra 1 sự lựa chọn đầu tiên (hoặc là
Log-in, hoặc là chọn các phương án Subscribe). Sau khi chọn xong người dùng sẽ dc chuyển tới 1 trang khác,
trang này chỉ có thông tin liên quan tới cái lựa chọn mà người dùng đã chọn trước đó.

Đưa ra quá nhiều thông tin khiến cho việc chọn lựa phương án và câu trả lời khó khăn hơn - vấn đề này diễn
ra nhan nhản trong các dạng form điền thông tin online. Caroline Jarret viết hẳn 1 chương về nó (Tạo ra các
câu hỏi dễ trả lời) trong cuốn sách “Forms that Work: Designing Web Forms for Usability” của cô ấy.
Cũng như cuốn sách về viết content cho Website của Ginny Redish, bất kỳ ai làm việc liên quan tới các dạng
forms đều nên nghiên cứu thật kĩ cuốn sách này.

Có thể bạn sẽ cần 1 chút trợ giúp.

Tuy nhiên, đời rất phức tạp, và một số lựa chọn thực sự không đơn giản tí nào.
Khi bạn không thể tránh khỏi việc đưa ra các sự lựa chọn phức tạp đau đầu, bạn cần phải cố gắng hết sức để
cung cấp cho người dùng càng nhiều hướng dẫn càng tốt - nhưng cũng đừng quá nhiều.
Các hướng dẫn sẽ hiệu quả nhất khi chúng:
- Ngắn gọn: Chỉ bao gồm một lượng thông tin tối thiểu, vừa đủ
- Đúng lúc đúng chỗ: Được đặt ở chỗ nào mà người dùng sẽ tìm thấy ngay khi họ cần nhất
- Rõ ràng: Được thiết kế sao cho người dùng không thể bỏ qua
Ví dụ như các dòng text be bé nằm cạnh các form field, những cái link chú giải kiểu “Cái này là gì?​", hay thậm
chí các tool tip box khi ta hover chuột lên 1 thứ gì đó khó hiểu.
Ví dụ ưa thích của kiểu bảng hướng dẫn “vừa đúng lúc" này thường sẽ xuất hiện ở các ngã 3 ngã 4 trên khắp
đường phố London. Nó rất ngắn gọn “NHÌN BÊN PHẢI" (và mũi tên chỉ sang phải), đúng lúc đúng chỗ (bạn
sẽ thấy chúng ngay khi bạn cần đc lưu ý bởi chúng), và cũng cực kì rõ ràng (​ hầu như lúc nào bước đi sang
đường bạn cũng nhìn xuống phía dưới)

Tôi đoán rằng các chỉ dẫn này đã cứu mạng rất nhiều du khách tới London, vì họ có thể lầm tưởng xe cộ sẽ
tới từ hướng khác (nó đã cứu tôi 1 lần đấy.)
Dù bạn có cần trợ giúp hay không, điều mấu chốt ở đây là chúng ta đều đứng giữa các sự lựa chọn khi sử
dụng website, và làm sao cho các lựa chọn đó đơn giản, không cần suy nghĩ nhiều chính là 1 trong những
điều quan trọng nhất ta có thể làm để thiết kế ra 1 sản phẩm dễ sử dụng với mọi người.
Chương 5. Loại bỏ từ ngữ thừa thãi
Nghệ thuật viết càng ít càng tốt cho website.

“Bỏ đi 1 nửa phần chữ trên mỗi trang, rồi sau đó bỏ tiếp 1 nửa của phần
còn lại."
Định luật thứ 3 của Steve Krug về Tính khả dụng.

Trong tất cả vỏn vẹn 5 hay 6 điều tôi học được hồi Đại học, thứ mà gắn bó với tôi lâu nhất, cũng chính là thứ
tôi thấy hữu ích nhất, chính là luật thứ 17 trong cuốn sách “The Elements of Style” của tác giả E.B. White:

17. Loại bỏ từ ngữ thừa thãi.

Hành văn chất lượng là phải súc tích. 1 câu văn không cần những từ ngữ thừa thãi, 1 đoạn văn
không cần những câu văn thừa thãi, cũng tương tự như 1 bức tranh không cần những đường
nét thừa thãi, và 1 cỗ máy không cần những bộ phận thừa thãi.

Khi tôi xem các trang web, tôi đã bị ngạc nhiên khi thấy phần lớn câu từ trên đó chỉ để làm cảnh, bởi vì chả có
ai đọc chúng cả. Và chỉ bằng cách ngồi ị 1 chỗ ở đó thôi, tất cả mớ chữ này hàm ý rằng người dùng có khi
phải đọc hết chúng nó thì mới hiểu được cách sử dụng trang web, điều này càng khiến cho trang web trở nên
khó hiểu và nguy hiểm hơn so với thực tế.

Định luật 3 của tôi nghe có vẻ cực đoan, bởi vì nó cần phải như vậy. Loại bỏ một nửa số từ ngữ trên thực tế là
một mục tiêu khả thi: Tôi không gặp khó khăn gì trong việc loại bỏ một nửa số từ trên hầu hết các trang web
mà không làm mất đi bất kỳ giá trị thông tin nào của chúng. Nhưng việc loại bỏ tiếp một nửa của phần text còn
lại chỉ là cách để khuyến khích mọi người cứ thẳng tay mà lọc chữ.

Loại bỏ tất cả mớ từ mà không ai thèm đọc đó có 1 số hiệu ứng tích cực:

- Khiến cho các content hữu ích nổi bật hơn
- Làm giảm đi độ nhiễu loạn thông tin của trang web
- Khiến cho trang web ngắn gọn hơn, tạo cơ hội cho người dùng xem được nhiều thông tin trong 1 lần
lướt mắt mà không phải scroll nhiều
Tôi không bảo là những bài báo trên WebMD.com hay các câu chuyện trên NYTimes.com phải bị rút ngắn.
Nhưng phần lớn các nội dung chữ trên mạng thường có xu hướng dài hơn mức cần thiết.

Loại bỏ Happy talk.

Happy talk thì chúng ta nhìn phát là biết: Chính là cái dòng chữ giới thiệu thường xuất hiện để chào mừng
người dùng đã vào được trang web, hoặc giải thích vắn tắt về nội dung của trang web mà họ chuẩn bị xem.
Nếu bạn vẫn còn băn khoăn không biết cái đoạn chữ này có phải Happy talk không, có 1 cách test chắc kèo:
Nếu bạn lắng nghe cẩn thận khi đang đọc cái text đó, bạn có thể nghe thấy 1 giọng nói nho nhỏ đang thì thầm
trong đầu mình: “Blah blah blah blah blah....”
Bạn sẽ bắt gặp rất nhiều Happy talk trong mấy cái tờ phướn truyền thông tự lăng xê rẻ tiền. Không giống như
văn phong truyền thông chất lượng, Happy talk kiểu này không có nội dung gì hữu ích, và chỉ tập trung vào
việc nói rằng chúng ta đỉnh như nào (nhưng cũng không nói rõ thứ gì làm ta đỉnh).
Mặc dù Happy talk thường thấy ở Home page - thường ở các đoạn chữ bắt đầu bằng câu “Chào mừng tới…” -
nơi cư trú ưa thích của chúng là ở front page (trang đầu) của các phân mục riêng lẻ của 1 trang web. Bởi vì
những page này thường chỉ là 1 cái list những link dẫn tới nhiều khu vực khác nhau của trang web mà không
có content riêng, nên những page kiểu đó có xu hướng có nhiều Happy talk để trông đỡ trống trải. Bất hạnh
thay, hiệu ứng nó mang lại cũng giống như 1 nhà xuất bản sách cảm thấy họ phải thêm vào 1 đoạn văn nho
nhỏ vào trang Mục lục: “ Cuốn sách nào bao gồm rất nhiều chương thú vị về ABC, DEF, và XYZ. Mong quý
độc giả thưởng thức."
Happy talk cũng như nói chuyện khách sáo ấy - chả có nội dung gì, về cơ bản chỉ là 1 cách để khiến cho mọi
thứ thân thiện hơn. Nhưng phần lớn người dùng Web không có thời gian để nói chuyện phiếm, họ muốn đạt
được thứ họ đang tìm nhanh chóng. Bạn có thể - và nên - loại bỏ càng nhiều Happy talk càng tốt.

Loại bỏ các câu Hướng dẫn.

Một nguồn từ ngữ thừa thãi khác là các câu hướng dẫn. Điều quan trọng nhất bạn cần biết về phần hướng
dẫn, chính là người dùng sẽ chả thèm đọc đâu - ít nhất là cho tới khi họ đã thử tự mò mẫm nhiều lần nhưng
vẫn không ra. Và kể cả khi đó, nếu cái hướng dẫn đó nhiều chữ quá, tỉ lệ người dùng tìm được cái thông tin
họ cần là khá thấp.
Mục tiêu của bạn là loại bỏ các câu hướng dẫn bằng cách thiết kế sao cho mọi thứ đều có tính tự giải thích,
hoặc là càng dễ hiểu càng tốt. Khi buộc phải dùng text hướng dẫn, hãy làm sao cho phần text này ngắn gọn
súc tích nhất có thể.

Ví dụ, đây là phần text hướng dẫn tôi đọc dc ở mở đầu của 1 trang web khảo sát (104 từ):
1 chút phân tích:

Tôi nghĩ phần text này có thể cải thiện nếu được cắt gọt nhiệt tình (34 từ):
Và giờ là đất diễn của thứ gì đó hoàn toàn khác biệt.

Trong những chương đầu tiên này, tôi đã cố gắng truyền đạt một số nguyên tắc cần ghi nhớ khi bạn xây dựng
một trang web.
Trong 2 chương tiếp theo, chúng ta sẽ đi sâu hơn và cách các nguyên tắc kể trên ứng dụng khi ta phải đối mặt
với 2 thách thức lớn nhất và quan trọng nhất trong thiết kế web: Navigation (điều hướng) và Homepage (trang
chủ).

Sẵn sàng chưa? Mang đồ ăn đồ uống gì chưa? 2 chương này sẽ rất dài đấy.
THỨ BẠN CẦN LÀM ĐÚNG
Chương 6. Biển chỉ đường và Vụn bánh mì?
Thiết kế hệ thống định vị và điều hướng.

Và bạn có lẽ sẽ thấy mình có / 1 căn nhà xinh đẹp / với 1 cô vợ xinh đẹp
Và bạn có lẽ sẽ tự hỏi bản thân / Ủa… / Làm sao mà mình có được
những thứ này?"
_ “Once in a lifetime” - nhóm nhạc Talkingheads_

Sự thật nó là như vậy:

Sẽ không ai dùng trang Web của mày nếu họ không biết làm thế nào để
đi lại trong cái web đó mà không bị lạc.

Bạn biết điều này từ kinh nghiệm của chính bạn khi là lướt Web. Nếu bạn vào một trang web và không thể tìm
thấy những gì bạn đang tìm kiếm hoặc không hiểu được cách trang web đó được tổ chức và sắp xếp, thì khả
năng cao là bạn sẽ không mất thời gian ở lại Web đó làm chi, hoặc là không bao giờ vào Web đó nữa luôn.
Vậy làm thế nào để ta tạo ra 1 hệ thống Navigation (điều hướng) rõ ràng, đơn giản và nhất quán?

Quy trình tìm đồ khi đi chợ.

Hình dung này: 1 buổi chiều bạn đi ra siêu thị để mua 1 cái lưỡi cưa.
Khi bạn đi vào, bạn sẽ nghĩ “Hmmm chúng nó để lưỡi cưa ở đâu nhỉ". Khi bạn vào bên trong, bạn sẽ bắt đầu
nhìn vào tên các mục hàng, treo cao trên tường (Chúng đủ lớn để bạn có thể đọc được từ xa)

“Hmmm” Bạn băn khoăn. “Công cụ? Hay là đồ làm vườn?” Có thể là 1 trong 2, nhưng bạn sẽ phải bắt đầu từ
đâu đó thôi, nên bạn đi vào khu bán Công Cụ.
Khi vào tới khu đó rồi, bạn sẽ tìm kiếm các biển hiệu ở cuối mỗi dãy hàng.

Khi bạn nghĩ bạn tới đúng dãy rồi, bạn bắt đầu tìm kiếm các sản phẩm riêng lẻ trên dãy đó.
Nếu hoá ra bạn đoán sai, bạn sẽ lại thử tìm ở dãi khác, hoặc bạn có thể quay ra ngoài và tìm lại từ đầu, trong
1 khu vực mới (‘Đồ làm vườn’ chẳng hạn). Tới lúc bạn tìm được thứ bạn muốn, quy trình nó sẽ giống như này:

Về cơ bản, bạn sử dụng hệ thống điều hướng của cửa hàng (các biển hiệu và hệ thống phân cấp tổ chức của
chúng) và khả năng quan sát (lướt, quét mắt) để tìm thấy những gì bạn đang tìm kiếm.
Tất nhiên, quá trình thực tế sẽ phức tạp hơn một chút. Đơn cử là khi bạn bước vào cửa, bạn sẽ dành một vài
tích tắc cho một quyết định quan trọng: Bạn sẽ bắt đầu bằng cách tự mình tìm kiếm cái cưa hay bạn sẽ hỏi
thẳng nhân viên bán hàng?
Đó là 1 quyết định được dựa trên 1 số lượng biến số khả năng - Bạn quen thuộc với cửa hàng tới đâu, bạn tin
tưởng vào khả năng tổ chức sắp xếp của cửa hàng tới mức nào, bạn có đang vội lắm không, hoặc thậm chí
cả việc bạn có hoà đồng hay không.
Khi ta đưa ra quyết định, quy trình sẽ giống như này hơn:

Nhớ là kể cả khi bạn tự đi tìm, nếu thấy loạn quá thì vẫn có khả năng bạn sẽ quay ra hỏi đường ai đó thôi.
Bài học nhập môn về Điều hướng trên Web.

Theo nhiều cách, bạn trải qua cùng 1 quy trình khi vào 1 Website nào đó.
- Thường thì bạn sẽ đang tìm cái gì đó. Trong thế giới “thực" thì đó có thể là phòng cấp cứu, hoặc là 1
chai tương cà cỡ đại. Còn trên Website thì đó có thể là 1 cặp headphones hoặc tên của dàn diễn viên
trong phim Casablanca, etc..
- Bạn sẽ quyết định xem nên hỏi trước hay tự tìm trước. Điều khác biệt là, ở trên Web thì không có
ông nào đứng đó để chỉ đường cho bạn cả. Thứ ở trên Web mà hữu dụng tương đương với hỏi đường
ở ngoài đời thực, chính là hành động tìm kiếm - gõ tên cái thứ bạn đang tìm trên khung search và nhận
về 1 mớ link có liên quan tới thứ đó, hoặc dẫn bạn trực tiếp tới thứ đó luôn.

Một vài người (Jakhôngb Nielsen gọi họ là những người dùng “thiên về search") sẽ luôn luôn tìm cái
search box đầu tiên mỗi khi vào 1 trang Web nào đó. (Họ có lẽ cũng chính là những người sẽ đi tìm
nhân viên bán hàng để hỏi đường ngay khi vào 1 cửa hàng nào đó)
Một vài người khác (Nielsen gọi là những người dùng “thiên về link" ) sẽ luôn luôn tự mò mẫm tìm hiểu
trước, và chỉ dùng search box khi mà họ đã thử click hết các đường link khả quan, hoặc khi họ đã thấy
quá nản với cái trang Web đó.
Với những người còn lại, quyết định nên dùng search box trước hay tự tìm trước phụ thuộc vào luồng
suy nghĩ của bạn lúc đó ra sao, bạn đang vội đến mức nào, và bản thân cái Web đó có hệ thống điều
hướng tử tế để mình tự tìm hay không.

- Nếu bạn chọn hướng tự tìm, bạn sẽ điều hướng dựa trên 1 hệ thống phân cấp, sử dụng các
biển hiệu để chỉ dẫn cho mình. Điển hình là, bạn sẽ lướt qua cái Homepage để tìm 1 chuỗi các phân
mục chính của trang web (chính là các biển hiệu khu vực tại cửa hàng) và click vào cái nào phù hợp.
 Sau đó bạn sẽ chọn tiếp trong 1 chuỗi phân mục phụ.

Với 1 chút may mắn, bạn sẽ có 1 list các thứ bạn đang tìm chỉ sau 1 vài click tiếp theo.
Sau đó bạn có thể click vào từng đường link để kiểm tra chi tiết, tương tự như khi bạn lôi sản phẩm thật ra
khỏi kệ trưng bày và kiểm tra qua lại, đọc nhãn hiệu, etc..
Quy trình trông sẽ như sau:
Lướt web nhẹ khôn kham.

Tìm kiếm mọi thứ trên một trang web và tìm kiếm chúng trong thế giới thực có rất nhiều điểm tương đồng.
Khi chúng ta ở trên 1 trang Web, theo 1 cách nào đó ta thấy mọi thứ giống y hệt như trên 1 không gian thực.
Nghĩ tới các thuật ngữ chúng ta thường dùng để mô tả trải nghiệm sử dụng Web như “lướt web", “đi sâu", “lần
mò" . Và click vào 1 đường link thì ta không dùng từ “tải" hoặc “hiển thị" 1 trang khác, nó sẽ “đưa mình tới" 1
trang khác.
Nhưng trải nghiệm sử dụng trang Web đang thiếu đi rất nhiều dấu hiệu mà con người đã dành cả đời làm
quen và sử dụng khi cần phải hình dung về không gian. Hãy xem xét những điều khác lạ của không gian trong
1 trang Web.
 Không có hình dung về tỉ lệ. Ngay cả khi chúng ta đã dùng 1 trang web thường xuyên, trừ khi đó là 1
web rất nhỏ, thì thường ta sẽ không biết được cái trang đó to cỡ nào (bao gồm 50 trang? 1000 trang? hay
17000 trang?). (​ Ngay cả những người quản lý trang Web thi thoảng cũng không biết rõ trang web của họ lớn
tới cỡ nào) Có thể có hẳn 1 cụm website to đùng mà ta chưa bao giờ tìm ra. Trải nghiệm này hoàn toàn khác
với trải nghiệm đọc 1 cuốn sách, tham quan 1 bảo tàng hay đi vào 1 cửa hàng, nơi mà bạn luôn có thể nắm
bắt được, dù chỉ mơ hồ, tỉ lệ không gian đã đi qua / chưa đi qua.
Kết quả thực tế là: sẽ rất khó để bạn biết được liệu mình đã lướt hết cái phần mình thích trên cái web này
chưa, dẫn tới việc bạn sẽ không biết khi nào mình có thể dừng lại. (Đây là 1 trong những lý do tại sao chúng ta
phải đổi màu cho những đường link đã được click vào. Nó báo hiệu cho chúng ta về những phần thông tin ta
đã xem hết, và phần nào chưa được khám phá)

Không có hình dung về phương hướng. Trên 1 trang web, không có trái phải trên dưới gì cả. Chúng
ta có thể nói về di chuyển lên trên hoặc xuống dưới, nhưng cái ý thực sự của chúng ta là trên, dưới trong hệ
thống phân cấp - tới 1 level chung chung hơn hoặc 1 level chi tiết hơn.

Không có hình dung về vị trí. Trong 1 không gian vật lý thực tế, khi đi loanh quanh, ta sẽ tích luỹ
thông tin và kiến thức về không gian đó. Ta phát triển cảm nhận về vị trí của mọi thứ và có thể đi đường tắt. Ở
ví dụ trên, lần đầu tiên tới được chỗ mua cái máy cưa thì mình có thể dựa vào biển hiệu, nhưng tới những lần
sau thì chúng ta sẽ đi thẳng tới vị trí của chúng luôn “Máy cưa à. Ừ mình nhớ nó ở đâu mà. góc bên phải, gần
gian hàng tủ lạnh".

Nhưng trên Web, chân bạn còn chẳng phải chạm đất; thay vào đó, bạn di chuyển đi lại bằng cách click vào
các đường link. Click vào mục “Công cụ chạy điện" và tự nhiên bạn được dịch chuyển tức thời tới dãy bán
Công cụ chạy điện, mà không phải đi qua quãng đường vật lý nào, không được nhìn thấy mọi thứ dọc đường.
Khi ta muốn quay lại 1 trang nào đó trên Web, thay vì phải dựa vào cảm quan vị trí vật lý như trên không gian
thực, ta phải nhớ lại ví trí của trang đó trong hệ thống phân cấp sắp xếp thông tin của cả trang web, và dò lại
hành trình của mình.
Đây chính là lý do tại sao các Dấu trang (bookmarks) - các lối đi tắt cá nhân được lưu trữ từ trước - rất quan
trọng, và tại sao nút Quay lại (back button) là nút được sử dụng nhiều nhất trong các trình duyệt Web.
Điều này cũng cho bạn biết tại sao cái khái niệm Homepage (Trang chủ) lại quan trọng. Homepage thì thường
cố định ở 1 chỗ. Khi bạn ở trong một trang web, Homepage giống như sao Bắc đẩu ấy. Bạn click vào
Homepage là có thể bắt đầu lại từ đầu được rồi.
Cái sự thiếu tính tương tác vật lý này vừa có lợi vừa có hại. Về mặt tích cực, cảm giác di chuyển nhẹ nhàng
không tốn sức này có thể rất thích thú, và nó giải thích 1 phần cho việc tại sao khi mình lướt web thời gian lại
trôi qua nhanh vậy, tương tự như khi chúng ta “chìm đắm" trong 1 cuốn sách hay ho.
Về mặt tiêu cực, tôi nghĩ điều này giúp giải thích lý do tại sao chúng ta sử dụng thuật ngữ “Web navigation”
(điều hướng Web), mặc dù chúng ta không bao giờ cần phải dùng tới từ điều hướng khi đang ở cửa hàng
bách hóa, hay thư viện. Nếu bạn tra từ ‘điều hướng’ trong từ điển, sẽ có 2 nghĩa chính: ‘đi từ nơi này đến nơi
khác’ và ‘xác định vị trí hiện tại'.
Chúng ta phải dùng từ ‘Điều hướng Web’ vì “xác định vị trí hiện tại của bạn” trên 1 trang web là vấn đề dễ gặp
phải hơn nhiều so với trên không gian vật lý. Ở trên 1 trang web vốn đã rất dễ bị lạc rồi, và ta còn không thể
ngó nghiêng xung quanh để xem mình đang ở dãy hàng hay khu vực nào nữa chứ. Điều hướng Web bù đắp
cho sự thiếu hụt cảm quan về vị trí bằng cách làm nổi bật hơn hệ thống phân cấp của trang Web, tạo ra cảm
giác về không gian cho người dùng.
Điều hướng không chỉ là 1 tính năng của trang Web, bản thân nó chính là trang web, cũng tương tự như cái
toà nhà này, các chuỗi kí ốt cửa hàng này, các quầy thu ngân và hệ thống thang cuốn này, đã cấu thành và
tạo nên 1 trung tâm thương mại. Nếu không có chúng, không ai biết mình đang đứng ở đâu cả.

Bài học rút ra là gì? Điều hướng web bắt buộc phải được làm thật tốt.

Các chức năng bị quên lãng của Điều hướng.

2 chức năng chính của Điều hướng khá hiển nhiên: Để giúp chúng ta tìm mọi thứ, và để cho chúng ta biết
mình đang ở đâu.
Tuy nhiên Điều hướng còn mang lại các chức năng khác cũng quan trọng không kém, nhưng lại dễ bị bỏ qua:
- Nó cho ta biết cái gì đang ở trên 1 trang web: Bằng cách làm hệ thống phân cấp thông tin rõ ràng
hơn, Điều hướng thể hiện rõ trang web này bao gồm những gì. Điều hướng có khả năng tiết lộ cấu trúc
nội dung đấy! Và tiết lộ cho người dùng về nội dung trang web thậm chí còn có thể quan trọng hơn việc
hướng dẫn người dùng về trang web đó.
- Nó cho ta biết cách sử dụng 1 trang web: Nếu Điều hướng làm tốt công việc của mình, nó sẽ ngầm
nói cho bạn biết cần bắt đầu ở đâu, và các hướng đi của bạn là gì. Lý tưởng hơn nữa thì Điều hướng
đóng vai trò như 1 Bản hướng dẫn (Càng tốt, vì phần lớn người dùng đằng nào cũng sẽ phớt lờ các
dạng hướng dẫn khác có trên trang Web thôi)
- Nó cho ta niềm tin vào đội ngũ xây dựng sản phẩm: Mỗi khi vào 1 trang web, chúng ta đều tự thắc
mắc 1 điều: “không biết mấy ông xây cái web này có làm việc có tâm không đây?” Đây là 1 trong
những yếu tố chính giúp chúng ta quyết định xem nên bỏ sang trang khác hay là vẫn tiếp tục dùng
trang hiện tại. Hệ thống Điều hướng rõ ràng, được xây dựng cẩn thận và thấu đáo là 1 trong những cơ
hội tốt nhất để chứng tỏ tiêu chuẩn của 1 trang web.
Các tập quán chung của Điều hướng trên web.

Các không gian vật lý như thành phố hay toà nhà (hoặc cả các không gian hiển thị thông tin như sách báo tạp
chí) đều có hệ thống điều hướng riêng biệt, với các tập quán đã dc cải tiến theo thời gian như biển chỉ đường,
số trang, và tiêu đề chương mục. Các tập quán này định hình rõ ràng nhận diện và vị trí của các yếu tố điều
hướng, để người dùng biết là mình đang cần tìm cái gì, và khi cần tìm cái đó thì nhìn vào khu vực nào.
Đặt các yếu tố đó ở đúng chỗ giúp người dùng tìm được chúng nhanh hơn, đỡ mất sức hơn. Thiết kế các yếu
tố đó theo 1 đúng kiểu giúp người dùng nhận ra chúng dễ dàng hơn.
Ví dụ, chúng ta quen với việc nhìn thấy biển tên đường ở các ngã tư, chúng ta sẽ thấy biển tên khi nhìn lên
(thay vì nhìn xuống), và chúng ta quen với kiểu thiết kế tiêu chuẩn của biển tên đường (đọc theo chiều ngang,
chữ trắng trên nền xanh, etc... )
Chúng ta cũng công nhận rằng tên của 1 toà nhà sẽ ở trên hoặc bên cạnh cửa chính toà nhà đó. Trong 1 siêu
thị, ta sẽ mặc định rằng biển tên sẽ được bố trí ở đầu mỗi dãy hàng. Trong 1 cuốn tạp chí, ta biết chắc là trang
mục lục nằm ở đâu đó trong mấy trang đầu tiên, và số trang sẽ nằm ở đâu đó ở phần lề trên hoặc dưới của
mỗi trang - và mục lục sẽ bao gồm các tiêu đề bài viết, và số trang sẽ có số trang và tên bài viết trên mỗi
trang.
Ta sẽ cảm thấy bực bội khó hiểu tới mức nào nếu 1 trong số những tập quán chung này bị làm sai (ví dụ như
khi tạp chí không đặt số trang trong các trang dành riêng cho quảng cáo)
Mặc dù giao diện có thể khác nhau rất nhiều, nhưng đây là những tập quán điều hướng cơ bản trên 1 trang
web.
Đừng có nhìn đểu nó, nhưng tôi thấy mâm nào cũng có mặt thằng này.

Các web designer dùng thuật ngữ “điều hướng đồng bộ" (hoặc điều hướng tổng) để mô tả 1 tập hợp các yếu
tố đồ hoạ mang tính điều hướng có ở trên hầu hết các website.

Khi được xây dựng tốt, hệ thống điều hướng đồng bộ sẽ nói, trong 1 tông giọng bình tĩnh, nhẹ nhàng:
“ Hệ thống điều hướng ở đây. Có thể nó sẽ thay đổi 1 chút, phụ thuộc vào vị trí của bạn, nhưng nó sẽ mãi ở
đây, và nó sẽ luôn hoạt động theo cách này"
Chỉ cần có hệ thống điều hướng xuất hiện 1 cách đồng bộ ở cùng 1 vị trí trong mọi trang phụ thôi cũng đủ để
người dùng xác nhận rằng họ vẫn đang ở trên cái trang web đó - điều này quan trọng hơn bạn tưởng nhiều.
Và giữ cho giao diện của nó đồng bộ xuyên suốt trang web cũng có nghĩa là, nếu may mắn, người dùng sẽ chỉ
cần làm quen với hệ thống điều hướng này 1 lần duy nhất.
Hệ thống điều hướng đồng bộ nên bao gồm đầy đủ 4 yếu tố này:

Tí nữa mình sẽ đi vào từng cái một. Nhưng trước tiên…

Nãy tôi có bảo là mọi-trang-web...

Tôi điêu đấy. Có 1 ngoại lệ với cái quy luật “mâm nào cũng có mặt”: Trang điền forms.
Trên các trang cần người dùng điền thông tin, hệ thống điều hướng đồng bộ đôi khi có thể là một sự xao
nhãng không cần thiết. Ví dụ, khi người dùng đang thanh toán cho các đơn hàng của mình trên một trang web
thương mại điện tử, bạn sẽ không muốn họ làm bất cứ điều gì ngoài việc điền form và thanh toán nhanh cho
xong. Tương tự như khi người dùng đăng ký tạo tài khoản, theo dõi (subscribe), điền form feedback, hoặc tick
chọn các tuỳ chọn cá nhân.
Đối với các trang này, sẽ hữu ích khi bạn có một phiên bản điều hướng đồng bộ thu nhỏ, chỉ bao gồm tên
trang web, 1 đường link tới Homepage, và bất kỳ tiện ích cơ bản nào có thể giúp người dùng điền form.

Giờ tôi đã biết mình không còn ở Kansas (Reference từ bài hát “We're not in Kansas - Big Country​)

Tên trang web, hoặc cái Logo thương hiệu thường ở góc trên bên trái trang web ấy, chính là cái tên toà nhà to
đùng ngoài đời thực. Ở Vincom thì tôi chỉ cần nhìn vào cái tên toà nhà 1 lần khi đi vào thôi, một khi đã ở trong
toà nhà rồi thì tôi biết chắc tôi đi đâu cũng vẫn ở trong Vincom. Nhưng ở trên 1 trang web - nơi mà phương
thức di chuyển của tôi là dịch chuyển tức thời với mỗi click - Tôi cần nhìn thấy tên trang web ở mọi trang phụ.

Cũng tương tự với việc chúng ta biết tên của toà nhà vì nó là cái dòng chữ to đùng ở cổng vào, khi ở trên
trang Web, chúng ta cũng biết web đó tên là gì khi nhìn lên phần trên của trang web đó (thường sẽ là ở phần
trên, bên trái, tất nhiên là với những ngôn ngữ đọc từ trái qua phải)
Tại sao à? Vì cái tên trang web đại diện cho cả trang web đó, nghĩa là nó là thứ cao nhất trong hệ thống phân
cấp thông tin của trang web.
Và có 2 cách để làm rõ được sự vượt trội này trong hệ thống phân cấp thị giác của 1 trang web: 1 là làm cho
nó trở thành thứ nổi bật nhất trên trang web, hoặc 2 là làm cho nó bao trọn mọi thứ khác.
Vì bạn không muốn cái logo website là yếu tố nổi bật nhất trên trang (ngoại trừ, có lẽ, trên Homepage), nơi tốt
nhất cho nó - nơi khiến tôi không cần phải thắc mắc về vị trí của tên trang web - chỉnh là ở trên đỉnh (top
page), nơi nó đứng đầu và bao trọn toàn bộ phần còn lại của trang web.
Chỉ đặt cái tên trang web ở đúng chỗ của nó thôi chưa đủ, bạn cần phải thiết kế cái tên trang web sao cho
đúng chuẩn 1 cái tên trang web.
Điều này nghĩa là nó nên có những đặc tính mà chúng ta hay thấy ở logo hay biển hiệu cửa hàng: 1 font chữ
đặc biệt, màu sắc nổi bật, và có những yếu tố đồ hoạ giúp cho tên trang web có thể được nhận ra ở mọi kích
cỡ, từ cái nút bấm tới cái biển quảng cáo.

Các phân mục chính

Các phân mục chính - đôi khi thường được gọi là hệ thống điều hướng chủ đạo - chính là các đường link tới
các khu vực chính của trang web: Các khu vực có level cao nhất chỉ sau tên trang web trong hệ thống phân
cấp thông tin.

Ở 1 số trang web, hệ thống điều hướng đồng bộ cũng sẽ có chỗ để hiển thị cho cả điều hướng thứ cấp - danh
sách các phân mục phụ thuộc phân mục chính hiện tại.

Ở những trang web khác, rà chuột hoặc click vào 1 phân mục chính bất kì và sẽ có 1 menu dạng drop down
hiện ra. Có trang web thì sẽ đưa bạn đến trang riêng của cái phân mục chích mà bạn vừa click vào, ở đó bạn
sẽ thấy các phân mục phụ.
Các tiện ích cơ bản (Utilities)

Các tiện ích cơ bản là các đường link tới các phần quan trọng của 1 trang Web, tuy các phần này không thuộc
hệ thống phân cấp nội dung thông tin.

Chúng hoặc là sẽ giúp bạn bắt đầu sử dụng trang web (Đăng kí/ đăng nhập, Trợ giúp, Sitemap, hoặc Giỏ
đựng hàng, etc..), hoặc là sẽ cung cấp thông tin về chủ trang web (About us hay Liên hệ).
Cũng như các biển tên từng cơ sở trong 1 siêu thị, danh sách các tiện ích cơ bản cần được thiết kế kém nổi
bật hơn phần Danh mục chính.

Các tiện ích cơ bản sẽ đa dạng tuỳ thuộc vào từng loại trang web. Với 1 trang web công ty hay trang web
thương mại điện tử, chúng có thể bao gồm bất cứ link nào trong danh sách sau đây:

Thông thường, Hệ thống điều hướng đồng bộ chỉ có thể chứa 4 hoặc 5 Tiện ích cơ bản mà người dùng hay
sử dụng nhất. Nếu bạn cố gắng nhồi thêm nhiều thì chỉ càng khiến cho các Tiện ích này bị mờ nhạt đi. Các
Tiện ích cơ bản ít được dùng hơn thì hãy đặt ở Footer: chính là các đường text link nho nhỏ ở cuối mỗi trang
đó.
Cứ dậm chân 3 lần và tự nhủ “Chẳng nơi đâu bằng nhà mình” (Reference từ The Wizard of Oz​)

Một trong những thứ quan trọng nhất trong Hệ thống điều hướng đồng bộ là 1 cái nút hoặc 1 cái link nào đó có
thể đưa người dùng về Homepage.
Để nút Home trong tầm mắt người dùng mọi lúc mọi nơi tạo ra 1 cảm giác an toàn bảo đảm rằng, bất kể việc
tôi có bị lạc sang phần nào trong trang web này, tôi vẫn luôn có thể làm lại từ đầu, như khi mình ấn nút “reset"
hay khi tôi sử dụng thẻ “Ra tù” trong cờ tỉ phú vậy.
Hầu như tất cả người dùng đều quen với việc coi phần tên trang web là một nút có thể đưa họ quay trở lại
trang Homepage. Tôi nghĩ đó cũng là một ý tưởng tốt khi đặt nút Home này chung mâm với các phân mục
chính của trang web.

Tìm kiếm tinh gọn

Dựa trên sự hữu ích của việc tìm kiếm và số lượng người thích việc tìm kiếm hơn là tự mò mẫm lướt web, trừ
khi cái trang đó rất nhỏ gọn và được sắp xếp tổ chức rất hợp lý, mọi trang web nên có hoặc là 1 cái search
box, hoặc là 1 đường link dẫn tới 1 trang tìm kiếm riêng.
Nhớ trong đầu rằng, với 1 tỷ lệ lớn người dùng, hành động có ý thức đầu tiên mà họ vào 1 trang web mới,
chính là lướt mắt khắp trang web để tìm thứ gì đó kiểu như 1 trong 3 kiểu mẫu sau:

Công thức rất đơn giản: 1 thanh nhập dữ liệu, 1 cái nút, và 1 từ khoá “Search" hoặc là icon Kính lúp được
công nhận trên toàn cầu khi ta muốn diễn tả hành động “tìm kiếm thứ gì đó”. Đừng gây khó khăn cho người
dùng - hãy bám theo những công thức này. Đặc biệt hơn, hãy tránh
- Các từ ngữ cầu kì: Người dùng chỉ tìm cái từ “search" thôi, nên là cứ từ khoá “search" mà dùng.
Đừng có “Find”, hay “Quick find”, hay “Quick search", hay “Keyword search". (Nếu bạn đã dùng
“Search" cho cái label của thanh nhập dữ liệu, dùng từ khoá “Go" cho tên nút cũng được)
- Hướng dẫn quá tỉ mỉ: Nếu bạn đã bám theo công thức, bất cứ ai dùng Web 1 vài buổi sẽ biết phải
thao tác ra sao. Thêm 1 cái dòng gợi ý “Gõ từ khoá vào đây" sẽ giống như nói rằng “Hãy để lại tin nhắn
sau tiếng *beeep*” trên cái hộp thư thoại của bạn. Hồi xưa thì đúng là cần thiết thật đấy, nhưng giờ thì
không còn nữa rồi, chỉ tổ làm cho mọi thứ mất thời gian hơn thôi.
- Quá nhiều tuỳ chọn: Nếu có nguy cơ khiến cho người dùng cảm thấy bối rối về quy mô của việc
Search (Search theo filter nào, cả trang web hay 1 phần trang web thôi), hãy cố gắng ghi rõ ra, càng rõ
càng tốt.
 Nhưng trước khi đưa ra cho người dùng các tuỳ chọn để giới hạn quy mô tìm kiếm (chỉ tìm trong phần
này của trang web thôi chẳng hạn), bạn cần cân nhắc thật kĩ. Và cũng cần cẩn thận trong việc đưa ra
các tuỳ chọn giúp người dùng tìm được chính xác thứ họ cần tìm (ví dụ tìm kiếm theo tên tiêu đề, hay
theo tác giả, hoặc tìm kiếm theo tên sản phẩm hay số hiệu sản phẩm, etc..)
Tôi hiếm khi thấy trường hợp nào giá trị đánh đổi của việc “thêm các tuỳ chọn" cho thanh search lại
xứng đáng với cái kết quả “người dùng phải cân nhắc giữa các tuỳ chọn đó và nghĩ xem liệu mình có
cần chúng không” (riêng cái việc bắt người dùng phải nghĩ thêm đã không ổn rồi)
Nếu bạn muốn đưa ra các tuỳ chọn về quy mô tìm kiếm cho người dùng, hãy đưa ra khi nó thực sự
hữu ích - ví dụ như khi người dùng tới trang kết quả tìm kiếm và phát hiện ra rằng có quá nhiều kết quả
trả về khi họ tìm kiếm mọi thứ, nên họ buộc phải giới hạn quy mô lại.

Thứ cấp, Tam cấp, và bất kì cái gì đứng sau Tam cấp

Cái này xảy ra nhiều đến nỗi tôi đã quen luôn rồi: Mỗi khi làm việc với ông designer nào mới mới, ổng sẽ gửi
tôi 1 bản design sơ bộ để tôi check xem có vấn đề về Tính khả dụng nào không, và lần nào tôi cũng nhận
được 1 cái sơ đồ cho 1 trang web có 4 level lận..

… và các bản design mẫu cho Homepage và chỉ 2 level trên cùng
Tôi tiếp tục ngó qua ngó lại để tìm thêm cái để xem, hoặc ít nhất là 1 cái trang nào đó với 1 dòng chữ viết tay
“Đây là chỗ phép màu xảy ra", nhưng chả bao giờ tôi tìm được thêm cái gì. Tôi nghĩ đây là một trong những
vấn đề phổ biến nhất trong thiết kế Web (đặc biệt là trong các trang web nào to to, nhiều tầng): Các trang thứ
cấp và các trang phụ bên trong không được đầu tư nhiều về thời gian cũng như nghiên cứu so với các trang
chính. Tại rất nhiều trang web, ngay khi người dùng đi sâu hơn trang thứ cấp, hệ thống điều hướng gần như
sập luôn và tồn tại chỉ mang tính chất đối phó. Vấn đề này phổ biến đến nỗi tôi còn gặp khó khăn trong việc
tìm ra các ví dụ chất lượng cho hệ thống điều hướng ở các trang phụ của phụ (level 3-4-5,..)

Tại sao điều này lại xảy ra?

Một phần, tôi nghĩ, là do Hệ thống điều hướng tốt về khoản đa cấp (nhiều mức độ) cũng rất khó để thiết kế -
khi phải tính tới phần không gian hạn chế trên trang web và cả một mớ các thứ khác cần được sắp xếp sao
cho hợp lý.

Phần vì, đội thiết kế thường cũng không có đủ thời gian để tìm hiểu sâu hơn 2 level đầu tiên.

Phần nữa vì có lẽ nó có vẻ cũng chẳng quan trọng lắm. (Dù sao thì, cái này quan trọng tới đâu được? Nó
không phải ở trang Chính, thậm chí còn không phải ở trang Thứ cấp). Và người ta thường có xu hướng nghĩ
rằng “tới lúc người dùng đi sâu tới mức đó trong 1 trang web, họ có lẽ cũng đã hiểu rõ cách trang đó vận hành
thế nào rồi.”

Và lại còn thêm cả vấn đề lấy nội dung mẫu và lấy ví dụ về hệ thống phân cấp thông tin trong các trang thuộc
level thấp nữa chứ.
Kể cả khi đội designer có hỏi xin thì có khi cũng chả được, vì thường thì bản thân cái người phụ trách về mảng
content cũng thường không nghĩ xa tới mức đó.

Nhưng thực tế là người dùng hoá ra lại dành nhiều thời gian trong các trang thuộc level thấp, cũng nhiều y
như các trang top-level vậy. Và trừ khi bạn đã tạo ra được 1 hệ thống điều hướng tổng thể từ trên xuống dưới
ngay từ đầu, sẽ rất khó để bạn xây dựng hệ thống điều hướng kiểu cuốn chiếu, thêm chỗ này tỉa chỗ kia, mà
vẫn giữ được tính đồng bộ của cả hệ thống.
Bài học ở đây là gì? Trước khi tranh luận về mấy cái mang tính visual như màu sắc, phong cách thiết kế,
chúng ta cần đặc biệt lưu ý về việc xây dựng các trang web mẫu có khả năng thể hiện hệ thống điều hướng
cho mọi tầng thông tin tiềm năng mà 1 trang web có thể chứa.

Tên trang, hay là “Tại sao tôi lại thích đi tới Los Angeles."

Nếu bạn đã từng tới LA, bạn sẽ hiểu cái lời bài hát nọ không chỉ đơn thuần là lời-bài-hát - LA thực sự chính là
một con đường cao tốc khổng lồ, không phải 1 thành phố. Và chính bởi vì người dân LA rất xem trọng việc lái
xe đi lại, nên thành phố này cũng có hệ thống biển chỉ đường tốt nhất tôi từng gặp. Tại LA,
- Biển chỉ đường rất to: Khi bạn dừng xe ở ngã tư, bạn có thể nhìn rõ biển hiệu của cả cái ngã tư tiếp
theo luôn.
- Biển chỉ đường được đặt đúng chỗ: Chúng được treo ngay trên chính cái đường bạn đang đi, nên
bạn chỉ cần liếc lên là thấy
Tôi phải thú nhận tôi chết mê chết mệt cái cách xử lý biển chỉ đường này của LA, vì tôi vốn sống ở Boston, nơi
mà bạn sẽ thấy cực kì may mắn nếu bạn có thể nhìn ra được biển chỉ đường trong khi vẫn còn thời gian để
xoay sở rẽ trái hoặc phải.

Kết quả là? Khi lái xe ở LA, tôi tốn ít năng lượng và sự tập trung hơn cho việc nhìn xem mình đang đi đường
nào, và nhiều hơn cho giao thông, các cuộc đối thoại, và nghe nhạc. Tôi rất thích lái xe ở LA.
Trên các trang web, phần tên trang (Page name)​ chính là biển chỉ đường. Tương tự với biển chỉ đường, khi
người dùng sử dụng trang web đó 1 cách trơn tru thì họ sẽ không để tâm tới tên trang đâu. Nhưng ngay khi
nhận ra là có thể họ đang không đi đúng hướng, người dùng cần nhìn thấy tên trang 1 cách dễ dàng nhất để
có thể xác định lại lộ trình.

Có 4 điều bạn cần biết về tên trang:

- Trang nào cũng cần có tên: Giống như việc mọi con đường cần có biển tên, mọi trang chính phụ
trong 1 trang web đều cần có tên của nó.
 Mấy ông designer thường nghĩ, “Ừ thì tao đã highlight cái page name trong phần Điều hướng bên trái
rồi kìa. Thế là đủ rồi.". Đây là 1 ý tưởng hấp dẫn, vì nó giúp ta tiết kiệm không gian, và đỡ đi 1 thứ phải
lo trong việc sắp xếp layout, nhưng ý tưởng này là không đủ được đâu. Bạn phải cho thêm tên trang
vào.

- Tên trang cũng cần được đặt đúng chỗ: Trong hệ thống phân cấp thị giác của 1 trang thông tin, tên
trang cần được thiết kế sao cho người dùng hiểu được rằng “phần nội dung này thuộc về cái tiêu đề
này". (Sau cùng thì, tên trang ra sao thì thông tin trang như vậy thôi - chưa baoh các phần cấu trúc
ngoài lề như banner quảng cáo được tính vào như 1 phần nội dung của 1 trang thông tin cả)

- Tên trang cần phải nổi bật: Bạn sẽ cần phải kết hợp cả vị trí, kích thước, màu sắc và font chữ để làm
nổi bật cái tên trang, thể hiện rõ với người dùng rằng “Đây là tiêu đề cho cả cái trang thông tin này nè".
Trong đa số trường hợp, tên trang sẽ là phần text lớn nhất trên trang đó.

- Tên trang cần phải đồng bộ với mục vừa được click vào: Dù rằng không có ai nhắc tới cái này cả,
trang web nào cũng có 1 cái luật bất thành văn:
“Tên trang sẽ đồng bộ với cái cụm từ mà bạn vừa click vào"

Nói theo cách đơn giản, nếu bạn click vào 1 đường link hoặc 1 button có tên “Khoai tây nghiền", bạn sẽ được
đưa tới 1 trang thông tin có tên “Khoai tây nghiền".
Nghe thì có vẻ lặt vặt, nhưng đây là 1 luật bất thành văn quan trọng. Mỗi khi vào trang web nào phạm phải luật
này, tôi lại phải nghĩ, kể cả khi suy nghĩ đó chỉ diễn ra trong 1 phần triệu giây “Sao 2 cái thứ này lại khác
nhau?”. Và nếu có một sự khác biệt lớn giữa tên đường link và tên trang thông tin, hoặc rất nhiều sự khác biệt
nhỏ nhỏ, thì niềm tin của tôi vào trang web và năng lực của những người tạo ra sẽ nó sẽ bị giảm đi.

Tất nhiên, đôi khi bạn cũng phải linh hoạt 1 chút, thường là do giới hạn không gian thiết kế. Nếu các từ khoá
trong đường link bạn vừa click vào và tên trang không khớp chính xác 100%, điều quan trọng nhất bạn cần để
ý là (a) chúng khớp nhau nhất có thể và (b) có lý do chính xác cho việc nội dung thông tin khác nhau. Ví dụ,
nếu người dùng click vào 1 cái button tên là Quà tặng Nam và Quà tặng Nữ và được chuyển sang các trang
có tên Quà tặng Phái Mạnh và quà tặng Phái Đẹp, thì ngay cả khi cách diễn đạt không giống nhau, họ cũng
cảm thấy có đủ sự liên kết về ngữ nghĩa để bỏ qua sự khác biệt.

“Bạn đang ở chỗ này."

Một trong những phương pháp giúp Hệ thống điều hướng khắc phục được cảm giác “bị lạc trên mạng" của
người dùng, chính là chỉ ra cho người dùng biết vị trí của họ trong sơ đồ cấu trúc thông tin của cả trang web,
tương tự với cái biển hiệu “Bạn đang ở chỗ này" trong những cấu trúc rộng lớn ngoài đời thực, như trung tâm
mua sắm, hay vườn quốc gia.

Trên web thì điều này được thể hiện bằng việc highlight vị trí hiện tại của người dùng trên chính các thanh
Điều hướng, danh sách Phân mục, hoặc Menu xuất hiện trên trang đó.
Trong ví dụ trên, cả Phân mục chính (Bedroom) và phân mục phụ (Lighting) đều được “đánh dấu" (làm nổi bật
lên). Có 1 vài cách cơ bản để làm nổi bật vị trí hiện tại của người dùng.

Lỗi thường gặp nhất khi làm khâu định vị này chính là khi cách phương thức làm nổi bật này chưa tạo được
sự tương phản cần thiết. Chúng cần phải trông khác hẳn so với phần còn lại của danh sách; nếu không thì
chúng sẽ mất đi ý nghĩa về mặt thị giác và thành ra làm cho trang web trông nhiễu loạn hơn. 1 cách chắc kèo
để đảm bảo sự nổi bật, đó là dùng nhiều phương pháp cùng 1 lúc - ví dụ như vừa đổi màu, vừa để text bold.

Sự thiếu tương phản về mặt thị giác thực ra là 1 vấn đề khá phổ biến. Mấy ông designer thì thích làm mọi thứ
nhẹ nhàng, đồng bộ, vì sự tinh tế là 1 trong những đặc tính của phong cách design tối giản, hiện đại. Nhưng
người sử dụng web thường vội tới mức họ rất hay bỏ qua các dấu hiệu tương phản, đặc biệt khi chúng quá
nhẹ nhàng tinh tế.

Nhìn chung, nếu bạn là designer mà bạn thấy cái dấu hiệu tương phản kia trông có vẻ hơi nổi... thì có khi bạn
sẽ phải làm cho nó nổi bật thêm gấp đôi nữa cơ.

Breadcrumbs

Cũng tương tự như việc Highlight các phân mục theo vị trí của người dùng, Breadcrumbs cũng cho họ biết vị
trí của mình.
Chúng được gọi là Breadcrumbs (vụn bánh mì) vì chúng có sự tương đồng về hình thức với dấu vết vụn bánh
mì mà Hansel đã thả xuống khu rừng để sau này 2 anh em Hansel & Gretel không bị lạc và có thể quay về
nhà.
(Trong truyện cổ Grimm phiên bản gốc, bà mẹ kế của Hansel & Gretel bắt người cha đẻ phải bỏ mặc 2 đứa
con của mình trong rừng rậm giữa thời kì đói kém, để cả gia đình không phải chết đói.) Người anh Hansel
khôn khéo và tháo vát đã phá hỏng kế hoạch bằng cách thả những hòn sỏi dọc đường và lần ra được lối về
nhà. Nhưng lần tiếp theo vào rừng, Hansel buộc phải thả vụn bánh mì để đánh dấu đường đi, và cuối cùng bị
chim rừng ăn hết trước khi 2 anh em có thể tìm ra lối đi về nhà. Sau này câu truyện còn phát triển sang những
chi tiết rùng rợn như ăn thịt người, trộm cắp, và cả tế sống, nhưng về cơ bản thì nó là 1 câu chuyện nói về
việc khi bị lạc thì ta sẽ thấy bực mình khó chịu ra sao.)

Breadcrumbs được cấu thành từ 1 chuỗi các trang bạn đã đi qua, bắt đầu từ Homepage đến trang hiện tại của
bạn, giúp bạn dễ dàng trở lại các trang có level cao hơn trong hệ thống phân cấp thông tin của 1 trang web.
Trong 1 thời gian dài, Breadcrumbs được coi là 1 thứ không phổ biến, chỉ tồn tại ở các trang web kiểu cơ sở
dữ liệu với hệ thống phân cấp thông tin khổng lồ. Còn ngày nay thì chúng được sử dụng trong càng nhiều
trang web hơn, đôi khi còn mang vai trò thay thế luôn cả hệ thống điều hướng.
Nếu làm đúng, Breadcrumbs thực có tính dễ giải thích cực lớn, chúng không chiếm nhiều diện tích, và mang
lại 1 phương pháp thuận lợi, nhất quán để người dùng làm được 2 thứ mà họ thường cần làm nhất: Quay lại
trang cũ, hoặc về thẳng trang Homepage. Breadcrumbs thường được dùng trong các trang web lớn, có hệ
thống phân cấp thông tin sâu.
Dưới đây là 1 vài cách tốt nhất để tận dụng Breadcrumbs:
- Đặt chúng ở trên top trang web: Breadcrumbs có vẻ hoạt động tốt nhất nếu chúng được xếp ở trên
đầu. Tôi nghĩ có lẽ là vì điều này có tác dụng cô lập và tách biệt Breadcrumbs luôn - khiến cho chúng
giống với 1 yếu tố đồ hoạ phụ kèm, như kiểu đánh số trang trong 1 cuốn sách hay tạp chí.
- Sử dụng dấu ‘>’ giữa các level: Sau 1 thời gian phát triển và thử sai, người ta đã nhận ra rằng thứ
giúp phân cách tốt nhất giữa các level chính là ký hiệu lớn hơn (>), có lẽ bởi vì về mặt thị giác, ký hiệu
này thể hiện chuyển động đi xuống tiếp các level thông tin sâu hơn.
- Cái level cuối cùng thì để Bold: Trang cuối cùng trong chuỗi Breadcrumbs sẽ chính là tên trang mà
người dùng đang xem hiện tại, nên việc để Bold tạo hiệu ứng nổi bật cần thiết cho việc định vị. Và bởi
vì đó chính là cái trang mà người dùng đang xem, nên tất nhiên nó không phải là 1 đường link rồi.
3 lý do mà tôi ​vẫn thích các tabs

Cái này tôi vẫn chưa chứng minh được (chưa thôi), nhưng tôi thật sự nghi ngờ rằng chính Leonardo da Vinci
đã phát minh ra khái niệm về phân tab vào khoảng đâu đó cuối thế kỉ 15. Xét trên khía cạnh giao diện thì
chúng là 1 sáng kiến tuyệt vời.
Tab là 1 trong những trường hợp hiếm hoi mà chúng ta có thể ứng dụng 1 hình ảnh đồ vật ngoài đời thực lên
giao diện ảo. Giống như các tab phân tách từng tệp giấy trong 1 tệp hồ sơ, hay các ngăn thư mục trong 1
ngăn kéo tài liệu, chúng giúp phân tách nội dung thành nhiều “tệp” khác nhau. Và chúng khiến cho việc sắp
xếp và tra cứu dễ dàng hơn khi người dùng chỉ cần rà tới cái tab chứa thông tin mà họ muốn đọc (hoặc nếu là
trên Web, thì chỉ cần click vào tab đó).
Tôi thấy các tabs là 1 sự lựa chọn tuyệt hảo nhưng lại ít được cân nhắc sử dụng khi điều hướng. Tôi thực sự
thích chúng vì:
- Chúng nó rõ ràng dễ hiểu: Tôi chưa từng thấy ai - bất kể mù công nghệ tới đâu - phải nhìn vào giao
diện tab và nói “Hmm không biết cái này dùng như nào nhỉ?"
- Chúng nó nổi bật: Khi tôi thực hiện các cuộc Usability Testing, tôi đã rất ngạc nhiên khi thấy người
dùng thường xuyên bỏ qua thanh điều hướng ngang ở trên đầu của 1 trang web. Tuy nhiên Tab thì
trông tách biệt tới nỗi chúng hiếm bị bị nhầm lẫn hay bỏ qua. Và bởi vì không ai có thể hiểu nhầm chức
năng điều hướng của Tab, chúng đã tạo ra 1 sự phân tách hiển nhiên giữa Điều hướng và Nội dung
thông tin mà ta muốn đạt được trong thiết kế của mình.
- Chúng nó trông gọn gàng đẹp mắt: Web designer thường luôn cố gắng làm cho thiết kế của trang
web trông ấn tượng hơn về mặt thị giác. Nếu thiết kế Tab đúng cách, chúng thể làm cho trang web
trông chặt chẽ ngăn nắp và đóng vai trò hữu ích trong khâu sắp xếp thông tin.

Tất nhiên nếu bạn muốn dùng Tabs thì bạn phải dùng cho đúng cách.
Để có thể tối ưu hiệu quả của Tab, thiết kế của bạn phải tạo ra cảm giác cái tab đang hoạt động (đang được
xem) phải nằm bên trên những tab còn lại. Đây là lý do chính khiến cho thiết kế của bạn cảm thấy giống với
Tab ngoài đời thực về mặt thị giác - thậm chí lý do này còn quan trọng hơn việc vẽ ra cái tab sao cho giống
ngoài đời.
Để tạo ra được hiệu ứng này, Tab đang hoạt động cần phải có 1 màu khác, hoặc 1 yếu tố tương phản nào đó,
và nó cũng cần phải gắn liền với phần không gian bên dưới / bên cạnh của mình. Đây chính là thứ khiến cho
cái Tab đang hoạt động nổi lên hẳn bên trên, cao hơn mấy thằng còn lại.

Bắt đầu kiểm tra thôi (Trunk test)

Giờ bạn đã biết các khâu hoạt động ra sao rồi, bạn đã sẵn sàng để thử bài test của tôi về 1 hệ thống điều
hướng tốt trên web. Bài test như sau:
Giả sử bạn bị bịt mắt lại và nhốt trong cốp xe, thằng tài xế chở bạn tới 1 trang thông tin nằm sâu bên trong 1
trang web chính. Nếu trang thông tin đó được thiết kế tốt, khi bỏ khăn bịt mắt ra, nhìn 1 hồi bạn sẽ có thể trả
lời được những câu hỏi này mà không cần đắn đo lưỡng lự.
- Tên trang Web là gì?​ (Site ID)
- Mình đang ở trang nào? (Tên trang thông tin)
- Các phân mục chính của trang Web này là gì? (Các sections)
- Mình có các tuỳ chọn nào ở level hiện tại? (Hệ thống điều hướng)
- Mình đang đứng ở đâu trong hệ thống này? (Các dấu hiệu thị giác về vị trí của bạn trên trang web)
- Làm thế nào để tìm kiếm?
Sao cái motif giống trong phim Goodfellas (đạo diễn: Martin Scorsese) vậy? Bởi vì trải nghiệm trên Web của
người dùng thường giống với cảm giác tự nhiên bị đưa tới 1 chỗ xa lạ, hơn là 1 con đường mòn quen thuộc
sau hiên nhà, nhưng phần lớn chúng ta lại không nhận ra được điều này. Khi thiết kế các trang thông tin, ta
thường nghĩ người dùng sẽ đi tới được các trang đó bằng cách bắt đầu từ Homepage và bám theo con đường
hợp lý, đầy logic mà ta đã sắp xếp. Nhưng trên thực tế, người dùng thường bị thả vào giữa cái trang Web mà
không biết mình đang ở đâu, phần lớn bởi vì trước đó họ vừa click vào 1 đường link nào đó từ 1 công cụ tìm
kiếm nào đó, từ trang mạng xã hội nào đó, hoặc từ 1 chiếc email, và chắc chắn là họ chưa bao giờ biết về cấu
trúc điều hướng của trang web này bao giờ.
Còn việc bị bịt mắt? Bài kiểm tra sẽ cần thị lực của bạn mờ ảo 1 chút, vì cái chính của việc test này không phải
là để xem coi bạn có thể trả lời được các câu hỏi kia hay không (vì rõ là chỉ cần nhìn kĩ trong 1 thời gian tương
đối là có thể có được câu trả lời rồi). Việc test này hướng tới việc liệu các yếu tố kia có nổi bần bật, đập vào
mắt người dùng tới mức họ không cần nhìn kĩ cũng nhận ra hay không. Ta sẽ phải dựa vào giao diện chung
của mọi thứ, không phải các tiểu tiết.

Tiến hành bài kiểm tra Trunk test như sau:

- Step 1: Chọn bừa 1 trang thông tin của 1 trang Web ngẫu nhiên nào đó, và in nó ra
- Step 2: Giơ tờ giấy lên khoảng cách 1 cánh tay và chỉ mở mắt he hé (Để bạn không thể nghiên
cứu kĩ cái trang đó được)
- Step 3: Tìm ra và đánh dấu các yếu tố sau, nhanh nhất có thể
+ tên trang Web
+ tên trang thông tin
+ Các phân mục chính (hệ thống điều hướng chủ đạo)
+ Hệ thống điều hướng thứ cấp
+ Các dấu hiệu thị giác về vị trí của bạn trên trang web
+ Công cụ tìm kiếm

Thử luôn trên trang web của bạn đi xem sao. Và thử nhờ 1 vài người bạn thử làm bài test luôn cũng được. Kết
quả có lẽ sẽ làm bạn ngạc nhiên đó.
Chương 7. Nguyên lý Big bang trong Thiết kế Web
Tầm quan trọng của việc chỉ cho người dùng đi đúng hướng ngay từ bước đầu tiên.

Lucy cưng, em liệu mà giải thích cho thật kĩ đấy nhé.

_ “I love Lucy” - TV Show của Mỹ những năm 1950s_

Thiết kế 1 cái Homepage thường làm tôi liên tưởng tới cái TV gameshow kinh điển ở Mỹ - trò chơi “Beat the
Clock" (Chiến thắng thời gian)
Mỗi người chơi sẽ lắng nghe chăm chú ông MC Bud Collyer giải thích 1 cái hành động mà họ sẽ phải làm. Ví
dụ “Bạn có 45 giây để ném 5 quả bóng nước này vào cái giỏ được buộc trên đầu bạn".
Các hành động này thường có vẻ khó làm, và cần sự khéo léo, nhưng sẽ làm được nếu may mắn.
Và ngay khi người chơi chuẩn bị bắt đầu, ông MC mới tiết lộ thêm “À còn 1 điều nữa: bạn sẽ phải bịt mắt khi
làm trò này!”, “...bạn sẽ phải làm trò này dưới nước!”, “... bạn sẽ phải làm trò này trong chiều không gian thứ 5
(?)”.

Với Homepage thì cũng thế đấy. Ngay khi bạn tưởng bạn đã xem hết 1 lượt các phần thông tin cơ bản rồi, lúc
nào cũng sẽ lòi ra thêm… 1-thứ-nữa.
Thử nghĩ về tất cả những thứ mà trang Homepage phải chứa xem:
- Nhận diện thương hiệu và Sứ mệnh. Ngay từ ấn tượng đầu, trang Homepage phải cho chúng ta biết
cái trang này là trang gì, mục tiêu của nó là gì - và nếu có thể, tại sao ta lại phải ở đây mà không phải ở
1 trang bất kì nào khác.
- Hệ thống phân cấp thông tin. Trang Homepage phải đưa ra được 1 cái nhìn tổng thể về quy mô
thông tin của cả hệ thống trang web - cả về nội dung (Thứ tôi có thể tìm thấy ở đây là gì?) lẫn tính
năng (Tôi có thể làm gì ở đây?) - và cách chúng được sắp xếp. Điều này thường có thể đạt được nếu
bạn sử dụng hệ thống điều hướng đồng bộ.
- Tìm kiếm. Phần lớn các trang web cần có 1 cái search box được bố trí to đẹp rõ ràng ở trang đầu
Homepage.
- Lấp ló thả thính. Như 1 trang bìa tạp chí, trang Homepage cần phải cuốn hút người dùng, báo cho họ
biết rằng còn nhiều thứ hay ho bên trong trang Web.
- Truyền thông nội dung. Làm nổi bật các phần thông tin mới nhất, phổ biến nhất, hấp dẫn nhất, như
cái top stories và các hot deals.
- Truyền thông phụ kèm. Mời gọi người dùng khám phá các phân mục khác của trang Web, hoặc thử
nghiệm các tính năng mới.
- Nội dung mới nhất. Nếu sự thành công của 1 trang web phụ thuộc vào tỉ lệ quay lại của người dùng,
trang Homepage cần phải có nội dung chất lượng và được cập nhật thường xuyên. Và kể cả khi 1
trang web nào đó không cần người dùng vào xem thường xuyên, chúng cũng cần cho thấy 1 chút đầu
tư cập nhật thông tin - dù chỉ là 1 cái đường link dẫn tới bài thông cáo mới nhất của công ty - để báo
cho người dùng biết rằng cái trang này không bị bỏ hoang, hoặc là đã quá lỗi thời.
- Các Chương trình khuyến mãi (deals). Homepage cần có đủ khoảng trống cho bất cứ thể loại quảng
cáo, truyền thông, chương trình khuyến mãi nào phù hợp.
- Lối đi tắt (shortcuts). Các phần nội dung được xem nhiều nhất (ví dụ như các bản cập nhật phần
mềm) có thể sẽ cần 1 đường link riêng trên trang Homepage, để người dùng đỡ mất công tìm.
- Đăng ký.​ Nếu trang web của bạn yêu cầu đăng ký, trang Homepage cần 1 khu vực đăng ký / đăng
nhập riêng để người dùng mới có thể đăng ký, và người dùng cũ có thể đăng nhập lại 1 cách dễ dàng
(“Chào mừng bạn trở lại, Steve Krug”)
Bên cạnh những cái chắc chắn phải có nêu trên, trang Homepage cũng cần đạt được 1 số mục tiêu trừu
tượng như sau:
- Cho người dùng biết họ đang cần tìm cái gì. Trang Homepage cần được thiết kế để tôi có thể tìm
được đúng thứ tôi cần 1 cách nhanh nhất và dễ dàng nhất, nếu mà trang web đó có thứ đó.
- Cho người dùng biết họ đang thiếu cái gì. Cùng lúc đó, trang Homepage cần phải khoe ra với tôi
những thứ tuyệt vời khác của trang Web mà có thể tôi sẽ hứng thú - kể cả khi tôi không chủ động tìm
kiếm chúng.
- Cho người dùng biết họ cần bắt đầu từ đâu. Không gì phiền hơn vào 1 cái trang Homepage mà
không biết nên bắt đầu từ đoạn nào.
- Tạo ra sự tin tưởng và cảm giác an toàn. Với 1 số người dùng vãng lai, trang Homepage có thể là
cơ hội duy nhất để gây ấn tượng tốt với họ.

Và bạn phải làm tất cả điều này… khi đang bịt mắt!

Cứ như thể cái mớ yêu cầu trên kia còn chưa đủ gắt, bạn còn phải thực hiện chúng trong những điều kiện vô
cùng khó khăn. Một vài thử thách thường gặp là như này:
- Ông nào cũng muốn có phần. Vì trang Homepage là cái trang thường được xem nhiều nhất - và có 1
số người dùng web họ chỉ biết xem mỗi trang Homepage thôi - nên những thứ được vinh dự đặt ở
Homepage sẽ có lượng traffic tốt hơn đáng kể.
Kết quả là, trang Homepage chính là mặt tiền của mọi trang Web: Đó là hình thức bất động sản mà ai
cũng muốn sở hữu, nhưng không phải ai cũng có được. Ông nào có đầu tư vào cái trang Web này
cũng muốn có 1 phần đất riêng trên Homepage, và riêng cái cuộc đấu đá tranh giành đất đai hiển thị
trên Homepage thôi cũng đủ tàn khốc rồi. Đôi khi nhìn vào mấy cái Homepage, tôi cảm thấy như thằng
nhóc trong phim “Giác quan thứ 6” ấy: “Cháu chỉ thấy… stakeholders (cổ đông / các bên liên
quan)”.

Hậu quả của việc chiều theo ý các Stakeholder.

 Biểu đồ này có khi còn chả chính xác lắm: Một số trường ĐH thậm chí còn không ghi tên đầy đủ của
mình trên trang Homepage luôn.
Thêm với cái xu hướng người dùng chỉ đủ kiên nhẫn để lướt web cho tới lúc họ nhìn thấy 1 cái đường
link nào hay hay có thể click được, cái khoảng không gian “Above the fold” (nửa trên của 1 trang web -
phần mà người dùng có thể nhìn thấy luôn và ngay, không cần scroll chuột) tương đối nhỏ trên trang
Homepage vốn đã rất chật chội, lại càng bị tranh giành ác liệt hơn.

- Lắm thầy nhiều ma. Vì trang Homepage rất quan trọng, nó thường là cái trang mà ai cũng quan tâm
để ý tới (kể cả CEO)
- Nhạc nào cũng phải nhảy. Không giống như các trang thông tin ở sâu bên trong 1 trang web, trang
Homepage phải đủ hấp dẫn cho bất cứ ai mò vào xem, bất kể mục tiêu và sở thích của họ khác nhau
ra sao.

Đồng chí đầu tiên hi sinh là...

Với tất cả trọng trách mà nó phải gánh vác, 1 trang Homepage không thể xoay sở đáp ứng được nhiều yêu
cầu đến thế, dù thiết kế có tốt tới đâu, dù trang web có đơn giản tới mức nào. Kiểu gì bạn cũng phải chấp
nhận mất cái này cái nọ khi thiết kế 1 trang Homepage. Và khi bạn cân nhắc xem giữ lại cái gì bỏ đi cái gì,
thêm cả ông sếp lại cứ muốn nhét thêm 1 cái khác vào nữa, kiểu gì cũng sẽ có thứ bị lãng quên.
Nhưng có 1 thứ mà bạn không thể lãng quên - mà chính cái thứ này lại càng dễ bị quên - đó là khả năng
truyền tải thông điệp chủ đạo của trang Web. Mỗi khi ai đó gửi tôi 1 bản design Homepage, có 1 thứ mà tôi
hầu như lúc nào cũng để ý được: Bản design cho trang web này có thông điệp chưa đủ rõ ràng.
Trang Homepage cần phải trả lời được, 1 cách nhanh chóng và rõ ràng nhất có thể, đầy đủ 4 câu hỏi mà tôi
hay tự hỏi mỗi lần vào xem 1 trang web mới:

Tôi phải trả lời được những câu hỏi này trong nháy mắt, 1 cách chính xác, nhanh gọn và rõ ràng.
Nếu nhìn vào trang Web trong 1 vài giây đầu mà tôi vẫn chưa rõ nó là về cái gì, tôi sẽ gặp nhiều khó khăn hơn
trong việc diễn giải những thứ khác, và tỉ lệ tôi hiểu sai thứ gì đó và cảm thấy khó chịu cũng sẽ cao hơn.
Nhưng nếu tôi hiểu đúng trang Web, khả năng tôi diễn giải đúng ý mọi thứ còn lại trên trang Web sẽ cao hơn,
điều này sẽ đóng góp nhiều hơn vào 1 trải nghiệm lướt Web tích cực, vui vẻ.

Tôi hay gọi đó là Nguyên lý Big bang trong Thiết kế Web. Cũng tương tự với Nguyên lý Big bang ngoài đời
thực, nguyên lý này dựa vào giả thuyết những-giây-đầu-tiên: ‘Khi bạn đang ở trên 1 trang Web mới nào đó,
những giây đầu tiên là cực kì quan trọng’.
Giờ ta đã biết từ 1 thí nghiệm rất tinh tế (hãy tìm “Attention Web Designers: You Have 50 Milliseconds to Make
a Good First Impression!” ​(Mấy ông Web designer chú ý: Ông chỉ có 50 mili giây để tạo ấn tượng tốt với người
dùng thôi!)​ ) rằng có rất nhiều thứ xảy ra ngay khi người dùng mở 1 trang Web mới. Ví dụ, họ sẽ đảo mắt 1
vòng (trong vài tích tắc thôi) và trong đầu họ sẽ hình thành 1 mớ ấn tượng chung chung: Trông có đẹp không?
Có nhiều nội dung không? Có nhiều khu vực nổi bật không, cái nào mình thấy hấp dẫn?

Điều hay ho nhất về cái thí nghiệm này chính là việc họ đã chỉ ra được rằng những ấn tượng ban đầu và
những ấn tượng về sau của 1 người dùng trên Web thường khá giống nhau. Nói theo cách đơn giản, chúng ta
thường trông mặt bắt hình dong, hình thành định kiến nhanh như tên lửa, nhưng hóa ra các ấn tượng chộp
giật đó lại không khác cho lắm so với những quan điểm logic, hợp lý mà chúng ta đúc kết được về 1 trang
Web sau khi đã cân nhắc xem xét nó thật kĩ càng.

Tuy nhiên không thể nói ấn tượng ban đầu của chúng ta về mọi thứ lúc nào cũng chính xác được. Trên thực
tế, 1 trong những điều tôi gặp nhiều nhất trong những cuộc Usability Testing chính là việc người dùng thường
sai tòe loe khi mới tìm hiểu về tính năng và định nghĩa của 1 thứ gì đó. Sau đó họ lại có thói quen dùng chính
những cái “tri thức” này để diễn giải mọi thứ tiếp theo.

Nếu suy luận ban đầu đã sai (“Trang này là để làm ABCXYZ...”), người dùng sẽ bắt đầu cố gắng nhét cái giải
thích đó vào mọi thứ tiếp theo mà họ thấy. Và nếu nó sai, thành ra họ sẽ càng hiểu sai nhiều hơn. Nếu người
ta mới đi ra đường đã lạc, thường thì họ sẽ càng bị lạc sâu hơn nữa.
Đây chính là lý do tại sao việc chỉ cho người dùng đi đúng hướng ngay từ bước đầu tiên là cực kì quan trọng.
Việc này đảm bảo rằng họ nhìn thấy được bức tranh tổng thể 1 cách chính xác rõ ràng.

À cũng đừng hiểu sai ý tôi: Những cái khác cũng rất quan trọng. Bạn vẫn cần phải gây ấn tượng tốt, thu hút,
chỉ dẫn, và đưa người dùng tới đúng chỗ. Nhưng những mục tiêu này thì quá nổi trội và rõ ràng, lúc nào cũng
sẽ có ai đó - cả trong lẫn ngoài đội phát triển sản phẩm - đảm bảo rằng chúng sẽ được thực hiện cẩn thận.
Nhưng riêng việc truyền tải thông điệp chủ đạo 1 cách rõ ràng và súc tích, thì thường không mấy ai mặn mà
cho lắm.
Nhưng mà.. trang Homepage á? Thật á?

Tôi biết có người sẽ nghĩ:

“Chả ai vào 1 trang nào đó từ trang Homepage nữa. Cái đó xưa lắm rồi!”
Và tất nhiên họ cũng đúng thôi. So với thời kì đầu thì trang Homepage đã mất đi tính toàn năng của mình. Giờ
thì người dùng có xu hướng vào 1 trang thông tin nằm sâu bên trong trang Web của bạn bằng cách click vào 1
đường link được dẫn từ email, bài blog, hoặc từ 1 trang mạng xã hội nào đó.
Vì lý do này, bạn cần làm mọi thứ trong khả năng để khiến cho mỗi trang thông tin trong trang Web của bạn
đều có khả năng định hướng và nhận diện về mặt thương hiệu và sứ mệnh, để người dùng hiểu được rõ Bạn
là ai, Bạn làm cái gì, Bạn cung cấp dịch vụ gì?

Tuy nhiên, vấn đề là, hầu hết các trang đều không có đủ không gian để làm được những yêu cầu trên 1 cách
chuẩn chỉnh. Kết quả là, có 1 cơ số người dùng đã hình thành nên 1 hành vi mới.
Khi vào được 1 trang thông tin nào đó trong 1 trang Web, điều tiếp theo người dùng thường làm đó là quay ra
trang Homepage để xem mình đang ở trang Web nào. (Tôi thường liên tưởng hành vi này giống những người
thợ lặn, thi thoảng thò đầu lên mặt nước xem mình đang ở đâu, gần hay xa bờ). Nếu cái trang Web đó hay ho
hấp dẫn, họ sẽ xem tiếp. Nếu trang Web đó chứa thông tin họ cần tham khảo, có thể họ sẽ muốn tìm xem ông
nào dựng lên cái Web này, để xem có uy tín không.
Trang Homepage vẫn là nơi diễn ra hành vi này của người dùng, và bạn cần đảm bảo việc này diễn ra trơn tru
thuận lợi.

Cách để truyền tải thông điệp chủ đạo

Mọi thứ trên 1 trang Homepage có thể góp phần làm cho người dùng hiểu thêm về trang Web. Nhưng có 3
yếu tố trên 1 trang Homepage mà được kì vọng sẽ cung cấp những thông tin súc tích, chính xác về nội dung
và dịch vụ của cả trang Web.

- Câu Tagline.​ Một trong những phần bất-động-sản ngon nhất trên trang Homepage chính là khoảng
trống bên cạnh / bên dưới cái logo trang Web. Khi ta nhìn thấy 1 cụm từ được đặt ngay sát logo như
thế, ta ngầm hiểu đó chính là 1 dòng Tagline, và ta hiểu dòng tagline đó như là 1 câu mô tả ngắn gọn
cho cả trang Web. Chúng ta sẽ đi sâu hơn nữa về Tagline trong phần tiếp theo.

- Phần Text chào mừng (Welcome text) Welcome text là 1 bản mô tả ngắn gọn cho trang Web,
thường được đặt ở 1 khu vực nổi bật trên trang Homepage (thường là ở góc trên bên trái hoặc ở giữa
trang) nên thường Welcome text sẽ là thứ đầu tiên đập vào mắt bạn.
 - Nút “Tìm hiểu thêm". Các mô hình kinh doanh và sản phẩm công nghệ thường cần giải thích rõ ràng
chi tiết, nhưng người dùng hiếm khi nào có đủ kiên nhẫn để đọc bản giải thích đầy đủ cả. Họ đã quen
với viêc xem những video ngắn gọn trên đt và máy tính. Kết quả là giờ đây người ta sẽ hay xem các
nội dung trên Web hơn nếu nó đủ ngắn gọn nhanh chóng.

Nhưng không phải ai cũng sẽ sử dụng 3 yếu tố này - cũng không phải ai cũng để ý tới chúng. Phần lớn người
dùng có lẽ sẽ đoán bừa nội dung trang Web dựa trên nội dung của trang Homepage. Nhưng nếu họ không thể
đoán được, bạn sẽ cần bố trí 1 vài khu vực trên trang Homepage để người dùng có thể nhìn vào đó mà tìm
hiểu. Dưới đây là 1 vài hướng dẫn giúp bạn truyền tải thông điệp chủ đạo của 1 trang Web.

- Sử dụng nhiều không gian nhất có thể. Bạn sẽ muốn dùng càng nhiều không gian để tạo ra thông
điệp chủ đạo càng tốt, vì 1 là bạn không thể tưởng tượng rằng lại có ai đó không biết trang này là trang
gì, và 2 là ai cũng muốn dùng khoảng trống trên trang Homepage cho những mục đích khác.
Lấy ví dụ là trang Kickstarter.com. Vì dịch vụ mới mẻ mà trang Web cung cấp, Kickstarter cần phải giải
thích khá nhiều, nên họ đã sử dụng rất nhiều đất trên trang Homepage chỉ để giải thích về thông điệp
chủ đạo và dịch vụ của trang Web. Hầu hết mọi yếu tố trên trang Homepage đều góp phần giúp giải
thích và khai sáng về nội dung trang Web.
Kickstarter có thể không có 1 dòng tagline (trừ khi họ muốn dùng câu slogan “Bring creativity to life"
làm tagline) nhưng đúng là họ đã rất nỗ lực trong việc đảm bảo người dùng hiểu được dịch vụ họ mang
lại và cách họ vận hành.
“What is Kickstarter?” rõ ràng là phần nổi bật nhất trên thanh điều hướng của trang Web rồi.
- … nhưng cũng đừng dùng quá nhiều không gian. Với phần lớn các trang Web, không cần thiết phải
dành quá nhiều không gian cho việc truyền đạt những thông tin cơ bản, và việc 1 thông điệp mà chiếm
hết cả cái trang Homepage cũng hơi quá để cho người dùng có thể tiếp thu. Giữ mọi thứ đơn giản
ngắn gọn - vừa đủ để thể hiện thông điệp - và chỉ vậy thôi. Đừng cố gắng khoe thêm tất cả mọi tính
năng hay ho, chỉ nói về những thứ quan trọng nhất là được rồi.
- Đừng sử dụng tuyên ngôn sứ mệnh trong phần Welcome text. Rất nhiều trang Web vứt lên trang
Homepage của họ những câu tuyên ngôn sứ mệnh nghe ngáo ngáo như kiểu được viết bởi mấy em thí
sinh thi Hoa hậu hoàn vũ vậy. “Tập đoàn XYZ ung cấp các giải pháp đẳng cấp thế giới trong lĩnh vực
đang phát triển của blah blah blah blah blah ....” Có ai thèm đọc đâu.
- Đó là 1 trong những thứ quan trọng nhất phải test. Bạn không thể chỉ dựa vào cảm quan cá nhân
về cái này được. Bạn cần đưa trang Homepage của bạn cho những người ngoài công ty đánh giá, để
xem liệu bản design này có khả năng truyền đạt rõ ràng thông điệp chủ đạo hay không, vì thông điệp
chủ đạo có lẽ là thứ duy nhất mà những người ở trong công ty không để ý được liệu nó có đang được
thể hiện rõ ràng hay không.
Không gì tuyệt hơn 1 câu Tagline chất lượng!

Tagline là 1 câu ngắn gọn đơn giản nhưng có thể định hình & định vị tính cách của cả 1 thương hiệu / tổ chức.
Tagline đã tồn tại từ rất lâu rồi, trong các lĩnh vực quảng cáo, giải trí và xuất bản, ví dụ như: “Nâng niu bàn
chân Việt” (Bitis), “Giá rẻ cho mọi nhà” (BigC), “Cửa chống ồn, tiết kiệm điện” (Euro Window)

Trên 1 trang Web, câu tagline thường nằm ở ngay gần cái logo thương hiệu, hoặc nó chính là 1 phần của logo
thương hiệu luôn. Chúng là 1 cách hiệu quả để truyền đạt thông điệp tới người dùng, vì chúng là 1 trong
những yếu tố có khả năng gói gọn 1 cách cô đọng và chính xác về mục đích của cả trang Web.
1 số đặc tính cần có khi tạo ra 1 câu Tagline:

- 1 câu Tagline tốt thường sẽ rõ ràng và hàm chứa thông tin, có khả năng giải thích chính xác dịch vụ
của trang Web / thương hiệu / tổ chức mang lại.

- 1 câu Tagline tốt thường sẽ không quá dài​. 6 tới 8 chữ là đủ dài để truyền tải 1 thông điệp, nhưng
cũng đủ ngắn gọn để nó trở nên dễ nhớ.

- 1 câu Tagline tốt thường sẽ nhấn mạnh giá trị khác biệt của trang Web / thương hiệu / tổ chức.
Jakhôngb Nielsen đã gợi ý rằng, Tagline tốt là 1 câu mà không ai trên thế giới này dùng được trừ bản
thân mình, và tôi nghĩ đây là 1 tiêu chuẩn cực hợp lý.
 - 1 câu Tagline tốt thường sẽ tích cực, thông minh, mang tính độc đáo cá nhân. Tạo ra 1 câu Tagline
thông minh là tốt, nhưng chỉ khi cái sự khôn khéo đó giúp truyền tải thông điệp về dịch vụ - thay vì làm
mờ đi chúng.

Nhà tao giàu cần gì dăm ba cái tagline!

Có 1 số trang Web có thể tồn tại mà không cần có tagline. Ví dụ như:

- Những trang Web đã đạt được độ phủ sóng và thương hiệu toàn cầu, nhà nào cũng biết.
- Những trang Web có nền tảng truyền thông offline vững chắc
Cá nhân tôi thì nghĩ kể những trang Web kiểu như trên cũng sẽ có lợi ích từ việc dùng Tagline. Sau cùng thì,
dù bạn có nổi tiếng tới đâu, tại sao lại bỏ qua 1 cơ hội để khiến cho người dùng biết trang Web của bạn sẽ
cung cấp dịch vụ tốt hơn? Và kể cả khi trang Web này thuộc về 1 thương hiệu có giá trị truyền thông offline
mạnh mẽ, mục tiêu của thương hiệu đó trên mạng online cũng chưa chắc đã 100% giống nhau, và việc giải
thích cho người dùng biết sự khác biệt về mục tiêu giữa 2 nền tảng là rất quan trọng.
Câu hỏi thứ 5

Một khi tôi đã biết được các thông tin cơ bản của trang Web, vẫn còn 1 câu hỏi quan trọng nữa mà trang
Homepage phải giúp tôi tìm ra câu trả lời:

Khi tôi vào 1 trang Web nào đó, sau khi nhìn ngó 1 lượt, tôi sẽ có khả năng nêu ra 3 điều sau, 1 cách tự tin:
- Nếu tôi muốn tìm kiếm thì bắt đầu tại đây
- Nếu tôi muốn lướt/ đọc thêm, thì bắt đầu tại đây
- Nếu tôi muốn thử nghiệm các sản phẩm tốt nhất của trang Web, thì bắt đầu tại đây

Trong những trang Web được xây dựng theo mô hình từng bước một (Ví dụ như các Web cung cấp dịch vụ
Đăng ký thế chấp), phần bắt đầu của quá trình đăng ký phải nổi bần bật ngay trước mắt người dùng. Và trong
những trang Web mà người dùng phải đăng ký tài khoản nếu là thành viên mới, hoặc đăng nhập nếu đã có tài
khoản, khu vực cho phép họ Đăng ký hoặc Đăng nhập cũng phải nổi bật, rõ ràng.

Bất hạnh thay, nhu cầu nhấn mạnh vào mọi thứ (hoặc ít nhất những thứ tuân theo mô hình kinh doanh hàng
tuần của công ty) thi thoảng lại làm những điểm đầu vào này kém nổi bật hơn hẳn. Sẽ rất khó để người dùng
có thể tìm ra chúng khi trang Web của bạn toàn là banner quảng cáo, gào lên “Bắt đầu chỗ này nè!”, “Click ở
đây luôn đi!”.

Cách tốt nhất để hạn chế các trường hợp này, chính là thiết kế các điểm đầu vào sao cho chúng trực quan, dễ
nhận ra (ví dụ như thiết kế search box thì phải có 1 cái ô nhập text và icon kính lúp, etc...). Việc đặt tên chúng
chính xác rõ ràng cũng là rất quan trọng, chức năng là gì thì đặt tên y nguyên như vầy, đơn giản dễ hiểu (Tìm
theo từ khóa, Đăng nhập, Bắt đầu tại đây, etc...)

Tại sao mấy con gà đẻ trứng vàng lại trở thành mục tiêu?

Ở trang Homepage, chúng ta rất thường bắt gặp những hành vi thiển cận mà không chỗ nào có. Khi tôi tham
dự các cuộc họp về thiết kế trang Homepage, tôi thường tự lẩm bẩm “các ông lại mang con gà đẻ trứng vàng
đi cắt tiết rồi..” (Hẳn ai cũng biết câu chuyện Con gà đẻ trứng vàng rồi. 1 ông nông dân nọ có 1 con gà đẻ ra
trứng bằng vàng mỗi ngày. Ông này tham, nghĩ rằng nếu mổ bụng con gà ra thì sẽ có nhiều trứng vàng hơn.
Tuy nhiên mổ xong thì chết luôn con gà, và ông ta từ đó không còn nhận dc 1 quả trứng vàng hàng ngày nữa.
Bài học rút ra là gì: Tham thì thâm)

Đương nhiên, thứ tệ nhất của những hành vi này, đó là xu hướng cố gắng nhồi nhét, làm cho mọi thứ nổi bật.
Vấn đề của việc làm nổi bật mọi thứ trên trang Homepage chính là việc nó thực sự có hiệu quả đáng kể. Bất
cứ cái gì được trình bày rõ ràng, nổi bật trên trang Homepage sẽ gần như được bảo đảm rằng chúng sẽ thu
về traffic tốt hơn - tốt hơn kha khá - dẫn tới việc các bên Stakeholder còn lại sẽ nghĩ: “Sao mình không làm
tương tự thế kia?"
Nhưng vấn đề là, chi phí và cơ hội của việc thêm nhiều thứ trên 1 trang Homepage không đồng đều. Cái phân
khúc được làm nổi bật sẽ có được 1 lượng traffic lớn, còn cái thiệt hại tổng thể về hiệu quả của 1 trang
Homepage (vì nó bị dàn trải và nhồi nhét ngồn ngộn thông tin) sẽ ảnh hưởng tới toàn bộ phần còn lại của
trang Web.
Đây là ví dụ hoàn hảo của cái gọi là Bi kịch của những thứ công cộng. Giả thuyết rất đơn giản như sau:

Cứ cái gì là của công (1 tài sản công cộng), không sớm thì muộn sẽ bị huỷ hoại do lạm dụng.

(Ý tưởng này, xuất phát từ nhà toán học không chuyên William Forster Lloyd vào khoảng thế kỉ 19, trở nên nổi
tiếng khi nó được sử dụng trong 1 bài luận văn kinh điển về tình trạng quá tải dân số của nhà sinh học Garrett
Hardin (Nghiên cứu khoa học “Bi kịch của Cộng đồng", tháng 12 năm 1968)

Lấy ví dụ về 1 đồng cỏ tại 1 thị trấn vùng quê nào đó đi. Với mỗi con vật mà cái ông chăn gia súc thêm vào cái
đồng cỏ chung này, ông ta sẽ nhận dc tất cả tiền thu được khi bán con vật đó đi , đây là 1 lợi ích tích cực +1.
Nhưng ảnh hưởng tiêu cực của việc “thêm 1 con nữa thôi” - việc nó góp phần tạo ra tình trạng chăn nuôi quá
đà - sẽ có tác động tới tới cả những con vật khác, nên cái ảnh hưởng tới bản thân ông chăn gia súc nọ sẽ sâu
hơn -1 nhiều.
Tuy nhiên, thứ hợp lý duy nhất mà mỗi ông chăn gia súc có thể nghĩ tới, là cho thêm 1 con nữa vào bầy gia
súc ở đồng cỏ chung. Và thêm 1 con nữa, 1 con nữa - thêm nhanh kẻo thằng khác nó cũng thêm gia súc của
nó vào. Và vì ông chăn gia súc nào cũng khôn lỏi như thế, tài sản công cộng là đồng cỏ chung kiểu gì cũng
xuống cấp.
Bảo vệ trang Homepage khỏi cái sự tràn lan yêu cầu chúng ta phải cảnh giác để ý thường xuyên, bởi vì điều
này thường xảy ra dần dần, từ từ, với tư duy “chỉ thêm vào 1.. Cái.. nữa.. Thôi..” chậm rãi, chắc chắn, không
chút mảy may thương tiếc.
Mọi stakeholders cần được giải thích và chỉ dẫn về sự nguy hiểm của việc nhồi nhét thông tin tràn lan trên
trang Homepage, và họ cũng cần được gợi ý về các phương pháp lôi kéo traffic khác, ví dụ như quảng cáo
chéo trên những trang khác, hoặc là sử dụng cùng 1 khoảng trống cố định trên trang Homepage theo lượt,
được phân chia công bằng.
KIỂM TRA LẠI XEM ĐÃ ĐÚNG THẬT CHƯA
Chương 8. Người nông dân và ông chăn bò đáng ra
phải là bạn thân
Tại sao phần lớn các cuộc tranh cãi về Tính khả dụng đều chỉ tổ phí thời gian, và làm cách nào để tránh được
điều này.

“Một ông thì thích cày bừa, ông kia thì thích chăn bò, nhưng chẳng có lý
do gì 2 ông này không chơi được với nhau cả."
_ OKLAHOMA!, OSCAR HAMMERSTEIN II_

Để tự họ mần, thì mấy cái đội phát triển trang Web không quá nổi tiếng trong khoản đưa ra quyết định về các
vấn đề về Tính khả dụng. Hầu như đội nào cũng tốn 1 mớ thời gian công sức quý báu để nhằn tới nhằn lui
cùng 1 vấn đề.
Thử xem đoạn này thì hiểu:
Tôi thường gọi những cuộc tranh luận không hồi kết này là “những cuộc đấu tranh tôn giáo”, vì chúng nó có rất
nhiều điểm tương đồng với phần lớn các cuộc tranh luận liên quan tới tôn giáo và chính trị: Hầu hết đều bao
gồm những con người đang cố gắng thể hiện niềm tin cá nhân 1 cách mạnh mẽ vào những thứ không thể
chứng minh - thường là để thống nhất xem đâu là cách tốt nhất để làm điều gì đó quan trọng (dù nó có là “đạt
được Bình yên vĩnh cửu”, “quản lý con người 1 cách hiệu quả”, hoặc đơn giản là “thiết kế 1 trang Web”). Cũng
giống như các cuộc đấu tranh tôn giáo, các cuộc tranh luận này hiếm khi mang lại kết quả là có ai đó chịu thay
đổi quan điểm.
Ngoài việc tốn thời gian, những cuộc tranh luận này còn tạo ra căng thẳng và làm suy mòn sự tôn trọng giữa
các thành viên trong cùng dự án, và thường khiến cho việc đưa ra quyết định quan trọng khó khăn hơn.
Đen đủi là, hầu như team làm sản phẩm nào cũng có 1 vài yếu tố và quan điểm sẽ dẫn tới những cuộc cãi
nhau này. Trong chương này, tôi sẽ mô tả những yếu tố đó, và cố gắng đưa ra những phương án để khắc
phục mà theo tôi nghĩ là phù hợp nhất với từng yếu tố.

“Ai cũng thích__________”

Tất cả những người làm Web như chúng ta đều có 1 điểm tương đồng - chúng ta cũng sử dụng Web hàng
ngày. Và giống như những người sử dụng Web khác, chúng ta có xu hướng hình thành nên quan điểm và
định kiến về những thứ mình thích hay không thích về các trang Web.
Như 1 người dùng Web bình thường, chúng ta thích các trang Web có phần Menu chính ở góc trên bên phải,
và các Menu phụ ở góc dưới bên trái, vì đó là những vị trí quen thuộc của chúng và vì như thế thì dễ dùng
hơn, hoặc chúng ta ghét như thế vì thế thì nhàm chán quá. Chúng ta thích các trang Web có nhiều hình ảnh
bắt mắt sang chảnh vì chúng thu hút và có tính tương tác, hoặc là chúng ta ghét chúng vì ta không quan tâm
tới giao diện mà chỉ muốn đọc content thôi. Chúng ta thích các trang Web có ABC, hoặc chúng ta ghét các
trang Web có XYZ.
Và khi làm việc trong 1 team phát triển trang Web, rất khó để gạt bỏ những quan điểm cá nhân này đi. Kết quả
là team nào cũng toàn những cá nhân có định kiến riêng về những thứ tạo nên 1 trang Web ngon hay lởm.
Xét trên độ mạnh mẽ của những định kiến đó - và tính bảo thủ của bản chất con người - Họ sẽ có xu hướng
chung là áp những quan điểm thích / không thích này lên tập người dùng nói chung: cho rằng phần lớn người
dùng cũng thích cái thứ mà mình thích, cho rằng họ cũng giống như mình thôi.
Cũng không phải là mình nghĩ tất cả mọi người sẽ giống như mình. Ta biết sẽ có một vài người ở đâu đó
ngoài kia không thích cái thứ ta thích - sau cùng thì, ngay cả trong cùng 1 team mà đã có người không thích
cái thứ ta thích rồi. Nhưng đó không phải là những người có tư duy logic. Và những người có tư duy logic
cũng không nhiều.

Người nông dân vs. ông chăn bò

Vượt lên trên cả những xung đột mang tính cá nhân, có hẳn 1 level xung đột khác: xung đột về ngành nghề.
Như những người nông dân và hội chăn bò trong vở kịch Oklahoma!​, những thành viên trong 1 đội phát triển
trang Web có quan điểm rất khác nhau về việc cái gì sẽ tạo nên 1 trang Web xịn, dựa trên ngành nghề của họ.
(trong vở kịch, những người làm nông tiết kiệm, biết sợ trời sợ đất, sống vì gia đình và tập thể, thường sẽ có
xung đột với mấy ông du mục chăn bò, nay đây mai đó, sống buông thả và tự do. Nông dân thì thích 1 thửa
ruộng quây hàng rào, chăn bò thì thích 1 thảo nguyên rộng lớn)

1 trang Web lý tưởng theo con mắt của mỗi ngành nghề…

Theo tôi thì mấy cái người này làm những cái nghề đó vì bản chất họ phù hợp với chính xác cái ngành nghề
như vậy. Ví dụ, mấy ông designer, trở thành designer vì họ thích những sản phẩm có thẩm mỹ, đem lại trải
nghiệm tích cực về mặt thị giác. Họ thấy sướng khi được xem những trang Web có typeface sang chảnh và
những yếu tố đồ hoạ nhẹ nhàng mà tinh tế. Kiểu gì cũng có endorphin (hóa chất được tiết ra từ não, dẫn đến
cảm giác hạnh phúc, hưng phấn) .
Mấy ông Dev thì thích sự phức tạp. Họ thích tìm ra cách mọi thứ vận hành, phân tách cấu trúc của chúng ra
trong đầu, và từ đó tìm ra các ý tưởng và giải pháp họ thấy hữu dụng. Một lần nữa, endorphin lại xuất hiện.
Và bởi vì những phản ứng này diễn ra ở cái tầm chất-hoá-học-được-não-tiết-ra, rất khó để họ có thể nhận ra
rằng mọi người khác có lẽ sẽ không cảm thấy tương tự thứ họ cảm thấy.
Kết quả là, designer sẽ muốn làm cái Web sao cho nó trông nịnh mắt, và developer sẽ muốn làm cái web có
những tính năng thú vị, nguyên bản, thông minh. Tôi cũng không rõ trong tình huống này thì ai là người nông
dân, ai là người chăn bò, nhưng tôi chắc chắn rằng sự khác biệt trong quan điểm của họ thường dẫn tới xung
đột - và những cảm xúc tiêu cực - khi cần phải đặt ra thứ tự ưu tiên trong thiết kế.
Cùng lúc đó, designer và developer lại ở cùng 1 chiến tuyến, chống lại 1 thế lực lớn hơn, trong 1 cuộc chiến
mà theo như Art Kleiner mô tả là, sự xung đột giữa Hype (đội truyền thông) và Craft (đội kĩ thuật). (Tham khảo
“Văn hoá doanh nghiệp trong thời đạt Internet" trong tạp chí về chiến lược kinh doanh
strategy-business.com/press/article/10374​)
Trong khi đội truyền thông (Quản lý cấp cao, dân MKT, nhà phát triển dự án) có nhiệm vụ hứa hẹn, mời mọc,
thương thuyết để thu hút vốn đầu tư, hợp đồng quảng cáo và người dùng, gánh nặng phát triển và xây dựng
“miền đất hứa" này sẽ do đội kĩ thuật (đội ngũ thiết kế, lập trình,...) đảm nhận.
Phiên bản high-tech hiện đại của cuộc đấu tranh dai dẳng trường kì giữa nghệ thuật và thương mại (hoặc có
lẽ là giữa Nông dân + Chăn bò và Bá tước đường sắt) lại khiến cho những cuộc tranh luận về các vấn đề liên
quan tới Tính khả dụng càng phức tạp hơn - thường ở dưới dạng các chỉ thị tuỳ tiện, khó hiểu và không liên
quan từ phía bên truyền thông. (Có lần tôi thấy 1 tính năng đặc biệt hack não trên trang Homepage của 1
trang Web rất có triển vọng, được thiết kế hợp lý thấu đáo. Khi hỏi về cái đó thì họ bảo “Ờ, nó. 1 hôm thằng
CEO ngủ mơ thấy cái đó, nên hắn bắt bọn tao thêm nó vào bằng được.” True story luôn.)

Bí ẩn về cái gọi là “Người dùng phổ thông”

Niềm tin vào việc phần lớn người dùng Web cũng giống chúng ta là quá đủ để tạo ra tình huống bế tắc trong
các buổi họp về thiết kế Web. Nhưng đằng sau niềm tin đó lại tồn tại 1 niềm tin khác, thậm chí còn hiểm hơn:
Niềm tin rằng phần lớn người dùng Web sẽ giống với bất cứ ai.

Ngay khi cuộc chiến về quan điểm cá nhân và quan điểm nghề nghiệp tạo ra 1 thế bí, cuộc tranh luận thường
sẽ chuyển sang hướng tìm 1 cách nào đó (hoặc là ý kiến từ 1 chuyên gia bên ngoài, hay các nghiên cứu chính
thức, các cuộc khảo sát, các bài test dựa trên nhóm người dùng, ..) để quyết định xem phần lớn người dùng
Web sẽ thích hay không thích cái gì - để biết được 1 Người dùng phổ thông sẽ trông ra sao, thích cái gì, quan
điểm như nào. Vấn đề duy nhất là… làm gì có cái gọi là “Người dùng phổ thông”.

Trên thực tế, tất cả những lần tôi quan sát người dùng sử dụng Web đã khiến tôi đưa ra 1 kết luận hoàn toàn
đối ngược:
MỌI NGƯỜI DÙNG WEB ĐỀU ĐỘC ĐÁO, VÀ MỌI CÁCH DÙNG WEB ĐỀU LÀ ĐẶC TRƯNG
Bạn càng quan sát nhiều người dùng và lắng nghe họ diễn giải ý định, động lực và quá trình suy nghĩ của họ,
bạn càng dễ nhận ra rằng các phản ứng của mỗi cá nhân với các trang Web thường sẽ dựa trên nhiều biến tới
mức những nỗ lực mô tả hành vi người dùng bằng những khía cạnh 1 chiều như “Thích” hay “Không thích” là
vô vọng - và phản tác dụng.

Và thứ tồi tệ nhất về bí ẩn của Người dùng phổ thông, chính là việc nó củng cố cho cái tư tưởng 1 bản thiết kế
Web tốt hầu hết chỉ xoay quanh việc tìm hiểu xem người ta thích cái gì. Khái niệm nghe cũng bùi tai đấy nhỉ:
Hoặc giao diện drop-down là tốt (vì phần lớn người dùng thích nó), hoặc nó dở (vì phần lớn người dùng ghét
nó). Content kiểu câu truyện / bài chia sẻ chỉ nên đặt ở 1 trang dài, scroll được hoặc là chúng nên được chia
thành nhiều trang nhỏ ngắn hơn, không cần scroll. Giao diện băng chuyền, menu cỡ lớn, etc… sẽ hoặc là tốt
hoặc là dở, hoặc là đen hoặc là trắng.

Vấn đề ở đây là, không có 1 câu trả lời “Đúng” đơn thuần cho phần lớn các câu hỏi liên quan tới thiết kế Web
(ít nhất với những câu hỏi quan trọng thì chắc chắn là không có). Thứ được cho là “tốt” sẽ là những bản
design có khả năng đáp ứng nhu cầu của người dùng - được tính toán kỹ lưỡng, thiết kế thấu đáo, và kiểm tra
cẩn thận.

Tất nhiên không phải tôi muốn nói kiểu như ‘Không có cái gì là sai cả, không có cái gì bạn không nên​ làm cả’.
Có những phương pháp thiết kế trang Web mà chắc chắn là sai lè ra, chẳng qua đó không phải là vấn đề mà
các team xây dựng Web phải tranh cãi, vậy thôi.

Liều thuốc giải cho những cuộc thánh chiến

Điều quan trọng là, việc hỏi những câu hỏi như “Có phải hầu hết người dùng đều thích menu dạng Pull-downs
không?” là không hiệu quả chút nào. Câu hỏi mà bạn cần đặt ra, đó là “Cái loại pull-down này,​ với những item
thông tin như ​này​, trong văn cảnh này​, trên cái trang ​này,​ có tạo ra được 1 trải nghiệm người dùng tốt cho
phần lớn những người sẽ sử dụng trang này​ hay không?”
Và thực sự thì chỉ có 1 cách duy nhất để trả lời kiểu câu hỏi này: Testing. Bạn phải sử dụng các thể loại kĩ
năng, kinh nghiệm, sức sáng tạo và hiểu biết của cả 1 tập thể để có thể xây dựng nên 1 phiên bản nào đó của
sản phẩm (1 phiên bản cùi cùi cũng được), và quan sát kĩ lưỡng quá trình người dùng tìm hiểu sản phẩm đó là
gì và cách nó vận hành ra sao.

Không có đường tắt, không có cách nào khác cả.

Khi mà các cuộc tranh luận về thứ người dùng thích và không thích làm lãng phí thời gian công sức, thì các
cuộc Usability Testing thường có khả năng hoá giải phần lớn các cuộc cãi vã, gỡ các nút thắt bằng cách
chuyển hướng cuộc tranh luận từ lĩnh vực ‘cái nào đúng cái nào sai' / ‘người ta thích hay ghét cái gì' sang lĩnh
vực ‘cái nào hiệu quả, cái nào không’. Và vì Testing tiết lộ cho chúng ta rất nhiều về sự đa dạng trong hành vi,
nguồn động lực, quan điểm và phản ứng của người dùng, thật khó để chúng ta tiếp tục giữ quan điểm rằng tất
cả người dùng Web đều suy nghĩ giống mình.
Làm thế nào để biết các cuộc Usability Testing thực sự có hiệu quả?
Chương tiếp theo sẽ giải thích cho bạn cách test trang web của riêng mình.
Chương 9. Usability Testing giá rẻ, chỉ 1k mỗi ngày
Giữ cho các bài test đơn giản thôi - để bạn có thể test cho đủ.

“Sao mình không làm cái này sớm hơn nhỉ?"

_ Tất cả mọi người, ở 1 thời điểm nào đó, trong lần Usability Testing
đầu tiên cho trang Web của họ_

Tôi từng nhận được kha khá cuộc gọi kiểu này

Ngay khi tôi nghe thấy “ 2 tuần nữa ra mắt trang Web" (hoặc thậm chí 2 tháng luôn) và “Usability Testing"
trong cùng 1 câu, tôi lại bắt đầu có cảm giác mình giống như 1 nhân viên cứu hoả kỳ cựu, tiến về toà nhà
đang cháy phừng phừng, vì tôi biết khá rõ tình hình hiện tại ra sao rồi.

Nếu là 2 tuần, thì kiểu gì cũng là yêu cầu chuyên gia tới kiểm tra xem có thảm hoạ gì sẽ diễn ra không. Ngày
ra mắt sắp tới và ông nào cũng lo sốt vó, và cuối cùng 1 ông phải đề nghị “Chắc là team mình nên thực hiện 1
vài cuộc Usability Testing thôi"

Nếu là 2 tháng, thì khả năng cao là khách hàng cần phải giải quyết 1 vài cuộc tranh luận nội bộ - thường sẽ
liên quan tới vấn đề thẩm mỹ. Các luồng ý kiến trong công ty bị chia rẽ giữa 2 bản design khác nhau; có người
thích bản sexy quyến rũ, có người lại thích bản tinh tế thanh nhã. Cuối cùng ai đó với đủ thẩm quyền chi trả
chi phí Testing trở nên quá mệt mỏi với mấy cuộc cãi nhau sẽ nói “Thôi, muốn biết cái nào ngon hơn thì test
cái là ra!”
Và thi thoảng Test xong cũng ra được kết quả, giải quyết tranh cãi, nhưng trong phần lớn trường hợp thì Test
xong chỉ thấy hoá ra cái thứ mà cả công ty đang cãi nhau lại chẳng quan trọng đến thế. Kiểu họ muốn test để
quyết định xem rèm cửa màu nào là đẹp nhất, nhưng cuối cùng chỉ để nhận ra là, cái phòng đó không có cửa
sổ. Ví dụ, họ sẽ phát hiện ra rằng việc chọn Menu dạng cascading hay menu dạng Mega chẳng khác là mấy,
nếu không ai hiểu được giá trị mà trang Web của họ mang lại.

Gần đây thì tôi không nhận được nhiều những cuộc gọi kiểu như thế nữa, và tôi cho rằng đó là 1 tín hiệu tốt -
giờ đây người ta đã bắt đầu nhận thức được tầm quan trọng của việc đưa Tính khả dụng vào mọi phần trong
mỗi dự án ngay từ đầu.
Đáng buồn là, vẫn có rất nhiều cuộc Usability Testing phải diễn ra như cũ: quá ít lần test, test quá muộn, và
test những thứ chẳng đâu vào đâu

Cả lớp nhắc lại theo thầy: Focus group (Thảo luận nhóm) không phải là Usability testing (Kiểm tra về
Tính khả dụng).

Đôi khi câu hỏi mở màn đó còn đáng sợ hơn:

Khi mà tới phút cuối rồi mà vẫn còn thuê chuyên gia để thực hiện “thảo luận nhóm", thường thì nghĩa là cái
yêu cầu này xuất phát từ đội MKT. Nếu đội MKT cảm thấy trang Web này đang đi sai hướng khi mà ngày ra
mắt đang cận kề, họ sẽ nhận thấy niềm hi vọng cuối cùng và duy nhất của họ để tránh được thảm hoạ tiềm
tàng chính là kêu gọi support từ ai đó / cái gì đó sở hữu thẩm quyền cao hơn: chính là Nghiên cứu thị trường.
Và 1 trong những kiểu nghiên cứu mà họ hiểu rõ nhất chính là Focus groups. Tôi thường phải tốn rất nhiều
công sức giải thích cho khách hàng hiểu là, thứ họ cần là Usability testing, không phải Focus groups - nhiều
tới mức cuối cùng tôi đã làm hẳn 1 clip hoạt hình nho nhỏ cho bõ tức.
(​someslightlyirregular.com/2011/08/you-say-potato​).

Túm cái quần lại, thì sự khác biệt như sau:

- Trong 1 F ​ ocus group (Thảo luận nhóm), 1 nhóm người dùng nhỏ (thường là 5 tới 10 người) ngồi với
nhau và bàn luận về các chủ đề như ý kiến của họ về sản phẩm, trải nghiệm cũ của họ với sản phẩm
đó, hoặc phản ứng của họ về các concept mới. Focus group có hiệu quả khi bạn muốn có bản mẫu về
cảm xúc và ý kiến của người dùng 1 cách nhanh chóng.
- Trong 1 U ​ sability testing (Kiểm tra về tính khả dụng), chúng ta sẽ quan sát từng người một sử dụng
1 cái gì đó (có thể là trang Web, 1 bản prototype, 1 vài bản thiết kế dc vẽ tay, etc...) để làm 1 task nhất
định nào đó, và từ đó bạn có thể dò ra thứ mà khiến người dùng bực bội, bối rối và cải thiện.

Sự khác biệt cơ bản, đó là trong các cuộc Usability Testing, bạn sẽ quan sát người ta thực sự sử dụng sản
phẩm, thay vì chỉ lắng nghe họ nói về chúng.

Thảo luận nhóm có thể phù hợp để quyết định về nhu cầu và sở thích của tập khách hàng - trong khái niệm
trừu tượng. Chúng sẽ hiệu quả khi dùng để test xem liệu 1 ý tưởng trong trang Web của bạn có dễ hiểu hay
không, và giá trị của trang Web có được trình bày hấp dẫn và thu hút hay không, để hiểu thêm về cách người
dùng đang giải quyết các vấn đề mà có thể chính trang Web của bạn sẽ giúp họ giải quyết sau này, và để biết
xem họ cảm thấy như nào về dịch vụ của bạn, cũng như của các đối thủ khác.
Nhưng chúng hoàn toàn không phù hợp cho việc kiểm tra xem liệu trang Web của bạn có hoạt động tốt hay
không, và làm thế nào để cải thiện điều đó.
Các dữ liệu bạn có được từ Focus group - kiểu như liệu bạn có đang xây dựng đúng sản phẩm hay không - là
những thứ mà bạn phải biết trước khi bắt đầu thiết kế / xây dựng bất cứ cái gì, nên Focus group nên được tiến
hành trong giai đoạn Planning (lên kế hoạch) của 1 dự án. Các cuộc Usability test thì khác, chúng cần được
tiến hành trong suốt cả quá trình dự án diễn ra.

Một vài điều chính xác về Usability testing.

Đây là những điều trọng yếu mà tôi biết về các cuộc Usability Testing.
- Nếu bạn muốn 1 trang Web ngon nghẻ, bạn phải tiến hành Test. Một khi bắt tay vào làm 1 trang
Web, dù chỉ là vài tuần thôi, bạn sẽ không có cái nhìn khách quan về nó nữa. Bạn đã biết nó quá rõ rồi.
Cách duy nhất để biết được xem nó có hiệu quả hay không, chính là quan sát người khác sử dụng nó.
Việc test này nhắc nhở bạn rằng không phải ai cũng suy nghĩ như mình, biết thứ mình đã biết, và sử
dụng Web giống hệt cách mình sử dụng Web.
Tôi từng nói, cách tốt nhất để nghĩ về cái việc test này, là nó cũng giống như đi du lịch vậy: 1 trải
nghiệm mở mang tầm mắt. Việc này nhắc nhở chúng ta rằng mỗi người giống và khác nhau ra sao, và
cho ta 1 góc nhìn mới trong mọi vấn đề. (bên Lean Startup thì họ mô tả rằng, việc này đưa bạn đi khỏi
văn phòng, ra ngoài nhìn ngắm thế giới)
Nhưng cuối cùng thì tôi nhận ra rằng, việc test này thực sự giống kiểu.. có bạn bè ở nơi khác tới thăm
mình hơn. Khi bạn dắt thằng bạn đi 1 vòng thăm thú thành phố, kiểu gì bạn cũng nhận ra những thứ
mới mẻ về thành phố của mình mà bình thường bạn không để ý, vì bạn đã quá quen thuộc với chúng.
Và cùng lúc đó, bạn nhận ra rằng có rất nhiều thứ mà bạn vốn coi nó là đương nhiên, thì lại không hề
như vậy với mọi người khác.

- Test dù chỉ 1 người dùng vẫn hơn là không test được ai. Test thì lúc nào cũng sẽ hiệu quả, và kể
cả những cuộc test tệ nhất, trên những người dùng không liên quan nhất, cũng chỉ cho bạn 1 vài điều
bạn có thể làm để cải thiện sản phẩm. Khi tôi tổ chức các buổi workshops, tôi thường cố gắng thực
hiện 1 cuộc Usability Testing trực tiếp, để người ta có thể thấy việc Test này nó đơn giản ra sao, và
mang lại các thông tin có giá trị như nào.
Tôi yêu cầu 1 người tình nguyện thử làm 1 cái task trên 1 trang Web ngẫu nhiên của 1 người khác
trong buổi workshop. Những cuộc Test này chỉ kéo dài dưới 15’, nhưng trong thời gian đó cái người
chủ trang Web kia cũng phải note lại tới vài trang giấy chứa đầy thông tin có giá trị. Và họ luôn hỏi xin 1
bản video của cuộc Test để về cho công ty xem. (Có ông kể là sau khi công ty xem được cuộc Test đó
diễn ra, họ đã sửa đổi 1 thứ trên trang Web của mình, và sau này họ tính toán được rằng việc cải thiện
1 thứ đó đã giúp công ty tiết kiệm được tận $100,000 chi phí)

- Test 1 người vào đầu dự án có hiệu quả hơn test 50 người vào gần cuối dự án. Phần lớn mọi
người nghĩ rằng các cuộc Test cần phải hoành tráng. Nhưng nếu bạn làm hoành tráng thì lại bạn sẽ
không có đủ sức lực và tâm huyết để làm nó đủ sớm, và đủ thường xuyên để thu thập được đủ thông
tin hữu ích. Một cuộc Test đơn giản, sớm đúng lúc - khi mà bạn vẫn có đủ thời gian để áp dụng thứ
bạn học được từ cuộc Test đó - luôn có giá trị hơn nhiều so với 1 cuộc Test chi tiết, hoành tráng sau
này.
 Một quan điểm phổ biến về việc xây dựng trang Web là việc thay đổi các thứ thường không quá phức
tạp. Nhưng sự thật là, việc thay đổi này không hẳn là dễ - nhất là với những thay đổi ở quy mô lớn - khi
trang Web đã đi vào vận hành. Một phần nhỏ người dùng sẽ từ chối thích nghi với hầu hết bất cứ loại
thay đổi nào, và kể cả những thay đổi nho nhỏ hóa ra cũng có hậu quả khôn lường. Bất kì lỗi nào mà
bạn sửa được ở giai đoạn đầu cũng sẽ giúp bạn tránh được vô vàn rắc rối về sau.

Usability testing tự chế

Cái gọi là Usability testing (Kiểm tra về Tính khả dụng) đã tồn tại rất lâu rồi, và ý tưởng căn bản của nó cũng
rất đơn giản: Nếu bạn muốn biết liệu cái này có đủ dễ dùng không, hãy quan sát người khác sử dụng nó và
ghi chú lại những chỗ mà họ gặp khó khăn.
Trong thời gian đầu, những cuộc kiểm tra về Tính khả dụng là 1 yêu cầu khá tốn kém. Bạn phải có 1 phòng thí
nghiệm với 1 phòng quan sát đằng sau 1 cửa kính 1 chiều, và hệ thống camera để quay lại phản ứng và hành
vi của người dùng khi thao tác với màn hình. Bạn cũng phải trả tiền cho 1 chuyên gia về Tính khả dụng để lên
kế hoạch và điều phối cuộc Kiểm tra. Và bạn cũng phải tuyển kha khá ứng viên (tôi gọi họ là “ứng viên” thay vì
“đối tượng nghiên cứu” để làm rõ rằng thứ được nghiên cứu và kiểm tra ở đây là sản phẩm của tôi, trang Web
của tôi, chứ không phải bọn họ) thì mới có được đủ kết quả cho việc thống kê. Nó tốn kém và cần chuẩn bị kĩ
lưỡng chính xác như 1 cuộc Thí nghiệm khoa học vậy. Mỗi lần tiến hành có khi phải mất khoảng $20,000 tới
$50,000. Nên thường thì chúng không diễn ra nhiều.
Sau đó vào năm 1989, Jakhôngb Nielsen viết 1 bài báo có tựa đề “Tinh chỉnh Tính khả dụng với giá cả hợp lý”
và chỉ ra rằng mọi thứ không nhất thiết phải tốn nhiều chi phí thế. Bạn không cần cả 1 cái phòng thí nghiệm và
phòng quan sát, và bạn có thể đạt được kết quả tương tự với số lượng ứng viên ít hơn nhiều. Chi phí cho mỗi
lần Kiểm tra giảm xuống còn khoảng $5000 - $10000.
Ý tưởng tinh gọn các cuộc Kiểm tra về Tính khả dụng này là 1 bước tiến lớn. Vấn đề duy nhất là, sản phẩm
nào cũng cần test, và $5000 hay $10000 thì vẫn là khá nhiều tiền, nên các cuộc Kiểm tra cũng không nhiều
hơn là bao.
Thứ mà tôi chuẩn bị trình bày với bạn trong chương này là 1 thứ thậm chí còn đơn giản hơn nữa (và cũng tốn
ít tiền hơn nhiều): các cuộc Kiểm tra về Tính khả dụng kiểu tự chế.
Tôi sẽ giải thích cho bạn cách tự tiến hành Kiểm tra về Tính khả dụng, khi mà bạn không có tiền hay thời gian.

Đừng hiểu sai ý tôi, nếu bạn có thể thuê dân chuyên để tiến hành Testing, thì hãy thuê luôn. Khả năng cao là
họ sẽ thể làm tốt hơn bạn rất nhiều. Nhưng nếu không thuê được thì tự triển thôi.

Tôi tin vào giá trị của phương pháp này đến mức tôi đã viết hẳn 1 cuốn sách (ngắn) giải thích cách làm theo
phương pháp đó. Cuốn sách gọi là “Rocket surgery made easy:…”. Cuốn sách cũng có bao gồm nội dung của
chương này, nhưng chi tiết hơn nhiều và có hướng dẫn từng bước cho cả quá trình thực hiện phương pháp.
Bạn nên tiến hành Test bao nhiêu lần là đủ?

Tôi nghĩ đội phát triển Web nào cũng nên dành 1 buổi mỗi tháng thực hiện 1 cuộc Usability Testing. Trong 1
buổi sáng bạn có thể test 3 người, và họp thảo luận về kết quả trong bữa trưa. Thế là xong. Sau buổi họp, cả
đội sẽ quyết định được thứ mình sẽ sửa đổi trước lần test tiếp theo, và thế là cả tháng đó bạn sẽ không cần
test thêm nữa. (Nếu bạn đang làm theo mô hình AGILE, bạn sẽ phải test thường xuyên hơn, nhưng các
nguyên tắc thì không đổi. Ví dụ, cứ 2 tuần là bạn cần test đủ 2 người. Tạo 1 lịch test cố định và tuân thủ lịch
trình đó mới là thứ quan trọng)

Vậy sao lại chỉ cần 1 buổi sáng mỗi tháng thôi?

- Quy mô như vậy đơn giản hơn, và bạn sẽ dễ tuân thủ lịch trình hơn. Phần lớn các team chỉ có thể dành
ra 1 buổi sáng mỗi tháng để tiến hành Test thôi. Nếu mọi thứ quá phức tạp hay tốn thời gian, tới lúc project
nhiều việc lên bạn chẳng có thời gian hay công sức mà làm đâu.

- Thế là đủ để đạt được thứ bạn cần. Theo dõi 3 ứng viên là đủ để bạn tìm ra được các vấn đề cần giải
quyết, các vấn đề đó cũng đủ để bạn bận rộn cho tới lần test tiếp theo.

- Bạn không cần phải quyết định khi nào sẽ test nữa. Bạn chỉ cần chọn 1 ngày trong tháng, như ngày Thứ
2 đầu tiên hàng tháng – và định luôn ngày đó là ngày Test. Điều này tốt hơn nhiều so với việc đưa ra các cuộc
Test dựa trên các mốc dự án và sản phẩm bàn giao. (“Chúng ta sẽ tiến hành Test khi chuẩn bị ra bản Beta), vì
lịch trình thường sẽ bị lệch và các cuộc Testing sẽ bị lệch theo. Đừng lo, kiểu gì cũng có thứ cho bạn Test
hàng tháng.

- Có nhiều khả năng mọi người sẽ tham gia hơn. Tiến hành Test trong 1 buổi sáng duy nhất theo 1 lịch cố
định sẽ làm tăng khả năng các thành viên trong team sẽ sắp xếp được thời gian để tham gia và quan sát ít
nhất 1 phần, và chỉ cần thế là tốt rồi.

Bạn sẽ cần bao nhiêu ứng viên?

Tôi nghĩ con số lý tưởng của mỗi lần Test là 3 người.

Có người sẽ phàn nàn rằng 3 là không đủ. Họ cho rằng đó là con số quá nhỏ để chứng minh bất cứ điều gì, và
Test ít người như vậy sẽ không bóc tách được hết được các vấn đề. Cả 2 điều này đều đúng, và đây là lý do
tại sao:

- Mục đích của kiểu Testing này không phải là để chứng minh cái gì cả. Chứng minh 1 điều gì đó yêu
cầu bạn phải thực hiện Kiểm tra định lượng, với số lượng mẫu vật lớn, và 1 quy trình kiểm tra được xác định
rõ ràng và tuân thủ nghiêm ngặt, và cần phải thu thập data và phân tích cẩn thận.

Các cuộc Testing tự chế là phương pháp Kiểm tra định tính, và mục đích của nó là để cải thiện sản phẩm mà
bạn đang xây dựng bằng cách xác định và khắc phục các vấn đề về Tính khả dụng. Quy trình của nó không
hề phức tạp chút nào: Bạn cho các ứng viên thực hiện các task, bạn quan sát và học hỏi. Kết quả chính là các
thông tin dữ liệu mà dựa vào đó chúng ta có thể đưa ra các quyết định và hành động, chứ không phải các
bằng chứng.

- Bạn không cần phải tìm ra tất cả các vấn đề. Trên thực tế, bạn sẽ không bao giờ tìm ra được tất cả các
vấn đề trong mọi thứ bạn Test. Và kể cả bạn có tìm ra được hết thì cũng không giải quyết được gì, vì sự thật
là:

Số lượng vấn đề bạn tìm ra trong 1 buổi có thể nhiều hơn số lượng vấn đề bạn có thể giải quyết trong 1 tháng.

Bạn sẽ luôn ở trong hoàn cảnh lỗi thì 1 rổ nhưng không còn lực để khắc phục chúng, nên quan trọng là bạn
tập trung vào cải thiện những lỗi nghiêm trọng trước đã. Và 3 người test hoàn toàn có thể gặp phải những vấn
đề phổ biến nhất liên quan tới thứ mà bạn đang cần test.

Thêm nữa, sang tháng sau kiểu gì bạn chả làm 1 cuộc Test nữa. VIệc làm được nhiều lần test quan trọng hơn
nhiều việc cố gắng vắt kiệt mọi dữ liệu và vấn đề từ mỗi lần test.

Làm thế nào để chọn ứng viên?

Khi các team quyết định tiến hành Test, họ thường tốn nhiều thời gian tìm những người dùng mà họ cho là sẽ
phản ánh đúng tập khách hàng của họ - ví dụ “Nam nhân viên kế toán, độ tuổi từ 25 tới 30, có 1 tới 3 năm kinh
nghiệm làm việc máy tính, vừa mua giày đắt tiền”

Việc thực hiện Test trên những ứng viên có vẻ giống với tập khách hàng cũng tốt, nhưng thực ra tuyển chọn
những người thuộc tập khách hàng cũng không quan trọng đến thế. Với nhiều trang Web, bạn có thể tiến
hành Test với hầu như bất cứ ai. Và nếu bạn mới tiến hành lần đầu, khả năng cao là trang web của bạn cũng
có những lỗi về Tính khả dụng cơ bản mà hầu như người dùng nào cũng sẽ gặp phải.

Việc tuyển dụng những người thuộc 1 bản profile chi tiết thường sẽ tốn nhiều công sức và tiền của hơn. Nếu
bạn có nhiều thời gian để tuyển người hoặc có thể thuê ai đó để làm công tác tuyển dụng giúp bạn, thì thôi cứ
tuyển kĩ kĩ chi tiết cũng được. Nhưng nếu việc tìm ra người dùng tiềm năng khiến cho bạn rơi vào hoàn cảnh
phải làm Testing ít đi, tôi khuyên bạn nên thử 1 cách tiếp cận khác:

TUYỂN CHỌN RỘNG RÃI VÀ ĐÁNH GIÁ CHI TIẾT

Nói theo cách đơn giản, thì bạn cứ thử tìm những người dùng thuộc tập khách hàng tiềm năng, nhưng cũng
đừng lăn tăn về việc đó quá. Thay vào đó thì nới lỏng các yêu cầu tuyển chọn và cân nhắc những sự khác biệt
giữa ứng viên thực tế và tập khách hàng tiềm năng. Khi ứng viên gặp vấn đề, hãy tự hỏi “Liệu người dùng
thuộc tập khách hàng tiềm năng có vấp phải cùng vấn đề đó không, hay là chỉ những ai không thuộc tập khách
hàng thì mới gặp những vấn đề kiểu này?”

Nếu việc sử dụng sản phẩm của bạn đòi hỏi kiến thức nhất định về 1 lĩnh vực nào đó (ví dụ 1 trang Web trao
đổi tiền tệ dành riêng cho dân quản lý tài chính chuyên nghiệp), thì đúng là bạn sẽ cần tuyển 1 vài người thuộc
mô tả đó. Nhưng không cần toàn bộ số lượng ứng viên nhé, vì nếu đã là lỗi căn bản về Tính khả dụng thì
phần lớn là những thứ mà ai cũng sẽ gặp phải thôi.

Trên thực tế, tôi thường thích tuyển 1 vài ứng viên không thuộc tập khách hàng tiềm năng, vì 3 lý do chính:

- Thiết kế 1 trang Web mà chỉ những đối tượng khách hàng tiềm năng sử dụng được thường
không phải là nước đi hay. Kiến thức chuyên ngành cũng muôn hình vạn trạng, và giả sử bạn thiết
kế 1 trang Web cho các nhà quản lý tài chính, sử dụng các thuật ngữ mà bạn nghĩ hội quản lý tài chính
sẽ hiểu hết, thì chắc chắn bạn sẽ khám phá ra rằng vẫn sẽ có 1 số lượng nhỏ (nhưng không phải
không đáng kể) trong số họ không hiểu hết các thuật ngữ đó. Và thường thì bạn sẽ cần phải thiết kế
cho cả dân không chuyên lẫn chính chuyên cả thôi.
- Ai trong số chúng ta cũng đều là người mới học cả. Nhìn sâu hơn vào 1 người được coi là chuyên
gia, và thường bạn sẽ bắt gặp người đó cũng đang trong quá trình học hành của riêng họ, chỉ là họ đã
tiếp nhận được 1 lượng kiến thức lớn hơn thôi.
- Dân chuyên thường không bị khó chịu chỉ vì 1 sản phẩm nào đó dễ hiểu đối với người mới bắt
đầu. Ai cũng thích sự minh bạch rõ ràng. (Sự minh bạch rõ ràng, chứ không phải 1 cái gì đó bị cắt tỉa
đi, sao cho trông nó sơ sài và dễ hiểu). Nếu gần như ai cũng dùng được sản phẩm, thì mấy ông dân
chuyên cũng dùng được mà.

Làm thế nào để tìm ứng viên?

Bạn có thể tuyển ứng viên ở rất nhiều chỗ, bằng rất nhiều cách, ví dụ như các buổi workshops, các nhóm
Facebook, trên Twitter, trên các forum công nghệ, hoặc 1 cái quảng cáo dạng pop-up trên trang Web của bạn,
hoặc đơn giản hơn nữa là hỏi bạn bè người quen.
Nếu bạn định tự đi tuyển ứng viên, tôi gợi ý bạn tải chùa bản báo cáo dài 147 trang của Nielsen Norman
Group “Cách tuyển chọn ứng viên cho các nghiên cứu về Tính khả dụng”. Bạn không phải đọc hết, nhưng đó
là 1 kho lời khuyên cực kì hữu ích.
Mức thù lao phổ biến cho người dùng bình thường trong 1 cuộc Test kéo dài 1 tiếng dao động vào khoảng
$50 tới $100, còn với những người có ngành nghề chuyên nghiệp, được trả lương cao, thời gian biểu bận rộn
(như nhà tâm lý, bác sĩ, chuyên gia tài chính, etc..) thì con số sẽ rơi vào khoảng vài trăm đô.
Tôi muốn trả cho mọi người nhiều hơn 1 chút so với mức hiện tại, vì tôi muốn họ biết rằng tôi tôn trọng thời
gian công sức của họ, và việc trả nhiều hơn nghĩa là họ cũng chủ động tham gia hơn. Nhớ là kể cả khi cuộc
Test chỉ diễn ra trong 1 tiếng, người ta còn mất thời gian đi lại di chuyển nữa mà.

Ai là người tiến hành Testing?

Người điều phối (facilitator) là người sẽ hướng dẫn các ứng viên trong suốt quá trình Testing. Hầu hết tất cả
mọi người đều có thể điều phối 1 cuộc Usability Testing. Bạn chỉ cần dám làm điều đó, và bạn sẽ thực sự trở
thành 1 điều phối ổn ổn một khi đã quen việc.
Tôi cũng đoán là bạn sẽ tự điều phối cuộc Test thôi, nhưng nếu không thì hãy cố gắng chọn ai đó có tính cách
kiên nhẫn, điềm tĩnh, thông cảm, biết lắng nghe. Đừng chọn ai đó không hoà đồng, hoặc không biết đối đáp
với mọi người.
Ngoài việc giữ cho mọi người thoải mái và tập trung vào cuộc Test, nhiệm vụ chủ yếu của người điều phối là
khuyến khích các ứng viên nói ra thứ mình nghĩ càng nhiều càng tốt. Sự kết hợp giữa quan sát hành động của
họ và lắng nghe điều họ đang nghĩ khi làm hành động đó chính là thứ giúp cho các quan sát viên (chúng ta)
nhìn thấy sản phẩm của mình qua con mắt của người khác, và hiểu được tại sao có những thứ tưởng như rõ
ràng với mình nhưng lại khó hiểu với người dùng.

Ai là người quan sát?

Càng nhiều càng tốt chứ sao!

Một trong những thứ giá trị nhất về việc làm Testing về Tính khả dụng, đó là tác động nó mang lại tới những ai
tham gia quan sát. Với nhiều người, đây là 1 trải nghiệm mang tính chuyển đổi, giúp họ thay đổi đáng kể quan
điểm của họ về người dùng: Họ bỗng nhiên hiểu được rằng không phải người dùng nào cũng giống mình.
Bạn nên cố khuyến khích mọi người - từ thành viên tới các stakeholder, tới các quản lý cấp thấp cấp cao - tới
tham gia quan sát buổi Test. Trên thực tế, nếu mà team còn budget cho việc testing, tôi khuyên các bạn dành
tiền đó mua đồ ăn vặt thật ngon để dụ dỗ người ta vào xem. (Bánh socola hiệu quả cực kì.)
Bạn sẽ cần 1 phòng quan sát (thường là phòng họp chung), 1 chiếc laptop có phần mềm share màn hình, 1
màn hình cỡ lớn hoặc máy chiếu, và nếu được thì thêm 1 cặp loa để ai cũng có thể nghe và thấy được những
thứ đang diễn ra ở phòng Test.
Trong giờ nghỉ giữa mỗi lượt Test, những quan sát viên cần phải viết ra 3 vấn đề về Tính khả dụng nghiêm
trọng nhất mà họ thấy được, để sau đó có thể chia sẻ và thảo luận trong buổi họp báo cáo. Form thì bạn có
thể tự tạo hoặc tải trên Web của tôi. Họ có thể ghi chú bao nhiêu cũng được, nhưng riêng cái danh sách 3 vấn
đề này thì họ phải làm, vì bạn thấy đấy, mục đích của việc họp báo cáo chính là xác định ra các vấn đề nghiêm
trọng nhất để tập trung cải thiện chúng trước.
Bạn nên test cái gì, và khi nào?

Mọi chuyên gia về Tính khả dụng sẽ đồng ý rằng, việc test càng sớm càng tốt và test đều đặn, xuyên suốt quá
trình làm sản phẩm là rất quan trọng.
Trên thực tế, thì bạn có thể Test sớm tới mức nào cũng được. Kể cả khi bạn còn chưa thiết kế Web của mình,
thì bạn vẫn có thể test các Web đối thủ cạnh tranh để học hỏi. Chúng có thể là đối thủ cạnh tranh trực tiếp,
hoặc chỉ đơn giản là các trang Web có cùng style, cùng cấu trúc, hoặc cùng tính năng mà trang của bạn muốn
có. Mời 3 ứng viên về và quan sát họ làm 1 số task cơ bản trên 1 vài trang Web của đối thủ và bạn sẽ học hỏi
được thêm kha khá điều mà không cần phải design hay build cái gì cả.
Nếu bạn phải thiết kế lại 1 trang Web đã có sẵn, bạn cũng cần phải test nó trước khi bắt đầu, để biết được cái
gì đang làm việc thiếu hiệu quả (và cần phải thay đổi) và cái gì đang làm tốt (để không làm gì ảnh hưởng tới
nó)
Sau đó xuyết suốt dự án, hãy cứ tiếp tục tiến hành Test mọi thứ team bạn làm ra, bắt đầu với những phải vẽ
tay thô sơ và tiếp tục tới những bản wireframe, các prototype, và cuối cùng là các trang Web thực.

Làm thế nào để chọn được task nào cần phải test?

Với mỗi vòng Testing, bạn sẽ phải nghĩ ra các tasks nào đó: thứ mà các ứng viên sẽ phải làm.
Các task mà bạn test trong mỗi vòng sẽ phụ thuộc vào những tính năng nào bạn đã có sẵn trong sản phẩm
của mình để test. Nếu bạn chưa có gì, chỉ có 1 bản vẽ tay, thì có thể các task sẽ chỉ đơn giản là Ứng viên xem
qua các bản vẽ tay đó là nói cho bạn biết thứ họ nhìn thấy là gì.
Còn nếu bạn có cái gì đó phức tạp hơn, thì hãy bắt đầu bằng việc làm 1 cái danh sách liệt kê các task mà
người dùng cần phải làm được với thứ mà bạn định test. Ví dụ, nếu bạn đang test 1 bản prototype của 1 quy
trình Đăng nhập, các task có thể bao gồm:
Tạo tài khoản
Đăng nhập bằng username đã có từ trước và password
Lấy lại mật khẩu đã quên
Lấy lại username đã quên
Thay đổi câu hỏi bảo mật
Hãy chọn đủ task cho khối lượng thời gian Test (khoảng 35’ tới 1 tiếng), hãy nhớ rằng có người sẽ làm các
task nhanh hơn là bạn tưởng.
Sau đó hãy đặt tên cho các task thật kĩ lưỡng, để các ứng viên hiểu rõ chính xác thứ bạn muốn họ làm. Cho
họ các thông tin mà họ cần, ví dụ như thông tin đăng nhập demo nếu bạn muốn ứng viên làm 1 task gì đó cần
đăng nhập tài khoản thì mới làm được.
Bạn sẽ thường có được kết quả thú vị hơn nếu bạn cho phép người dùng quyết định 1 số cái chi tiết trong task
đó. Ví dụ, sẽ tốt hơn nhiều nếu bạn ra Task là “Tìm 1 cuốn sách bạn muốn mua, hoặc 1 cuốn sách bạn mới
mua gần đây”, thay vì “Tìm 1 cuốn sách về nấu ăn giá dưới $14”. Điều này làm tăng sự đầu tư về cảm xúc và
cho phép họ sử dụng nhiều kiến thức và kinh nghiệm cá nhân trong lĩnh vực đó hơn.

Điều gì xảy ra trong cuộc Test?

Bạn có thể tải kịch bản mà tôi hay dùng để Test các trang Web (hoặc là phiên bản Test các app) tại trang
rocketsurgerymadeeasy.com​. Tôi khuyên bạn nên đọc các câu “thoại” chính xác như đã viết, bởi vì tôi đã
chỉnh sửa từ ngữ rất kĩ lưỡng.
1 cuộc Test kéo dài 1 tiếng thông thường sẽ được chia nhỏ ra thành các phần như sau:
- Giới thiệu (4 phút): Bạn bắt đầu bằng việc giải thích cách bài Test vận hành để các ứng viên biết mình
cần làm gì và trông chờ những thứ như thế nào.
- Câu hỏi (2 phút): Tiếp theo, bạn hỏi các ứng viên 1 vài câu hỏi về bản thân. Điều này giúp cho họ thoải
mái hơn và cho bạn biết được họ thông thạo về công nghệ / máy tính tới mức nào.
- Giới thiệu về Homepage (3 phút): Sau đó bạn mở cái trang Homepage của trang Web mà bạn định
Test lên, yêu cầu các ứng viên nhìn qua rồi chia sẻ cảm nghĩ và ý hiểu của họ về trang Homepage.
Điều này giúp bạn biết trang Homepage của mình dễ hiểu tới mức độ nào, và các ứng viên của bạn
biết về sản phẩm đó nhiều tới mức nào.
- Làm các tasks​ (35 phút): Đây là trọng tâm của cuộc Test: Quan sát các ứng viên thử làm 1 chuỗi các
task (hoặc trong 1 vài trường hợp khác - làm 1 task lớn duy nhất). 1 lần nữa, nhiệm vụ của bạn là đảm
bảo các ứng viên tập trung vào làm các task và nói ra cảm nghĩ của mình khi làm chúng.
Nếu ứng viên mải làm quá mà quên mất không nói ra thứ họ nghĩ, hãy khơi gợi họ - “Bạn nghĩ gì về
task này?” (Để cho đa dạng thì bạn cũng có thể nói “Bạn đang xem khu vực nào thế?” hay “Giờ bạn
đang làm tới phần nào rồi?”)
Trong giai đoạn này của cuộc Test, điều quan trọng là bạn phải để họ tự làm các task và tránh nói hay
làm điều gì gây ảnh hưởng tới cách họ làm. Đừng hỏi họ những câu hỏi mang tính dẫn dắt, và đừng
cho họ thêm manh mối hay sự hỗ trợ nào, trừ khi họ đang bị kẹt cứng ở 1 chỗ nào đó và rất rất bực
bội. Nếu họ cần sự trợ giúp, cứ nói mấy câu kiểu như “Nếu tôi không có ở đây thì bạn sẽ làm gì?”
 - Thăm dò​ (5 phút): Sau khi làm xong các task, bạn có thể hỏi các ứng viên về bất cứ thứ gì đã diễn ra
trong cuộc Test, hay bất cứ câu hỏi nào mà các quan sát viên muốn bạn hỏi các ứng viên.
- Kết thúc (5 phút): Cuối cùng, cảm ơn các ứng viên đã dành thời gian, thanh toán chi phí và tiễn họ về.

Một cuộc Test mẫu

Đây là 1 bản cut từ 1 cuộc Test thông thường (tuy không có thật). Tên của ứng viên là Janice, 25 tuổi.

---------------------------------------------------------------------------------------------------------------------------------------------------
Giới thiệu
---------------
Xin chào, Janice. Tên tôi là Steve Krug và tôi sẽ hướng dẫn bạn trong cuộc Kiểm tra này.
Trước khi bắt đầu, tôi có một số thông báo cho bạn, và tôi sẽ đọc nó ra để đảm bảo rằng tôi đã trình bày đầy
đủ mọi thứ.
Có lẽ bạn đã biết rõ tại sao chúng ta ở đây hôm nay, nhưng tôi vẫn sẽ tóm tắt lại 1 lần nữa. Chúng tôi đang
xây dựng 1 trang Web, và chúng tôi cần kiểm tra nó để có thể thấy được người dùng sẽ sử dụng nó ra sao.
Cuộc kiểm tra sẽ kéo dài khoảng một tiếng.
Tôi muốn làm rõ luôn rằng thứ chúng tôi đang thử nghiệm là trang web, chứ không phải bạn. Dù bạn có làm gì
thì bạn cũng không phải là người sai. Trên thực tế, đây có lẽ là cái nơi duy nhất mà bạn không phải lo lắng về
việc mắc lỗi.
Chúng tôi muốn nghe chính xác những gì bạn nghĩ khi sử dụng trang Web này, vì vậy xin đừng lo lắng rằng
bạn sẽ làm tổn thương cảm xúc của chúng tôi. Chúng tôi muốn cải thiện nó, vì vậy chúng tôi cần biết những gì
bạn thực sự nghĩ về nó.
Khi chúng ta tiến hành cuộc Kiểm tra, tôi sẽ thường xuyên yêu cầu bạn nói ra cảm nghĩ của mình, nói ra
những điều bạn đang nghĩ trong đầu. Điều này sẽ giúp chúng tôi rất nhiều trong quá trình Kiểm tra.
Nếu bạn có câu hỏi, cứ hỏi thoải mái. Tôi có thể không trả lời được ngay, vì chúng tôi chú trọng vào cách mọi
người sử dụng Web khi không có ai ngồi bên cạnh để giúp đỡ, nhưng tôi sẽ cố gắng trả lời bất kỳ câu hỏi nào
bạn muốn hỏi khi chúng tôi hoàn thành cuộc Kiểm tra.
Và bất cứ lúc nào bạn cần nghỉ ngơi thì cứ nói cho tôi biết nhé.
Đề cập tới chuyện này là rất quan trọng, vì khi tiến hành cuộc Kiểm tra thì các ứng viên sẽ có câu hỏi,và việc
không phản hồi câu hỏi luôn và ngay sẽ có vẻ bất lịch sự. Bạn cần phải làm rõ rằng việc không phản hồi này
không mang tính tư thù, và bạn vẫn sẽ cố gắng phản hồi các câu hỏi sau khi cuộc Kiểm tra kết thúc, nếu họ
vẫn thắc mắc.

Bạn hẳn đã nhìn thấy chiếc microphone này. Nếu bạn cho phép, chúng tôi sẽ record lại những gì xảy ra trên
màn hình và những gì bạn nói. Bản record sẽ chỉ được sử dụng để giúp chúng tôi tìm ra cách cải thiện trang
web và không ai có thể xem bản record đó ngoại trừ những người làm việc trong dự án. Nó cũng giúp các điều
phối viên như tôi kha khá, vì tôi không phải ghi chép quá nhiều nữa.
Ngoài ra, có một vài người trong nhóm thiết kế Web đang quan sát cuộc Kiểm tra này ở 1 phòng khác. (Họ
không thể nhìn thấy những gì diễn ra trong phòng này, chỉ thấy được màn hình của bạn thôi.)
Tới lúc này, phần lớn mọi người sẽ đùa lại “Chắc tôi không bị cho lên haivl hay beatvn đâu nhỉ?”
Nếu được, thì tôi sẽ yêu cầu bạn ký 1 bản form đồng thuận đơn giản, form đó là về việc chúng tôi đã có sự
đồng thuận của bạn trong việc quay chụp tư liệu, nhưng các tư liệu chỉ được xem bởi những thành viên thuộc
dự án.
Bạn có câu hỏi gì nữa không? Okay, vậy chúng ta tiến hành thôi.

Bạn có thể tham khảo Bản form đồng thuận mẫu và các loại form hữu ích khác tại trang
rocketsurgerymadeeasy.com​.

Câu hỏi
---------------
Trước khi chúng ta cùng xem qua trang web, tôi muốn hỏi bạn một vài câu hỏi ngắn. Đầu tiên, nghề nghiệp
của bạn là gì?

“Tôi là một nhân viên định tuyến.”

Tôi chưa bao giờ nghe nói về công việc này luôn. Chính xác thì một nhân viên định tuyến làm gì mỗi ngày
vậy?
“Tôi tiếp nhận đơn đặt hàng và gửi chúng đến đúng phòng ban chịu trách nghiệm xử lý đơn hàng đó. Tôi làm
việc tại một công ty đa quốc gia khá lớn, vì vậy có rất nhiều thứ cần được sắp xếp và phân bố.”

Tôi hiểu rồi. Bây giờ tôi muốn hỏi thêm, bạn ước tính việc sử dụng Internet, bao gồm cả lướt web giải trí và
email cá nhân của mình chiếm khoảng bao nhiêu giờ một tuần? Chỉ là một ước tính đại khái thôi cũng được.
Tôi thấy việc bắt đầu với một vài câu hỏi để biết được đại khái Ứng viên là ai và cách họ sử dụng Internet là
khá tốt. Điều này khiến họ cảm thấy thoải mái hơn và tạo ấn tượng tốt rằng chúng ta đang chăm chú lắng nghe
những gì họ nói, và không có câu trả lời nào là sai hay đúng.
Đừng ngần ngại thừa nhận sự thiếu hiểu biết của bạn về bất cứ điều gì. Vai trò của bạn ở đây không phải là
thể hiện như một chuyên gia, mà là một người biết lắng nghe.

“Ồ, tôi cũng chẳng rõ nữa. Có lẽ là 4 tiếng mỗi ngày khi ở công ty, và có thể là 8 tiếng một tuần khi ở nhà. 8
tiếng này chủ yếu rơi vào ngày cuối tuần. Buổi tối đi làm về mệt rồi sức đâu mà lên mạng nữa. Nhưng thi
thoảng tôi thích chơi game ấy mà.”

Tỉ lệ giữa việc sử dụng Email và lướt Web là gì - chỉ cần 1 con số ước lượng thôi cũng được.

“Thì ở công ty thì hầu như lúc nào tôi cũng phải kiểm tra email. Tôi nhận được nhiều email lắm, rất nhiều trong
số đó là mail rác nhưng tôi vẫn phải xem qua hết 1 lượt. Có lẽ tỉ lệ sẽ là ⅔ thời gian sử dụng Internet là dành
cho Email, và ⅓ là dành cho lướt Web”
Để ý rằng cô ấy không chắc chắn mình thường dành bao nhiêu thời gian trên Internet. Hầu hết mọi người đều
như vậy. Đừng lo. Câu trả lời chính xác không thực sự quan trọng ở đây. Điều quan trọng ở đây là giúp cô ấy
nói về bản thân và suy nghĩ về cách mình sử dụng Internet, qua đó bạn có thể đánh giá sơ bộ được về kiểu
người dùng này.
Bạn hay vào những trang nào khi sử dụng Internet?

“Trong công việc thì chủ yếu là mạng nội bộ của công ty chúng tôi. Và trang Web của một số đối thủ cạnh
tranh. Ở nhà thì tôi hay vào các trang web Game và thương mại điện tử.”

Bạn có trang web yêu thích nào không?

“À, dĩ nhiên là Google rồi. Lúc nào tôi cũng vào Google trước tiên. Và một cái trang gì đó tên là Snakes.com
thì phải, bởi vì tôi có một con rắn làm thú cưng.”

Có thật không? Loài rắn nào thế?

“Một con trăn. Nó dài khoảng 4 feet, nhưng nó phải lên tới 8-9 feet khi nó trưởng thành hoàn toàn.”

Tuyệt. Các câu hỏi thì chỉ có vậy thôi, giờ chúng ta bắt đầu Kiểm tra nhé?

“Được thôi"
Đừng sợ bị lạc đề khi tìm hiểu sâu hơn về Ứng viên, miễn là bạn quay lại chủ đề chính đúng lúc.
Giới thiệu về Homepage
---------------
Đầu tiên, tôi sẽ yêu cầu bạn nhìn vào trang Web này và nói cho tôi biết bạn nghĩ gì về nó: Thứ gây ấn tượng
về nó là gì, bạn nghĩ trang Web này là của ai, bạn có thể làm gì ở đó, và trang web này để làm cái gì. Cứ nhìn
1 lượt và trả lời các câu hỏi. Bạn có thể scroll nếu muốn, nhưng đừng click vào cái gì vội nhé.
Cho tới thời điểm này, browser vẫn đang là Google để ứng viên không bị phân tâm. Sau khi trình bày, tôi truy
cập trang Web của mình và đưa chuột lại cho ứng viên.

“Chà, có lẽ ấn tượng đầu tiên của tôi là màu sắc rất đẹp. Tôi thích màu cam này, và cũng thích cái hình ảnh
mặt trời be bé ở chỗ cái logo eLance.”
Trong 1 cuộc Test thông thường, việc người này người kia thích hay ghét màu sắc hoặc hình ảnh minh hoạ
đều có tỉ lệ xảy ra tương đương nhau. Đừng bận tâm quá về những phản ứng cá nhân của ứng viên về yếu tố
thẩm mỹ của sản phẩm.
“Để xem.. [đọc..] “The global services market.” “Where the world competes to get your job done.””

“Tôi không biết cái này nghĩa là gì. Chịu luôn.”

“Animate your Logo: Free” [Nhìn vào mục Cool stuff bên trái] “Graphic design marketplace.” “View the RFP
marketplace.” “eLance marketplaces.” “

“Có nhiều thứ ở đây quá, nhưng tôi không biết cái gì là cái gì cả.”

Nếu bạn phải đoán thì bạn nghĩ nó là cái gì?

“Uh thì có lẽ nó có liên quan tới mua bán gì đó…”

“[Nhìn quanh trang web lần nữa] Khi tôi nhìn thấy cái list dưới này (cái list các hạng mục ở phần giữa giữa
trang Web) có lẽ chúng chính là các dịch vụ mà trang Web cung cấp. Pháp lý, Tài chính, Nghệ thuật sáng
tạo,... tất cả đều mang hơi hướng Dịch vụ.”
Ứng viên này đang làm rất tốt việc diễn giải những gì mình đang nghĩ trong đầu. Nhưng nếu cô ấy không làm
được thì đây chính là lúc tôi bắt đầu hỏi “Bạn đang nghĩ gì về trang Web này?”

“Nên chắc nó là thế đó. Sàn trao đổi mua và bán các Dịch vụ”

OK. Giờ nếu bạn đang ngồi ở nhà lướt web, thì bạn sẽ click vào cái gì đầu tiên?

“Chắc tôi sẽ click vào cái mục “Graphic Design". Tôi thích Graphic design mà.”

Làm các Tasks

---------------
Được rồi, giờ chúng ta sẽ thử làm 1 số task nhất định.
Và 1 lần nữa, nếu bạn có thể tiếp tục nói ra cảm nhận của mình càng nhiều càng tốt khi làm các task này thì
việc đó sẽ giúp ích cho chúng tôi rất nhiều.
Bạn có thể nghĩ tới 1 cái dịch vụ nào đó mà bạn cần thông qua trang Web này không?

“Hmm.. để tôi xem nào. Hình như tôi thấy “Home Improvement" ở đâu đó. Nhà tôi đang tính xây thêm 1 cái
ban công. Có lẽ tôi sẽ thuê được ai đó trên này.”

Vậy nếu bạn đang tìm ai đó để xây ban công cho mình, bạn sẽ làm gì trước?

“Chắc tôi sẽ click vào 1 trong số những categories dưới đây. [Nhìn] Đây rồi, Home improvement, ở ngay dưới
“Family & Household”

Vậy bạn sẽ làm gì?

“Chắc tôi sẽ click thôi… [Lưỡng lự, nhìn vào 2 cái link ở dưới “Family & Household”]”

Giờ tôi sẽ bảo ứng viên làm 1 task, để chúng ta biết được liệu cô ấy có thể dùng Trang Web để làm thứ mình
muốn được không.
Nếu được thì cứ để người dùng có 1 chút tiếng nói trong việc chọn các task mình sẽ làm.

“Hmm giờ tôi không biết làm gì nữa. Tôi không thể click vào chữ “Home improvement", nên có lẽ hoặc là tôi
phải click vào link “RFPs" hoặc link “Fixed-price". Nhưng tôi không biết sự khác biệt là gì cả. Fixed-price nghĩa
là giá cố định thì tôi hiểu đại khái; họ sẽ báo giá và họ sẽ làm theo báo giá đó. Nhưng RFPs thì chịu.”
Hoá ra là cô ấy đã hiểu nhầm. Trong trường hợp này, ‘fixed-price' có nghĩa là các dịch vụ có thể thuê theo 1
mức chi phí cố định được trả theo giờ, trong khi cái ‘RFP’ (Request for Proposal) thực ra lại là sự lựa chọn mà
sẽ cung cấp dịch vụ tương đồng với hướng đi của ứng viên. Đây chính là kiểu ‘hiểu nhầm' mà thường sẽ khiến
cho đội phát triển trang Web ngã ngửa ra vì ngạc nhiên.

Rồi, bạn sẽ click vào cái nào?

“Chắc là fixed-price thôi.”

OK, bạn tiếp tục đi.

Từ thời điểm này, tôi chỉ đơn giản là quan sát ứng viên thử đăng 1 dự án, để cô ấy đi từng bước cho tới khi
a) cô ấy hoàn thành task đó
b) cô ấy không làm được và bị bối rối, mất kiên nhẫn
c) cô ấy thử tự lần mò (với tình huống này thì chúng ta chả rút ra được cái gì cả)
Tôi sẽ cho cô ấy thêm 3,4 tasks nữa để làm, miễn sao thời gian để hoàn thành các task đó không quá 45 phút.

Thăm dò
---------------
Giờ chúng ta đã hoàn thành xong các tasks rồi, tôi muốn hỏi 1 vài câu hỏi.
Về những hình ảnh ở trên đầu trang Web - những hình minh hoạ có đánh số ấy? Bạn nghĩ gì về chúng?
Khi ứng viên đang làm task, tôi sẽ cẩn thận không hỏi những câu hỏi mang tính dẫn dắt, vì tôi muốn cuộc Test
diễn ra tự nhiên.
Nhưng tôi sẽ luôn dành ra chút thời gian vào cuối cuộc Test để hỏi những cau hỏi mang tính thăm dò, để tôi có
thể hiểu rõ hơn về những thứ đã xảy ra trong cuộc Test, và tại sao chúng lại xảy ra như vậy.
“Tôi cũng có nhìn thấy chúng đấy, nhưng tôi không cố gắng hiểu xem nó là gì. Tôi nghĩ chúng là hình hướng
dẫn các bước trong quy trình thôi"

Có lý do tại sao bạn không để tâm tới chúng không?

“Không có. chỉ là lúc đó tôi chưa thực sự sẵn sàng để bắt đầu quy trình vội. Tôi không biết liệu mình có muốn
dùng dịch vụ này không. Tôi chỉ nhìn qua xem sao thôi"

OK, được rồi.

Trong tình huống này, tôi hỏi câu hỏi này vì đội Design trang Web cho rằng phần lớn người dùng sẽ bắt đầu
bằng việc click vào các tấm ảnh minh hoạ của 5 bước trong quy trình, và tất cả mọi người sẽ ít nhất là nhìn
thấy và đọc 5 bước đó.

---------------------------------------------------------------------------------------------------------------------------------------------------

Đó, Test nó chỉ như thế là xong rồi.

Nếu bạn muốn xem 1 cuộc Test hoàn chỉnh, bạn sẽ tìm thấy 1 cái clip dài 25’ trên trang web của tôi. Truy cập
trang ​rocketsurgerymadeeasy.com​ và cick vào phần “Demo test video" nhé.

Các vấn đề thường gặp phải

Dưới đây là 1 vài loại vấn đề mà bạn sẽ gặp khá nhiều khi tiến hành Test.

- Người dùng chưa hiểu rõ về trang Web. Họ chỉ đơn giản là không hiểu được thôi. Họ nhìn vào 1
trang Web và hoặc là họ không hiểu nó là cái gì, hoặc là họ tưởng là hiểu rồi nhưng hoá ra là hiểu
nhầm.
- Những từ khoá mà họ đang tìm kiếm không ở đó. Thường thì điều này nghĩa là bạn đã không
lường trước được hết những thứ mà người dùng cần tìm, hoặc là các từ khoá bạn dùng để mô tả mọi
thứ khác với các từ khoá họ dùng.
- Có nhiều thứ diễn ra quá. Đôi khi những thứ họ đang tìm nằm ngay giữa trang Web, nhưng người
dùng lại không nhìn thấy được. Trong trường hợp này, bạn phải giảm đi sự nhiễu loạn thông tin trong
thiết kế, hoặc là cố gắng làm nổi bật hơn những thứ mà người dùng đang muốn tìm.
Họp báo cáo: Quyết định xem nên sửa cái gì

Sau mỗi lượt Test, bạn nên sắp xếp thời gian càng sớm càng tốt cho cả team ngồi cùng nhau và chia sẻ về
những thứ họ quan sát được, và quyết định xem nên khắc phục vấn đề nào, và khắc phục ra sao.
Tôi gợi ý mọi người tiến hành họp báo cáo ngay trong bữa trưa sau khi cuộc Test kết thúc, với mọi ấn tượng
và quan sát còn mới nguyên trong đầu mọi người. (Order pizza thật là ngon, thật là nhiều để khuyến khích mọi
người tham gia đầy đủ)
Bất cứ khi nào bạn test, hầu như lúc nào bạn cũng sẽ tìm ra 1 vài vấn đề nghiêm trọng về Tính khả dụng.
Không may là, không phải lúc nào chúng cũng là thứ được ưu tiên khắc phục. Thường thì sẽ có người nói: “Ừ
biết là cái đó cùi rồi, nhưng cả cái tính năng đó sẽ bị đổi sớm thôi, và từ giờ tới đó cứ để nó đấy cũng chả
sao". Hoặc là khi phải đối mặt với sự lựa chọn giữa việc sửa 1 vấn đề nghiêm trọng hay sửa nhiều vấn đề đơn
giản, thường thì họ sẽ chọn cái nào ít tốn công hơn.
Đây chính 1 lý do tại sao bạn vẫn thường gặp những lỗi cực nghiêm trọng về Tính khả dụng ngay cả ở trên
những trang Web lớn, có nền tảng đầu tư dồi dào, và chính vì lẽ đó nên 1 trong những “lẽ sống" của tôi tại
Rocket Surgery là:
“Phải tập trung vào các vấn đề nghiêm trọng nhất trước tiên, bất chấp mọi thứ khác"

Sau đây là phương pháp tôi hay dùng để đảm bảo “lẽ sống" này được tuân theo, nhưng với team của bạn thì
cứ liệu cơm gắp mắm thôi nhé.
- Tạo 1 danh sách chung. Đi 1 vòng, yêu cầu tất cả mọi người nêu ra 3 vấn đề nghiêm trọng nhất mà
họ quan sát được sau mỗi vòng Test (ít nhất phải có 9 cái vấn đề, vì đã có 3 vòng Test rồi.). Viết chúng
lên bảng. Thường thì sẽ có nhiều người nói “Tôi cũng thấy thế" với 1 vài vấn đề, và bạn có thể track số
lượng bằng việc thêm dấu tick ở mỗi vấn đề.
ở giai đoạn này thì không có tranh cãi thảo luận gì cả, bạn chỉ cần liệt kê ra các vấn đề thôi. Những
thành viên khác trong team phải quan sát và chỉ ra được các vấn đề có thực, đã diễn ra trong các vòng
Test.
- Chọn 10 vấn đề nghiêm trọng nhất. Bạn có thể tổ chức vote cho dân chủ, nhưng thường thì chỉ cần
chọn luôn những vấn đề mà có nhiều dấu tick nhất là được (có nhiều người cho rằng đó là 1 vấn đề
nghiêm trọng nhất)
- Phân loại và đánh giá các vấn đề. Xếp chúng theo thứ tự từ 1 tới 10, với 1 là vấn đề nghiêm trọng,
tồi tệ nhất. Cái top 10 này để riêng ra 1 chỗ.
- Tạo danh sách được sắp xếp theo thứ tự. Đi từ trên xuống, viết ra những ý tưởng sơ bộ về việc
Làm thế nào để khắc phục vấn đề này trong 1 tháng tới, ai sẽ đảm nhận việc này, và các tài nguyên
cần có để việc khắc phục vấn đề này.
Bạn không cần phải khắc phục các vấn đề 1 cách triệt để và hoàn hảo. Bạn chỉ cần cố gắng cải thiện
nó là được - tinh chỉnh chau chuốt 1 chút - vừa đủ để đá nó khỏi danh sách “Các vấn đề nghiêm trọng"
là đc.
Khi bạn cảm thấy mình đã phân bố đủ mọi quỹ thời gian và nhân lực có thể cho việc khắc phục các
vấn đề trong nguyên 1 tháng tiếp theo, DỪNG LẠI NGAY. Bạn đã đạt được mục tiêu. Cả nhóm đã
quyết định được cái gì cần phải sửa và có trách nghiệm phải sửa chúng.

Dưới đây là 1 vài tips giúp bạn quyết định nên sửa cái gì - và không nên sửa cái gì.
 - Tạo 1 danh sách riêng cho các vấn đề nhỏ lẻ. Bạn có thể giữ 1 danh sách các vấn đề không quá
nghiêm trọng và cũng khá dễ khắc phục. Ý tôi nói ‘dễ khắc phục' ở đây là 1 người có thể sửa nó trong
không quá 1 tiếng, mà không cần phải chờ sự đồng ý cho phép của bất cứ ai không tham gia họp báo
cáo.
- Tránh sự cám dỗ của việc thêm thắt. Khi mà thấy rõ được là người dùng chắc chắn không hiểu
được cái gì đó, phản ứng đầu tiên của đội phát triển sản phẩm thường là cố gắng thêm cái nọ cái kia,
kiểu thêm 1 cái phần giải thích hoặc hướng dẫn gì đó. Nhưng thường thì giải pháp đúng đắn chỉ đơn
giản là bỏ đi những thứ (hoặc 1 vài thứ) không cần thiết để khiến cho mọi thứ rõ ràng, dễ hiểu hơn,
thay vì lại nhét thêm 1 thứ khác gây phân tán sự tập trung.
- Hãy cẩn thận và tỉnh táo trước những yêu cầu “thêm tính năng mới". Các ứng viên thường sẽ nói
“Nếu có cái tính năng này thì sẽ tiện hơn nhiều". Cứ thật tỉnh táo, đa nghi trước những yêu cầu thêm
tính năng mới kiểu này, không thiệt đi đâu được. Tôi phát hiện ra rằng, nếu bạn yêu cầu họ mô tả cái
tính năng đó sẽ hoạt động ra sao - trong phần “hỏi thăm dò" ở cuối 1 cuộc Test - thường thì trăm người
như một, cho tới khi họ mô tả xong thì chính họ cũng sẽ thú nhận “Giờ nói ra mới thấy, có khi tôi cũng
chả dùng cái tính năng này đâu". Các ứng viên tất nhiên không phải Designer, nhưng thi thoảng họ sẽ
có các ý tưởng rất hay, và khi họ có thì bạn sẽ biết luôn, vì bạn sẽ tự nhủ “Sao mình không nghĩ ra cái
này nhỉ!?”
- Kệ các vấn đề kiểu “ thuyền Kayak”. Trong bất cứ cuộc Test nào, khả năng cao bạn sẽ gặp 1 vài
trường hợp mà người dùng sẽ đi lạc trong chốc lát nhưng vẫn quay lại đúng hướng được ngay sau đó
mà không cần trợ giúp gì cả. Nó cũng như kiểu bạn đi thuyền Kayak ấy, miễn là con thuyền tự chỉnh
được sự cân bằng đủ sớm, thì mọi thứ vẫn ổn. Trong thuật ngữ bóng rổ thì cái này gọi là “No harm, No
foul" (không gây hại thì cũng không phạm lỗi)
Miễn là
a) bất cứ ai gặp phải vấn đề đều tự nhận ra được mình đang đi sai hướng 1 cách nhanh chóng
b) họ có thể tự sửa chữa tình hình mà không cần giúp
c) họ không bị hoảng loạn, bối rối
thì bạn hoàn toàn có thể tự tin bỏ qua các vấn đề này. Nhìn chung, nếu người dùng đoán sai lần đầu
mà đoán đúng ở ngay lần 2 thì cũng tính là tạm ổn rồi.

Các phương pháp thay thế

Có 2 phương pháp hiệu quả khác để tiến hành Testing:

- Testing từ xa. Sự khác biệt ở đây là, thay vì đi tới công ty của bạn, các ứng viên có thể thoải mái tham
gia cuộc Test ở nhà hoặc ở chỗ làm việc của họ, sử dụng các phần mềm chia sẻ màn hình trực tiếp.
Loại trừ đi vấn đề di chuyển giúp cho việc tuyển dụng đơn giản hơn rất nhiều, và đáng nói hơn là điều
này giúp bạn mở rộng quy mô tuyển dụng từ tập “người sống ở gần công ty bạn" tới “hầu như tất cả
mọi người”. Ta chỉ cần có mạng ngon và loa/headphone có gắn microphone là đủ.
- Cũng là testing từ xa, nhưng không cần giám sát. Các dịch vụ như UserTesting.com cung cấp cho
chúng ta các ứng viên có thể tự quay lại bản thân mình khi họ làm 1 cuộc Usability Testing. Bạn chỉ
cần gửi thông tin về các task bạn muốn họ làm, và 1 đường link tới trang Web/ bản prototype/ mobile
app của bạn là được. Trong vòng 1 tiếng (trung bình là thế), bạn có thể xem 1 video của 1 ứng viên
 đang thực hiện các task đó, đồng thời nói ra những gì họ đang nghĩ trong đầu (Tôi cũng muốn tiết lộ
luôn: Tôi có nhận được 1 khoản bồi dưỡng từ trang UserTesting.com vì tôi cho phép họ sử dụng tên
mình trong sản phẩm của họ. Nhưng tôi cho họ làm việc đó chỉ đơn giản bởi vì tôi luôn nghĩ rằng đó là
1 sản phẩm tuyệt vời - cũng chính là lý do tại sao tôi có nhắc tới sản phẩm này ở đây.) Bạn sẽ không
thể tương tác trực tiếp với các ứng viên, nhưng phương pháp này khá tiết kiệm và không tốn của bạn
chút công sức nào, đặc biệt là về khâu tuyển dụng. Bạn chỉ cần đăng ký và nhận về các video để xem
thôi.

Thử đi, bạn sẽ thích nó thôi.

Dù rằng phương pháp là gì thì bạn cũng nên thử làm 1 lần. Tôi gần như chắc chắn rằng nếu bạn thử rồi thì sẽ
muốn tiếp tục tiến hành nó.
Sau đây là 1 vài gợi ý phản biện khi bạn gặp những quan điểm phản đối việc tiến hành Testing.
CÁC THẮC MẮC RỘNG HƠN VÀ CÁC ẢNH
HƯỞNG NGOẠI QUAN
Chương 10. Mobile: Không chỉ đơn thuần là tên 1 thành
phố thuộc bang Alabama nữa.

Chào mừng tới thế kỉ 21 - Bạn có thể bị chóng mặt đấy.

[Gáy thật to] SỨC MẠNH TẦM CỠ VŨ TRỤ!

​ à phải sống trong cái đèn bé như lỗ mũi!
[Lí nhí] M
_ Thần đèn trong phim Aladdin, khi nói về sự trái khoáy nghịch lý của việc tồn tại như 1 Thần đèn _

À, smartphone.
Cái bọn điện thoại ấy, chúng nó đang trở nên ngày càng thông minh hơn. Chúng nó họp hội đồng trong ngăn
kéo hàng ngày và lên kế hoạch kỹ lưỡng. Nhưng phải mãi tới Bước Nhảy Vọt (Apple cho ra mắt iPhone lần
đầu tiên vào năm 2007) thì bọn điện thoại này mới có được nhận thức.

Bản thân tôi thì lại chào mừng sự xuất hiện của mấy ông tướng bé xinh, tốn thời gian này. Tôi biết ngày xưa
tôi đã từng sống vui vẻ mà không cần 1 chiếc máy tính tiên tiến có màn hình cảm ứng và kết nối mạng ngay
trong túi áo, nhưng càng ngày càng khó để nhớ lại cuộc sống của tôi hồi đó ra sao.

Và tất nhiên cũng vào khoảng thời gian này mà phiên bản Mobile cho các trang Web thành hình. Đúng là
trước đây cũng đã có cái gọi là trình duyệt Web trên điện thoại rồi, nhưng bọn này - theo thuật ngữ chuyên
ngành - quá lởm.

Vấn đề vẫn chỉ xoay quanh 1 thứ - như Thần đèn đã nói rất chuẩn - chính là không gian sống bé như cái lỗ
mũi. Các thiết bị mobile (di động) đồng nghĩa với việc các thiết bị đó sẽ bị nhồi nhét mọi thứ vào, cả cái trang
Web dài như bài sớ bị gói lại trong 1 cái màn hình có kích thước bé như lòng bàn tay. Có nhiều giải pháp đã
được đưa ra, thậm chí các phiên bản trang Web tinh gọn nữa (nhớ cái thời mà ta phải ấn số tương ứng để
chọn các menu item được đánh số không?) và, như thường lệ, những người thực sự cần đọc thông tin vẫn
phải tự mò mẫm trong khổ sở.

Nhưng Apple đã thành công trong việc tích hợp nhiều tính năng của máy tính vào trong 1 giao diện trình duyệt
được thiết kế và cấu tạo cẩn thận (mà lại có dáng hình vừa mắt, thon gọn, đầy thẩm mỹ nữa chứ). Một trong
những phát kiến tuyệt vời của Apple chính là khả năng cuộn (scroll - hay là vuốt lên vuốt xuống đó) và zoom to
nhỏ tuỳ ý (lấy 2 ngón tay co kéo màn hình) nhanh lẹ. (Chính cái khoản “nhanh-lẹ” này - chính cái tốc độ phản
ứng cực tốt của thiết bị - là thứ ăn tiền, giúp cho sản phẩm thực sự hữu ích)

Lần đầu tiên trong lịch sử, người dùng thực sự thích lướt Web trên 1 thiết bị mà họ có thể mang theo mình
mọi lúc mọi nơi. Với tuổi thọ pin kéo dài cả ngày, bạn có thể xem mọi thứ ở bất cứ đâu, bất cứ khi nào. Nói
rằng đây là 1 bước chuyển đổi to lớn không hề quá lời chút nào. Tất nhiên, bước chuyển này không chỉ gói
gọn mỗi việc sử dụng Web. Cứ xem xem có bao nhiêu thứ mà chiếc smartphone gọn nhẹ của bạn đã tích hợp
được: 1 chiếc máy ảnh (máy quay video nữa, với 1 số người thì đây là chiếc máy ảnh / máy quay phim tốt
nhất họ sở hữu), thiết bị định vị GPS phủ sóng toàn cầu, đồng hồ, đồng hồ báo thức, kho ảnh và máy phát
nhạc, etc...

Đúng vậy đấy, chiếc máy ảnh tốt nhất với chúng ta không phải là 1 chiếc máy ảnh tân tiến nhất, mà là cái nào
chúng ta có thể mang theo mình ở mọi lúc mọi nơi.

Và thử nghĩ về việc những người đang sống ở các quốc gia đang phát triển, smartphone chính là chiếc máy
tính đầu tiên - có lẽ là duy nhất đối với họ, theo cùng cái cách mà họ có thể sử dụng đt di động trước cả khi họ
dùng điện thoại để bàn. Không thể chối cãi được rằng các thiết bị dị động chính là con sóng của thời đại mới,
trừ những thứ phải xử lý dữ liệu đồ sộ (ví dụ như, ít nhất là ở thời điểm hiện tại, các phần mềm làm video)
hoặc các phần mềm cần màn hình giao diện lớn (Photoshop, Ai, CAD, etc..)

Sự khác biệt là gì?

Vậy, Tính khả dụng có gì khác khi bạn đang thiết kế cho 1 thiết bị di động?
Theo 1 cách nào đó, câu trả lời là: không nhiều. Các quy tắc cơ bản vẫn thế. Có khi trên các màn hình nhỏ
của thiết bị di động thì người dùng còn lướt nhanh hơn và đọc ít hơn ấy.
Nhưng đúng là có 1 vài sự khác biệt cơ bản về thiết bị di động có thể gây ra các vấn đề khá khó nhằn liên
quan tới Tính khả dụng.
Khi tôi viết những dòng này, Web và App design cho các thiết bị di động vẫn hầu hết đang ở trong cái thời
“Wild West” (tạm dịch: thời đồ đá) trên nhiều phương diện. Chắc sẽ phải 1 vài năm nữa thì mọi thứ mới khác
đi được, có thể là tới lúc đó thì các cải tiến công nghệ mới cũng sẽ ra đời, thúc đẩy cả quy trình bắt đầu lại 1
lần nữa.

Tôi sẽ không nói nhiều tới những Best-practice cụ thể, bởi vì có lẽ sẽ còn cả đống các ý tưởng hay ho về thiết
kế giao diện có tiềm năng trở thành các tập quán phổ biến trong tương lai, thậm chí hiện tại còn chưa được ra
đời. Và tất nhiên các nền tảng công nghệ sẽ tiếp tục đổi thay với tốc độ nhanh hơn cách chúng ta tiếp cận
chúng rất nhiều.
Tôi sẽ nói tới 1 vài thứ mà tôi đảm bảo sẽ đúng mãi trong tương lai. Và điều đầu tiên là…

Quan trọng là ở chuyện Đánh đổi.

1 cách nhìn các thiết kế - bất cứ loại thiết kế nào - đó là thiết kế cần phải có khuôn khổ (những thứ bạn
phải-làm và những thứ bạn không-nên làm) và đánh đổi (việc chúng ta phải đưa ra các lựa chọn
không-được-lý-tưởng-như-mình-muốn để sản phẩm của mình nằm trong khuôn khổ nói trên).
Nói theo cách của tổng thống Lincoln, điều tốt nhất bạn có thể làm, chính là làm vừa lòng 1 vài người, tại 1 vài
thời điểm. (Đó là nếu đúng trên thực tế ổng có nói “Bạn có thể lừa 1 vài người mãi mãi, và lừa tất cả mọi
người ở 1 vài thời điểm, nhưng bạn không thể lừa tất cả mọi người mãi mãi”. Một trong những điều mà tôi học
được sau bao năm lăn lộn trên mạng, đó là khi bạn gặp 1 cái ảnh người nổi tiếng và 1 câu quote bên cạnh, thì
92% là câu đó không phải do người kia nói ra. không tin bạn cứ thử check Wiki của Lincoln mà xem.
en.wikiquote.org/wiki/Abraham_Lincoln​ )

Có hẳn 1 cái ảnh meme được lưu thông rộng rãi về việc các Khuôn khổ không phải là 1 thế lực tiêu cực như
người ta hay tưởng, mà thực ra chúng lại khiến việc thiết kế dễ dàng hơn và tạo môi trường tốt hơn cho tư
duy cải tiến sáng tạo.

Sự thật đúng là như thế - Khuôn khổ thực sự rất hữu ích. Nếu bạn phải đi mua ghế sofa mà phải vừa vặn với
cái phòng này, và hợp màu với cái tường này, thì việc tìm mua sẽ dễ dàng hơn nhiều so với việc cứ nhắm mắt
mua đại. 1 mô tả yêu cầu nhất định khi vẽ tranh luôn mang lại 1 hiệu ứng tập trung cần thiết, còn nếu trường
hợp là 1 tấm giấy trắng với vô hạn sự lựa chọn - tuy nghe có vẻ tự do thoải mái - có thể gây ra hiệu ứng tê liệt.

Bạn có thể không tin rằng Khuôn khổ có ảnh hưởng tích cực cũng được, nhưng chuyện đó cũng chẳng quan
trọng: Cứ thiết kế là sẽ có khuôn khổ. Và khi có khuôn khổ, sẽ phải có đánh đổi.

Theo kinh nghiệm của tôi, rất nhiều - nếu không muốn nói là hầu hết - các vấn đề nghiêm trọng về Tính khả
dụng là hậu quả của việc đưa ra quyết định sai lầm trong việc đánh đổi.

Ví dụ nhé, tôi không dùng app CBS News trên điện thoại.
Dùng 1 thời gian thì tôi thấy là các mẩu tin của nó được bẻ ra thành rất nhiều cụm nhỏ (đôi khi là quá nhỏ), và
mỗi cụm lại mất bao nhiêu tgian để load (nếu nó mà load nhanh thì có khi t cũng không ngại dùng đâu). Và
như để sát muối vào vết thương, ở mỗi page bạn lại phải cuộn qua cùng 1 cái ảnh để đọc được 1 mẩu content
ngắn cũn. Trải nghiệm nó như sau:
Tôi khó chịu với việc này tới mức khi tôi lướt xem tin tức trên Google (thứ mà tôi làm vài lần mỗi ngày) và nhìn
thấy cái link là của CBS thì tôi bỏ qua luôn, tìm của trang khác chứ nhất quyết không vào lại đó đọc nữa.

Khi tôi gặp các vấn đề kiểu này, tôi hiểu là nó đang tồn tại không phải vì cái đội xây dựng sản phẩm chưa nghĩ
tới vấn đề đó. Trên thực tế, tôi khá là chắc kèo rằng đây là chủ đề của những cuộc tranh luận căng thẳng mà
trong đó 2 hay nhiều bên tham gia đều phải thỏa hiệp.

Với trường hợp đánh đổi này của CBS thì tôi cũng không rõ các Khuôn khổ được đưa ra là gì. Vì trên các
page có cả Quảng cáo, có thể yêu cầu khuôn khổ là phải thiết kế trải nghiệm đọc báo sao cho có nhiều page
view nhất có thể. Hoặc yêu cầu khuôn khổ có thể liên quan tới cách bài báo được chia phần cho các mục đích
khác nhau trong hệ thống quản lý bài viết. Tôi có thể đoán cả ngày. Tôi chỉ biết là họ đã đưa ra 1 sự lựa chọn
đánh đổi, và sự lựa chọn đó đang không tập trung vào việc tạo ra 1 trải nghiệm sử dụng tốt đối với khách
hàng.

Cái vất vả bậc nhất trong quá trình tạo ra trải nghiệm sử dụng tốt trên nền tảng Mobile chỉ xoay quanh việc làm
sao để đưa ra các quyết định đánh đổi hợp lý mà thôi.

Chế độ hà khắc của không gian chật hẹp

Thứ rõ ràng hiển nhiên nhất về các màn hình mobile, chính là kích thước nhỏ bé của nó. Hàng thập kỉ qua
chúng ta đã và đang thiết kế cho các kiểu màn hình mà, ở thời đó thì có thể vẫn được cho là bé, nhưng giờ
đây nếu so sánh với tiêu chuẩn hiện tại thì còn rộng rãi thoải mái chán. Mà ngay từ hồi đó thì đội designer đã
phải cố gắng để nhồi nhét tất cả mọi thứ lên màn hình rồi.

Nếu bạn tưởng không gian trên trang Web Home page đã quý lắm rồi, thử thiết kế trên mobile phát là hiểu
ngay. Nên chắc chắn kiểu gì cũng phải có đánh đổi.
Một cách để thích ứng với không gian nhỏ hơn là vứt mấy thứ thừa thãi đi. Tạo ra 1 bản thiết kế cho Mobile
giống như 1 phiên bản thu gọn của Website. Nhưng tất nhiên việc này sẽ đặt ra 1 câu hỏi khó nhằn: Nên vứt
đi phần nào bây giờ?

Một cách tiếp cận phù hợp chính là Mobile First: Thay vì thiết kế 1 phiên bản đầy đủ điện nước (thi thoảng còn
hơi quá đầy đủ) của trang Web trước tiên rồi sau đó lọc bỏ các phần để làm bản Mobile, bạn có thể thiết kế
phiên bản Mobile trước, dựa trên các tính năng và nội dung quan trọng nhất đối với người dùng. Sau đó bạn
vẫn có thể thêm các tính năng và nội dung khác khi lên bản Website.

Đó là 1 ý tưởng tuyệt vời. Vì sao, đơn giản bởi vì phương pháp này bắt bạn phải tập trung quyết định xem cái
nào là thực sự cần thiết, cái nào người dùng cần nhất. Đó luôn luôn là 1 hướng đi phù hợp.

Nhưng có người lại hiểu rằng phương pháp đó nghĩa là chúng ta chỉ cần chọn những tính năng mà người
dùng muốn làm khi mà họ phải sử dụng thiết bị di động. Giả thuyết này cho rằng, khi người dùng sử dụng
phiên bản mobile, họ thường ‘đang ở ngoài đường', ‘đang phải di chuyển', chứ không phải ngồi làm việc với
máy tính, nên thành ra trên Mobile chúng ta chỉ cần các tính năng mà người dùng hay sử dụng khi đang ở
ngoài đường thôi. Ví dụ, khi đang đi shopping ở ngoài thì bạn có thể sẽ muốn kiểm tra số dư trong tài khoản
ngân hàng, nhưng bạn sẽ hiếm khi muốn tạo tài khoản khác, hoặc đối chiếu lịch sử giao dịch.

Tất nhiên, đây là 1 ngộ nhận sai lầm. Người dùng thường sử dụng thiết bị di động ở bất cứ chỗ nào họ thích,
ngay cả khi đang ngồi chơi ở nhà, và họ muốn (và kỳ vọng) có thể làm được mọi thứ. Hoặc ít nhất là ai cũng
muốn làm 1 vài thứ gì đó, và nếu tính tổng mỗi người vào thì cũng gần hết mọi tính năng rồi.

Nếu bạn định thêm vào mọi tính năng, bạn càng phải để ý thật kỹ tới việc phân cấp ưu tiên.

Những thứ mà người dùng cần làm trong lúc đang gấp, hoặc thường xuyên phải làm, cần phải dễ tìm, dễ thao
tác. Tất cả mọi thứ khác thì có thể chấp nhận bắt người dùng tap nhiều hơn, đi xa hơn, nhưng dù gì thì vẫn
phải có 1 lộ trình rõ ràng, dễ hiểu tới chúng.
Trong 1 vài trường hợp, việc các màn hình bị thiếu không gian cũng đồng nghĩa với việc các phiên bản Mobile
thường sẽ sâu hơn nhiều so với thằng anh em bên Web của nó, nên có thể bạn sẽ phải tap thêm 3,4 lần nữa,
đi sâu thêm 1,2 level nữa để tới được 1 phần thông tin / tính năng nhất định.

Điều này nghĩa là người dùng sẽ phải tap nhiều hơn, nhưng cũng không sao hết. Đó là điều không thể tránh
khỏi: Nếu muốn xem cùng 1 lượng thông tin trên 1 màn hình nhỏ hơn, bạn sẽ hoặc là phải tap nhiều hơn,
hoặc là phải scroll nhiều hơn. Miễn là người dùng vẫn cảm thấy tự tin rằng mình đang đi đúng hướng, thì họ
vẫn sẽ tiếp tục đi thôi.

Tuy nhiên, đây là thứ cần lưu ý:

KHÔNG NÊN HY SINH TÍNH KHẢ DỤNG (TRẢI NGHIỆM NGƯỜI DÙNG) KHI GẶP PHẢI CÁC VẤN ĐỀ
LIÊN QUAN TỚI KHÔNG GIAN THIẾT KẾ.

(Cảm ơn Manikandan Baluchamy vì quan điểm này.)

Chuyện nuôi tắc kè hoa

Khúc hùng ca của quan điểm 1-bản-design-cho-mọi-loại-màn-hình có lịch sử lâu đời, trong đó có cả những hi
vọng tươi sáng, những lời hứa lèo, và cả 1 hội cả designer lẫn developer ai cũng khổ sở te tua.
Nếu có 2 điều tôi có thể nói với bạn về các bản thiết kế áp dụng được cho nhiều màn hình (hay còn gọi là các
Bố cục năng động (Dynamic layout), các Thiết kế lỏng (Fluid design), các Thiết kế thích ứng (Adaptive design),
hay Thiết kế tương tác (Responsive design)), thường chúng sẽ:
- Tốn cực nhiều công sức làm
- Rất khó để làm cho chuẩn chỉ

Trong quá khứ, các Design kiểu tương tác - 1 phiên bản thiết kế mà trông vẫn sang xịn mịn trên nhiều màn
hình thiết bị - chỉ là 1 sự lựa chọn, bạn thích thì làm không thích thì thôi. Nó nghe có vẻ là 1 ý hay, nhưng rất ít
người thực sự để tâm tới điều đó. Còn giờ đây khi mà các màn hình di động kích cỡ nhỏ lên ngôi, thì ai cũng
phải để tâm tới nó: Nếu bạn có 1 trang Web, bạn buộc phải thiết kế sao cho nó trang Web đó có thể xem được
trên mọi kích cỡ màn hình.

Mấy ông Dev đã ngộ ra từ rất lâu rằng, cố gắng tạo ra các phiên bản khác nhau của bất cứ thứ gì, là con
đường ngắn nhất dẫn tới bệnh thần kinh. Nó tăng gấp đôi công việc cho họ và chắc chắn là cả 2 bản đều sẽ
không được cập nhật thường xuyên, hoặc là cái này không trùng khớp với cái kia.

Vấn đề này vẫn đang được giải quyết. Vì vấn đề ảnh hưởng trực tiếp tới lợi nhuận của công ty, nên sẽ có các
phương án kĩ thuật, dù mất thời gian.
Hiện tại, thì có 3 gợi ý như sau:
- Cho phép chức năng Zooming: Nếu bạn không có đủ lực để làm phiên bản Mobile xịn sò cho trang
Web của bạn, và bạn cũng không làm Responsive, thì ít nhất bạn cũng nên đảm bảo trang Web của
mình có khả năng cho phép người ta xem được thông tin ngay cả trên 1 thiết bị mobile. Không có mấy
 điều trên đời này khó chịu hơn việc mở 1 trang Web trên điện thoại của bạn và thấy rằng nó không thể
zoom to lên được để đọc thông tin (Nói thế thôi, còn 1 tỷ thứ khác khó chịu hơn, nhưng bạn hiểu ý tôi
rồi đấy..)
- Đừng có bắt người dùng quay lại trang Homepage: Một điều cực kì phiền toái nữa: Khi tôi tap vào 1
cái link từ email hay 1 trang mạng xã hội nào đó, và cái link đó thay vì đưa tôi tới bài viết chi tiết, thì lại
vứt tôi ở ngay cái trang chủ. Bắt mình phải tự tìm lại cái bài viết đó 1 lần nữa.

- Luôn luôn để 1 cái link dẫn tới trang Web “đầy đủ”: Bất kể cái bản Mobile của bạn hoành tráng và
chi tiết tới mức nào, bạn vẫn phải cho người dùng 1 lối đi tới phiên bản Web, đặc biệt là khi bản Web
có những tính năng hay thông tin mà phiên bản Mobile không có. (Tập quán chung hiện tại đang là để
1 cái nút Toggle Mobile/Website ở dưới cùng của mỗi trang Web)
Có rất nhiều trường hợp mà người dùng sẵn lòng zoom to ra nhỏ vào trên cái màn hình bé xíu của
thiết bị di động để tiếp cận cái tính năng mà họ quen dùng, hoặc để làm thứ họ cần làm. Bên cạnh đó
cũng có người thích xem phiên bản Web khi sử dụng tablet 7 inches khi chuyển sang chế độ ngang
(landscape mode)

Đừng giấu Đặc tính tương tác của bất kì thứ gì

Đặc tính tương tác (affordance) là những ký hiệu thị giác trong thiết kế / cấu trúc của 1 vật thể, những ký hiệu
này sẽ giúp người dùng hiểu được cách sử dụng vật thể đó. (Tôi nhắc tới các ký hiệu thị giác này ở chương 3.
Nhớ cái câu chuyện về Tay nắm mở cửa và cuốn sách của Don Norman không? Chính ông ấy đã phổ thông
hóa thuật ngữ này trong xuất bản đầu tiên của cuốn “The Design of Everyday Things” vào năm 1988 và cộng
đồng thiết kế trên toàn thế giới đã nhanh chóng tiếp thu thuật ngữ đó)

(Đen đủi thay, cái cách mà cộng đồng sử dụng nó không hẳn là đúng với cách mà tác giả muốn. Ông ấy đã
xác minh điều này trong lần xuất bản mới của cuốn “The Design of Everyday Things” bằng cách đề nghị
chuyển thuật ngữ thành “Dấu hiệu nhận biết” (Signifier) thay vì Đặc tính tương tác (Affordance), nhưng có lẽ
đã quá muộn để bắt ông thần đèn này quay trở lại chiếc đèn. Mặc dù có lỗi với tác giả, có lẽ tôi vẫn sẽ phải
dùng từ khóa Đặc tính tương tác trong cuốn sách này vì (a) Người ta vẫn quen với từ khóa này hơn và (b) sửa
lại hết thì thực sự là nhức đầu lắm.)
Đặc tính tương tác là yếu tố quan trọng căn bản trong 1 giao diện UI. Ví dụ, 1 số nút bấm được thiết kế theo
style 3D để người dùng hiểu rõ rằng đây là nút có thể bấm vào được. Tương tự với “mùi” thông tin, các đặc
tính này càng rõ ràng thì người dùng càng dễ hiểu, dễ nắm bắt các ký hiệu về mặt giao diện.

Tương tự, 1 cái ô hình chữ nhật có viền xung quanh thể hiện rằng người dùng có thể click vào nó và gõ chữ.
Nếu bạn có 1 cái text box có thể edit được mà không cần viền, người dùng vẫn có thể click vào nó và gõ chữ
nếu họ biết khu vực text box nằm ở đó. Nhưng chính cái Đặc tính tương tác - cái viền xung quanh khu vực
text box - đã giúp cho tính năng này rõ ràng hơn.

Để các Đặc tính tương tác hoạt động hiệu quả, chúng cần phải dễ nhận biết, nhưng trên thực tế các tính chất
của 1 thiết bị di động đã khiến cho chúng kém nhận biết hơn rất nhiều, hoặc có khi vô hình luôn. Và theo
nguyên tắc là các Đặc tính tương tác là thứ bạn không bao giờ được ẩn đi.
Tuy nhiên, ý tôi không phải mọi Đặc tính tương tác nào cũng cần phải nổi bần bật trên màn hình. Chúng chỉ
cần đủ rõ ràng để người dùng có thể nhận ra và hiểu được cách sử dụng tính năng, từ đó làm được thứ mà
họ muốn làm.

Không có con trỏ = Không hover được = Không có tín hiệu gì cả

Trước khi có màn hình cảm ứng, Thiết kế Web đã phụ thuộc rất nhiều vào tính năng hover (rê chuột vào 1 thứ
gì đó) - Khi ta rê chuột vào 1 thứ gì đó trên trang Web mà chưa click, giao diện của thứ đó sẽ thay đổi tùy vào
chức năng.

Nhưng 1 màn hình cảm ứng (sử dụng trên hầu hết tất cả các thiết bị di động) không có khả năng cảm ứng
chính xác khi ngón tay chúng ta đang di chuyển qua lại trên màn hình, chỉ khi đầu ngón tay thực sự chạm vào
màn hình thôi. Đây chính là lý do tại sao các thiết bị di động không có chuột / con trỏ. (Phải thú nhận là hồi tôi
mới dùng iPhone, phải mất mấy tháng đầu tôi mới phát hiện ra là không có con trỏ)

Hậu quả là, rất nhiều các tính năng có giao diện hữu ích phụ thuộc vào hiệu ứng hover đều trở nên vô dụng,
như tool tips (các khung text hiện lên để chỉ dẫn, nhắc nhở, cung cấp thêm thông tin cho người dùng), các loại
nút có khả năng thay đổi màu sắc và hình khối để báo hiệu rằng chúng nó có thể click được, và các loại menu
drop down để hiển thị thông tin.

Là 1 designer, bạn cần phải nhận thức được rằng, các yếu tố đồ họa này không còn phù hợp với người dùng
mobile nữa, và bạn sẽ phải tìm ra các phương pháp thay thế chúng.

Flat design (Thiết kế phẳng): Bạn hay Thù?

Các Đặc tính tương tác luôn đòi hỏi sự khác biệt về mặt thị giác. Nhưng trend mới nổi gần đây trong thiết kế
giao diện (Mà có khi tới cái lúc bạn đọc được dòng này thì cũng hết xừ hot rồi) lại đi theo hướng ngược lại
hoàn toàn: xóa đi toàn bộ những sự khác biệt về mặt thị giác và “dàn phẳng” giao diện của mọi yếu tố đồ họa.

Trông thì đẹp đấy (ít nhất là với 1 số người), và nó khiến cho giao diện nói chung trông đỡ lộn xộn rối mắt hơn.
Nhưng cái giá phải trả là gì?

Trong trường hợp này, sự đánh đổi diễn ra giữa giao diện sạch sẽ, gọn gàng ở 1 bên và việc cung cấp đủ
thông tin về mặt thị giác để người dùng có thể hiểu được các Đặc tính tương tác ở bên còn lại.

Thật không may, Flat design có xu hướng loại bỏ hết, không chỉ những yếu tố trang trí cầu kì gây xao nhãng,
mà còn cả những yếu tố đồ họa thực sự hữu ích.

Sự khác biệt rõ ràng để người dùng chú ý vào các Đặc tính tương tác thường phải ở dạng đa-chiều. Thứ nói
cho bạn biết cái này là cái gì có thể là vị trí của nó (trong navigation bar) và định dạng của nó (viết hoa, viết in
đậm) - suy ra đây chỉ có thể là menu item thôi.
Bằng việc loại bỏ 1 số những khác biệt rõ ràng này trong hệ thống thị giác của bản thiết kế, Flat design khiến
cho việc phân biệt mọi thứ khó khăn hơn rất nhiều

Flat design đã khiến tất cả mọi người ngạc nhiên. Nó làm tôi nhớ đến ‘thế giới trước khi ảnh màu xuất hiện’
trong loạt truyện tranh / hoạt hình ưa thích của tôi “Calvin và Hobbes” (Bạn có thể xem nốt phần còn lại ở cuối
chương 13)

CALVIN AND HOBBES © 1989 Watterson. Reprinted with permission of UNIVERSAL UCLICK. All rights reserved.

Bạn có thể sử dụng Flat design kiểu gì cũng được (Có khi bạn sẽ bị bắt phải thiết kế theo style đó ấy chứ),
nhưng hãy đảm bảo rằng bạn tận dụng được tối đa các chiều không gian được cho phép sử dụng trong Flat
design để bù đắp cho những gì bạn mất đi.

Bạn thực sự có thể quá giàu có, hoặc quá gầy..

...Nhưng máy tính thì không thể quá nhanh được. Đặc biệt là trên các thiết bị di động, tốc độ tốt càng khiến
cho mọi thứ cảm thấy ổn hơn. Tốc độ tải chậm đồng nghĩa với việc khiến cho người dùng chán nản và gây
mất thiện cảm với nhà phát hành.

Ví dụ, tôi rất thích phần tin mới từ ứng dụng mobile AP (Associated Press). Họ luôn là dịch vụ cập nhật các tin
tức quan trọng nhanh nhất.

Thật không may cho AP là, mỗi khi tôi tap vào thông báo push noti của AP, cái app nó lại phải load 1 mớ ảnh
của tất cả các mẩu tin tức hàng đầu khác trước khi cho tôi xem chi tiết về cái mẩu tin mà tôi vừa tap vào.
Thành ra, tôi lại có thói quen: Khi có thông báo từ AP, tôi ngay lập tức mở trang The New York Times hoặc
Google News để xem họ đã có thông tin gì về sự kiện đó chưa.

Ở thời nay thì chúng ta đều đã quen với tốc độ mạng nhanh chóng, nhưng cũng cần phải nhớ rằng tốc độ tải
của các thiết bị mobile khá thất thường. Nếu chúng ta ở nhà hoặc ngồi ngoài Starbucks thì có lẽ mạng cũng ổn
ổn, nhưng một khi ta đi ra chỗ khác không có Wifi và phải dùng 3G hay 4G, thì hiệu suất có thể sẽ khác nhiều.

Lưu ý rằng các phương án thiết kế responsive của bạn sẽ không tải các trang có chứa 1 khối lượng code và
tài liệu quá nhiều so với mức cần thiết trên màn hình của người dùng.

Các yếu tố nổi trội của Tính khả dụng trong Mobile app

Có thể bạn vẫn còn nhớ từ những trang đầu tiên của cuốn sách, tôi có nhắc tới việc mình sẽ đào sâu hơn về
những phẩm chất của cái gọi là Tính khả dụng, theo định nghĩa của mọi người: Hữu ích, dễ nắm bắt, hiệu
quả, hợp lý, hấn dẫn, thú vị. Rồi, đó chính là lúc này đây.
Cá nhân tôi hay tập trung vào 3 đặc tính cốt lõi trong định nghĩa của tôi về Tính khả dụng:
1 người dùng có năng lực và kinh nhiệm trung bình (hoặc dưới trung bình) có thể tự tìm ra cách sử
dụng sản phẩm [tính dễ nắm bắt] để làm được 1 điều gì đó [tính hiệu quả] mà không tốn nhiều công sức
[​tính hợp lý]

Tôi không dành quá nhiều thời gian nghĩ về việc liệu sản phẩm có Tính hữu ích hay không, vì đây là câu hỏi
cho đội MKT nhiều hơn, điều mà cần phải được làm rõ trước khi bất kì dự án nào bắt đầu, thông qua các
phương pháp như phỏng vấn, thảo luận nhóm, và khảo sát. Tính hấp dẫn cũng là câu hỏi thuộc lĩnh vực MKT
nhiều hơn, và tôi sẽ nói về vấn đề này nhiều hơn ở chương cuối.

​ ính dễ nắm bắt và T

Giờ thì hãy bàn luận về Tính thú vị, T ​ ính dễ nhớ, và cách chúng được thể hiện trên các
mobile app.

Đây là thời của tính thú vị

Thế nói chung cái gì gọi là “thú vị”?

Thú vị cũng hơi khó để cắt nghĩa, nó là kiểu “Khi bạn cảm thấy thế thì nó là như thế” thì dễ hình dung hơn.
Thay vì 1 bản định nghĩa, có lẽ liệt kê ra 1 vài từ khóa mà người ta hay dùng để mô tả các sản phẩm thú vị sẽ
khiến chúng ta dễ hiểu hơn: vui vẻ, bất ngờ, ấn tượng, thu hút, khôn khéo, ảo diệu. (Cá nhân tôi ấy, thì app
nào mà thú-vị thường sẽ “có thể làm cái gì đó mà nếu là ở hồi xưa thì ta chắc sẽ bị hỏa thiêu.)

Các app thú vị thường được sinh ra từ việc kết hợp ý tưởng - 1 cái gì đó mà người ta rất muốn làm, nhưng
không làm được, và 1 cách xoay sở nào đó (thường sẽ là công nghệ) để biến việc đó trở nên khả thi.

App SoundHound là 1 ví dụ hoàn hảo. Nó không chỉ giúp bạn nhận diện được bản nhạc đang được phát ở bất
cứ chỗ nào, nó còn có thể hiển thị lời bài hát khớp với nhịp nhạc đang được phát.
Và app Paper không đơn thuần là 1 app vẽ bậy thông thường. Thay vì nó có 1 tá công cụ vẽ với 1 tỉ sự lựa
chọn, bạn chỉ có 5 loại bút vẽ và không cần phải chọn cái gì hết. Và mỗi loại được tối ưu hóa để bạn vẽ cái gì
ra trông cũng đẹp.

Xây dựng tính thú vị cho các app mobile đang trở nên càng quan trọng hơn, bởi vì thị trường lúc nào cũng rất
cạnh tranh. Chỉ làm 1 thứ gì đó tốt thôi là chưa đủ, bạn phải tạo ra 1 thứ gì đó cực kì đỉnh thì may ra. Sự thú vị
có thể được coi là 1 bài tập cộng điểm thêm của thiết kế UX.

Làm cho app của bạn thú vị là 1 mục tiêu hợp lý. Nhưng cũng đừng tập trung quá nhiều vào nó mà quên đi
tính khả dụng của sản phẩm nhé.

Ứng dụng cần phải dễ nắm bắt

Một trong những vấn đề lớn nhất của những ứng dụng hiện nay, đó là việc chúng có quá nhiều tính năng khó
nắm bắt.
Lấy app Clear làm ví dụ. Đây là ứng dụng cho phép chúng ta tạo ra các to-do list. App thực sự thông minh, đột
phá, có thẩm mỹ, hữu ích, và thú vị, với 1 giao diện minimal tinh gọn, đơn giản. Tất cả các tương tác chuyển
động đều được xử lý tinh tế, mượt mà, cộng thêm cả các hiệu ứng âm thanh cầu kì. Một người dùng đã nhận
xét “Như kiểu tôi vừa chơi pinball, vừa có thể làm việc năng suất vậy."

Vấn đề nằm ở chỗ, lý do tại sao việc sử dụng app lại thú vị tới thế, chính là vì app đó có các chuyển động
tương tác, thao tác, hệ thống điều hướng rất sáng tạo, nhưng có quá nhiều thứ phải tiếp thu.

Với phần lớn các app, thường các chỉ dẫn về cách sử dụng ứng dụng sẽ nằm ở 1 vài màn hình đầu tiên khi
bạn mới mở app. Nhưng nếu muốn tìm lại các chỉ dẫn này để đọc lại thì rất khó, hoặc bất khả thi.

Và nếu có sự chỉ dẫn (và nếu bạn may mắn tìm được), thường nó sẽ nằm ở 1 trang text ngắn ngủn, hoặc 1
chiếc link dẫn tới trang của Developer, hoặc 1 trang Web hỗ trợ khách hàng mà bạn chỉ có thể gửi đi câu hỏi
thắc mắc chứ không thực sự tìm ra được câu trả lời.

Việc này có thể có hiệu quả với những app đơn giản, có ít tính năng, nhưng ngay khi bạn cố gắng tạo thêm
nhiều tính năng - và đặc biệt là những tính năng sáng tạo, không đi theo các tập quán và giao diện quen thuộc
- thì chỉ dẫn sơ sài như vậy chắc chắn không đủ.

Những người đã thiết kế ra app Clear thực sự đã làm rất tốt trong khâu chỉ dẫn người dùng, nếu phải so sánh
với phần lớn các app khác. Lần đầu tiên tôi dùng nó, tôi đã tap qua tổng cộng 10 màn hình chỉ dẫn các tính
năng chính được thiết kế đẹp đẽ.

Theo sau các màn hình chỉ dẫn này là phần tutorial được thiết kế thông minh, và thực ra đó chỉ là 1 trong
những list của app thôi.

Mỗi item của cái list đó gợi ý bạn thử làm 1 thao tác, và khi bạn làm xong hết các thao tác đó thì cũng coi như
là đã dùng qua hết các tính năng của app rồi.
Nhưng khi tôi thử sử dụng chúng để tiến hành các bài Test demo về Tính khả dụng trong buổi thuyết trình của
mình, thì kết quả không được ổn cho lắm.

Tôi cho các ứng viên cơ hội để tìm hiểu về app thông qua việc đọc mô tả sử dụng trên App store, xem qua các
màn hình chỉ dẫn, và thử các tương tác giống như tutorial bên trên. Sau đó tôi yêu cầu họ thử làm 1 số task
cơ bản mà app này có thể làm được: Tạo 1 danh sách mới có tên là “Du lịch Chicago” với 3 item bên trong -
Đặt phòng - Thuê xe - Chọn chuyến bay.

Tính tới thời điểm hiện tại, chưa có ai thành công cả.

Dù thông tin đã được trình bày ở các màn hình chỉ dẫn ngay khi người dùng mở app, họ có lẽ không hiểu
được 1 điều là app này có 3 level: level của cách danh sách, level của các item thuộc danh sách, và level
quản lý setting. Và kể cả khi họ có nhớ các thông tin này từ việc xem qua các màn hình chỉ dẫn, họ vẫn không
tìm ra được các định hướng giữa các level. Và nếu bạn không biết cách định hướng, bạn cũng không tự xoay
sở để mò ra được màn hình Help (trợ giúp). Tiến thoái lưỡng nan luôn.

Tuy nhiên không thể cho rằng trên thực tế không có ai có thể học cách sử dụng app. App vẫn nhận được
review tích cực và thường xuyên được đánh giá tốt trên thị trường. Nhưng tôi vẫn phải băn khoăn không biết
bao nhiêu người bỏ tiền mua app nhưng chưa bao giờ thực sự sử dụng được nó, hoặc không biết bao nhiêu
lượt mua nữa họ có thể nhận về nếu cái app nó dễ nắm bắt và dễ học hỏi hơn.

Và đây còn là 1 sản phẩm từ 1 đội ngũ đã đặt nhiều công sức vào khâu chỉ dẫn và trợ giúp người dùng. Phần
lớn sản phẩm khác không làm được như họ đâu.
Bạn cần phải làm được tốt hơn cái phần-lớn-còn-lại đó, và Usability Testing sẽ giúp bạn tìm ra được phương
thức phù hợp.

Ứng dụng cần phải dễ nhớ nữa

Còn 1 đặc tính quan trọng khác: Tính dễ nhớ. Một khi bạn đã tìm ra cách app đó hoạt động, liệu tới lần sau
bạn có nhớ cách sử dụng nó không, hay bạn lại phải mò mẫm 1 lần nữa?

Thường tôi không hay nói nhiều về Tính dễ nhớ, vì tôi nghĩ cách dễ nhất để người dùng học-lại 1 cái gì đó
chính là làm sao cho việc học hỏi nó rõ ràng và đơn giản ngay từ đầu. Nếu ngay từ lần đầu tiên quá trình học
cách sử dụng 1 thứ gì đó đã dễ dàng, nhanh chóng, thì những lần sau cũng thế.

Nhưng với 1 số app thì đây có thể là vấn đề nghiêm trọng.

Một trong những app chuyên về vẽ ưa thích của tôi là ASketch. Tôi ưng cái app này bởi vì bất kể thứ tôi vẽ ra
có thô kệch hay khó hiểu ra sao, kết quả trông vẫn rất thú vị.

Nhưng trong hàng tháng trời, mỗi khi tôi mở app lên là tôi không thể nào nhớ được cách bắt đầu 1 bức vẽ
mới.

Trên thực tế, tôi còn không nhớ được cách tìm ra bất cứ tính năng điều khiển nào. Để tối đa hoá không gian
vẽ, app không để icon hay nút nào trên màn hình.
Tôi đã thử các thao tác thông thường: Tap 2 lần, tap 3 lần, tap vào phần trên hoặc phần dưới màn hình, quẹt
qua lại các kiểu, tap bằng nhiều ngón tay, và mãi tôi mới mò ra. Nhưng tới lần sau mở lại app, tôi lại quên mất
cách thao tác để hiển thị bảng điều khiển.

Tính dễ nhớ có thể là 1 nhân tố lớn ảnh hưởng tới việc sử dụng app thường xuyên của người dùng. Thường
thì sau khi vừa mua app, bạn sẽ sẵn lòng dành chút thời gian để tìm hiểu cách sử dụng nó. Nhưng nếu lần
nào dùng app bạn cũng phải bỏ ngần ấy công sức và thời gian tìm hiểu cách sử dụng, thì có lẽ đó cũng không
phải là 1 trải nghiệm tích cực. Trừ khi bạn rất rất bị ấn tượng bởi tính năng của app, khả năng cao là bạn sẽ
không dùng nó nữa - và đó chính là số phận của phần lớn các app.

Testing Tính khả dụng trên các thiết bị mobile

Nói chung là quy trình làm Test Tính khả dụng trên mobile cũng y hệt như quy trình tôi mô tả ở chương 9.

Bạn vẫn sẽ phải tạo ra các task cho ứng viên làm, và quan sát họ. Bạn vẫn sẽ phải khuyến khích họ nói ra
những gì họ nghĩ trong đầu khi đang thực hiện các task. Bạn vẫn phải im lặng phần lớn thời gian diễn ra cuộc
Test và chỉ hỏi những câu hỏi thăm dò vào cuối buổi Test. Và tất nhiên bạn vẫn nên cố gắng mời càng nhiều
stakeholder càng tốt để họ tới quan sát cuộc Test trực tiếp.

Hầu hết những cái khác biệt khi bạn Test Tính khả dụng đều liên quan tới việc tổ chức hậu cần hơn là tới quy
trình, nên cứ yên tâm mà sắp xếp Test thôi.

Công tác hậu cần của Testing cho các thiết bị mobile

Khi bạn tiến hành Test trên 1 chiếc máy tính, việc chuẩn bị là khá đơn giản:
- Điều phối viên và ứng viên đều quan sát cùng 1 màn hình.
- Phần mềm chia sẻ màn hình cho phép những người quan sát xem được những gì đang diễn ra.
- Phần mềm quay màn hình quay lại video của cả cuộc Test.

Nhưng nếu bạn đã từng thử làm Test cho các thiết bị mobile, hẳn bạn cũng hiểu được sự phức tạp của khâu
chuẩn bị: các thể loại camera, Webcam, bộ xử lý tín hiệu, khung giới hạn vật lý (à thực ra cũng không cần 1
khung vật lý, chỉ cần 1 cái gì đó để đánh dấu, kiểu như “Đừng di chuyển thiết bị quá khung này" để giữ cho
ứng viên và màn hình trong tầm quay của camera), và cả những thứ gọi là Sleds và Goosenecks (các thiết bị
giúp cố định khung hình của camera)

Sau đây là 1 vài vấn đề mà bạn sẽ gặp phải:

- Bạn có cần để ứng viên sử dụng thiết bị mobile của họ không?
- Các ưng viên có cần phải cầm thiết bị mobile 1 cách tự nhiên hay không, hay là phải đặt thiết bị ở 1
chỗ cố định trên bàn?
- Các quan sát viên cần xem được những gì (ví dụ: chỉ cần xem dc màn hình thôi, hay là cả màn hình
lẫn thao tác ngón tay của ứng viên)? và làm thế nào để hiển thị những yếu tố này trong 1 phòng quan
sát khác?
- Làm thế nào để quay lại toàn bộ quá trình?

Một trong những lý do chính khiến cho việc Testing Tính khả dụng trên mobile khó khăn chính là sự thiếu hụt
trong công cụ / phương tiện kĩ thuật - những công cụ đắc lực để chúng ta tiến hành Testing sản phẩm trên
Web lại không thể hỗ trợ khi Testing sản phẩm trên Mobile. Vào thời điểm tôi viết những dòng này, các ứng
dụng chất lượng có tính năng chia sẻ và quay lại màn hình cho điện thoại chưa có, phần lớn bởi vì hệ điều
hành trên Mobile có xu hướng ngăn chặn các tác vụ nền (thuật ngữ chuẩn xác là background process). Và
đằng nào thì các thiết bị mobile cũng không đủ mạnh mẽ để chạy cả ứng dụng sản phẩm lẫn ứng dụng quay /
chia sẻ màn hình.

Gợi ý của tôi cho bạn

Cho tới khi các phương án về công nghệ ra đời, tôi đã và đang làm theo những cách sau:
- Sử dụng 1 camera quay trực tiếp vào màn hình thiết bị thay vì dùng các ứng dụng Mirror màn
hình. ​Mirror màn hình cũng tương tự chia sẻ màn hình thôi: Nó cho phép chúng ta xem được những gì
 đang diễn ra trên màn hình. Bạn có thể làm điều này với các ứng dụng hoặc thiết bị khác nhau (Apple
Airplay, hoặc kết nối thiết bị mobile với màn hình TV / trình chiếu bằng dây cáp để hiển thị màn hình)
Nhưng Mirror không phải là 1 cách tốt để quan sát các bài Test trên các thiết bị cảm ứng, vì chúng ta
không thể nhìn thấy các thao tác tay của ứng viên. Quan sát 1 cuộc Test mà không nhìn thấy được
thao tác ngón tay của ứng viên cảm giác như kiểu đi nghe nhạc piano mà không thấy ông chơi piano
đâu: Mọi thứ diễn ra rất nhanh và khó để bắt kịp. Nhìn thấy tay tương tác với màn hình sẽ dễ nắm bắt
hơn nhiều.
Nếu bạn muốn quay được cả thao tác tay, kiểu gì cũng cần phải có camera (Một số phần mềm mirror
sẽ thể hiện các đường quẹt và chấm trên màn hình, nhưng cũng không được rõ ràng sinh động như
thao tác ngón tay)

- Cố định camera vào thiết bị nên ứng viên có thể cầm nó 1 cách tự nhiên. Trong 1 số trường hợp,
thiết bị mobile được đặt trên bàn và không thể bị dịch chuyển. Trong các trường hợp khác, ứng viên có
thể giữ thiết bị mobile, nhưng họ được yêu cầu phải giữ thiết bị trong 1 khung giới hạn cố định, đánh
dấu bằng bút marker hoặc băng dính (để thiết bị dù có bị di chuyển chút ít thì vẫn nằm trong khung
quay của camera)
Nếu bạn cố định camera vào thiết bị, ứng viên có thể di chuyển nó thoải mái mà màn hình vẫn sẽ được
quay lại rõ ràng.

- Không cần thêm 1 cái camera riêng để quay ứng viên đâu. Thực sự tôi không thích cái trò quay lại
biểu cảm của ứng viên. Một số người lại thích nhìn nét mặt ứng viên, nhưng tôi nghĩ đây là 1 sự phân
tán không hơn không kém. Tôi tập trung vào việc quan sát ứng viên thực hiện các task trên thiết bị
nhiều hơn, và tôi vẫn hoàn toàn có thể biết được cảm xúc của họ thông qua giọng nói.
Thêm 1 chiếc camera thứ 2 tất nhiên sẽ khiến cho công đoạn hậu cần phức tạp hơn, và tôi nghĩ nó
cũng không đáng cho lắm. Tất nhiên nếu sếp bảo cần quay lại biểu cảm người dùng thì thôi cứ quay
vậy.

Bằng chứng cho khái niệm: Chiếc camera Brundlefly (*) của tôi

(Brundlefly là từ mà nhân vật do Jeff Goldblum thủ vai - Seth Brundle trong phim ‘The Fly' (Con Ruồi) đã sử
dụng để mô tả bản thân mình sau 1 thí nghiệm với thiết bị dịch chuyển đã vô tình dung hoà DNA của hắn với
DNA của 1 con ruồi.)

Vì tò mò thuần tuý, tôi đã tự lắp ghép 1 dàn camera tự chế bằng cách gắn cái Webcam vào thiết bị mobile
bằng phần kẹp trong chiếc đèn bàn thu gọn. Cầm lên gần như không nặng thêm bao nhiêu, và chỉ cần thêm 1
chiếc Microphone là có thể thu được âm thanh rồi. Thiết bị của tôi tốn khoảng $30 cho tổng tất cả các thiết bị,
và khoảng 1 tiếng để lắp ráp. Tôi chắc chắn là ai đó sẽ tự làm được cái gì đó tương tự sớm thôi - có khi còn
ngon hơn ấy. Tôi vẫn sẽ đăng tải bản hướng dẫn cách lắp ráp tại nhà trên trang rocketsurgerymadeeasy.com
Gắn camera trực tiếp vào thiết bị mobile mang lại 1 khung hình rất tiện lợi để theo dõi. Chúng ta có thể quan
sát 1 khung hình cố định kể cả khi ứng viên cầm thiết bị di chuyển xung quanh.

Tôi nghĩ phương pháp này đã giải quyết được hầu hết các lập luận phản đối các phương án gắn camera khác:
- Chúng quá nặng và bất tiện. Thiết bị này gần như không nặng thêm bao nhiêu, và khi thao tác bạn
không cần phải thay đổi tư thế cầm.
- Chúng gây xao nhãng. ​Thiết bị này rất nhỏ (thậm chí ngoài đời còn nhỏ hơn cả trong ảnh) và được
lắp ráp sao cho máy quay nằm ngoài tầm nhìn của người dùng, nhưng vẫn quay được toàn bộ màn
hình thiết bị mobile.
- Không ai muốn gắn cái gì vào điện thoại của họ cả. Các thiết bị cố định màn hình thường được gắn
vào điện thoại bằng băng dính 2 mặt hoặc băng dính gai. Trong khi đó thiết bị của tôi dùng 1 cái kẹp
nhỏ gọn, không thể làm trầy xước điện thoại nhưng vẫn đủ chắc chắn để bám vào thiết bị.
Một điểm yếu của phương pháp này là khâu chuẩn bị dây dợ tạm bợ: Nó cần có 1 dây cáp USB nối từ
camera tới laptop. Nhưng bạn cũng có thể mua 1 sợi dây kết nối dài hơn với giá không đắt hơn bao
nhiêu.

Khâu chuẩn bị còn lại rất đơn giản.

- Kết nối thiết bị Brundlefly với laptop của điều phối viên qua USB
- Mở trình duyệt chiếu video để hiển thị khung màn hình được quay từ thiết bị Brundlefly. Điều phối viên
sẽ quan sát qua laptop.
- Chia sẻ màn hình laptop với các quan sát viên sử dụng các ứng dụng chia sẻ màn hình (GoToMeeting,
WebEx, etc...)
- Chạy phần mềm quay màn hình (ví dụ như Camtasia) trên màn hình trong phòng quan sát. (không
chạy phần mềm này trực tiếp trên laptop của Điều phối viên vì như vậy sẽ khá nặng máy.)

Thế thôi.

Cuối cùng...

Bằng cách này hay cách khác, có lẽ xu thế trong tương lai sẽ là mobile, nơi mà chúng ta có thể làm được mọi
thứ, và điều này mang lại những cơ hội khổng lồ để tạo ra các trải nghiệm người dùng tuyệt vời và các tính
năng hữu ích. Những công nghệ mới cũng sẽ được ra đời liên tục và nhanh chóng, và có thể 1 trong số chúng
sẽ có liên quan trực tiếp tới những cách tương tác khác nhau giữa người dùng và thiết bị.
(Cá nhân tôi dự đoán việc nói chuyện với thiết bị của bạn sẽ là 1 trong những bước đột phá công nghệ tiếp
theo. Với sự ra đời của công nghệ có khả năng nhận diện giọng nói với độ chính xác cao, chúng ta chỉ cần tìm
cách để người dùng có thể nói chuyện với các thiết bị của họ sao cho họ không cảm thấy quá đần độn. Nếu ai
đó đang làm việc nghiêm túc trong lĩnh vực này đọc được đoạn này thì hãy gọi tôi nhé, tôi đã sử dụng các
phần mềm nhận diện giọng nói trong suốt 15 năm vừa qua, và tôi có rất nhiều chiêm nghiệm về tính phổ biến
của công nghệ này.)

Chỉ cần nhớ là, đừng bao giờ bỏ quên Tính khả dụng trong 1 mớ bòng bong các ưu tiên khác. Và cách tốt
nhất để đảm bảo điều này, chính là Testing.
Chương 11. Tính khả dụng như một thường thức ở đời

Tại sao Website của bạn nên là Thạch Sanh (Bản gốc là từ “Mensch" - một từ mượn có nguồn gốc từ tiếng
Đức, có nghĩa gốc là “con người”. Hiện tại từ này được dùng để mô tả những người thành thật, đàng hoàng,
đáng được tôn trọng. Ai đó thường làm việc tốt, việc nghĩa.)

Chân thành à: làm cái đấy mới khó.

Nếu mày giả tạo được cả sự chân thành, thì phần còn lại dễ như ăn bánh.

_ Một mẩu chuyện đùa đã cũ về 1 ai đó ở Hollywood _

Một thời gian trước đây, tôi được đặt trước 1 chuyến bay tới Denver. Hoá ra, ngày diễn ra chuyến bay của tôi
lại là ngày deadline cho 1 cuộc thương lượng về quyền lợi (hay còn lại là đình công) giữa hãng hàng không
mà tôi được đặt vé với 1 bên Công đoàn thuộc hãng đó.

Lo lắng, tôi làm điều mà ai cũng làm: (a) Kiểm tra Google News đều đặn để xem 2 bên đã đạt được thoả thuận
chưa, và (b) thường xuyên vào trang Web của hãng hàng không đó để xem họ có thông báo gì không.

Tôi đã rất ngạc nhiên khi biết rằng ở trên Trang chủ của hãng hàng không kia không hề có thông tin gì về cuộc
đình công của nhân viên, mà thậm nguyên cả cái trang Web cũng không nhắc tới sự kiện đó dù chỉ 1 chữ. Tôi
đã lần mò khắp nơi. Tôi thậm chí còn xem trong danh sách FAQ. Vẫn chỉ là những câu hỏi dịch vụ thông
thường. “Đình công? Đình công nào? Ai biết đâu."

Lúc đó, vào buổi sáng cất cánh chuyến bay của tôi, cũng là buổi sáng deadline cho cuộc thương lượng kia,
bạn phải hiểu là sẽ chỉ tồn tại duy nhất 1 câu hỏi mà người ta muốn hỏi trên cái trang Web đó, và có lẽ nó
cũng là thắc mắc của cả trăm ngàn người ở trong cùng hoàn cảnh như tôi: “Thế bây giờ chuyến bay của tôi sẽ
ra sao?”

Tôi đã kì vọng tìm được hẳn 1 danh sách FAQ chi tiết và rõ ràng, rành riêng cho sự kiện đó:
- Liệu có đình công diễn ra thật không?
- Cuộc thương lượng đang diễn biến ra sao?
- Nếu có đình công thì điều gì sẽ xảy ra?
- Làm thế nào để tôi đặt lại vé máy bay của mình?
- Hãng sẽ làm gì để giúp chúng tôi trong hoàn cảnh này?

Nhưng không có gì hết cả.

Tôi nhận ra được điều gì từ việc này?
Hoặc là (a) hãng hàng không nọ không có quy trình cập nhật trang Homepage cho những trường hợp đặc
biệt, hoặc là (b) họ không muốn công bố rằng mình có 1 cuộc đình công vì lý do kinh doanh hoặc lý do pháp lý
nào đó, hoặc là (c) họ không nghĩ rằng sẽ có người ngoài quan tâm tới chuyện đó, hoặc là (d) họ chẳng thèm
quan tâm.

Bất kể lý do thật sự là gì, điều này thật sự đã làm tôi mất thiện cảm với cả hãng hàng không kia và cả trang
Web của họ luôn. Thương hiệu của họ - thứ mà họ đã đầu tư cả trăm triệu USD chải chuốt đánh bóng trong
nhiều năm - đã không còn thu hút đối với tôi nữa.

Phần lớn của cuốn sách này đã nói về cách đưa sự minh bạch, dễ hiểu, rõ ràng vào sản phẩm của bạn: Đảm
bảo rằng người dùng hiểu được thứ họ đang xem - và cách sử dụng nó - mà không tốn nhiều công sức.

Nhưng Tính khả dụng còn 1 nguyên tố quan trọng khác nữa: Làm điều đúng đắn - quan tâm tới người dùng và
quyền lợi của họ. Bên cạnh câu hỏi “trang Web của tôi đã đủ rõ ràng chưa?”, bạn cũng cần đặt ra câu hỏi này
cho bản thân “Dịch vụ của tôi có cư xử đàng hoàng như Thạch Sanh không?”

Kho thiện cảm

Tôi thường hình dung về 1 cái bình máu - giống bình máu / mana trong game ấy - và gọi nó là kho Thiện cảm
của bản thân mỗi khi vào 1 Website. Mỗi khi gặp 1 vấn đề nào đó, kho Thiện cảm sẽ hụt đi 1 chút. Ví dụ với
trang web của hãng hàng không mà tôi vừa kể trên:

Kho Thiện cảm của mỗi người đều có hạn, và nếu bạn đối xử tệ bạc với người dùng và làm cạn kho Thiện
cảm thì khả năng cao là họ rời trang thôi. Nhưng rời trang có thể còn không phải là hậu quả duy nhất, người
dùng có thể sẽ không dùng sản phẩm của bạn lần nào nữa, hoặc họ sẽ có ấn tượng xấu và truyền miệng tới
những người dùng tiềm năng của sản phẩm, hoặc đơn giản là họ cho đánh giá 1 sao và miệt thị sản phẩm
trên các thể loại mạng xã hội. Với mấy ông làm MKT thì cái chỉ số NPS (Net Promoter Score) của ông chắc
chắn sẽ tụt dốc nặng nề.
Cũng có những thứ đáng lưu ý về cái gọi là kho Thiện cảm này:
- Đặc trưng cá nhân. Độ lớn nhỏ của kho Thiện cảm phụ thuộc vào tính cách mỗi người. Có người
thường sẽ đa nghi hơn, có người lại cục tính hơn, có người dễ tin tưởng, có người lại đầy tò mò.
Tuy nhiên, kể cả kho có lớn đến đâu đi nữa thì cũng không nên phụ thuộc vào yếu tố này quá nhiều.
- Tuỳ vào tình huống. Nếu mà tôi đang vội, hoặc là vừa có 1 trải nghiệm tồi tệ từ 1 trang khác, có lẽ kho
Thiện cảm của tôi khi xem trang của bạn sẽ thấp hơn hẳn so với bình thường, kể cả khi kho Thiện cảm
của tôi vốn cũng khá là lớn.
- Có thể hồi lại. Kể cả khi bạn làm gì đó sai và khiến cho tôi mất Thiện cảm, bạn vẫn có thể phục hồi lại
kho bằng cách làm những thứ có ích, giúp cho tôicarm thấy bạn đang thực sự quan tâm tới lợi ích
khách hàng.
- Đôi khi chỉ cần 1 lỗi thôi là mất luôn toàn bộ. Ví dụ, mở cái form đăng ký ra và thấy 7 7 49 cái
trường thông tin phải nhập cũng là đủ để làm cạn luôn kho Thiện cảm của ai đó, khiến họ nản chí và
rời trang luôn.

Những điều gây mất Thiện cảm

Sau đây là 1 vài thứ khiến cho người dùng có cảm giác không được trân trọng, không được quan tâm:

- Những thông tin mà người dùng muốn xem bị “giấu” đi. Những thứ hay bị giấu đi nhất thường là
Số hotline chăm sóc khách hàng, chi phí ship, và giá tiền.
Chúng nó giấu số Hotline CSKH đi là để cho người dùng đỡ gọi nhiều, vì mỗi cuộc gọi sẽ khiến công ty
chủ quản mất tiền. Hậu quả sẽ là người dùng bị mất thiện cảm và sẽ càng bực mình hơn khi họ tìm ra
được số hotline để gọi. Mặt khác, nếu số Hotline được đặt nổi bần bật trên trang Web, càng rõ càng tốt
- đôi khi người dùng sẽ cố gắng kiên nhẫn hơn 1 chút và tự mình tìm ra thông tin, vì khi đó họ biết họ
hoàn toàn có thể gọi Hỗ trợ nếu muốn.
Một số trang Web giấu thông tin giá cả đi với hi vọng rằng họ sẽ có thể đưa người dùng đi đủ sâu vào
bên trong quy trình mua hàng để khi nhận được thông tin về giá cả thì họ sẽ đỡ shock hơn, vì lúc đó họ
đã bỏ ra nhiều công sức và thời gian để đi gần hết quy trình rồi. Ví dụ ưa thích của tôi cho vấn đề này
chính là mấy cái trang Web cung cấp dịch vụ Wifi ở nơi công cộng như sân bay, bến xe.. Bạn mở
laptop lên, tìm Wifi và thử kết nối. Nhưng sau đó bạn lại phải đọc và click qua 1 mớ trang Web trung
gian, theo dấu những đường link như “Kết nối không dây", “Click vào đây để hoà mạng", chỉ để tới
được 1 trang nói về chi phí bạn phải trả để kết nối mạng. Đúng như cái chiến thuật telesale cũ rích:
Nếu họ cố gắng giữ bạn nghe máy đủ lâu, và thuyết minh đủ nhiều về lợi ích sản phẩm, có lẽ họ có thể
thuyết phục bạn mua hàng.

- Trừng phạt người dùng vì không làm mọi thứ theo đúng ý đồ. Đáng ra người dùng không bao giờ
phải lo lắng về việc hình thức dữ liệu (formatting data) được nhập ra sao: Liệu mình có phải thêm dấu
gạch ngang ở số thẻ Credit card không, liệu nhập sđt thì nên nhập mã quốc gia hay nhập số như bình
thường, hay viết tên mình thì có phải viết hoa tất cả không. Có rất nhiều trang Web cứ khăng khăng
 bắt người dùng nhập số Credit card và phải viết cả dấu gạch ngang, trong khi điều đó rất phiền phức.
Đừng có khiến trải nghiệm của người dùng khó khăn hơn chỉ bởi vì các bạn không muốn viết thêm vài
dòng code.
- Bắt người dùng điền quá nhiều thông tin không cần thiết. Phần lớn người dùng thường nghi ngờ
trước những yêu cầu nhập thông tin cá nhân, và sẽ cảm thấy khó chịu nếu 1 trang Web bắt họ nhập
thông tin không liên quan tới thứ mà họ đang cần làm. (Ví dụ tôi chỉ muốn đăng ký tài khoản để xem
thông tin sản phẩm, đừng bắt tôi nhập cả thông tin Credit card và CVC number chứ.)

- Phỉnh nịnh người dùng 1 cách thái quá. Tôi luôn luôn cảnh giác với sự chân thành giả tạo, và
những hành động thoạt đầu có vẻ quan tâm tới khách hàng nhưng thực ra chỉ là để cho lợi ích của bản
thân khiến tôi rất khó chịu. Bạn cứ thử nhớ lại xem mỗi khi bên CSKH nói “cuộc gọi của bạn là rất quan
trọng đối với chúng tôi" thì trong đầu ta đang nghĩ gì, có quan tâm không.

- Tung hoả mù với người dùng. Phải lướt qua 1 mớ trang Web tràn ngập những ảnh minh hoạ và
những content nửa vời cho thấy rõ ràng rằng bạn không hiểu, hoặc không quan tâm tới việc người
dùng có thể đang vội.

- Thiết kế kiểu nghiệp dư. Người dùng có thể mất thiện cảm nếu trang Web trông ẩu tả, lộn xộn, không
chuyên nghiệp, như thể đội ngũ xây dựng không hề đầu tư thời gian công sức để làm sao cho trang
Web trông dễ coi.
Tuy nhiên, trong khi phần lớn người dùng thích comment, phê bình, góp ý về giao diện của 1 trang
Web - đặc biệt là vấn đề màu sắc - hầu như không ai lại đi rời 1 trang Web chỉ bởi vì nó trông không
được ưng mắt cả (Tôi thường bảo mọi người cứ bỏ qua mấy cái comment liên quan đến màu sắc trong
1 cuộc Usability Testing, trừ khi có cùng 1 lúc nhiều người đều cho rằng cái bảng màu hiện tại trông
muốn mửa. Lúc đó thì mới đáng lưu tâm. Chuyện này đã xảy ra 1 lần trong 1 cuộc Test do tôi điều phối
rồi. Sau đó khách hàng phải đổi màu luôn.)
Sẽ có những lúc bạn phải cố tình chọn 1 phương án không thân thiện với người dùng. Đôi khi việc
không làm theo ý nguyện khách hàng lại là 1 phần chủ đích của sản phẩm, trên quan điểm về mặt kinh
doanh (business sense). Ví dụ, người dùng ai cũng ghét mấy cái pop-up không biết ở đâu ra tự nhiên
bật lên. Nhưng nếu số liệu thống kê cho thấy doanh thu của bạn tăng lên 10% nhờ việc sử dụng
pop-ups và nếu bạn thấy đó là 1 con số đáng để đánh đổi, thì cứ thế mà triển thôi. Đó là 1 quyết định
về mặt chiến lược kinh doanh. Chỉ cần đảm bảo là nếu bạn có làm thì làm 1 cách văn minh, rõ ràng
đầy đủ thông tin, thay vì kiểu chộp giật, đánh úp.
Những điều tạo ra Thiện cảm

Tin tốt lành là kể cả khi bạn có lỡ mắc sai lầm, bạn vẫn có thể lấy lại thiện cảm bằng cách làm những điều
khiến người dùng tin rằng bạn có quan tâm tới họ và lợi ích của họ. Phần lớn các giải pháp đều đơn giản chỉ
là làm ngược lại với những điều gây mất Thiện cảm được nhắc tới bên trên.

- Biết những thứ mà người dùng muốn làm / muốn xem trên trang Web của bạn và làm nổi bật
chúng nó lên. ​Thường thì không khó để tìm ra thứ mà người ta muốn làm trên 1 trang Web. Kể cả
những người mà hiểu sai về hầu hết những thứ khác trong trang Web của của chính công ty họ cũng
có thể trả lợi được đại khái câu hỏi “3 điều cơ bản mà người dùng muốn làm trên trang của bạn là gì?”.
Vấn đề là, việc làm nổi bật chúng lên chưa hẳn được coi là 1 ưu tiên hàng đầu. (Đáng ra, nếu phần lớn
người dùng vào trang Web của bạn để đăng ký thế chấp, thì không có gì gì khác được cản trở họ đăng
ký thế chấp 1 cách đơn giản, nhanh gọn. Vậy thôi).

- Trình bày cho người dùng những gì họ cần được biết. Hãy thẳng thắn và minh bạch về những thứ
như giá tiền ship, phí đỗ xe hàng ngày, phí dịch vụ - tất cả những thứ mà bạn không muốn minh bạch.
Bạn có thể sẽ mất điểm vì phí ship gì mà cao thế, nhưng bạn sẽ gây được thiện cảm vì sự minh bạch
và khiến người dùng dễ bỏ qua cho sự chênh lệch về giá cả hơn.

- Rút gọn quy trình nếu bạn có thể. Ví dụ, thay vì cho người dùng biết về mã tracking ID từ 1 công ty
vận chuyển nào đó cho đơn hàng của tôi (bắt tôi tự lấy mã ID, tự vào công ty đó, tự nhập mã) thì hãy
dẫn thẳng 1 cái link tới trang Web của công ty vận chuyển đó trong Biên lai được gửi qua email cho tôi,
và tôi chỉ cần click vào link là tracking ID sẽ được nhập tự động luôn trên trang Web đó. (Như thường
lệ thì Amazon là bên đầu tiên cung cấp tính năng này.)

- Đầu tư công sức vào mọi thứ. Ví dụ ưa thích của tôi là trang Hỗ trợ kĩ thuật của HP, nơi mà tôi có
thể thấy được rõ ràng sự đầu tư của đội ngũ phát triển vào việc (a) cung cấp đầy đủ thông tin khách
hàng cần để có thể tự giải quyết vấn đề, (b) đảm bảo thông tin đó chính xác và hữu ích, (c) trình bày
nó 1 cách rõ ràng dễ hiểu, và (d) sắp xếp nó hợp lý để ai cũng tìm ra được. Tôi đã sử dụng rất nhiều
máy in của bên HP, và hầu như mỗi khi tôi gặp vấn đề nào đó, tôi đều tự xử lý được. Kết quả là, tôi trở
thành khách hàng trung thành của HP.

- Biết những khó khăn mà khách hàng có thể gặp phải, và chuẩn bị phương án giải quyết cho
khó khăn đó. T ​ rang FAQ (Frequently Asked Questions - Những câu hỏi thường gặp) là rất có giá trị,
đặc biệt là khi
+ Trang đó thực sự bao gồm những câu hỏi thường gặp, không phải là chiêu trò Marketing trá
hình - dùng những câu hỏi đơn giản, không liên quan để cho ra 1 câu trả lời mang tính PR cho
sản phẩm. (Đó không gọi là trang “Những câu hỏi thường gặp”, mà là trang “Những câu hỏi
mình muốn gặp" thì đúng hơn)
 + Trang đó được cập nhật thường xuyên. bên Chăm sóc khách hàng và Hỗ trợ kĩ thuật có thể dễ
dàng cho bạn 1 danh sách 5 vấn đề được hỏi nhiều nhất trong tuần. Tôi sẽ luôn luôn đặt danh
sách này ở trên đầu của trang Hỗ trợ trong mọi trang Web.
+ Trang đó đưa ra giải pháp chính xác, trung thực. Thường thì trang FAQ sẽ bao gồm những vấn
đề khó khăn mà bạn ước gì mình không phải giải đáp cho khách hàng. Sự trung thực trong
những tình huống này thực sự tạo ra Thiện cảm.

- Cung cấp những tính năng mang tính thoải mái như các trang Web tiện cho việc in ấn. Có 1
người thích in ra những bài báo / câu chuyện trải dài trên nhiều trang chỉ với 1 click duy nhất, và chỉ
cần 1 chút thao tác với CSS thôi đã khiến việc này tương đối dễ dàng rồi. Vứt hết quảng cáo đi, nhưng
đừng vứt hình minh hoạ, số liệu hay tranh ảnh.

- Khiến cho việc sửa lỗi dễ dàng hơn với người dùng. Nếu bạn thực sự tiến hành Testing người
dùng đủ nhiều, bạn sẽ có thể giúp người dùng tránh được 1 mớ lỗi linh tinh trên thực tế. Nhưng nếu
thực tế rằng việc lỗi xảy ra là không thể tránh khỏi, hãy luôn luôn cung cấp 1 phương pháp rõ ràng,
hợp lý để người dùng có thể sửa lỗi đó.

- Khi chưa biết phải làm gì, cứ xin lỗi cái đã. Đôi khi mấy việc như này cũng xả ra: Bạn đơn giản là
không có đủ lực hay đủ vốn hay đủ trình để làm thứ mà người dùng mong muốn (ví dụ, hệ thống thư
viện tại trường ĐH luôn yêu cầu mật khẩu tách biệt cho từng kho dữ liệu, nên bạn không thể cho phép
người dùng chỉ log in 1 lần như bình thường họ muốn làm). Nhưng nếu bạn đã không thể làm thứ họ
mong muốn, thì ít nhất cũng nên cố gắng sao cho họ hiểu rằng: “Chúng tôi biết bạn đang không thoải
mái, nhưng đây là phương pháp khả quan nhất tại thời điểm này. Hãy thông cảm nhé!”
Chương 12. Tính dễ tiếp cận và bạn

Đúng cái lúc bạn tưởng là xong xuôi rồi, 1 con moè bay qua, trên lưng nó có gắn 1
miếng bánh mì nướng phết bơ.

Khi thả 1 con moè từ trên cao xuống, lúc nào nó cũng xoay sở để tiếp đất bằng chân, và
khi thả 1 miếng bánh mì nướng từ trên cao xuống, lúc nào mặt phết bơ cũng là mặt tiếp
đất. Tôi đề nghị gắn bánh mì phết mơ lên lưng 1 con moè, 2 thứ đó sẽ xoay vòng vòng
không chịu tiếp đất và lơ lửng trên không trung. Với 1 số lượng lớn bánh mì phết mèo
bơ, chúng ta có thể tạo ra đủ năng lượng cho đầu máy tàu điện đi từ New York tới tận
Chigago.

_ JOHN FRAZEE, trong cuốn “Nhật ký các nhiệm vụ bất khả thi”_

Thi thoảng có người hỏi tôi, “Còn Accessibility (Tính dễ tiếp cận) thì sao? Chẳng phải đó cũng là 1 phần của
Tính khả dụng à?”
Và tất nhiên là họ đúng. Trừ khi bạn tính quy chụp rằng những người khuyết tật không phải là 1 tập khách
hàng của mình, bạn không thể công nhận rằng trang Web của mình là khả-dụng nếu nó không cho người ta
khả năng tiếp cận.
Tầm này thì, hầu như bất cứ ai có liên quan tới Web design đều phải biết ít nhất 1 chút về Tính dễ tiếp cận
trên Web. Nhưng hầu như mọi trang Web tôi vào thử đều trượt bài kiểm tra trong 3 giây về Tính dễ tiếp cận -
Tăng kích cỡ chữ. (nếu bạn đang tính gửi cho tôi 1 cái email nhắc nhở rằng Zoom đang thay thế Text size
trong phần lớn các trình duyệt, thì tôi cảm ơn, nhưng thôi bạn không cần gửi đâu. Tất cả các trang Web sẽ
được zoom to hơn nếu bạn dùng Zoom, nhưng chỉ với những trang Web nào đã không còn sử dụng các font
cố định 1 size - thường thì đây chính là dấu hiệu cho thấy những nỗ lực khiến cho trang Web dễ tiếp cận hơn)
 Đổi “Text size” của Browser bạn đang dùng sang “Largest”

Sau đó (không có sự khác biệt)

Tại sao lại như vậy?

Developer và designer nghe thấy những gì

Trong hầu hết các công ty, những người phải chịu trách nghiệm giải quyết các vấn đề về Tính dễ tiếp cận của
1 sản phẩm thường hoá ra lại chính là những người đã xây dựng nó: Đội Designer và đội Developer.

Khi họ cố tìm hiểu về những thứ mình nên làm, bất cứ kho tài liệu nào, bất kể sách vở hay tạp chí nghiên cứu
nào cũng đều liệt kê ra 1 danh sách y hệt nhau: Những lý do tại sao bạn cần xây dựng 1 trang Web sao cho
nó dễ tiếp cận nhất:
- Đó là 1 quyết định tốt về mặt kinh doanh - Kể cả người khuyết tật cũng vào mạng như thường mà, và
họ cũng là khách hàng đối với chúng ta.
- Tất cả mọi người cần được sở hữu những cơ hội và khả năng tiếp cận thông tin tương đồng với nhau.
- Phần lớn các tính năng giúp ích cho việc cải thiện tính dễ tiếp cận, cũng giúp cải thiện trải nghiệm sử
dụng với tất cả mọi người.
- Thị trường này cực kì lớn, ước tính 65% dân số đều có 1 dạng khuyết tật nào đó.
- Mục 508 - cái này thậm chí còn không phải là 1 ý tưởng tốt nữa r, nó chính là luật rồi.

Có rất nhiều thứ đúng trong danh sách lý do này. Tuy nhiên, đó là chưa đủ để có thể thuyết phục các bạn
designer và developer tuổi đời mới ngoài 20 làm về “Tính dễ tiếp cận". Trong đó có 2 luận điểm khiến cho họ
đặc biệt nghi ngờ:
- ___% dân số đều có 1 dạng khuyết tật nào đó: Vì tập hợp những người mà họ gặp hàng ngày chủ
yếu là những người lành lặn, tuổi đời trẻ, rất khó để bắt họ tin rằng 1 phần lớn dân số thực sự cần hỗ
trợ khi muốn sử dụng web. Họ sẵn sàng coi luận điểm này như là 1 sự phóng đại thường gặp mỗi khi
người ta đang cố gắng thuyết phục ai đó hướng tới 1 lý tưởng lớn lao nào đó, nhưng họ cũng sẽ có xu
hướng nghĩ rằng: “Nếu 1 luận điểm trong này rõ ràng là không có cơ sở, thì tôi hoàn toàn có quyền
nghi ngờ về tất cả các luận điểm còn lại"
- Việc thiết kế sản phẩm sao cho dễ tiếp cận hơn sẽ có lợi cho tất cả mọi người: Họ biết rằng đúng
là những chuyển đổi trong thiết kế đôi khi cũng tiện lợi cho cả những người bình thường, ví dụ như chế
độ Phụ đề (CC - Closed captioning) cũng giúp cải thiện trải nghiệm sử dụng sản phẩm cho cả những
người không bị khiếm thính (Ví dụ, tôi và vợ tôi Melanie thường bật phụ đề lên khi xem phim UK).
Nhưng vì CC luôn là ví dụ duy nhất được sử dụng cho luận điểm này, nên cảm giác như họ đang tranh
luận kiểu “Những dự án đưa con người lên vũ trụ chỉ có ích lợi vì từ đó chúng ta có đồ uống Tang" (1
loại đồ uống dạng bột, có vị cam, được chế riêng dành cho phi hành gia). Sẽ đơn giản hơn rất nhiều
cho Developer và Designer nghĩ ra những trường hợp mà các chuyển đổi mang tính dễ tiếp cận trong
thiết kế gây ra phiền toái hơn cho “những người còn lại"

Điều tệ nhất về sự nghi ngờ này chính là việc nó có thể làm lu mờ đi cái sự thật hiển nhiên nhất, quan trọng
nhất:
- ​Đó là thứ nên làm: Và nó không chỉ đơn giản là thứ “nên" làm; bởi vì đó là điều đúng đắn mang tính
căn bản, bởi vì 1 luận điểm mạnh mẽ bảo vệ cho Tính dễ tiếp cận nhưng lại không được sử dụng
nhiều, đó là việc Tính dễ tiếp cận đã giúp cải thiện cuộc sống của con người nhiều tới mức nào. Cá
nhân tôi thấy chỉ 1 ví dụ này là quá đủ: “Những người mù giờ đây đã có thể dùng máy tính và tự đọc
hầu hết các trang tin tức báo chí trên mạng.” Tưởng tượng mà xem.
Chúng ta có bao nhiêu cơ hội để có thể cải thiện cuộc sống của mọi người, chỉ bằng việc nỗ lực làm tốt công
việc của mình hơn 1 chút?
Và với những người vẫn không thấy luận điểm này thuyết phục, hãy ghi nhớ rằng kể cả khi bạn chưa thực sự
đối mặt với nó, một hình thức lập pháp nào đó yêu cầu bạn phải thiết kế với đầy đủ tính tiếp cận sẽ tới, không
sớm thì muộn. Cứ chờ xem.

Developer và designer sợ những gì

Khi họ hiểu nhiều hơn về Tính dễ tiếp cận, 2 nỗi sợ hãi sẽ xuất hiện:
- Nhiều việc hơn. Đặc biệt là với Developer, Tính dễ tiếp cận có thể được xem như là 1 tính năng mới,
phức tạp, khó nhằn, được ném vào trong 1 dự án mà vốn đã có lịch trình chặt chẽ và khối lượng công
việc đồ sộ. Trường hợp xấu nhất, cái này được truyền xuống như là 1 “chỉ thị" từ cấp trên, bổ sung
cùng 1 mớ báo cáo, họp review tốn thời gian.
- Thiết kế phải làm dâu trăm họ. Thứ mà đội designer sợ nhất chính là thứ mà tôi nhắc đến dưới cụm
từ “bánh mì mèo bơ" - Khi mà các thiết kế tốt cho người khuyết tật lại nằm ở thái cực đối nghịch với
thiết kế tốt cho những người còn lại. Họ lo sợ rằng mình sẽ buộc phải thiết kế các trang web ít thẩm mỹ
hơn, ít hấp dẫn hơn - và ít hữu ích hơn - với phần lớn tập khách hàng.

Trong 1 thế giới lý tưởng, Tính dễ tiếp cận sẽ hoạt động như cái tấm biển mà tôi từng thấy trong 1 chiếc xe
Taxi tại Chicago. Thoạt nhìn thì cũng giống 1 tấm biển thông báo bình thường. Nhưng khi trông ánh sáng
phản chiếu lên nó trông là lạ thì tôi mới nhìn kĩ hơn, và khi hiểu ra thì tôi thấy đây là 1 ý tưởng thiên tài.

Tấm biển hiệu được đặt thêm 1 lớp nhựa Plexiglas, và trên lớp nhựa trong suốt đó có đính ngôn ngữ nổi
(Braille). Thông thường thì cả bản thiết kế chữ thường và chữ Braille sẽ chỉ chiếm 1 nửa diện tích, vì 2 bản
phải san sẻ cùng 1 khoảng trống, nhưng với thiết kế này thì cả 2 tập khách hàng đều có được trải nghiệm sử
dụng sản phẩm tối ưu. Đây là 1 phương án tinh tế thực sự.
Tuy nhiên tôi nghĩ, với 1 số designer, Tính dễ tiếp cận mang lại 1 ấn tượng không mấy tích cực đối với họ,
như 1 mẩu chuyện ngắn của Vonnegut: chính phủ tạo ra sự bình đẳng bằng cách.. làm tàn tật tất cả mọi
người. (Trong cuốn “Harrison Bergeron”, George - nhân vật chính có trí thông minh “cao hơn hẳn người bình
thường", bị buộc phải đeo trên tai 1 cái “radio khuyết tật" mọi lúc mọi nơi. Cái radio này sẽ phát ra nhiều âm
thanh vô nghĩa ồn ào cứ 20 giây 1 lần, để làm cho những người như George không thể “lợi dụng não bộ của
mình”)

Sự thật là, việc này có thể rất phức tạp

Khi người ta tìm hiểu về Tính dễ tiếp cận, họ thường gặp 1 lời khuyên nghe có vẻ rất hứa hẹn:

Vấn đề là, khi chạy Validator cho 1 trang Web, hoá ra nó giống như 1 cuộc kiểm tra về ngữ pháp hơn là về
chính tả. Ừ thì đúng là nó cũng có tìm ra những lỗi hiển nhiên và dễ sửa, như kiểu phần Alt text bị mất đi (Alt
text cung cấp 1 dòng chữ mô tả cho 1 hình ảnh nào đó, cực kì hữu ích với những người sử dụng các phần
mềm screen reader (phần mềm chuyên dụng giúp cải thiện trải nghiệm sử dụng Web cho người khuyết tật)
hoặc những người lướt web mà không bật chế độ hiển thị hình ảnh) Nhưng nó cũng đồng thời trả về 1 loạt
những cảnh báo mơ hồ là bạn có thể đã làm cái gì đó sai, và 1 danh sách dài dằng dặc những thứ bạn nên
check mà chưa chắc những thứ đó đã là vấn đề.

Điều này có thể gây nản chí với những người vừa mới tìm hiểu về Tính dễ tiếp cận, bởi vì những danh sách
dài ngoẵng và những lời khuyên mơ hồ có nghĩa là họ phải tự mày mò tìm hiểu thêm rất rất nhiều.
Và sự thật là, việc biến 1 trang Web trở nên dễ tiếp cận hơn đáng ra phải dễ hơn rất nhiều, nhưng trên thực tế
nó lại khá phức tạp.

Sau cùng thì, phần lớn designer và developer sẽ không trở thành các chuyên gia về Tính dễ tiếp cận được.
Nếu Tính dễ tiếp cận trên Web có trở nên phổ cập, thì nó cũng phải dễ làm, dễ hiểu hơn nhiều. Các phần
mềm screen reader và các công nghệ mang tính thích ứng cũng phải thông minh hơn, các công cụ xây dựng
trang Web (như Dreamweaver) cũng phải được thiết kế sao cho việc lập trình Tính dễ tiếp cận 1 cách chính
xác dễ dàng hơn, và quy trình thiết kế của chúng ta cũng phải cần được cập nhật sao cho tư duy về Tính dễ
tiếp cận tồn tại ngay từ những bước đầu.

4 điều bạn có thể làm ngay từ bây giờ

Sự thật là hiện tại chúng ta đang gặp khó khăn trong việc áp dụng Tính dễ tiếp cận cho các sản phẩm không
có nghĩa là chúng ta không thể làm gì về điều này.
Kể cả với tiêu chuẩn và công nghệ hiện tại (2013), ta vẫn có thể làm cho hầu hết mọi trang Web dễ tiếp cận
hơn mà không cần tốn quá nhiều công sức, bằng cách tập trung vào chỉ một vài thứ có tầm ảnh hưởng lớn
nhất. Và may là nó cũng không liên quan gì tới bánh mì mèo bơ cả nhé.

- #1 Sửa những lỗi về Tính khả dụng gây khó hiểu cho người dùng.
Một trong những điều tôi thấy khó chịu nhất về cái luận điểm Tang nhắc tới bên trên (làm cho 1 trang
web dễ tiếp cận khiến cho nó dễ dùng hơn với tất cả mọi người) chính là việc nó đã làm lu mờ đi tính
đúng đắn của mệnh đề ngược lại: Làm cho 1 trang web dễ dùng hơn với tất cả phần còn lại của người
dùng chính là 1 trong những cách hiệu quả nhất để khiến trang web đó dễ tiếp cận hơn với những
người khuyết tật.
Nếu 1 thứ gì đó gây khó hiểu với phần lớn người dùng trên trang của bạn, khả năng cao là nó cũng
gây khó hiểu với những người dùng có vấn đề về Tính tiếp cận. (Sau cùng thì cũng có ai tự nhiên trở
nên thông minh đột xuất khi mà bị khuyết tật đâu.) Và cũng rất có khả năng là họ còn mất nhiều thời
gian công sức hơn để vượt qua cái sự khó hiểu kia.
Ví dụ, hãy nghĩ tới 1 lần bạn gặp khó khăn khi sử dụng 1 trang Web (gặp 1 thông báo lỗi khó hiểu khi
bạn đang điền form thông tin, kiểu kiểu thế). Giờ thử tưởng tượng mình giải quyết vấn đề đó, khi mà
bạn bị khiếm thị.
Điều tốt nhất, đơn giản nhất mà bạn có thể làm để cải thiện Tính dễ tiếp cận của trang Web của bạn
chính là test nó thường xuyên, và liên tục loại bỏ những phần có tiềm năng gây khó hiểu với người
dùng. Trên thực tế, nếu bạn không ưu tiên cho việc này trước, kể cả bạn có áp dụng quy tắc hướng
dẫn về Tính dễ tiếp cận nhiều và kĩ lưỡng tới mức nào, thì những người khuyết tật vẫn sẽ không thể
sử dụng được trang Web của bạn.

- #2 Đọc nghiên cứu.

Tôi hi vọng là bạn đã hiểu được rằng: Cách tốt nhất để học cách khiến cho mọi thứ dễ dùng hơn chính
là quan sát người ta sử dụng nó. Nhưng phần lớn chúng ta thậm chí còn không có kinh nghiệm sử
dụng Công nghệ thích ứng (các công cụ hoặc sản phẩm được tạo ra để hỗ trợ người khuyết tật), đừng
nói gì tới việc quan sát người ta sử dụng chúng.
Nếu bạn có động lực và thời gian, tôi khuyến khích bạn tìm 1 vài người khiếm thị hay dùng Web, và
dành thời gian quan sát họ sử dụng thiết bị screen reader.
May mắn là, việc gian khổ đó đã có người làm giúp bạn. Mary Theofanos và Janice (Ginny) Redish đã
quan sát 16 người khiếm thị sử dụng thiết bị screen reader để làm 1 số tasks trên các trang Web và
tổng hợp lại những gì họ thu được trong 1 bài nghiên cứu có tên “Hướng dẫn thiết kế trang Web có
Tính khả dụng và Tính dễ tiếp cận: Quan sát người dùng sử dụng thiết bị Screen reader” (bài
nghiên cứu được xuất bản trên tạp chí Tương Tác ACM - tháng 9/10 2003. Với sự đồng thuận từ ACM,
Ginny đã có thể cấp quyền sử dụng bài nghiên cứu cho mục đích cá nhân tại trang
 redish.net/images/stories/PDF/InteractionsPaperAuthorsVer.pdf.​ Đúng là tới thời điểm cuốn sách này
được xuất bản (2013), bài nghiên cứu đã 10 năm tuổi, nhưng vẫn giữ nguyên giá trị thông tin vốn có)
Như với mọi loại User testing, bài nghiên cứu cung cấp những thông tin cực kì quý báu. Đây là 1 ví dụ
về những thứ họ đã khám phá ra:
Những người sử dụng Screen-reader dùng tai để quét thông tin. ​Hầu hết người khiếm thị cũng
giống như người bình thường, cũng không được kiên nhẫn cho lắm. Họ muốn có được thông tin mình
cần càng nhanh càng tốt. Họ cũng không nghe mọi thứ trên trang Web - cũng như cái cách những
người dùng bình thường không đọc mọi thứ trên trang Web. Họ dùng tai để “quét thông tin". chỉ nghe
đủ để quyết định xem có nên nghe thêm nữa không. Rất nhiều người còn chỉnh tốc độ đọc của Screen
reader nhanh tới đáng ngạc nhiên.
Họ nghe những từ đầu tiên của 1 link hoặc 1 mẩu content. Nếu nghe không có vẻ liên quan thì họ
chuyển sang link tiếp theo, dòng tiếp theo, bài viết tiếp theo. Nếu 1 người dùng bình thường có thể
quét được keyword bằng cách đọc lướt toàn bộ trang web, 1 người dùng khiếm thị có thể sẽ không
nghe tới cái keyword đó nếu nó không nằm ở ngay đầu câu hoặc ở đầu 1 chiếc link.

Tôi khuyên khích mọi người đọc bài nghiên cứu này trước khi bạn đọc bất cứ thứ gì về Tính dễ tiếp cận. Chỉ
trong 20’ thôi, bài nghiên cứu sẽ giúp bạn hiểu được quy mô và độ phức tạp của những vấn đề bạn sẽ phải
giải quyết.

- #3 Đọc sách.
Sau khi bạn đã đọc xong bài nghiên cứu của Ginny & Mary, bạn có thể dành cuối tuần đọc 1 cuốn sách
về Tính dễ tiếp cận trên Web. Có 2 cuốn sách đặc biệt chất lượng này:
+ A Web for Everyone: Designing Accessible User Experiences (​Trang Web cho tất cả mọi người:
Thiết kế trải nghiệm người dùng dễ tiếp cận) của Sarah Horton & Whitney Quesenbery (Cách
tiếp cận của họ là “UX tốt nghĩa là tính tiếp cận tốt. Sau đây là cách làm tốt cả 2”.)
+ Web Accessibility: Web Standards and Regulatory Compliance (​Tính dễ tiếp cận trong một
trang Web: Các tiêu chuẩn và quy tắc vận hành Web) của Jim Thatcher và 1 số tác giả khác.
(Đây là các quy tắc và tiêu chuẩn, và chúng tôi sẽ giúp bạn làm đúng theo quy tắc và tiêu chuẩn
đó)
Những cuốn sách này nói về rất nhiều mảng kiến thức, nên cũng đừng lo về việc phải học được hết từ
chúng. Ở thời điểm hiện tại bạn chỉ cần hiểu được toàn cảnh là tốt rồi.

- #4 Nhắm tới những mục tiêu vừa tầm, khả thi.

Giờ bạn đã sẵn sàng để thực hiện thứ mà hầu hết mọi người coi là Tính dễ tiếp cận trên 1 trang Web:
Tiến hành những thay đổi nhất định trên thiết kế.
Ngay lúc này đây, những điều dưới đây có lẽ là những thứ quan trọng nhất cần phải làm.
+ Thêm alt text vào các ảnh: Thêm 1 thuộc tính alt rỗng (hoặc là “null") (<alt=””>) cho những ảnh
nào mà screen reader không quét được, và thêm những câu text minh hoạ ngắn gọn cho các
ảnh. Để học cách viết Alt text ổn - và thực ra là học cách làm bất cứ điều gì trong list này ổn -
hãy qua trang ​webaim.org​. Mấy ông ở WebAIM đã soạn ra những bài nghiên cứu thực tiễn cực
kì tốt, bao gồm những chi tiết cơ bản, thực tế của hầu hết mọi kĩ thuật về Tính dễ tiếp cận.
 + Sử dụng tiêu đề hợp lý: Tiêu đề tiêu chuẩn HTML cung cấp thông tin hữu ích về tính tổ chức
về mặt logic trong content cua bạn với những người sử dụng screen reader, và giúp họ điều
hướng bằng bàn phím 1 cách dễ dàng hơn. Sử dụng <h1> với tiêu đề của trang và tiêu đề các
phần content chính, <h2> cho tiêu đề các mục chính, <h3> cho tiêu đề các mục phụ, và cứ thế
tiếp tục, và sau đó sử dụng CSS để tinh chỉnh giao diện đồ hoạ của mỗi level.
+ Thiết kế sao cho các trường form thông tin cũng có thể được quét bởi Screen reader:
Cái này chủ yếu liên quan tới việc sử dụng HTML <label> để gắn trường thông tin với label text
của chúng, để người ta biết họ cần phải nhập cái gì vào trường thông tin này.
+ Đặt nút link “Skip tới content chính" trên đầu mỗi page: Tưởng tượng mình phải bỏ ra 20s
hoặc lâu hơn phải nghe đi nghe lại cái hệ thống điều hướng menu bar trên đầu của mỗi trang
Web rồi mới được nghe tới phần nội dung, và bạn sẽ hiểu tại sao cái nút link này lại cần thiết
tới vậy.
+ Thiết kế sao cho người dùng có thể truy cập tất cả nội dung trên Web bằng bàn phím: Cứ
nhớ kĩ là không phải ai cũng có thể sử dụng chuột để di chuyện trên Web được.
+ Tạo ra sự tương phản cần thiết giữa text và nền background: Chỉ là 1 quy tắc đơn giản về
giao diện thôi, nhưng cũng sẽ giúp ích cho các thiết bị như screen reader hơn nhiều.
+ Sử dụng 1 template website dễ tiếp cận: Nếu bạn đang dùng Wordpress, hãy đảm bảo rằng
theme mà bạn đang chọn đã được thiết kế sao cho nó dễ tiếp cận nhất có thể.

Vậy thôi, vừa tìm hiểu vừa làm thì có lẽ bạn sẽ học hỏi thêm được nhiều hơn nữa, nhưng kể cả khi bạn chỉ
làm những thứ mà tôi nhắc tới ở đây thôi cũng là 1 khởi đầu tuyệt vời rồi.

Khi tôi viết chương này 7 năm trước (2006), kết chương như sau:
“Mong rằng sau 5 năm nữa tôi có thể xoá bỏ chương này và thay vào đó bằng 1 chương khác nhờ vào các
phần mềm phát triển Web, các trình duyệt, các ứng dụng screen reader, các quy chuẩn hướng dẫn đã có sự
phát triển vượt bậc để chúng ta có thể xây dựng các trang Web dễ tiếp cận mà không cần phải lăn tăn.”
Haiizzzz..

Mong là lần này sẽ khả quan hơn.

Chương 13. Hướng đi cho những tâm hồn lạc lối

(​Hướng đi cho những tâm hồn lạc lối (bản thật nhé) là 1 lời bình trác tuyệt về ý nghĩa của bản kinh Talmud
được viết từ thế kỉ 12 bởi Rabbi Moshe ben Maimon (hay còn được biết tới với cái tên phổ biến hơn -
Maimonides). Tôi thấy câu tiêu đề này nó ngầu thực sự nên đã chôm luôn cho chương cuối này.

Áp dụng Tính khả dụng (Usability) lên vạn vật xung quanh bạn.

Tôi là Lorax. Tôi nói thay cho rừng cây.

_ Ngài LORAX, truyện thiếu nhi của tác giả Dr. Seuss _

Tôi nhận được rất nhiều email từ mọi người, hỏi cùng một câu hỏi với đại ý như sau:

“ Oke tôi hiểu rồi. Cái Tính khả dụng này nó quan trọng, và tôi rất muốn áp dụng nó. Nhưng làm sao tôi có thể
thuyết phục sếp tôi - và sếp của sếp tôi - rằng chúng ta nên coi trọng trải nghiệm người dùng hơn và cho phép
tôi dành thời gian công sức để tập trung cho nhiệm vụ đó?”

Thế.. bạn có thể làm gì nếu bạn đang ở trong 1 môi trường mà mình không được đáp ứng mong muốn “làm
về Tính khả dụng”?

Bạn phải biết lĩnh vực của mình là gì

Đầu tiên, 1 chút lược sử về vị trí của Tính khả dụng trong thế giới đã thay đổi ra sao.
Vào cuối những năm 1990s, Usability (Tính khả dụng) and User Centered Design - UCD (Thiết kế lấy Người
dùng làm trung tâm) là những thuật ngữ mà người ta hay dùng để nói về những phương pháp thiết kế đặt lợi
ích và trải nghiệm người dùng lên trước. Và hồi đó chỉ có 2 “nghề" tập trung vào việc làm cho sản phẩm dễ
dùng hơn: Usability (đảm bảo mọi thứ được thiết kế sao cho người dùng có thể sử dụng chúng 1 cách dễ
dàng) và Information Architecture (Kiến trúc thông tin) (đảm bảo nội dung của 1 sản phẩm được sắp xếp tổ
chức sao cho người dùng có thể tìm thông tin mà họ muốn 1 cách dễ dàng)

Giờ đây, thuật ngữ mà bạn thường nghe nhất là User Experience Design (Thiết kế trải nghiệm cho người
dùng), hoặc chỉ đơn giản là User Experience (Thiết kế trải nghiệm) (UXD hoặc UX), và có lẽ có cả 1 mớ
chuyên môn liên quan, như Interaction Design (Thiết kế tương tác), Interface Design (Thiết kế giao diện),
Visual Design (Thiết kế thị giác), và Content Management (Quản lý nội dung) - và tất nhiên, Usability (Tính khả
dụng) và Information Architecture (Kiến trúc thông tin) - tất cả đều thuộc về khái niệm UX.

Một sự khác biệt giữa UCD và UX, chính là quy mô của chúng. UCD tập trung vào thiết kế sản phẩm 1 cách
chính xác và đảm bảo rằng nó dùng được. UX thì có vai trò cân nhắc tới nhu cầu của người dùng ở tất cả mọi
giai đoạn khi họ sử dụng sản phẩm, từ lúc họ nhìn thấy quảng cáo trên TV, tới khi họ bắt đầu mua sản phẩm
và theo dõi tiến độ giao hàng, hay cả khi họ trả sản phẩm về 1 chi nhánh địa phương nào đó.

Tin vui ở đây là hiện tại người ta đã bắt đầu có nhận thức tốt hơn về tầm quan trọng của việc tập trung vào
người dùng. Steve Jobs (và Jonathan Ive) đã tạo nên 1 ví dụ mang tính kinh doanh rất thuyết phục về UX, và
kết quả là Tính khả dụng giờ đây được nhận thức và coi trọng hơn xưa rất nhiều.

Tin không vui là, nếu trước đây Tính khả dụng từng là 1 tiêu chuẩn độc tôn cho các thiết kế thân thiện với
người dùng, giờ đây lại có thêm mấy thằng anh em râu ria cũng nhảy vào la liếm thị thường, mỗi thằng đều tin
rằng nó và các đặc tính của nó mới là thứ phù hợp nhất. Tin kém vui hơn nữa, chính là việc không có mấy
người hiểu được sự khác biệt giữa các đặc tính, hay sự đóng góp độc đáo mà chúng có thể mang lại.
Đây chính là lĩnh vực của bạn. Nên khi ai đó nói rằng “Tôi làm UX", hay “Usability á, lỗi thời rồi. giờ phải làm
UX", hãy cười 1 cách duyên dáng và hỏi họ 1 vài câu hỏi về cách họ tìm hiểu về người dùng, cách họ test xem
liệu người dùng có dùng được sản phẩm của họ không, và cách họ thay đổi để thích ứng. Nếu họ không làm
được những thứ đó, thì đúng là họ cần sự trợ giúp từ bạn. Nếu họ làm được, hãy học hỏi. Chúng ta gọi mình
là gì không quan trọng, quan trọng là thái độ làm việc và kĩ năng chuyên môn.

Lời khuyên thường gặp

Sau đây là 2 lời gợi ý tôi thường nghe khi ai đó muốn thuyết phục cấp quản lý hỗ trợ (và trài trợ) cho phần việc
liên quan tới Tính khả dụng:

- Chứng minh ROI (Tỷ suất hoàn vốn).

Ở cách tiếp cận này, bạn thu thập và phân tích data để chứng minh rằng 1 thay đổi trong Tính khả
dụng bạn đưa ra đã mang lại doanh thu và cắt giảm chi phí (“Đổi text label của nút này giúp tăng
0.25% sales”). Có 1 cuốn sách khá hay về cách tiếp cận này: : Cost-justifying
Usability: An Update for the Internet Age,​ edit bởi Randolph Bias và Deborah Mayhew.

- Giao tiếp đúng kênh, đúng ngôn ngữ.

Thay vì nói về lợi ích của người dùng, hãy tìm hiểu hiện tại vấn đề mang tính kinh doanh của công ty là
gì và trình bày phương án của bạn sao cho cấp quản lý hiểu được rằng nó là 1 phần giải pháp mà
công ty cần: Nói về những thứ như pain points, touch points, KPIs, CSI, hay bất cứ từ khoá nào đang
hot trong giới quản lý ở công ty của bạn.

Cả 2 đều là những ý tưởng ổn và đáng để thử nếu bạn có thể. Nhưng để làm được cả 1 bài nghiên cứu và
thuyết minh về Tỷ suất hoàn vốn giữa chi phí và doanh thu, bạn cần bỏ ra khá nhiều thời gian công sức, và
nếu không làm chặt chẽ cẩn thận thì sẽ luôn có ai đó khác nhảy vào nhận vơ, bảo rằng cái giá trị thu về kia là
đạt được nhờ 1 thứ khác, chứ không phải phương án của bạn. Và học cách giao tiếp đúng kiểu “kinh doanh"
cũng không dễ đâu nhé. Thế nên người ta mới phải cấp bằng MBA.

Nếu tôi là bạn...

… thì có khi tôi không trụ được quá 1 tuần. Lần nào được mời vào cơ quan của khách hàng tôi cũng mắt chữ
O mồm chữ A khi thấy môi trường làm việc khắc nghiệt như vậy nhưng vẫn có bao nhiêu người vẫn chịu
được. Đơn giản là tôi không thể chịu nổi những thứ tranh chấp nội bộ trong 1 tập thể, và ngồi họp nguyên cả
ngày.
Nhưng tôi đã dành kha khá thời gian “tham quan" các thể loại cơ quan đoàn thể công ty tập đoàn và thuyết
phục cấp quản lý coi trọng vấn đề về Tính khả dụng. Nên có lẽ tôi cũng biết chút ít về những chiến thuật nào
hiệu quả, và những người thử áp dụng những chiến thuật đó đều kể rằng kết quả là khá tích cực. Vậy nên đây
là những thứ tôi sẽ làm, nếu tôi là bạn:
- Mời sếp bạn, và sếp của sếp bạn, tham gia quan sát 1 buổi Usability Testing.
Phương pháp mà tôi cho là hiệu quả nhất chính là mời cấp quản lý tới và quan sát dù chỉ 1 cuộc
Usability Testing. Bảo các sếp rằng bạn chuẩn bị tiến hành 1 buổi Test và tinh thần của đội ngũ làm
Web sẽ lên cao nếu có sự có mặt của họ, dù chỉ 1 chút thời gian thôi cũng được.
Theo kinh nghiệm của tôi, quản lý cấp cao thường bị lôi cuốn bởi sự thú vị của cuộc Test và ở lại lâu
hơn họ tưởng, bởi vì đó là lần đầu tiên họ nhìn thấy ai đó thử sử dụng sản phẩm của công ty mình và
thường nó không phải 1 ấn tượng đẹp đẽ tích cực như họ tưởng.
Quan trọng là phải kéo được họ tới xem trực tiếp. Sự khác biệt giữa xem trực tiếp 1 cuộc Test và nghe
1 bài thuyết trình báo cáo về nó cũng hệt như sự khác biệt giữa xem 1 trận bóng trực tiếp trên sân vận
động và nghe 1 bản tin nhanh về trận bóng đó trên bản tin. Mọi thứ trực tiếp đều mang lại trải nghiệm
mang tính ghi nhớ, còn tin tức thì không.
Nếu bạn không thể mời họ đến, thì thôi đành phải lôi plan B ra: thêm luôn cả clip highlight những phân
đoạn mang lại thông tin quan trọng trong bài thuyết trình của mình. Nếu bạn thậm chí còn không đc
làm thuyết trình, thì đăng 1 clip nhỏ (ít hơn 3’) trên hệ thống mạng nội bộ của công ty và gửi email cho
các sếp, đi kèm với 1 dòng mô tả được viết nghiêm túc, cẩn thận, gây tò mò. Clip chỉ ngắn khoảng 3’
nên kể cả lãnh đạo cấp cao cũng có thể xem được dễ dàng.

- Với lần tiến hành test đầu tiên, hãy cố gắng tự sắp xếp tổ chức mọi thứ.
Khi bạn lần đầu tiến hành test, đừng xin phép, cứ tự làm, và làm ở quy mô vừa phải, đơn giản và
không cần quá trang trọng, nếu được thì hãy tìm tình nguyện viên tham gia test để đỡ tốn chi phí.
Cố gắng đảm bảo rằng sau cuộc Test thì cái gì đó phải được cải thiện nhờ kết quả từ cuộc Test. Chọn
1 tính năng dễ Test - cái nào bạn biết chắc rằng nó có ít nhất 1 lỗi nghiêm trọng về Tính khả dụng mà
có thể sửa 1 cách nhanh chóng mà không cần hỏi xin ý kiến nhiều người - sửa 1 cái nút với phần text
được viết chưa chính xác, chẳng hạn. Sau đó test nó, sửa nó, và công bố nó.
Nếu bạn có thể tìm ra 1 cách đơn giản để đo lường chính xác được sự cải thiện mà nó tạo ra thì càng
tốt. Ví dụ, bên CSKH báo cáo rằng có rất nhiều cuộc gọi phàn nàn từ khách hàng về 1 tính năng vô lý
nào đó, và bạn có thể chỉ ra sự thuyên giảm trong tần suất và số lượng cuộc gọi phàn nàn về tính năng
kia, sau khi đã được test và cải thiện.

- Hãy test sản phẩm của các bên cạnh tranh.

 Tôi có nhắc tới ở chương 9 rằng, việc test các trang Web của đối thủ cạnh tranh là 1 ý tưởng không tồi,
nhất là ở giai đoạn đầu của dự án. Và nó cũng là 1 cách tuyệt vời để nâng cao sự ủng hộ cho việc test.
Ai cũng thích tìm hiểu kĩ hơn và gossip về đối thủ, và vì đây là sản phẩm của chúng nó chứ không phải
của mình, nên việc test không nặng nề với bất cứ cá nhân nào. Đó sẽ là 1 buổi test vui vẻ, đông người
tham gia, và cũng có thể cho ra được các thông tin hữu ích.

- Đồng cảm với cấp quản lý.

1 vài năm trước ở hội nghị thường niên UXPA, tôi lượn 1 vòng và nghĩ “Mấy người ở đây ổn quá!".
Sau đó tôi chợt nhận ra: Tất nhiên họ phải ổn rồi. Sự đồng cảm gần như là 1 yêu cầu bắt buộc nếu bạn
đang muốn làm về UX / Usability. Và nếu bạn thực sự thích làm việc đó, bạn hẳn cũng phải có năng
lực đồng cảm ở 1 mức độ nhất định. Tôi khuyến khích mọi người áp dụng tâm thế đồng cảm này với
các sếp. không phải theo kiểu “làm sao mình tìm ra được những thứ thúc đẩy nó để lợi dụng bắt nó
làm theo ý mình nhỉ", mà là kiểu “đặt mình vào trong hoàn cảnh của họ và hiểu được thế giới quan của
họ". Có 1 sự đồng cảm chân thành với họ. Kết quả có thể làm bạn ngạc nhiên đấy.

- Hiểu được vị trí của mình trong bức tranh tổng thể.
Cá nhân mà nói, ở ví trí của bạn, 1 chút khiêm nhường sẽ rất có lợi. Thực tế phũ phàng là trong thế
giới kinh doanh bạn chỉ là 1 bánh răng rất nhỏ trong 1 mớ bánh răng và linh kiện thôi. (Tôi không có ý
xúc phạm, làm ơn đừng để bụng quan điểm này. Hãy tập trung làm tốt việc của mình và cố gắng cân
bằng cuộc sống công sở và cuộc sống cá nhân. Sống vui vẻ hạnh phúc nữa.)
Bạn hẳn là muốn sự sôi nổi đam mê của mình về vấn đề Usability được tiếp nhận và hưởng ứng rộng
rãi, nhưng nếu bạn cứ đi khắp nơi rêu rao rằng thứ bạn làm là đúng nhất, tiêu chuẩn nhất - về Usability
(hoặc về bất cứ cái gì khác) - thì cũng không hiệu quả đâu. Trách nghiệm cơ bản của bạn chỉ đơn giản
là chia sẻ những thứ bạn biết, chứ không phải đi dạy đời người khác phải làm thế nọ thế kia mới là
đúng.

Tôi cũng muốn giới thiệu với mọi người 2 cuốn sách hữu ích này.
Đầu tiên là It’s Our Research: Getting Stakeholder Buy-In for User Experience Research Projects (​ Đây là
Nghiên cứu của chúng ta: Thuyết phục Cổ đông tin vào những dự án nghiên cứu về UX) của Tomer Sharon.
Tomer là UX Researcher ở Google, và tôi chưa từng nghe hắn nói cái gì không đúng, không chính xác, không
đáng để làm cả.
Bất cứ cuốn sách nào với dòng tựa đề phụ kiểu “Trở thành giọng nói lý trí trong 1 tập thể" hay “Chấp nhận sự
thật rằng có thể mọi thứ không hiệu quả như ý muốn, và điều đó cũng không sao cả" thường đều rất đáng
đọc.

Cuốn thứ 2 là The User Experience Team of One: A Research and Design Survival Guide​ (​ Đội quân UX 1
người: Bản hướng dẫn nghiên cứu và thiết kế) của Leah Buley. Cuốn sách được viết dành riêng cho những
người kiểu “người duy nhất trong công ty sử dụng phương pháp User Centered Design (Thiết kế đặt người
dùng làm trọng tâm)” hoặc kiểu “thường xuyên là người duy nhất trong team có thể làm được về UX, có nhận
thức được UX quan trọng ra sao".
Chương 3 (Xây dựng hỗ trợ cho công việc của bạn) và chương 4 (Phát triển sự nghiệp và bản thân bạn) đầy
những lời khuyên và tài nguyên hữu ích.
Cưỡng lại trước những thế lực đen tối.

Làm Usability, về bản chất, là 1 công việc hướng về người dùng: Như ngài Lorax trong truyện của Dr. Seuss,
bạn phải nói thay cho rừng cây, trong trường hợp này thì chính là các người dùng. Usability về cơ bản là phục
vụ người dùng 1 cách tốt hơn bằng cách xây dựng sản phẩm tốt hơn.

Nhưng có 1 xu hướng - tôi nhận ra khoảng 5 năm trước - của 1 số người (đội *ho ​Marketing ​*ho)​ thường cố
gắng bắt những người làm về Usability giúp họ tìm cách thao túng người dùng thay vì tập trung giúp người
dùng giải quyết nhu cầu của họ. (Thậm chí có hẳn 1 cuốn sách gọi là Evil by Design: Interaction Design to
Lead Us into Temptation​ của Chris Nodder nói về việc hiểu biết về những điểm yếu về mặt tâm lý của con
người có thể dẫn dắt các quyết định liên quan tới thiết kế. Mỗi chương đề cập tới 1 trong Thất đại tội: Tham
lam, Ngạo mạn, Lười biếng, etc...)

Tôi không có vấn đề gì với việc những người cần sự trợ giúp của chúng ta lại có ảnh hưởng tới người dùng.
Nếu bạn muốn biết cách gây ảnh hưởng lên mọi người, cứ đọc cuốn sách kinh điển của Robert Cialdini về chủ
đề này, Influence: The Psychology of Persuasion. T ​ hực sự cuốn sách rất hay và hiệu quả, đầy những ý
tưởng và sự thật đã được kiểm chứng qua thời gian.
Hoặc đọc bất cứ cuốn sách nào của Susan Weinschenk về việc những nghiên cứu về thần kinh có thể dạy
cho chúng ta biết thêm về động lực thúc đẩy con người và cách các quyết định được hình thành.
Tôi cũng không có vấn đề gì với việc giúp đỡ bạn thuyết phục người khác làm 1 thứ gì đó, miễn là nó không
mang tính lừa đảo. Bản thân việc khuyến khích người dùng nói ra những thứ họ đang nghĩ trong đầu trong
quy trình làm Usability Testing cũng có thể cho ra những thông tin hữu ích về lý do tại sao việc thuyết phục
người ta làm 1 thứ gì đó lại thất bại hay thành công.

Nhưng tôi lại thấy bất an khi nghe người ta nói về việc lợi dụng các cuộc Usability Testing để giúp xác định
xem cái này có “hấp dẫn" hay không (desirable), vì đó không phải là thứ phù hợp để những cuộc Usability
Testing có thể đo lường chính xác. Bạn có thể cảm nhận được trong 1 cuộc Test rằng người dùng này có
đang thích 1 thứ nào đó không, nhưng cũng chỉ tới thế mà thôi: 1 cảm nhận. Liệu 1 thứ gì đó có hấp dẫn
không là 1 câu hỏi liên quan tới lĩnh vực nghiên cứu thị trường, và câu trả lời cho nó chỉ có thể được tìm ra
bằng cách sử dụng những công cụ và phương pháp nghiên cứu thị trường thôi.

Vấn đề ở đây là những người này thường không thực sự cần chúng ta (chuyên gia về Usability) trợ giúp trong
việc quyết định xem 1 thứ nào đó có hấp dẫn hay không, hay trong việc tìm ra cách làm cho sản phẩm hấp
dẫn hơn. Thay vào đó, họ nhờ tới các cuộc Usability Testing để cho họ biết cách để khiến người ta nghĩ rằng
sản phẩm này là hấp dẫn, hay nói đơn giản hơn, là thao túng người dùng.

Đôi khi việc thao túng này cũng tương đối vô hại, như việc cái checkbox “nhận tin newsletter qua email" luôn
được đặt mặc định là có check, được thiết kế sao cho mờ nhạt nhất có thể để bạn không để ý được.
Đôi khi nó nhích gần hơn tới ranh giới đen tối, như việc lừa người dùng cài đặt 1 cái Trình duyệt ngoài mong
muốn (*ho Yahoo *ho​) và thay đổi công cụ tìm kiếm mặc định cũng như setting của trang Homepage khi người
dùng không để ý. Chúng ta đều đã từng bị lừa như này ít nhất 1 lần.

Bạn click vào 1 cái link để tải 1 phần mềm miễn phí.

Link đó mở ra 1 màn hình với 3 nút “Start download" to đùng.

không để ý dòng hướng dẫn gần như vô hình ở chính giữa màn hình, khi không thấy có gì xảy ra bạn lại tiếp
tục clip vào 1 trong 3 nút Download kia để bắt đầu Tải xuống.

Một trang mới hiện ra với 1 nút “Start download" khác, nên bạn buộc phải click thôi.. và thành ra lại phải tải
thêm 1 phần mềm nào đó mình không cần.
Tiêu cực nhất là việc thao túng này bước sang hẳn ranh giới đen tối, trở thành các chiêu trò lừa đảo khách
hàng, như chiếm đoạt thông tin cá nhân, lừa tiền, etc..
Hãy hiểu rõ rằng nếu ai đó yêu cầu bạn làm những điều này, thì chắc chắn đó không phải việc bạn nên làm.

Người dùng phụ thuộc vào bạn cả đấy.

Một vài câu trả lời rõ ràng.

1 chút bonus cho các bạn trước khi cuốn sách kết thúc, vì đã đọc tới tận những dòng cuối này.

Phần lớn cuốn sách này là nói về việc đáp án cho những câu hỏi về Tính khả dụng phụ thuộc nhiều tới mức
nào vào hoàn cảnh, và câu trả lời phù hợp cho phần lớn những câu hỏi trên, đơn giản là “Còn tuỳ".

Nhưng tôi biết rằng chúng ta đều muốn có 1 vài câu trả lời rõ ràng, chắc chắn, vậy nên đây là tổng hợp nho
nhỏ của những điều bạn chắc chắn nên hoặc không nên làm.
 - Đừng sử dụng text nhỏ, có độ tương phản thấp.
Bạn có thể sử dụng text có độ tương phản thấp nhưng phải to rõ ràng, hoặc sử dụng text nhỏ nhưng
độ tương phản cao. Nhưng đừng bao giờ sử dụng text nhỏ, có độ tương phản thấp. (và cũng tránh sử
dụng cái cặp còn lại luôn nhé). Trừ khi bạn đang thiết kế trang Web portfolio riêng của mình, và bạn
thật sự không quan tâm liệu người ta có đọc text hay không.

- Đừng nhét label vào trong các trường nhập thông tin (form fields)
Đúng là điều này có thể rất cám dỗ, nhất là khi thiết kế cho các màn hình di động bé tí xíu. Nhưng
đừng làm trừ khi trường hợp của bạn có tất cả những thứ liệt kê sau đây: Cái form đó cưc kì đơn giản,
cái label đó sẽ biến mất khi bạn chuẩn bị gõ và sẽ hiện lại khi bạn để trống field đó, cái label đó sẽ
không bao giờ bị nhầm lẫn với thông tin sẽ được nhập, và sẽ không có khả năng bạn sẽ nhập nhầm
luôn cả label CÙNG VỚI thông tin bạn vừa nhập (Job TiA ​ ssistant Manager​tle​). Và bạn vẫn phải đảm
bảo là các trường nhập thông tin này hoàn toàn dễ tiếp cận.
Nếu bạn không đồng ý, trước khi gửi 1 chiếc email phản biện làm ơn hãy tìm đọc “Don’t Put Labels
Inside Text Boxes (Unless You’re Luke W)” hết đã.

- Giữ lại sự khác biệt giữa các link đã được click và chưa được click
Theo mặc định, các trình duyệt Web hiển thị các đường link đã được click ở 1 màu khác so với các
đường link chưa được click, để bạn có thể biết mình đang ở đâu, đã click vào cái gì. Điều này hoá ra
lại là thông tin cực kỳ hữu ích, đặc biệt là khi nó được truy vết từ URL, chứ không phải từ cách đặt tên
cho các đường link. Nên nếu bạn đã click vào Book a trip​, sau này bạn lại gặp 1 cái link như Book a
flight​ thì chắc chắn bạn sẽ hiểu rằng 2 link này dẫn tới cùng 1 trang.
Bạn có thể chọn bất cứ màu nào, miễn là 2 màu đó khác biệt rõ ràng.

- Đừng đặt tiêu đề lơ lửng giữa 2 đoạn Paragraph

Tiêu đề nên gần với cái text nội dung của nó hơn là với phần text nội dung của tiêu đề trước. (Uh đúng
là tôi đã nhắc tới điều này ở Chương 3 rồi, nhưng nó khá quan trọng và dễ bị mắc phải nên tôi phải
nhắc thêm 1 lần nữa cho chắc.)

Thế thôi các bạn à.

Như Bob và Ray từng nói, “Hang by your thumbs, and write if you get work.”
(Câu chào tạm biệt điển hình của cặp dẫn chương trình trên Radio nổi tiếng Bob Elliott và Ray Goulding trong
những năm 1930s. Mang ý nghĩa khích lệ tinh thần kiên trì, tự học hỏi, tự rèn luyện phát triển bản thân)

Tôi mong rằng thi thoảng bạn sẽ xem thử trang Web của tôi stevekrug.com​, và bạn hoàn toàn có thể gửi mail
cho tôi tới địa chỉ stevekrug@gmail.com​. Tôi có thể đảm bảo rằng tôi sẽ đọc hết và trân quý hết từng chiếc
mail, kể cả khi tôi không có đủ thời gian để trả lời.

Nhưng trên hết, hãy dũng cảm và lạc quan. Như tôi đã nói ở đầu cuốn sách, xây dựng 1 trang Web / app tốt là
1 thử thách khổng lồ, và bất cứ ai chỉ cần làm đúng được 1 nửa thôi là tôi phục lắm rồi.

Và làm ơn đừng coi những thứ tôi viết ra đều mang tính phản đối việc lách luật, hay phá luật. Tôi biết có
những trang Web mà bạn muốn giao diện khó hiểu, gây thắc mắc và tò mò với người dùng 1 cách có chủ
đích. Chỉ cần đảm bảo là bạn hiểu rõ mình đang phá/lách những luật nào và hiểu rõ lý do tại sao mình lại làm
như vậy, 1 cách logic.

À nhân tiện đây, đây là phần còn lại của mẩu truyện Calvin và Hobbes.
LỜI ĐỀ TẶNG

… và tất cả những gì tôi nhận được chỉ là chiếc áo T-shirt cùi bắp này.

...​Và cảm ơn những cán bộ thuộc tàu U.S.S Forrestal, bộ phim này sẽ không bao giờ
thành hình nếu không có sự hợp tác của họ.

_ Lời đề tặng phổ thông trong 1 bộ phim bất kỳ _

[Chèn đại 1 cái meme “It takes a village" tại đây]

(“It takes a village” là 1 meme thường được dùng để nói về công sức tập thể khi làm 1 thứ gì đó)

Nhưng đúng là thế. Tôi không chỉ không thể viết được cuốn sách này 1 mình - tôi còn thậm chí không muốn
viết nó ra luôn ấy. Tuy nhiên, 1 lần nữa, tôi vẫn có thể điểm tên những vị khách quen đã từng giúp tôi trong
thời gian bắt đầu cuốn sách này và cuốn Rocket Surgery​.

Tôi thực sự đã nhờ cậy vào lòng tốt và thiện chí của họ để cải thiện thói quen viết lách của mình.

Như thường lệ, cách tôi quản lý thời gian đã gây khó khăn phiền phức cho tất cả các bên liên quan (Bạn đã
bao giờ nghe tới câu nói “Nếu không có phút 90 thì tôi đã chẳng làm được gì ra hồn rồi" chưa?). Thật sự đấy,
cứ như thể ai đó đã chủ động giúp tôi lên dây cót cho chiếc đồng hồ báo thức của mình, mỗi khi tôi không để
ý.
Chân thành cảm ơn - và thực ra là cả xin lỗi nữa - tới

Elisabeth Bayle​, đối tác tâm giao của tôi, con chuột bạch đầu tiên cho những ý tưởng và dự án của tôi, người
bạn lâu năm của tôi, và - kể cả khi cô ấy không muốn thừa nhận điều này - người phụ trách biên tập chính cho
cuốn sách này. Nếu bạn có ý định viết 1 cuốn sách, lời khuyên tốt nhất của tôi cho bạn, chính là tìm ra ai đó
thông minh và hài hước và cũng hiểu biết về chủ đề đó như chính bạn vậy, sau đó thuyết phục họ bỏ thời gian
công sức quý báu của họ ra để lắng nghe, góp ý và đưa ra lời khuyên cho bạn, đồng thời biên tập chỉnh sửa
cái mớ chữ bạn vừa viết ra nữa.
Nói là không có cô ấy thì cuốn sách này sẽ không bao giờ ra đời thì cũng hơi quá (mặc dù đúng là thế). Chỉ là
từ đầu tôi chắc chắn không bao giờ cân nhắc viết nó nếu biết là cô ấy sẽ không tham gia. Tôi cũng muốn gửi
lời cảm ơn tới Elliott​ vì đã luôn luôn đồng hành với Elisabeth, giúp cô ấy có được sự cân bằng trong đời sống
tinh thần sau mỗi ngày dài làm việc mệt mỏi với tôi.

Barbara Flanagan​, biên tập viên và 1 người bạn lâu năm khác của tôi. Có 1 cái giai thoại hài hước như này
“Barbara chưa bao giờ sai 1 lỗi ngữ pháp nào trong cả cuộc đời cô ấy. Ừa thì có 1 lần cô ấy tưởng là mình sai,
nhưng hoá ra vẫn không phải." Trước khi bạn cào phím viết 1 cái mail chỉ ra lỗi ngữ pháp trong cuốn sách của
tôi, cứ biết là Barbara đã nhắc tôi về cái lỗi đó từ lâu lắm rồi, và vẫn nói “Nhưng đây là giọng văn của ông.
Cuốn sách của ông. Ông đi mà quyết.". Đó mới là tinh thần hào phóng rộng mở mà tôi trân quý.

Nancy Davis​, tổng biên tập tại Peachpit, người xoay sở để vừa đảm đương vị trí công việc quan trọng thường
ngày, vừa giúp tôi với tư cách cố vấn tối cao (consigliere​) và là nhà vô địch trong lòng tôi. Cô ấy là 1 trong số ít
những người mà lời khen của họ có sức nặng và giá trị gấp 10 lần lời khen từ người thường. Tôi sẽ rất nhớ
những lúc buôn chuyện về mấy ông con trai cuồng chim chóc của cô ấy.

Nancy Ruenzel, Lisa Brazieal, Romney Lange, Mimi Heft, Aren Straiger, Glenn Bisignani​, và tất cả
những nhân viên thông minh, dễ mến, tài năng và chăm chỉ tại Peachpit đã hỗ trợ tôi rất nhiều (trong khi
thường xuyên phải giữ mồm giữ miệng để không sỉ vả làm tôi buồn, tôi cá luôn đấy).

Caroline Jarrett ​và​ Whitney Quesenbery​, những chuyên gia đánh giá của riêng tôi, những người đã tình
nguyện dành ra 1 chút thời gian quý báu của họ để sản phẩm của tôi (và tôi) bớt ngáo hơn. Ở 1 thời điểm
khác, tôi sẽ miêu tả họ như những “người bạn đồng hành". Chúng tôi có chung quan điểm trong rất nhiều thứ,
và tôi rất vui vì được ở bên những người như vầy. Tuy nhiên, để bảo vệ sự minh bạch và trong sáng trong
quan điểm, tôi cảm thấy buộc phải viết rõ ra rằng họ không hẳn là đồng ý với tất cả mọi thứ viết trong cuốn
sách.

Randall Munroe​, người đã vô cùng hào phóng về việc tái xuất bản sản phẩm của anh ấy, và người đã cho tôi
và con trai tôi cười ra nước mắt về những năm tháng tại xdcd.com

Những người đồng nghiệp thông minh và vui tính như Ginny Redish, Randolph Bias, Carol Barnum,
Jennifer McGinn, Nicole Burden, Heather O’Neill, Bruno Figuereido, ​và​ Luca Salvino.

Những người đã đóng góp 1 phần kiến thức chuyên ngành quý giá của họ, như Hal Shubin, Joshua Porter,
Wayne Pau, Jacqueline Ritacco, ​và những người bạn tại Học viện Bayard ở Copenhagen.
Lou Rosenfeld​, người đã ủng hộ tôi về mặt tinh thần và đạo đức, đưa ra những lời tư vấn tuyệt vời, và đơn
giản Lou chỉ cần là Lou đối với tôi thôi.

Karen Whitehouse ​và​ Roger Black​, về cơ bản là cha và mẹ đỡ đầu của cuốn sách này, những người đầu
tiên kéo tôi vào hành trình này bằng việc cho tôi cơ hội viết ấn bản đầu tiên 14 năm trước.

Cộng đồng chuyên gia về Usability, hoá ra lại là những người cực kì tử tế và tốt bụng. Thử tham gia 1 cái
hội nghị thường niên UXPA mà xem.

Những người Baristas​ thân thiện tại Putterham Circle Starbucks, ​thường là những người tôi nhìn mặt còn
nhiều hơn cả nhìn vợ hàng ngày.

Con trai tôi, Harry, giờ chuẩn bị lấy bằng RPI, người mà tôi trân trọng sự hiện diện của nó trong cuộc sống rất
nhiều, nhiều hơn nó tưởng. Tôi thường xuyên làm nó mất hết kiên nhẫn khi cứ bắt nó giải thích đi giải thích lại
về sự khác biệt giữa Meme (ảnh chế) và Trope (câu thoại lóng).

Nếu ai đó đang tuyển vị trí liên quan tới chuyên ngành Khoa học nhận thức với 1 ngành phụ là Thiết kế game,
tôi rất sẵn lòng ứng cử nó.

Và cuối cùng, Melanie​, người mà chỉ có đúng khiếm khuyết: Cái nét tính cách di truyền là không mê tín, không
kiêng nể đất trời gì sất, thường khiến cô ấy nói mấy thứ kiểu “ Ờm, cả mùa đông này em chưa ốm trận nào.”
Ngoại trừ điều đó, thì tôi, như tôi đã nói rất nhiều lần, là 1 trong những ông chồng may mắn nhất.
Nếu bạn muốn 1 cuộc đời tươi đẹp, thì cưới vợ cho cẩn thận vào.

Dịch & biên tập bởi:

Kiều Bảo Duy

UI/UX Designer
Sun*, Inc.

Tháng 8/2020.