Giờ đây tôi thiết kế với Claude nhiều hơn Figma
(blog.janestreet.com)- Chuyển từ quy trình thiết kế dựa trên việc viết tài liệu đặc tả và mockup trong Figma sang trực tiếp biến ý tưởng trong đầu thành chức năng nguyên mẫu có thể hoạt động
- Trước đây từng hoài nghi về các LLM như Copilot, Cursor, Gemini, nhưng sau khi gia nhập Jane Street đã cảm nhận rõ rằng hỗ trợ AI là điều thiết yếu
- Claude cho phép lặp lại miễn phí và không giới hạn, nên dù thay đổi đến 50 lần vẫn không phàn nàn, giúp cải thiện chi tiết như nút Submit, phím tắt, chỉnh sửa câu chữ
- Nhà thiết kế cũng có thể tự tạo POC đang hoạt động như kỹ sư, để người khác trực tiếp dùng thử và đánh giá
- Bằng cách dồn toàn bộ nỗ lực vào chính sản phẩm đầu ra thực tế, cách làm này dẫn tới một mô hình cộng tác mới loại bỏ các công việc phụ ở giai đoạn trung gian
Chuyển từ hoài nghi về LLM
- Trong thời gian dài đã hoài nghi về LLM, và mỗi lần dùng đều thất vọng với kết quả
- Năm ngoái khi muốn sửa trò chơi tự làm, đã thử Copilot và Cursor nhưng cả hai đều không tạo ra được thay đổi có thể chạy được
- Ở công ty trước, từng dùng Gemini để làm dàn ý product brief và wireframe, nhưng cuối cùng đều bị bỏ
- Tất cả những lĩnh vực từng thử LLM đều là việc vốn đã làm tốt, và kết quả còn tệ hơn tự làm
- Sau khi gia nhập Jane Street vào mùa hè năm ngoái, đã cảm nhận rõ rằng hỗ trợ AI là điều bắt buộc
- Vì có nhiều lĩnh vực mới và còn chưa thành thạo như OCaml và Bonsai
- Điều bất ngờ lớn nhất là ngay cả quy trình thiết kế, lĩnh vực mình giỏi nhất, cũng đã thay đổi
Quy trình làm việc xoay quanh nguyên mẫu
- Thay vì viết tài liệu đặc tả, mockup Figma, proposal, rồi review việc triển khai với lập trình viên, tác giả trực tiếp xây dựng chức năng nguyên mẫu thực hiện đúng điều mình muốn
-
Luồng công việc thực tế
- Viết ra vấn đề và đề xuất bằng lời
- Mở editor, chạy build, server và Claude, rồi dùng phần mô tả đã viết làm prompt
- Trước tiên làm cho chức năng cơ bản chạy được để chứng minh tính khả thi
- Lặp lại bao nhiêu lần tùy ý
- Push thay đổi vào môi trường phát triển và thu thập ý kiến người dùng
- Gửi feature có hình thức và hành vi như mong muốn (ở công ty này tương đương với pull request)
- Nguyên mẫu nằm ngay trong codebase thực tế tốt hơn mockup hay tài liệu ở gần như mọi mặt
Ví dụ nguyên mẫu nhập JSQL
- Gần đây đã tạo một nguyên mẫu thêm LLM prompting vào JSQL input
- JSQL là một phương ngữ SQL nội bộ được dùng trong nhiều công cụ dành cho các nhóm người dùng khác nhau
- Nó thực sự hoạt động, và đã được dùng, thử nghiệm, sống cùng nó trong vài ngày
- Claude cho phép lặp lại miễn phí và không giới hạn, nên không bận tâm cả khi đổi ý lần thứ 50 hoặc yêu cầu những chỉnh sửa nhỏ
- Tinh chỉnh nút Submit, thêm phím tắt bàn phím, sửa câu chữ, điều chỉnh prompt, thêm thông báo xác nhận dạng tạo sinh
- Ở công ty cũ, những cải tiến như vậy sẽ cần qua lại giữa kỹ thuật và thiết kế trong vài ngày đến vài tuần, hoặc thậm chí chẳng bao giờ được làm
- Mọi nỗ lực đều được dồn vào việc cải thiện sản phẩm đầu ra thực tế, chứ không tiêu tốn vào các việc phụ như tạo component trong Figma hay định dạng tài liệu
Quá trình định hình quy trình làm việc
- Cũng phải mất thời gian mới đi đến được cách làm này
- Lúc mới gia nhập, chỉ dùng AI cho những việc nhỏ như sửa các lỗi UX lặt vặt
- Với các ý tưởng lớn hơn vẫn dùng Figma và tài liệu, còn thử với Claude thì thất bại
- Trong hai tháng qua, số tình huống phải với tay sang Figma đã giảm mạnh
- Nhờ sự kết hợp giữa việc mô hình tốt hơn, bản thân thành thạo hơn và chọn đúng phạm vi, AI giờ đây cũng hoạt động với các việc lớn hơn
- Ngoài prompt JSQL, còn có nhiều nguyên mẫu xử lý thay đổi cho ứng dụng hướng người dùng, data model và thư viện, trong đó có một số diff hơn 2000 dòng
- Có khi thiết kế trong Figma rồi mới triển khai nguyên mẫu tương tác, còn với một số ứng dụng mới thì bỏ qua Figma hoàn toàn và lặp lại thiết kế hình ảnh với Claude ngay từ đầu
Sức mạnh trao cho nhà thiết kế
- Kỹ sư khi có ý tưởng có thể tự làm ra một bản proof of concept hoạt động được, còn nhà thiết kế thì phải thuyết phục người khác
- Với ý tưởng như “LLM prompting trực tiếp trong JSQL input”, ở thời điểm bắt đầu thậm chí còn chưa rõ có khả thi hay không, nên giao cho ai đó làm nguyên mẫu có thể là lãng phí thời gian
- Cũng có thể đó là một đề xuất không thực sự đáp ứng rõ ràng nhu cầu người dùng
- Khi hiện thực hóa ý tưởng bằng Claude, người khác sẽ dễ dàng hơn nhiều trong việc trực tiếp dùng thử và đánh giá
Thách thức trong cách review
- Nhược điểm là reviewer sẽ nhận được một chức năng đã hoàn thiện
- Dấy lên câu hỏi liệu họ có bị đặt vào tình huống chỉ review code mà không có quyền đóng góp vào bản thân chức năng hay không
- Điều này giống như trong mảng thiết kế, PM đưa wireframe chi tiết rồi yêu cầu “chỉ cần làm cho nó đẹp”
- Tác giả muốn đề xuất phải rõ ràng và đầy đủ nhất có thể, nhưng cũng muốn các đồng nghiệp kỹ sư cùng lặp lại trong không gian thiết kế như khi làm với mockup Figma
-
Giải pháp hiện tại
- Chọn nhìn nhận feature theo cách khác và viết phần hướng dẫn ngắn trong mô tả
- Nguyên mẫu là một tài liệu đề xuất sống, code chỉ mang tính dùng một lần, còn vai trò của reviewer là đưa phản hồi về thiết kế và trải nghiệm người dùng
- Cuối cùng reviewer sẽ tiếp nhận ý tưởng và triển khai nó trong một feature riêng, tham chiếu nguyên mẫu nhưng trực tiếp sở hữu code production
- Điều gì là hợp lý và mang lại cảm giác tốt vẫn đang tiếp tục được tìm kiếm
Lo ngại và sự căng thẳng quen thuộc
- Có nỗi lo rằng khi thiết kế với Claude, mình có thể rời xa kiểu tư duy linh hoạt và sáng tạo để mắc kẹt trong lối nghĩ lặp lại quanh những gì mình tin Claude có thể tạo ra
- Điều này có thể ổn với các công cụ trưởng thành chỉ cần thay đổi dần dần, nhưng khi làm thứ mới thì có thể bỏ lỡ ý tưởng
- Đây là một sự căng thẳng quen thuộc, gợi lại cuộc tranh luận năm 2011 về việc nhà thiết kế có nên viết code hay không
- Những người phản đối cho rằng khi bắt đầu lập trình, sẽ khó tạo ra các thay đổi lớn trong ý tưởng
- Tuy vậy, vì đều thích làm website và lập trình nên tác giả vẫn tiếp tục viết code
- Khi các framework frontend như React trở nên phổ biến và việc phát triển phức tạp hơn, tác giả đã chọn chuyên môn hóa
- Các dự án cá nhân vẫn được làm bằng React, điều này giúp giao tiếp tốt hơn với lập trình viên
- Phần lớn thời gian làm việc vẫn dành cho Figma và tài liệu
- Nếu gia nhập Jane Street trước thời kỳ LLM, có lẽ tác giả đã còn lún sâu hơn vào Figma
- Dù có chút kinh nghiệm với JavaScript, OCaml và Bonsai lại hoàn toàn mới, nên đóng góp về mặt kỹ thuật hẳn sẽ cảm thấy ngoài tầm với
- Thay vào đó, giờ đây tác giả lại đang tạo ra sản phẩm đầu ra thực tế, cảm thấy rất thú vị khi quay lại với chính medium đó và thấy mình có nhiều tự do hơn để thử bất cứ điều gì
1 bình luận
Ý kiến trên Hacker News
Phía business vốn đã hay mang yêu cầu đến dưới dạng giải pháp do chính họ nghĩ ra, mà thường lại là thứ kiểu cỗ máy Rube Goldberg, nên phải reverse engineer qua đối thoại mới chạm được tới yêu cầu thật sự
Sắp tới có vẻ họ sẽ mang đến những giải pháp đã “sẵn sàng” và “đang chạy”, rồi càng ít cởi mở hơn với chuyện cùng nhìn tổng thể thiết kế và kiến trúc
Kiểu sẽ thành: “Cứ làm như này là được mà. Gần xong rồi, sao còn cần X insight nữa?”
Điểm trừ là phía business không hiểu vì sao không thể cứ thế đưa app đó lên production
Áp lực kiểu “AI giúp đi nhanh hơn mà” sẽ ngày càng lớn, và cuối cùng có lẽ sẽ phụ thuộc vào động lực tổ chức có lành mạnh hay không
Điểm cộng là ý tưởng được kiểm chứng kỹ hơn nhiều so với một bản phác trên khăn giấy
Claude hẳn đã hỏi về các edge case và quyết định thiết kế rồi, và nhiều khả năng đến một lúc nào đó đã có những chỉ thị rõ ràng như “đừng lo chuyện đó, cứ giả định đi” hoặc “dùng vài lần rồi thấy tương tác này không ổn, đổi giúp tôi”
Hiện tại áp lực “có vấn đề gì đâu, cứ deploy đi” rất mạnh, rất ngớ ngẩn và làm tụt tinh thần nên gần như là lỗ ròng, nhưng nếu ổn định lại thì biết đâu về sau sẽ thành lãi ròng cho các dự án tương lai
Mà những chỉnh sửa nhỏ đó lại là kiểu layout vỡ nếu trình duyệt không đúng 1920px chiều rộng, filter và sort thỉnh thoảng hoạt động sai, hoặc sau một số thao tác thì giá trị mới không được cập nhật đúng trong app
Bất kể vấn đề là gì, phía business vẫn nghĩ họ đã làm xong 95%, nên mặc định trước rằng “dev có kinh nghiệm thì sửa nhanh thôi”
Mọi người quen với kết quả mình đang có hơn, và khó chấp nhận những thay đổi trong bản mix chuyên nghiệp mới hơn
Có những PM, CSM, TAM có cảm giác tốt trong việc chuyển bài toán khách hàng thành tính năng sản phẩm dễ dùng, nhưng nếu bỏ qua khâu định nghĩa vấn đề và để một tổ chức chức năng khác đi xây giải pháp thì thường sẽ dẫn tới thảm họa, lãng phí lớn cho engineering và các nguồn lực khác
Khi ai đó mang một giải pháp tới, rủi ro là phải mất vài tháng xây phần mềm đủ để vận hành được rồi mới phát hiện khách hàng ghét nó, nó không giải quyết được vấn đề hoặc còn tạo ra vấn đề mới
Không phải ở chỗ tôi đang làm mà là chỗ cũ, và họ đã cứ thế đưa lên production dù có cả mất dữ liệu lẫn vấn đề bảo mật
Tôi nhớ Jane Street là nhà đầu tư của Anthropic, nên cũng nên tính tới điểm đó
Còn có chuyện vào tháng 7/2025, SEBI của Ấn Độ đã cấm Jane Street tiếp cận thị trường vì cáo buộc họ dùng nhiều pháp nhân để thao túng thị trường
Chắc vì những thùng tiền khổng lồ thì cần rất nhiều dashboard
Ở đây nhà thiết kế có vẻ đang tiếp cận sai, giống như bị cuốn vào kiểu ngưỡng mộ kỹ sư là muốn làm prototype sâu và sát thực tế nhất có thể
Nhưng đó không phải phần quan trọng nhất của công việc thiết kế
Phần quan trọng nhất là làm ra đúng thứ cần làm
Những câu hỏi như “Vì sao cần ô nhập JSQL? Thực sự họ muốn gì? Còn cách nào khác không?” thường được giải tốt hơn bằng phác thảo bút giấy, họp, quan sát và thảo luận
Tốt hơn là chốt quá nhanh vào một thiết kế cụ thể rồi lao vào tranh luận kiểu nút nên ở bên trái hay bên phải, hay chi tiết hành vi của LLM sẽ ra sao
Tất nhiên, cũng có thể đó chính là điều họ muốn mọi người nghĩ
Thỉnh thoảng tôi thấy điều này
LLM hiện tại không nhìn xa hơn vòng lặp lặp lại, nên tôi phải tự nghĩ vượt khung và hỏi kiểu “nếu nhìn từ góc này thì sao?” thì đột nhiên mới có cách thiết kế mới xuất hiện
Đôi khi còn phải làm lưu đồ để khiến LLM nhìn xa hơn giai đoạn tiến trình hiện tại của nó
Câu “Claude cho tôi số lần lặp miễn phí, không giới hạn, và không than phiền dù tôi đổi ý lần thứ 50 hay yêu cầu chỉnh sửa nhỏ” nghe như là không phải trả tiền cho Claude à?
Các studio thiết kế nhỏ cũng tương tự, và thường không tính theo giờ như dev
Tôi trả lời thật là mình cực kỳ tệ về thiết kế, và còn gặp vấn đề cả trong việc ngoại suy từ design system
Rất khó để tôi đi tới một điểm nhìn có vẻ ổn, và trong quá trình đó gần như lúc nào tôi cũng làm mọi thứ tệ hơn
Nhà thiết kế phỏng vấn tôi khi đó lại coi chuyện đó như công kích cá nhân rồi ép tôi rất căng
Trước đó cũng từng có trải nghiệm tương tự
Các designer ghét việc bị hỏi liên tục mọi thứ nên trông như thế nào, và muốn bàn giao theo kiểu đưa qua một lần là xong
Ngay cả ở các agency marketing và quảng cáo, tôi cũng phải cãi nhau liên tục để xin mẫu cho những thứ không có trong đặc tả thiết kế xem chúng nên trông ra sao
Không phải tôi nói mình đúng, nhưng đó là tử huyệt lớn của tôi
Vì thế khi nghe “miễn phí, không giới hạn, không than phiền”, điều đầu tiên tôi nghĩ tới là thời gian và sự kiên nhẫn chứ không phải tiền
Bolt tôi dùng để làm prototype thì không nổi giận
Nó có thể không tạo ra thiết kế tốt nhất, nhưng vẫn tốt hơn rất nhiều so với thứ tôi tự làm được, và khi xong thì có thể đưa cho một designer thật chỉnh cho tốt hơn
Cho đến lúc đó, tôi không phải lo chuyện làm ai đó bực mình
Tôi đã dùng Claude Design cho frontend.
Hình thức và cảm giác của kết quả đầu ra đủ ổn, nhưng thiết kế thường trông giống nhau và nhìn chung đi theo các mẫu rập khuôn của web hiện đại.
Tôi tò mò không biết có ai đã thử làm những thứ sáng tạo, phi điển hình với nó chưa.
Đến giờ tôi đã bỏ vào khoảng 3 tuần và vẫn chưa hoàn thiện, nhưng chắc cũng đủ để hình dung.
Cũng như 10 năm qua từng có SaaS boilerplate, giờ cũng có LLM boilerplate được học từ Internet.
Dù vậy, nếu chịu can thiệp đủ nhiều thì vẫn có thể làm gần như mọi thứ.
Điều thú vị là nó sẽ khớp với yêu cầu nếu bạn đưa ra, còn nếu không định hướng thì nó sẽ chọn phương án an toàn.
Nếu bạn định đánh giá thẩm mỹ của đầu ra cũng như trải nghiệm người dùng và nội dung, nhưng lại hầu như không đưa prompt về mặt thẩm mỹ, thì bạn sẽ chỉ nhận được các mặc định an toàn.
Nó làm tốt kiểu thiết kế mang cảm giác bản sao bootstrap/tailwind, nhưng bạn phải chủ động đẩy nó theo hướng khác.
Với các trang web đơn giản, tôi bắt đầu đặt trọng tâm duy nhất của vòng lặp đầu tiên vào phong cách thị giác.
Chỉ cần chỉ dẫn thật cụ thể để nó trông không quá tiêu chuẩn, và đưa ví dụ về kiểu website bạn muốn.
Nếu vật lộn một chút thì nó sẽ cho cảm giác sáng tạo hơn, nhưng vẫn cần công sức viết prompt.
Nó được các nhà thiết kế rất kỳ cựu và được tôn trọng cao giới thiệu cho tôi; giờ họ gần như làm prototype hoàn toàn trong Claude, rồi nếu thích thì tinh chỉnh lại trong Figma.
Ngay từ đầu, nếu bạn yêu cầu một UI chung chung mà không có prompt phong cách chi tiết, thì đương nhiên kết quả sẽ là thiết kế chung chung.
Điểm lợi ở đây là nhà thiết kế học coding.
Tôi luôn thấy lạ khi nhà thiết kế lại định hình phần mềm mà không hiểu phần mềm được tạo ra như thế nào.
Nhân tiện, tôi cũng là designer.
Tuy nhiên, thiết kế bằng code là một cách tiếp cận ưu tiên kỹ thuật.
Nếu mục tiêu của thiết kế là định hình đầu ra theo mục tiêu của con người, thì cũng có thể nói rằng tốt hơn là không nên bắt đầu từ những quy tắc cứng nhắc của code.
Không phải vì nó cho ra kết quả đẹp hơn, mà vì để đẩy tư duy tiến lên thì bút và giấy vẫn rất khó bị đánh bại.
Giờ thì gần như có thể code bằng giọng nói, nên tôi lại quay về với vibe coding và xây sản phẩm, và cảm giác thật tuyệt.
Sếp tôi vẫn đang cố nắm bắt tình hình mới này, nhưng có vẻ như sự phân chia vai trò kiểu cũ đang bắt đầu chết dần.
Tôi nghĩ đứng ở giao điểm đó là vị trí tốt nhất lúc này.
Cảm giác như cả đời tôi đã chuẩn bị cho thời khắc này vậy.
Với designer, có lẽ nó giống Figma nhưng thay vì trình chỉnh sửa trực quan thì bạn nhìn kết quả và sửa bằng ngôn ngữ.
Vợ tôi là product manager ở một công ty FAANG, và đội của cô ấy đang cực kỳ dựa vào AI để vibe coding những mẩu phần mềm mà trước đây đáng ra họ sẽ làm bằng Word hay Excel.
Họ không học coding, và cũng không nhìn vào code lấy một giây.
Cách tiếp cận kiểu “prototype là tài liệu đề xuất sống, code có thể vứt đi, và nhiệm vụ của reviewer là phản hồi về thiết kế và trải nghiệm người dùng.
Cuối cùng reviewer sẽ nhận lấy ý tưởng rồi triển khai thành một tính năng riêng, còn prototype chỉ được dùng để tham khảo, trong khi code production thì họ trực tiếp sở hữu” giải quyết được vấn đề tôi luôn gặp ở mọi POC.
Đây thực sự là một cách làm rất hay.
Khi xử lý một vấn đề cụ thể của một sản phẩm cụ thể, người ta rất dễ gọi nó là “tài liệu đề xuất”.
Nhưng vẫn còn vô số designer dùng Figma để định nghĩa và duy trì design system cho toàn bộ sản phẩm và nền tảng, và trong trường hợp đó Figma chính là nguồn chân lý.
Đội của chúng tôi cũng làm như vậy, và tôi là kỹ sư frontend, nhưng thành thật mà nói tôi thực sự nhớ cách làm cũ.
Khi đặc tả được viết bị thay bằng prototype chạy được, giờ đây phát sinh thêm gánh nặng nhận thức là phải đọc code để đoán xem thay đổi nào là chủ đích và đâu là nhiễu cần bỏ đi.
Tôi phải nhận các PR được tạo ra, rồi quyết định nên chỉnh trên đó hay làm lại từ đầu, mà cách nào cũng có ma sát.
Đã có lúc nó tạo ra cả đống thay đổi ngoài ý muốn, tôi bỏ thời gian re-implement rồi chuyển sang, để sau đó lại nhận câu “Ôi, xin lỗi, cái đó không phải thứ tôi định đổi đâu”.
Tôi hiểu việc nó trao quyền, nhưng nó cũng lấy đi một phần niềm vui tôi từng có trong công việc và biến nó thành chuyện đau đầu.
Phía thiết kế và sản phẩm dùng Claude để vibe-design hoặc vibe-code tính năng hay trải nghiệm, rồi làm prototype rất nhanh để mang ra trước khách hàng lấy phản hồi với lượng thời gian kỹ thuật tối thiểu.
Điều đó rất tuyệt.
Nhưng có lẽ điều gây ngạc nhiên là xét tổng thể, nó lại không giúp phát hành nhanh hơn bao nhiêu.
Tôi nghĩ lý do là vì trong quá trình đó, người ta đã đánh mất sự suy nghĩ.
Không ít phần tư duy giờ đã được thuê ngoài cho mô hình ngôn ngữ.
Nó sơn lấp những chỗ hở trong prompt và lấp đầy những hành vi chưa được nêu rõ bằng ảo giác.
Những điểm trước đây sẽ khiến ta dừng lại như “cái này có vẻ không khớp”, “mình truyền đạt ý tưởng này thế nào nhỉ”, “trường hợp này thì sao” nay đã biến mất, và giờ các chi tiết đó bị đẩy lùi đến sau khi đã làm ra cái gì đó.
Tất nhiên ta có thể cải thiện quy trình và nhìn lại cách tận dụng kỹ thuật mới này tốt hơn, nhưng nếu hỏi nó có tốt hơn trước không thì tôi không chắc.
Nó đang tàn lụi.
Giờ thì người làm backend cũng làm cả frontend.
Đó là một ngộ nhận.
Bạn có ngồi soi assembly do compiler sinh ra không? Không.
Vậy thì tại sao lại ngồi nhìn đống code này?
Chúng ta đã đẩy tầng trừu tượng lên cao hơn.
Tôi cũng dùng cách tiếp cận này khá nhiều
Ngay cả trước thời AI tôi cũng đã làm thủ công như vậy
Trước hết ngồi xuống với người dùng chỉ cùng cây bút và tờ giấy, sau đó nhanh chóng làm một POC hoặc bản demo frontend, để người dùng tự chạm vào thử rồi điều chỉnh cho đến khi nó hoạt động đúng như họ muốn
Với tôi, việc dùng code để làm một bản demo frontend nhanh thay vì chất lượng production vốn đã thường nhanh hơn so với việc tạo các tương tác chính xác trong Figma
Vì có thể tương tác hoàn toàn, tôi bắt được nhiều trường hợp biên ở phía trải nghiệm người dùng hơn rất nhiều
Giờ nhờ Claude Code mà tốc độ tạo các prototype dùng xong rồi bỏ còn nhanh hơn, nhưng không phải khác biệt quá lớn
Vì 80% tổng thời gian là để trao đổi với người dùng và suy nghĩ xem nó nên hoạt động thế nào, Claude chỉ giống như giúp cắt một nửa phần 20% còn lại so với khi tự tay làm nhanh
Bản đầu tiên thì nhanh hơn, nhưng khi chưa hiểu hoàn toàn thì việc lặp lại lại chậm hơn
Edwin, thấy bài này được đăng lên thật vui
Tôi nhớ là khoảng năm 2012/2013 chúng ta từng cùng tham gia hackathon
Khả năng đi đến một prototype hoạt động được nhanh hơn là điều rất tiếp sức, ngay cả khi luôn có cám dỗ muốn cứ thế đem một ý tưởng còn dang dở ra phát hành
Các yêu cầu về thiết kế và trải nghiệm người dùng hưởng lợi rất nhiều khi có thể vượt qua storyboard và wireframe để thực sự chạm vào và trải nghiệm luồng hoạt động