UI vs UX, thêm một góc nhìn

August 9, 2013August 10, 2013 ~ binhtruong ~ Leave a comment

Phân biệt UI, UX dưới góc nhìn interaction design

(Ảnh: UI/UX, nguồn Internet)

Từ khi UX (User Experience) ra đời thì có khá nhiều các blog, website nói về sự khác biệt giữa UI, UX. Hoặc với nhiều người thì đây là việc “rõ như ban ngày”. Hiểu nôm na thì UI (User Interface) là giao diện người dùng, có từ khi máy tính / máy điện toán ra đời và khá phổ biến trong thiết kế phần mềm máy tính ở thập niên 90. UX (User Experience) là những gì người dùng “trải nghiệm” trong và sau khi sử dụng sản phẩm. Có người nói, UI đi trước, UX đi sau. Cũng có người nói UI là giao diện, là sản phẩm còn UX là thương hiệu, dịch vụ, và là cảm nhận của người dùng, có tài liệu thì khẳng định UI cũng là 1 phần của UX… OK, có rất nhiều quan điểm, so sánh, nhìn chung là có vẻ dễ hiểu, nhưng cũng rất chung chung.

Thêm vào đó, những trang web như UX is not UI ( http://uxisnotui.com/ ) còn đưa ra bảng thống kê những khác biệt về UX và UI một cách rất cụ thể, chứng minh sự bao trùm của UX lên mảng UI với khẳng định UX là một giải pháp hoàn thiện.

“UX is the intangible design of a strategy that brings us to a solution”

Theo tôi quan niệm này không sai vì sản phẩm nào mà chẳng có phần UI để người dùng thao tác, tương tác với các tính năng của nó. Nhưng liệu có cách nhìn nào “dễ chịu” hơn và dễ hiểu hơn với UI cũng như tầm quan trọng của nó hay không?

(Bảng so sánh UX, UI, nguồn http://uxisnotui.com/ )

UI is communication

Có một điều thú vị là, năm 2013 đánh dấu sự trở lại về việc nghiên cứu cải tiến UI, với nhiều sách vở, paper về nó. Ở góc độ tương tác với người dùng, Everett McKay đã đưa ra quan điểm, nhận định khá dễ hiểu như sau: UI is communication. Trong nhận định của mình, McKay chỉ rõ 2 điểm như sau:

UI (User Interface): là phương tiện kết nối giữa người dùng và sản phẩm công nghệ. Một chiếc TV có các nút bấm điều khiển, có bảng điều khiển hiển thị kênh, âm lượng. Một website có các menu tương tác, nút bấm, thanh toán hay một chiếc ô tô có vô lăng, bảng thông tin điện tử hiển thị lượng xăng, tốc độ.v.v… Đó chính là “giao diện” hay là tiếp diện để giao tiếp với người dùng. Là những gì người dùng “trực tiếp nhìn thấy” và “cảm nhận” khi sử dụng 1 sản phẩm. (Looks and feels).
UX (User Experience): bao gồm toàn bộ trải nghiệm của người dùng đối với một sản phẩm. Trải nghiệm này tất nhiên bao gồm cả tương tác UI nhưng ngoài ra, nó còn bao gồm những thứ mà người dùng không giao tiếp trực tiếp với sản phẩm. Để dễ hiểu hơn, trải nghiệm có thể là quá trình mua hàng trực tuyến, hay mở gói một sản phẩm (un-pack), hỗ trợ kỹ thuật, chăm sóc khách hàng, chế độ bảo hành..v.v…

Giao tiếp luôn là chìa khóa của cuộc sống, và đối với phần mềm cũng vậy. UI là cách mà người dùng giao tiếp với hệ thống. Thông qua UI, người dùng biết họ phải làm gì. Ngược lại, với UX, đó là 1 quá trình nghiên cứu để giảm thiểu các thao tác “thừa” cho người dùng, giảm bớt những gánh nặng và những khó khăn mà người dùng gặp phải.

“User interface design addresses actions users must do, but user experience design also addresses actions users don’thave to do” – Everett McKay

Một hệ thống được thiết kế UI tốt thường là một hệ thống có các màn hình giao diện dễ sử dụng, hiển thị dashboard thông tin tốt, cho phép người dùng cấu hình (configuration) các thông số ngay sau khi cài đặt hoặc đăng ký sử dụng. Nhưng tiến xa hơn nữa, một hệ thống có UX tốt là hệ thống “không bắt” người dùng phải thiết lập các thông số cấu hình (configuration) trước khi sử dụng. Ví như Twitter chỉ cần đăng ký account là có thể tweet ngay lập tức.

Nói một cách ngắn gọn, UI chính là cách thức, phương tiện giao tiếp giữa người dùng và phần mềm, dù đó là web hay mobile app. Một UI tốt là UI mà người dùng có thể dễ dàng tiếp cận, dễ dàng “giao tiếp” thậm chí không phải đọc tài liệu user guide hay phải có người đào tạo. Hãy nhìn nhận UI là communication, và UX là quá trình trải nghiệm, cải tiến và rồi mang lại feeling tốt hơn.

Domino’s Pizza Saigon

August 9, 2013 ~ binhtruong ~ 4 Comments

Một số thiết kế UX của Domino’s Pizza Quận Tân Bình, HCM

(Ảnh: Tracking screen của nhà hàng Domino’s Pizza, Cộng Hòa, Q. Tân Bình, HCM)

Domino’s Pizza là một hương hiệu pizza của Mỹ đã tồn tại trên 50 năm. Khởi điểm với tên gọi DomiNick’s và đổi tên thành Domino’s một thời gian sau đó, hãng pizza này vào Saigon năm 2010 rồi sau đó nhanh chóng phát triển với nhiều chi nhánh trên khắp các quận nội thành. Ở Hà Nội thì chưa có cửa hàng nào. Mới đây Domino’s khai trương 1 cửa hàng ở quận Tân Bình nên tôi ghé thử, cũng 1 phần là có discount 30%.

Ấn tượng đầu tiên là design hoàn chỉnh, thống nhất 2 màu đỏ – xanh nước biển của hãng, từ logo cho tới màu tường, bao bì… trên tường sử dụng typography với phong cách khỏe khoắn và có gì đó rất US. Tuy nhiên, đập vào mắt và đáng chú ý nhất chính là tấm bảng thông báo thời gian phục vụ với từng đơn hàng (xem hình trên). Khi bạn order một đơn hàng, nhân viên sẽ hỏi tên của bạn rồi sau đó, khi đơn hàng đã nhập vào máy tính, thông tin của nó sẽ hiển thị trên màn hình bao gồm số thứ tự (ID đơn hàng), tên khách hàng, thời gian cần thiết để chuẩn bị món ăn và sau cùng là trạng thái của đơn hàng đang được xử lý tới đâu. Ví dụ: #1 – Binh – 12mins – in oven nghĩa là pizza của tôi đang trong lò sẽ được phục vụ trong vòng 12 phút nữa.

Idea này không mới, và có ở nhiều nơi áp dụng, hoặc là bằng cách hiển bảng điện tử hoặc bằng cách phát 1 thiết bị tự nhấp nháy đèn hoặc rung khi order của mình chuẩn bị xong xuôi. Cá nhân tôi thích cách dùng bảng điện tử như của Domino’s vì:

Thông tin được visualize giúp người dùng / khách hàng dễ theo dõi.
Tạo một cam kết cho tất cả các khách hàng về thời gian. Khi bạn đã công bố thời hạn hoàn thành 1 order, uy tín của bạn được đặt vào cam kết đó, và cũng có nghĩa là bạn tôn trọng những khách hàng đang chờ đợi.
Đầu tư nhỏ, ấn tượng + hiệu quả lớn.

Bên cạnh đó, Domino’s pizza cũng cần cải thiện một số điểm như:

Bảng điện tử nên để thông tin tiếng Việt, điều này sẽ giúp cho người dùng dễ hiểu hơn (không phải khách nào cũng hiểu “in oven” là bánh đang nướng trong lò). Điều này có thể do phần mềm của Domino’s chưa Việt hóa.
Khi khách hàng trùng tên nhau, ví dụ có nhiều người tên là Lan, Nhung.. thì việc theo dõi thông tin trở nên khó khăn. Giải pháp “gọn nhẹ” nhất theo tôi là đổi thứ tự cột thông tin. Ví dụ: ID đơn hàng, thời gian thực hiện, trạng thái và sau cùng là tên khách hàng. Ngoài ra trong hóa đơn đưa cho khách, ID đơn hàng cần in đậm và to hơn chút xíu.

Ngoài bảng điện tử khá hiệu quả thì Domino’s cũng đang áp dụng message wall/board dành cho khách hàng, nhưng đáng tiếc là chưa biết làm thế nào để đưa thông tin lên khoảng trống trên tường của họ.

(Ảnh chụp message wall của Domino’s Pizza)

Một mảng tường đen với khẩu hiệu CTA (Call To Action) bằng tiếng Anh “TELL US WHAT YOU THINK” khá nổi bật và bắt mắt, nhưng khách hàng (là tôi) phải làm sao để “viết” ý tưởng / góp ý của mình lên đây? Cung cấp cho khách hàng bút xóa màu trắng? hay sẽ để cho khách hàng dán sticky note lên tường? Việc này làm tôi nhớ tới một góc nhỏ trong quán cafe Starbucks ở Quận 1 mà ở đó, họ có góc dán ảnh của khách hàng (ảnh Polaroid) nhưng tôi cũng không biết làm sao để có ảnh và được dán lên đó? Như vậy thiết kế mới chỉ mang tính trang trí chứ chưa thực sự tạo ra “tương tác” với khách hàng. Chưa đạt được cái gọi là Interactive design.

Domino’s Pizza phục vụ các món ăn của họ bằng những hộp đựng bằng bìa carton giống như các hộp đựng pizza giao hàng tận nhà. Cách đựng thức ăn như vậy giúp khách hàng dễ dàng mang đồ ăn về nếu ăn không hết. Nhưng nếu bạn muốn một bữa ăn với những chiếc đĩa, dao, nĩa thịnh soạn thì có lẽ Alfresco, Pizza hut sẽ là lựa chọn phù hợp hơn.

Gamification framework for software product

July 31, 2013August 1, 2013 ~ binhtruong ~ Leave a comment

Gamification framework trong thiết kế sản phẩm phần mềm

(Ảnh: gamification, nguồn: Internet)

Khi bắt tay vào thiết kế sản phẩm phần mềm, có thể là business enterprise software, hoặc 1 web application hay mobile application, và bạn muốn áp dụng Gamification vào sản phẩm của mình nhằm gắn kết người dùng, bạn sẽ bắt đầu từ đâu?

Khác với các phương pháp truyền thống như lấy dữ liệu làm trung tâm khi thiết kế phần mềm (Data Center Design) hay tập trung vào công nghệ (Technology Center Design), cách tiếp cận của software designer những năm gần đây tập trung vào người dùng (user), còn gọi là User Center Design. Trên thực tế, người sử dụng không quan tâm đến công nghệ hay những dữ liệu được xử lý bên trong phần mềm ra sao, cái mà họ quan tâm là:

Getting thing done: làm xong việc của mình.
Interact with users: tương tác với các đồng nghiệp, đối tác thông qua phần mềm.
Having fun: cảm thấy thích thú, vui vẻ và gắn kết với ứng dụng (engagement), điều khiến họ dành nhiều thời gian sử dụng phần mềm của bạn.

Kế thừa những tư tưởng của User Center Design, những người áp dụng Gamification vào qui trình thiết kế phần mềm đưa ra một khái niệm mang tính chất như một bước tiến xa hơn: Player Center Design. OK, Chúng ta sẽ tập trung thảo luận về Player Center Design và những thành phần mà framework & process đó cung cấp.

(Ảnh Player Center Design, nguồn: Gamification at Work, xuất bản 2013)

Khác biệt giữa user và player

Khi đặt vào bối cảnh của Game (Game context), người dùng (user) lúc này trở thành người “tham gia cuộc chơi” (player). Ngoài những yếu tố như tính hiệu quả, sự thành thạo (sử dụng chức năng, luật chơi) và mức độ thỏa mãn thì Gamification còn bổ sung những nhân tố mà một software product thông thường chưa có được. Sự bổ sung quan trọng nhất có lẽ là tính chủ động của player. Khác với user, player chủ động tham gia cuộc chơi với những ham muốn chinh phục thử thách. Thông qua thời gian và kinh nghiệm sử dụng sản phẩm phần mềm, player tìm thấy cho mình niềm vui khi chinh phục và trải nghiệm. Những điều này không thể tìm thấy ở một software user thông dụng.

Một player luôn cải thiện mình đi từ vị trí beginner, lên tới intermediate user và cái đích sau cùng sẽ là advance / expert level.

Khi Player là trung tâm

Cũng giống như công việc của UX designer (1), khi áp dụng Player Center Design framework vào việc thiết kế phát triển sản phẩm phần mềm, thì người thiết kế sản phẩm sử dụng framework nêu trên để tư duy Gamification. Qua đó, hướng phát triển sản phẩm, chức năng, đi từ trung tâm của mô hình rồi sau đó lan tỏa ra các thành phần bên ngoài như sau:

Player: Hiểu player cũng như context của họ. Player trong trường hợp này sẽ là ai? Ai sử dụng phần mềm của bạn? Họ là nhân viên kinh doanh? khách hàng mua hàng tại siêu thị, hay các nhà quản lý? Mỗi đối tượng sẽ có mục đích sử dụng phần mềm khác nhau, thời gian khác nhau và nhu cầu khác nhau. Hiểu player cũng giúp bạn hoàn thành tốt công việc Personas trong UX.
Mission: Xác định nhiệm vụ mà ứng dụng sẽ cung cấp, đáp ứng. Player nếu là nhân viên sẽ thao tác những gì hàng ngày? Và nếu player là nhà quản lý sẽ cần những thông tin, báo cáo gì?
Human motivation: Đây là một trong những phần quan trọng nhất của Player Center Design và đối với Gamification, đây là yếu tố khiến người dùng “gắn kết” với ứng dụng. Có thể dễ dàng nhận thấy điều này được áp dụng triệt để trong việc thiết kế games thông qua quan sát những người chơi game say mê như thế nào. Để motivate player, sẽ cần phải áp dụng nhiều biện pháp liên quan tới tâm lý hành vi, tới những thách thức và đụng chạm tới phạm vi rộng hơn như social psychology.
Game mechanics: Mechanic (từ gốc trong tiếng Anh là cơ khí, máy móc) mang ý nghĩa là các thành phần cấu thành (hoặc cấu trúc) của game. Trong ngành công nghiệp Game, các game mechanics thường được tính toán rất phức tạp với nhiều thuật toán và công thức, đặc biệt là các biểu thức để tăng “level” trong game. Khi áp dụng vào thiết kế phần mềm, có thể hiểu nôm na là việc áp dụng các kết cấu của Game design vào thiết kế phần mềm, qua đó, lôi cuốn người dùng sử dụng và gắn kết lâu dài sản phẩm của bạn. Các game mechanics trong phần mềm (mobile / web app) thường thể hiện qua UI với những kiểu phổ biến như điểm số (points), thứ hạng (level), danh hiệu, phù hiệu (badges), bảng xếp hạng (leader board – trong foursquare là top check-in), thách thức (challenges, chính là mayorship của foursquare).v.v… (2)
Manage, Monitor và Measure: Đây là vòng tròn tiếp theo, bao bên ngoài của nền tảng nêu trên. Giống như bất cứ sản phẩm phần mềm nào, game phần lớn cũng là 1 sản phẩm phần mềm, và cũng cần được theo dõi, đo đạc, thống kê hành vi của người dùng. Trong UX, việc theo dõi và quan sát người dùng để từ đó tối ưu tính năng, UI, business flow của sản phẩm cũng rất phổ biến. Có một lưu ý quan trọng là, Gamification là một chương trình dài hạn, không phải một dự án có bắt đầu và kết thúc, do vậy, các sản phẩm áp dụng Gamification thường khởi đầu với những tính năng đơn giản (Lean start) và rồi theo thời gian, ứng dụng đó sẽ được điều chỉnh, cải tiến để phù hợp với người dùng hơn, motivate và engage tốt hơn với người dùng.

Gamification is a program and not a project – Gamification at Work

Sau cùng, các yếu tố bên ngoài cần lưu ý là bối cảnh của ứng dụng. Mobile sẽ có “context” khác với các web app. Nếu phần mềm phục vụ cho các doanh nghiệp (enterprise context) thì thời gian, đối tượng sử dụng sẽ khác với sản phẩm phục vụ cho học sinh, sinh viên. Ethical và legal đảm bảo cho việc áp dụng Gamification không đi quá giới hạn, không sa đà vào việc lợi dụng người dùng để kiếm lợi thông qua thời gian và tài chính của họ (trực tiếp hay gián tiếp). Nhưng quan trọng nhất, theo tôi, đó là dù bạn thiết kế sản phẩm phần mềm nào, khi áp dụng Gamification nên giữ được một giá trị cốt lõi của “game” đó là: Keep it fun!

Ghi chú:

(1) Nhiều blog cho rằng không thể thiết kế được UX, vì đã là kinh nghiệm của người dùng thì “không thiết kế” được, nhưng quan điểm của tôi thì UX design là sự linh hoạt. Mọi thứ đều có thể được thiết kế, đo đạc, thậm chí lập kế hoạch đo đạc và theo dõi người dùng để cải tiến sản phẩm, quan sát tâm lý hành vi, nhận thức (cognitive), thị giác (visual eye-catching) .v.v… UX Designer có thể là 1 người, hoặc 1 team, và chịu trách nhiệm những việc như vậy.

(2) Game mechanics là một lĩnh vực rất rộng lớn, hiện tại các mobile / web app thường áp dụng từ 7 – 40 mechanics khác nhau tùy vào loại hình ứng dụng. Tôi sẽ viết về game mechanics, các cách ứng dụng và cách thiết kế ra 1 game mechanics vào các blog sau.

Bảng thông tin tại Lotte Cinema

July 29, 2013 ~ binhtruong ~ Leave a comment

Thiết kế thông tin hiển thị dashboard của Lotte Cinema

(Ảnh chụp bảng thông tin tại Lotte Cinema, Pico Mall, đường Cộng Hòa, Tân Bình, HCM)

Pico Mall là một trung tâm thương mại (TTTM) mới khai trương, nằm trên trục đường Cộng Hòa, Quận Tân Bình, Tp HCM. Cũng như bao TTTM khác, ở đây có food-court, và rạp chiếu phim. Rạp film ở đây là “thị phần” của Lotte, một trong những tập đoàn lớn của Hàn Quốc. Lotte Cinema có ưu điểm là giá “mềm” hơn các rạp khác cùng loại, ví dụ như Megastar, Galaxy (chả hiểu sao dạo này Galaxy đắt lên ngang hàng với Megastar?).

Nếu so sánh với các TTTM khác như Parkson, Vincom thì Pico Mall (cả ở Hà Nội lẫn Tp HCM) đã được “kiểm chứng” là không biết thiết kế thông tin cũng như bố cục gian hàng. Giữa các tầng, việc phân loại nhóm ngành hàng rất lộn xộn và không điều hướng hành vi của khách. Và có vẻ như Lotte Cinema ở đây cũng không ngoại lệ.

Bước chân vào sảnh chính của Lotte Cinema, việc đầu tiên đối với hầu hết các khách hàng là xem những thông tin cần thiết nhất như: các phim đang chiếu, lịch chiếu và giá vé. Tuy nhiên, tôi và người bạn đi cùng mất hơn 10 giây để định hình được bảng thông tin điện tử của Lotte Cinema đang trình diễn thông tin ra sao và mất thêm khoảng 30 giây – 1 phút để có được thông tin mình cần. Thậm chí thời gian là lâu hơn. Như vậy trung bình một người khách hàng mới lần đầu bước vào đây mất khoảng 5 phút để thấy và hiểu được thông tin mình cần (có thể sẽ còn lâu hơn với người ít đi xem rạp).

Vấn đề nằm ở chỗ, người thiết kế ra bảng thông tin điện tử này cũng có ý đồ usability với một số điểm nhấn như sau:

Toàn bộ thông tin được bố trí trên bảng điện tử, kéo dài theo chiều ngang, nhằm cung cấp cho khách hàng một cách tiện lợi nhất, đầy đủ nhất.
Bảng điện tử được treo không quá cao, dễ nhìn.
Font chữ rõ ràng, màu chữ được bố trí theo trạng thái riêng để phân biệt giờ chiếu đã qua, giờ chiếu gần nhất và giờ chiếu còn lại trong ngày.
Tên film được viết đầy đủ chứ không viết tắt kiểu khó hiểu như Megastar
Màu nền tương phản với màu của chữ, và không biến đổi hay có ảnh nhìn, giúp cho khách hàng đọc thông tin dễ dàng hơn.

Thiết kế là vậy, định hướng usability là vậy thì tại sao vẫn khiến khách hàng (là tôi) cảm thấy khó chịu khi đọc, cũng như thấy khó khăn, chật vật một lúc đầu mới “hiểu” được ý đồ và cách trình diễn thông tin? Theo quan điểm cá nhân tôi, có vài điểm trong thiết kế của bảng tin điện tử này khiến người dùng “bối rối”:

Có những thông tin “thừa” đối với khách hàng. Nếu nhìn lại bức ảnh trên, liệu bạn có “hiểu ngay” các khái ký tự A, 1B là gì không? Hoặc bên cạnh tên film là các con số 05, 06… Ở địa vị khách hàng, tôi sẽ tự đoán đây là số phòng chiếu film / hoặc rạp film? Trên thực tế, khi đã mua vé, tôi không quan tâm lắm đến thông tin này, nó không phải là thông tin bắt buộc phải có, và khi qua cửa soát vé chung, bao giờ nhân viên cũng chỉ cho tôi vào phòng chiếu phù hợp. Thông tin phòng chiếu cũng đã được in trên vé, vì vậy những thông tin này không phải là “thông tin trợ giúp” cho hành vi mua vé của khách hàng.
Bố cục thông tin chưa hợp lý. Cụ thể là thời điểm khách hàng đặt chân vào sảnh chính và tìm thông tin chiếu phim, tên phim và giờ chiếu sẽ ở cách xa nhau nếu bạn xem film vào buổi tối. Nguyên nhân là bởi bảng thông tin hiện toàn bộ giờ chiếu của phim từ sáng tới tối. Nếu giờ chiếu đã trôi qua, font chữ là màu vàng, và nếu giờ chiếu sắp tới hoặc gần với giờ hiện tại nhất sẽ được định dạng font chữ màu xanh. Giờ chiếu trong vài giờ tiếp theo sẽ là màu trắng. Vấn đề là ở chỗ: giờ hiện tại và các suất chiếu gần đó được format màu giống nhau nhưng để lệch nhau (xem hình trên), và suất chiếu gần nhất lại cách quá xa tên film khiến cho khách hàng phải “đoán” mới nắm được thông tin mình cần. Một lần nữa, những giờ chiếu trong ngày đã qua rồi thì khách hàng cũng không quan tâm nữa (vì cũng chẳng mua vé được nữa). Nếu muốn mua vé cho ngày hôm sau? Lượng khách hàng này không phải là đa số nếu so với khách hàng xem film trong ngày, nên cần ưu tiên khách hàng hiện tại hơn.
Độ trễ của thời gian hiển thị quá ngắn. Vì chiều cao của bảng thông tin bị hạn chế ở mức vừa phải, chỉ có 03 film hiển thị trên 03 dòng tương ứng nên thông tin phải “nhảy” liên tục. Sẽ không có vấn đề gì quá lớn nếu như độ trễ của mỗi lần “nhảy ” thông tin hiển thị quá ngắn. Theo tính nhẩm của tôi thì độ trễ dưới 3 giây, có lúc tưởng như chỉ khoảng 2 giây là thông tin thay đổi. Như vậy tôi sẽ phải “chờ” tới khi màn hình hiển thị lại thông tin của bộ phim tôi muốn xem để có thể tiếp tục tìm thông tin mình cần.

Bảng điện tử không phải là nơi duy nhất mà người dùng/ khách hàng có thể tìm kiếm thông tin để đặt vé xem film. Có nhiều cách khác như dùng mobile app, thông qua website của Lotte Cinema, hoặc hỏi trực tiếp nhân viên bán vé khi đã “chốt hạ” mình muốn xem film nào. Tuy nhiên, bảng điện tử phục vụ cho số đông khách hàng, những người “không thích” hoặc “chưa quen” với online booking. Và ở góc độ thiết kế, nó còn nhiều thiếu sót. Chẳng hạn như vì quá dài nên phải ghép nhiều màn hình lại, tạo ra các đường kẻ dọc ngăn cách luồng thông tin do khung màn hình tạo ra, hoặc như việc bố trí các giờ chiếu rời rạc và không có sự gắn kết giữa các suất chiếu này với tên film. Nhưng trên thực tế những khiếm khuyết này có thể khắc phục dễ dàng. Điều quan trọng là khi thiết kế ra 1 sản phẩm có tính tương tác với người dùng, bạn phải test nó, phải trở thành người dùng đầu tiên đối với chính sản phẩm mình làm ra…rồi từ đó tối ưu thiết kế để mang lại hiệu quả cao nhất.

Push, Pull door tại Coffee Bean and Tea Leafs

July 29, 2013July 29, 2013 ~ binhtruong ~ Leave a comment

Chuyện cánh cửa của cafe Coffee Bean & Tea Leafs đường CMT8, HCM

(Ảnh chụp cửa ra vào khu WC, cafe Coffee Bean & Tea Leafs, đường CMT8, HCM)

Con người thường có tâm lý làm theo những chỉ dẫn mặc định hoặc theo những suy đoán mà họ tin rằng suy đoán đó là đúng đắn, là đương nhiên. Điều này dễ hiểu bởi ai trong chúng ta cũng quen với những dấu hiệu phổ biến như EXIT, WC, hay PUSH/PULL trên các cánh cửa của các cửa hàng mặt phố. Khi một dấu hiệu (sign) đã là “mặc định” trong trí não của ai đó, người ta hiếm khi làm điều ngược lại với trí nhớ / thói quen của mình.

Câu chuyện hôm nay tôi nói về 1 cánh cửa. Cánh cửa này là cửa ra vào khu WC tại quán cafe The Coffee Bean & Tea Leafs, nằm trên đường CMT8, thành phố HCM (xem hình trên). Khi nhìn vào cánh cửa, người dùng (có cả tôi) đã có những suy nghĩ “mặc định” như sau:

Đây là lối vào khu vệ sinh, dựa trên dấu hiệu WC
Cửa có tay cầm nho nhỏ phía tay phải (và tay trái nếu nhìn ở trong ra), như vậy có thể dùng để kéo. (Tay cầm dạng này thì chỉ kéo thôi chứ không đẩy).
Người dùng sẽ chú ý tới “tay cầm” trên cánh cửa trước, và nếu có biển hiệu, sẽ chuyển qua làm theo hướng dẫn trên biển hiệu mà bỏ qua tay cầm.

Khi tới cần cánh cửa, tôi đẩy nhẹ và bước vào. Một lát sau, khi quay lại, tôi dùng tay nắm chặt vào chỗ “tay cầm” trên cánh cửa và kéo về phía mình. Như vậy, trong hiểu biết nhanh (quick learn) của tôi, cánh cửa này như bao cửa khác là đóng mở 1 chiều. Và vì thế, một cảm giác usability xuất hiện là cái “tay cầm” bằng nhựa rất khó chịu, đau tay, ở vị trí hơi thấp và không phù hợp với một cánh cửa to như vậy. Chả hiểu “thằng cha” nào design ra cái cửa kiểu này?

Trở về chỗ ngồi của mình, và vì tôi ngồi gần cánh cửa này, tôi để ý 2-3 khách hàng khác cũng gặp vấn đề như tôi, nghĩa là đẩy vào thì dễ mà đi WC xong quay trở lại thì rất khó khăn để kéo cánh cửa về phía mình từ bên trong. Với chị em phụ nữ thì việc này thật nặng nhọc và khó khăn. Tuy nhiên 15 phút sau, có 1 khách hàng nam giới, người nước ngoài đi vào khu WC, và hành vi của ông ta khác hẳn với tôi và những người trước đó: ông ta cố gắng kéo cánh cửa (Pull) về phía mình để đi vào khu WC rồi sau khi trở ra thì đẩy (Push) cánh cửa từ trong ra. Ô hô, hóa ra cánh cửa có thể đẩy / hoặc kéo từ cả 2 phía.

(Ảnh: chú thích trên cánh cửa, nguồn: Internet)

Việc một cánh cửa có thể đẩy (Push) hoặc kéo (Pull) từ cả 2 phía không phải là điều gì mới mẻ. Rất nhiều Shop trên mặt phố tại Tp HCM có những cánh cửa kiểu này. Vậy thì vấn đề ở đây chính là biển báo. Và bởi vì không có biển báo, nên các khách hàng của The Coffee Bean không được “hướng dẫn” phải sử dụng cánh cửa như thế nào, hệ quả là họ sử dụng cánh cửa theo thói quen “mặc định” trong trí não của họ. Có người đẩy trước kéo sau, có người thì làm ngược lại. Mặc ai người nấy dùng.

Biển báo là không bắt buộc, nếu cánh cửa chỉ có thể đẩy / kéo theo 1 chiều duy nhất, nghĩa là chỉ có 1 cách dùng thì người dùng sẽ phải sử dụng theo cách khả thi nhất sau 1-2 phép thử. Bằng cách này sẽ hạn chế “tại nạn” khi có nhiều hơn 1 khách hàng tiến tới cánh cửa này từ cả 2 phía (trước và sau cánh cửa). Bên cạnh đó, nếu có biển báo thì người dùng (là khách hàng ở đây) sẽ không phải học cách dùng và sẽ dễ dàng sử dụng hơn. Nói về biển báo, trên Thế Giới có 1 design pattern cho Push/Pull như vậy.

(Ảnh và nguồn: Push Pull Sign)

Có thể thấy, ngay từ những điểu nhỏ nhặt nhất là cánh cửa ra vào, nếu bổ sung những thứ “nho nhỏ” để quá trình nhận thức (recognition) của người dùng được rút ngắn lại thì họ (khách hàng) sẽ cảm thấy happy hơn dù chỉ trong giây lát.

Với cánh cửa của The Coffee Bean & Tea Leafs, cá nhân tôi cho rằng nên có 1 số cải tiến nho nhỏ:

Bổ sung nhãn (label) cho 2 phía của cánh cửa. Nếu không dùng “hoạt họa” như hình trên thì có thể đơn giản sử dụng chữ cái PUSH / PULL là xong. Khi nhìn thấy PUSH / PULL, phần lớn người dùng sẽ bỏ qua cái “tay cầm”.
Chuyển chiều hướng hoạt động đóng/mở của cánh cửa về 1 chiều duy nhất, nghĩa là khi vào PUSH, khi đi ra phải PULL. Làm như vậy có thể giảm tính tiện lợi với người dùng (PUSH thì đỡ mệt và “sướng” hơn là PULL cả cánh cửa to bự) nhưng lại tăng tính an toàn. Vì nếu để cánh cửa có thể PUSH từ 2 phía sẽ gây nguy hiểm khi có 2-3 người dùng ra / vào từ 2 phía.
Nếu để PUSH cả 2 phía, cần bổ sung ghi chú “Đẩy cửa nhẹ và từ từ…” để giảm thiểu “tai nạn” không đáng có.

OK. Chuyện cũng chỉ là cái cánh cửa. Cánh cửa thông thường chẳng có gì đáng nói, nhưng khi mà có khoảng 5-10 người gặp khó khăn với nó (cánh cửa) trong quá trình sử dụng thì đó là lúc người thiết kế ra nó cần phải xem lại, tối ưu sao cho nó đạt hiệu quả tối đa. Nói thì dông dài, nhưng đó chính là 1 dạng Observe User Experience. Và sự hài lòng của khách hàng đôi khi cũng chỉ tới từ những điều nhỏ nhặt như vậy mà thôi.