VR/AR Design

14/03/2017

Cách đây mấy tháng tôi có may mắn được tham dự một dự án (nhỏ) về VR, tuy nhỏ nhưng cũng đủ để được tiếp thu khá nhiều kiến thức (và cũng đủ để biết còn một tỉ loại kiến thức khác mà mình còn chưa biết).

Hôm rồi tôi có một bài present ngắn trong một meetup về product design ở Sydney. Đại ý vầy:

Công việc UI Design trong tương lai sẽ thay đổi nhiều.

Lý do chính là những gì mà chúng ta đang thiết kế hiện tại sẽ được đám chatbot (FB messenger, Google assistant,…) và mấy em virtual assistant (Siri, Cortana, Alexa,…) xử lý hết. Trong tương lai những interface truyền thống sẽ không còn cần để thực hiện một tác vụ cụ thể nào đó nữa, user chỉ cần chat hoặc nói chuyện trực tiếp với máy để thực hiện tác vụ.

Vì vậy, UX Designers có thể sẽ vẫn sống tốt, không lo chết đói. Tuy nhiên UI Designers thì nhiều khả năng sẽ tiến hoá thành VR/AR Designers.

VR là thực tế ảo, AR không biết dịch ra tiếng Việt như thế nào cho hay, nôm na là “thực tế tăng cường”, trong đó UI Design đóng vai trò rất quan trọng.

  • Design cho AR, đặc biệt là VR là một trời kiến thức mới. Những kiến thức này lại hoàn toàn khác với những gì mà UI Design truyền thống đã quen thuộc. Vài cái tên mà chúng ta sẽ nghe nhiều trong các buổi thảo luận về VR Design như: orientation tracking, 6DOF, physiological comfort, environment comfort…
  • Có nhiều kiến thức đến từ những lĩnh vực (không mấy) liên quan, ví dụ nhiếp ảnh (depth of field), 3D modelling (UV mapping, mental ray, vortex,…) hoặc motion design.
  • Concept thiết kế cũng khác. Ví dụ đơn giản: UI Designer hiện tại thì cái gì cũng có boundary (artboard, grid system,…) trong khi đó thì VR Design là non boundary design, nên từ đó mỗi UI element đều phải có xuất hiện và biến mất như thế nào, ở thời điểm nào.
  • VR/AR design phải để ý đến những vấn đề hoàn toàn mới. Ví dụ: motion sickness (say sóng), claustrophobia/agoraphobia,…
  • Audio, thứ mà trước đây với interface truyền thống không mấy quan trọng, nay bỗng nhiên là một phần không thể thiếu.
  • Các công cụ để design và dựng prototype cũng khác.
  • Cách phối hợp giữa team design và team kỹ thuật cũng khác.

Đây là một lĩnh vực mới, và nhiều khả năng sẽ trở thành main stream trong tương lai gần. Mỗi lần mình cùng bạn bè nói chuyện về chủ đề này, ai cũng cùng một câu nói: “Sao tự nhiên thấy mình lạc hậu quá xá!”.

Anh sáu Lê Nin đã nói: “Học, học nữa, học mãi.”

• • •

Ps, Sketch và XD

13/03/2017

Một report rất thú vị! Những ai đang làm về UI Design rất nên đọc [download tại đây].
Nói thêm về Ps và Sketchapp

Cá nhân tôi từ 4-5 năm gần đây đã hoàn toàn chuyển sang Sketch và hoàn toàn không còn dùng Ps cho UI Design nữa. Dù trước đó tôi là một fan cuồng của Ps do đã sử dụng Ps từ thời Ps 4.0 cách đây hơn 20 năm (nghe 20 năm mà hết cả hồn, mình già dữ trời!).

Tuy nhiên Sketch có điểm hạn chế là không chạy cross platform được giữa 2 Win và Mac. Điều tưởng nhỏ nhưng nhiều lần lại là “pain in the ass” khi một dự án cần phải phối hợp với các team khác ngoài công ty / hoặc cùng công ty nhưng khác team (design và dev chẳng hạn) / hoặc thậm chí cùng team nhưng có đứa nào đó lên đồng mà dùng Win.

Adobe XD hứa hẹn giải quyết được vấn đề này. Gần đây thì các bạn bè xung quanh cũng có vài người đã bắt đầu rục rịch chuyển từ Sketch sang XD.

Tuy nhiên sau vài lần thử với một vài dự án thì tôi quyết định vẫn tiếp tục với Sketch một thời gian nữa. Lý do là XD vẫn còn thiếu một vài tính năng nhỏ làm cho việc sử dụng hàng ngày hơi bị khó chịu (các core features quan trọng thì đã đủ để XD làm bất kỳ dự án nào). Lý do thứ 2 là desin community của XD vẫn chưa đông và sôi động như Sketch, dẫn đến việc chia sẻ các kinh nghiệm và tài nguyên bị hạn chế hơn.

Nhưng chắc chắn rồi Adobe sẽ sớm khắc phục những vấn đề này và… “đứa con xưa lại tìm về nhà”.

• • •

Xây dựng Customer Journey Map – Phần 4

15/06/2016

Bước 5: User Workshop – Hypotheses validation

Tái thẩm định hypotheses với khách hàng để rút ra sự hiểu biết sâu hơn về những vấn đề (issues) và nhu cầu của họ (user needs).

Việc validation này được thực hiện thông qua một User Workshop. Mục đích của workshop này là mời những người dùng thực tế đến, giải thích sơ bộ cho họ về Hypotheses CJM và nhờ họ tái thẩm định lại CJM này.

IMG_0027

Có nhiều điều cần lưu ý về việc tổ chức và triển khai workshop kiểu này. Ở đây mình chỉ nói một cách đơn giản và khái quát vài điểm quan trọng:

  • Số lượng user tham gia: 10 – 15 (không nên nhiều hơn con số này)
  • Nên có thêm một số đại diện của các bộ phận khác trong công ty, ví dụ: giao nhận, marketing, customer support,… Họ có thể cùng tham gia hoặc đóng vai trò quan sát cũng được, nhưng nên có.
  • Nên chia những người tham dự thành một số nhóm nhỏ tầm 4-6 người/nhóm.
  • Warm up bằng một số hoạt động như self-introduction, user story telling,…
  • Có một bước gọi là (In)validating assumption, cách tiến hành: in hypotheses CJM ra thành nhiều bản lớn (2-3m), dẫn dắt họ qua những assumptions của chúng ta. Từ đó nhờ họ điều chỉnh lại những bước (stages), những kỳ vọng (expectations) và trải nghiệm (emotions) của họ qua từng bước. Nhờ họ đánh dấu những điều đó lên HJM, cứ vậy hết nhóm này đến nhóm khác (do đó cần in CJM ra nhiều bản).
  • Những thông tin cần phải uncover trong workshop này bao gồm:
    • Loại hành động (Actions);
    • Touch point (phương tiện để thực hiện hành động đó, vd: điện thoại, laptop, call center, sales agent,…);
    • Nhận thức (perception);
    • Suy nghĩ (thoughts);
    • Cảm xúc (emotions) của họ trong khi tiến hành từng bước;
  • Hoạt động tiếp theo cần làm là facilitate để họ cùng nhau xây dựng lên một CJM hoàn hảo theo suy nghĩ của họ.
  • Trong một số trường hợp, có thể tiến hành cho họ vẽ thử một số prototype, tất nhiên prototype này không dùng để đưa cho development team mà thông qua đó chúng ta sẽ thấy được những ý tưởng của họ (đôi khi rất kỳ quặc) và từ đó hiểu rõ hơn họ muốn gì.
  • Cuối ngày sẽ là users chia sẻ về những gì họ đã làm, những pain points quan trọng đối với họ,… với toàn bộ mọi người và sau đó cùng nhau thảo luận.
  • Debrief: Sau buổi workshop này UX Designer và các stakeholder nên có một buổi debrief ngắn để xác định những điểm quan trọng đã được uncover trong buổi workshop.
• • •

Xây dựng Customer Journey Map – Phần 3

15/06/2016

Bước 3: User Experience Research

Bước này sẽ dùng những kỹ thuật chuyên cho UX research như:

  • Customer Interview (thường gọi là CI): phỏng vấn người dùng, chi tiết tiến hành CI như thế nào thì các bạn tự tìm hiểu trên mạng, có dịp mình sẽ nói chi tiết hơn trong một bài khác. Lưu ý là cái này khác với market research nhé.
  • Field observation (thường gọi là Shadowing): đến trực tiếp hiện trường để quan sát hành vi của khách hàng.
  • Empathy mapping (tự tìm hiểu qua cùng keyword).
• • •

Xây dựng Customer Journey Map – Phần 2

11/06/2016

Để bắt đầu, thường thì nếu điều kiện cho phép, mình sẽ yêu cầu setup một phòng riêng gọi là war room (keyword: “ux war room”). Trong đó in ra tất cả những thông tin có được đính lên tường, đây sẽ là nơi để trao đổi giữa mình với product owner và các stakeholders, có một nơi như thế này cũng sẽ tiện cho bất kỳ ai/bất kỳ lúc nào cũng có thể vô brainstorm mà không tốn thời gian setup lại.

Một cái war room sẽ trông như vầy:

warroom

Nếu để ý bạn sẽ thấy làm UX đa số dùng những cách làm “thô sơ”. Tụi mình đã thử đủ thứ ứng dụng, phần mềm,… cuối cùng thì những cách làm “thô sơ” này vẫn luôn hiệu quả nhất (đọc thêm ở đây). Ưu điểm lớn nhất của cách làm này là tính trực quan, bên cạnh đó các stakeholders và users ai cũng có thể tham gia được dễ dàng, không lệ thuộc vào công nghệ.

Như đã nói ở bài trước, cách mình viết sẽ là gợi mở vấn đề, đưa ra những keyword để các bạn tự tìm hiểu và nghiên cứu thêm. Từ đó chọn ra cách làm phù hợp với bản thân và công ty của mình. Mình sẽ không đưa ra template hay kết quả mẫu. Đó cũng là cách để các bạn xây dựng riêng style làm UX cho mình.

• • •

Xây dựng Customer Journey Map

10/06/2016

Lại kể chuyện tiếp về thời gian đi làm consultant.

Đa số trường hợp, khi khách hàng đã bắt đầu cần đến consultant nghĩa là họ đang đối mặt với những vấn đề mà nguồn lực bên trong công ty không tìm ra được giải pháp. Do đó họ mới cần đến một nguồn lực bên ngoài vào giúp họ. Vậy làm thế nào mà tụi mình – những người ất ơ từ đâu đến – lại có thể giúp họ tìm ra giải pháp? (trong khi họ là những người làm việc sát cánh ở công ty trong thời gian dài – là người có nhiều insight nhất – còn chưa tìm ra được giải pháp).

Bài này mình sẽ chia sẻ một trong những kỹ thuật mà tụi mình dùng rất nhiều (và cũng thường tư vấn khách hàng tiến hành nhất). Đó là Customer Journey Map.

Loạt bài này sẽ hơi dài (dù mình đã cố viết ngắn nhất có thể) và thuộc dạng hơi nâng cao một chút, nên những ai chưa biết về khái niệm UX Design có thể đọc thêm bài tổng quan ở link này. Ai muốn hiểu hơn chút xíu về công việc UX consultant có thể đọc thêm ở đây.

Như thường lệ bài viết sẽ dùng nhiều từ tiếng Anh, không phải vì “chảnh” (dù bình thường mình cũng chảnh), mà do có 2 lý do chính:

  • Các từ đó sẽ là keyword cho các bạn dùng để nghiên cứu sâu hơn.
  • Cho tiện viết bài, vì một số từ dịch ra tiếng Việt nghe rất kỳ.

• • •

Less is more

09/06/2016

Có câu chuyện nho nhỏ về việc viết email.

Thời gian làm consultant, mình có làm việc onsite ở một công ty khách hàng. Ở đó mình làm việc cùng với một bạn Head of CX (Customer Experience). Tuy chỉ trong thời gian ngắn nhưng mình học được khá nhiều cách làm việc và tư duy của bạn.

Có một chi tiết mình vẫn nhớ.

Trong mọi giao tiếp, đặc biệt là bằng email, bạn thường viết rất ngắn gọn, đi thẳng vào ý chính, hầu hết là dùng bullet points. Có vài lần (chính xác là 2 lần) bạn gửi cho mình email khá dài. Và mình để ý cả 2 lần, ở cuối email bạn đều kèm theo dưới email một dòng: “Xin lỗi tao viết email này hơi dài, nếu có thời gian tao hẵn đã viết nó ngắn hơn”.

Hôm sau gặp bạn, mình hỏi: “Sao mày lại xin lỗi?”

Bạn trả lời như sau: “Một email dài sẽ làm người đọc bực mình khi nhận, mệt mỏi khi đọc, mất thời gian khi xử lý để nắm được ý mình muốn gì. → Viết một email ngắn mà vẫn truyền tải đủ ý sẽ làm cho người đọc có một trải nghiệm tốt hơn. → Nhưng viết ngắn cần phải có thời gian để optimize. → Và mấy lần viết dài cho mày là những lần tao đang gấp không có thời gian optimize. Nên tao có thói quen mỗi khi viết dài thì tao xin lỗi”.

“Less is more” – rule cơ bản nhất của UX – được bạn áp dụng vào cả việc viết email. Không quá khó hiểu khi bạn nắm toàn bộ mảng CX của một trong những công ty lớn nhất ở Úc.

• • •

Các thiết bị chuyên dụng cho UX, cần hay không?

12/05/2016

Có nhiều công ty quan niệm rằng đầu tư cho UX rất tốn kém, trong đó một phần không nhỏ là đầu tư vào các thiết bị, phòng óc, máy móc chuyên dụng. Vậy những thiết bị này có thực sự cần thiết không? Liệu rằng phải có thiết bị thì mới triển khai được?

Câu trả lời ngắn gọn là: Không!

Câu trả lời dài dòng là:

• • •

Quy trình tuyển dụng một UX Designer

28/04/2016

Hồi đầu năm nay mình lead một dự án nhằm xây dựng lại quy trình tuyển dụng cho team Product Design ở công ty. Để có được quy trình này, mình và công ty đã tốn rất nhiều thời gian tham khảo các quy trình tuyển dụng từ các công ty lớn khác ở Úc và Mỹ + kết hợp với tình hình thực tế của công ty + tư vấn từ các chuyên gia trong ngành và chuyên gia tuyển dụng (có thuê hẳn một consultancy để tư vấn).

Quy trình này thoạt trông thì có vẻ hơi dài tuy nhiên nếu so với các công ty lớn khác ở Úc thì cũng thuộc dạng trung bình. Khi thăm dò phản hồi của các ứng viên thì đa số cũng phản hồi là không quá dài.

Bài bên dưới là dành cho công việc UX Design, các vị trí khác như UX Researcher hay Visual Designer cũng tương tự, chỉ khác bài test cà cách tiến hành Onsite Interview.

Chia sẻ lại cho những ai quan tâm.

• • •

Check out process

14/01/2016

Khá nhiều website thương mại điện tử vẫn đang thiết kế những process check out kiểu như vầy:

• • •