“Rác vào, bảo vật ra”: Nhà thiết kế trưởng của Anthropic nói về triết lý sản phẩm của Cowork và sự thật sau 10 ngày ra mắt

整理 & Biên soạn: sâuTechFlow

Khách mời: Jenny Wen, Trưởng bộ phận Thiết kế của Cowork

Người dẫn chương trình: Peter Yang

Nguồn podcast: Peter Yang

Tiêu đề gốc: Claude Cowork Tutorial from Cowork s Design Lead (40 Min) | Jenny Wen

Ngày phát hành: 2026年3月29日

Tóm tắt các ý chính

Jenny là Trưởng bộ phận Thiết kế của Cowork. Cô ấy đã đưa tôi đi sâu vào cách vận hành nội bộ của Anthropic, bao gồm cách cô ấy sử dụng thiết kế và phát triển sản phẩm của Cowork, cũng như câu chuyện thật đằng sau sự ra đời của Cowork. Anthropic gần như mỗi ngày đều cho ra mắt các tính năng mới, và việc được thấy cách họ làm việc khiến tôi vô cùng choáng ngợp.

Tổng hợp các ý kiến hay

Về cách làm việc hằng ngày

Phần lớn những việc tôi dành thời gian làm là đưa sản phẩm ra thị trường. Nhưng tôi nghĩ điều này có lẽ khác so với một hai năm trước. Và phần lớn thực ra là chúng tôi cùng “jam” (cộng tác ứng biến) với các kỹ sư, người làm sản phẩm, v.v. theo một cách không quá chính thức. Thường thì mọi người cùng xem một prototype, sau đó chỉ ra và suy nghĩ nó có thể phát triển/tiến hóa như thế nào.

Về triết lý sử dụng “rác vào, ngọc ra”

Tôi nghĩ điều khiến tôi ấn tượng nhất ở Cowork là khả năng sắp xếp và xử lý thông tin của nó. Tôi thích gọi nó là “rác vào, ngọc ra”. Nó có thể thu thập thông tin từ nhiều nguồn khác nhau, sau đó nhanh chóng tìm ra các điểm then chốt, chắt lọc nội dung có giá trị và chuyển hóa thành các kết quả mang tính ứng dụng, tạo ra hiệu quả sản xuất thực sự.

Về sự khác nhau giữa Cowork và Claude Code

Ngoài công việc viết code sản xuất (production code) cực kỳ tỉ mỉ ra, hiện tại gần như mọi việc khác tôi đều làm bằng Cowork. Nếu là những tình huống cần tập trung vào một số chi tiết code nhất định, tôi vẫn sẽ dùng Claude Code. Nhưng đối với giao tiếp và cộng tác hằng ngày, hiện tại tôi hoàn toàn dựa vào Cowork.

Về câu chuyện ra đời của Cowork

Câu “họ làm ra trong 10 ngày” thực ra là được cắt ghép từ một cuộc phỏng vấn hoặc bài báo truyền thông nào đó. Nhưng sự thật là, về hướng đi này của Cowork, từ lúc tôi gia nhập Anthropic cách đây một năm, chúng tôi đã bắt đầu lên ý tưởng. Chúng tôi vẫn luôn suy nghĩ cách xây dựng một “đối tác suy nghĩ” (thinking partner) có thể giúp tất cả những người làm việc tri thức nói chung.

Mặc dù Claude Code đã có thể xử lý rất tốt các tác vụ liên quan đến code, nhưng mục tiêu của chúng tôi là bao phủ mọi tình huống làm việc tri thức. Tôi nghĩ thách thức thực sự nằm ở: chúng tôi sẽ thực hiện ý tưởng đó như thế nào? Kiến trúc nào là phù hợp nhất? Trải nghiệm người dùng (UX) nào mới là đúng?

Về sự tiến hóa trong quy trình thiết kế

Tôi vẫn làm Figma. Nhưng hiện tại chúng tôi không làm tài liệu đặc tả thường xuyên nữa, và cũng thường không quá chi tiết. Chúng tôi vẫn sắp xếp ưu tiên, và nó vẫn tồn tại như một tài liệu, nhưng thường chỉ là vài bullet points, không phải kiểu bảng thiết kế đẹp mắt, quá mức trau chuốt.

Về kế hoạch và tầm nhìn

Lĩnh vực kỹ thuật của chúng tôi thay đổi với tốc độ rất nhanh, các mô hình mới liên tục xuất hiện, tốc độ cập nhật cũng ngày càng nhanh hơn. Vì vậy, việc đặt tầm nhìn một năm cho chúng tôi không thực tế, chứ đừng nói đến tầm nhìn hai đến năm năm, vì có quá nhiều yếu tố chưa biết.

Về tương lai của người thiết kế

Nếu bạn cảm thấy mặt đất dưới chân đang di chuyển, thì là vì nó thật sự đang thay đổi. Chúng ta phải thừa nhận điều đó và học cách thích nghi, đồng thời với thái độ cởi mở, chúng ta phải nhìn lại cách làm việc hiện tại của mình.

Mỗi khi tôi cảm thấy nghề nghiệp của mình bị thử thách, thì trong những lúc như vậy tôi lại nghĩ đến các đồng nghiệp kỹ sư của tôi. Họ đã trải qua những biến đổi lớn trong công việc từ lâu rồi, nhưng họ không chỉ thích nghi với các thay đổi đó mà còn đón nhận thử thách với rất nhiều can đảm và sự khiêm tốn, cuối cùng đạt được kết quả làm việc hiệu quả và xuất sắc hơn. Họ là nguồn cảm hứng của tôi—tôi sẽ nhắc mình rằng nếu những đồng nghiệp mà tôi vô cùng kính trọng có thể làm được, thì chắc chắn tôi cũng làm được. Họ là tấm gương để tôi thích nghi với thay đổi.

Mở đầu

Peter Yang: Xin chào mọi người, hôm nay tôi cực kỳ hào hứng khi được chào đón Trưởng bộ phận Thiết kế của Anthropic là Jenny. Jenny sẽ cho chúng tôi thấy cách cô ấy sử dụng Claude Cowork và Claude Code để thiết kế và ra mắt sản phẩm, đồng thời chia sẻ câu chuyện nội bộ của Cowork, và có lẽ còn nói qua về bước tiếp theo của sản phẩm.

Jenny, một ngày làm việc điển hình của bạn trông như thế nào? Những nhiệm vụ nào chiếm phần lớn thời gian của bạn?

Jenny:

Tôi không biết có phải là một ngày điển hình hay không, nhưng phần lớn những việc tôi dành thời gian làm chính là đưa sản phẩm ra thị trường. Tuy nhiên tôi nghĩ điều này có thể khác so với một hai năm trước. Và phần lớn thực ra là chúng tôi cùng “jam” (cộng tác ứng biến) theo một cách không quá chính thức với các kỹ sư, người làm sản phẩm, v.v. Thường thì mọi người cùng xem một prototype, rồi chỉ ra và suy nghĩ nó có thể phát triển như thế nào. Có lúc chỉ là thảo luận về cách tính năng thể hiện. Có lúc là tôi tự thực hiện một số thứ. Tôi nghĩ vẫn còn rất nhiều thời gian tôi tự thiết kế, làm prototype, v.v. Nhưng cách làm công việc thiết kế hiện tại trông có vẻ thoải mái hơn.

Peter Yang: Ý là về cơ bản bạn dùng các công cụ như Claude để tạo ra một loạt prototype, rồi cùng kỹ sư “jam”, đưa phản hồi, và dùng prompt để AI cải thiện nó, đúng không?

Jenny:

Thực ra, chúng thường thậm chí không phải prototype. Mà là các prototype làm việc đã được xây dựng và chạy nội bộ trong môi trường Claude hoặc Cowork. Thường thì tôi sẽ dành thời gian sử dụng tính năng này, thúc đẩy tính năng này, xem khả năng của nó ra sao, và hình thành ý kiến. Bước lặp tiếp theo thường là tôi ngồi xuống nói với kỹ sư: này, tôi đang nghĩ thế này. Đây là những chỗ tôi nghĩ nên sửa. Tôi vẫn cảm thấy rằng việc lặp lại, mài giũa và tinh chỉnh trong công cụ thiết kế là cực kỳ, cực kỳ quan trọng. Vì vậy phần đó không hề biến mất. Chỉ là vì tôi đồng thời xử lý nhiều dự án hơn, nên cảm giác cách làm hiệu quả hơn là rất tùy hứng, rất không chính thức.

Peter Yang: Tôi nghĩ đó luôn là phần tôi thích nhất khi làm product manager hoặc designer—kéo designer và kỹ sư lại với nhau, nhìn sản phẩm cùng lặp lại. Thế thì bây giờ các bạn có không còn làm các tài liệu kế hoạch kiểu đặc tả, file Figma… nữa đúng không? Hay các bạn cứ lặp prototype ngay trong code?

Jenny:

Tôi vẫn làm Figma. Nhưng giờ chúng tôi không làm tài liệu đặc tả thường xuyên nữa, và cũng thường không chi tiết lắm. Đúng. Chúng tôi vẫn làm việc sắp xếp ưu tiên, và nó vẫn tồn tại như một tài liệu. Thật ra điều này giúp ích cho nhóm an ninh hoặc pháp lý của chúng tôi: để họ hiểu nội dung sẽ được phát hành là gì, nhưng thường thì chỉ là vài bullet points. Không phải kiểu bảng thiết kế đẹp mắt, quá mức trau chuốt. Tôi nghĩ file Figma của chúng tôi cũng giống như vậy.

Demo thực hành Cowork

Peter Yang: Bạn có thể cho chúng tôi xem cách bạn sử dụng các sản phẩm này, hoặc mỗi sản phẩm bạn dùng để làm gì không?

Jenny:

Được chứ. Tôi sẽ kể về cách tôi sử dụng Cowork. Thật ra tôi có một bí mật nhỏ: ngoài công việc viết code sản xuất (production code) cực kỳ tỉ mỉ, hiện tại gần như mọi việc khác tôi đều làm bằng Cowork. Nếu cần tập trung vào một số chi tiết code trong tình huống nào đó, tôi vẫn sẽ dùng Claude Code. Nhưng đối với giao tiếp và cộng tác hằng ngày, hiện tại tôi hoàn toàn phụ thuộc vào Cowork.

Tôi nghĩ điểm khiến Cowork làm tôi ngạc nhiên nhất là khả năng tổ chức và xử lý thông tin của nó. Tôi thích gọi nó là “rác vào, ngọc ra”. Nó có thể thu thập thông tin từ nhiều nguồn khác nhau, rồi nhanh chóng tìm ra các điểm then chốt, chắt lọc nội dung có giá trị và chuyển hóa nó thành các kết quả mang tính ứng dụng, có thể tạo ra năng suất thực sự.

Lấy ví dụ: hiện tại tôi kết nối với một thư mục, trong đó có lưu một số bản ghi phỏng vấn người dùng. Nhóm Cowork của chúng tôi rất coi trọng việc gắn chặt với người dùng, và đây cũng là một trong những yếu tố quan trọng giúp chúng tôi đạt được thành công. Chúng tôi trò chuyện trực tiếp với người dùng thông qua nghiên cứu trải nghiệm người dùng truyền thống (UXR), đồng thời cũng có cách làm nội bộ để tự dùng, chẳng hạn như chúng tôi có một kênh Slack chuyên dùng để thu thập phản hồi. Ngoài ra, chúng tôi cũng theo dõi các cuộc thảo luận trên mạng xã hội và lắng nghe ý kiến của những người dùng nhiệt huyết. Chính vì chúng tôi luôn giữ kết nối chặt chẽ với người dùng, và có thể lặp lại sản phẩm nhanh chóng, nên chúng tôi mới liên tục cải tiến và đạt được kết quả như hôm nay.

Vì vậy, việc tôi cần làm bây giờ là nói với Claude: này, tôi có thư mục phỏng vấn này. Nhưng tôi cũng sẽ bảo Claude đi xem mạng xã hội, Reddit và cả các đánh giá khách hàng của Cowork, để nói cho tôi biết đâu là các insight lớn nhất. Nó có thể mất một chút thời gian, vì nó phải xử lý rất nhiều dữ liệu và gia công chúng. Nhưng nó sẽ làm một số việc, ví dụ đôi khi nó tạo ra các sub-agent để xử lý song song, đồng thời dành thời gian để tìm kiếm trên web.

Peter Yang: Trong công việc thực tế của bạn, các bạn có kiểu báo cáo insight hằng tuần không? Tức là tự động tổng hợp tất cả rồi gửi cho bạn và cả team?

Jenny:

Thực ra bây giờ chúng tôi có thể làm trực tiếp bằng Cowork. Tôi nghĩ nhóm nghiên cứu của chúng tôi có một bản sẽ được phát ra, và chúng tôi cũng có một bản sẽ ping chúng tôi trên Slack. Chúng tôi cũng lắng nghe trực tiếp từ kênh Slack nội bộ. Chúng tôi rất phụ thuộc vào những người dùng mạnh nhất nội bộ để cung cấp phản hồi mang tính tiên phong. Bởi vì người nội bộ thực sự sẵn sàng nói thật với bạn—họ thường đẩy các tính năng đi xa nhất và cũng dễ theo dõi tiếp nhất.

Peter Yang: Tôi nghĩ đó mới là điều nên xảy ra, và tôi cũng cảm thấy hầu hết các công ty thì các nhóm bị tách rời quá nhiều. Nhưng Anthropic thì dường như không phải vậy.

Jenny:

Tôi nghĩ đây cũng là một phần quan trọng giúp Claude Code thành công—lắng nghe người dùng tuyến đầu. Và đây cũng là điều chúng tôi đã làm rất nhiều khi dùng Figma, rất nhiều dogfooding nội bộ. Bởi đặc biệt khi liên quan đến thiết kế tương tác và việc mài giũa, người nội bộ thực sự sẽ “chọc vào” các chi tiết; còn phản hồi từ người dùng bên ngoài thường nhiều hơn ở chỗ: nó có phù hợp với quy trình người dùng của họ hay không. Vì vậy nó mang lại một cấp độ phản hồi hoàn toàn khác.

Cowork vs Claude Code: ranh giới người dùng

Peter Yang: Tôi biết bộ phận marketing của Anthropic, và cả các product manager, hiện giờ về cơ bản đang dùng Claude Code để làm việc—đặc biệt là sau khi Cowork được bật khả dụng nội bộ. Bạn nghĩ sao về các loại tình huống sử dụng khác nhau? Hoặc mọi người sử dụng Cowork và Claude Code như thế nào?

Jenny:

Chúng tôi nhận thấy phạm vi ứng dụng tổng thể của Cowork đang dần mở rộng và bắt đầu được dùng trong một số tình huống giống như những nơi trước đây những người dùng tiên phong của Claude Code đã thử. Hãy nhớ lại khi chúng tôi vừa bắt đầu phát triển Cowork: nhóm sales nội bộ là nguồn thông tin chính. Trong số họ có vài người là người dùng chuyên sâu Claude Code, dùng nó để tạo danh sách khách hàng tiềm năng, viết kịch bản cuộc gọi, v.v. Khi tôi lần đầu thấy các use case đó, tôi đã rất bất ngờ, vì lúc đó thậm chí tôi còn chưa nghĩ Claude Code có thể dùng để làm những tác vụ đó. Nhưng bây giờ, những người dùng đó gần như đã chuyển hẳn sang Cowork, thậm chí đồng nghiệp của họ cũng bắt đầu dùng Cowork thường xuyên.

Là vì bây giờ có một UI nhìn đẹp. Tôi nghĩ đó là lý do thực sự khiến nó được cần đến. Và còn có một phần vì nó rất gần với các công việc khác mà họ đang làm—họ vốn đã sử dụng tính năng chat, và từ ứng dụng desktop này họ cũng tiếp tục dùng Claude Code, nên tôi thấy nó phù hợp với workflow hiện tại của họ hơn là việc mở command line.

Từ insight đến quy trình đầy đủ của Artifact có thể thực thi

Jenny:

Ở đây có bảy chủ đề khác nhau, và mỗi tuần lại khác. Tôi hầu như có thể nói ngay với nó: “Hãy tạo cho tôi tài liệu X này”, và nó đã tự động tồn tại trong một thư mục trên máy tính của tôi. Tôi cũng có thể khởi động đồng thời hai tác vụ song song. Ví dụ tôi có thể nói: “Các insight này rất tuyệt, vậy dựa trên đó thì tôi nên xây dựng những chức năng sản phẩm nào thực sự?” Rồi tôi lại có thể làm song song một việc khác—biến nội dung thành một bộ slide thuyết trình mà tôi có thể chia sẻ với team khi kickoff vào tuần này.

Nhưng cuối cùng, từ đây tôi có thể bắt đầu thiết kế quy trình—nó sẽ đưa cho tôi các tùy chọn chức năng khác nhau. Từ đó tôi thậm chí có thể nhờ Claude tạo cho tôi một số wireframe cho các chức năng đó. Nó có thể cho tôi một loạt lựa chọn khác nhau; tôi có thể mang chúng sang Figma để tinh chỉnh thật sự, hoặc mang chúng vào Claude Code, rồi dùng các thành phần của hệ thống thiết kế thực của chúng tôi để biến chúng thành các thứ “thật”. Sau đó, từ đó chúng tôi tiếp tục.

Ngoài ra, tôi cũng có thể làm hai thứ đó thành tác vụ theo lịch. Ví dụ tôi sẽ bảo nó sắp xếp cho tôi chạy tự động vào 10 giờ sáng mỗi thứ Hai. Như vậy, mỗi thứ Hai lúc 10 giờ sáng, tôi sẽ bắt đầu làm việc cả tuần với bản thuyết trình đó trong tay, cùng với ba hoặc bốn ý tưởng sản phẩm khác nhau, để kickoff cho tuần. Nó nén lại chu kỳ lặp từ phản hồi để tạo ra các thứ tangible hoặc các ý tưởng mà team có thể nhìn thấy. Nó giúp chúng tôi lặp sản phẩm nhanh chóng, và nhanh chóng làm cho sản phẩm tốt hơn.

Peter Yang: Tất cả đều là về lặp lại, tất cả đều là về lặp lại. Tôi bây giờ cũng lười hơn, tôi luôn bảo AI làm bản đầu tiên trước, rồi tôi phản hồi.

Jenny:

Đúng. Vì vậy nếu bạn thật sự muốn tôi bắt đầu từ con số 0 để sắp xếp các insight này thành một dạng ưu tiên chức năng nào đó, thì hiện tại thời gian nó mất sẽ lâu hơn rất nhiều so với trước đây.

Tôi cũng làm như vậy. Ví dụ như bạn gửi cho tôi các ghi chú podcast này: tôi có một thư mục ghi chú cá nhân, trong đó có nội dung của các cuộc họp 1:1, những ý tưởng ngẫu nhiên, v.v. Rồi tôi cứ nói: “Hãy đọc ghi chú cá nhân của tôi, giúp tôi nghĩ các ý chính để phát biểu trong podcast này, và giúp tôi nghĩ xem tôi nên nói gì ở đây.” Tất nhiên tôi sẽ không đọc y nguyên từng chữ. Nhưng nó thực sự giúp tôi mở ra tư duy, giúp tôi tiến hóa trong cách suy nghĩ, thay vì bị kẹt lại ở đó.

Skills và kho kiến thức cá nhân

Peter Yang: Bạn dùng những skills nào? Hoặc bạn có một bộ skills chuyên dùng riêng cho cá nhân để làm các tài liệu và slide không?

Jenny:

Trong nội bộ có vài skill chuyên dùng để làm tài liệu và slide, vì nó giúp chúng tôi giữ tính nhất quán về thương hiệu. Tôi thực sự không có một kho skill cá nhân. Phần lớn thời gian là tôi mượn các skill đã có sẵn trong nội bộ, rồi áp dụng cho các mục đích khác nhau.

Peter Yang: Ví dụ tôi có một writing skill, nó sẽ bảo AI đừng dùng mấy từ vựng kiểu AI slop.

Jenny:

Nhưng thực ra tôi phát hiện rằng, với các thư mục của Cowork—nơi tôi lưu tất cả các ghi chú cá nhân của mình—nó hiểu tôi thông qua các thư mục đó, và với tôi thì nó đã rất hữu ích rồi. Tôi lại thấy ngày càng không cần memory và skills nữa, vì nó đã có một kho kiến thức về tôi rồi. Tất nhiên tôi vẫn nghĩ skills có các tình huống phù hợp, nhưng với case sử dụng hiện tại của tôi thì tôi cảm thấy nhu cầu không lớn lắm.

Peter Yang: Là vì nó tự động cập nhật trí nhớ mỗi ngày dựa trên cuộc trò chuyện của bạn?

Jenny:

Vâng. Về cơ bản đó là một dạng memory do chính tôi duy trì, vì tôi luôn ghi chú trong đó.

Các điểm cộng tác trong nhóm

Peter Yang: Vậy trong toàn bộ quy trình, khi nào bạn kéo team vào? Hay là bạn lặp cùng AI rồi lại qua lại lặp với team, hay làm theo cách nào?

Jenny:

Ý của tôi là, các thứ như phỏng vấn UXR thật sự thì thực ra tôi không tự làm—mà do người làm product manager hoặc các nhà nghiên cứu trong nhóm, hoặc người khác trong team làm. Sau đó, thông qua phần đó, bạn chia sẻ artifact, kéo họ vào, và bản thân việc đó thực sự trở thành căn cứ cho cách vận hành của team.

Nhóm của chúng tôi ít nhất là khá theo hướng bottom-up và dân chủ, nên cách vận hành là: chúng tôi đưa insight và mục tiêu cho mọi người, rồi mỗi người sẽ làm prototype, thử nghiệm những thứ đó, và ý tưởng đến từ mọi hướng. Nó không phải kiểu “designer như tôi nghĩ ra tất cả phương án” mà là: “Này, đây có insight. Đây là mục tiêu mà tháng này chúng ta cần cùng đạt đến, vậy mọi người cùng đạt nó như thế nào?”

Tôi nghĩ với cách đó, chúng tôi vẫn sẽ không giao toàn bộ cho Claude làm hết. Chúng tôi vẫn dựa vào chính mình để đưa ra nhiều phán đoán, và chúng tôi là người quản lý và quyết định thật sự phải xây dựng và làm những gì.

Peter Yang: Khi mọi người nói về gu và năng lực phán đoán trên mạng, tôi nghĩ phương pháp để bồi dưỡng những năng lực đó thực chất chính là thu thập rất nhiều phản hồi về sản phẩm liên tục từ cả nội bộ lẫn bên ngoài. Trong quá trình đó, bạn dần hình thành một kiểu trực giác có thể nhận ra chỗ nào đang sai, cần được sửa. Bởi vì bạn mỗi ngày đều lắng nghe và xử lý phản hồi, lâu dần bạn sẽ có một năng lực phán đoán nhạy bén với vấn đề.

Jenny:

Còn về thiết kế, một tính năng của Claude là nó có thể tạo ra các bản phác thảo giống wireframe và đưa ra nhiều lựa chọn thiết kế. Với tư cách là một designer, tôi rất thích cách đó. Dù độ chi tiết của các phác thảo không cao, nhưng chúng cho phép tôi trực quan nhìn thấy các khả năng khác nhau mà không cần phải hoàn toàn dựa vào trí tưởng tượng của chính mình. Cách này giúp tôi quyết định nhanh hơn hướng thiết kế tiếp theo.

Vì vậy tôi nghĩ việc để Claude tạo trực tiếp các lựa chọn ban đầu này sẽ giúp tôi tiết kiệm thời gian và công sức làm wireframe thủ công. Trong số các lựa chọn đó, tôi sẽ chọn một hướng và bắt đầu lặp lại trong phạm vi nhỏ. Tiếp theo, tôi có thể dùng code để biến hướng đó thành một prototype ban đầu, rồi tiếp tục tối ưu và hoàn thiện thiết kế dựa trên nền tảng ấy.

Câu chuyện thật về sự ra đời của Cowork

Peter Yang: Bây giờ chúng ta nói về việc Cowork được tạo ra như thế nào nhé. Bên ngoài có rất nhiều câu chuyện rằng nó làm ra trong 10 ngày, nhưng thực ra trước đó đã có rất nhiều lần lặp rồi đúng không?

Jenny:

Cái câu “họ làm ra trong 10 ngày” thực ra là được trích ra từ một cuộc phỏng vấn hoặc một bài báo truyền thông nào đó, rồi mọi người cứ thảo luận xoay quanh điểm đó. Nhưng thực tế là, về hướng Cowork này, chúng tôi đã bắt đầu lên kế hoạch ngay từ khi tôi gia nhập Anthropic cách đây một năm. Chúng tôi luôn suy nghĩ cách xây dựng một “đối tác suy nghĩ” (thinking partner) có thể giúp tất cả những người làm việc tri thức nói chung. Dù Claude Code đã có thể xử lý tốt các tác vụ liên quan đến code, nhưng mục tiêu của chúng tôi là bao phủ mọi tình huống làm việc tri thức. Tôi nghĩ thách thức thực sự là: chúng tôi nên triển khai ý tưởng đó như thế nào? Kiến trúc nào phù hợp nhất? Và trải nghiệm người dùng (UX) nào là đúng?

Trong suốt một năm qua, chúng tôi đã thử rất nhiều prototype khác nhau. Có những ý tưởng còn lớn hơn cả mục tiêu hiện tại. Chúng tôi cũng tiến hành nhiều thí nghiệm kỹ thuật, thử các khung framework cho AI agent, nhưng một số thử nghiệm không thành công. Cuối cùng, chúng tôi mới dần dần xác định được hướng đi hiện tại. Chúng tôi không chỉ tham khảo các prototype do đội trong phòng thí nghiệm phát triển, mà còn nghiên cứu các prototype mà đội sản phẩm của chúng tôi tự xây dựng. Cuối cùng, thời điểm và năng lực thực thi trở thành yếu tố then chốt—giống như tia sét đúng lúc trúng đích.

Khi chúng tôi quyết định phát hành sản phẩm này, toàn bộ quá trình diễn ra rất nhanh—từ lúc “chúng ta nên ra mắt rồi” đến khi “sản phẩm đã lên”, chỉ mất 10 ngày. Lý do chính là vì trong kỳ nghỉ của Claude Code, chúng tôi đã nhìn thấy tiềm năng của nó. Trong kỳ nghỉ, nhiều người cuối cùng cũng có thời gian để thử dùng Claude Code, thậm chí cả một số người không thuộc nhóm kỹ thuật cũng bắt đầu dùng nó: ví dụ dùng nó để phân tích bản transcript podcast hoặc để phân tích dữ liệu phức tạp. Chúng tôi nhận thấy khung framework cho agent của Claude Code cũng bắt đầu cho thấy độ phù hợp thị trường ban đầu (product-market fit) ngay cả trong nhóm người dùng không kỹ thuật. Thực ra lúc đó nội bộ chúng tôi đã có một prototype có thể chạy được, ban đầu dự định sẽ ra mắt muộn hơn. Nhưng các phản hồi khiến chúng tôi nhận ra “giờ mới là thời điểm tốt nhất”. Và thế là chúng tôi nắm lấy cơ hội này, cuối cùng có được 10 ngày điên rồ đó.

Peter Yang: Nếu tôi hiểu đúng, trong năm qua các bạn đã chia sẻ rất nhiều prototype trong Slack nội bộ, thu thập rất nhiều phản hồi, rồi cuối cùng chốt một prototype khả thi. Rồi vì nhìn thấy thị trường có nhu cầu, các bạn đã hoàn thành một đợt sprint nhanh và đẩy sản phẩm ra.

Jenny:

Đúng, đại khái là như vậy. Chúng tôi vốn định vài tuần nữa mới ra mắt, nhưng lúc đó chúng tôi cảm thấy “bây giờ chính là thời điểm tốt nhất”. Điều này cũng khiến chúng tôi—trong bối cảnh thời gian gấp—thu hẹp phạm vi sản phẩm xuống mức thực tế khả thi hơn, và dồn toàn bộ tinh lực cùng nguồn lực, cuối cùng thành công khi phát hành.

Lặp lại thiết kế ban đầu: Từ công cụ workflow đến Chat tối giản

Peter Yang: Bạn có thể chia sẻ một số kinh nghiệm về các lần lặp ban đầu, hoặc trưng bày những thứ đang được phát triển không?

Jenny:

Tất nhiên. Tôi đã cố tình sắp xếp một số ảnh chụp màn hình sớm, có thể cho thấy cách nghĩ và quá trình lặp lại thiết kế của chúng tôi lúc đó.

Vào đầu năm nay, chúng tôi có một prototype sớm—được hoàn thành nhờ sự hợp tác giữa tôi và một designer khác. Lúc đó, chúng tôi thử làm cho công cụ này thiên về định hướng nhiệm vụ (task-oriented) hoặc định hướng workflow (workflow-oriented). Bởi vì chúng tôi rất lo người dùng có hiểu được cách dùng một sản phẩm như Cowork hay không, liệu họ có thể hoàn thành một số nhiệm vụ cụ thể hay đạt được một kết quả rõ ràng (outcome) hay không—ví dụ như tạo một dashboard, hoặc tổng hợp dữ liệu từ nhiều nguồn khác nhau. Vì vậy, lúc đó chúng tôi thiết kế giao diện người dùng rất có cấu trúc, gần như như một công cụ workflow—chẳng hạn như “thêm nội dung này, đây là input (inputs), đây là output (outputs)”. Còn tính năng chat được đặt ở vị trí thứ yếu.

Nhưng cảm giác là để làm được mọi thứ lại cần quá nhiều bước. Năm 2025 rồi, vậy tại sao chúng ta còn phải phức tạp như thế? Chẳng phải cứ để Claude xử lý cho không phải sao?

Đó là một hướng thiết kế sớm. Nhưng sau đó chúng tôi quyết định đổi hướng—làm cho nó đơn giản hơn, giống như một ô chat (chat box). Chúng tôi thử dẫn dắt người dùng đạt đến các mục tiêu cụ thể hơn thông qua cách này, như phân tích hoặc tạo tài liệu. Chúng tôi cũng thiết kế một prototype mang tính chức năng: sau khi người dùng bấm vào, họ sẽ thấy nhiều lựa chọn, và mỗi lựa chọn có các nút để điều chỉnh—ví dụ như độ dài tài liệu, hoặc chọn kiểu tài liệu như memo hoặc slide thuyết trình. Nhưng cuối cùng thì thiết kế này khiến người dùng cảm thấy quá phức tạp và nặng nề.

Vì vậy, sau nhiều lần khám phá và thử nghiệm, chúng tôi liên tục tìm điểm cân bằng: rốt cuộc chúng tôi nên xác định rõ hơn các use case, hay giữ kiểu tự do như chat box.

Phiên bản mà chúng tôi phát hành cách đây vài tuần chính là như hiện tại. Trước đó, chúng tôi đã thử một trải nghiệm gần giống “chế độ hướng dẫn” (wizard-like): người dùng bấm vào sẽ thấy lời gợi ý như “tạo một tài liệu, độ dài là ba đến năm trang”, v.v.

Lúc đó chúng tôi cũng thêm rất nhiều yếu tố vào giao diện với hi vọng nó trông khác với một ô chat thông thường. Nhưng rồi phát hiện ra rằng kiểu thiết kế này làm giao diện quá phức tạp, các yếu tố thị giác cạnh tranh quá mạnh với nhau. Vì thế chúng tôi quyết định đơn giản hóa thiết kế, loại bỏ phần lớn các yếu tố không cần thiết.

Giao diện người dùng mà bạn thấy bây giờ đã được đơn giản hóa đáng kể. Chúng tôi đã bỏ các sidebars nặng nề (sidebars), để nó giống một ô chat truyền thống hơn. Nhưng ở trang chủ chúng tôi có vài chỉnh sửa để nó trông giống hơn một “danh sách việc cần làm” (to-do list) do chính tôi và Claude cùng chia sẻ, thay vì một công cụ chat tràn đầy các gợi ý và hướng dẫn phức tạp.

Peter Yang: Có lẽ trong tương lai nó có thể hỗ trợ nhiều agent (tác nhân), và bạn có thể kéo-thả nhiệm vụ lên để quản lý workflow.

Jenny：：

Có thể trong tương lai sẽ có khả năng như vậy. Nhưng tôi muốn nhấn mạnh rằng thiết kế UI khoảng bốn, năm tuần trước còn hoàn toàn khác. Chúng tôi liên tục học hỏi và khám phá kiểu thiết kế nào hiệu quả, kiểu nào không hiệu quả, đồng thời cố gắng tìm ra cách tốt nhất để trình bày công nghệ này cho người dùng.

Định vị khác biệt giữa Cowork và Claude Code

Peter Yang: Khi dùng Claude Code, tôi thường chia sẻ một số phản hồi trên Twitter. Nó có rất nhiều lệnh dạng slash (slash commands) cài sẵn, và người dùng phải học dần dần. Trải nghiệm này hơi giống việc đi Costco “săn kho báu” (treasure hunt), bạn không bao giờ biết sẽ tìm thấy tính năng mới gì.

Nhưng với người mới bắt đầu, cách đó không thân thiện lắm. Nó giống như một trò chơi: càng dùng lâu bạn càng quen và càng nắm được cách dùng. Tôi có cảm giác Cowork đang thử khám phá vùng trung gian giữa công cụ chat thông thường và Claude Code. Nó không ẩn tất cả tính năng đi, nhưng cũng có một cách nào đó để dẫn dắt người dùng dùng nó tốt hơn.

Jenny：

Đúng. Trong Cowork vẫn hỗ trợ slash commands (slash commands), nhưng chúng không phải là phương thức tương tác chính. Theo quan sát của tôi, ít nhất Cowork là một công cụ hướng tới người chuyên nghiệp. Chúng tôi thấy nhiều người dùng đã sử dụng nó theo kiểu của người dùng nâng cao, và trong cộng đồng cũng đã xuất hiện một số người dùng nâng cao. Những người này thường sẵn sàng dành thời gian học các tính năng phức tạp hơn, chẳng hạn như tự tạo skills (skills), chia sẻ với team, hoặc dùng lệnh viết tắt (shorthand commands).

Nhưng mục tiêu của chúng tôi là khiến các tính năng đó trở thành một phương thức tương tác phụ, không phải nội dung buộc người dùng phải học. Tức là kể cả khi người dùng không biết hết các lệnh, họ vẫn có thể dùng Cowork một cách dễ dàng. Chúng tôi muốn tương tác của người dùng với Claude là tự nhiên và trực quan, chứ không phải bắt buộc phải ghi nhớ một loạt các lệnh thì mới làm được.

Quy hoạch quy trình và tầm nhìn

Peter Yang: Quy trình lập kế hoạch của Anthropic như thế nào? Các bạn có làm kế hoạch hằng năm và đặt mục tiêu không, hay chủ yếu dựa vào phát triển prototype và không ngừng thử nghiệm?

Jenny:

Cách chúng tôi lên kế hoạch mỗi lần lại khác nhau. Ở đội của tôi, chúng tôi làm kế hoạch theo tháng. Chúng tôi có một bảng tính, ít nhất ở phần Cowork, nhiều nhất liệt kê khoảng 12 nhiệm vụ—đều là các ưu tiên hàng đầu của chúng tôi (P0). Mỗi nhiệm vụ có một người chịu trách nhiệm trực tiếp (DRI), và mỗi tuần chúng tôi đều kiểm tra: liệu chúng tôi có còn đi đúng quỹ đạo không? Chúng tôi cũng làm một số kế hoạch theo quý hoặc nửa năm. Thường là do một người phụ trách chỉ ra: “Tôi nghĩ chúng ta nên phát triển theo hướng này, và đây là những thứ chúng ta cần chú ý.” Nhưng các kế hoạch đó không nghiêm ngặt đến mức phải nhất định thực hiện các dự án cụ thể. Nhiều hơn là cung cấp một định hướng tổng thể cho team, nên tương đối linh hoạt.

Peter Yang: Linh hoạt đúng không? Điều thú vị là tôi thấy các công ty càng đổi mới càng ít làm kế hoạch theo năm, mà thay vào đó liên tục lặp và học từ người dùng. Trong sự nghiệp bạn có làm những thứ tương tự một North Star vision deck không? Bạn nghĩ nó có hữu dụng không?

Jenny:

Tôi có. Năm ngoái tôi từng làm một North Star vision deck. Tôi nghĩ tầm nhìn thực sự có giá trị: nó chỉ đường cho team và giúp chúng tôi giữ rõ ràng trong các công việc sắp tới. Nhưng vì lĩnh vực kỹ thuật của chúng tôi thay đổi cực nhanh, các mô hình mới liên tục xuất hiện, tốc độ cập nhật cũng ngày càng nhanh. Vì vậy, việc đặt tầm nhìn cho một năm là không thực tế với chúng tôi, chứ đừng nói đến hai đến năm năm, vì có quá nhiều yếu tố chưa biết.

Tuy nhiên, vai trò thật sự của tầm nhìn là dẫn mọi người đi cùng một hướng, đặc biệt trong môi trường mà mọi người đều có thể tự do xây dựng các dự án của riêng họ. Vì vậy hiện tại tôi nghĩ khoảng thời gian cho tầm nhìn tối đa là từ ba đến sáu tháng, và nó có thể được trình bày dưới dạng tài liệu. Tôi cảm thấy khi tầm nhìn được trực quan hóa thì nó có tác động lớn hơn. Đó cũng là giá trị rất lớn của thiết kế—có thể tích hợp nhiều yếu tố khác nhau, và trong một khoảng thời gian nhất định, kể một câu chuyện liền mạch. Tất nhiên tầm nhìn cũng có thể là một prototype chứ không chỉ là một deck tĩnh. Nó có thể giúp chúng tôi phối hợp công việc giữa các team, đặc biệt khi có năm team đang xử lý các dự án rất giống nhau hoặc có thể xung đột. Thiết kế có thể giúp các ý tưởng này hội tụ thông qua việc “curate” (chọn lọc và tổ chức), và trình bày cho chúng tôi một lộ trình hướng tới trải nghiệm người dùng lý tưởng, thay vì trải nghiệm bị phân tán.

Peter Yang: Vậy các bạn có các buổi review của product manager không, hoặc review cho những người liên quan không? Các buổi review này có chính thức không, hay họ cũng tham gia vào quá trình thiết kế prototype?

Jenny:

Chúng tôi có review, nhưng không giống như trước đây ở một số công ty là cứ mỗi tính năng đều phải review. Review của chúng tôi chủ yếu dành cho các dự án lớn hơn và ưu tiên cao hơn. Mục đích của review không phải là tốn nhiều thời gian chuẩn bị, mà là để tăng tính hiển thị cho dự án và lấy phản hồi. Nếu có các dự án quan trọng ảnh hưởng đến công ty hoặc liên quan đến nhiều team thì chúng tôi sẽ tiến hành review đó.

Gợi ý cho designer: cách tìm vị trí trong thời đại AI

Peter Yang: Vậy đối với những designer cảm thấy môi trường nghề nghiệp của mình đang thay đổi nhanh chóng, bạn có lời khuyên gì? Liệu họ nên bắt đầu học cách submit code (PR) không, hay designer nên thích nghi theo cách khác?

Jenny:

Nếu bạn cảm thấy mặt đất dưới chân đang di chuyển, thì đó là vì nó thật sự đang thay đổi. Chúng ta phải thừa nhận điều đó và học cách thích nghi, đồng thời với một thái độ cởi mở, nhìn lại cách làm việc hiện tại của chúng ta. Tôi nghĩ những thay đổi hiện tại tác động đặc biệt lớn đến designer, nhất là vì chúng ta đang ở “làn sóng thứ hai” của cơn sóng này. Những vai trò nghề nghiệp khác cũng đã trải qua các lần chuyển đổi tương tự, và bây giờ thì đến lượt chúng ta. Đồng thời, các công cụ thiết kế của chúng tôi cũng không ngừng tiến hóa.

Mỗi khi tôi cảm thấy nghề nghiệp của mình bị thách thức, tôi lại thấy hơi bất an, kiểu như: “Chết tiệt, công việc của mình đang thay đổi quá lớn, liệu người ta có còn coi trọng công việc của mình như trước nữa không?” Nhưng lúc đó tôi lại nghĩ đến các đồng nghiệp kỹ sư của tôi. Họ đã trải qua những biến đổi lớn trong công việc từ lâu rồi, nhưng họ không chỉ thích nghi với những thay đổi đó, mà còn đón nhận thử thách với rất nhiều can đảm và sự khiêm tốn, cuối cùng đạt được kết quả làm việc hiệu quả và xuất sắc hơn. Họ là nguồn cảm hứng của tôi—tôi sẽ nhắc bản thân rằng nếu những đồng nghiệp mà tôi vô cùng kính trọng có thể làm được, thì tôi cũng nhất định làm được. Họ là tấm gương thích nghi với thay đổi.

Peter Yang: Nói theo một cách nào đó, những thay đổi này giúp designer thoát khỏi rất nhiều công việc lặp lại phiền phức—ví dụ không còn phải mất thời gian chỉnh sửa các khung ô hộp đủ kiểu nữa, đúng không? Như vậy bạn có thể dồn nhiều thời gian hơn cho tư duy ở cấp độ cao và công việc sáng tạo.

Jenny:

Đúng. Hoặc nói cách khác, những thay đổi này cho phép chúng tôi làm được nhiều việc hơn. Ví dụ, khi tôi thấy các đồng nghiệp kỹ sư của mình bây giờ có thể hoàn thành một tính năng hoàn chỉnh chỉ trong vài ngày, trong khi trước đây có thể phải mất vài tuần, tôi thực sự cảm thấy rất choáng ngợp. Vì vậy, vâng, những thay đổi này cũng mang đến nhiều khả năng hơn.