UX8 NOV, 202611 phút đọc

Dùng AI mà vẫn giữ được sự tín nhiệm: góc nhìn từ designer

Dùng AI mà vẫn giữ được sự tín nhiệm: góc nhìn từ designer

Mấy hôm trước mình đọc bài “Đừng để AI làm mất sự tín nhiệm của bạn trong công việc” của anh Hoàng Nguyễn trên cộng đồng MindYourMind. Anh kể chuyện một ứng viên Product Owner nộp bài test gần như toàn bộ do AI viết, rồi trong buổi trình bày lại tiếp tục dùng AI để trả lời câu hỏi. Buổi test dừng sau hai câu hỏi.

Đọc xong mình nhận ra chuyện này không chỉ xảy ra với PO. Ở vị trí designer, mình cũng đã gặp, và cũng từng nhận tài liệu từ các bên liên quan (stakeholder) có cùng vấn đề. Bài trước mình viết về việc AI có đang khiến designer lười suy nghĩ, tức là chuyện bên trong mỗi người. Bài này nói về hệ quả ra bên ngoài: người khác nhìn vào sản phẩm của mình và quyết định có tin mình hay không.

Bài test đẹp, nhưng hai câu hỏi là đủ

Mình từng xem qua bài test của một ứng viên designer. Đề bài là cải thiện màn hình thanh toán của một app mua sắm. Bài nộp rất đẹp: có phần vấn đề, có insight người dùng và năm đề xuất cải tiến. Đề xuất số một là “tối ưu hành trình thanh toán để giảm ma sát cho người dùng”.

Khi trình bày, mình hỏi một câu đơn giản: “Ma sát nằm ở bước nào? Người dùng đang bị kẹt ở đâu?”. Bạn ấy đọc lại câu trên slide theo một cách khác, nhưng không chỉ ra được bước nào. Mình hỏi tiếp: “Nếu chỉ được làm một việc, bạn chọn việc gì và bỏ việc gì?”. Bạn ấy cũng không trả lời được, vì năm đề xuất đó do AI liệt kê, chưa đề xuất nào được bạn tự cân nhắc.

Một câu trả lời thuyết phục hơn có thể rất đơn giản: “Ở bước nhập địa chỉ, form có 9 ô. Mình nhờ 3 người bạn điền thử thì cả 3 đều dừng lại ở ô mã bưu chính. Mình đề xuất bỏ ô đó trước.” Không cần câu chữ hay, chỉ cần cho thấy bạn đã tự nhìn vào vấn đề.

Mình không nghĩ bạn ấy kém. Chỉ là bài test không nhằm xem bạn làm ra tài liệu đẹp đến đâu, mà để xem bạn suy nghĩ thế nào khi gặp một vấn đề.

Designer mất điểm ở ba chỗ

Theo mình, có ba chỗ AI dễ làm designer mất điểm nhất, vì đó là ba chỗ người khác đánh giá cách mình nghĩ.

Khi giải thích quyết định thiết kế

Một quyết định thiết kế đứng vững khi trả lời được ba câu: vấn đề là gì, mình đánh đổi gì, và đo bằng cách nào. AI viết rất nhanh những câu như “tối ưu hành trình người dùng” hay “nâng tầm trải nghiệm trực quan”. Chúng không sai, nhưng cũng không nói gì cụ thể, nên chỉ cần một câu “vì sao” là lộ.

Hai slide trình bày cùng một đề xuất cho trang chủ app năng lượng mặt trời: một slide chung chung và một slide có vấn đề, đánh đổi, cách đo
Cùng một đề xuất, hai cách trình bày. Mockup, số liệu và nội dung đã được thay đổi để bảo mật dự án.

Bài B không dài hơn bài A. Nó chỉ có những thứ mà người làm phải tự đi tìm: 5 trên 8 người thử phải cuộn mới thấy mức pin, thẻ thời tiết sẽ phải nhường chỗ, và sau khi ra mắt sẽ đo bằng thời gian tìm mức pin. AI có thể giúp mình trình bày ba ý đó gọn hơn, nhưng không thể tự nghĩ ra chúng thay mình.

Khi viết UX copy

Đây là chỗ “giọng AI” lộ rõ nhất, vì người dùng cuối đọc nó mỗi ngày. Những câu dài, nhiều mệnh đề, có cụm như “hành trình”, “liền mạch”, “tối ưu” và cấu trúc như dịch thẳng từ tiếng Anh. Anh Hoàng Nguyễn cũng nhắc đến những cách diễn đạt mà trước khi AI phổ biến, anh gần như chưa thấy người Việt dùng trong công việc.

Thẻ Ảnh hưởng thời tiết trong app năng lượng mặt trời, bản AI viết dài và chung chung, bản sửa lại ngắn và nói rõ điều sẽ xảy ra
Thẻ AI insight trước và sau khi sửa. Mockup, tên sản phẩm, số liệu và nội dung đã được thay đổi để bảo mật dự án.

Nielsen Norman Group cũng nói rằng bản nháp do AI viết thường thiên về câu chữ chung chung, dễ lệch khỏi giọng thương hiệu và không biết gì về người dùng hay bối cảnh của sản phẩm. Lời khuyên của họ là xem AI như người cùng viết bản nháp đầu, rồi luôn có người đọc lại trước khi đưa lên sản phẩm. Bản sửa ở hình trên không cần văn hay. Nó chỉ cần trả lời được điều người dùng muốn biết: hôm nay có ảnh hưởng gì đến mình không.

Khi viết case study và portfolio

Case study là nơi người tuyển dụng tìm hiểu cách bạn làm việc. Một case study viết bằng AI thường có đủ các mục: bối cảnh, vấn đề, quy trình, kết quả. Nhưng đọc kỹ thì không thấy bạn ở đâu trong đó. Không có lúc nào bạn sai, không có quyết định nào khó, không có chi tiết nào chỉ người trong dự án mới biết.

Người đọc case study nhiều sẽ nhận ra rất nhanh. Và giống như ví dụ ở trên, họ sẽ kiểm chứng lại trong buổi phỏng vấn.

Với stakeholder: thiếu một edge case là flow rối

Với những tài liệu đi qua nhiều bên trong dự án, vấn đề thường không nằm ở câu chữ mà ở những gì không được viết ra. Mình từng nhận một tài liệu yêu cầu trông rất đầy đủ: có mục tiêu, user story, tiêu chí chấp nhận. Nhưng các trường hợp ngoại lệ gần như không có: mất mạng giữa chừng thì sao, dữ liệu trống thì hiển thị gì, người dùng quay lại giữa luồng thì bắt đầu từ đâu.

Khi thiết kế và phát triển bắt đầu, những câu hỏi đó lần lượt xuất hiện. Mỗi người tự đoán một kiểu, flow bắt đầu rối, rồi phải quay lại họp để thống nhất. Thời gian mà tài liệu đó tiết kiệm được cho người viết đã chuyển sang cho cả đội phải bù lại.

Có lần khác, các tiêu chí chấp nhận (AC) được AI viết riêng cho từng user story, và người viết không tự đặt chúng cạnh nhau để so lại. Từng AC đọc riêng thì hợp lý, nhưng ghép lại thì có cặp mâu thuẫn nhau: một AC yêu cầu tự lưu nháp khi thoát, một AC khác lại yêu cầu xóa dữ liệu khi thoát. Đội dev làm đúng từng AC, và flow vẫn sai.

Cũng có lúc cả đội dùng AI để dựng thẳng giao diện cho nhanh, và bản đó được đưa lên chạy thật. Từng màn hình riêng lẻ trông đều ổn. Nhưng khi design system của đội chưa đủ chặt, mỗi màn hình AI tạo ra lại tự chọn màu, khoảng cách và component theo một kiểu riêng. Ghép lại thành cả platform thì các màn hình không còn nói cùng một ngôn ngữ. Cuối cùng, designer phải lấy chính bản live đó làm điểm xuất phát, mang ngược về Figma để rà và chỉnh lại cho đồng bộ. Thời gian tiết kiệm được lúc dựng nhanh lại phải trả ở bước sửa về sau. Điều mình rút ra là AI chỉ dựng nhanh và đúng khi design system đủ rõ để nó bám theo. Nếu nền móng chưa vững, AI chỉ khiến những chỗ lệch nhau xuất hiện nhanh hơn.

Nhóm nghiên cứu của BetterUp Labs và Stanford Social Media Lab gọi kiểu sản phẩm này là “workslop”: nội dung do AI tạo, trông như một kết quả tốt nhưng không đủ thực chất để giúp công việc tiến lên. Trong khảo sát của họ, khoảng 40% người đi làm cho biết đã nhận được workslop trong tháng gần nhất, và trung bình mất gần hai giờ để xử lý mỗi lần. Điều đáng chú ý hơn là khoảng một nửa số người nhận đánh giá người gửi kém sáng tạo, kém năng lực và kém đáng tin hơn.

Không ai nói, nhưng người ta nhớ

Phần mình thấy đúng nhất trong bài của anh Hoàng Nguyễn là sự tín nhiệm không mất đi trong một lần. Người nhận vẫn cảm ơn, vẫn dùng tài liệu, có khi còn không yêu cầu sửa. Nhưng lần sau có một việc khó, họ sẽ nghĩ đến người khác trước.

Hình động: ba tài liệu viết bằng AI lần lượt được gửi đến leader, lần nào cũng nhận lời cảm ơn nhưng mức tín nhiệm giảm dần, và việc quan trọng tiếp theo được giao cho đồng nghiệp khác.
Tài liệu nào gửi đi cũng nhận được lời cảm ơn, nhưng mức tín nhiệm thì không hiện lên ở đâu cả.

Với designer, điều đó có thể là không được mời vào buổi định hướng sản phẩm, hoặc đề xuất của mình phải qua thêm một vòng kiểm tra. Không có thông báo nào cho mình biết chuyện đó đã bắt đầu.

Dùng AI sao cho người khác vẫn tin mình

Nói thật, chính website bạn đang đọc cũng được mình làm cùng AI theo kiểu vibe coding. Mình dùng nó để có một chỗ trình bày dự án và ghi chép của mình, chứ không phải để bán dịch vụ làm web hay để cho thấy mình biết lập trình. Phần mình chịu trách nhiệm là những gì nằm trên đó: quyết định thiết kế, câu chuyện dự án và từng bài viết. Theo mình, nói rõ AI giúp phần nào và mình chịu trách nhiệm phần nào cũng là một cách giữ sự tín nhiệm.

Mình vẫn dùng AI mỗi ngày: tóm tắt tài liệu, gợi ý cách diễn đạt, liệt kê trường hợp ngoại lệ để mình rà lại, dựng nhanh vài phương án để so sánh. Nhưng trước khi gửi bất cứ thứ gì quan trọng, mình tự hỏi bốn câu.

Checklist bốn câu hỏi trước khi gửi tài liệu, bên cạnh một spec có câu AI gợi ý bị gạch và câu viết lại cụ thể
Bốn câu tự hỏi trước khi gửi, và một đoạn spec trước và sau khi viết lại. Mockup và nội dung đã được thay đổi để bảo mật dự án.
  1. Mình có nói lại được thông điệp chính bằng lời của mình không? Nếu phải nhìn slide mới nói được, có thể mình chưa thật sự hiểu nó.
  2. Mình có trả lời được câu “vì sao không chọn cách khác” không? Một quyết định không có phương án bị loại thường chưa phải là quyết định.
  3. Mỗi con số có nguồn mà mình đã tự mở ra xem không? AI rất giỏi đưa ra con số nghe hợp lý.
  4. Có câu nào mình sẽ không bao giờ nói ra miệng không? Nếu có, mình viết lại theo cách mình sẽ nói trong cuộc họp.

Câu thứ tư nghe đơn giản nhưng hiệu quả với mình nhất. Đôi khi phải bỏ một câu nghe rất hay để thay bằng một câu bình thường hơn, nhưng đúng với điều mình muốn nói.

Kết

Mình không nghĩ có cách dùng AI nào đúng tuyệt đối. Mỗi người, mỗi đội đều đang tự tìm nhịp của mình với một công cụ thay đổi gần như từng tháng. Những chuyện trong bài này cũng có lúc chính mình vấp phải. Mình viết lại để nhớ, không phải để nói ai đúng ai sai.

Với mình, làm việc trong một thế giới có AI giống như có thêm một cộng sự rất nhanh. Mình giao cho nó những việc lặp lại, để dành thời gian cho những phần cần mình nhất: hiểu người dùng, cân nhắc đánh đổi và giải thích được quyết định của mình. Khi ai đó hỏi “vì sao”, câu trả lời đến từ những gì mình thật sự hiểu, và đó là phần AI không giữ hộ mình được.

Anh Hoàng Nguyễn có một ví von mình rất thích: token của AI hết thì mua thêm được, còn sự tín nhiệm thì cần thời gian để vun đắp. Nên mình chọn cứ dùng AI, cứ học cùng nó, nhưng giữ thói quen hiểu rõ những gì mình gửi đi. Nếu bạn cũng đang tìm cách làm việc cùng AI và muốn trao đổi, cứ nhắn mình qua mục liên hệ nhe!

← Quay lại Blog Bài tiếp theoAI có đang khiến designer lười suy nghĩ? →