Buổi 1 — PM cần biết gì về UX (và không cần biết gì)
Khoá này không dạy bạn thiết kế. Nó dạy bạn làm việc với thiết kế — và biết khi nào một thiết kế đang có vấn đề trước khi nó tới tay người dùng.
Ranh giới vai trò
Designer sở hữu giải pháp thiết kế. Cách bố trí, luồng tương tác, hệ thống thị giác. PM không nên đưa wireframe rồi bảo "làm theo cái này" — đó là lấy mất phần việc mà họ giỏi hơn bạn.
PM sở hữu vấn đề và ràng buộc. Người dùng nào, họ đang cố làm gì, thành công đo bằng gì, ràng buộc kỹ thuật và thời gian ra sao.
Ranh giới này bị vi phạm theo cả hai chiều. PM vẽ giao diện thì designer trở thành người tô màu. Designer quyết định phạm vi thì sản phẩm mất định hướng thương mại.
Ba thứ PM phải biết
Usability không phải thẩm mỹ. Một giao diện đẹp có thể rất khó dùng, và ngược lại. Khi bạn nói "tôi không thích cái này", hãy dừng lại và hỏi: mình đang nói về sở thích thị giác hay về khả năng hoàn thành công việc?
Trạng thái quan trọng hơn màn hình. Mockup vẽ trạng thái đẹp nhất: có dữ liệu, mọi thứ thành công. Sản phẩm thật sống phần lớn thời gian ở trạng thái rỗng, đang tải, và lỗi. PM là người phải hỏi về ba trạng thái đó.
Mỗi lựa chọn thêm vào là một chi phí. Thêm một tuỳ chọn nghe có vẻ vô hại, nhưng nó làm chậm mọi người dùng phải đọc qua nó. Sản phẩm phức tạp hiếm khi do một quyết định lớn — nó là kết quả của trăm quyết định nhỏ tưởng như miễn phí.
Ba thứ PM không cần biết
Bạn không cần biết dùng Figma thành thạo, không cần biết lý thuyết màu, không cần tranh luận về khoảng cách 4px hay 8px. Can thiệp vào những thứ này làm mất thời gian và làm hỏng quan hệ.
Cách phản hồi thiết kế cho đúng
Phản hồi kém: "Tôi thấy nút này nên to hơn." Phản hồi tốt: "Trong dữ liệu, 40% người dùng không tìm thấy chức năng này. Có cách nào làm nó dễ phát hiện hơn không?"
Cái đầu áp đặt giải pháp. Cái sau nêu vấn đề và để designer làm việc của họ — họ thường nghĩ ra phương án tốt hơn cái bạn định đề xuất.
Nguyên tắc: PM nói về vấn đề và mục tiêu, designer nói về giải pháp.
Bài tập
Lấy phản hồi thiết kế gần nhất bạn đưa ra. Viết lại nó dưới dạng vấn đề kèm bằng chứng thay vì dưới dạng giải pháp.
<!--les-append-->
Ba câu nói làm hỏng quan hệ với designer
| Câu | Vấn đề | Nói thay bằng |
|---|---|---|
| "Làm theo cái này nhé" (kèm wireframe) | Biến designer thành người tô màu | "Đây là vấn đề và ràng buộc — em hình dung thế nào?" |
| "Tôi không thích cái này" | Sở thích cá nhân đội lốt phản hồi | "Người dùng ở bước này đang cố làm gì? Cái này giúp họ ra sao?" |
| "Làm cho nó đẹp hơn" | Không hành động được | "Màn hình này đang có 4 thứ cạnh tranh sự chú ý — cái nào quan trọng nhất?" |
Ba câu hỏi PM nên hỏi ở mọi bản thiết kế
- "Việc chính trên màn hình này là gì?" Nếu designer kể ra ba việc, màn hình đang phục vụ nhiều mục đích cùng lúc.
- "Người dùng đến đây từ đâu, và đi đâu tiếp?" Màn hình đẹp trong một luồng sai vẫn là sản phẩm tệ.
- "Chưa có dữ liệu thì trông thế nào?" (Xem buổi 2.)
Khi bạn và designer bất đồng
Phân định theo loại bất đồng, không theo ai nói to hơn:
| Bất đồng về | Ai quyết | Nguyên tắc |
|---|---|---|
| Trải nghiệm, bố cục, luồng | Designer | Nếu có dữ liệu người dùng thì dữ liệu thắng |
| Phạm vi, ưu tiên, thời hạn | PM | Designer nêu chi phí, PM quyết đánh đổi |
| "Đẹp hay không" | Không ai | Đây không phải câu hỏi quyết định được; đổi sang câu hỏi về mục tiêu |
Thứ PM KHÔNG cần biết
Để rõ ranh giới theo chiều còn lại — bạn không cần biết:
- Cách dùng công cụ thiết kế
- Lý thuyết màu sắc, hệ thống lưới, cách chọn phông chữ
- Cách vẽ wireframe (và nếu bạn vẽ, hãy vẽ xấu có chủ đích để không ai tưởng đó là thiết kế cuối)
Làm ngay
Trong buổi duyệt thiết kế tiếp theo, đừng đưa ý kiến nào trong 10 phút đầu. Chỉ hỏi ba câu ở trên. Quan sát xem cuộc trò chuyện đi theo hướng khác thế nào. <!--/les-append-->