Bỏ qua đến nội dung chính

The design process is dead. Here’s what’s replacing it. | Jenny Wen (head of design at Claude)

TL;DR

  • Quy trình thiết kế truyền thống đã lỗi thời do sự phát triển nhanh chóng của kỹ thuật và AI, đòi hỏi các nhà thiết kế phải thay đổi trọng tâm công việc.
  • Vai trò của nhà thiết kế đang dịch chuyển từ việc tạo ra các bản mock đẹp đẽ sang hỗ trợ thực thi kỹ thuật, tinh chỉnh sản phẩm ở chặng cuối và định hình tầm nhìn chiến lược ngắn hạn.
  • Thiết kế giờ đây tập trung nhiều hơn vào việc tạo nguyên mẫu bằng mã nguồn thực tế và học hỏi từ dữ liệu người dùng thực, đặc biệt khi làm việc với các mô hình AI không xác định.

iterate

Old: mockups in Figma

New: prototype in real code

Designer shapes near-term vision

Designer polishes last mile

Learn from real user data

Điểm chính

  • Từ bỏ quy trình thiết kế cũ: Quy trình nghiên cứu, khám phá, phân kỳ và hội tụ truyền thống đã lỗi thời, đặc biệt với khả năng phát triển nhanh chóng của kỹ sư và AI.
  • Hỗ trợ thực thi là ưu tiên: Các nhà thiết kế cần dành ít thời gian hơn cho việc tạo bản mock và nhiều thời gian hơn để giúp đỡ kỹ sư và đội ngũ thực thi, hướng dẫn họ trong quá trình phát triển.
  • Tầm nhìn ngắn hạn và nguyên mẫu: Tầm nhìn thiết kế đã rút ngắn từ 2-10 năm xuống còn 3-6 tháng, thường được truyền đạt qua các nguyên mẫu chức năng hơn là bản trình bày phức tạp.
  • Phân cấp công việc thiết kế: Công việc thiết kế đang phân cấp thành hai loại: (1) hỗ trợ triển khai/thực thi và (2) tạo ra tầm nhìn/định hướng chiến lược.
  • Chủ động với công cụ lập trình: Nhà thiết kế nên tận dụng các công cụ lập trình và tham gia vào "chặng cuối" của việc triển khai, bao gồm cả tinh chỉnh và tạo nguyên mẫu bằng mã nguồn thực tế.
  • Học hỏi từ dữ liệu thực: Với sự không xác định của các mô hình AI, việc thử nghiệm sản phẩm với dữ liệu và người dùng thực tế quan trọng hơn việc tạo ra các bản mock chi tiết, vì bạn không thể đoán trước được tất cả các trường hợp sử dụng.
  • Thích ứng với sự thay đổi rộng khắp: Sự thay đổi trong quy trình thiết kế không chỉ giới hạn ở các công ty AI tiên phong mà đang lan rộng khắp ngành, mặc dù vẫn còn một số phản ứng tiêu cực từ những người gắn bó với quy trình cũ.

Từ vựng

  • design process — quy trình thiết kế
  • designer — nhà thiết kế
  • mock — bản thiết kế giả/bản nháp
  • prototyping — tạo nguyên mẫu
  • engineer — kỹ sư
  • implementation/execution — thực thi/triển khai
  • vision — tầm nhìn
  • deck — bản trình bày
  • agent — tác nhân (trong ngữ cảnh AI)
  • AI (Artificial Intelligence) — Trí tuệ nhân tạo (AI)
  • bleeding edge — ranh giới tiên phong
  • last mile — chặng cuối (trong triển khai)
  • use cases — trường hợp sử dụng
  • stratified — phân cấp

Nội dung chi tiết

Giới thiệu về sự thay đổi của quy trình thiết kế

Quy trình thiết kế mà các designer đã được dạy, chúng ta coi nó như một điều răn. Điều đó về cơ bản đã lỗi thời. Với tư cách là một designer, bạn thực sự không còn thời gian để tạo ra những bản mock đẹp đẽ nữa. Một phần lớn của vai trò thiết kế hiện nay là giúp các kỹ sư và đội ngũ thực thi, chứ không chỉ đơn thuần là nói với họ "đây là bản thiết kế". Vài năm trước, 60 đến 70% công việc là tạo mockprototyping. Nhưng bây giờ tôi cảm thấy phần mocking up chỉ còn khoảng 30 đến 40%. Bạn không nên ngăn cản điều đó, hãy để họ "nấu" (cook). Không chỉ các designer cảm thấy như "ồ, chúng ta phải bắt kịp các kỹ sư". Tôi nghĩ ngay cả các kỹ sư cũng tự hỏi "làm sao chúng ta có thể tự mình bắt kịp?" "Làm sao chúng ta có thể bắt kịp với tất cả các tác nhân (agent) của mình? Có bảy tác nhân (agent) đang liên tục chạy."

Kết quả của việc kỹ thuật thay đổi rất nhiều là thiết kế buộc phải thay đổi. Chúng ta từng lập tầm nhìn (vision) 2 năm, 5 năm, thậm chí 10 năm. Giờ đây, đó là một tầm nhìn (vision) chỉ từ 3 đến 6 tháng và không nhất thiết phải tạo ra một bản trình bày (deck) đẹp mắt. Đôi khi chỉ là tạo một nguyên mẫu (prototype) hướng mọi người đi đúng hướng. Boris gần đây đã chia sẻ trên podcast rằng Claude Code hiện đang giúp anh ấy đưa ra các ý tưởng. Chúng ta sẽ giỏi hơn về gu thẩm mỹ (taste) và đánh giá (judgement), cũng như thiết kế. Chúng ta có thể đang giữ chặt điều đó quá mức. Vậy bộ não con người sẽ tiếp tục có giá trị ở đâu? Cuối cùng, ai đó phải quyết định điều gì thực sự sẽ được xây dựng và điều gì thực sự quan trọng. Ai đó vẫn cần phải chịu trách nhiệm về quyết định.

Bạn tìm kiếm điều gì khi tuyển dụng designer? Hiện tại có lẽ có ba kiểu người mà tôi đặc biệt quan tâm.

Phỏng vấn Jenny Wen về tương lai của thiết kế

Khách mời hôm nay là Jenny Wen. Jenny từng là trưởng bộ phận thiết kế cho Claude, và hiện đang dẫn dắt thiết kế cho Claude Co-work. Trước đó, cô là giám đốc thiết kế tại Figma, nơi cô lãnh đạo các đội ngũ thiết kế đứng sau FigJamSlides. Cô cũng từng là designer tại Dropbox, SquareShopify. Điều tôi yêu thích ở cuộc trò chuyện này là Jenny đang sống trong tương lai nơi ngành thiết kế đang hướng tới. Và cô ấy ở đây để cho chúng ta một cái nhìn thoáng qua về điều đó trông như thế nào và mọi thứ sẽ thay đổi ra sao đối với các designer. Điều đó khá hoang dã và cực kỳ thú vị. Xin chân thành cảm ơn No. 111 và Emily Lin Hasham đã gợi ý các chủ đề và câu hỏi cho cuộc trò chuyện này. Đừng quên truy cập lennisproass.com để khám phá một bộ ưu đãi đáng kinh ngạc dành riêng cho những người đăng ký newsletter của Lenny. Hãy cùng bắt đầu sau một vài lời nhắn từ các nhà tài trợ tuyệt vời của chúng ta.

Lời nhắn từ nhà tài trợ: Mercury

Tập này được tài trợ bởi Mercury, ngân hàng khác biệt triệt để được hơn 300.000 doanh nhân (entrepreneurs), bao gồm cả tôi, yêu thích. Tôi đã chuyển sang Mercury từ Chase hơn một năm trước và đó là một trải nghiệm tốt hơn đáng kể. Giống như một người chuyên về sản phẩm đã xây dựng một ngân hàng, thay vì một người làm trong ngành ngân hàng xây dựng một sản phẩm. Nó nhanh chóng. Nó thanh lịch. Nó siêu dễ dàng để thiết lập chuyển khoản điện tử (wires), theo dõi chi tiêu của tôi, thiết lập các kích hoạt (triggers) để chuyển tiền khi tài khoản xuống thấp. Chúng tôi đã chuyển tất cả các hoạt động xuất hóa đơn (invoicing) của mình sang Mercury. Và đó là một trải nghiệm mượt mà hơn bất cứ điều gì chúng tôi đã thử. Nó cũng thực sự dễ dàng để cấp cho những người trong nhóm của bạn đúng mức quyền truy cập (access) để giúp giảm tải công việc của bạn. Bắt đầu miễn phí. Không cần đến trực tiếp, không số dư tối thiểu (minimum balances). Sản phẩm cũng linh hoạt phù hợp với mọi quy mô công ty, từ các startup đến các enterprise lớn. Chỉ cần truy cập mercury.com để tìm hiểu thêm và đăng ký trực tuyến trong vài phút. Mercury là một công ty fintech, không phải là một ngân hàng được FDIC bảo hiểm. Các dịch vụ ngân hàng được cung cấp thông qua Choice Financial GroupColumn NA members FDIC.

Lời nhắn từ nhà tài trợ: Orcus

Tập này được tài trợ bởi Orcus, công ty đứng sau Conductor mã nguồn mở, nền tảng điều phối (orchestration platform) hỗ trợ các ứng dụng enterprise hiện đại. Các hệ thống hiện đại được xây dựng trên microservices, API và các kiến trúc hướng sự kiện (event-driven architectures). Nhưng các công cụ tự động hóa (automation tools) cũ không thể theo kịp. Các nền tảng low code bị cô lập, quản lý quy trình (process management) lỗi thời và công cụ API (API tooling) không kết nối sẽ sụp đổ dưới quy mô thực tế và sự thay đổi liên tục. Orcus Conductor cung cấp một lớp điều phối (orchestration layer) cấp sản xuất (production grade) để phối hợp các microservices, API, đường dẫn dữ liệu (data pipelines), tác vụ con người (human tasks) và các quy trình làm việc dựa trên tác nhân (agentic workflows) với kiểm soát luồng xác định (deterministic control flow), thử lại (retries), khả năng quan sát (observability) và quản trị (governance). Được xây dựng cho quy mô enterprise, Orcus hỗ trợ phát triển theo hướng trực quan (visual) và mã nguồn (code first) với tuân thủ (compliance) và độ tin cậy (reliability) tích hợp thông qua cổng MCP (MCP gateway) tích hợp sẵn. Tác nhân AI (AI agents) xử lý suy luận (reasoning) và ra quyết định (decision-making) trong khi truy cập an toàn các API hiện có và các hệ thống nội bộ với vai trò công cụ MCP (MCP tools). Điều này cho phép các tác nhân (agent) hoạt động trong các môi trường enterprise và mở rộng từ các bản demo đến sản xuất (production), phối hợp các hệ thống, tác nhân (agent) và con người cùng nhau để mang lại kết quả thông minh hơn một cách nhanh chóng hơn. Tìm hiểu thêm tại orcus.io/lenny. Đó là o-r-k-e-s.io/lenny.

Tác động của trí tuệ nhân tạo (AI) lên quy trình thiết kế

Jenny, cảm ơn bạn rất nhiều vì đã có mặt ở đây và chào mừng bạn đến với podcast.

Vâng, rất vui được ở đây.

Tôi đã mong chờ cuộc trò chuyện này vì tôi đã dành rất nhiều thời gian trên podcast này để nói về tương lai của kỹ thuật phần mềm (software engineering), vai trò đó đang thay đổi như thế nào, vai trò của quản lý sản phẩm (product management), vai trò đó đang thay đổi như thế nào. Tôi chưa dành nhiều thời gian để nói về cách thiết kế đang thay đổi. Rõ ràng nó cũng đang thay đổi một cách thực sự lớn và bạn có một chỗ ngồi hàng đầu (front row seat) để chứng kiến mọi thứ đang đi về đâu. Tôi cũng biết bạn có rất nhiều quan điểm mạnh mẽ (strong opinions) về nơi mọi thứ đang hướng tới. Vì vậy, có rất nhiều điều tôi muốn nói. Tôi muốn bắt đầu với câu hỏi rộng này: Quy trình thiết kế đang thay đổi như thế nào với sự trỗi dậy của trí tuệ nhân tạo (AI)?

Nó đang thay đổi rất nhiều. Tôi nghĩ rằng nó vẫn còn một chặng đường dài phải đi về cách nó đang thay đổi. Tôi nghĩ chúng ta đã thực sự thấy, bạn biết đấy, kỹ thuật (engineering) thay đổi nhiều hơn trong thời gian gần đây so với thiết kế. Nhưng tôi nghĩ kết quả của việc kỹ thuật thay đổi rất nhiều là thiết kế buộc phải thay đổi.

Vì vậy, tôi nghĩ một số ngữ cảnh (context) xung quanh điều này là tôi đã có một buổi nói chuyện tại một hội nghị ở Berlin vài tháng trước vào tháng 9 và tôi gọi nó là "đừng tin vào quy trình thiết kế" (don't trust the design process), nơi tôi về cơ bản chỉ nói rằng, bạn biết đấy, quy trình thiết kế mà các designer đã được dạy – nơi bạn đi và thực hiện một loạt nghiên cứu (research) và khám phá (discovery), rồi bạn phân kỳ, hội tụ, phân kỳ, hội tụ – và đó là một quy trình mà chúng ta coi như kinh thánh (gospel) và cố gắng hết sức để bảo tồn, và chúng ta đã nói "tin vào quy trình" (trust the process). Điều đó về cơ bản đã lỗi thời. Tôi nghĩ nó đã chết dần (dying) trước thời đại AI (age of AI), nhưng bây giờ khi các kỹ sư có thể tự phát triển "bảy Claude" của riêng họ, tôi nghĩ với tư cách là designer, chúng ta thực sự phải từ bỏ quy trình đó. Và tôi nghĩ đó là điều lớn lao đang thay đổi.

Nhưng tôi nghĩ ngay cả trong ba đến bốn tháng qua kể từ khi tôi thực hiện buổi nói chuyện đó, buổi nói chuyện đó thực sự bắt đầu cảm thấy khá... nó hơi lỗi thời đối với tôi, điều này hơi đáng xấu hổ. Nhưng đặc biệt với sự thay đổi lớn của phiên bản Opus 46 và nhiều người đã thực sự khám phá và sử dụng Claude Code trong kỳ nghỉ lễ, tôi nghĩ chúng ta đang chứng kiến sự thay đổi quy trình của mình diễn ra mạnh mẽ hơn nữa. Cách tôi nhìn nhận nó bây giờ là có hai loại công việc thiết kế và công việc thiết kế đang trở nên rất phân cấp (stratified) trong thế giới mới này.

Hai loại hình công việc thiết kế mới

Vậy có loại hình thứ nhất thực sự chỉ là hỗ trợ triển khai (implementation) và thực thi (execution). Đây là loại hình mà các kỹ sư đang sử dụng "bảy Claude" của họ để tạo ra tất cả các tính năng này và bất kỳ ai cũng có thể đưa ra một ý tưởng, và bạn có thể nói về một ý tưởng, và ai đó, thường là một kỹ sư (bởi vì họ vẫn giỏi triển khai những thứ này hơn chúng ta), họ sẽ tạo ra một phiên bản sơ bộ của nó và bạn có thể dùng thử. Và với tư cách là một designer, bạn thực sự không còn thời gian để tạo ra những bản mock đẹp đẽ này nữa hoặc để dẫn dắt theo cách này.

Và sau đó tôi nghĩ có loại hình công việc thứ hai cũng rất quan trọng, đó là tạo ra tầm nhìn (vision) hoặc định hướng (direction) cho mọi thứ. Loại hình này cảm thấy khó khăn nhất để dành thời gian và nó vẫn là một loại hình mà chúng ta vẫn làm trước đây, nhưng tôi nghĩ hình dạng của nó đang thay đổi rất nhiều bởi vì tôi nghĩ chúng ta từng nói rằng chúng ta sẽ thực hiện tầm nhìn thiết kế (design vision) này. Chúng ta sẽ tạo ra một tầm nhìn (vision) 2 năm, 5 năm, thậm chí 10 năm và chúng ta sẽ hướng mình đến một điều gì đó. Nhưng cách công nghệ đang thay đổi bây giờ, chúng ta thực sự không biết, chúng ta không biết điều gì sẽ xảy ra trong 2 năm tới. Có quá nhiều thứ đang thay đổi và nó thường trở thành một tầm nhìn (vision) từ 3 đến 6 tháng và không nhất thiết là thứ tạo ra một bản trình bày (deck) đẹp mắt, được kể chuyện một cách tuyệt vời. Đôi khi chỉ là tạo một nguyên mẫu (prototype) hướng mọi người đi đúng hướng. Và tôi nghĩ loại hình công việc này vẫn thực sự quan trọng trong thế giới này, bởi vì trong một thế giới nơi mọi người có thể phát triển "bảy Claude" của riêng họ, tạo ra bất kỳ tính năng nào họ muốn theo bất kỳ định hướng (direction) hoặc triển khai (implementation) nào, bạn cần phải hướng họ đến một điều gì đó. Và để đảm bảo rằng tất cả chúng ta đang tạo ra thứ gì đó có ý nghĩa cùng nhau và cũng được thực hiện một cách hiệu quả (efficient), phải không? Giống như nếu tất cả chúng ta đang làm việc vì một mục đích lớn hơn (greater cause), điều đó sẽ hiệu quả (efficient) hơn nhiều so với việc chỉ làm những điều ngẫu nhiên. Và đó là sự thay đổi lớn mà tôi đang thấy và tôi nghĩ tôi có ý kiến ​​về nó bây giờ, nhưng hãy hỏi tôi trong khoảng 3 tháng nữa và nó thực sự có thể thay đổi nhiều hơn nữa.

Sự thay đổi lan rộng trong ngành thiết kế

Vậy điều bạn đang nói ở đây không phải là bạn hay lĩnh vực thiết kế đang nói "chúng ta cần thay đổi". Mà là kỹ thuật (engineering) và thực tế là bạn có thể xây dựng rất nhanh chỉ đơn giản là buộc vai trò của một designer phải thay đổi vì như bạn đã nói, các kỹ sư có thể liên tục "phát hành" (ship), "phát hành", "phát hành", "phát hành" và điều bạn đang nhận thấy ở đây là tốt hơn hết là không cản trở điều đó, cứ để họ "nấu" (cook) như người ta vẫn nói, và sau đó có một kiểu giúp đỡ họ trong quá trình họ "phát hành", tập hợp nó lại, đảm bảo mọi thứ kết nối với nhau, hướng dẫn họ một chút.

Vâng, tôi nghĩ vậy. Vâng, tôi không nghĩ có một tiếng nói thống nhất nào nói rằng các designer, chúng ta cần thay đổi ngay bây giờ, nhưng vâng, có những hệ quả (follow-on effects) từ việc các công cụ kỹ thuật (engineering tooling) thực sự thay đổi. Tôi nghĩ chúng ta có thể sẽ thấy công cụ thiết kế (design tooling) cũng thay đổi trong năm tới hoặc lâu hơn. Nhưng rất nhiều trong số đó hiện đang đi sau. Và tôi nghĩ điều đó cũng thực sự trao quyền cho chúng ta, bởi vì với tư cách là designer, chúng ta giờ đây cũng có quyền truy cập vào rất nhiều công cụ lập trình (coding tools) này và chúng ta có thể là một phần của quy trình theo cách mà chúng ta đang triển khai (implementing) mọi thứ. Giống như tôi đang làm rất nhiều công việc chặng cuối (last mile) nơi tôi triển khai tất cả sự tinh chỉnh (polish) và làm việc rất chặt chẽ với các kỹ sư để đưa tính năng đi đúng hướng và cũng nguyên mẫu (prototype) mọi thứ bằng mã nguồn (code) thực tế thay vì dựa vào các kỹ sư để làm điều đó.

Bạn nghĩ điều này đúng đến mức nào ở tất cả các công ty, chẳng hạn như các công ty AI (AI companies), các công ty không phải AI (non-AI companies)? Bạn biết đấy, ai đó có thể nghe điều này: "Được rồi, Anthropic Claude, được rồi, giống như họ đang ở ranh giới tiên phong (bleeding edge)." Một là, hai là, giống như nhà phát triển (developer) một chút, nhưng tôi nghĩ mọi người có thể cảm thấy như "được rồi, điều này sẽ không xảy ra ở Salesforce, điều này sẽ không xảy ra ở, tôi không biết, ServiceNow hay bất cứ đâu." Vậy tôi đoán bạn có cảm thấy đây là nơi tất cả các nhóm đang hướng tới không? Nó chủ yếu là các công ty AI ranh giới tiên phong (bleeding edge)? Bạn nghĩ sự thay đổi quy trình thiết kế này sẽ lan rộng đến mức nào?

Buổi nói chuyện tôi đã làm năm ngoái kỳ lạ thay lại là buổi nói chuyện gây tiếng vang nhất mà tôi từng làm và tôi nghĩ đó là điều mà mọi người đang bắt đầu cảm thấy trên toàn ngành, nơi họ nói "ồ vâng, chúng ta không thể sử dụng quy trình thiết kế cũ nữa."

Sự Thay Đổi trong Quy Trình Thiết Kế với AI

Chúng tôi đang sử dụng các công cụ AI như Claude Code, Bzero và nhiều công cụ AI khác để bắt đầu xây dựng các bản prototype. Các quản lý sản phẩm (PM) cũng đang bắt đầu tạo các bản prototype và những thứ tương tự. Vì vậy, tôi nghĩ rằng có một điều gì đó mới đang xuất hiện.

Tuy nhiên, một quan sát thú vị khác từ cuộc nói chuyện đó là có một lượng phản ứng tiêu cực đáng kể. Nhiều người rõ ràng đã đầu tư toàn bộ lộ trình sự nghiệp của mình vào việc học, giảng dạy và sử dụng một quy trình thiết kế rất ổn định, và tôi nghĩ đã có rất nhiều sự nghi ngờ, chẳng hạn như "ồ, chúng tôi không thể làm việc mà không có giai đoạn khám phá", "chúng tôi không thể thiếu những phần trong quy trình này". Vì vậy, tôi nghĩ rằng vẫn có một phần ngành công nghiệp chưa hoàn toàn thích nghi với cách làm việc mới này, nếu điều đó có ý nghĩa.

Bạn có thể lập luận rằng câu hỏi đặt ra là điều gì dẫn đến những sản phẩmcông ty thành công nhất. Có thể đó là việc dành thời gian để khám phá, nghiên cứu người dùng, tạo bản mock, lặp lại và thử nghiệm beta. Hoặc cũng có thể là kỹ sư chỉ cần đưa ra những thứ tạm ổn, không quá xuất sắc, nhưng đủ tốt, và chúng ta học hỏi, lặp lại, xây dựng rồi lại lặp lại. Liệu hướng đi thứ hai đó không chỉ là điều mọi người đang làm mà còn thực sự dẫn đến sản phẩm tốt hơn tại thời điểm này?

Tôi nghĩ bạn phải lựa chọn và sử dụng sự suy xét của mình về thời điểm thực sự nên xuất xưởng một thứ gì đó. Nhưng tôi tin rằng khả năng thực thi, thử nghiệm một điều gì đó với dữ liệu thực và một tư duy người dùng thực sự trong sản phẩm, điều đó thực sự dẫn đến một sản phẩm tốt hơn. Đặc biệt là khi tất cả chúng ta đang làm việc với các mô hình AI mới đang phát triển và không xác định. Bạn không thể tạo bản mock cho tất cả các trạng thái, bạn không thể đưa ra lý thuyết, và bạn thậm chí không thể tạo một prototype có thể nhấp được với nó. Bạn phải sử dụng các mô hình thực tế bên dưới và bạn phải xem mọi người dùng thử nó với các trường hợp sử dụng của họ. Bởi vì với những mô hình này, bạn thiết kế chúng cho các trường hợp sử dụng khác nhau, nhưng bạn phải khám phá các trường hợp sử dụng khi bạn thấy mọi người đang dùng chúng.

Một điều khác tôi thường nghe, dựa trên những gì bạn vừa nói, là bạn không biết mọi người sẽ làm gì với AI. Bạn không biết nó sẽ tốt đến mức nào ở một số khía cạnh, đặc biệt là phần không xác định của nó. Vì vậy, bạn có thể tạo ra những bản mock tuyệt vời về những gì nó có thể trở thành, và sau đó mọi người lại sử dụng nó theo một cách hoàn toàn khác, đó là nguồn gốc của Co-work và có lẽ cả Claude Code ở giai đoạn đầu. Vậy, việc trở thành một nhà thiết kế tại Anthropic sẽ như thế nào? Hãy kể cho chúng tôi về một ngày làm việc điển hình tại Anthropic, ngay tại trung tâm của cơn bão.

Một Ngày của Nhà Thiết Kế AI tại Anthropic

Một lượng thời gian đáng kể tại Anthropic thực sự chỉ là để cập nhật những gì mọi người đang làm, những gì đang diễn ra trong công ty. Tôi nghĩ đây là công ty mà tôi đã làm việc ở một vài công ty khác có quy mô tương tự, nơi có rất nhiều thông tin và rất nhiều điều đang xảy ra, nhưng tôi cảm thấy thực sự bị thôi thúc phải theo dõi chúng. Có những thứ liên quan đến phát triển mô hình ở phía nghiên cứu, và vào bất kỳ thời điểm nào, có rất nhiều team khác nhau đang tạo prototype và thử nghiệm các ý tưởng khác nhau, và có một loạt các mã tên và những thứ tương tự. Rất nhiều thời gian tôi chỉ cố gắng điều hướng và tìm hiểu xem những dự án đó là gì, bởi vì tôi đang cố gắng tìm hiểu xem điều gì sắp đến với tôi. Có những thứ từ cả team nghiên cứu và cả các team lab của chúng tôi, những team này gần với nghiên cứu hơn và đang thử nghiệm, tạo prototype các thứ. Và sau đó, có những thứ tôi muốn tự mình thử nghiệm, chúng tôi có rất nhiều prototypesản phẩm nội bộ mà chúng tôi có thể sử dụng, và tôi chỉ tò mò muốn thử những thứ đó.

Và tôi nghĩ cũng có rất nhiều người nội bộ có nhiều hiểu biết và ý kiến về hướng đi của ngành, và một số trong số đó thực sự rất thú vị để đọc bởi vì rất nhiều trong số đó là các cuộc tranh luận triết học hoặc định hướng của công ty, và những thứ tương tự. Tôi cảm thấy mình chỉ muốn theo kịp những điều này, trong khi ở một công ty bình thường, tôi sẽ nghĩ "không sao cả, đây là những thứ nằm ngoài tầm với của tôi, tôi không thực sự quan tâm nhiều". Còn ở đây, tôi nghĩ cả về khối lượng và loại hình những điều đang xảy ra đều khiến tôi thực sự quan tâm đến việc theo dõi. Và ngoài việc theo dõi đó (không phải là một phần lớn trong công việc của tôi, nhưng tôi nghĩ đó là một phần thực sự thú vị).

Vai Trò Thiết Kế Đang Thay Đổi

Vâng, điều đó kết nối với điểm bạn đã nói trước đó. Một phần lớn vai trò thiết kế bây giờ là giúp các kỹ sưteam thực thi. Không chỉ là nói cho họ biết "đây là bản mock, đây là thiết kế". Mà là giúp họ đi đúng hướng, giúp họ kết nối các ý tưởng, tạo ra trải nghiệm mạch lạc khi nó đang diễn ra. Vì vậy, điều đó rất hợp lý.

Vâng. Vâng. Vâng. Và tôi nghĩ một phần của nó chỉ là sự tò mò, bạn biết đấy. Giống như tôi có một ghế hàng đầu để chứng kiến rất nhiều điều đang xảy ra trong ngành. Và vì vậy, rất nhiều trong số đó là "Vâng, Slack của chúng tôi là một mỏ vàng," bạn biết đấy. Tôi chỉ hào hứng đọc những gì mọi người đang làm và nói.

Tôi chưa bao giờ nghĩ rằng đã có quá nhiều tin tức về AI để theo dõi đối với một người bình thường, và sau đó thực sự thấy những gì đang diễn ra bên trong một lab là một tập hợp hoàn toàn mới các kênh thông tin để xem.

Vâng. Vâng. Giống như tôi không nghĩ rằng tin tức AI tốt nhất có lẽ là tin tức nội bộ nếu bạn đang ở một trong những công ty này, trong Slack của họ.

Tuyệt. Vâng.

Vấn đề cứ ngày càng khó hơn khi phải theo dõi những gì đang diễn ra. Được rồi. Vậy đó là một phần của công việc. Còn gì nữa?

Công Việc Thiết Kế Truyền Thống và Hiện Đại

Vẫn có một số phần truyền thống như việc tôi suy nghĩ về những gì sẽ xảy ra trong tương lai và thiết kế cho điều đó. Đó là điều mà, ví dụ, tuần này tôi đã dành thời gian cho nó, kiểu như "được rồi, chúng ta đã ở chế độ thực thi rất nhiều cho Co-work và bây giờ tôi muốn dành thời gian để suy nghĩ về 3 tháng tới sẽ như thế nào và điều đó thực sự có thể đi đến đâu dựa trên tình hình thị trường, các mô hình và nó có thể là gì". Bởi vì tôi nghĩ việc hình dung và thể hiện điều đó cho team và định hướng mọi người cùng một hướng vẫn thực sự hữu ích.

Và sau đó tôi cũng dành một phần lớn thời gian trong ngày để "jamming" (làm việc chung) với các kỹ sư. Rất nhiều công việc chỉ là trò chuyện hoặc whiteboarding hoặc xem xét một thứ gì đó họ đã xây dựng và đưa ra phản hồi về nó, đóng vai trò là một nhà thiết kế theo cách chúng tôi đang tư vấn. Và sau đó, tôi dành một phần trong ngày của mình cho mã nguồn, bạn biết đấy, trau chuốt, triển khai mọi thứ. Đôi khi, một kỹ sư và tôi đã làm việc xong một thứ gì đó và họ đã triển khai phiên bản đầu tiên của nó, và tôi chỉ vào để trau chuốt nó cùng họ. Và đó là một phần thực sự thú vị trong công việc của tôi mà tôi nghĩ là không tồn tại nhiều cách đây vài tháng.

Bạn vẫn đang thực hiện các yếu tố của quy trình thiết kế truyền thống chứ? Prototyping, user research, các hội thảo, tôi không biết, giống như toàn bộ những gì bạn đã mô tả.

Vâng, tôi nghĩ chúng tôi vẫn đang làm tất cả những điều đó ở một mức độ nào đó. Chúng tôi có một nhà nghiên cứu người dùng trong team đang tổng hợp cả các nghiên cứu truyền thống cũng như các cuộc khảo sát, và toàn bộ team đang đọc những nghiên cứu và phản hồi đó. Chúng tôi vẫn đang prototyping mọi thứ. Tôi vẫn đang mocking mọi thứ. Tôi nghĩ chỉ là tôi có một bộ công cụ rộng hơn bây giờ và tôi nghĩ tỷ lệ thời gian tôi dành cho mỗi việc đã thay đổi.

Đã hiểu. Được rồi. Vậy đó là một điểm rất thú vị. Trước đây, đó là một phần rất lớn.

Tôi đoán biểu đồ hình tròn về cuộc sống của bạn trước đây sẽ như thế nào, nơi mà nó là tư duy, lập kế hoạch, prototyping, mocking, nghiên cứu và sau đó chỉ là phản hồi và thực thi, và bây giờ.

Sự Thay Đổi trong Phân Bổ Thời Gian của Nhà Thiết Kế

Vâng. Tôi nghĩ với tư cách là một nhà thiết kế vài năm trước, tôi sẽ nói khoảng 60 đến 70% thời gian là dành cho việc mockingprototyping mọi thứ, và sau đó dành khoảng 20% thời gian cuối cùng để làm việc chung với các kỹ sư, tư vấn cho họ, và khoảng 10% cuối cùng có lẽ là các cuộc họp điều phối, v.v. Nhưng bây giờ tôi cảm thấy phần mocking đó là khoảng 30 đến 40%, và sau đó có 30 đến 40% khác hiện đang làm việc trực tiếp với các kỹ sư, và sau đó có một phần (tôi không biết còn lại bao nhiêu) nhưng có một phần hiện đang là triển khai nữa.

Vâng.

Giống như thực sự xây dựng và xuất xưởng.

Vâng.

Tuyệt vời. Vậy theo dõi chủ đề đó, AI stack của bạn là gì? Với tư cách là một nhà thiết kế, tôi biết bạn là một quản lý. Tôi muốn nói về việc bạn thực sự đang... tôi cũng muốn biết AI stack của bạn là gì. Bạn đang sử dụng những công cụ nào trong vai trò của mình?

AI Stack của Một Nhà Thiết Kỹ Sư Thiết Kế

AI stack của tôi là gì? Chà, chúng tôi đang làm việc về các chủ đề. Vì vậy, chúng tôi đang đi sâu vào stack của Claude. Vâng.

Tôi đang sử dụng rõ ràng là Claude Chat, và sau đó ngày càng nhiều Claude Co-work. Về cơ bản, tôi đã chuyển tất cả các trường hợp sử dụng chat của mình sang Co-work bởi vì tôi thấy rằng nó tốt hơn cho những tác vụ chạy dài hơn, và hầu hết những gì tôi yêu cầu Claude đều là những tác vụ chạy dài hơn này. Và tất nhiên là có Claude Code, tôi sử dụng nó chủ yếu với VS Code trong IDE bởi vì tôi thường điều chỉnh các thứ liên quan đến frontend, và thật hữu ích khi có thể xem mã nguồn và sau đó nói chuyện với Claude nữa. Tôi đã cố gắng thực sự sử dụng Claude Code nhiều hơn từ xa, cả qua di động và qua Slack nữa. Thật thú vị khi ai đó nói "ồ vâng, biểu tượng này bị lệch" và bạn chỉ cần at mention Claude, và Claude sẽ làm điều đó, và sau đó bạn lấy PR và nó đã xong. Điều đó cũng thực sự rất vui. Và vâng, tôi nghĩ rằng chúng tôi là một nhà Claude hoàn toàn ở đây. Vì vậy, đó về cơ bản là stack của tôi.

Bạn vẫn đang sử dụng Figma với tư cách là một nhà thiết kế chứ? Tôi vẫn đang sử dụng Figma. Vâng. Vâng.

Figma và Tương Lai của Thiết Kế

Được rồi. Tôi đang chờ đợi để nghe điều đó. Được rồi. Vậy Figma vẫn là một phần trong cuộc sống của bạn. Là một người từng làm ở Figma (Figmate, đó có phải là cách bạn được gọi không?)

Vâng. Vâng. Figmates. Vâng.

Vâng. Được rồi. Vậy tôi biết có cuộc tranh luận lớn này trên Twitter rằng liệu mã nguồn có phải là tương lai của thiết kế không. Chúng ta có cần Figma nữa không? Chúng ta có cần thiết kế nữa không? Ý bạn là gì? Figma vẫn quan trọng. Ý tôi là, với tư cách là một Figmate cũ, tôi thậm chí có thể thiên vị theo cách đó, nhưng tôi nghĩ vẫn có điều gì đó khi tôi sử dụng Figma, tôi nghĩ "đúng vậy, đây là những gì tôi nên sử dụng" và nó vẫn lấp đầy một khoảng trống rất tốt cho tôi.

Tôi nghĩ rất nhiều điều đó thực ra chỉ là một phần là khám phá nhiều tùy chọn khác nhau. Tôi nghĩ đó là một phần thực sự quan trọng của quy trình thiết kế, để có thể suy nghĩ về 8 đến 10 cách khác nhau để làm một điều gì đó. Tôi nghĩ thiết kế tốt nhất xảy ra khi bạn có thể đưa ra rất nhiều ý tưởng và chọn lọc, và thúc đẩy bản thân đưa ra nhiều hướng đi khác nhau. Hiện tại, lập trình hoặc hiện tại làm việc với một số công cụ lập trình này không phù hợp lắm với điều đó bởi vì nó rất tuyến tính. Bạn tập trung rất nhiều vào một hướng và bạn chỉ lặp lại với Claude chẳng hạn. Vì vậy, Figma đã thực sự tuyệt vời trong việc khám phá tất cả các tùy chọn khác nhau này và tôi nghĩ nó vẫn sẽ tồn tại theo cách đó ở một mức độ nào đó. Và sau đó, tôi nghĩ có những chi tiết hình ảnh và tương tác rất tinh tế cũng rất tuyệt vời để có thể thử trong Figma.

Công cụ thiết kế: IDE và AI Agent

Việc có thể suy nghĩ về nhiều hướng đi vi mô khác nhau, ví dụ như các kiểu chữ hoặc phong cách, và khám phá chúng trên một canvas vẫn cực kỳ hữu ích. Đó không phải là điều tôi luôn muốn chuyển thẳng sang code để thực hiện. Thật thú vị khi bạn vẫn sử dụng một IDE, vì trong kỹ thuật, xu hướng đang dịch chuyển rõ rệt sang các dòng lệnh, tác nhân. Các IDE dường như không còn được ưa chuộng nữa. Điều này hoàn toàn hợp lý. Bạn chỉ muốn chỉnh sửa một số thuộc tính CSS, một vài màu sắc. Vì vậy, tôi hiểu tại sao việc chỉ cần yêu cầu tác nhân "Này, hãy thay đổi giá trị hex này" lại dễ dàng hơn rất nhiều so với việc tự chỉnh sửa. Sẽ rất khó chịu khi phải yêu cầu "Bạn có thể đổi sang lớp này không?" trong khi bạn có thể trực tiếp vào và thay đổi nó. Vì vậy, thật thú vị. Tôi tự hỏi liệu các IDE giờ đây có trở nên hữu ích cho designerPM còn các kỹ sư đã chuyển sang công cụ khác. Có lẽ vậy.

Hỗ trợ kỹ sư về thiết kế và tốc độ shipping

Rất nhiều thời gian của tôi dành để làm việc với các kỹ sư, đưa ra phản hồi và định hướng họ đi đúng hướng. Có một cảm giác như lời khuyên của bạn là hãy "buông bỏ", đừng cảm thấy mình cần phải là người "gác cổng", nhưng đồng thời cũng cần giúp họ đi theo một hướng gắn kết và tạo ra những sản phẩm mà chúng ta tự hào. Tôi nghĩ nhiều designer hiện đang ở trong tình huống này, cảm thấy như "Ôi trời ơi, tôi không thể theo kịp tất cả các kỹ sư đang shipping mọi thứ cả ngày." Bạn đã học được điều gì để giúp các kỹ sư của mình cải thiện thiết kế để kết quả tốt hơn, hoặc chỉ đơn giản là duy trì khả năng theo dõi và không bị căng thẳng quá mức?

Bất cứ khi nào tôi làm việc với các kỹ sư trong các dự án, đặc biệt là theo hình thức tư vấn, tôi luôn cố gắng giải thích lý do tại sao tôi lại suy nghĩ theo cách đó, để giúp họ rút ra các nguyên tắc thay vì tôi chỉ nói "Không, tôi không nghĩ cái này nên ở đây." Thay vào đó, tôi sẽ nói "Không, tôi nghĩ chúng ta nên có một nút ở đây vì không phải ai cũng nhận ra họ có thể câu lệnh/lời nhắc cái này," và đưa ra ví dụ từ nghiên cứu hoặc các nguồn khác. Tôi cũng cố gắng hướng các kỹ sư đến hệ thống thiết kếmã nguồn của chúng tôi, bởi vì hiện tại Claude đang viết rất nhiều mã nguồn và nó không phải lúc nào cũng tuân thủ hệ thống thiết kế. Vì vậy, càng nhiều càng tốt, tôi trang bị cho họ những công cụ mà họ có thể sử dụng trong tương lai mà không cần tôi, điều đó rất hữu ích.

Về việc cố gắng không bị căng thẳng, tôi nghĩ điều đó rất khó khăn, đặc biệt là vào thời điểm hiện tại. Tôi thấy điều này rất nhiều từ cả kỹ sưdesigner: giờ đây chúng ta có khả năng làm được nhiều điều hơn, chúng ta lại muốn làm nhiều hơn nữa. Vì vậy, không chỉ designer mới cảm thấy "Ồ, chúng ta phải theo kịp các kỹ sư." Ngay cả các kỹ sư cũng tự hỏi "Làm thế nào để chúng ta theo kịp chính mình ngay bây giờ?" Đó là điều tôi nghe rất nhiều. "Đúng vậy, làm thế nào để theo kịp tất cả các tác nhân của chúng ta? Bảy tác nhân mà chúng ta liên tục vận hành."

Xây dựng niềm tin qua tốc độ và sự lặp lại

Vậy thì, với tư cách là một designer trong một ngành nghề mà sự khéo léo, trải nghiệm tuyệt vời, chất lượng và niềm tin là những yếu tố cốt lõi của công việc để truyền tải vào các sản phẩm—bởi vì về lý thuyết, điều đó dẫn đến các sản phẩm và công ty thực sự thành công. Làm thế nào bạn duy trì sự khéo léo, chất lượng và niềm tin khi các sản phẩm của bạn đang được shipping liên tục và bạn không thể theo dõi hết, và thậm chí không có designer nào tham gia?

Không phải là không có designer nào tham gia, mà là có quá nhiều việc cho một designer xử lý. Với điều này, tôi suy nghĩ về vị trí của các tính năng hoặc sản phẩm trong chu kỳ chấp nhận so với việc chỉ là một phiên bản xem trước nghiên cứu ban đầu. Ví dụ, đôi khi chúng tôi sẽ ra mắt các thứ và nói "Này, đây là một phiên bản xem trước nghiên cứu. Nó còn ở giai đoạn đầu. Nó sẽ có rất nhiều lỗi," và chúng tôi đưa ra nhiều cảnh báo về điều đó. Tôi nghĩ Claude Co-work thực sự là một ví dụ điển hình cho việc này, nơi chúng tôi gắn nhãn nó là một phiên bản xem trước nghiên cứu và tung ra thị trường, biết rằng "Này, cái này cũng giống như các mô hình của chúng tôi. Đây là phiên bản tồi tệ nhất của nó, nhưng chúng tôi sẽ đưa nó ra thị trường vì chúng tôi tin rằng, sau khi đã thử nghiệm nội bộ rất nhiều, có một điều gì đó thực sự mạnh mẽ ở đây mà một số người sẽ được hưởng lợi." Nó có thể chưa phải là dễ sử dụng nhất, có thể không có chất lượng cao nhất, có thể có một số vấn đề, nhưng chúng tôi sẽ đưa nó ra vì chúng tôi tin rằng lợi ích vượt trội hơn nhược điểm. Tôi nghĩ điều đó là chấp nhận được, đặc biệt khi sản phẩm đã có giá trị thực sự và đáng để đưa ra thị trường.

Tuy nhiên, tôi nghĩ lời hứa bạn phải đưa ra cho người dùng là "Này, chúng tôi sẽ tung ra nó, nhưng chúng tôi sẽ lặp lại. Chúng tôi sẽ lắng nghe phản hồi của bạn và lặp lại để làm cho nó tốt hơn." Bạn phải thể hiện cam kết đó. Bạn phải cho thế giới thấy điều đó. Bạn phải phản hồi phản hồi của mọi người và phải cho thấy rằng bạn liên tục shipping và cải thiện nó. Bởi vì tôi nghĩ cách bạn thực sự đánh mất niềm tin về chất lượng khi phát hành sớm một thứ gì đó là nếu bạn phát hành sớm và sau đó không có gì xảy ra nữa. Đó là điều làm giảm giá trị thương hiệu. Nhưng bất cứ khi nào bạn đưa ra một thứ gì đó sớm, bạn vẫn có thể làm điều đó và duy trì thương hiệu của công ty mình. Tôi nghĩ đó là điều chúng tôi đã làm khá tốt, và nếu có ai đang lắng nghe có thể rút ra bài học từ đó thì đó là "Đúng vậy, chúng tôi sẽ tiếp tục làm điều đó." Và tôi nghĩ điều đó thực sự thú vị đối với tôi với tư cách là một designer bởi vì bạn đưa một thứ gì đó ra ngoài và bạn thực sự học hỏi được, nhận được phản hồi ngay lập tức về nó, và biết phải làm gì tiếp theo.

Cách tôi từng nghe bạn mô tả điều này là "xây dựng niềm tin thông qua tốc độ." Đúng vậy, chắc chắn. Đó là xây dựng niềm tin thông qua tốc độ, nhưng cũng là làm cho mọi người cảm thấy rằng họ đã được lắng nghe và chúng tôi đang khắc phục mọi thứ dựa trên mục đích sử dụng của họ, và phản hồi của họ thực sự được đánh giá cao và được sử dụng. Đúng vậy, rõ ràng là khi các phòng thí nghiệm ra mắt các sản phẩm và các bạn đều rất giỏi trong việc này. Mọi người trong nhóm đều tweet và phản hồi các tweet, bình luận, và sau đó shipping "Này, chúng tôi đã sửa cái này hôm qua và điều này đang xảy ra." Vì vậy, có một cảm giác rõ ràng rằng "Đây chỉ là ngày hôm nay và chúng tôi biết điều này đang bị lỗi và chúng tôi sẽ sửa nó." Và vì Claude Code có thể viết mã nguồn rất nhanh, nên các bản sửa lỗi cũng đến rất nhanh.

Giá trị của tư duy con người trong kỷ nguyên AI

Một câu hỏi lớn khác mà mọi người đang hỏi, và tôi cũng hỏi rất nhiều trên podcast này, là về những kỹ năng nào sẽ trở nên có giá trị. Hoặc một cách khác mà Lex đã nói gần đây là "Bộ não con người sẽ tiếp tục có giá trị ở đâu khi trí tuệ nhân tạo (AI) ngày càng thông minh hơn?" Chúng ta đã trải qua một quá trình tiến hóa: từ việc tự động hoàn thành các đoạn mã nguồn đến việc trí tuệ nhân tạo (AI) hiện viết 100% mã nguồn—thật điên rồ!—cho đến việc trí tuệ nhân tạo (AI) tự xem xét mã nguồn của chính mình. Boris gần đây trên podcast đã nói rằng Claude Code hiện đang giúp anh ấy đưa ra ý tưởng và quyết định nên xây dựng cái gì. Điều đó giống như "Wow, hãy nhìn xem, toàn bộ quy trình phát triển sản phẩm đang dần bị trí tuệ nhân tạo (AI) tiếp quản."

Vậy câu hỏi đặt ra là "Bộ não con người sẽ vẫn hữu ích ở đâu, ít nhất là cho đến khi chúng ta có siêu trí tuệ?" Bạn có nghĩ rằng trí tuệ nhân tạo (AI) sẽ trở nên rất giỏi về "thị hiếu", "đánh giá" và thiết kế không? Tôi nghĩ nó sẽ trở nên tốt hơn về thị hiếu, đánh giá và thiết kế. Đúng vậy. Tôi nghĩ chúng ta có thể đang bám víu vào điều đó quá nhiều, cho rằng "Ồ, một designer hoặc một ai đó sẽ luôn biết điều tốt nhất để shipping hoặc phiên bản tốt nhất của cái này." Nhưng tôi nghĩ "thị hiếu" của trí tuệ nhân tạo (AI) cuối cùng sẽ trở nên tốt hơn.

Cuối cùng, vẫn cần có người quyết định điều gì thực sự sẽ được xây dựng và điều gì thực sự quan trọng. Và khi tôi nghĩ về việc mọi người nói "Ồ, trí tuệ nhân tạo (AI) sẽ tự xây dựng phần mềm này cho chúng ta," thì nhiều phần khó khăn của việc xây dựng phần mềm thực ra lại không phải là việc xây dựng nó. Nếu bạn nghĩ về những thời điểm khó khăn nhất bạn từng trải qua trong công việc, có lẽ đó là những việc như bạn và một người khác bất đồng về việc tính năng này nên có gì hoặc không nên có gì. Những điều đó vẫn cho cảm giác như trí tuệ nhân tạo (AI) có thể đưa ra ý kiến, nhưng nó không nhất thiết phải giải quyết tranh chấp giữa bạn và người khác. Vì vậy, có một điều gì đó về việc quyết định điều gì thực sự đi vào những thứ chúng ta xây dựng, mà tôi đoán đó là một dạng thị hiếu, nhưng có lẽ không phải là thị hiếu theo cách chúng ta nghĩ về thị hiếu thẩm mỹ hoặc tương tự. Có một dạng đánh giá về việc nên làm gì tiếp theo.

Chỉ cần nhìn cách trí tuệ nhân tạo (AI) nhanh chóng chiếm lĩnh lập trình, điều mà một năm trước, và chắc chắn là hai năm trước, hầu hết mọi người đều nghĩ "Tôi không nghĩ vậy. Tôi không nghĩ trí tuệ nhân tạo (AI) sẽ giỏi đến thế." Và giờ đây, những kỹ sư giỏi nhất thế giới tin tưởng nó đến mức họ thậm chí không nhìn vào mã nguồn nữa. Đó là lúc nó khiến tôi phải đánh giá lại tất cả những giả định mà tôi từng có về việc "Okay, trí tuệ nhân tạo (AI) sẽ không bao giờ giỏi bằng những PMdesigner thực sự giỏi trong việc đánh giá cái gì là tuyệt vời và quyết định nên xây dựng cái gì." Nhưng tôi bắt đầu nghĩ rằng nó sẽ đạt được điều đó. Ngay cả trong ví dụ bạn đã chia sẻ, nó có thể cung cấp cho hai người đang cố gắng đưa ra quyết định: "Đây là tất cả dữ liệu bạn cần để đưa ra quyết định và đây là lý do tại sao đây là câu trả lời đúng. Chỉ cần nhấn 'Có', nhấn '1' và tôi sẽ xây dựng nó." (tiếng cười) Đúng vậy. Vì vậy, tôi nghĩ chúng ta đang đánh giá thấp mức độ giỏi mà nó sẽ đạt được trong những việc này.

Vậy, bạn nghĩ rằng nó sẽ trở nên tốt hơn, nhưng bạn vẫn nghĩ rằng chúng ta sẽ cần những designer tuyệt vời tham gia, những PM tuyệt vời để giúp đưa ra những quyết định này, và tất nhiên là cả các kỹ sư? Đúng vậy. Tôi nghĩ vẫn sẽ có người phải quyết định "Ồ, chúng ta muốn xây dựng loại sản phẩm này," hoặc, dựa trên những gì trí tuệ nhân tạo (AI) đang trình bày cho chúng ta, vẫn cần có người chịu trách nhiệm về quyết định đó. Giống như việc ngay cả khi Claude có thể viết tất cả mã nguồn cho bạn ngày hôm nay, thì vẫn là một kỹ sư chịu trách nhiệm về việc mã nguồn đó có thực sự hoạt động không, có thực sự có ý nghĩa trong sản phẩm hay không. Vì vậy, tôi nghĩ có một lớp ra quyết định/đánh giá mà có lẽ một ngày nào đó chúng ta sẽ không phải làm, nhưng nó vẫn thuộc về chúng ta. Đúng vậy, điều đó có lý.

Điều đó khiến tôi nghĩ về ví dụ về X quang, nơi luôn có cảm giác rằng trí tuệ nhân tạo (AI) sẽ chiếm lĩnh lĩnh vực X quang và cho bạn biết điều gì đang xảy ra. Nhưng con người chủ yếu hữu ích để ký duyệt quyết định bởi vì phải có người chịu trách nhiệm nếu họ sai. Mà đó không phải là công việc tốt nhất trên thế giới. Nhưng đó là một trò chơi khác: y tế so với mã nguồn. Đúng vậy.

Giao diện tương tác với AI trong tương lai

Một câu hỏi đang được đặt ra trong thiết kế trí tuệ nhân tạo (AI) là dường như các chatbotterminal không phải là giao diện người dùng bền vững cho trí tuệ nhân tạo (AI). Chatbot? Không, không, không, đây chỉ là một điểm dừng tạm thời trên hành trình thôi. Nhưng bây giờ nó lại tiến xa hơn và chỉ là các terminal. Bạn có suy nghĩ gì về việc liệu sẽ có bước tiếp theo trong cách chúng ta tương tác với trí tuệ nhân tạo (AI) hay chatbotterminal là nơi chúng ta chủ yếu sẽ dừng lại? Sẽ có khả năng là sự kết hợp của cả hai: cả giao diện người dùng (UI) và các giao diện mà bạn tương tác, nhấp chuột và cảm thấy xúc giác hơn.

Xu Hướng Tương Lai: Chatbot, UI và Giao Tiếp Với AI

Chúng ta đã và đang trải nghiệm điều này với Claude, chatbot. Gần đây, chúng tôi đã phát hành một loạt các widget cho phép Claude gợi ý và đặt câu hỏi, cũng như hiển thị những thứ như thời tiết và cổ phiếu theo những cách tương tác. Tôi nghĩ những widget này đã nhận được phản hồi rất tốt vì mọi người vẫn thích xem, chạm và nhấp vào giao diện người dùng (UI); chúng hiệu quả hơn nhiều so với việc gõ gì đó cho Claude. Nhưng đồng thời, khi chúng tôi thực sự tập trung vào mô hình chatbot, tôi nghĩ điều đó đã mang lại cho chúng tôi toàn bộ thế giới linh hoạt mà chúng tôi không có với các UI được xây dựng sẵn. Vì vậy, theo tôi, chat sẽ không bao giờ biến mất vì nó đã mở ra một cách thức mới với vô vàn khả năng để làm việc với mô hình và tương tác với máy tính mà trước đây chúng ta chưa từng có. Tuy nhiên, tôi nghĩ rằng đối với những tác vụ rất cụ thể, việc tồn tại trong UI vẫn sẽ trực tiếp nhất. Và tôi nghĩ điều có thể xảy ra ở đây là nhiều UI đó sẽ được các mô hình tạo ra ngày càng thường xuyên hơn, thay vì chúng ta phải tự tay viết mã cho từng trường hợp.

Nhưng tôi nghĩ chúng ta đang ở trong một không gian mà tôi không nghĩ chat, và thậm chí có thể là nói chuyện với terminal, sẽ biến mất. Điều thú vị là với OpenAI, Claude, Mbot – tất cả các tên này – một trong những đổi mới lớn là một cách khác để chat với nó thông qua WhatsApp, Telegram và SMS. Giống như một dạng chatbot khác, nhưng điều đó đã mở ra một khả năng lớn: "Ồ, tôi có thể chat với nó qua WhatsApp." Vâng. Và việc chat và nói chuyện với ai đó vẫn là điều mà chúng ta, với tư cách là con người, đang làm. Đó là một cách để chúng ta tương tác một cách rất phong phú, và bây giờ chúng ta có thêm một phương tiện khác để tương tác với máy tính.

Vâng. Kevin Wheel, người làm việc tại một phòng thí nghiệm AI khác (tôi sẽ không đề cập tên), đã có một quan điểm tuyệt vời trên podcast rằng nói chuyện là một cách tuyệt vời để xử lý mọi cấp độ trí thông minh. Chúng ta có thể nói chuyện với những người rất rất thông minh và những người không quá thông minh; và việc nói chuyện mở rộng quy mô rất tốt trên toàn bộ phổ. Chúng ta có thể nói chuyện với những người có IQ 200, IQ 300 – việc nói chuyện vẫn hiệu quả. Đó là lý do tại sao nó là một cách tuyệt vời để đối phó với sự phát triển trí thông minh của các mô hình và nó tiếp tục hiệu quả.

Omni: Giải Pháp Phân Tích AI Cho Sản Phẩm

Vâng, điều đó hoàn toàn hợp lý. Tập này được tài trợ bởi Omni. Nhiều đội ngũ sản phẩm ngày nay đang tranh luận về cách triển khai phân tích AI. Phần khó khăn là rõ ràng: việc để một LLM dự đoán SQL trong môi trường sản xuất là một mớ hỗn độn lớn và là một ý tưởng tồi. Omni tiếp cận theo một cách khác. Họ có một lớp ngữ nghĩa (semantic layer) được tích hợp sẵn để khi bạn nhúng các công cụ phân tích của họ, AI thực sự hiểu các định nghĩa kinh doanh của bạn, chứ không chỉ các bảng thô. Bạn có thể kiểm tra truy vấn, xác thực lý do và khóa quyền trước khi mọi thứ đưa vào sản xuất. Nếu bạn muốn phân tích AI trong sản phẩm của mình mà không cần xây dựng toàn bộ stack từ đầu, hãy truy cập omni.co/lenny để dùng thử miễn phí ba tuần. Các công ty như Perplexity, DBT và Buzzfeed sử dụng Omni để cung cấp các phân tích mà khách hàng của họ có thể tin tưởng. Đó là omni.co/lenny.

Vai Trò IC và Quản Lý Trong Thiết Kế

Được rồi. Tôi muốn quay lại ý tưởng về quản lýIC (cá nhân đóng góp trực tiếp). Vậy là bạn đã đặt mình trở lại vai trò IC theo nhiều cách. Hãy nói về điều đó và liệu bạn có nghĩ đó là điều mà các quản lý thiết kế cần làm hay không. Vâng, tôi có những quan điểm về việc này. Năm vừa qua tại Anthropic, tôi tham gia với tư cách IC trước. Sau đó, tôi quản lý một đội trong vài tháng theo một cơ cấu tổ chức cần thiết. Và bây giờ tôi thực sự đã quay lại làm công việc IC toàn thời gian. Tôi gia nhập Anthropic với tư cách IC vì tôi thực sự rất hào hứng với loại công việc IC có thể làm ở đây, nhưng cũng bởi vì tôi cảm thấy muốn được gần gũi với công việc, và tôi nghĩ đây là thời điểm rất quan trọng để làm điều đó trước khi tôi thăng tiến trong cấp bậc công ty. Và tôi đã có những câu hỏi và nghi ngờ về việc liệu quản lý cấp trung có an toàn trong tương lai hay không, liệu cách chúng ta đang làm việc có phải là một công việc sẽ tồn tại trong tương lai hay không, hay tôi nên thử một điều gì đó khác và tự tay làm việc. Và thành thật mà nói, tôi thực sự yêu thích cả hai mặt của vấn đề: tôi thích quản lý con người, tôi thích xây dựng đội ngũ và ở cấp độ đó, nhưng tôi cũng thực sự yêu thích công việc IC. Tôi giống như một quản lý miễn cưỡng khi tôi làm điều đó và tôi đã nghĩ, "Được rồi, tôi sẽ làm." Vì vậy, tôi yêu cả hai mặt của vấn đề khá đồng đều. Nhưng tôi nghĩ điều mà việc làm IC trong năm vừa qua đã dạy tôi là nó thực sự đã mang lại cho tôi rất nhiều kỹ năng mà tôi không nghĩ mình sẽ có được nếu tôi chỉ quản lý trong suốt năm nay. Giống như quy trình thiết kế, như tôi đã đề cập, đã thay đổi rất nhiều trong năm qua và tôi cảm thấy mình đã học được rất nhiều kỹ năng cứng mà tôi sẽ không nhất thiết có thời gian để làm nếu tôi chỉ quản lý một đội. Vì vậy, đó thực sự là điều tốt nhất mà nó mang lại cho tôi. Và tôi nghĩ bất cứ lúc nào nếu tôi lại quản lý một đội, tôi nghĩ nó sẽ mang lại cho tôi sự đồng cảm và hiểu biết về cách quy trình thiết kế đã thay đổi. Và tôi nghĩ đó thực sự là một điều rất quan trọng ngay bây giờ vì các đội đang làm việc rất khác nhau. Tôi nghĩ thực sự khá khó để đồng cảm nếu bạn không làm việc theo cách đó hoặc bạn không phải lúc nào cũng thử tất cả các công cụ và thử nghiệm mọi thứ. Nhưng vâng, đây là một thời điểm thú vị để trở thành một nhà thiết kế, và nếu tôi không làm việc trong môi trường này, tôi không biết liệu tôi có hoàn toàn hiểu được nó hay biết phải làm gì hoặc cách hướng dẫn đội ngũ của mình. Vì vậy, đó là những gì năm nay thực sự đã mang lại cho tôi.

Tương Lai Của Quản Lý Thiết Kế

Và trước đây bạn là Giám đốc Thiết kế tại Figma, phải không? Đội ngũ của bạn lớn đến mức nào? Chỉ để mọi người có thể hình dung. Ở mức tối đa, tôi nghĩ tôi có khoảng 12-15 nhà thiết kế, và tôi cũng có một vài quản lý. Tuyệt vời. Vậy là bạn có cảm giác rằng quản lý cấp trung có thể không tồn tại lâu dài. Cảm nhận hiện tại của bạn là gì? Bạn nghĩ rằng quản lý thiết kế là một điều sẽ tồn tại lâu dài, hay bạn nghĩ mọi người đều chuyển sang vai trò IC? Tôi nghĩ rằng miễn là có một đội ngũ người làm việc, việc có một người quản lý đội ngũ là hữu ích. Tôi nghĩ rằng có giá trị thực sự ở các quản lý. Nó phụ thuộc vào hình thức của quản lý và những gì họ thực sự làm. Nhưng cách tôi nghĩ về một quản lý hữu ích ngày nay là một người không chỉ đơn thuần là quản lý con người – kiểu như, chỉ là ai đó để thiết lập công việc cho bạn, giúp đỡ bạn trong lộ trình sự nghiệp, có các cuộc họp 1-1, đảm bảo bạn cảm thấy tốt trong công việc. Tôi nghĩ điều đó không còn là một điều quan trọng như trước nữa. Nhưng tôi nghĩ một người có thể thực sự hoạt động như người đưa ra hướng đi cho đội ngũ cũng như thực hiện một số công việc quản lý con người – sự kết hợp đó – tôi nghĩ đó là tương lai của vai trò quản lý, ít nhất là hiện tại. Kiểu như một người có thể thực sự gắn kết với đội ngũ về mặt công việc và đưa ra hướng đi ở đó, cũng như tạo ra môi trường để họ thực hiện công việc tốt nhất của mình.

Trở Lại Vai Trò IC và Những Thách Thức

Và bạn có thấy mình quay lại quản lý về lâu dài không? Có thể lắm. Tôi nghĩ tôi thực sự yêu thích việc giúp một đội ngũ xây dựng sản phẩm tốt nhất có thể. Và phương châm của tôi là: "bằng mọi giá." Nếu đội ngũ cần ai đó để định hướng cho đội và thiết lập đội ngũ, đó có thể là tôi. Nếu đội ngũ chỉ cần ai đó để thực thi, đó cũng có thể là tôi. Vì vậy, lời khuyên mà tôi nghe được cho những người làm thiết kế, đặc biệt là các quản lý, là: bạn gần như cần phải quay lại vai trò IC để thực sự hiểu những gì đang diễn ra và mức độ thay đổi của nó, để bạn có thể trở thành một quản lý tốt hơn. Tôi nghĩ vậy. Và tôi nghĩ theo truyền thống, ít nhất là những gì tôi đã thấy ở nhiều ngành kỹ thuật, khi họ thuê một EM (Quản lý Kỹ thuật) hoặc thậm chí đôi khi là giám đốc, họ thực sự yêu cầu EM xoay vòng vài tháng và đảm nhận một vài nhiệm vụ để thực sự hiểu cách công nghệ hoạt động trước khi họ trở thành quản lý toàn thời gian. Và tôi nghĩ thiết kế có lẽ cũng cần làm điều tương tự, nơi tôi nghĩ trong quá khứ thiết kế đã thiên về quản lý con người nhiều hơn. Bạn thấy mình bị mai một nhất ở điểm nào khi quay lại làm nhà thiết kế IC? Thực ra là làm phê bình (crits), bạn biết đấy, và bị chỉ trích. Vâng. Bị chỉ trích. Bạn sẽ nghĩ, "Ồ, vâng." Thật khó để nhận phản hồi phê bình và lắng nghe nó thường xuyên, bởi vì đó là điều bạn phải làm với tư cách một nhà thiết kế: đó là một bài tập khá dễ tổn thương khi chia sẻ công việc và trình bày nó với đội ngũ của bạn, sau đó cũng phải nhận rất nhiều phản hồi phê bình và chấp nhận điều đó mọi lúc.

Quá Trình Phát Triển Co-work

Vậy hiện tại bạn đang dẫn dắt thiết kế, cụ thể là thiết kế trên Co-work, đúng không? Vâng. Tuyệt vời. Boris, người gần đây đã tham gia podcast, đã nói về việc có rất nhiều cuộc tranh luận về Co-work nên là gì, và có rất nhiều ý tưởng lớn. Và anh ấy nói, cuối cùng, chúng ta hãy biến nó thành một terminal cơ bản trong sản phẩm và chỉ là một terminal có giao diện đẹp. Bạn có thể chia sẻ bất cứ điều gì về quá trình đi đến quyết định cuối cùng về trải nghiệm Co-work không? Nhân tiện, tôi đang nhìn nó trên màn hình của mình đây. Với Co-work nói riêng, chúng tôi đã có một loạt các nguyên mẫu khác nhau nội bộ về hình dạng của nó. Và đó là một trong những điều mà chúng tôi đã thử rất nhiều thứ và sau đó tôi nghĩ chúng tôi không thực sự chắc chắn khi nào nó sẽ sẵn sàng để phát hành, và sau đó mọi thứ diễn ra cùng một lúc. Kiểu như chúng tôi đã nói, "Được rồi, chúng ta sẽ phát hành nó sớm thôi." Nó là 10 ngày. 10 ngày xây dựng. Vâng, nó chắc chắn dài hơn thế. Nhìn chung, mất khoảng 10 ngày để đưa nó từ những gì chúng tôi có nội bộ thành một thứ mà chúng tôi sẵn sàng phát hành ra bên ngoài. Vì vậy, chúng tôi đã xây dựng nó trong một thời gian, nhưng chúng tôi không thực sự chắc chắn về hình thức thực tế mà nó sẽ có. Và cách nó đạt được điều đó thực ra là có rất nhiều khám phá khác nhau mà chúng tôi đã có nội bộ trên đỉnh của các hệ thống tác nhân (agent harnesses) khác nhau và nhiều thứ khác nữa. Và chúng tôi chỉ tạo nguyên mẫu các phần nhỏ của các tương tác khác nhau đã kết thúc trong Co-work. Vì vậy, những thứ như khi Claude đưa cho bạn một danh sách việc cần làm, chúng tôi đã thử rất nhiều yếu tố hình thức khác nhau cho điều đó. Chúng tôi đã thử rất nhiều yếu tố hình thức khác nhau cho cách nó trình bày cho bạn các câu hỏi trắc nghiệm khác nhau. Chúng tôi đã thử rất nhiều cách khác nhau để dạy mọi người về trường hợp sử dụng và nhiều thứ khác nữa. Và tôi không biết liệu chúng tôi có đạt được yếu tố hình thức tốt nhất từ ​​trước đến nay hay không, nhưng về cơ bản, đó là những thứ đã hoạt động nội bộ mà mọi người thích, mà chúng tôi chỉ nghĩ rằng chúng tôi sẽ nhận được thêm tín hiệu bằng cách phát hành nó. Vì vậy, tôi nghĩ rằng việc buộc bản thân phát hành nó trong vòng 10 ngày mà chúng tôi đã làm, nó chỉ là kiểu như bất cứ thứ gì chúng tôi có, hãy đưa nó ra ngoài và sau đó chúng ta sẽ lặp lại từ đó, đó là những gì chúng tôi đang làm. Và nó đã gây bão trên internet khi bạn ra mắt, nên nó đã thành công. Vâng. Có tính năng nào của Co-work ngày nay mà bạn tự hào nhất hoặc chỉ muốn sửa chữa và cải thiện không? Thành thật mà nói, tôi nghĩ tôi tự hào nhất về việc chúng tôi thực sự đã phát hành nó và đưa nó ra ngoài.

Trải nghiệm sản phẩm và quy trình phát triển

Nói về những gì tôi thích, tôi không chắc có một điều cụ thể nào cả, vì khi bạn làm việc gì đó quá lâu, đặc biệt là với tư cách một designer, bạn chỉ thấy những lỗi của nó. Nhưng có nhiều thứ tôi rất hào hứng. Chúng tôi đã liên tục iterate, đặc biệt là trên homepage, để biến nó thành nơi mà người dùng cảm thấy như đây là những task bạn có thể giao cho ClaudeClaude đang thực hiện. Tính năng này sắp được triển khai. Có thể nó đã ra mắt vào thời điểm này.

Người phỏng vấn: Được rồi. Tôi thấy một tính năng randomizer nhỏ, bạn nhấp vào đó và nó đưa ra nhiều ý tưởng khác nhau.

Đúng vậy. Và khi bạn bắt đầu làm việc với Claude về các vấn đề, nó sẽ giống như một danh sách to-do list hơn. Cảm giác như đây là những việc Claude đang làm. Đây là những việc Claude cần bạn chú ý. Tôi nghĩ có một cơ hội ở đây để làm cho nó giống như một danh sách to-do list chung giữa bạn và Claude. Tôi rất hào hứng khi tiếp tục iterate về điều đó. Và tôi cũng hào hứng suy nghĩ thêm về form factor thực sự của nó là gì? Liệu nó có luôn bị kẹt trong màn hình không, hay làm thế nào để nó tiếp cận các surface khác mà nó đang làm việc cùng?

Người phỏng vấn: Tôi thích việc bạn chia sẻ rằng không phải chỉ mất 10 ngày để làm điều này. Có những con số mà mọi người hay nói ra: "Chúng tôi xây dựng nó trong 10 ngày". Ý của bạn là đã có thời gian dành cho việc suy nghĩ về định hướng, prototyping, mocking, thử nghiệm các thứ. Sau đó, "Được rồi, bây giờ chúng ta biết mình muốn gì, hãy xây dựng và ship nó."

Vâng, tôi nghĩ vì một lý do nào đó, điều đó đã trở thành thứ viral được rút ra từ tất cả các thông báo về co-work, đó là nó chỉ mất 10 ngày. Nhưng tôi nghĩ đã có rất nhiều khám phá khác nhau và nhiều người đã làm việc trên các phần khác nhau của co-work. Đúng vậy, nó không chỉ mất 10 ngày và có rất nhiều người khác nhau tham gia. Đây là một trong những trường hợp mà ý tưởng cứ quay trở lại, nhưng không bao giờ là thời điểm thích hợp hoặc có những biến thể khác nhau của nó. Sau đó, đột nhiên, thời điểm thích hợp xuất hiện và cảm giác như điều đó đã hiển nhiên từ trước, nhưng thực tế là một hành trình rất dài để đạt được nó.

Người phỏng vấn: Nhân tiện, đối với những người không biết nhiều về co-work, cách tôi nghĩ về nó là Claude có đôi tay, nơi bạn có thể làm mọi thứ trên máy tính của mình.

Đó có phải là cách bạn mô tả nó chỉ trong một hoặc hai câu không?

Người phỏng vấn: Đó là một mô tả hay. Tôi chưa bao giờ nghe thấy điều đó nhưng tôi thích nó. Tôi có thể sẽ dùng nó thường xuyên hơn là Claude có đôi tay.

Tôi cũng nghĩ về nó như Claude, nhưng Claude thực sự giỏi trong việc lấy tất cả những thứ "rác" của bạn và biến chúng thành thứ gì đó tốt đẹp. Một trong những use case yêu thích của tôi từ co-work là chỉ cần đưa cho nó một thư mục chứa đồ của tôi, và không thực sự quan trọng có gì trong thư mục đó, nhưng tôi có thể trích xuất được điều gì đó tốt đẹp từ nó.

Người phỏng vấn: Tôi đã làm điều đó nhiều lần.

Tiêu chí tuyển dụng nhà thiết kế trong kỷ nguyên AI

Được rồi, quay lại việc quản lý và vai trò của một designer. Tôi muốn nói một chút về việc tuyển dụng. Với việc vai trò của một designer thay đổi rất nhiều, bạn tìm kiếm điều gì mới? Bạn tìm kiếm điều gì khi tuyển dụng các designer mà bạn nghĩ là thực sự quan trọng để họ thành công trong thế giới mới này?

Vâng, tôi nghĩ khi làm việc cụ thể trong môi trường mà tôi đang làm, có một cảm giác về khả năng phục hồi và khả năng thích nghi. Tôi nghĩ điều đó thực sự quan trọng bởi vì rất nhiều thứ đang thay đổi xung quanh chúng ta, và bạn phải thực sự sẵn sàng thích nghi, thử các phương pháp mới, thử các công cụ AI mới và học hỏi những điều mới, thay vì chỉ mắc kẹt trong các quy trình và cách làm cũ.

Nhưng sau đó tôi cũng nghĩ về ba archetype những người mà tôi thấy rất thú vị hiện nay. Tôi nghĩ những người này đã thú vị với tôi từ trước, nhưng tôi cảm thấy trong kỷ nguyên này thì họ đặc biệt quan trọng.

Đầu tiên tôi gọi là strong generalists. Không chỉ là những generalists bình thường, những người khá giỏi nhiều thứ, mà là những người gần như có hình dạng block-shaped trong T-shaped framework, nơi họ thực sự giỏi một vài kỹ năng cốt lõi, đạt đến phân vị thứ 80. Thành thật mà nói, tôi nghĩ điều này khá hiếm và khó để tuyển dụng. Nhưng tôi thích điều này vì vai trò thiết kế mà chúng ta đã thấy đang mở rộng và trải rộng. Tất cả chúng ta đều đang trở nên giống quản lý sản phẩm hơn, tất cả chúng ta đều đang trở nên giống kỹ sư hơn. Vì vậy, nếu bạn đã có kỹ năng mạnh trong một vài lĩnh vực khác nhau, bạn sẽ rất dễ dàng điều chỉnh và mở rộng vai trò của mình. Điều đó thực sự thú vị đối với tôi. Đó chỉ là một người thực sự giỏi nhiều thứ. Lại một yêu cầu lớn.

Và sau đó, người thứ hai mà tôi rất hào hứng, trong T-shaped framework, là một deep specialist. Một người có hình dạng chữ T, nhưng phần đầu của chữ T có lẽ sâu hơn hầu hết những người khác. Vì vậy, những người có thể nằm trong top 10% của ngành chẳng hạn. Lại một lần nữa, cực kỳ khó tìm. Và tôi cảm thấy rất may mắn khi làm việc ở những nơi mà bạn có thể đủ khả năng tuyển dụng những người như vậy và thực sự đưa họ vào làm việc.

Và cuối cùng, có lẽ là điều mà tất cả chúng ta đang bỏ qua, đó là cái mà tôi gọi là craft new grad. Đó chỉ là một người mới vào nghề và cảm thấy có vẻ khôn ngoan và kinh nghiệm hơn tuổi, nhưng cũng rất khiêm tốn và rất ham học hỏi. Tôi nghĩ người này rất thú vị hiện nay vì tôi nghĩ hầu hết các công ty chỉ đang tuyển dụng những senior talent, những người đã từng làm việc trước đây, rất có kinh nghiệm. Nhưng với việc vai trò đang thay đổi và những gì chúng ta được kỳ vọng phải làm đang thay đổi, tôi nghĩ việc có một người gần như có một blank slate và là một người học hỏi rất nhanh, rất ham học hỏi các chiến thuật mới và những thứ tương tự, không có tất cả các quy trình và nghi lễ cố định trong tâm trí, điều đó cực kỳ có giá trị. Vì vậy, tôi nghĩ đó là những người mà nhiều người trong chúng ta đang bỏ qua, nhưng tôi lại thực sự hào hứng về họ.

Kỹ năng cụ thể của nhà thiết kế

Người phỏng vấn: Tuyệt vời. Về deep T-shape, có ví dụ nào về một người trong ngành thiết kế có kỹ năng gì mà họ thực sự giỏi không?

Đôi khi có những designer rất technical đến mức họ có thể là 50% một kỹ sư phần mềm. Điều đó thực sự thú vị, đặc biệt là bởi vì hiện tại, ít nhất đối với chúng tôi, bạn đang làm việc trực tiếp với model, vì vậy có chuyên môn sâu về kỹ thuật sẽ rất hữu ích. Nhưng một kiểu deep specialist T khác thì chỉ đơn giản là, bạn biết đấy, họ thực sự giỏi về visual design hoặc chỉ thiết kế icon hoặc những thứ tương tự, khi mà bất cứ ai cũng có thể làm bất cứ điều gì, việc có một deep specialist slant như vậy tạo cảm giác, ồ vâng, họ thực sự có thể giúp phân biệt những thứ chúng ta đang xây dựng.

Người phỏng vấn: Tuyệt vời. Được rồi. Và về block-shape này, chúng tôi đã có Mark Andrees trên podcast. Chúng tôi gọi nó là F-shape hoặc E-shape nơi có nhiều chữ T. Chữ F nằm ngang, chữ E nằm ngang, tôi đoán vậy. Đó có phải là điều bạn đang mô tả, nơi có nhiều thứ bạn thực sự giỏi không?

Vâng. Vâng. Và cơ bản là, tôi không biết liệu bạn có gần như có skill set của họ không, nó sẽ trông như một khối, bạn biết đấy, như...

Người phỏng vấn: Có rất nhiều kỹ năng mà chữ T trải rộng ra. Được rồi.

Được rồi. Và craft new grad. Vậy đây là một người rất ham học hỏi, cởi mở, kiên cường, rất thông minh, tôi hình dung đó là một phần lớn của nó.

Vâng.

Người phỏng vấn: Tuyệt vời.

Vâng. Vâng.

Lời khuyên cho nhà thiết kế trẻ

Người phỏng vấn: Nếu một người là một designer mới, một young designer đang cố gắng thâm nhập và thành công, lời khuyên của bạn dành cho họ là gì để giúp họ có cơ hội gia nhập Anthropic chẳng hạn?

Tôi sẽ nói hãy cứ xây dựng thật nhiều thứ, hãy thử nghiệm thật nhiều thứ, xây dựng những thứ thực tế. Tôi nghĩ điều đó có thể mang lại cảm giác... tôi không thực sự biết tình trạng của design education hay giáo dục hiện nay như thế nào, nhưng ít nhất từ thời tôi đi học thì mọi thứ rất theoretical và kiểu như "chúng tôi sẽ dạy bạn một số approaches và những thứ tương tự". Nhưng những người craft new grad giỏi nhất mà tôi biết chỉ đơn giản là những người sử dụng technology, xây dựng những thứ thực tế, không cảm thấy bị giới hạn bởi kinh nghiệm ít ỏi mà họ có thể có. Tôi nghĩ đôi khi họ thực sự không bị gánh nặng bởi điều đó, vì chúng ta có những kỳ vọng về bản thân sau khi làm việc trong ngành quá lâu, nhưng họ thì không và họ cảm thấy như mọi thứ đều có thể. Vì vậy, chỉ cần xây dựng rất nhiều thứ và chia sẻ chúng với mọi người, và tìm một community gồm những người cũng làm điều đó.

Vâng, tôi nghĩ điều mà tôi muốn nói ở đây là tôi đã học ở một trường mà sau khi tôi tốt nghiệp một thời gian, họ bắt đầu một thứ gọi là Socratica. Về cơ bản, toàn bộ ý tưởng của họ là xây dựng và giới thiệu các sản phẩm, gần giống như một science project. Và tôi nghĩ đã có một phong trào thực sự thú vị ở đó, những người chỉ đơn giản là xây dựng và thực hiện mọi thứ. Ví dụ, ai đó đã xây dựng dự án Claude robot. Điều này cũng xảy ra vài năm trước, nơi họ lắp ráp các robot chạy trên Claude. Và sau đó, một người khác đã làm điều gì đó mà cô ấy chỉ muốn dán googly eyes lên một chiếc xe buýt ở Boston. Và có một cảm giác vừa là agency về việc "vâng, chúng ta có thể làm mọi thứ", nhưng cũng là một community nơi mọi người chỉ thử và xây dựng mọi thứ và chia sẻ chúng với nhau. Vì vậy, bất kể điều đó trông như thế nào, tùy thuộc vào trường mà ai đó đang theo học hoặc sắp tốt nghiệp, vâng, làm những việc như vậy là điều sẽ khiến mọi người nổi bật.

Nhu cầu kỹ năng kỹ thuật cho nhà thiết kế hiện tại

Người phỏng vấn: Đối với các designer hiện tại đang ở giữa career path hoặc cấp senior, bạn có nghĩ rằng họ cần phải trở nên technical và học code, ít nhất là xây dựng, hay bạn nghĩ họ có thể thực sự thành công mà không cần tập trung vào điều đó và chỉ cần giỏi hơn ở những kỹ năng khác?

Tôi nghĩ chắc chắn sẽ hữu ích nếu bạn không cần phải học code đến mức có thể xây dựng mọi thứ từ đầu, nhưng tôi cảm thấy ngày càng nhiều từ vựng của designer hiện nay là việc triển khai một số thứ. Tuy nhiên, tôi tự hỏi rằng khi các model và sản phẩm ngày càng tốt hơn, liệu chúng ta có tiếp tục di chuyển lên các abstraction layer cao hơn và bạn sẽ không cần phải thực sự biết từng dòng code hoạt động như thế nào hay không. Nhưng tôi nghĩ điều tôi muốn nói là hãy bắt đầu đưa các coding tools vào toolkit của bạn, dù bạn có thực sự trở nên technical hay không. Tôi nghĩ bất kỳ designer nào cũng nên thực sự nhận thức và biết cách sử dụng các công cụ sẵn có, thay vì có thể học và rồi đi học React hoặc v.v.

Claude với vai trò nhà thiết kế

Người phỏng vấn: Bạn sẽ nói Claude hoặc Claude (mô hình AI) là một designer giỏi đến mức nào? Bạn có muốn tuyển dụng Claude làm designer không, hay nó chưa đạt đến trình độ đó?

Tôi không nghĩ Claude đã đạt đến trình độ đó. Tôi không nghĩ Claude đã đạt đến trình độ của một designer mà bạn sẽ tuyển dụng. Tôi nghĩ nó vẫn chưa phải là strong generalist hay deep specialist hay craft new grad.

AI và Thiết Kế Sáng Tạo

Tôi nghĩ AI khá tốt ở khâu đầu tiên và trong việc trình bày nhiều ý tưởng khác nhau cho bạn, nhưng chưa có gì thực sự "đặc biệt" hay "đáng để tuyển dụng" cả. Đây là tin tốt cho các nhà thiết kế (cười) vì hiện tại AI vẫn còn kém ở mảng này. Tôi rất tò mò muốn xem AI có thể phát triển đến mức nào. Đó là một câu hỏi lớn đang bỏ ngỏ: Liệu AI có thể tạo ra những trải nghiệm sáng tạo, độc đáo, mới lạ tuyệt vời, hay sẽ không bao giờ sánh kịp một nhà thiết kế con người? Dù sao thì, AI đã tốt hơn rất nhiều trong khoảng một năm trở lại đây.

Thời Gian "Kém Hiệu Quả" Của Quản Lý: Đòn Bẩy Cao

Có một vài "nghi thức" hoặc quan điểm quản lý mà tôi muốn đề cập, mà tôi đã nghe từ những người làm việc cùng bạn. Một trong số đó là quan điểm táo bạo của bạn rằng "thời gian đòn bẩy thấp" đối với một quản lý thực ra không tồn tại, và có rất nhiều lợi ích có thể đạt được từ những việc mà mọi người coi là đòn bẩy thấp. Bạn có thể nói thêm về điều đó không?

Vâng, tôi nhớ khi mới trở thành quản lý, một trong những lời khuyên tôi nhận được từ một khóa học hay một cuốn sách nào đó là: "Bây giờ bạn là quản lý, bạn phải thực sự ưu tiên thời gian và phân loại công việc của mình." Có một ma trận 2x2 mà tôi không nhớ chính xác là gì, nhưng về cơ bản, nó nói rằng: "Đây là những việc chỉ mình tôi làm được," "đây là những việc người khác có thể làm," và mọi thứ còn lại được coi là đòn bẩy thấp và bạn không nên làm nữa. Rất nhiều việc đòn bẩy thấp chỉ là những chi tiết nhỏ nhặt, hoặc đúng là những task mà người khác có thể làm.

Nhưng khi tôi nghĩ về những lãnh đạoquản lý mà tôi kính trọng nhất, tôi thực sự nghĩ rằng một số đặc điểm tốt nhất của họ là họ chọn những task có vẻ là đòn bẩy thấp để tự mình thực hiện, và điều đó cuối cùng lại trở thành một hành động có đòn bẩy rất cao, bởi vì chính họ là người làm điều đó.

Một ví dụ là khi các lãnh đạo cấp cao tự mình thử nghiệm sản phẩm một cách kỹ lưỡng và họ rất am hiểu về nó. Họ dog food (tự dùng sản phẩm của mình), tái hiện lỗi, dành nhiều thời gian với các kỹ sư để chia sẻ log và xem xét từng chi tiết. Tôi nghĩ rằng điều đó cuối cùng lại có đòn bẩy rất cao, mặc dù tốn nhiều thời gian tỉ mỉ, bởi vì nó tạo ra sự quen thuộc với sản phẩm, điều mà tôi nghĩ là rất tốt. Nó cũng tạo ra một không khí nơi mọi người cảm thấy "ồ, vị lãnh đạo cấp cao này thực sự quan tâm sâu sắc và họ thực sự hiểu rõ mọi ngóc ngách của sản phẩm, họ sẵn sàng xắn tay áo và đưa ra phản hồi, làm việc với đội ngũ về nó."

Và tôi cũng nghĩ tương tự, những gì tôi đã thấy là khi một lãnh đạo cấp cao có thể tự mình sửa một bug. Thậm chí tôi từng thấy Mike Kreger tự gửi PRs. Điều đó thực sự rất hay vì nó tạo cảm giác: "Tuyệt vời. Chúng ta đều là một đội ngũ và không có việc gì là dưới tầm người này." Một điều nữa tôi thích, mang tính văn hóa hơn, là khi ai đó cố gắng làm thiệp kỷ niệm hoặc thiệp chúc mừng thật đẹp cho đồng nghiệp. Điều đó cho thấy rằng một trợ lý hoặc ai đó có thể làm thiệp, nhưng lãnh đạo này lại là người quan tâm đến đội ngũ của mình đến mức tự bỏ công sức ra. Vì vậy, đó là điều tôi cố gắng thể hiện: lựa chọn những task tưởng chừng đòn bẩy thấp nhưng lại đáng để mình dành thời gian.

Vâng, điều đó thật thú vị. Ý bạn là, những việc đòn bẩy thấp lại là những việc thường có tác động lớn nhất, bởi vì cấp dưới sẽ không mong đợi bạn dành thời gian cho việc đó, và đó là lý do tại sao đòn bẩy thấp lại trở thành đòn bẩy cao.

Đúng vậy. Và tôi nghĩ đó là điều làm cho phong cách lãnh đạo của bạn trở nên nổi bật hoặc đặc biệt đối với một người nào đó.

Xây Dựng Đội Ngũ Tuyệt Vời: An Toàn Tâm Lý và Tiêu Chuẩn Cao

Tuyệt vời. Một "nghi thức" hoặc cách điều hành đội ngũ mà tôi nghe nói về bạn là bạn khuyến khích thành viên đội ngũ "chọc ghẹo" nhau, điều mà thoạt nhìn có vẻ không phải là một môi trường tuyệt vời. Nhưng mặt khác, tôi liên tục nghe rằng các đội ngũ mà bạn đã xây dựng đều là những đội ngũ hạnh phúc nhất, có hiệu suất cao nhất. Hãy nói về ý tưởng này của việc "chọc ghẹo" và khuyến khích nó, cũng như những gì bạn đã học được về việc xây dựng các đội ngũ tuyệt vời.

Vâng, tôi nghĩ không phải là tôi nói: "Này, các bạn nên chọc ghẹo nhau," tôi không ép buộc theo cách đó hay bất cứ điều gì. Nhưng khi tôi nghĩ về an toàn tâm lý trong đội ngũ và những người hòa hợp với nhau, giống như khi bạn nghĩ về bạn bè của mình, bạn luôn sẵn lòng đẩy ranh giới một chút và chọc ghẹo họ. Bạn chọc ghẹo bạn bè rất nhiều, nhưng bạn có thể không chọc ghẹo đồng nghiệp nhiều vì đó là vấn đề về sự thoải mái và an toàn tâm lý, đúng không? Vì vậy, không phải là tôi muốn đội ngũ của mình phải chọc ghẹo nhau. Nhưng tôi nghĩ đó có thể là một dấu hiệu rất tốt khi các thành viên trong đội ngũ của bạn cảm thấy thoải mái khi trêu chọc nhau một chút.

Và tôi nghĩ đó cũng có thể là một dấu hiệu tốt khi mọi người cũng cảm thấy như vậy đối với bạn với tư cách là một lãnh đạo, tức là họ không quá sợ hãi bạn, và họ cảm thấy có một cảm giác an toàn tâm lý rằng nếu họ nói điều gì đó, họ sẽ không bị sa thải. Một ví dụ về điều này là với đội ngũ cuối cùng của tôi, tôi cảm thấy họ sẽ trêu chọc những điều tôi nói trong các buổi đánh giá đôi khi, như một số cụm từ nhất định tôi hay dùng.

Một ví dụ là gì?

Tôi không... Ồ, tôi sẽ luôn nói: "Được rồi, các bước tiếp theo là gì? Và làm thế nào chúng ta theo dõi điều này?" Và rồi họ sẽ bắt chước: "Được rồi, các bước tiếp theo là gì?" Và họ sẽ bắt chước tôi theo cách đó. Vâng, tôi nghĩ nó chỉ cho thấy một mức độ là: "Được rồi, những người này không nhất thiết phải sợ tôi. Họ biết rằng họ tin tưởng tôi. Họ có thể tin tưởng tôi." Và họ hiểu đủ về nhau và về tôi, về cuộc sống cá nhân của chúng tôi, để có thể biết ranh giới nằm ở đâu.

Nhưng đồng thời, tôi nghĩ điều bạn phải cẩn trọng trong lĩnh vực đó là liệu bạn, với tư cách là quản lý, có phải là bạn bè với cấp dưới của mình không, điều mà tôi nghĩ mọi người thường khuyên không nên làm. Và cách tôi nghĩ về việc cân bằng điều này là bạn phải tạo ra một nền tảng an toàn tâm lý, nơi mọi người cảm thấy thoải mái cả với nhau và với bạn, nhưng bạn cũng phải đảm bảo rằng họ biết bạn có tiêu chuẩn rất cao.

Và tôi nghĩ hai điều này có thể cảm thấy như đang đối lập nhau, nhưng tôi nghĩ chúng thực sự hoạt động rất tốt cùng nhau, bởi vì một khi bạn có an toàn tâm lý, mọi người tin tưởng lẫn nhau, và việc bạn áp dụng các tiêu chuẩn cao thực sự tôi nghĩ có thể trở nên dễ dàng hơn vì bạn có thể làm điều đó mà không sợ hãi. Và tôi hình dung điều này theo cách tiếp cận giống như làm một phụ huynh nghiêm khắc một chút, bạn biết đấy? Giống như: "Ồ vâng, đội ngũ của tôi, tôi làm việc với họ theo cách mà họ biết tôi sẽ luôn ở đó." Và tôi sẽ không sa thải họ một cách tùy tiện hay gì đó, nhưng đồng thời, họ cũng biết rằng tôi muốn những điều tốt đẹp nhất cho họ, bạn biết đấy, và tôi có tiêu chuẩn cao, và tôi đang làm việc với họ để tạo ra công việc tốt nhất có thể.

Vì vậy, đó là sự cân bằng tôi cần đạt được: bạn có thể tạo ra một môi trường mà đội ngũ của bạn cảm thấy thoải mái khi chọc ghẹo bạn, nhưng đồng thời họ cũng biết rằng họ phải làm việc xuất sắc và họ sẽ làm việc xuất sắc cùng bạn.

Đó là lời khuyên tuyệt vời. Thật thú vị khi phong cách quản lý này, hay quản lý tốt, thường quay trở lại. Nó làm tôi nhớ đến Radical Candor – sự kết hợp giữa quan tâm sâu sắc và thách thức trực tiếp.

Đúng vậy. Và đó là điều tôi nghe được ở đây: hãy đảm bảo mọi người biết rằng bạn quan tâm sâu sắc đến họ, nhưng cũng phải rất trực tiếp và có tiêu chuẩn cao.

Vâng, vâng.

Khuôn Khổ Legibility Và Ý Tưởng Illegible

Thật thú vị. Được rồi, có lẽ là câu hỏi cuối cùng. Tôi luôn tìm kiếm các khuôn khổ, phương pháp và quy trình thú vị mà mọi người đã thấy hữu ích trong công việc của họ, và tôi nghe nói bạn là một fan hâm mộ lớn của một thứ gọi là legibility framework (khuôn khổ dễ hiểu/khó hiểu). Hãy nói về nó, cách bạn sử dụng nó và tại sao nó lại có giá trị.

Vâng, khuôn khổ này tôi nghĩ tôi đã thấy trên Twitter có lẽ vào năm ngoái. Đó là Evan Tana, một đối tác tại SPC – anh ấy là một VC. Về cơ bản, đó là một ma trận 2x2. Tôi không nghĩ nó nhận được nhiều sự chú ý lắm, nhưng một khi tôi bắt đầu thấy nó, tôi thực sự không thể ngừng suy nghĩ về nó.

Trong ma trận 2x2 này, các nhà sáng lập (founder) có thể illegible (khó hiểu) hoặc legible (dễ hiểu), và các ý tưởng (idea) cũng có thể illegible hoặc legible. Về cơ bản, anh ấy nói rằng nếu cả nhà sáng lậpý tưởng đều super legible (cực kỳ dễ hiểu), thì ý tưởng đó có lẽ không thực sự mới lạ, và ai đó đã hoặc sẽ thực hiện nó rồi, bạn thực sự không tìm thấy điều gì mới.

Nhưng điều thực sự thú vị là khi bản thân ý tưởngillegible. Và ý của anh ấy về illegibleý tưởng đó thực sự nằm ở mô hình tiên tiến (frontier), mọi người có thể chưa hiểu được, hoặc cách nó được trình bày chưa thực sự rõ ràng theo cách mà mọi người dễ hiểu nhất. Tôi nghĩ đây rõ ràng là một cách tốt để một VC hoạt động, bởi vì bạn đang cố gắng tìm kiếm những cơ hội mà mọi người không nhìn thấy và đưa chúng ra thế giới.

Nhưng tôi cũng nghĩ rằng một phần vai trò của nhà thiết kế, ít nhất là tại một phòng thí nghiệm tiên tiến (frontier lab) như Anthrop topic, là phát hiện những ý tưởng illegible và cố gắng hiểu bản chất của chúng, cũng như cách để lấy đó và biến đổi chúng, dù là thông qua kể chuyện (storytelling) hay thông qua trải nghiệm người dùng (UX) thực tế và yếu tố hình thức (form factor), rồi đưa chúng ra thị trường. Và tôi nghĩ rằng, giống như khi tôi đề cập đến việc lướt Slack và xem tất cả những thứ mọi người đang tạo ra, đó chính là điều tôi đang làm. Tôi đang cố gắng xem: "Ồ, những ý tưởng nào thực sự có năng lượng xung quanh nhưng có thể chưa hợp lý, và đáng để tôi suy nghĩ kỹ hơn trong công việc của mình?"

Có một ví dụ điển hình thực sự liên quan đến cowork, đó là một nguyên mẫu nội bộ mà chúng tôi gọi là Claude Studio, tôi nghĩ ai đó đã xây dựng nó vào khoảng giữa năm ngoái. Về cơ bản, đó chỉ là một giao diện mạnh mẽ, phức tạp được xây dựng trên một cơ chế tác nhân (agentic harness). Tôi nghĩ đó cũng có thể là Claude code vào thời điểm đó. Và nó có tất cả các màn hình hiển thị tất cả kiến thức, kỹ năng và những gì Claude đang thực hiện, cùng với việc xem trước các đầu ra của nó.

Và tôi nghĩ, đối với một nhà thiết kế, tôi nhìn vào nó và tôi đã nghĩ: "Đây là... tôi không biết chuyện gì đang xảy ra. Tôi thực sự không hiểu nó." Nhưng sau đó, tôi thấy những người trong nghiên cứu, những người xây dựng nó và những người nội bộ khác, có rất nhiều năng lượng xung quanh nó. Và tôi đã nghĩ: "Tuyệt vời. Tôi nghĩ có điều gì đó ở đây, nhưng tôi chỉ chưa hiểu nó." Và tôi nghĩ đó thực sự là một ví dụ về một ý tưởng illegible.

Đúc kết từ Nguyên Mẫu và Vai trò của Designer

Và cuối cùng, những gì ra đời từ đó là một khung kỹ năng (skills framework) và các tệp Markdown (markdown files) hướng dẫn Claude cách thực hiện một việc gì đó. Điều đó xuất phát từ nguyên mẫu (prototype) cụ thể mà tôi không trực tiếp tham gia, mà chủ yếu là những người làm việc trên nguyên mẫu này đã trích xuất nó. Nhưng khi bắt tay vào phát triển Claude co-work và tôi đang nghĩ về form factor cho những thứ đó, việc nhìn thấy nguyên mẫu kia và các loại thông tin mà mọi người thấy thực sự hữu ích – như nhìn thấy kế hoạch và các công việc cần làm của Claude, nhìn thấy ngữ cảnh của Claude và các tệp mà nó đang xử lý – những thứ đó chính là những gì tôi đã lấy từ nguyên mẫu đó và đưa vào Claude co-work. Vì vậy, tôi nghĩ về việc làm thế nào các designer có thể giống các VC (Quỹ đầu tư mạo hiểm) hơn theo cách này, chỉ khi chúng ta xem xét các nguyên mẫu nội bộ.

Các Mô Hình Thành Công Sớm Trong Khởi Nghiệp

Điều này siêu thú vị. Gần đây tôi đã thực hiện một dự án nghiên cứu với Terrence Rohan, một VC (Quỹ đầu tư mạo hiểm) thực thụ, nơi chúng tôi xem xét các mô hình chung của những người gia nhập các công ty rất sớm và sau đó đã đạt được thành công lớn, như Palantir, Stripe, LinearNotion. Những người gia nhập nhiều công ty này từ sớm đang tìm kiếm điều gì? Một trong những yếu tố là ý tưởng – nó điên rồ đến mức mọi người đều cười nhạo, rằng điều này là không thể, bạn sẽ không bao giờ làm được. Đây là điều điên rồ nhất. Tại sao bạn lại nghĩ đến nó, như Palantir hay OpenAI thực ra cũng là một trong số đó, chỉ là một phòng thí nghiệm nghiên cứu làm một số thứ. Vì vậy, thật thú vị là điều này không phải lúc nào cũng hiệu quả, và không phải mọi ý tưởng điên rồ, có vẻ vô lý đều sẽ tốt. Nhưng tôi nghĩ điều bạn đang nói là hãy chú ý đến những điều bạn thấy thú vị và chưa hoàn toàn rõ ràng. Có thể bạn sẽ là người giúp tổng hợp nó lại.

Đúng vậy. Nhưng cũng là nếu có một nguồn năng lượng nào đó xung quanh nó mà tôi không hoàn toàn hiểu, hãy tìm cách đi sâu hơn và cố gắng hiểu nó là gì. Đúng vậy. Vì tôi nghĩ những người thường hướng tới những ý tưởng ban đầu này, họ không phải lúc nào cũng có thể diễn đạt được lý do tại sao. Và bạn phải là người đi sâu hơn để hiểu điều đó. Đó là một trong ba mô hình mà chúng tôi tìm thấy. Một trong những mô hình khác là: hãy chú ý đến những người đang rất hào hứng với một điều gì đó, ngay cả khi bạn không hiểu. Chà. Và nó nghe có vẻ điên rồ. Thật thú vị. Vậy còn điều kia là gì? Ồ, các nhà sáng lập chỉ là top 1% là yếu tố còn lại, điều mà mọi người đều có ở Anthropic. Vì vậy, bạn đã có được điều đó.

Công việc thay đổi và đội ngũ Design của Anthropic

Ôi chao. Jenny, thật là một thời điểm điên rồ mà chúng ta đang sống. Thật nhiều thay đổi. Được rồi, trước khi chúng ta đến vòng hỏi nhanh cực kỳ thú vị, có điều gì khác mà tôi nên hỏi bạn mà bạn muốn gửi gắm đến người nghe, điều mà bạn muốn nhấn mạnh không? Tôi nghĩ tôi chỉ muốn nhắc đến đội ngũ Design của Anthropic và gửi lời khen ngợi đến họ, đơn giản vì họ là một đội ngũ rất khiêm tốn và không phải lúc nào cũng được công khai trên mạng xã hội, nhưng họ đang thực hiện rất nhiều công việc tuyệt vời, đặc biệt trong thời điểm này khi công việc của chúng ta đang thay đổi quá nhiều. Đội ngũ này rất kiên cường (resilient) và họ bao gồm toàn bộ những người có kỹ thuật rất tốt và chuyên về prototype cho đến những người có craft rất cao và đang đưa ra những sản phẩm tuyệt vời. Và chúng tôi đang tuyển dụng xuyên suốt năm. Vì vậy, tôi chỉ muốn nhắc đến điều đó nếu tôi không làm bạn sợ với cách chúng tôi làm việc nội bộ tại Anthropic. Nếu điều đó nghe thú vị hơn là đáng sợ thì rất muốn được kết nối. Điều nghe có vẻ thú vị là được tiếp cận các kênh Slack này hoặc tất cả các tính năng đang được xây dựng? Đúng vậy, đó là lợi ích cốt lõi.

Lời khuyên tuyển dụng và Mindset cho tương lai

Hãy nói chuyện với siêu trí tuệ ngay bây giờ và cho tôi biết tôi nên đầu tư vào đâu. Tôi chỉ đùa thôi. Và về việc tuyển dụng, có điều gì cụ thể mà mọi người nên cân nhắc nếu họ muốn ứng tuyển không? Hãy suy nghĩ một chút về các archetype mà tôi đã đề cập, đặc biệt là generalist mạnh mẽ (strong generalist) và chuyên gia sâu (deep specialist). Chúng tôi rất hứng thú với những người như vậy, nhưng nhìn chung là những người cảm thấy họ, bạn biết đấy, những archetype đó phù hợp với họ, nhưng cũng là những người thực sự hào hứng với công nghệ, đã xây dựng rất nhiều, và muốn ở trên tiền tuyến (frontier).

Vòng Hỏi Nhanh: Sách, Phim và Triết lý Cuộc sống

Tuyệt vời. Với điều đó, chúng ta đã đến vòng hỏi nhanh rất thú vị và chúng tôi có năm câu hỏi dành cho bạn. Jenny, bạn đã sẵn sàng chưa? Được rồi, tôi sẵn sàng. Bắt đầu nào. Hai hoặc ba cuốn sách mà bạn thường xuyên giới thiệu cho người khác nhất là gì? Cuốn đầu tiên là The Power Broker của Robert Caro, một đề xuất cực kỳ mạnh mẽ vì nó dài khoảng 1100 trang. Nhưng tôi nghĩ trong thời đại này khi khả năng tập trung của chúng ta quá ngắn, tôi nghĩ cuốn này thực sự đáng đọc từ đầu đến cuối. Bởi vì tôi nghĩ có rất ít bộ sưu tập hoặc hồi ký nào mà nó bao quát toàn bộ cuộc đời của một người và bạn có thể thấy cách một người thay đổi qua nhiều thập kỷ đó. Và đây cũng là một người thực sự gây tranh cãi, và thật tuyệt khi đọc một cái nhìn rất sắc thái về một người, Robert Moses, và tôi nghĩ chúng ta đang bỏ lỡ một số tư duy dài hạn này vì chúng ta quá bận tâm đến hiện tại. Vì vậy, đó chỉ là một lời nhắc nhở quan trọng rằng career path (lộ trình sự nghiệp) là dài, và nó cũng thực sự tốt để hiểu cách một người hoàn thành công việc rất tốt. Vì vậy, Power Broker. Cuốn thứ hai mà tôi giới thiệu cho rất nhiều người là một cuốn sách tên là Insomniac City, được viết bởi Bill Hayes, người là đối tác của nhà khoa học Oliver Sacks vào khoảng thời gian Oliver Sacks qua đời. Và đó chỉ là một cuốn hồi ký đẹp đẽ, thanh tao về những ngày cuối cùng của Oliver Sacks và câu chuyện tình yêu của họ. Tôi nghĩ điều này có rất ít liên quan đến nội dung trên podcast của bạn, Lenny, nhưng nó chỉ là một cuốn sách mà tôi thực sự yêu thích. Và nó khiến bạn suy nghĩ về sự hữu hạn của cuộc đời, nhưng cũng về tình yêu và cuộc sống, v.v. Vì vậy, đó là một trong những cuốn sách yêu thích của tôi. Mục tiêu của tôi ở đây không phải là, bạn biết đấy, tôi đang cố gắng tạo ra những con người Renaissance (Phục hưng). Vì vậy, tất cả những thứ khác này đều tuyệt vời. Thật thú vị, tôi thấy Julie Zhou, một design leader nổi tiếng, gần đây cũng đang đọc The Power Broker. Tôi không biết chuyện gì đang xảy ra ở đây, nó đang lan truyền trong giới design.

Phim, Chương trình TV và Sản phẩm yêu thích gần đây

Được rồi. Bạn có bộ phim hoặc chương trình TV gần đây yêu thích nào mà bạn thực sự thích không? Ừm, gần đây tôi đã xem A Sentimental Value. Tôi xem nó trên máy bay, đó là, bạn biết đấy, cách các đạo diễn muốn bạn xem phim của họ. Nhưng đó là một bộ phim Na Uy của cùng đạo diễn đã làm The Worst Person in the World. Tôi nghĩ chỉ riêng nhịp độ, cách viết, mối quan hệ giữa các nhân vật đã rất tinh tế và đẹp đẽ. Nó về cơ bản là về một gia đình, một bộ phim tâm lý gia đình, nhưng cũng về ngôi nhà mà họ đã sống suốt đời. Nó đẹp đẽ vì ngôi nhà cũng giống như một nhân vật. Vì vậy, tôi không biết phải nói gì khác về điều đó, nhưng đó là một bộ phim rất hay. Và sau đó tôi cũng muốn giới thiệu rõ ràng The Bear season 2. Bạn biết đấy, chúng ta đang theo dõi nó. Tôi nghĩ mọi người đều thích xem những người thực sự có năng lực trong công việc của họ làm một điều gì đó. Vì vậy, vâng. Tưởng tượng mình là một diễn viên trong chương trình đó, bạn phải học và ghi nhớ bao nhiêu thuật ngữ. Đúng vậy. Nó cũng có vẻ rất nhanh, họ làm rất nhiều thứ trong một cảnh quay và có rất nhiều chuyển động, v.v. Có vẻ thực sự rất khó để trở thành một diễn viên. Và tôi chỉ mới nhận ra gần đây Noah Wyle đã từng đóng ER khi còn trẻ, và bây giờ anh ấy là người đứng đầu điều này. Đúng vậy.

Phương châm sống và Use case của Co-work

Ôi chao. Được rồi. Sản phẩm yêu thích mà bạn gần đây khám phá và thực sự yêu thích không thể là co-work? Không phải là một sản phẩm tôi thực sự khám phá gần đây. Nhưng Retro tôi đã sử dụng nó được gần hai năm nay kể từ khi nó ra mắt. Và tôi nghĩ tôi đã khám phá ra những lợi ích mới của nó gần đây. Vì vậy, đối với những người không biết về Retro, nó giống như một ứng dụng chia sẻ ảnh cộng đồng nhỏ, trong đó bạn chỉ có thể chia sẻ ảnh từ mỗi tuần, từ một tuần cụ thể, chứ không phải từ mọi thời điểm. Và nó về cơ bản không có bất kỳ thứ gì của mạng xã hội. Bạn không thể thực sự thấy số lượt thích, không có quảng cáo, v.v. Nhưng một điều thực sự hay là bây giờ tôi đã sử dụng nó được 2 năm, tôi có thể nhìn lại mỗi năm và thấy như, "Ồ, đúng vậy, tuần này hai năm trước tôi đã làm điều này," và nó đã trở thành một cách thực sự đặc biệt để sống qua mỗi tuần trong cuộc đời tôi. Chà. Và đó cũng là một ứng dụng được thiết kế đẹp mắt nếu bạn đang tìm cách xây dựng gu thẩm mỹ của riêng mình trong design. Đúng vậy. Các designer rất thích Retro. Tôi có thể thấy điều đó. Được rồi. Bạn có một phương châm sống yêu thích nào mà bạn thường quay lại trong công việc hay cuộc sống không? Đúng vậy. Ừm, không chắc đó có phải là phương châm sống yêu thích của tôi không, nhưng một điều tôi thường bắt gặp mình nói rất nhiều là "Đó là nó." Bố tôi nói điều đó suốt. Tôi yêu nó. Đúng vậy. Nghe có vẻ rất thất bại, nhưng tôi hứa là không phải vậy. Tôi nghĩ với rất nhiều điều đang diễn ra trên thế giới hiện nay, đặc biệt là với ngành công nghiệp và mọi thứ, bạn không thể kiểm soát mọi thứ, và đôi khi "Đó là nó" chỉ mang lại sự nhẹ nhàng mà bạn cần để tiến về phía trước. Tôi đã tham gia một khóa thiền 10 ngày cách đây một thời gian và tôi trở về từ đó và nói, "Bố ơi, bố đã đúng suốt thời gian qua. Đây là toàn bộ câu trả lời." Đó là nó. Bạn không thể bám víu, đừng cố gắng thay đổi. Cứ để nó là nó. Đó là nó. Có rất nhiều chiều sâu trong đó. Tôi đã nghĩ, "Được rồi, thông minh hơn tôi nghĩ."

Co-work cho phân tích nội tâm và xây dựng tiêu chí

Được rồi, câu hỏi cuối cùng. Quay trở lại co-work, có một use case (trường hợp sử dụng) nào đó khiến bạn kinh ngạc, một điều gì đó như, "Wow, thật tuyệt vời khi Co-work có thể làm được điều đó," hoặc là điều bạn dùng nó cho hoặc bạn đã nghe ai đó dùng nó cho không? Một điều tôi thực sự thích là phân tích nội tâm (introspection). Và vì vậy, tôi có một thư mục các ghi chú cục bộ mà tôi sử dụng IIA writer và tôi về cơ bản chỉ viết bất cứ điều gì và qua nhiều năm đã thu thập nó với rất nhiều ghi chú khác nhau và chúng bao gồm tất cả các loại điều khác nhau như one-on-one notes, những suy nghĩ ngẫu nhiên, các memo nhỏ, interview notes, v.v. Và điều yêu thích của tôi là nó rất tuyệt vời khi sử dụng co-work để phân tích những điều đó và có được những hiểu biết sâu sắc từ đó và thực sự tạo ra những thứ từ đó. Vì vậy, bất cứ khi nào tôi có thể học được điều gì đó mới về bản thân, tôi đều yêu thích điều đó. Nhưng tôi nghĩ một điều rất thực tế mà tôi đã làm với nó ngày hôm trước là liên quan đến việc tuyển dụng, tôi đã nghĩ, "Ồ, đúng vậy, tôi muốn diễn đạt rõ ràng điều mà tôi tìm kiếm, điều tôi tìm kiếm trong design craft vì tôi nghĩ thực ra rất nhiều người gặp khó khăn trong việc diễn đạt điều đó." Và tôi chỉ yêu cầu nó đọc qua tất cả các ghi chú của tôi, cả interview notes và những điều khác mà tôi quan tâm cũng như các memo và những thứ tương tự mà tôi đã viết trong quá khứ, và sau đó nó đã tạo cho tôi một rubric (bộ tiêu chí đánh giá) để đánh giá điều đó. Vì vậy, kiểu phân tích nội tâm đó, nơi mà "Ồ, tôi thậm chí không nhận ra những điều này về bản thân mình mà tôi đã thể hiện một cách ngầm định," điều đó thực sự tuyệt vời đối với tôi. Điều đó thật tuyệt vời.

AI trong Phân Tích Dữ Liệu Cá Nhân

Để mọi người hiểu rõ hơn, bạn có một thư mục chứa tất cả những gì bạn đã viết: các buổi họp 1-1, các cuộc họp, bạn có thể sử dụng — tôi không biết liệu các bạn có được phép dùng Granola hay những công cụ tương tự không — như bản ghi cuộc họp, và hỏi AI. Tôi định hỏi bạn dùng câu lệnh/lời nhắc nào, nhưng dường như chỉ đơn giản là 'Đọc tất cả những gì tôi đã viết và giúp tôi hiểu cảm nhận của mình về thiết kế là gì.'

Vâng, về cơ bản tôi nghĩ là: 'Này, tôi có rất nhiều ghi chú phỏng vấn và ghi chú liên quan đến kỹ năng thiết kế trong thư mục này. Hãy đọc chúng và giúp tôi tạo một rubric ghi nhớ để đánh giá kỹ năng trong các buổi phỏng vấn.' Thật tuyệt vời. Vâng.

Lời Khuyên và Cách Kết Nối

Jenny, buổi trò chuyện này thật tuyệt vời. Thật là một thời điểm đáng sống. Thật là một thời điểm.

Hai câu hỏi cuối cùng: Mọi người có thể tìm thấy bạn ở đâu trực tuyến nếu muốn liên hệ, và thính giả có thể hữu ích cho bạn bằng cách nào?

Vâng. Ờm, tôi có mặt trên Twitter/X, cái tên mà chúng ta gọi nó những ngày này. Tên người dùng là jenny_wen. Đó có lẽ là nơi tốt nhất. Tôi không dùng LinkedIn nhiều. Vì vậy, đó là nơi tốt nhất. Và làm thế nào để mọi người có thể giúp ích cho tôi? Hãy gửi cho chúng tôi phản hồi sản phẩm của bạn. Bạn biết đấy, chúng tôi đang phát triển co-work hoặc bất cứ điều gì liên quan đến Claude. Chỉ cần gửi cho chúng tôi phản hồi của bạn. Chúng tôi rất muốn cải thiện nó cho bạn.

Lời Kết

Jenny, cảm ơn bạn rất nhiều vì đã có mặt tại đây. Vâng, dĩ nhiên rồi. Thật tuyệt khi được trò chuyện với Lenny. Thật tuyệt vời. Jenny, cảm ơn bạn. Tạm biệt mọi người.

Cảm ơn bạn rất nhiều vì đã lắng nghe. Nếu bạn thấy nội dung này hữu ích, bạn có thể đăng ký theo dõi chương trình trên Apple Podcast, Spotify hoặc ứng dụng podcast yêu thích của bạn. Ngoài ra, xin hãy cân nhắc để lại đánh giá hoặc bình luận vì điều đó thực sự giúp những thính giả khác tìm thấy podcast. Bạn có thể tìm tất cả các tập trước hoặc tìm hiểu thêm về chương trình tại lennyspodcast.com. Hẹn gặp lại bạn trong tập tiếp theo.

Góp ý / Báo lỗiPhát hiện sai sót hoặc có ý tưởng cải thiện?