Giờ tôi thiết kế với Claude nhiều hơn cả Figma
(blog.janestreet.com)- Quy trình thiết kế đang dịch chuyển từ cách làm đi qua tài liệu đặc tả và mockup Figma rồi mới rà soát triển khai, sang luồng tạo tính năng nguyên mẫu chạy được ngay trong codebase thực tế
- Copilot, Cursor và Gemini đều không đáp ứng kỳ vọng ở các việc như chỉnh sửa game, product brief hay wireframe vốn tưởng là “đúng bài” của chúng, nhưng trong môi trường OCaml và Bonsai còn mới phải học thì hỗ trợ AI lại trở thành yếu tố thiết yếu
- Quy trình giờ xoay quanh triển khai thực tế: đưa vấn đề và đề xuất vào prompt, dựng chức năng cơ bản, lặp lại chỉnh sửa, triển khai lên môi trường dev, xem phản hồi người dùng rồi gửi feature
- Một nguyên mẫu bổ sung prompting LLM vào ô nhập JSQL đã khiến tác giả tinh chỉnh nhiều vòng từ nút bấm, phím tắt, câu chữ, prompt đến thông điệp xác nhận, và dồn công sức vào đầu ra thực tế thay vì component Figma hay định dạng tài liệu
- Giờ đây designer có thể tự biến ý tưởng thành thứ dùng được, nhưng các nguyên mẫu trông như tính năng hoàn chỉnh cũng kéo theo thách thức mới cho cách tham gia review và khám phá sáng tạo
Từ hoài nghi về LLM sang công cụ hỗ trợ thiết yếu
- Trong thời gian dài, mỗi lần dùng LLM tôi đều thất vọng với kết quả, và mỗi khi áp dụng LLM vào những việc mình vốn làm tốt thì chất lượng lại thấp hơn tự làm
- Năm ngoái tôi dùng Copilot và Cursor để sửa một trò chơi mình làm, nhưng cả hai đều không tạo ra được thay đổi chạy được; ở công ty cũ tôi cũng thử dùng Gemini để tạo dàn ý product brief và wireframe, nhưng cuối cùng đều bỏ hết
- Sau khi gia nhập Jane Street vào mùa hè năm ngoái, tôi có quá nhiều thứ mới phải học, và với các công nghệ mình chưa quen như OCaml và Bonsai, hỗ trợ AI đóng vai trò thiết yếu
- Thay đổi lớn nhất là AI bắt đầu làm biến đổi cả quy trình thiết kế, vốn là phần tôi tự tin nhất
Nguyên mẫu ngay trong codebase thực tế thay cho Figma và tài liệu
- Thay vì viết tài liệu đặc tả, làm mockup Figma, soạn proposal rồi rà soát triển khai với developer, tôi tạo ra một tính năng nguyên mẫu thực hiện chính xác điều mình đang hình dung
- Luồng làm việc thực tế là viết ra vài câu mô tả vấn đề và đề xuất, rồi chạy build, server và Claude trong editor, dùng chính phần mô tả đó làm prompt
- Làm cho chức năng cơ bản chạy được để kiểm tra tính khả thi, rồi lặp đi lặp lại chỉnh sửa bao nhiêu lần tùy ý
- Đưa thay đổi lên môi trường dev, hỏi ý kiến người dùng, rồi gửi feature khi nó đã có hình thức và hành vi mình mong muốn
- Ở Jane Street, feature là quy trình tương đương với pull request
- Một tính năng nguyên mẫu bên trong codebase thực tế mang lại trải nghiệm tốt hơn mockup và tài liệu ở gần như mọi mặt
- Gần đây tôi đã làm một nguyên mẫu thêm prompting LLM vào ô nhập JSQL, và nó thực sự hoạt động; tôi còn tự dùng thử trong vài ngày để kiểm chứng
- JSQL là phương ngữ SQL nội bộ dùng cho nhiều công cụ hướng đến người dùng
- Claude cho phép lặp lại thoải mái gần như vô hạn, không hề khó chịu kể cả ở lần đổi ý thứ 50 hay các yêu cầu chỉnh sửa rất nhỏ
- Tôi đã cải thiện cả nút Submit, phím tắt bàn phím, câu chữ, prompt và thông điệp xác nhận được tạo ra
- Ở công ty cũ, đây sẽ là kiểu cải tiến quy trình cần nhiều ngày hoặc nhiều tuần qua lại giữa engineering và design, hoặc khả năng cao là sẽ không bao giờ diễn ra
- Công sức dành cho tính năng này tập trung vào cải thiện đầu ra thực tế, thay vì các sản phẩm trung gian như tạo component Figma hay chỉnh format tài liệu
Phạm vi mở rộng trong hai tháng gần đây
- Tôi mất khá nhiều thời gian mới đi đến được luồng làm việc này; hồi mới vào công ty, tôi chỉ dùng AI cho các việc nhỏ như sửa những điểm vướng UX lặt vặt
- Với các ý tưởng lớn hơn, tôi vẫn dùng Figma và tài liệu, còn các nỗ lực làm bằng Claude thì thất bại
- Nhưng trong 2 tháng qua, số lần tôi mở Figma đã giảm mạnh, nhờ sự kết hợp của model tốt hơn, kỹ năng dùng công cụ tốt hơn và chọn phạm vi phù hợp hơn
- AI không chỉ dùng cho prompt JSQL mà còn hoạt động với khoảng 6 nguyên mẫu khác, bao gồm thay đổi hướng đến người dùng, data model và thư viện
- Một số nguyên mẫu có diff hơn 2000 dòng
- Tôi cũng dùng nó để triển khai nguyên mẫu tương tác cho một ứng dụng mới vốn được thiết kế trong Figma
- Một số ứng dụng mới thậm chí bỏ qua Figma và lặp thiết kế trực quan bằng Claude ngay từ đầu
Mở rộng quyền chủ động cho designer và định nghĩa lại cách review
- Khi có ý tưởng, engineer có thể tự làm ra proof of concept chạy được; còn designer thì thường phải thuyết phục người khác làm giúp
- Với những ý tưởng như “prompting LLM trực tiếp trong ô nhập JSQL”, tính khả thi ở thời điểm bắt đầu chưa hề rõ ràng, nên nếu giao nguyên mẫu cho người khác làm thì rất dễ lãng phí thời gian
- Có những đề xuất có thể không đáp ứng rõ ràng nhu cầu người dùng; nhưng khi biến ý tưởng thành hình hài thực tế bằng Claude, người khác có thể trực tiếp dùng thử và đánh giá dễ hơn
- Mặt trái là reviewer nhận về thứ trông như một tính năng hoàn chỉnh, nên không rõ họ có phải chỉ review code mà không còn cơ hội góp ý vào bản thân tính năng hay không
- Nếu ví sang design, điều này giống như PM đưa một wireframe quá chi tiết rồi yêu cầu bạn chỉ việc làm cho nó đẹp lên, và đó không phải kiểu review dễ chịu
- Đề xuất cần rõ ràng và đầy đủ, nhưng đồng thời cũng cần để đồng nghiệp engineer đối xử với nó như một mockup Figma, tức là một đối tượng để cùng lặp lại trong không gian thiết kế
- Giải pháp hiện tại là thêm một lưu ý ngắn trong phần mô tả feature
- Nguyên mẫu là một tài liệu đề xuất sống
- Code có thể bị bỏ đi
- Vai trò của reviewer là đưa ra phản hồi về design và trải nghiệm người dùng
- Cuối cùng, reviewer có thể tiếp nhận ý tưởng, triển khai nó trong một feature riêng, tham chiếu nguyên mẫu nhưng sở hữu phần code production
- Trong công việc thực tế, chúng tôi vẫn đang tiếp tục xác định điều gì là hợp lý và tạo cảm giác đúng trong quy trình mới này
Giới hạn của lối làm việc lặp lại và cảm giác quay về với vật liệu thực
- Có một nỗi lo rằng thiết kế bằng Claude có thể đẩy tôi rời xa cách suy nghĩ linh hoạt và giàu sáng tạo, khiến tôi mắc kẹt trong kiểu lặp lại chỉ quanh quẩn trong những kết quả mà mình nghĩ Claude có thể tạo ra
- Điều này không sao với các công cụ đã trưởng thành, nơi thay đổi chủ yếu mang tính lặp lại; nhưng khi tạo ra thứ mới, luôn có nguy cơ bỏ lỡ ý tưởng
- Vào khoảng năm 2011, khi tôi bắt đầu sự nghiệp chuyên nghiệp, đã có rất nhiều tranh luận về designers should code, và phe phản đối cho rằng một khi bắt đầu lập trình, bạn sẽ khó tạo ra những thay đổi lớn cho ý tưởng
- Tôi vốn thích làm website và lập trình nên vẫn tiếp tục viết code; đến khi các framework frontend như React trở nên phổ biến và frontend development phức tạp hơn, tôi chọn chuyên môn hóa
- Các dự án React cá nhân giúp tôi tương tác tốt hơn với developer, nhưng ở nơi làm việc tôi vẫn dành gần như toàn bộ thời gian cho Figma và tài liệu
- Nếu tôi gia nhập Jane Street trước thời kỳ LLM, có lẽ tôi sẽ bị cố định sâu hơn vào Figma; và không giống JavaScript, OCaml và Bonsai hoàn toàn mới với tôi, nên việc đóng góp về mặt kỹ thuật có thể đã giống như điều nằm ngoài tầm với
- Còn bây giờ, tôi lại đang tạo ra sản phẩm thực tế, làm việc ngay trong chất liệu đó, và cảm 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