Buổi 8 — Đưa UX vào quy trình sản phẩm

Biết về UX không đủ. Phần khó là làm cho nó xảy ra đều đặn khi lịch gấp và ai cũng bận.

Ba điểm chèn vào quy trình

Trước khi viết PRD — nghiên cứu. Dù chỉ là ba cuộc trò chuyện với người dùng. Viết yêu cầu mà chưa nói chuyện với ai là viết dựa trên giả định.

Trong lúc thiết kế — phản hồi sớm và thường xuyên. Xem bản phác thảo giấy tốt hơn xem bản hoàn thiện: khi thiết kế còn thô, mọi người còn dám phản biện. Bản đẹp tạo cảm giác đã xong và ức chế góp ý.

Trước khi ship — kiểm chứng. Một buổi usability test với năm người, hoặc chí ít là bốn kiểm tra accessibility và rà soát bốn trạng thái màn hình.

Đưa vào Definition of Done

Cách bền vững nhất là biến nó thành checklist chứ không dựa vào ý chí:

• Bốn trạng thái màn hình đã được thiết kế (rỗng, đang tải, lỗi, có dữ liệu)
• Luồng lỗi và luồng quay lại đã mô tả
• Kiểm tra tương phản và vùng bấm đã chạy
• Đã dùng thử trên điện thoại thật với mạng chậm

Checklist không đảm bảo chất lượng, nhưng nó ngăn được việc quên — và quên là nguyên nhân của phần lớn lỗi trải nghiệm.

Khi lịch gấp

Sẽ có lúc phải cắt. Thứ tự cắt hợp lý:

Cắt được: đánh bóng thị giác, hoạt ảnh, biến thể cho trường hợp hiếm. Không nên cắt: trạng thái lỗi, giữ dữ liệu người dùng, luồng chính trên mobile.

Cắt nhầm nhóm thứ hai tạo ra thứ trông ổn trong demo và hỏng trong thực tế.

Đo trải nghiệm

Ba nhóm chỉ số:

Hành vi — tỉ lệ hoàn thành nhiệm vụ, thời gian hoàn thành, số lần thử lại. Đây là nhóm đáng tin nhất.

Vận hành — số ticket support theo màn hình, tỉ lệ lỗi. Rẻ nhất để thu thập và thường bị bỏ qua.

Chủ quan — SUS, CSAT. Có giá trị khi so sánh theo thời gian, không có giá trị khi đứng một mình.

Nhóm thứ hai đặc biệt hữu ích cho PM: nếu một màn hình sinh ra nhiều ticket bất thường, đó là bằng chứng khách quan để đưa vào ưu tiên.

Xây quan hệ với designer

Ba việc tạo khác biệt lớn nhất:

Chia sẻ bối cảnh sớm, không chỉ giao yêu cầu. Designer hiểu vấn đề sẽ đề xuất phương án bạn không nghĩ tới.

Cho họ tiếp xúc người dùng. Designer chỉ nhận yêu cầu qua PM sẽ thiết kế theo cách hiểu của bạn, kể cả khi bạn hiểu sai.

Nói về vấn đề, không nói về giải pháp. Đã nhắc ở buổi 1, và đáng nhắc lại vì đây là thói quen khó bỏ nhất.

Kết

PM không cần trở thành designer. Nhưng PM là người quyết định có đủ thời gian để làm đúng hay không, và là người hỏi những câu mà mockup không trả lời.

Hai việc đó ảnh hưởng tới trải nghiệm cuối cùng nhiều hơn bất kỳ kỹ năng thiết kế nào bạn có thể học được.

Bài tập

Thêm checklist bốn mục ở trên vào Definition of Done của team. Chạy hai sprint rồi xem lại: bao nhiêu vấn đề đã được bắt trước khi tới tay người dùng.

<!--les-append-->

Bắt đầu từ một thứ, không phải tất cả

Đưa cả tám buổi vào quy trình cùng lúc là cách chắc chắn để không thứ nào sống sót. Chọn một việc và làm đều trong một quý.

Thứ tự đề xuất theo lợi tức trên công sức:

Vì sao việc số 4 khó nhất

Khi thiết kế còn thô, mọi người dám phản biện. Khi nó đã đẹp, người ta ngại — bản đẹp tạo cảm giác đã xong.

Nhưng designer thường muốn trình bày bản hoàn chỉnh, vì bản thô trông như chưa làm việc. Đây là vấn đề văn hoá, không phải vấn đề quy trình. Cách duy nhất chữa được: người dẫn dắt phải công khai khen một bản phác thảo thô, vài lần, cho tới khi cả đội tin rằng nó an toàn.

Khi lịch gấp

Đây là lúc mọi thứ trong khoá này bị cắt đầu tiên. Nếu chỉ giữ được một thứ, giữ bốn trạng thái màn hình — nó tốn ít nhất và ngăn được nhiều lỗi nhất.

Và ghi lại thứ bị cắt. Nợ không được ghi là nợ không ai trả.

Đo xem có tác dụng không

Chỉ số thứ ba là chỉ số tốt nhất và có sẵn trong dữ liệu của bạn.

Làm ngay

Chọn một việc trong bảng ưu tiên và đưa nó vào Definition of Done của đội trong tuần này. Một việc, làm đều trong một quý — tốt hơn tám việc làm được hai tuần. <!--/les-append-->