Thiết kế sản phẩm đang thay đổi

• Công cụ AI trực tiếp tận dụng design system để tạo UI, khiến vai trò của nhà thiết kế chuyển từ thiết kế thị giác đơn thuần sang trọng tâm là chiến lược và điều phối
• Giờ đây, câu hỏi cốt lõi không còn là “ai đang lấy mất việc của ai” mà là quy trình đang thay đổi như thế nào
• Những công việc vô hình như code, PRD, bản tóm tắt dễ tự động hóa hơn, nhưng các công việc hữu hình như UI và luồng mà người dùng trực tiếp nhìn thấy và tương tác có khoảng cách chất lượng lớn, nên tốc độ tự động hóa thiết kế vẫn chưa theo kịp kỹ thuật
• Quá trình chuyển mockup Figma sang code từng là nút thắt lớn nhất, nhưng nếu nhà thiết kế thiết kế trực tiếp trong môi trường code thì có thể loại bỏ hoàn toàn sự lãng phí của khâu handoff này
• Giá trị cốt lõi của nhà thiết kế trong thời đại AI không nằm ở công việc pixel mà ở năng lực orchestration: đánh giá nên làm gì, phản biện đầu ra của AI một cách sắc bén và điều phối công việc
• Những công ty đầu tư vào các nhóm nhỏ được trao quyền và design system có thể đọc được bởi máy sẽ vượt trội so với các tổ chức feature factory quy mô lớn

---

Bối cảnh của sự thay đổi trong thiết kế sản phẩm

• Kể từ khi làm website đầu tiên bằng Dreamweaver vào năm 1999, tác giả đã làm việc theo cách thiết kế bằng Photoshop, Sketch, Figma rồi chuyển cho lập trình viên
• Gần đây, tác giả kết nối Claude Code với design system nội bộ và tạo ra UI chạy thực tế chỉ với ba prompt, bỏ qua bước thiết kế thị giác truyền thống
• Qua trải nghiệm này, tác giả nhận ra giá trị của nhà thiết kế đang dịch chuyển từ năng lực thực thi sang “gu thẩm mỹ và phán đoán chiến lược”
• Khi AI hiện thực hóa luồng “prompt → tạo ra → triển khai” dựa trên design system, một thay đổi căn bản trong thiết kế sản phẩm đang diễn ra

Cuộc tranh luận sai hướng: thay đổi của quy trình chứ không phải số lượng nhân sự

• Diễn ngôn hiện tại về AI và các vai trò product vẫn đang mắc kẹt trong tranh chấp lãnh địa xoay quanh số lượng người, như “liệu designer có mất việc không” hay “engineer có bị thay thế không”
• Câu hỏi thật sự là về quy trình: AI không xóa bỏ các chức năng này mà thay đổi ai làm, làm nhanh đến mức nào và nút thắt sẽ dịch chuyển về đâu
• Những công việc vô hình (invisible work) như viết code, soạn PRD, phân tích dữ liệu dễ tự động hóa vì khoảng cách chất lượng được che giấu phía sau UI
  • Code có bẩn nhưng ứng dụng vẫn chạy thì không ai để ý, và PRD do AI tạo ra cũng không sao nếu vấn đề được định nghĩa đúng
• Ngược lại, những công việc hữu hình (visible work) như giao diện người dùng, luồng và trải nghiệm sẽ để lộ ngay khoảng cách chất lượng và người dùng nhận ra tức thì
• Khi việc build trở nên nhanh và rẻ hơn, vấn đề khó nhất không còn là “làm như thế nào” mà là “điều gì đáng để xây dựng”
• Tốc độ cải thiện của thiết kế có hỗ trợ AI tất yếu sẽ chậm hơn kỹ thuật, và tính bất đối xứng này sẽ tái cấu trúc toàn bộ quy trình phát triển sản phẩm cũng như cách tổ chức đội ngũ

Công việc hữu hình: thiết kế không nằm sau bức tường mà chính là bức tường

• Engineering có thể ví như hệ thống đường ống — nó ẩn sau bức tường, và chỉ cần nước chảy ra từ vòi thì cấu trúc bên trong không quan trọng
  • Boris Cherny vận hành đồng thời 4~5 coding agent và đạt mức tăng tốc hơn 400%, trong khi các kỹ sư ở Silicon Valley đang chuyển từ tự tay viết code sang orchestration một đội agent
• Thiết kế phần mềm lại chính là bức tường, là vòi nước và là tay cầm, nên dù AI tạo ra thì người dùng vẫn phản ứng nhạy cảm với hình thức và cảm giác sử dụng
• AI có thể làm theo chuẩn và mẫu có trong dữ liệu huấn luyện, nhưng khó xử lý những quyết định dựa trên nghiên cứu người dùng ở quy mô lớn như hàng chục cuộc phỏng vấn, kết quả khảo sát, phân tích hành vi sử dụng, audit đối thủ vì bối cảnh quá lớn
• Có một nút thắt gọi là vấn đề tiếp nhận (ingestion problem) — dù AI có thể tạo ra lượng lớn code hoặc tóm tắt cuộc họp, con người vẫn phải đọc, hấp thụ và đánh giá phản biện thì mới có thể đối thoại và ra quyết định một cách trí tuệ
  • Code review đang trở thành nút thắt thực sự, và đây là giới hạn của tốc độ con người mà không mô hình nào có thể né tránh
• AI rất giỏi tạo nội dung và tóm tắt, nhưng năng lực sáng tạo ra cái mới hay sở hữu gu thẩm mỹ (taste) vẫn chưa được chứng minh

Thiết kế trong code, không phải trong Figma

• Nút thắt lớn nhất trong phát triển sản phẩm là quá trình handoff giữa designer và developer để dịch mockup Figma thành code production
  • Việc vẽ hình ảnh phần mềm, chỉnh từng pixel rồi bàn giao cho engineer, sau đó QA đối chiếu code với mockup và trả lại PR vì lệch typography hay spacing là một sự phi hiệu quả khổng lồ
• AI có thể giải quyết nút thắt này, nhưng chỉ khi nhà thiết kế thiết kế trực tiếp trong môi trường code
• Một số designer thực sự đang hủy gói Figma và chuyển sang công cụ AI; lập luận cốt lõi là mockup không phải sản phẩm mà chỉ là một đầu ra song song cần được dịch, rà soát và điều chỉnh
  • Mỗi pixel đẩy ra từ Figma là một lời hứa mà engineer phải tuân thủ trong một môi trường hoàn toàn khác, và công cụ thiết kế càng xa code production thì lãng phí trong handoff càng tăng
• Thử nghiệm dùng Claude Code trỏ vào repo design system và tạo UI hoạt động chỉ bằng ba prompt đã xác nhận điều này
  • Để đạt độ tin cậy ở quy mô lớn cần có tài liệu vững chắc, quy tắc rõ ràng và agent orchestration, nhưng nền tảng đã sẵn sàng
• Trường hợp của đội engineering tại Monday.com: ở lần thử đầu tiên dán link Figma vào Cursor, code được tạo ra không dùng component của design system, màu sắc bị hardcode và typography ghi đè giá trị mặc định của hệ thống
  • Giải pháp là xây dựng design system MCP (Model Context Protocol) — biến component, token, quy tắc accessibility và pattern sử dụng thành dạng máy có thể đọc, rồi dùng workflow agentic 11 node để cung cấp ngữ cảnh có cấu trúc cho mô hình
  • Đây là cách tiếp cận “orchestration, không phải phép màu”: agent không trực tiếp viết code mà xây dựng hiểu biết về code nên trông như thế nào rồi chuyển cho coding agent của developer
• Designer tại Anthropic đang trực tiếp gửi pull request bằng Claude Code và sản phẩm console rồi triển khai lên production — tính đến tháng 2/2026, đây đã là thực tế

Điều còn lại cho con người: orchestration và phán đoán

• Nếu AI có thể làm cả tạo code, viết PRD, tóm tắt nghiên cứu và prototype giao diện, thì thứ còn lại cho con người là orchestration
  • Mô hình đã đủ năng lực; nút thắt nằm ở con người trước bàn phím — khả năng biết nên yêu cầu gì, chia nhỏ công việc ra sao và khi nào cần bác bỏ kết quả của mô hình mới là trọng yếu
• Kyle Zantos là một designer dành 70% thời gian làm việc trong terminal; anh nhấn mạnh rằng vì ngay cả khuyến nghị từ 4 tháng trước cũng đã lỗi thời, điều quan trọng là học triết lý và cách tiếp cận chứ không phải cấu hình công cụ cụ thể
• Arin Bhowmick, Chief Design Officer của SAP, cho rằng giao diện trau chuốt về mặt thị giác có thể che lấp các vấn đề sâu hơn như đầu ra không đáng tin cậy, quyết định thiếu minh bạch và hành vi yếu ở các edge case
  • Lãnh đạo thiết kế cần xem niềm tin, sự rõ ràng và độ tin cậy là đầu ra thiết kế hạng nhất, chứ không chỉ chất lượng bề mặt
• Theo Vlad Derdeicea, khoảng 80% thời gian của design lead được dùng cho giao tiếp, căn chỉnh và biện minh, còn công việc thiết kế trực tiếp chỉ chiếm 20%
  • Mọi quyết định thiết kế đều đi kèm “thuế biện minh” (justification tax) — thời gian để giải thích, ghi chép và bảo vệ những lựa chọn mà ở lĩnh vực khác có thể chỉ cần một cuộc trò chuyện ngắn
  • AI không nên chỉ nhắm vào công việc mockup mà phải nhắm vào 80% này: tổng hợp biên bản họp, soạn nháp giao tiếp với stakeholder, tóm tắt nghiên cứu và tạo prototype nhanh để giải quyết tranh luận bằng dữ liệu thay vì ý kiến
• Cách nhìn của Jan Tegze: đừng cố làm công việc hiện tại tốt hơn, mà hãy tìm ra những ràng buộc trong lĩnh vực tồn tại vì giới hạn của con người và loại bỏ chúng bằng agent — không chỉ tăng tốc công việc hiện tại mà làm được những điều trước đây là bất khả thi
  • “Không phải cạnh tranh với agent, mà là tạo ra năng lực mới đòi hỏi cả bạn và agent”
• Designer junior dưới 5 năm kinh nghiệm đối mặt rủi ro lớn hơn — vì họ thiếu năng lực phán đoán để đánh giá đầu ra AI và thiếu kinh nghiệm để phát hiện lỗi của mô hình; ngưỡng kỹ năng tối thiểu đang tăng lên

Nhóm nhỏ, đòn bẩy lớn

• Phần lớn công ty phần mềm hiện được tổ chức theo cấu trúc không còn phù hợp — một feature factory thừa PM đặt PM vào mỗi squad dù có hỗ trợ thiết kế chuyên trách hay không
  • PM bùng nổ trong thời kỳ ZIRP vì đây là vị trí gần doanh thu và số lượng tăng theo độ phức tạp tổ chức
  • Marty Cagan gọi đây là “nhà hát quản lý sản phẩm” — sự dư thừa của các PM kém hiệu quả, khác gì những project manager lương cao quá mức chuyên lập roadmap và điều hành standup
• Andrew Ng tại Davos dự đoán rằng nếu AI làm năng suất engineering bùng nổ, tỷ lệ PM so với engineer sẽ đảo từ 1:8 sang gần 1:1
  • Khi AI agent viết phần lớn code production, nền engineering đông đảo sẽ thu hẹp và đặc tả cùng phán đoán trở thành nguồn lực khan hiếm
• Airbnb đã hợp nhất product management và product marketing thành một vai trò “full-stack”
  • Brian Chesky: “Nếu bạn không biết cách nói về sản phẩm, bạn không thể xây dựng sản phẩm” — ông nâng storytelling và giao tiếp đối ngoại thành yếu tố hạng nhất của vai trò PM
  • Designer được nâng lên thành “kiến trúc sư” dẫn dắt sản phẩm cùng engineer, chứ không còn là dịch vụ phụ trợ xử lý ticket
  • Các công việc điều phối từng làm phình to đội ngũ PM được chuyển cho program manager chuyên trách
• Điều này tương tự mô hình tổ chức theo chức năng của Apple: chuyên gia dẫn dắt chuyên gia, CEO là điểm tích hợp, và không có PM kiểu “mini CEO” vận hành từng đơn vị kinh doanh
• Mô hình nhóm lý tưởng trong thời đại AI là nhóm nhỏ được trao quyền gồm 2~3 engineer, 1 PM, 1 designer
  • Design system trở thành hạ tầng cốt lõi; nếu không có design system trong code và tài liệu đầy đủ, AI sẽ đưa ra quyết định sai về UI và cách triển khai
  • Những công ty đầu tư vào design system máy có thể đọc và các nhóm nhỏ được trao quyền sẽ vượt xa những công ty vẫn duy trì squad 15 người và quy trình phê duyệt ba tầng

Hiệu ứng lãi kép: khoảng cách giữa người điều phối và người đẩy pixel

• Sau thí nghiệm dùng Claude Code tạo ra màn hình chạy được từ design system, tác giả đang cải tiến liên tục bằng tài liệu tốt hơn, quy tắc component nghiêm ngặt hơn và hướng dẫn kết hợp rõ ràng hơn
  • Mỗi vòng lặp đều nhanh hơn và gần mức production-ready hơn, khi cải thiện của mô hình, tinh luyện kỹ năng và năng lực điều phối đều tích lũy theo lãi kép
• Khoảng cách giữa “designer biết orchestration AI” và “designer chỉ đẩy pixel trong Figma” được dự báo sẽ trở nên rất lớn trong vòng 12 tháng
  • Không phải vì người đẩy pixel kém năng lực, mà vì người điều phối hoạt động ở một tốc độ và phạm vi hoàn toàn khác — khi người khác còn đang xuất mockup cho cuộc họp handoff, họ đã triển khai UI chạy được
• Tác giả đang dạy cách làm này cho đội ngũ, không phải vì nghề sẽ biến mất, mà vì nghề này đang trở thành một công việc nơi gu thẩm mỹ, năng lực phán đoán và khả năng điều phối công việc quan trọng hơn khả năng vẽ ra giao diện