Abstraction Hub

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

Tag: Behavior psychology

CMS, một khía cạnh trải nghiệm bị bỏ quên

CMS đúng là một trải nghiệm mặc định bị bỏ quên bởi đội ngũ xây dựng web. Họ cho rằng cứ bàn giao cho người dùng hệ thống CMS sẵn có và người dùng phải chấp nhận điều đó. Trên thực tế, chúng ta có thể làm tốt hơn.

TDB*

Các dự án thiết kế website thường chỉ được chú trọng vào giao diện (UI) của trang web với những thứ như banner, bố cục, màu sắc, menu (navigation), v.v.. Và rồi sau khi mọi thứ được thống nhất giữa các bên thì trang web được ra mắt, công bố trên các phương tiện truyền thông. Sau đó thì sao? Toàn bộ hệ thống website, phần mềm quản trị nội dung (hay còn gọi là CMS, viết tắt của Content Management System) được bàn giao cho bộ phận vận hành, quản lý nội dung của khách hàng. Đội ngũ phát triển website thì tổ chức ăn mừng và không cần quan tâm tới dự án đó nữa.

3 tháng sau quay lại hỏi thăm khách hàng, đội ngũ làm web phát hiện ra giao diện của website xấu quắc, hình ảnh, nội dung của các bài viết bị xô lệch…

View original post 864 more words

UX is not always fun

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:

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

Tại sao làm UX khó?

(Ảnh minh hoạ UX design, nguồn NN/g)

Làm việc liên quan đến UX khó, hay “UX khó” là câu cửa miệng của rất nhiều người. Từ những người mới tinh trong ngành, mới va chạm với “UI” hoặc UX concepts cho tới những bạn chuyển từ BA, Graphic design sang UX đều thấy nó khó, và thường “phán” luôn rằng UX “rất khó”. Vậy thực hư ra sao? có thật sự đây là một ngành khó không và nó khó tới đâu để bạn theo đuổi? Qua bài viết này, tôi sẽ cố gắng giải thích phần nào để mọi người cùng hiểu rõ.

Tại sao mọi người thường thấy UX khó

Nói về cái “khó” ở một lĩnh vực thì thường do mấy nguyên nhân như sau (theo kinh nghiệm cá nhân mình quan sát mấy năm qua trong các group về UX):

  • Vì tất cả mọi người xung quanh đều “bảo rằng” nó khó.
  • Không có mentor (người hướng dẫn) trong lĩnh vực này ở Việt Nam (hoặc không có nhiều)
  • Không được đào tạo bài bản về những lĩnh vực “liên quan” tới UX. Bạn cần hiểu rằng không có 1 trường lớp nào dạy “chuyên ngành UX”, bởi UX là một công việc và để làm công việc này bạn có thể xuất thân từ nhiều lĩnh vực liên quan.
  • Thị trường Việt Nam vẫn đa phần là các công ty Outsourcing hoặc các Startup không có tiền làm UX. Các tổ chức lớn thì chưa quan tâm tới UX (hoặc thế hệ lãnh đạo chưa hiểu vụ này) do đó những người muốn làm việc liên quan tới UX (VD: như mình chẳng hạn) sẽ có rất ít cơ hội để cọ xát, mà như vậy thì có học mãi cũng không vỡ ra, không giỏi lên được.
  • Hiểu sai từ đầu về UX, Usability, Utility, UI, v.v… Cái này khó trách bởi một phần là không có trường lớp / khoá học nào đào tạo cụ thể, tỉ mỉ những kiến thức này.
  • Không hiểu biết về tiêu chuẩn ngành, vì ở Việt Nam không ai nói về cái đó cũng như không ai đặt ra cái đó trong các dự án liên quan.

Những điều này dẫn tới nhiều “ngộ nhận” và khiến cho các bạn “lầm tưởng” mình đang làm UX, rồi càng đi càng chệch hướng sang “UI” hoặc product managent. Đến những nhà tuyển dụng cũng gộp luôn cái “job title” là “UI/UX” để cho dễ tuyển dụng, kiểu như tôi cũng đang tuyển người làm UX về… để vẽ UI. Cứ thế mọi thứ càng khiến những người muốn làm UX cảm thấy khó khăn, mông lung.

(Nguồn ảnh: Cultivate)

Thế UX có khó thật không?

Câu trả lời là có, nhưng không phải là không làm được nếu bạn được định hướng bài bản. Và những vấn đề “khó” của UX nằm ở nhiều khâu trong qui trình thiết kế và nhiều cấp độ khác nhau bao gồm cả yếu tố tác động bên ngoài. Quan trọng hơn cả, cái khó của UX khi vào dự án là bạn phải chứng minh tính hiệu quả của nó. Ví dụ

  • Các dự án UX được áp dụng ko chỉ với web hoặc mobile app, mà nó có phạm vi rộng ở touch screen, màn hình xe hơi, màn hình máy ATM v.v… Mỗi mảng nó có concepts, constraints riêng, cộng với dữ liệu phân tích audiences/ users, cộng với các design patterns.. từ đó outlight ra các concept & solution.
  • Xuyên suốt chiều dài của một dự án UX, facing & facilitate là kỹ năng bạn sử dụng nhiều nhất bởi mục đích cuối cùng của dự án là sản phẩm “đầu ra” của bạn được thông qua, đáp ứng “tất cả” các bên liên quan. Không qua được khâu này, bạn fail 😦

Cụ thể hơn được không?

Tất nhiên là được, các dự án UX trong thực tế thường có dạng như sau:

  • Bạn và team của bạn chạy 1 dự án UX, sau 2 tháng, facility meeting với chủ đầu tư mà bạn ko thuyết phục được các stakeholders bằng các option/solution bạn đưa ra -> bạn failed.
  • Bạn làm dự án UX, chạy 3 tháng, implement sản phẩm, chạy A/B testing các kiểu nhưng traffic ko tăng, conversion rate giảm, bạn không lý giải được các nguyên nhân chủ quan, khách quan -> bạn failed. Tất nhiên ai cũng hiểu vụ trafic và conversion còn phụ thuộc vào thời điểm trong năm (vd với website mua sắm), tính hiệu quả của marketing campaign, đội ngũ chăm sóc khách hàng, CX process v.v… nhưng dù nhiều hay ít, là người làm UX bạn vẫn có liên quan trong đó. Nên nhớ, tất cả (UX, CX, Communication, Marketing..) đều là 1 team trước mặt khách hàng mà thôi.

Khó thế thì làm thế nào?

Câu trả lời rất rộng nhưng cũng có thể gói gọn trong mấy khái niệm dưới đây:

  • Empathy – bạn phải hiểu người khác ở một mức độ nhất định (toàn bộ stakeholders) và những công cụ như personas, need finding… chính là phục vụ việc này.
  • Communications – vô cùng quan trọng, nó là một kênh / một kỹ năng để truyền tải trong dự án UX (và các dự án trong lĩnh vực khác cũng vậy)
  • Expectation management – kỹ năng này đòi hỏi bạn phải có kinh nghiệm từng trải trong sale, project management, account management mới có thể làm được. Chính vì thế làm dự án UX bạn không thể làm 1 mình (trừ phi dự án nhỏ, thật nhỏ).
  • Solution – giải pháp cho sản phẩm, dịch vụ và nó phải phù hợp với các yếu tố Time – Budget – Business Context (gọi là other tactics)

Đến đây chắc bạn cũng phần nào hình dung được tại sao làm UX nó liên quan tới BA, marketing, digital solution, thậm chí là hardware/devices, hay những kiến thức về project management, process (Lean, Agile, Sprint…)..v.v.. tất cả cũng chỉ hướng đến một mục tiêu nhằm đạt được hiệu quả cao trong các mục tiêu nói trên. Có điều kiện tôi sẽ nói kỹ hơn về các kỹ thuật liên quan của từng khái niệm trên.

Sau cùng, UX luôn đi cùng với strategy, và nó là high-level plan to achieve one or more business goals under conditions. Có nghĩa là thông qua việc xây dựng đội ngũ làm UX, một doanh nghiệp, hoặc một team làm sản phẩm sẽ sử dụng nó (UX) như một phần của chiến lược nhằm mang lại kết quả tốt hơn ở “nhiều khâu” khác nhau trong quá trình vận hành sản phẩm hoặc business của doanh nghiệp đó. Đừng chỉ nhìn ở góc độ UI của website hoặc UI của mobile app. UX rộng hơn thế.

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

Bình Trương.

Treat the client like 2-year-old child

(Mang lại cho khách hàng những thứ đơn giản, dễ hiểu)

Capture

(Hình 1: user’s guessing. Nguồn: www.satukyrolainen.com)

Làm việc trong lĩnh vực digital production  mà cụ thể hơn là offshore development hay outsourcing thì communication is the key. Mỗi dự án từ lúc lên ý tưởng, cho tới lúc bàn giao sản phẩm cho khách hàng luôn cần giao tiếp liên tục để chắc chắn rằng các bên tham gia hiểu ý nhau. Nghe thì đơn giản, nhưng đây luôn là nguồn gốc của mọi vấn đề. Mà thường là các bên không hiểu nhau. Users không hiểu phần mềm, nghiệp vụ (business process) dẫn đến bực tức và “ghét” phần mềm một cách tự nhiên. Lâu này thành định kiến là “phần mềm khó sử dụng”.

Case study: How to test?

 UX xuất hiện khắp mọi nơi, và nói một cách đơn giản là một người có UX mindset sẽ chú trọng vào bất cứ thứ gì mình đưa ra (kể cả là lời nói – UX có dính tới psychology cũng 1 phần là như vậy). Câu truyện của sáng nay rất đơn giản và phổ biến, nhưng tôi ấn tượng với câu nói của boss. Nôm na là như sau:

  • Boss: Khách hàng muốn test toàn bộ qui trình đăng ký, thanh toán credit card mà ko bị charge phí, nhận email confirmation. Mình có cung cấp được chưa?
  • PM (Project Manager): Mình đã làm 1 tools migrate khách hàng cũ, với khách hàng mới thì không cần lo vì hệ thống tự generate confirmation code, khách hàng cũ chạy tools, ngoài ra cần migrate data demo sang server staging, làm sạch dữ liệu test, by pass thẻ visa…
  • Boss: I don’t fucking care. Please treat me like 2-year-old child. Client even likes 1-year-old child. I don’t know and don’t understand whatever you do behind the scenes.
  • PM: Chúng ta sẽ cung cấp sandbox để test, migrate dữ liệu cần khách hàng confirm migrate những gì, blah blah..
  • Boss: Những thứ đằng sau đó không cần giải thích với người dùng, đưa cho họ cái họ cần để test được hệ thống như một người dùng cuối (end-user).

Cá nhân mình thấy hợp lý. Bởi đơn giản những thứ kỹ thuật, thiết kế.v.v… là việc của mình, khách hàng thuê mình vì điều đó, còn với họ, họ cần tiếp cận với sản phẩm như một đứa trẻ, tiếp cận và học hỏi, test một cách dễ dàng nhất. Điều muốn nói ở đây là giao tiếp. Communication is the key in UX. Lắng nghe, rồi hiểu đúng cái mà khách hàng cần, đưa cho họ thông tin/câu trả lời đơn giản và dễ hiểu nhất. Họ không quan tâm bạn là ai, thương hiệu của bạn là gì? bạn sử dụng công nghệ gì? All bullshit things. Cái họ cần là vấn đề của họ được giải quyế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 🙂