The UX of AI: Making AI-Powered Apps Your Users Don't Hate

1. Khoảng cách giữa developer và user

Kathryn Grayson Nanz, người tự giới thiệu ngắn gọn là Kat, là senior design and developer advocate tại Progress Software. Phần lớn sự nghiệp của cô xoay quanh front end. Cô đi một con đường khá vòng vèo: từ design rồi mới sang development, và cuối cùng tìm được chỗ đứng của mình ở vùng giao nhau giữa hai thế giới đó. Nền tảng design cho cô nhiều góc nhìn về phía UX của software engineering, và phần user research mà cô được làm trong vai trò developer advocate là một trong những phần cô thích nhất của công việc. Cô đã dành nhiều năm dạy developer về design, về UX, về cách build software thân thiện với người dùng hơn. Việc này lúc nào cũng có giá trị, nhưng giờ AI đã bước vào cuộc chơi thì nó quan trọng hơn bao giờ hết.

Kat nói không cần nhắc thì ai cũng biết AI là một công nghệ mới rất đặc biệt. Nó phát triển cực nhanh và có tiềm năng cải thiện hệ thống và software theo những cách mà chỉ vài năm trước chúng ta còn chưa dám mơ tới. Nhưng đi kèm với tiềm năng đó là khá nhiều rủi ro. Bản chất non-deterministic của AI khiến output có thể dao động rất mạnh về chất lượng, định dạng, văn phong và độ chính xác, kể cả khi mình đã cố hết sức để ngăn điều đó. Thêm vào đó, dùng AI đòi hỏi những kiểu interaction pattern hoàn toàn mới. Thực tế chúng ta đã thấy cả một bộ từ vựng mới, kỹ thuật mới, đôi khi cả những vai trò mới ra đời chỉ để đáp ứng nhu cầu này.

Với những người sống và thở cùng công nghệ này mỗi ngày, các khái niệm như prompt engineer, hallucination, retrieval augmented generation (RAG) và nhiều thứ khác đã thành chuyện thường ngày. Nhưng với đại đa số user của chúng ta thì chưa phải vậy. Trong bất kỳ công nghệ nào cũng có một khoảng cách giữa developer, người mà theo lẽ tự nhiên đã trở thành chuyên gia về chủ đề đó, và user. Mức độ hiểu biết kỹ thuật (technical literacy) của một software engineer trung bình bao giờ cũng cao hơn user trung bình của chính phần mềm đó.

Đó là lúc UX xuất hiện. UX là cách chúng ta bắc cầu giữa điều mình định làm khi build một ứng dụng và điều user thực sự, ừ thì, trải nghiệm (experiences). Suy cho cùng, software của mình làm được gì cũng chẳng quan trọng nếu user ghét dùng nó tới mức tìm mọi cách để né. Và theo Kat, ngay lúc này AI đang có một vấn đề UX khá nghiêm trọng. User thấy tính năng AI được gắn vào gần như mọi thứ: từ phần mềm công việc, tới app mạng xã hội, xuống tận hệ điều hành của máy tính và điện thoại.

2. AI đang có một vấn đề UX

Kat mượn lời một "nhà công nghệ thông thái": "Các nhà khoa học của ông mải lo xem họ có làm được hay không, tới mức không dừng lại để nghĩ xem họ có nên làm hay không." Chúng ta đang đẩy user dùng những công cụ và tính năng mới này, nhưng không phải lúc nào cũng làm cho việc đó dễ dàng.

Tình huống hay gặp: user được đưa cho một tính năng AI thiết kế kém, mà họ chỉ lờ mờ biết cách dùng. Họ thử, nó không làm điều họ muốn hay mong đợi, và họ thấy bực, thấy khó chịu, và bắt đầu có cảm giác tiêu cực về AI nói chung. Càng nhiều lần thử một tính năng AI mà nhận kết quả kém, họ càng ít muốn quay lại dùng nó trong tương lai. Nghĩa là, với tư cách người tạo ra các tính năng và phần mềm này, chúng ta chỉ có một số lần nhất định để làm đúng, trước khi user buông hẳn và không thử nữa.

Theo ý kiến cá nhân của Kat, khoảng cách hiểu biết giữa developer và user trong chuyện AI là một trong những khoảng cách rộng nhất cô từng thấy ở bất kỳ công nghệ nào. Điều đó khiến việc build những tính năng chạy bằng AI mà user thực sự khai thác hết được giá trị trở nên cực kỳ khó.

Cô lấy ví dụ lịch sử. Khi Macintosh giới thiệu graphical user interface (GUI), nó cũng giống AI bây giờ: rất khác lạ và xa lạ với user. Nhưng một phần lớn thành công và danh tiếng của Macintosh đến từ khả năng tạo ra một trải nghiệm gặp user đúng ở chỗ họ đang đứng (met users where they were). Họ mượn từ vựng và user flow từ đời thực. Họ dùng rất nhiều icon và hình ảnh minh hoạ, và họ thật sự đảm bảo hướng dẫn user cách tận dụng hết chiếc máy tính cá nhân mới của mình. Theo thời gian, khi user trung bình quen hơn và hiểu biết hơn, trải nghiệm của Macintosh cũng tiến hoá theo họ.

3. Bài học từ Macintosh: từ System 1 tới System 6

Qua các phiên bản, ta bắt đầu thấy nhiều thuật ngữ kỹ thuật hơn và ít lớp trừu tượng (abstraction) hơn. Kat cho xem sự khác biệt giữa Control Panel của Macintosh System 1 và System 6. Nếu bạn đưa cho một user thời System 1 những chữ như "rate of insertion point blinking" (tốc độ nhấp nháy của con trỏ nhập liệu) hay "RAM cache", gần như chắc chắn chúng chẳng có nghĩa gì với họ. Tương tự, ở System 6 những icon loa nhỏ và loa to cho âm lượng đã biến mất, cùng với hình con rùa và con thỏ để chỉ tốc độ. Lối minh hoạ quá sát nghĩa đen như vậy không còn cần nữa.

Kat cho rằng ngay lúc này, trong phép so sánh việc đưa AI tới user, chúng ta đang ở đâu đó quanh System 3. Có lẽ ta không còn cần icon con rùa và con thỏ nữa, nhưng cũng chưa thể giả định rằng user sẽ ngồi xuống với AI software của mình như một chuyên gia.

Tin tốt là, khác với giao diện Macintosh, lần này chúng ta không phải bắt đầu hoàn toàn từ con số không. User đã có sẵn những mental model về cách dùng software, và chúng sẽ được mang sang những gì chúng ta đang build. Chỉ là chúng không phải lúc nào cũng khớp một-một, và đó là chỗ chúng ta bước vào. Với tư cách developer, vai trò của mình là tận dụng những pattern mà user đã quen, bắt đầu kết hợp chúng theo những cách mới, rồi giới thiệu dần dần cho user sao cho không thấy choáng ngợp. Một trải nghiệm tốt không chỉ đưa cho user công cụ mà còn hướng dẫn họ cách dùng công cụ đó.

4. Mượn mental model có sẵn: ví dụ chat interface

Lấy ví dụ một AI chat interface. Thuần tuý về UI, chat với một LLM gần như, nhưng không hẳn, giống chat với một người khác. Vậy nên ta mượn được một số pattern quen thuộc: tin nhắn của user nằm một bên, tin của AI nằm bên kia; tin nhắn hiện phía trên một ô nhập liệu có nút gửi; lịch sử tin nhắn cuộn được, và nhiều thứ khác. Những thứ đó cho user một điểm xuất phát rất tốt và rất nhiều gợi ý thị giác về cách bắt đầu tương tác với một AI chat.

Tuy vậy, trải nghiệm này chưa đủ giống để ta nhấc nguyên giao diện direct message có sẵn rồi tái sử dụng toàn bộ. Một chat interface vốn được build cho hai người sẽ không có những chỗ cần thiết cho việc thêm nguồn tham khảo (reference source), tạm dừng hay dừng hẳn một câu trả lời đang được LLM sinh ra, dùng các agentic tool và integration, và nhiều thứ khác nữa. Đó chính là những chỗ ta phải biến các UX và UI pattern có sẵn thành một cái gì đó mới. Chúng ta phải là cây cầu, giúp user dần quen với những trải nghiệm AI mới này.

Kat so sánh màn hình new chat của Copilot Researcher agent với một new chat trong Teams. Cả hai đều có những phần quen thuộc: ô nhập text, dấu cộng để đính kèm file, vân vân. Nhưng Teams giả định mức độ quen thuộc cao hơn nhiều. Nó không giải thích bất kỳ icon nào nó dùng, và ta không thấy những thứ nhằm hạ thấp rào cản ban đầu như ví dụ mẫu, nút bấm chữ lớn, hay tuỳ chọn tương tác bằng giọng nói vốn xuất hiện ở màn hình chat của agent.

5. Vì sao không để AI tự thiết kế, và năm trụ cột

Trước khi đi sâu, Kat dừng lại để nói về "con voi trong phòng": tại sao không để AI tự tạo ra các giải pháp này cho chúng ta? Tại sao chúng ta phải tự thiết kế và build các pattern AI mới, khi đã có công nghệ sinh được giao diện?

Vấn đề là AI chỉ thực sự remix được những thứ đã tồn tại. Nó cực giỏi nhìn vào các pattern phổ biến có sẵn và sao lại chúng, nhưng các pattern cho giao diện AI thì chưa tồn tại trọn vẹn. Hoặc ít nhất, chúng vẫn đang được phát triển rất nhanh và thay đổi liên tục theo đà tiến của công nghệ. Chưa có một lịch sử dài các giao diện AI chuẩn hoá và quen thuộc để tham chiếu. Vậy nên ít nhất là bây giờ, chúng ta phải tự xoay xở, chưa thể giao việc này cho AI. Có thể sau này sẽ khác, nhưng tạm thời đây vẫn là một vấn đề rất con người.

Thêm nữa, như nhiều người bắt đầu nhận ra, design do AI tạo ra sẽ khá giống mọi design khác ngoài kia. AI tham chiếu và remix được, nhưng bạn sẽ không nhận được những concept hoàn toàn mới từ nó. Một UI do AI sinh ra thường trông, theo lời Kat, "trung bình hết mức" (pretty darn average). Đó có thể là một điểm khởi đầu rất tốt, nhưng thường không phải là điểm kết thúc tốt. Nếu bạn chỉ cần một landing page nhanh thì có lẽ nó làm được. Nhưng vì ta đang xử lý những kiểu tương tác hoàn toàn mới, cần chú ý tới UX nhiều hơn chứ không ít hơn, nên chừng đó chưa đủ để đưa ta tới đích, ở mức chất lượng mà user cần và xứng đáng được nhận.

Vậy nếu phải build pattern mới và giao diện mới để giúp user khai thác hết giá trị của công nghệ này, ta bắt đầu từ đâu? Giống hầu hết mọi chuyện trong design: tốt nhất là bắt đầu từ user, cụ thể là từ các vấn đề của user. Khi nghĩ về các tính năng AI, ta cần nghĩ xem user gặp khó khăn gì với AI, và những user flow nào giảm thiểu các vấn đề đó nhiều nhất có thể.

Từ user research cô đang làm và những user cô có dịp trò chuyện, Kat gom các thách thức chính thành năm nhóm: trust (niềm tin), clarity (sự rõ ràng), control (quyền kiểm soát), transparency (sự minh bạch) và meaningful benefit (lợi ích thực sự). Phần còn lại của talk đi sâu vào từng nhóm: hiểu vấn đề user gặp khi dùng AI, và xem các ví dụ về pattern và kỹ thuật mới để xử lý chúng. Khi đảm bảo xử lý đủ cả năm, ta có thể tạo ra những trải nghiệm AI đỡ user đi qua giai đoạn làm quen với công nghệ mới này, và giúp họ ở vị trí dùng được nó tới mức tối đa.

6. Trust: black box, hallucination và citation

"Bắt đầu thôi", Kat nói, và trụ cột đầu tiên là trust. Đây là rào cản số một, lớn nhất một cách áp đảo, mà ta phải vượt qua để user chịu dùng các tính năng AI mình build. Hiện tại, với user trung bình, AI là một black box. Nhiều người đơn giản là không hiểu về mặt kỹ thuật nó hoạt động thế nào, và khi không hiểu một thứ hoạt động ra sao thì rất, rất khó tin vào output của nó.

Thêm vào đó, gần như ai từng dùng một LLM cũng đã có lúc thấy nó hallucinate. Dù model ngày càng tốt hơn, ta vẫn chưa tới mức có thể khẳng định bất kỳ công cụ nào chắc chắn 100% không hallucinate. Luôn có một khả năng, dù nhỏ, rằng AI đưa ra câu trả lời sai. Vậy một user có thể thấy output sai bao nhiêu lần mà vẫn còn tin?

Rất dễ nghĩ rằng lời giải là định vị tính năng mình đang launch như một ngoại lệ. Ta nói kiểu: "Các công cụ AI khác có thể không đáng tin, nhưng của chúng tôi thì khác. Của chúng tôi chất lượng hơn, an toàn hơn, đáng tin cậy hơn", vân vân. Nhưng không chỉ điều này đáng ngờ về tính đúng đắn, vì suy cho cùng không nhiều người trong chúng ta thực sự tự train model của mình, nên phần lớn chuyện này nằm ngoài tầm kiểm soát của mình. Mà đây còn là một điều rất khó thuyết phục user.

Ở những chỗ không thể hứa về trust, ta phải nỗ lực hơn mức bình thường để giành được nó. Sự trung thực về năng lực và giới hạn hiện tại của công cụ AI sẽ đi xa hơn nhiều so với việc phủ nhận mọi vấn đề tiềm ẩn. Thay vì cố thuyết phục user rằng giải pháp của mình vốn dĩ đáng tin, ta có thể build những pattern giúp họ nhận ra khi thông tin sai được trả về, và cho họ công cụ để sửa hoặc giảm thiểu nó.

Câu "Trust but verify" (tin nhưng vẫn kiểm chứng) chính là mục tiêu ở đây. Bằng cách trích dẫn nguồn trong câu trả lời do AI sinh ra và link thẳng về tài liệu gốc, ta cho user thông tin cần thiết để tự kiểm chứng output. User càng có thể bấm vào và thấy câu trả lời đến từ đâu, họ càng tin nội dung hơn, kể cả khi họ không chọn kiểm tra mọi nguồn mỗi lần.

Ngoài việc cho user thẩm định câu trả lời, citation còn có một mục đích quan trọng thứ hai: nó cho user dùng lại tài liệu trong công việc của chính họ mà vẫn giữ được dấu vết về độ chính xác. Điều này rất quan trọng cho uy tín và danh tiếng của họ. Bạn có hay chia sẻ nội dung từ một nguồn không kiểm chứng được không, khi biết rằng mọi lỗi cuối cùng sẽ gắn với tên của chính bạn? Sinh output cho user có thể là bước cuối trong quy trình của mình, nhưng với họ đó chỉ là khởi đầu. User muốn lấy nội dung đó biến thành một báo cáo, một email, một chiến dịch, một bài thuyết trình. Nếu output không trích dẫn được và không đáng tin, nó sẽ đơn giản là không được dùng.

Có vài cách triển khai, và chọn cách nào tuỳ vào thứ bạn đang build và bối cảnh nó được dùng. Một vài cách phổ biến là tooltip, inline link và side panel tham chiếu. Tooltip cho phép đưa ra một đoạn trích ngắn có liên quan, rất tốt để tăng độ tin cậy. Link dĩ nhiên lý tưởng khi nội dung đến từ nguồn bên ngoài như một trang web khác, khác với nguồn nội bộ như một tài liệu trong shared drive. Còn nếu tính năng bạn build nhằm hỗ trợ công việc thiên về nghiên cứu, bạn có thể thêm một side panel để user khám phá tài liệu gốc chi tiết hơn. Cách này phần nào định vị AI assistant như một thủ thư (librarian) hơn là một chuyên gia tự thân.

7. Trust trong agentic workflow: action plan

Chỗ thứ hai mà trust đóng vai trò lớn là agentic workflow, khi AI tự suy nghĩ và tự thực thi công việc. Điều này dễ hiểu là có thể khiến user lo lắng, tuỳ vào mức độ hệ trọng của dự án và việc rollback các hành động sai dễ hay khó. Đó là lúc giữ human in the loop trở nên cực kỳ quan trọng.

Một trong những cách tốt nhất để giúp user đủ tin các hệ thống này mà dùng chúng là cho user xem một action plan và cho phép họ duyệt trước khi agent bắt đầu làm. Đây đã thành một flow khá phổ biến ở nhiều foundation model. Nếu bạn dùng tính năng agentic trong Claude hay ChatGPT, bạn sẽ thấy nó lập danh sách các bước sẽ làm để hoàn thành một tác vụ, rồi hỏi bạn xác nhận trước khi bắt đầu.

Dĩ nhiên cũng có những setting để tắt bước này hoặc luôn cho phép, và tất cả đều quan trọng nếu bạn để user lặp lại một flow nhiều lần mà không muốn họ phải trông chừng nó. Kat "spoil" trước: phần transparency phía sau sẽ nói thêm về permission. Nhưng nếu bạn tạo một agentic tool mà không bao giờ cho user xem plan, và một hành động xảy ra mà họ không hiểu vì sao hay bằng cách nào, thì sẽ rất, rất khó để họ tin cả kết quả của hành động đó lẫn chính agentic tool.

8. Trust và nội dung do AI tạo ra: đánh dấu rõ ràng

Hiện có một mức hoài nghi không thể phủ nhận, và Kat còn cho rằng có lẽ là đúng đắn, về chuyện một nội dung có phải do AI tạo ra hay không. Có lẽ bạn đã thấy những cuộc trao đổi online khi ai đó chia sẻ một ảnh hay video, và lập tức có người khác vào comment rằng cái đó không có thật (cô bật cười ở đây). Khi ta dành quá nhiều thời gian và sức lực để nghi ngờ và điều tra nội dung được chia sẻ với mình, đó không phải môi trường nuôi dưỡng niềm tin.

Hiện tại, nội dung do AI tạo ra gây phân cực mạnh trong user. Có người dùng nó rất nhiều trong đời sống hằng ngày, có người phản ứng tiêu cực và gạt đi như "slop". Khả năng AI tạo ra text, hình ảnh và video gần như không phân biệt được với tác phẩm của con người là rất mới, và với nhiều user, điều đó vẫn có cảm giác kỳ quái và bất an. Kat nói rõ cô không nhắc chuyện này để khơi một cuộc tranh luận. Nghe thì có vẻ phũ, nhưng quan điểm cá nhân của chúng ta về nội dung AI không thực sự quan trọng lắm trong bối cảnh này. Điều quan trọng hơn là nhận thức rằng user sẽ phản ứng với nội dung AI theo rất nhiều cách, và không phải cách nào cũng tích cực.

Vậy nếu muốn đưa nội dung AI vào ứng dụng mà không chắc user sẽ cảm thấy thế nào, ta làm gì để giữ niềm tin của họ? Một trong những việc dễ nhất là đánh dấu mọi nội dung do AI tạo ra là do AI tạo ra. Có thể đơn giản như một dòng disclaimer trong mô tả trên app store, một watermark trên ảnh (dạng digital hay nhìn thấy được), hoặc thậm chí chỉ là một dấu sao ở cuối câu để biểu thị nội dung đó do AI tạo.

Khi làm vậy, ta loại bỏ khả năng user cảm thấy mình đã cố lén nhét nội dung AI vào app, hoặc kiểu như đang lừa họ. Nếu ta dùng AI và nghĩ đó là lựa chọn phù hợp cho công việc, hoặc tin chắc user nên được chia sẻ nội dung do AI tạo, thì chẳng có gì phải xấu hổ khi ghi rõ chỗ nào đã dùng nó. Tuỳ chỗ AI được dùng, việc gợi ý cho user những phần nào của output họ có thể cần tự kiểm chứng cũng hữu ích, thay vì bắt họ soát mọi thứ như thể tất cả đều do AI tạo khi điều đó không thực sự cần.

9. Clarity: bỏ chuyện "phép màu", dùng live generation

Đi liền với trust là clarity. Clarity là một trong những khía cạnh quan trọng nhất của một trải nghiệm tốt nói chung, và mức độ hệ trọng chỉ tăng lên khi ta đưa AI vào. Vì như đã nói, AI vẫn còn rất nhiều điều xa lạ với user, ta cần mô tả và nói thẳng về những gì đang diễn ra ở mọi thời điểm. Càng cho user thấy software đang làm gì và điều gì sắp xảy ra, họ càng thấy thoải mái khi dùng AI.

Kat để ý thấy có một xu hướng đóng khung AI với user như phép màu. Chẳng cần nhìn đâu xa: sự phổ biến của icon lấp lánh (sparkle icon) để đánh dấu AI là một ví dụ. Nghe thì bí ẩn và hay ho, nhưng nó không chính xác. AI chỉ là một công nghệ khác, và user xứng đáng nhận được sự rõ ràng thay vì kịch tính. Họ muốn biết chuyện gì đang xảy ra, một output được tạo ra thế nào, và chẳng có lý do gì để ta không vén tấm màn lên bất cứ khi nào có thể.

Một trong những cách rõ ràng nhất là streaming text, hoặc các kiểu sinh nội dung trực tiếp tương tự. Đây không chỉ là cách rất hay để che đi vấn đề latency của việc sinh nội dung bằng AI (chẳng ai thích ngồi nhìn loading spinner), mà còn là cách tuyệt vời để cho user thấy chuyện gì đang diễn ra theo thời gian thực. Nếu bắt user chờ tới khi cả câu trả lời được sinh xong, có một khả năng không nhỏ là nó không phải thứ họ muốn. Còn nếu bắt đầu hiện một phần câu trả lời ngay trong lúc sinh, user có cơ hội đánh giá nó ngay lập tức. Họ có thể nghĩ ra câu hỏi tiếp theo, điều chỉnh, hoặc dừng hẳn quá trình nếu nó không trả về thứ họ mong.

Cách này cũng giữ user là người tham gia chủ động trong quá trình, tránh trải nghiệm kiểu truyện tranh xkcd "my code's compiling": bấm một nút rồi bỏ đi chỗ khác. Hẳn bạn cũng từng thấy hoàn thành một việc khó hơn nhiều thế nào khi cứ liên tục rời khỏi workflow. Kể cả khi biết một quá trình chỉ mất một phút, nếu không có gì giữ bạn ở đó, bạn sẽ bắt đầu check email, trả lời tin nhắn Slack hay lướt điện thoại. Và thế là một phút chờ thành một "side quest" năm tới mười phút, khiến việc quay lại đúng chỗ đang làm khó hơn nhiều. Càng ngăn được điều này cho user, họ càng làm việc hiệu quả hơn khi dùng công cụ của mình.

10. Thinking aloud và highlight những gì vừa đổi

Một cách khác giúp gỡ bức tường giữa AI và user là để AI "nghĩ thành tiếng" (think out loud) càng nhiều càng tốt khi xử lý một yêu cầu, đặc biệt trong các tương tác dạng chat. Giống live streaming, điều này tăng độ tự tin của user vào output, vì họ có thể lần theo các vụn bánh mì và hiểu sâu hơn một kết luận đã được rút ra thế nào.

Suy cho cùng, ta làm điều này suốt khi nói chuyện với người khác. Khi trình bày một ý tưởng, ta biết sẽ có ích nếu nói qua lập luận về cách mình đi tới đó và vì sao mình nghĩ đó là lựa chọn đúng. Giải thích bản thân là một phần tự nhiên của tương tác giữa người với người tới mức ta đã mặc định mong đợi nó. Khi không thấy điều đó được phản chiếu trong các hệ thống mình dùng, ta có thể thấy khá bực bội, như thể có gì đó đang vô tình bị giấu đi.

Thêm nữa, thấy được chuỗi suy nghĩ (chain of thought) giúp user sửa lại chính xác và tốt hơn khi output không như mong đợi. Nếu user hiểu mọi bước diễn ra giữa điểm A và điểm F, họ có thể chỉ ra đúng chỗ mọi thứ bắt đầu chệch hướng, và từ đó đưa ra chỉ dẫn cụ thể hơn hoặc làm rõ những phần mơ hồ trong yêu cầu của mình.

Một số pattern có sẵn dễ chuyển từ cách dùng không có AI sang bối cảnh này hơn, và highlight nội dung mới là một trong số đó. Không có gì đột phá, nhưng khi kết hợp với mọi thứ khác, nó có thể giúp rất nhiều để user theo dõi các hành động của AI, nhất là khi một agent đang tự hành động. Ý tưởng cơ bản: khi nội dung mới xuất hiện, hoặc có gì đó bị thay đổi hay cập nhật, nó được đánh dấu riêng để kéo sự chú ý của user tới đó.

Đôi khi điều này nghĩa đen là di chuyển focus lên hoặc xuống trang để thấy cái gì đã đổi, như khi tin nhắn mới xuất hiện trong một cuộc chat và lịch sử tin nhắn cuộn xuống để hiển thị nó. Những lúc khác, nó chỉ là kéo mắt user quay lại một vùng họ có thể không đang nhìn, kể cả khi không có chuyển động nào trên trang: đổi màu đoạn text đã sửa, đóng khung hoặc highlight nội dung mới, hay đánh dấu những dòng code khác đi.

11. Control: user ngồi ghế lái và cái phanh khẩn cấp

Các công cụ AI thường được đóng khung như một kiểu trợ lý cá nhân, một đồng nghiệp junior thông minh mà user có thể giao việc. Nhưng như ai từng giao việc cũng sẽ nói với bạn, đôi khi điều đó nghĩa là mọi thứ không được làm theo cách bạn sẽ làm. Khi user làm việc với công cụ AI của mình, họ cần biết rằng rốt cuộc họ vẫn là người ngồi ghế lái. Suy cho cùng, giao việc được cho AI chẳng có mấy giá trị nếu sau đó bạn không thể nhảy vào bất cứ lúc nào để điều chỉnh, sửa và vá.

Theo hướng đó, user cũng phải dừng hoặc override được một hành động của AI ở bất kỳ thời điểm nào: trong lúc sinh nội dung, giữa chừng một agentic workflow, khi nó đang chạy code hay script, hay bất cứ việc gì khác. Nếu user không thể huỷ quá trình, họ thực ra không phải người đang kiểm soát, và nói thẳng ra thì điều đó không chấp nhận được.

Một trong những điều trấn an nhất ta có thể đưa cho những user đang lo lắng là một cái phanh khẩn cấp rõ ràng và nổi bật, mà họ có thể đạp để dừng mọi thứ vì bất kỳ lý do gì. Nghĩa là nó không được giấu trong một menu nào đó, hay đòi một lệnh cụ thể mà họ phải nhớ, vì trong khoảnh khắc căng thẳng họ sẽ không nhớ nổi. Ta muốn đưa cho họ thứ tương đương một nút đỏ to để đập vào là mọi thứ dừng lại bất cứ khi nào cần.

Dĩ nhiên, khi user đã dừng một quá trình, ta có thể đoán được họ muốn làm gì tiếp: họ muốn hoàn tác những thứ sai đã bị thay đổi. Từ rất lâu trước AI, bộ heuristics của Nielsen đã liệt kê safe exploration như một nguyên tắc cốt lõi cho một trải nghiệm tốt (trong danh sách của Nielsen Norman Group, nguyên tắc gần nhất mang tên "User control and freedom"). Nghĩa là user phải được đi tới đi lui, bấm rồi bỏ bấm, và nói chung là được nghịch ngợm trong software mà không bị kẹt hoặc vô tình tạo ra những thay đổi lớn và vĩnh viễn.

12. Undo, redo, version history và chỉnh sửa có chọn lọc

Đôi khi user thử một thứ rồi đổi ý, quyết định không thích, hoặc nó không làm điều họ tưởng. Khi đó ta muốn việc quay về một trạng thái trước đó dễ nhất có thể. Tấm lưới an toàn này lúc nào cũng có giá trị, nhưng giờ khi đang xử lý output non-deterministic, có một dạng version history gần như là điều không thể thương lượng.

Dĩ nhiên mức version history cần có sẽ khác nhau tuỳ tác vụ. Kiểu version control như Git mà developer quen dùng có lẽ là quá mức cần thiết cho một ứng dụng dành cho user. Nếu đây là một giao diện hội thoại thật sự đơn giản, có khi bạn không cần nó: user chỉ việc diễn đạt lại câu hỏi và thử lại nếu chưa nhận được câu trả lời mong muốn. Nhưng nếu công cụ làm việc phức tạp hơn như tạo và sửa một tài liệu, các thao tác undo và redo đơn giản cho phép user đi tới đi lui trong khoảng mười bước gần nhất sẽ rất hữu ích. Còn nếu bạn muốn họ làm những việc thật sự nâng cao với công cụ của mình, thì đáng để build cơ chế checkpoint hoặc save state.

Hãy xem user sẽ làm những loại tác vụ gì với tính năng AI của bạn, và nghĩ xem mỗi bước tiến có khả năng làm thay đổi nội dung hiện có nhiều tới đâu. Lý tưởng nhất, cơ chế này cũng cho user đủ độ chi tiết để điều chỉnh có mục tiêu. Bạn không nhất thiết muốn họ phải xoá sạch và thay toàn bộ những gì xảy ra trong một bước chỉ vì họ không hài lòng. Kết quả do AI sinh ra thường có chất lượng lẫn lộn: user có thể muốn giữ vài phần và hoàn tác vài phần khác. Càng cho họ nhiều quyền kiểm soát quá trình sáng tạo đó, họ càng thấy thú vị khi cộng tác với công cụ AI của mình.

Điều này càng đúng lúc này, khi chi phí token bắt đầu nhích lên. Kiểm soát chi tiết phần nào được làm lại cho phép lặp (iteration) cụ thể và hiệu quả hơn, thay vì user chỉ biết nói "Try again" rồi bắt đầu lại từ đầu mỗi lần.

13. Transparency: permission và memory

Công cụ AI mạnh nhất khi chúng hoà liền mạch vào phần còn lại của workflow của user: tham chiếu tài liệu nội bộ, gửi email, đặt lịch hẹn, soạn và chia sẻ nội dung, vân vân. Nhưng phần lớn user sẽ không tích hợp thứ họ không nhìn thấy và không hiểu. Nếu các ứng dụng AI ta build sẽ trở thành một phần đời sống hằng ngày của họ, user cần minh bạch về chính xác những gì chúng làm, chúng được truy cập những gì, và chúng sẽ tốn của họ bao nhiêu, cả thời gian lẫn tiền bạc. Càng làm các tính năng này minh bạch, user càng ít do dự khi chấp nhận chúng.

Khái niệm xin quyền user chắc chắn không riêng gì AI, nhưng mức độ hệ trọng có thể cảm thấy cao hơn nhiều khi bạn xin user cho phép AI hành động thay họ. Nghĩa là ta cần giúp user dễ dàng thấy công cụ của mình đã được cho truy cập những ứng dụng nào và theo cách nào, và nhớ rằng permission thường không chỉ là có hay không. Agent của bạn chỉ được tham chiếu dữ liệu từ database này, hay còn được xoá bảng? Nó chỉ được đọc email của user, hay còn được gửi từ địa chỉ của họ? Nó có được chạy script, search file trên máy họ không? Mỗi hành động như vậy đều cần user trực tiếp đồng ý.

Permission cũng không phải chuyện làm một lần là xong. User có thể thấy thoải mái cho phép một hành động xảy ra một lần dưới sự giám sát trực tiếp của họ, nhưng không muốn cho phép vĩnh viễn. Họ có thể cho truy cập một thư mục cụ thể, nhưng không phải mọi thư mục. Họ có thể duyệt một hành động nhưng muốn được báo mỗi lần hành động đó diễn ra. Hãy xem trong cấu trúc permission của bạn có những vùng xám nào, và cố đáp ứng càng nhiều lựa chọn càng tốt.

Một điểm vướng phổ biến khác với AI là thu thập dữ liệu. Lưu thông tin từ các lần tương tác trước thường có ích, nhưng lưu loại dữ liệu này đòi hỏi chú ý thực sự tới permission và quản lý dữ liệu. Nếu bạn muốn tạo một hệ thống biết ghi nhớ, bạn cũng phải đảm bảo nó biết quên, và user không chỉ thấy được mà còn có tiếng nói cuối cùng về những gì được ghi nhớ. Một permission flow lý tưởng không chỉ xin sự đồng ý của user ngay lúc đó, mà còn tạo ra một chỗ để họ xem lịch sử những gì họ đã cho phép truy cập và khi nào, đồng thời cho họ thu hồi quyền đó bất cứ lúc nào.

14. Báo trước thời gian, chi phí và lúc AI tự chạy

Kat nói phần này khá đơn giản nên sẽ không dừng lâu, nhưng một khía cạnh then chốt khác của transparency là đảm bảo user biết chính xác họ đang cam kết điều gì khi duyệt một yêu cầu hành động. Ngoài việc duyệt các bước và plan như đã bàn ở phần trust, họ còn cần biết việc đó sẽ mất bao lâu, và sẽ tốn của họ bao nhiêu: tiền, token hay credit, tuỳ bạn tính kiểu gì. Kể cả khi không nói được con số chính xác, một ước lượng sơ bộ nói chung cũng đủ thông tin để user làm việc, và có thể sửa lại yêu cầu nếu nó vượt quá mức họ thấy thoải mái.

Tương tự việc đánh dấu nội dung nào do AI tạo, đây cũng là một dịp tốt để có tín hiệu thị giác cho biết khi nào một công cụ AI đang tự hành động. Ví dụ nếu bạn cho một agent điều khiển browser của user, thì cần có một banner, một sidebar hay một đường viền, một dấu hiệu nào đó cho thấy user không còn là người đang lái tương tác đó.

Đây không chỉ là việc nên làm vì minh bạch, để user hiểu trạng thái hiện tại của hệ thống, mà còn giúp họ không vô tình làm gián đoạn hay làm rối một quá trình đang chạy. Điều này đặc biệt quan trọng với những quá trình bạn biết sẽ kéo dài, khi user có thể đã rời đi rồi quay lại mà không theo dõi hết mọi thứ diễn ra lúc họ vắng mặt.

15. Meaningful benefit: hướng dẫn dùng và bước tiếp theo

Cuối cùng, mọi công nghệ thú vị và tính năng hay ho trên đời đều vô nghĩa nếu thứ ta build không giải quyết những vấn đề user cần giải quyết. Muốn vậy, ta cần tạo ra những trải nghiệm giúp user lấy được output họ cần từ tính năng AI một cách đơn giản nhất, và bắt đầu dùng nó trong công việc hay đời sống hằng ngày.

Một trong những sai lầm lớn nhất khi phát triển tính năng AI là giả định user biết cách dùng chúng. Như đã nhắc ở đầu talk, chúng ta biết cách cung cấp context, chỉ định yêu cầu về định dạng, hay chia tác vụ lớn thành phần nhỏ rồi lặp, nhưng user thường thì không. Nên khi đặt một ô text trống trước mặt user và chỉ bảo họ "ask AI", thực ra ta đang bắt họ làm khá nhiều việc để tự tìm ra cách dùng. Họ cần hiểu công cụ giải quyết được loại vấn đề gì, cần cụ thể tới mức nào, AI cần thông tin gì để làm tốt, có cần thêm nguồn hay tài liệu tham khảo không, và làm sao nhận ra khi một câu trả lời cần được tinh chỉnh.

Thay vì đòi user có mức AI literacy đó ngay từ ngày đầu, ta có thể giúp họ bằng ví dụ, template, prompt gợi ý và guided workflow cho thấy thành công trông như thế nào.

Tiếp theo: user sẽ làm gì với nội dung mà tính năng AI của bạn sinh ra? Nếu họ chạy một lượt search hay phân tích một spreadsheet, chuyện gì xảy ra sau đó? Họ làm gì với kết quả? Nếu họ tạo một bức ảnh, họ cho ai xem? Họ chia sẻ thế nào? Nó được in ra, đăng online hay gửi cho bạn bè? Bằng cách thêm các nút hành động cho bước tiếp theo (next step action button), ta làm cho việc tận dụng output trong công việc của họ dễ nhất có thể. Nếu họ không hành động được với nội dung vừa tạo, nó sẽ không bao giờ là gì hơn một món đồ chơi mới lạ, không có giá trị dùng thực tế. Nhưng ta có thể dẫn họ tới các hành động gợi ý giúp họ tận dụng tối đa thứ họ đã tạo.

Muốn đi thêm một bước, ta có thể build integration trực tiếp với những công cụ họ dùng nhiều nhất. Có thể họ muốn tạo một tài liệu mới trong phần mềm soạn thảo từ một bản nháp. Có thể họ muốn push code mới lên một repo đã liên kết. Có thể họ muốn mở một ticket mới trong hệ thống tracking với những phát hiện từ một lần test. Càng làm đơn giản việc đưa thông tin từ công cụ của mình sang phần còn lại của workflow, công cụ đó càng hữu ích với họ.

16. Khác biệt giờ nằm ở trải nghiệm

AI có thể sinh nội dung, viết code, phân tích dữ liệu, tự động hoá tác vụ, giúp user làm đủ loại việc tuyệt vời, nhưng chỉ khi họ chịu thử và chỉ khi ta làm nó đủ dễ. Khi mọi thứ công cụ AI làm đều bị giấu sau tấm màn, user cảm thấy mọi chuyện đang xảy ra mà không có ý kiến của họ. Điều đó khó chịu, nhất là khi nhiều người vốn đã có phần hoài nghi hoặc ngần ngại với AI. Nếu ta vô tình tạo ra những trải nghiệm AI lấy mất quyền lực, sự hiểu biết và quyền tự chủ của user, họ sẽ không bao giờ hứng thú dùng thứ ta build, vì họ sẽ không bao giờ thật sự thấy thoải mái khi dùng nó.

Bằng cách tập trung vào các pattern củng cố năm trụ cột trust, clarity, control, transparency và meaningful benefit, ta có thể dựng guardrail quanh các tính năng AI để user cảm thấy an toàn và tự tin.

Vì công nghệ đã ở đây rồi. Các model đã rất tốt, và ngày càng tốt hơn, nhanh hơn, hiệu quả hơn. Điều đó có nghĩa là yếu tố khác biệt của AI software ta build không còn là hiệu năng nữa. Nó là chất lượng của những trải nghiệm ta build quanh các model đó.

Ranh giới giữa design và development mỗi ngày lại mờ đi thêm một chút. User tương tác với hệ thống thế nào, họ thấy bao nhiêu thông tin, họ có bao nhiêu quyền kiểm soát, và ta giành được niềm tin của họ ra sao, giờ là những câu hỏi mà developer phải cân nhắc khi build AI software, dù chức danh của bạn có chữ "designer" hay không (cô bật cười). Công nghệ có thể đáng kinh ngạc, nhưng để nó thực sự thành công, user vẫn phải ở trung tâm của mọi thứ ta build.

Kat cảm ơn người nghe và hy vọng talk này hữu ích khi mọi người bắt đầu tích hợp tính năng AI vào ứng dụng và software của mình. Slide và bản văn đầy đủ của talk được cô chia sẻ qua các mã QR ở slide cuối, và cô mời mọi người cứ liên hệ với cô online nếu có câu hỏi, vì cô luôn sẵn lòng trò chuyện.