UX is not always fun

December 8, 2017December 9, 2017 ~ binhtruong ~ Leave a comment

Ai cũng nghĩ làm công việc liên quan đến UX là hay ho lắm, hàng ngày ngồi “chơi” với những công cụ đồ hoạ, những wireframe, những thứ như Sketch, Adobe XD, v.v…chỉ nghĩ tới thôi đã thấy cool rồi. Nhưng thực tế những công việc của UX designer có rất nhiều thứ khiến bạn mau nản lòng, hoặc cảm thấy nhàm chán nếu bạn không thực sự đam mê lĩnh vực này. Trong bài viết này, tôi sẽ chỉ ra những điểm để các bạn hình dung rõ hơn những việc phải làm hàng ngày của “dân UX”.

(Nguồn ảnh: UX planet)

Bắt đầu như thế nào?

Các dự án UX có 3 loại chính:

Làm từ đầu, đừng nghĩ đây là hạnh phúc nhé bởi bạn sẽ phải thực hiện khối lượng công việc khá nhiều.
Cải tiến một sản phẩm / dịch vụ nào đó => dự án kiểu này có sẵn dữ liệu đầu vào giúp bạn định hình phần nào nhưng đổi lại áp lực phải chứng mình giải pháp của bạn thông qua những thay đổi (về design) có hiệu quả.
Tư vấn, thường là giai đoạn 1 dự án đã thiết kế gần xong, hoặc được thiết kế xong bởi team designer nội bộ của một công ty, bạn nhảy vào “góp ý”.

Với loại 1, bạn phải biết nhiều thứ hoặc phải phụ thuộc vào nhiều người tham gia, do đó, dự án chậm là đương nhiên. Bên cạnh đó, việc đi thuyết phục, trao đổi với những cá nhân trong dự án cũng khiến bạn mệt mỏi. Tổ chức càng lớn, communication & progress càng chậm (đơn giản là do họ có qui trình kiểm soát chặt, dẫn đến ai cũng sợ trách nhiệm, do đó ra quyết định chậm, thiếu chính kiến).

Với dự án loại 2, như đã nói ở trên, bạn phải đối mặt với áp lực về mặt hiệu quả của giải pháp đưa ra, nhiều khi giải pháp mới thông qua UX research, dẫn tới điều chỉnh UI “có” mang lại hiệu quả nhưng không đáp ứng kỳ vọng của chủ đầu tư, ví dụ CAC (Customer Acquisition Cost) bị đội lên, hoặc lượng giao dịch trong một payment app chỉ “tăng nhẹ” (do không phải đợt Tết chẳng hạn).

Dự án loại 3 bạn cảm thấy khá “an toàn”, nhưng bạn sẽ nói gì nếu UX không tốt? bạn sẽ huỵch toẹt nói với đội ngũ thiết kế đập đi làm lại? Bạn sẽ “phán” về chất lượng UX khi nó chưa có real testing và chưa có test data? Nói chung bạn nên nghĩ đến những điều này để hình dung về dự án UX trong tương lai.

(nguồn ảnh: uxpin)

Không có chỗ mà làm UX?

Cái này tôi đã nói khá nhiều trong các bài viết trước đây, nhưng trong phạm vi bài này tôi chỉ nhấn mạnh rằng ở Việt Nam, bạn sẽ được “dí” ngay vào bước làm prototype và bị cắt đi hầu như toàn bộ các công đoạn của UX. Tóm lại, bạn khó tìm ra chỗ nào trong qui trình các dự án ở Việt Nam để làm UX chi tiết. Vì sao? UX tốn thời gian, cần thời gian để thử nghiệm, cũng đồng nghĩa là tốn tiền, mà các sếp Việt Nam chỉ muốn nhìn thấy UI và không đủ kiên nhẫn chi tiền cho UX.

“UX team of one” không thực sự hiệu quả

Đây là khái niệm được nhắc tới 3-4 năm về trước, từ một cuốn sách cùng tên với nội dung hướng dẫn làm UX kể cả khi bạn chỉ có một mình. Nghe có vẻ ổn, nhưng đây là điều dành cho người có khả năng tiếng Anh + tự học + giao tiếp + kết nối tốt. Nó cũng phù hợp cho dự án nhỏ, còn vào dự án thực tế và với khả năng của người Việt, nó chưa hiệu quả ngay được. Ngoài ra, tính chất khó khăn nhất là việc làm một mình rất dễ khiến cho bạn bị “ego”, nghĩa là đưa cái tôi, đưa quan điểm cá nhân vào giải pháp thiết kế và trở nên phòng vệ trước những phản hồi của khách hàng.

(UX nhiều việc phải làm, cho nên chơi 1 mình mệt lắm. Nguồn ảnh: UX planet)

Agency luôn ép về tiến độ

Với kinh nghiệm làm digital agency 12 năm của mình thì chưa có bao giờ bạn có đủ thời gian rộng rãi, dễ thở khi làm với agency. Đối với các bộ phận marketing của khách hàng cũng vậy, thời gian phê duyệt kinh phí thì rất lâu, nhưng một khi duyệt rồi thì lại muốn có ngay sản phẩm để xem và nếu ai đã từng làm agency thì sẽ hiểu rằng, bạn sẽ bị “giục”, bị “ép” hàng ngày, hàng ngày, và hàng ngày… Cho dù là nửa đêm, cuối tuần hay ngày lễ, bạn luôn phải chuẩn bị tinh thần nghe điện thoại từ đối tác.

Build more, fail more

Đừng nghĩ làm một lần là “ăn ngay”, cũng đừng nghĩ gửi 1-2 options cho khách hàng là đủ. Mọi thứ sẽ thay đổi liên tục, và dự án càng để lâu càng nhiều phát sinh. Kể cả trường hợp dự án của bạn go-live ngon lành, khi có dữ liệu test và user’s analytics data thì bạn phải quay lại điều chỉnh. Người ta nói “làm UX là vừa làm vừa đo, cho nên đừng đánh giá một bản thiết kế mà hãy test nó”.

Do NOT evaluate design, test it. – NN/g

Adoption: có ai quan tâm đến việc bạn làm?

Câu trả lời là chẳng ai cả, hoặc số ít người trong công ty để ý tới, rất ít. Họ cũng không đánh giá cao công việc này của bạn, trừ những người đã từng phải “trả giá” khi thiết kế sản phẩm ẩu và mất nhiều tiền vì nó.

(ảnh remote testing với đủ thứ để làm – Nguồn ảnh: usabila)

Có nhiều việc chẳng vui vẻ gì

Ngoài việc ngồi vẽ UI, làm wireframe mà đa phần mọi người nghĩ về nó khi nghĩ tới UX (bởi nó khá thú vị) thì còn rất rất nhiều việc khác nữa bạn phải làm trong một dự án UX. Tôi có thể kể ra 20-50 công việc khác nhau mà bạn phải làm (nhiều khi chán ngấy) dù muốn dù không, tất nhiên tuỳ thuộc vào độ lớn của dự án và tuỳ thuộc vào qui trình của công ty bạn đang làm, qui trình của đối tác. Sau đây là một số ví dụ:

User research: cực kỳ lắm các thể loại kỹ thuật liên quan và càng làm càng thấy mông lung. Nhất là dự án có tính global như hệ thống website Kempinski.com mà tôi làm 3 năm qua. 80 website chạy trên 1 nền tảng, 7 ngôn ngữ cho site corporate, 19 ngôn ngữ cho các site khách sạn thành viên và lượng người dùng trải rộng khắp thế giới. Chỉ một báo cáo về eyes-tracking thôi mà cãi nhau cả buổi.
Experience mapping: nếu bạn chưa làm bao giờ thì thử Google xem nó là cái gì và ngồi làm nó “tốn máu” như thế nào. Với website là một bản, với mobile là một bản, thậm chí nếu làm kỹ thì bạn có thể làm cho từng khâu như check-out, onboarding, cart-abandonment.. càng làm kỹ càng mất thời gian, thử đi thử lại, cứ có data rồi thì lại update.
Documentation: UX rất nặng về làm tài liệu và nó có đủ thể loại tài liệu trên đời. Từ personas, đến use case, cho tới wireframe, IA, search model, v.v.. và cái nào bạn cũng phải cho vào tài liệu chuẩn để gửi cho khách hàng. Có tài liệu là kích thước A4, có cái mô tả POC (proof of concept) thì tôi hay dùng A3 để lúc in màu ra cho đẹp + dễ nhìn. Nếu bạn không làm thì ai làm? cùng lắm bạn có thêm 1-2 BA tham gia giúp bạn, nhưng họ không thể mô tả cái ý tưởng của bạn cũng như những kết quả của bạn làm ra. User journey vẽ thì hay, nhưng mà ngồi mô tả main flow, exceptional flow, alternative flow cũng hết hơi.
Presentation & meeting: Dự án càng lớn thì càng phải họp nhiều, trình bày + giải thích nhiều, thậm chí bạn cứ phải đi qua đi lại hoặc sang bên khách hàng ngồi on-site. Nhưng khách hàng họ còn lo làm việc của họ, đâu có làm với bạn hàng ngày, đôi khi tôi trình bày tại cuộc họp nhưng đối tác không nhớ 2 tuần trước chúng tôi đã làm những gì, đã xử lý tới đâu, tại sao hôm nay lại đưa ra giải pháp này?
v.v.. không muốn kể nhiều nữa vì…nói ra thì nhiều lắm 😀

(Hình mô tả user research, bạn có muốn làm không? Nguồn ảnh: IDF)

Khách hàng, họ là 1 thế giới khác

Đối với khách hàng, họ không quan tâm qui trình của bạn, không quan tâm tới thương hiệu của bạn, phần lớn họ chỉ quan tâm tới 3 điều: chi phí, tiến độ, và sản phẩm làm ra “trông” như thế nào. Nói như vậy để bạn hình dung được một điều, chỉ có một số ít khách hàng cá nhân sẽ “ngưỡng mộ” cái bạn làm ra, phần lớn còn lại, họ quan tâm tới vấn đề họ phải lo nghĩ, vì vậy, hãy cố gắng hiểu họ thay vì chỉ lo chăm chút bản thiết kế của mình. Hãy lắng nghe cái họ cần thay vì nghĩ rằng “ông/bà thì biết cái đếch gì về thiết kế mà nói…”, đúng là họ không biết UX, UI thật, nhưng họ biết họ cần gì (đặc biệt là chủ doanh nghiệp) và vì thế họ mới thuê bạn làm.

(Nhìn vào checklist cũng phát nản :D, nguồn ảnh: github.io)

Lời kết

Nhiều bạn nghĩ rằng: tôi chẳng cần thiết làm những việc ông nói ở trên, theme tôi làm ra bán vẫn chạy ầm ầm. OK, đấy là công việc làm web themes của bạn và nó rất hạn chế trong việc áp dụng UX (bởi nó tốt sẵn rồi, và expectation đã định hình từ lâu). Còn ra dự án lớn, đa quốc gia, đa chủng loại người dùng, hay như một công ty có nhiều văn phòng khắp nơi trên Thế Giới, bạn sẽ phải làm những thứ đó. Tại sao? Thứ nhất, họ yêu cầu bạn làm thì bạn phải làm, đó là qui trình chuẩn và họ trả tiền cho bạn làm như vậy. Thứ 2, những kỹ thuật, qui trình này nhằm đảm bảo yếu tố thành công của dự án ở mức % tối đa với những rủi ro đi kèm.

Làm UX có nhiều cái vui nhưng cũng như các ngành nghề khác nó cũng có nhiều cái mệt mỏi, không vui vẻ gì. Bạn phải học cách vượt qua nó, sống chung với nó cũng như xây dựng một đội ngũ hiểu nhau, làm việc ăn ý với nhau. UX rất rộng và có nhiều việc phải làm. Đừng chỉ nhìn ở góc độ mình làm theme WordPress, Magento hay làm app du lịch, đặt phòng khách sạn, đặt vé máy bay v.v.. Khi nhìn UX ở góc độ business, projects… bạn sẽ thấy nó rất hay và rất khác.

Bài này hơi dài, nhưng bao lâu nay không thấy ai viết về vấn đề này, nên mình lại viết 😀

Hà Nội, tháng 12/2017

Binh Truong

Findability Tiki

September 6, 2015September 6, 2015 ~ binhtruong ~ Leave a comment

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

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

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

(Hình 3: Category “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:

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

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

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

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

Crowd testing, a kind of…

September 3, 2015 ~ binhtruong ~ 1 Comment

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).

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

July 21, 2014July 21, 2014 ~ binhtruong ~ 1 Comment

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

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

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).
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

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.