Trong chuỗi Vỡ lòng, Py có nhắc tới bolt.new như một “túi mù” – chủ yếu vì lúc đó Py vẫn chưa thật sự quen tay với công cụ này. Còn gần đây, khi thử dùng Claude AI để phác thảo wireframe cho một sản phẩm mới, Py lại thấy “hợp” hơn hẳn – thao tác dễ chịu, phản hồi nhanh, và quan trọng là… hiểu ý.

Làm việc cùng Claude

Khi cộng tác với Claude, Py thường hình dung đây như một bạn web designer trong team. Có khi Claude còn “dữ liệu đầy người” hơn bạn designer thật, vì có thể liên kết ngay đến hàng loạt kiến thức thiết kế và UX/UI của các sản phẩm công nghệ khác. Điều quan trọng là mình – với tư cách PO – cần nói cho rõ ràng.

Để Claude hiểu và thực hiện tốt, Py thường mô tả theo:

• User Story
• Acceptance Criteria
• Ref: Một bản wireframe sơ bộ hoặc ảnh chụp màn hình từ những sản phẩm có tính năng tương tự

Tuy nhiên, không phải lúc nào Py cũng viết bài bản vậy. Có khi chỉ đơn giản là gõ thẳng những gì mình cần, cụ thể tới mức không còn gì để hiểu lầm, rồi từ đó iterate qua vài lượt để tinh chỉnh. Thậm chí, có lúc Py còn dùng Gemini hoặc GPT khác viết, rồi copy qua Claude chạy tiếp.

Ví dụ dưới đây là đoạn prompt Py dùng để tạo trang chủ cho Xsy-peasy:

Build the homepage of a creative workshop booking platform called “Xsy Peasy”. The target users are young urban professionals looking for relaxing and hands-on activities after work, such as pottery, painting, or flower arrangement.

The homepage should include:
- A clear and inviting hero section with a short tagline and a call-to-action button (e.g., “Explore workshops”)
- A search bar for finding workshops by keyword or category
- Featured categories (e.g., Pottery, Painting, Flower Art) with simple icons or images
- A section for upcoming workshops with title, date, and location
- User testimonials or reviews
- A footer with navigation links and contact info

Keep the layout clean and mobile-friendly. Focus on ease of navigation and emotional appeal.

Bạn có thể tham khảo kết quả ở đây.

Một bài học nhỏ Py rút ra sau khi prompt nhiều lượt với Claude là nên ghi rõ: phần nào giữ nguyên, phần nào có thể thay đổi, ví dụ như trong đoạn chat re-design trang chủ Anpylogue. Cách này giúp tiết kiệm thời gian và tránh sửa tới lui vì “lỡ đổi chỗ không cần thiết”. Ngoài ra, như bạn sẽ thấy kết quả từ Claude có vẻ “đầy đủ” hơn prompt của Py, đây cũng là short-cut để tiết kiệm thời gian define use cases với những user flow đã quá phổ biến. 

Với cách prompt trên, Claude sẽ “code” ra một trang web hoàn chỉnh, tuy nhiên, để điều chỉnh lại những chi tiết hoặc add thêm các yếu tố “bảo mật” thì chắc chắn không thể tiếp tục dùng prompt. Cách của Py là dùng tiếp plugin html.to.design để chuyển “web” này thành figma, việc còn lại là điều chỉnh theo ý muốn. Phần này có thể sẽ cần đòi hỏi một chút kiến thức về design trên figma, theo trải nghiệm của Py thì chỉ cần vọc qua để biết chỉnh như thế nào cho nhanh chứ cũng không cần quá đi sâu.

Dù là công cụ nào thì ban đầu cũng sẽ cần một chút thời gian làm quen. Việc đó phần nào phụ thuộc vào tốc độ học và độ kiên nhẫn của mỗi người. Py thường sẽ tự đặt một khung thời gian thử nghiệm – nếu sau chừng đó mà vẫn loay hoay chưa ra kết quả thì sẽ quay lại cách làm cũ để đảm bảo tiến độ. Không có công cụ nào là “thần thánh”, nhưng khi biết cách dùng đúng lúc, đúng chỗ thì chúng thực sự giúp mình nhẹ gánh hơn một chút.

Nâng chuẩn PO

Dù không đo lường cụ thể nhưng bản thân Py cũng cảm nhận việc ứng dụng các tool AI khi làm sản phẩm thực sự giúp Py tiết kiệm nhiều thời gian hơn ở đoạn delivery. Từ đó, chất lượng yêu cầu của wireframe/docs cũng không thể chỉ dừng lại ở số lượng hạn chế use cases như trước. Hoặc ít nhất, nhờ những cải tiến này PO sẽ có nhiều time quay về với phần discovery:

• Tính năng này giải quyết vấn đề gì?
• Nếu bỏ tính năng X, liệu có ảnh hưởng đến user flow không?
• Có cách nào làm trải nghiệm này vui hơn, dễ nhớ hơn?
• …

Nói chung, PO cần tự nâng tiêu chuẩn của mình để “do more, with less”.

Sau cùng, điều Py thấy rõ nhất khi thử nghiệm với Claude – hay bất kỳ công cụ AI nào – không phải là “làm được gì mới”, mà là “giữ được gì cũ”. Giữ lại sự tỉnh táo để biết mình đang giải bài toán gì. Giữ được sự tò mò khi làm việc với một feature quen mà vẫn muốn soi lại từ góc nhìn khác. Giữ được sự chủ động trong cách làm, ngay cả khi có thêm công cụ hỗ trợ. Vì công cụ có thể thay đổi, công nghệ sẽ còn phát triển nữa. Nhưng vai trò của người làm sản phẩm – người đặt câu hỏi, nhìn vấn đề, định hướng giải pháp– thì vẫn vậy. 

---

Cám ơn bạn đã nán lại cho đến những dòng cuối cùng này. 

Chúc bạn cũng sẽ tìm được một cách làm “thuận tay” – không chỉ với AI, mà với chính mình.

Anpy

P/s: Việc quan trọng cần nhắc lại, PO chỉ cần vẽ wireframe, không phải Mock-up, nên hãy giữ wireframe đơn giản nhất có thể. Vì tôn trọng SoW và chuyên môn của nhau cũng là cách gián tiếp gia tăng hiệu quả làm việc nhóm.