Thiết kế một không gian làm việc kết hợp AI hỗ trợ viết, phân tích hiệu suất và ra quyết định cho đội ngũ nội dung

AI có thể tạo ra một bản UI đẹp trong vài phút. Nhưng một bản UI đẹp chưa nói được hướng thiết kế có đúng hay không — đặc biệt trong sản phẩm có hai nhóm người dùng có những động lực có thể xung đột nhau.

Scribe AI là một bài toán như vậy: người phụ trách chiến lược nội dung cần dữ liệu để ra quyết định, trong khi người viết cần một không gian đủ yên để tập trung viết.

Vì vậy, câu hỏi xuyên suốt dự án là:

AI nên xuất hiện ở đâu, và quan trọng hơn — khi nào nó nên im lặng để trả lại sự yên tĩnh cho người viết?

Tổng quan dự án

Scribe AI là một sản phẩm SaaS B2B kết hợp AI hỗ trợ viết và phân tích hiệu suất nội dung trong cùng một không gian làm việc.

Đề bài yêu cầu thiết kế lại trải nghiệm cho hai vai trò:

• Người phụ trách chiến lược nội dung (strategist)— theo dõi hiệu suất, hiểu nội dung nào đang đóng góp vào pipeline và chuẩn bị dữ liệu để báo cáo.
• Người viết nội dung (Writer)— viết nội dung hàng ngày, cần AI hỗ trợ nhưng không muốn bị gián đoạn trong quá trình viết.

Thách thức cốt lõi là biến lớp AI vốn khá “vô hình” thành một phần hữu ích của trải nghiệm, mà không phá vỡ luồng viết của Writer.

01. Nghiên cứu: hỏi ít hơn, nhưng phải thay đổi được quyết định

Dự án bắt đầu bằng việc xây dựng một bộ 8 câu hỏi nghiên cứu, bao phủ từ cách người dùng hình thành nhận thức, quy trình làm việc, niềm tin vào AI, “giọng thương hiệu” đến chỉ số hiệu suất và cách strategist phối hợp với writer. 

Nhưng tớ không mặc định rằng cả 8 câu hỏi đều cần được nghiên cứu như nhau. Bởi nghiên cứu người dùng cũng là một bước tốn chi phí.

AI đề xuất 8 câu hỏi nghiên cứu đồng thời gợi ý mức độ ưu tiên. Nhưng tớ nhận ra thứ tự đó không dựa trên bất kỳ tiêu chí nào tớ đưa ra. Tớ hỏi ngược: bạn dựa vào đâu để xếp thứ tự này? Buộc AI phải giải thích logic phía sau — hoặc thừa nhận rằng mức độ ưu tiên đó chưa dựa trên một tiêu chí rõ ràng.

Sau đó tớ tiếp tục lọc lại câu hỏi thêm lần nữa:

• Câu hỏi nào đã có câu trả lời từ đề bài?
• Câu nào có thể giải quyết bằng nghiên cứu tài liệu thay vì phải phỏng vấn?
• Nếu thời gian bị rút ngắn, câu hỏi nào thực sự ảnh hưởng đến sản phẩm?
• Quan trọng nhất: nếu có câu trả lời cho câu hỏi này, nó có thay đổi một quyết định thiết kế cụ thể không?

Một câu hỏi nghiên cứu chỉ đáng giữ nếu câu trả lời của nó có khả năng thay đổi một quyết định thiết kế.

Những câu hỏi không mang đến một quyết định thiết kế cụ thể sẽ không được ưu tiên, dù bản thân chúng nghe có vẻ rất hay. 

Đây cũng là cách tớ sử dụng AI trong nghiên cứu: AI giúp mở rộng không gian câu hỏi. Tớ quyết định câu hỏi nào đáng để đi tìm câu trả lời.

02. Nghiên cứu: Bài toán về mối quan hệ

Khi đặt hai người dùng cạnh nhau

Từ kết quả nghiên cứu, vấn đề thật sự sâu hơn: hai người không chỉ có nhu cầu khác nhau — họ có thể có động lực chống lại nhau.

Nếu Scribe AI hiển thị lớp trí tuệ theo cách khiến người viết cảm thấy mình đang bị theo dõi thay vì được hỗ trợ, trải nghiệm có tốt đến đâu, họ vẫn có thể không muốn sử dụng nó.

Đây trở thành bài toán thiết kế thực sự của dự án.

03. Không phải câu hỏi thiết kế nào cũng cần AI

Tớ không đưa AI vào mọi quyết định.

Trong ba câu hỏi HMW, tớ tự giải quyết hai câu đầu dựa trên nghiên cứu đã có. Chỉ đến HMW thứ ba — làm thế nào để đề xuất của AI trở thành một phần của quá trình viết và phân tích thay vì một lớp chồng lên nó — tớ mới dùng AI để động não vì lý do:

Đó là vùng mờ mà tớ chưa có câu trả lời chắc chắn.

Tớ đã yêu cầu AI đưa ra nhiều ý tưởng với các hướng khác nhau: từ cách thị trường đang làm, cách làm ngược lại cho đến những ý tưởng được đẩy tới giới hạn phi thực tế. Tớ không chọn ý tưởng vì nó “ngầu”, mà đánh giá từng ý tưởng dựa trên những nguyên tắc thiết kế đã xác định. 

• Ý tưởng này có giữ quyền quyết định cuối cùng ở người dùng không?
• Ý tưởng này có giúp Writer tập trung hơn, hay thêm một thứ để họ phải chú ý?
• Ý tưởng này có cho Strategist câu trả lời có căn cứ, hay chỉ đẩy thêm dữ liệu?

04. Xác định hướng thiết kế

AI không cần luôn “chạm” vào người dùng nhưng sẽ luôn sẵn sàng mà không bắt người dùng phải chú ý đến nó.

Kiểm tra khoảng trống trên thị trường

Nếu hướng thiết kế này được đưa ra thị trường, nó đang giải quyết một khoảng trống thực sự hay chỉ đổi tên một cách làm đã quá quen thuộc? Để trả lời cho câu hỏi này tớ tiếp tục đối chiếu Scribe AI với 6 công cụ viết có AI:

Jasper · Notion AI · Writer.com · Grammarly Business · Surfer SEO · Copy.ai

Khoảng trống tớ muốn Scribe AI giải quyết

	Cách tiếp cận phổ biến	Scribe AI
Writer	AI liên tục đề xuất trong lúc viết	AI chạy nền, Writer chủ động gọi
Strategist	Dashboard → tự tìm insight	Câu hỏi → AI trả lời
AI intelligence	Hiển thị trực tiếp	Hiện diện theo ngữ cảnh
Quyền kiểm soát	AI chủ động dẫn dắt	Người dùng quyết định khi tương tác

Phần lớn công cụ AI viết hiện nay không thiết kế cho việc người viết viết tốt hơn — chúng thiết kế để chứng minh AI đang có mặt. Đề xuất liên tục, gợi ý liên tục, không để ý đến việc writer cần hay không. Đó là cách sản phẩm chứng minh giá trị AI với đội sales và với chính KPI adoption của họ. Tớ nghĩ đây là sai lầm gốc rễ, không phải vấn đề UX.

Điểm khác biệt không nằm ở việc Scribe AI có nhiều tính năng hơn, mà ở cách AI được đặt vào trải nghiệm: nó thay đổi cách người dùng tiếp cận AI mà không lấy quyền kiểm soát khỏi họ.

Hướng thiết kế: Trợ lý âm thầm

Để AI trở thành trợ lý âm thầm, tớ đã giữ lại những ý tưởng chính:

• Trước khi bắt đầu, Writer chọn một lần: viết từ trang trắng hoàn toàn, hoặc mở đầu bằng gợi ý từ template/AI. Dù chọn cách nào, ngay sau đó AI lùi lại chạy trong nền và xây dựng một Shadow Draft dựa trên brief và brand voice.
• Writer chỉ nhìn thấy một tín hiệu nhỏ cho biết AI đang làm gì và chủ động gọi AI khi cần.
• Khi mở khung AI, mỗi đề xuất được giải thích theo ba lớp: Đề xuất → Lý do → Hành động.
• Writer có thể Áp dụng hoặc Chỉnh sửa từng đề xuất.
• AI đề xuất. Writer quyết định.

Chỉ những phần được áp dụng mới thay đổi bài viết. Người viết vẫn là người quyết định cuối cùng.

05. Tầm nhìn: Trí tuệ của AI cũng phải trưởng thành theo đội ngũ

Shadow Draft không chỉ là một cách tương tác. Tớ hình dung đó là một lớp trí tuệ có thể học theo thời gian mà không cần thay đổi cách người dùng tương tác với nó.

Cách tương tác của người viết không thay đổi, nhưng độ sâu và độ tin cậy của các gợi ý bởi AI sẽ lớn lên theo thời gian.

06. Strategist: không cần thêm một bảng điều khiển

Nếu writer cần một AI biết khi nào nên im lặng, strategist lại gặp vấn đề ngược lại.

Họ đang phải tổng hợp dữ liệu từ nhiều công cụ và bảng điều khiển trước khi có thể trả lời một câu hỏi đơn giản từ cấp trên. Một bảng điều khiển nhiều biểu đồ có thể chứa rất nhiều thông tin, nhưng vẫn khiến người phụ trách chiến lược bị động:

“Nếu câu hỏi của cấp trên không nằm trong những biểu đồ tôi đã chuẩn bị thì sao?”

Vì vậy, tớ loại bỏ bảng điều khiển mặc định. Thay vào đó, phần phân tích bắt đầu bằng một câu hỏi:

“Bạn muốn biết gì về nội dung tháng này?”

Tiếp đó là những câu hỏi gợi ý được tạo dựa trên dữ liệu hiện có của đội ngũ.

Khi đặt câu hỏi, AI trả về ba lớp: Biểu đồ → Giải thích → Hành động đề xuất. Người dùng có thể bật hoặc tắt phần giải thích tùy nhu cầu. Tớ không muốn AI chỉ biến dữ liệu thành một câu trả lời. Strategist cần nhìn thấy cơ sở của kết luận để có thể kiểm tra, giải thích lại và vạch ra kế hoạch hành động tiếp theo.

Kết quả cũng được định dạng sẵn để đưa vào báo cáo. Không còn là: “Đây là 20 chỉ số. Hãy tự phân tích.”

Mà sẽ là câu trả lời hoàn chỉnh:

“Câu trả lời + Lý do được phân tích từ dữ liệu + Bạn có thể làm tiếp theo” để strategist có thể tự tin trước bất kì câu hỏi nào ngay trong cuộc họp.

07. AI không phải lúc nào cũng chờ được hỏi

Giao diện câu hỏi giải quyết những vấn đề mà strategist chủ động đặt ra. Nhưng lớp AI dành cho strategist còn có một vai trò khác.

AI được thiết kế để chủ động tìm những mẫu hình không dễ nhận ra trong dữ liệu và đưa chúng lên thành thẻ insight.

Ví dụ: Các bài dạng nghiên cứu tình huống đăng vào thứ Ba có mức tương tác cao gấp đôi các ngày khác trong ba tháng qua.

Strategist không cần biết trước mình nên hỏi câu gì mới tìm được insight đó. Đây là điểm cân bằng giữa hai kiểu trí tuệ:

AI phản hồi: Tôi hỏi → AI trả lời. AI chủ động: AI thấy điều đáng chú ý → AI đưa nó lên.

Cả hai đều phục vụ cùng một mục tiêu: Rút ngắn khoảng cách từ dữ liệu đến quyết định.

AI cũng xuất hiện trong màn hình Lập kế hoạch dưới dạng 2–3 hành động tiếp theo được đề xuất dựa trên dữ liệu hiệu suất, thay vì những khuyến nghị chung chung. 

08. Tạo prototype: Hai công cụ, một hướng thiết kế

Với dự án này tớ dùng Aura.build và Figma Make để tạo hai phiên bản từ cùng một hướng thiết kế để có cơ hội phân tích xem:

Cùng một logic sản phẩm, hai AI sẽ diễn giải nó khác nhau ở đâu?

Hai nguyên mẫu vì thế trở thành một cách khác để kiểm tra logic thiết kế, chứ không chỉ để tạo giao diện nhanh hơn.

09. Kiểm thử: Lỗi nghiêm trọng nhất lại liên quan đến quyền kiểm soát

Tớ tự chạy một vòng rà soát trên nguyên mẫu cuối, kiểm tra từ Đăng nhập, Tạo nội dung mới, Vùng soạn thảo, Phân tích đến Khung AI.

Kết quả ban đầu

7 Đạt · 6 Lỗi nhỏ · 5 Lỗi lớn · 1 Lỗi nghiêm trọng

Một lỗi nghiêm trọng nổi bật:

Sau khi áp dụng đề xuất, người viết không có cách hoàn tác ngay thao tác đó.

Người viết có thể áp dụng một đề xuất của AI, nhưng không có cách rõ ràng để quay lại ngay lập tức. Về mặt giao diện, đây có thể chỉ là một thao tác còn thiếu. Nhưng về mặt nguyên tắc sản phẩm, nó nghiêm trọng hơn nhiều. Bởi vì toàn bộ hướng thiết kế được xây trên một nguyên tắc:

AI có thể đề xuất. Người viết phải luôn giữ quyền quyết định cuối cùng.

Nếu người viết không thể dễ dàng hoàn tác một quyết định do AI đề xuất, nguyên tắc đó đã bị phá vỡ ngay trong chính thao tác tương tác. AI có thể sẽ chưa hoàn thiện prototype ngay lần generate đầu tiên.

Sau khi cập nhật

15 Đạt · 2 Lỗi nhỏ · 2 Lỗi lớn · 0 Lỗi nghiêm trọng

Đó cũng là lý do tớ không xem kiểm thử là bước cuối để “kiểm tra giao diện”.

Kiểm thử là lúc kiểm tra xem những nguyên tắc sản phẩm mình nói có thực sự tồn tại trong thao tác của người dùng hay không.

10. Điều tớ học được khi thiết kế cùng AI

Từ dự án Scribe AI tớ đã đúc rút được 3 kinh nghiệm :

• Không nhất thiết phải dùng AI ở mọi bước.
• AI đã giúp tớ nghĩ rộng hơn. Nhưng nó không thay tớ quyết định điều gì đáng để theo đuổi.
• Không nhất thiết là AI phải luôn xuất hiện. Đôi khi, một AI tốt là AI biết lúc nào người dùng không cần nó. Đó cũng là lý do tớ không đo thành công của Scribe AI bằng việc AI được gọi bao nhiêu lần — mà bằng việc người dùng có còn cảm thấy cần kiểm tra lại AI hay không

Nếu có thêm thời gian

Tớ sẽ quay lại những câu hỏi HMW đã bị loại. Trong quá trình loại bỏ ý tưởng, có một số ý tưởng vẫn có thể chứa những hướng đáng thử — chỉ là ở thời điểm đó tớ vẫn chưa có đủ dữ liệu để tin vào chúng.

Đặc biệt, tớ muốn tiếp tục kiểm tra những ý tưởng nằm giữa trí tuệ chủ động, khả năng học theo thời gian và lập kế hoạch nội dung. Có thể một trong số chúng sẽ trở thành một hướng sản phẩm khác. Nhưng ở dự án này, tớ chọn dừng ở một nguyên tắc rõ ràng:

AI không cần làm nhiều hơn. Nó cần biết mình đang ở đâu trong trải nghiệm của người dùng — và biết khi nào nên lùi lại.