Mobile First

September 23, 2013November 4, 2013 ~ binhtruong ~ 2 Comments

Review sách “Mobile First” của Luke Wroblewski

(Ảnh: mobile first, nguồn Internet)

Luke Wroblewski là một người được biết đến bởi khả năng viết rất “khủng” của ông. Bên cạnh công việc chính là product design officer (ở bển gọi là CPO = Chief Product Officer), cũng như từng kinh qua nhiều vị trí design lead tại Yahoo, eBay… Luke còn là blogger với hàng ngàn blog đã được viết, hàng trăm slide và buổi trình bày về UI, Product design.

Khi tôi đọc cuốn “How to create the next Facebook” của Tom Taulli cách đây 3 tháng, Tom cũng đưa ra gợi ý các tech start-up nên bắt đầu với sản phẩm dành cho mobile trước khi xây dựng web app. Và cuốn “Mobile first” dường như khẳng định điều này trong mindset của tôi.

Có một điều dễ nhận thấy, ngày nay các thiết bị smart phone chiếm phần lớn thời gian rảnh rỗi của người dùng. Từ thanh thiếu niên cho tới những người đi làm, thậm chí cả trẻ em và người ở độ tuổi đang nghỉ hưu. Nếu có thời gian rảnh, hoặc thậm chí không rảnh cho lắm, phần lớn người dùng Internet vẫn sẽ “lăm lăm” chiếc điện thoại trên tay và “thao tác song song” cùng thời điểm họ đang…làm việc khác.

(Ảnh bìa sách mobile first, nguồn Amazon)

“Mobile first” được viết dưới dạng “starter guide”, nghĩa là dành cho với những người bắt đầu chuyển sang thiết kế ứng dụng dành cho mobile. Chính vì vậy, cùng với phong cách viết sách ngắn ngọn của A Book Apart, cuốn sách chỉ bao gồm 7 chương và gói gọn trong khoảng 150 trang. Bắt đầu với việc giải thích “tại sao phải mobile first” (kiểu như đặt vấn đề), Luke hướng người đọc vào ngay trọng tâm làm thế nào để bắt đầu, hoặc để nghĩ về thiết kế ứng dụng cho mobile. Tất nhiên, ai cũng hiểu thiết kế mobile app đòi hỏi nhiều thứ phải quan tâm, nhưng với góc độ của những người làm web design bắt đầu chuyển sang mobile design thì tác giả khuyến cáo vài điểm ngắn gọn như:

Constraints: Những khác biệt, giới hạn cũng như lưu ý khi thiết kế mobile app.
Capabilities: Giống như các sách về mobile design, tác giả nhắc lại những chức năng, khả năng của smartphone mà designer nên tận dụng.
Organization: Cách thức tổ chức thông tin, menu sao cho phù hợp với mobile context.
Actions & Input: Cách thiết kế màn hình nhập thông tin của người dùng, các thao tác thường gặp đối với ứng dụng mobile.
Layout: Chủ yếu nói về độ phân giải màn hình, các điểm khác nhau của các loại thiết bị… (tôi không khoái chương này, bởi nó hơi thừa).

Sách cũng cung cấp khá nhiều nguồn thu thập thông tin report về hiện trạng sử dụng mobile app cũng như truy cập Internet bằng thiết bị handheld. Tuy nhiên, với cá nhân tôi, thông tin giá trị nhất của cuốn sách chính là Constraints, được đề cập ở chương 2. Giá trị nhất bởi idea của nó bắt nguồn từ việc khuyến khích những người làm sản phẩm (dù web hay mobile) hãy tự đặt mình vào hoàn cảnh phải thiết kế cho mobile trước. Bởi bằng cách này, bạn sẽ phải tối ưu (đến mức tối đa) các chức năng quan trọng nhất, cách thức tổ chức thông tin, menu hợp lý nhất cũng như nội dung phù hợp với ngữ cảnh của người sử dụng. Thiết kế sau cùng sẽ tránh được những thứ “dư thừa” không cần thiết và cách làm như vậy sẽ tiết kiệm cả chi phí, tìm hiểu người dùng cũng như UX hiệu quả hơn.

Ghi chú:

Có thể xem bản review của mình tại Amazon ở URL này.

One eyeball, One thumb

September 19, 2013September 19, 2013 ~ binhtruong ~ Leave a comment

Một lưu ý khi thiết kế giao diện mobile app

(Ảnh 1: one eyeball, one thumb. Nguồn Internet)

Khái niệm “One eyeball, one thumb” là một phát biểu của Luke Wroblewski, người đứng trong hàng ngũ chuyên gia đầu ngành về UI, UX cho web và mobile application design. Phát biểu này rút ra từ các báo cáo (1) nghiên cứu hành vi sử dụng smart phone của người dùng. Các báo cáo này cho thấy, phần lớn thời gian người dùng sử dụng smart phone là ở nhà, và sử dụng song song với thời gian làm các công việc khác như xem TV, ăn cơm, ngồi cafe tán chuyện với người thân, đọc sách báo, hay là một tay bế em bé – 1 tay nghịch iPhone… Trong quá trình sử dụng đó, phần lớn người dùng chỉ sử dụng 1 tay để thao tác với chiếc điện thoại, và phần lớn là chỉ dùng ngón cái để tương tác với các thành phần giao diện (UI) của ứng dụng smart phone, rồi khi cần thì liếc mắt xem thông tin trên màn hình. Thử ngẫm lại xem bạn có hay làm vậy không? Nếu có, thì đó chính là “one eyeball, one thumb”.

Nếu như phần lớn người dùng chỉ sử dụng ngón tay cái (thumb) thì việc thiết kế giao diện cho ứng dụng smart phone phải tính tới khả năng tiện dụng, usability, và UX trong trường hợp này.

Khi người dùng chủ yếu tương tác với điện thoại smart phone bằng ngón tay cái, nghĩa là khả năng thao tác sẽ có giới hạn của nó. Trên giao diện ứng dụng iPhone, HTC sẽ có những vùng mà nếu như sử dụng 1 tay thì người dùng sẽ gặp khó khăn. Ở đây, người ta chia ra làm 03 vùng như sau:

REACH: Vùng giao diện người dùng phải vất vả nhất nếu muốn dùng ngón tay cái chạm tới.
OK: Vùng giao diện nằm trong khả năng “touch” của ngón tay cái.
EASY: Vùng giao diện thuận tiện nhất dành cho đối tượng “one eyeball, one thumb”

Như vậy, nếu nhìn vào 2 bức ảnh trong blog này (ảnh 1 và ảnh 2) thì dù điện thoại iPhone, hay HTC, Android… người dùng đều có vùng giới hạn khi sử dụng ngón cái để thao tác. Vậy xử lý việc này thế nào? Dễ hiểu là các navigation, hay chức năng quan trọng nên đặt trong vùng EASY, ngược lại, những thứ như cover photo, wallpaper hay thông tin ít thay đổi, có thể đặt trong vùng REACH, phần còn lại, những thông tin, listing item, feed nên đặt ở vùng OK.

(Ảnh 2: các vùng giới hạn của iPhone khi thao tác bằng ngón tay cái)

Việc đưa ra giao diện phù hợp với các vùng giới hạn (tôi tạm dịch từ “limitation area”) là điều cần thiết, và bởi vì những lúc sử dụng smart phone bằng cả 2 tay là ít hơn, hoặc nếu có thì giao diện có thế nào cũng dễ tương tác hơn. Có một số cải tiến trong các ứng dụng iPhone phổ biến mà ta có thể nhận thấy họ đã điều chỉnh để phù hợp với tình huống “rule of thumb” như là:

Tập trung các navigation menu tương tác ở phía dưới màn hình smart phone. Ví dụ facebook phiên bản mới, Path, foursquare…
Thiết kế các icon, button to hơn, chuẩn hơn để cho ngón tay cái có thể chạm vào tốt hơn. Điều này cũng có nghĩa là hạn chế sử dụng “text navigation” và áp dụng các icon, button có kích thước lớn hơn. Apple sử dụng kích thước 44 x 44 points, Windows phone đưa ra khoảng cách tiêu chuẩn của họ từ 7mm (min) cho tới 9mm (max), MIT thì cung cấp kích thước 10-14mm cho tablet và 8-10mm cho smart phone. (các kích thước này thường ngụ ý là chiều cao x chiều rộng, nếu button/menu không phải hình vuông thì đó là chiều cao).
Thay đổi khoảng các giữa các icon, button sao cho giảm thiểu được việc thao tác “nhầm” menu mà người dùng mong muốn. (định bấm vào nút này nhưng vô tình chạm phải nút kia). Khoảng cách đề xuất tương đối chuẩn hiện nay là 2mm.

(Ảnh 3: màn hình giao diện ứng dụng Path, Foursquare với menu tương tác nằm gọn trong vùng EASY)

Không chỉ ảnh hưởng tới navigation, mà “one thumb rule” còn khiến người thiết kế ứng dụng smart phone phải lưu ý tới việc tổ chức thông tin sao cho phù hợp, cũng như phải sắp đặt thứ tự ưu tiên của các chức năng được xem là “core feature” nhằm thu hút người dùng ở mức tối đa. (bởi họ chỉ “liếc” bằng “one eyeball” mà thôi).

Với việc áp dụng UX concept “one eyeball, one thumb” vào thiết kế, các ứng dụng mobile đã có nhiều thay đổi đáng kể và nếu để ý một chút thì foursquare và Path là 02 ứng dụng làm tốt nhất việc này. Bên cạnh đó, màn hình iPhone 4 (theo tôi là thiết kế tốt nhất của iPhone từ trước tới nay) với kích thước 3.5in (320 x 480) sẽ dễ dàng thao tác hơn so với iPhone 5 (kích thước 4.08in, 1,136 x 640) khi sử dụng một tay theo thói quen thường lệ.

Tham khảo:

(1) Báo cáo thống kê thời điểm sử dụng smart phone trong ngày của người dùng [URL].

(2) Rule of thumb, tạp chí Forbes.

(3) How do users really hold mobile devices, UXMatter.

What to Test in A/B

September 18, 2013September 19, 2013 ~ binhtruong ~ Leave a comment

Test cái gì trong A/B testing, và thực hiện A/B test cho website như thế nào?

(Ảnh: kết quả thử nghiệm A/B testing, nguồn Internet)

A/B testing hiện tại có lẽ đang là một khái niệm được áp dụng rộng rãi trong các chiến dịch marketing, đi kèm với micro site hoặc các landing page quảng cáo. Khái niệm cơ bản của A/B testing tôi đã trình bày trong blog trước đây, tuy nhiên thực hiện như thế nào thì cần phải có kế hoạch cũng như chiến thuật cụ thể hơn.

This process begins with the most important question of all: What is the purpose of your site?

Có thể nói, ở Việt Nam thì không nhiều công ty có đủ chi phí, sự kiên nhẫn và mindset làm A/B testing. Nghe thì hay, nói thì hay nhưng không phải ai cũng muốn thực hiện nghiêm túc, đa phần chỉ dừng lại ở mức theo dõi Google Analytic xem số liệu rồi điều chỉnh chi phí marketing mà thôi. Nhưng nếu muốn làm nghiêm túc thì sao? OK, đầu tiên bạn (hoặc team của bạn, bao gồm cả sếp) phải trả lời câu hỏi mục đích của website (hoặc landing page) là gì? Không có đích đến, sẽ không hoạch định được đường đi đúng đắn.

Khi đã có mục tiêu cụ thể, A/B testing được tiến hành theo 05 bước phổ biến như sau:

Define success: Thiết lập các số liệu dưới dạng tiêu chuẩn mà các nhóm triển khai sản phẩm (website cùng hướng tới). Thường sẽ có 02 nhóm A và B. Bạn sẽ không thể xác định xem giải pháp của nhóm nào giành phần thắng nếu như không xác định các số liệu định lượng một cách rõ ràng. Số liệu có thể là thời gian trung bình 01 user xem một trang web, số lượng pageviews, số lượng đơn đặt hàng trung bình, số lượng visitor, doanh thu / trên 1 visitor.v.v… (Cũng có thể lựa chọn các thông số như churn rate, exit rate, conversion rate…)
Identify bottlenecks: Phối hợp cùng với nhóm của bạn, cùng với số liệu analytic của website, phân tích xem website đang bị “tắc” ở đâu? nghẽn ở khâu nào? người dùng dừng lại và bỏ đi từ trang nào nhiều nhất trên website? trang checkout có vấn đề gì không? hoặc trang xem chi tiết sản phẩm có cần cải tiến ở khâu nào để người dùng đặt hàng dễ dàng hơn? A/B testing không nhất thiết phải test tất cả các trang trong 1 website, chỉ cần tìm ra “bottleneck” và cải tiến triệt để sẽ mang lại hiệu quả rõ rệt.
Construct a hypothesis: Hypothesis nghĩa là giả thuyết. Sau khi xác định được “bottleneck” của website ở đâu, các nhóm xây dựng website cần tiến hành hàng loạt các thủ tục, các bài test để đưa ra giả thuyết về người dùng. Ví dụ như phỏng vấn một lượng người dùng (user interview), theo dõi, quan sát hành vi của một nhóm người dùng (focus group) hoặc lấy thông tin phản hồi (thông qua feedback form)… để rồi từ đó đưa ra các giả thuyết, cũng như các thay đổi cần thiết, các cách thức thực hiện thay đổi (về giao diện, về qui trình mua hàng online chẳng hạn).
Prioritize: Khi có một mớ các giả thuyết, bước tiếp theo là đưa ra mức độ ưu tiên. Cải tiến cái nào trước, test cái nào trước, thử nghiệm giải pháp nào trước. Tất cả tùy thuộc vào mục tiêu mà chúng ta đã đặt ra ban đầu. Chẳng hạn như website e-commerce thì những màn hình check-out, payment cần ưu tiên hơn là test các API tương tác với các đại lý.
Test: Sau cùng, khi đã có các giải pháp thử nghiệm theo thứ tự ưu tiên (thường 1 trang màn hình trên website sẽ có 2 giải pháp A và B để 2 nhóm tiến hành test), công việc phải làm chính là test. Việc test được tiến hành với những nhóm người dùng ngẫu nhiên (có thể thuê freelancer, tình nguyện viên, sinh viên vào dự án test này).

Đầu ra của việc A/B test chính là các báo cáo, với những thông số analytic mới và các nhóm (nhóm A, nhóm B) lại tiến hành cập nhật, cải tiến giải pháp của mình. Chu trình A/B test bao gồm 5 bước nêu trên có thể được thực hiện lặp lại nhiều lần, cho tới khi các giải pháp thay đổi đáp ứng được mục tiêu đặt ra (thường là về số liệu) ban đầu.

Sau khi kết thúc dự án A/B testing (gọi là dự án nội bộ), người quản lý dự án chọn ra phương án (A hoặc B) đáp ứng yêu cầu tốt nhất để từ đó triển khai cho sản phẩm go live. Lưu ý nhỏ là A/B testing không nhất thiết phải tiến hành khi dự án website mới bắt đầu, A/B testing phục vụ cho cải tiến, kiểm nghiệm những phương áp thay đổi, phát triển sản phẩm trong suốt vòng đời của sản phẩm đó.

Thiết kế sản phẩm bắt đầu từ mobile?

September 17, 2013September 20, 2013 ~ binhtruong ~ Leave a comment

Định hướng lấy mobile làm trọng tâm khi xây dựng sản phẩm

(Ảnh: mobile life, nguồn Internet)

Cách làm sản phẩm phần mềm truyền thống từ trước tới nay vẫn thường là bắt đầu với desktop, laptop… rồi sau đó mới tới mobile, tablet nếu “có nhu cầu” nở rộng thị phần hoặc khách hàng “yêu cầu”. Nhất là các dự án ở Việt Nam, cứ phải có 1 URD (1) hoặc SRS (2) với một bó tính năng hoành tráng. Thế giới giờ thay đổi rồi, làm sản phẩm thì không làm như vậy được nữa. Mọi thứ nên bắt đầu từ mobile.

Hiện trạng và động lực

Hiện nay, lượng người dùng sử dụng mobile truy cập các trang web, sử dụng mobile app để chia sẻ dữ liệu lên các trang mạng xã hội (Facebook, Twitter…) tăng vọt, các báo cáo thông kê (3) cho thấy xu hướng sử dụng điện thoại để online càng ngày càng phổ biến hơn dùng laptop, hoặc desktop. (Khổ lắm, biết rồi…nói mãi…)

Thời điểm năm 2006, điện thoại thông minh nhất thì cũng chỉ có máy ảnh 2mega pixel, tốc độ vào web chậm, mạng 3G tại Việt Nam vẫn còn chậm, và các điện thoại smart phone phổ biến vẫn là motorola, Black Berry với bàn phím vật lý không tiện dụng… (thực ra là tiện dụng với SMS chứ vào web thì không ổn lắm).

Ngày 29 tháng 6 năm 2007, chắc nhiều người vẫn còn nhớ, Steve Job cho ra mắt iPhone, với touch screen và bàn phím ảo, đó thực sự là bước ngoặt, với một thiết bị mới, tiện dụng hơn và UX hơn hẳn các điện thoại cùng thời bấy giờ.

Theo thời gian, 6-7 năm kể từ ngày ấy, giá thành của smart phone ngày càng rẻ đi cũng như giá viễn thông (3G, wifi) không tăng lên và có xu hướng ngày càng rẻ, thậm chí ở Việt Nam còn rẻ hơn nữa… bên cạnh đó thì tốc độ truy cập ngày một nhanh hơn, băng thông rộng hơn… Nói không ngoa thì Việt Nam là nước dùng free wifi, internet nhiều và sướng nhất Đông Nam Á tính đến bây giờ.

Theo báo cáo của Cisco, số lượng người dùng toàn cầu sở hữu smartphone khoảng 13% trên tổng số người sử dụng các thiết bị di động, tuy nhiên nhóm người dùng này tạo ra lượng trao đổi dữ liệu chiếm 78% trên tổng số lưu lượng thống kê được (handset traffic).

(Ảnh: mobile era, nguồn: Internet & Mobile Internet 2013 của KPCB)

Hiện trạng đã rõ rồi, động lực cũng có đủ rồi… vậy nên bắt đầu với native app (iPhone app, Android app) hay với mobile web?

Native mobile app và mobile web

Câu trả lời là… Nếu có thể, hãy làm cả 2 phiên bản. Native app thì rõ ràng là sẽ thao thác tốt hơn với các lợi thế của smartphone (SMS, Camera, định vị GPS, các chương trình chạy ngầm v.v…) và cũng có nghĩa là UX tốt hơn. Tuy nhiên thì nếu một website có phiên bản mobile thì sẽ tăng khả năng truy cập (từ smart phone) cho người dùng. Dễ hiểu thôi, không phải lúc nào cũng hùng hục cài iPhone app của một website “xa lạ” hoặc “mới quen” được, cứ chơi mobile web cho lành.

Bên cạnh đó, mobile web thì phù hợp cho chia sẻ content, xử lý điều hướng những URL tốt hơn và cross-platform vì không cần phải làm riêng cho mỗi 1 dòng điện thoại một phiên bản. Dễ dàng cập nhật hơn (từ máy chủ web) khi có phiên bản mới chứ không phải cập nhật từng phiên bản như native app, A/B testing cũng sẽ dễ thực hiện hơn.

Tóm lại, không nhất thiết phải cung cấp tất cả các phiên bản cùng lúc, những liên tục mở rộng và cung cấp nhiều cách thức tiếp cận cho người dùng, cũng là một cách mang lại cho họ (người dùng) nhiều trải nghiệm hơn.

Nhưng tại sao lại mobile first? và “UX” có vai trò gì ở đây?

Khi chọn thiết kế cho mobile trước tiên, cũng có nghĩa là nhóm phát triển phải thiết kế cho một màn hình nhỏ, nhiều hạn chế. Bạn phải chắc chắn rằng, những tính năng hiển thị trên màn hình mobile sẽ là những tính năng quan trọng nhất, cần thiết nhất. Và cần hiểu một thực tế là: không có chỗ cho tất cả các tính năng, bạn và nhóm của bạn phải lựa chọn, phải tìm hiểu cái người dùng quan tâm nhất để đưa vào key features.

You have to make sure that what stays on the screen is the most important set of features for your customers and your business – Luke W.

Khi nhóm phá triển của Flickr thiết kế phiên bản dành cho mobile, họ đã phải giảm bớt số lượng tính năng (functions/ features) từ hơn 60 chức năng xuống còn 6 tính năng cơ bản nhất, nhưng quan trọng nhất. Flickr có phiên bản web trước khi ra mắt phiên bản mobile, cũng bởi nguyên nhân lịch sử. Bạn có cơ hội hoàn toàn khác. Ngay hôm nay, khi lựa chọn thiết kế cho mobile trước, thì điều đó cũng có nghĩa là bạn phải lựa những gì đáng được ưu tiên nhất, để rồi sau đó, phiên bản web (ra đời sau) sẽ tránh được những dư thừa không cần thiết. Như vậy, bạn sẽ chắc chắn được một điều rằng: ta chỉ đưa cho người dùng những gì họ thực sự cần, và cơ hội hiểu người dùng cũng sẽ nhiều hơn, tốt hơn.

Cuối cùng, “Simply the best” và “less is more” chính là 2 slogan mà tôi muốn nhắc lại để kết thúc blog này. Mobile là hiện tại, và cũng sẽ là tương lai.

Ghi chú:

(1) URD viết tắt của User Requirement Definition, nghĩa là tài liệu mô tả yêu cầu của người dùng đối với một phần mềm (hoặc hệ thống phần mềm).

(2) SRS viết tắt của Software Requirement Specification, là tài liệu đặc tả phần mềm (mang tính kỹ thuật hơn là tính chức năng ở phía người dùng).

(3) Xem các báo cáo thông kê tại đây [Mobile Data Wave 13 june 2012], [The Mobile Internet Report 2009], và report mình thích nhất (tìm trên slideshare.com sẽ có rất nhiều) [Internet & Mobile Internet 2013 KPCB]

Elevator pitch

September 12, 2013September 20, 2013 ~ binhtruong ~ Leave a comment

Cách trình bày khái niệm UX hoàn chỉnh trong khoảng thời gian ngắn

(Ảnh: mô tả elevator pitch, nguồn Internet)

Có một sự thật là ở Việt Nam, Usability hay UX vẫn xa lạ với nhiều người, hay nói thẳng ra là với những người không làm trong lĩnh vực mobile/web design, bất kể là IT hay không liên quan IT, khi được hỏi về UX đều “lớ ngớ”. Họ không có khái niệm đó.

Elevator pitch là khái niệm mà các start-up hay dùng, ám chỉ việc đưa ra thông tin ngắn gọn nhưng đầy đủ về “business” của mình trong một thời gian ngắn để kêu gọi đầu tư, thu hút sự chú ý của những khách hàng, đối tác, nhà đầu tư tiềm năm. Thời gian “ngắn gọn” ở đây được so sánh với thời gian đứng trong thang máy, đi từ dưới lên trên, hoặc từ trên xuống dưới (khoảng từ 10 – 30 giây). Nếu muốn giới thiệu “business” hay đơn giản hơn là “nghề nghiệp” của mình, một số khái niệm sau đây có lẽ sẽ dễ hiểu hơn:

Luật sư
Nhân viên kinh doanh, nhân viên bảo hiểm/ngân hàng.
Kỹ sư phần mềm, kỹ sư máy tính
Phi công…

Thế nếu bạn làm về UX (UX manager, UX designer) hoặc làm Usability engineer thì câu trả lời sẽ thế nào? Đây là cái tôi băn khoăn, bởi ngay cả với đồng nghiệp, trong cùng một công ty IT outsourcing có uy tín, nhiều người cũng không hiểu đấy là nghề gì? nghề đó thì làm gì? Again, họ không có khái niệm đó.

(Ảnh: một số công việc chuyên sâu trong lĩnh vực UX, nguồn: slideshare.com)

Nhìn vào bức ảnh trên, thì cho dù ở trời ta hay trời Tây, khi nói ra lĩnh vực chuyên môn của mình trong ngành UX, cũng khó mà giúp người nghe hiểu ra ngay mình làm cái gì. Vậy lựa chọn câu trả lời ra sao cho phù hợp? Tôi chọn ra 03 lựa chọn của 03 người nổi tiếng trong ngành như sau:

“It’s sort of on a need-to-know basis…The simpler you can keep it the better.” – Steve Krug (1)

“I tell people I do the software engineering, because people can relate to that. Then I say I’m involved in making products easy to use.” – Joe Dumas, Dr. Usability (2)

“I try to help design websites so people can use them easily…the web domain is a handy one to talk in because it is one that almost everybody can relate to.” – Tom Tullis, Fidelity Investments (3)

Tôi thích lựa chọn số 2 vì có lẽ nhiều người sẽ hiểu hơn là tôi đang làm, đang nghiên cứu về cái gì. Mà cũng dễ gần gũi với khái niệm thông thường hơn. Có lẽ, một lúc nào đó, tôi sẽ đem chủ đề này ra để thảo luận tại một buổi off-line, và khi càng nhiều người nói về nó (UX), nó sẽ càng trở nên phổ biến hơn.

Ghi chú:

(1) Steve Krug nổi tiếng với cuốn “Don’t make me thing” và “Rocket Surgery Made Easy”.

(2) Joe Duma: Bác này là huyền thoại trong ngày Usability, nhiều tuổi hơn cả Jacob Nielsen, viết quyển “A Practical Guide to Usability Testing“.

(3) Tom Tullis: Tác giả cuốn “Measuring the User Experience“.