Abstraction Hub

IA, UX, UI, User Experiences, Usability, Web Design, Information Architect, HCI

Category: Usability Engineering

Findability Tiki

Bug noted – lỗi cấu trúc thông tin của Tiki

0

(Hình 1: Tiki.vn – nguồn Tiki.vn)

Từ trước tới giờ, thỉnh thoảng tôi vẫn viết về các lỗi thiết kế (UI, service) của các website, việc này không nhằm chê bai hay “tự sướng”, mà là để chỉ ra những thứ ta có thể làm tốt hơn, và bản thân tôi cũng học hỏi từ đó.

Trở lại với Tiki.vn sau sự cố bị từ chối cộng điểm vì ban quản trị nghĩ rằng tôi “copy” bình luận sách từ trên Internet. Sau khi chứng minh là tôi copy từ chính… blog của mình, tôi đã được bổ sung “tiki xu” trở lại. Nhưng sau đó thì cũng không engage với website này nữa, một phần vì muốn đi lượn phố Nguyễn Xí hơn, và một phần Tiki mở rộng sang đa ngành nghề (tôi biết áp lực tăng trưởng là phải vậy). Tuy nhiên hôm nay cần mua một cuốn mà lười ra phố, nên tôi lại truy cập website này.

Về cơ bản thì hệ thống website Tiki.vn vẫn vậy, ngoài những tính năng cơ bản thì có nhiều không gian được thiết kế lại để dành cho quảng cáo hơn. Cấu trúc thông tin top-down vẫn như cũ, nghĩa là danh mục chính, rồi các cấp danh mục nhỏ hơn qui hoạch bên trong.

00

(Hình 2: on top banner của Tiki )

Tuy nhiên, đi sâu vào phần tìm kiếm sách, tôi nhận thấy 2 vấn đề “cản trở” người dùng tìm được thông tin mình cần trước khi ra quyết định mua sách:

Vấn đề #1  Cover to detail: Nghĩa là cấu trúc thông tin bên ngoài và thông tin chi tiết bên trong không có sự đồng nhất. Mặt này có 2 điểm: một là mental model của cá nhân tôi nghĩ rằng hình ảnh thumbnail của 1 category sẽ được lựa chọn từ 1 trong những sản phẩm thuộc category đó. Cụ thể là cuốn REWORK đáng ra phải nằm trong phần “Kỹ năng sống – Làm việc” như hình bên dưới:

Tiki1

(Hình 3Category “Kỹ năng sống – Làm việc” nhìn từ bên ngoài với hình ảnh cover là cuốn REWORK)

Nhưng khi click vào bên trong, category này hoàn toàn không có sản phẩm REWORK như tôi hình dung:

Tiki1b

(Hình 4: Bên trong category “Kỹ năng sống – Làm việc”)

Bên cạnh đó, khi vào xem chi tiết category nêu trên, toàn bộ phần thông tin của tên category, menu thứ cấp breadcrumb đều tự động chuyển sang tiếng Anh. Điều này một lần nữa sẽ khiến người dùng “bối rối” bởi không biết “có phải mình vừa chọn sai category hay không?”. Vậy tôi phải làm gì đây? Tất nhiên là phải nhờ tới chức năng “tìm kiếm”, một thành phần cơ bản của IA, và điều này cho thấy vấn đề tiếp theo.

Vấn đề #2  deep organize & breadcrumb: Tôi chủ động gõ từ khóa “reworkd” vào ô tìm kiếm, phần gợi mở (suggestion) hiển thị ra cuốn REWORK nhưng khi gõ “enter” để tìm kiếm thì kết quả không tìm thấy. Ok, tôi sửa lại từ khóa thành “rework” và tìm thấy thông tin sản phẩm mình mong muốn:

Tiki2

(Hình 5: Hình ảnh sản phẩm REWORK)

Từ vị trí này, tôi để ý lên phần menu breadcrumb. Tại sao tôi phải làm vậy? một lần nữa, nó là logic theo mental modal của user’s brain. Lý do là ở các bước đã nêu ở trên, tôi là một người dùng đã tìm sản phẩm (hoặc đã được định hướng tìm sản phẩm) tại một category không chính xác.  Chính vì thế nên tôi mới thắc mắc là sản phẩm này nằm ở category nào ? và làm sao để tìm thấy nó?

Theo thứ tự, tôi bắt đầu tìm theo chiều cấu trúc từ trong ra ngoài để tìm category chính thức của sản phẩm. Thứ tự này bao gồm:

  • Trang chủ ->
    • English books ->
      • Business – Investing ->
        • Entrepreneurship – Small Business

Vậy là có tới 4 cấp category dẫn tới sản phẩm tôi muốn tìm mua. Tới đây, tôi lần lượt bấm vào các category theo thứ tự từ trong ra ngoài, từ dưới lên trên với mong muốn trở về đúng category listing của sản phẩm. Nhưng kết quả tôi nhận được lại là các category không có dữ liệu bên trong:

3-1

(Hình 6: category Entrepreneurship – Small Business không có dữ liệu bên trong)

Tiki3

(Hình 7: category Business – Investing không có dữ liệu bên trong)

Sau cùng, không biết làm thế nào để tìm được đúng category cần thiết, tôi bấm vào “English book” thì hệ thống đưa tôi trở về trang chuyên các sản phẩm sách tiếng Anh, mà trong đó, tôi gặp lại category “Kỹ năng sống – Làm việc” ở Hình 3 phía trên. Là một người dùng, tôi hoàn toàn mất phương hướng (completely lost).

Nhìn ở góc độ tổng thể, website vẫn vận hành bình thường. Các đơn hàng có lẽ vẫn đều đặn và thỏa mãn chỉ tiêu KPI của đội ngũ kinh doanh, nhưng không chắc thời gian tìm kiếm trung bình đối với một sản phẩm rồi từ đó dẫn đến hành vi đặt hàng, mua hàng của người dùng là bao lâu? Sẽ ảnh hưởng tới conversion rate có đáng kể hay không? Có thể, mọi thứ là không đáng kể.

Bài viết này tôi muốn chỉ ra một điều đơn giản: IA luôn có thể làm kỹ lưỡng hơn nữa để sản phẩm phục vụ người dùng tốt hơn, trải nghiệm qua đó cũng tăng lên, bởi e-Commerce, nói một cách khác, là để tiết kiệm thời gian.

Findability is a critical success factor for overall usability. If users can’t find what they need through some combination of browsing, searching, and asking, then the system fails. – IA definition, Peter Morville

Có 1 designer lâu năm nói với tôi rằng “Người làm thiết kế có nghề thì có thể nhìn ra vấn đề sau vài bước quan sát”. Bản thân tôi cũng đang luyện rèn kỹ năng đó.

Noted:

  • IA (Information Architect ): Kiến trúc thông tin.
Advertisements

Crowd testing, a kind of…

Thực hiện phương pháp test bởi nhóm người dùng khách quan (alternative focus group)

(Ảnh: Pixel Art Suits – Nguồn: blog.smartbear.com)

Crowd testing không phải topic mới, bởi nó khả phổ biến trên thế giới, đặc biệt là các công ty chuyên làm dịch vụ testing. Có 1 tên gọi khác mà bạn cũng hay gặp, đó là “crowd-source testing”, với nôm na ý tưởng là sử dụng 1 nhóm người dùng nhất định để test sản phẩm của bạn (hoặc công ty bạn) làm ra. Ở góc độ chuyên nghiệp, crowd testing nhằm giải quyết những vấn đề cụ thể như:

  • Cross-culture: Sản phẩm được thực hiện ở 1 nước, nhưng phục vụ global users, cũng có nghĩa là target users của bạn ở nhiều đất nước khác nhau, văn hóa, ngôn ngữ, tôn giáo và nhận thức / tư duy khác nhau. Chính vì thế mà nếu sản phẩm chỉ được test bởi 1 nhóm tester ở trong công ty của bạn là không đủ.
  • Alternative view: Với một nhóm được chọn ngẫu nhiên bao gồm những người chuyên nghiệp lẫn không chuyên, bạn sẽ có số liệu usability test có tính trung thực cao hơn. Bởi nếu bạn và những thành viên trong nhóm cùng test sản phẩm với nhau thì “tính khám phá” sẽ không còn do nhóm đã tham gia phát triển sản phẩm được 1 thời gian nhất định. Vd: nếu test phần registration thì sau vài lần self-test bạn / hoặc developer trong nhóm sẽ thao tác rất nhanh để đi qua bước đó. Cảm quan về layout, color, first feeling cũng không còn mới nữa.v.v..
  • Quick failure, quick rebuild: Khi đưa sản phẩm dạng MVP (Most Valuable Product) cho nhóm crowd testing, bạn có cơ hội kiểm chứng tính đúng đắn, hiệu quả của tính năng cũng như giao diện nhanh hơn. Điều này giúp giảm thiểu sự “tranh cãi” trong nội bộ nhóm, cũng như giảm thiểu lỗi usability tới end-user thực sự của bạn.
  • Improve personas: Personas là một công việc khá nặng nhọc nếu làm cẩn thận vả kỹ lưỡng, tuy nhiên trong nhiều dự án có thời gian phát triển ngắn, việc interview người dùng để phát triển nghiên cứu personas là khá khó khăn cũng như tốn nhiều thời gian và chi phí. Crowd-testing với sự lựa chọn của nhóm “rộng” hơn và “tập trung” hơn vào thị phần bạn hướng tới sẽ giúp bạn có phản hồi tích cực.
  • Ego is good: Ego (cái tôi), trong nhiều trường hợp bị tẩy chay, nhất là làm việc nhóm, nhưng trong testing lại là 1 điều tích cực. Tại sao? Bởi Ego là bản chất của con người. Khi được mời test 1 sản phẩm, bạn sẽ nghĩ gì? OK, sản phẩm này có phục vụ cho “tôi” đạt được cái “tôi” muốn hay không? Để xem họ làm ăn ra sao, kiểu gì chả có lỗi? và “tôi” thích thú khi tìm ra lỗi, và cảm giác đó giúp “tôi” thấy mình thật cool. (may mà có “tôi” không thì sản phẩm bị lọt lỗi ra ngoài nhé!).v.v…
  • v.v.. và nhiều lợi ích khác nữa (lúc nào rảnh mình chém tiếp).

crowd-test

(Ảnh minh họa crowd testing, nguồn Applause)

nhóm của tôi, crowd testing được thực hiện đơn giản hơn và mục tiêu hướng tới usability nhiều hơn. Thay vì phân loại crowd testing thành từng phần chuyên nghiệp như: Functional, Security, UI, Performance.v.v.. thì tôi hướng tới việc để các bạn test tự phát (un-educated users). Mục đích là để tôi và nhóm phát triển có cái nhìn trung thực về end-users’s feeling.

Qua thời gian thử nhiệm 1 năm, tôi rút ra kinh nghiệm thực hiện crowd testing cho nhóm với các bước đơn giản như sau:

  • Thời điểm: Sau khi sản phẩm được QA test xong, các lỗi đã được xử lý, tôi gửi email cho cả công ty (khoảng 60 người) và yêu cầu họ hỗ trợ “dùng thử” sản phẩm.
  • Đối tượng: Tất cả mọi người, từ em lễ tân tới kế toán hay những nhóm chuyên môn (PM, QA, PHP, Front-end, Managers..) khác.
  • Thời gian test: 30 phút (bạn có thể để dài hơn nhưng thực ra theo mình thấy để dài hơn sẽ không hiệu quả, thời gian ngắn, bạn sẽ chỉ test những thứ mà bạn thích test nhất, hoặc 30 phút cũng cho bạn thấy với newbie users, thời gian đó có đủ để họ biết dùng sản phẩm hay không?)
  • Xử lý phản hồi / ý kiến đóng góp: Nên làm đơn giản nhất có thể. Tránh sử dụng những nhứ professional như JIRA, Trello, Basecamp… nó quá xa vời với người không chuyên và cũng “mất thời gian” để log bug. Với tôi, tạo 1 file Google excel hoặc 1 shared folder để mọi người kéo thả screen shots lên đó là đủ.
  • Sử dụng online chat tool: Cứ thử đi, xem có ai dùng không? có ai hỏi bạn cách sử dụng không? Zopim là 1 tool miễn phí tốt cho bạn.
  • Stop and review: Bạn phải kiên quyết giữ qui tắc 30 phút. Hết thời gian là ngắt truy nhập 🙂 để sau đó nhóm của bạn tiến hành review, thiết lập ưu tiên cho những bug / hay đóng góp quan trọng và lên kế hoạch hoàn thiện sản phẩm. Quyền quyết định vẫn nằm ở nhóm của bạn, nhưng hãy tập trung vào những ý kiến khách quan và có tính cụ thể cao. Tránh những ý kiến kiểu như “liệu tăng scale lên 1000 concurrent users thì sẽ thế nào?”, hoặc “Ứng dụng khó dùng quá..!”,v.v.. Nói chung là cần tỉnh táo, khách quan.

Crowd testing ở góc độ của tôi có phần nào giống Sprint Demo của Scrum, nhưng thay vì demo theo tuần (cái mà ít hiệu quả ở 1 công ty mà ai cũng bận rộn) thì nhóm của tôi demo ở giai đoạn sản phẩm đã có thể dùng được đối với user. Nghĩa là người dùng có thể chạy hết một user journey.

Bạn có thể áp dụng gamification như giải thưởng cho người test tốt nhất, lỗi tìm ra nhiều nhất, đóng góp về mặt usability hay nhất.v.v.. để tăng tính sôi nổi của cuộc chơi.

Khi sản phẩm được đem ra crowd testing, cũng có nghĩa là cả nhóm phải cố gắng làm thật tốt, chỉn chu hơn. Tester cũng cố gắng test cẩn thận hơn và vì thế bạn có cơ hội kiểm nghiệm nhiều hơn một chút.

Protect Users’ Work

Nhắc lại khái niệm usability căn bản: Đừng cản trở người dùng

Foody-update

(Hình 1: Ảnh chụp màn hình Foody app yêu cầu người dùng nâng cấp phiên bản mới)

Dạo này viết lách về Foody hơi nhiều, nhưng có lẽ mobile app của Việt Nam ít người review quá, nên nhân dịp gặp một case study mới, mình lại “tám” một chút về nó.

Case study

Tình huống người sử dụng lần này khá đơn giản: Tôi và bạn gái hẹn nhau đi ăn tối, và quyết định khám phá 1 chi nhánh mới mở của M2C cafe. Trong đầu không nhớ rõ địa chỉ, vì thế nên nhớ tới Foody app nên lấy điện thoại ra để tìm địa điểm. Hai người chúng tôi dùng một chiếc iPhone 5 và một chiếc iPhone 4, cả hai đều cài ứng dụng Foody từ AppStore. Tuy nhiên, khi bạn tôi mở foody app thì nhận được thông báo “yêu cầu phải nâng cấp phiên bản mới nhất“, nếu không bấm vào CTA “Launch AppStore” thì chỉ có nước thoát khỏi ứng dụng mà thôi. Tôi cũng thử lại một lần nữa với Foody app trên điện thoại của mình và cũng nhận được kết quả tương tự. Câu hỏi đặt ra là:

  • Nhu cầu của chúng tôi (users) là sử dụng app để tìm địa chỉ quán. Chúng tôi không muốn cập nhật vào lúc này, làm sao để đạt được mục đích?
  • Khi bạn đang đứng ở.. ngoài đường, thì khả năng update ứng dựng từ AppStore với mạng 3G của Việt Nam là không khả thi và tốn rất nhiều thời gian, trong khi đó thì bạn đang đói. Thứ mà ứng dụng “yêu cầu” không match với cái người dùng cần.  Mà nếu không update Foody app thì.. có ảnh hưởng gì tới hòa bình thế giới không?

Khái niệm usability căn bản

Tôi không biết bản Foody app v2.7 có gì nổi bật, ngay cả giờ đây sau khi đã cập nhật xong xuôi, thứ tôi cần vẫn chỉ là tìm địa điểm quán ăn / cafe một cách nhanh nhất, tiện nhất khi cần thiết (mà phần lớn tôi đoán rằng user behavior của người dùng sẽ diễn ra ở… ngoài đường). Tôi không thực hiện được điều tôi muốn, không thao tác được chức năng cơ bản nếu không update phiên bản mới, và điều này gọi là blocker bugs trong khái niệm phần mềm.

Prevents developers or testers from performing their jobs. Impacts the development process. – open SUSE – Bug definitions

Đối với interaction design thì điều này phạm phải 2 nguyên tắc cơ bản nhất đó là ngăn cản người dùng thao tác với sản phẩm / thiết bị / ứng dụng phần mềm và không cho phép người dùng ra quyết định đối với tương tác hệ thống. Nghe có vẻ to tát, nhưng thực chất từ chuyên môn gọi là Protect Users’ Work và Autonomy. Cụ thể hơn, 2 nguyên tắc này có thể được giải thích ngắn gọn như sau:

  1. Autonomy: Qui tắc này cho phép người dùng đưa ra quyết định của riêng họ, kể cả với những người kém về mặt thẩm mỹ hoặc yếu trong khâu thao tác với sản phẩm ( Nguyên văn: Enable users to make their own decisions, even ones aesthetically poor or behaviorally less efficient).
  2. Protect Users’ Work: Đây là qui tắc đầu tiên và căn bản của usability design. Ý nghĩa của nó là luôn luôn đảm bảo người sử dụng hoàn thành công việc của mình, đảm bảo công việc của họ được thực hiện thành công. Ngoài ra, nghĩa mở rộng của qui tắc này là đảm bảo người dùng không bị mất thông tin, dữ liệu trong trường hợp không thể tiếp tục thao tác với ứng dụng (vd: mất đường truyền internet, mất password…)

Cải tiến nho nhỏ?

Trường hợp của Foody app không phải là quá khó cải tiến, mà có lẽ ai trong chúng ta cũng biết, với 1 thay đổi nhỏ nhưng sẽ mang lại hiệu quả tích cực hơn với người dùng, ví dụ như: Bổ sung nút lựa chọn “Later” bên cạnh nút CTA “Launch AppStore” để người dùng có quyền lựa chọn cài đặt bản nâng cấp hay tiếp tục sử dụng phiên bản cũ.

Vấn đề ở đây không lớn, nhưng thuộc về khái niệm cơ bản mà có lẽ những người ở vị trí nhân viên phụ trách sản phẩm (Product manager / UX manager ) nên có một checklist để kiểm tra trước khi để sản phẩm go live.

Tham khảo:

  • 10 Usability Heuristics for User Interface Design [URL]
  • First Principles of Interaction Design (Revised & Expanded) [URL] => Cái này rất rất chi là cơ bản 🙂

 

Domino’s Pizza Saigon

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

Capture

(Ả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ọ.

Capture2

(Ả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.

 

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

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

Lotte-info-board

(Ả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”:

  1. 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.
  2. 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.
  3. Độ 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.