Cách viết prompt cho Claude: 6 mẫu cho dân thiết kế

Viết prompt cho Claude giống viết brief cho một đồng nghiệp giỏi nhưng mới vào. Hãy nói rõ bối cảnh, việc cần làm, đưa đủ tài liệu và mô tả kết quả bạn muốn nhận: bảng, danh sách hay đoạn văn, dài bao nhiêu, cho ai đọc. Bên dưới là cách làm từng phần và sáu mẫu chép được cho designer.

Tôi là Hai Le, UI/UX designer biết code. Site này được dựng cùng Claude Code, và repo của nó có cả một thư mục kế hoạch viết qua lại với Claude. Các nguyên tắc trong bài lấy từ tài liệu prompt của Anthropic, kiểm ngày 2026-10-04. Sáu mẫu là khung tôi viết cho những việc tôi làm thật trong nghề. Kết quả sẽ khác theo tài liệu bạn đưa vào, nên hãy coi chúng là điểm xuất phát rồi chỉnh tiếp. Nếu bạn chưa từng mở Claude, đọc Claude là gì trước.

Một prompt tốt gồm những phần nào?

Tài liệu của Anthropic nhấn ba điều mà tôi thấy đúng với việc thiết kế:

• Nói lý do. Giải thích vì sao một yêu cầu quan trọng giúp Claude hiểu mục tiêu và trả lời sát hơn. "Viết ngắn" kém hơn "viết ngắn vì câu này nằm trên nút bấm 120px".
• Nói điều cần làm thay vì điều cấm. Thay "đừng dùng gạch đầu dòng" bằng "viết thành đoạn văn liền mạch".
• Tách tài liệu khỏi chỉ dẫn. Bọc nội dung trong thẻ như <transcript> hoặc <brief>. Với tài liệu dài, đặt tài liệu lên đầu, câu hỏi xuống cuối.

Trước khi gửi, tôi dùng phép thử Anthropic đề xuất: đưa prompt cho một đồng nghiệp không biết bối cảnh. Nếu họ phải hỏi lại, Claude cũng sẽ đoán.

Mẫu 1: tóm tắt phỏng vấn người dùng thế nào?

Tôi là product designer. Tôi vừa phỏng vấn người dùng cho [sản phẩm] để hiểu [mục tiêu nghiên cứu]. Bản tóm tắt sẽ dùng trong buổi họp với PM và dev, nên mỗi nhận định phải truy được về lời người dùng.

Ghi chú phỏng vấn nằm trong thẻ <transcript>. Tên người tham gia đã được đổi thành P1, P2...

<transcript>
[dán ghi chú]
</transcript>

Làm theo thứ tự:
1. Trích nguyên văn những câu liên quan đến [mục tiêu nghiên cứu], ghi rõ của ai.
2. Gom các trích dẫn thành nhóm vấn đề. Mỗi nhóm ghi số người nhắc đến.
3. Trả về bảng: Vấn đề | Số người | Trích dẫn tiêu biểu | Câu hỏi còn bỏ ngỏ.
Nếu một nhóm chỉ có một người nhắc, vẫn giữ nhưng đánh dấu "tín hiệu yếu".

Vì sao hiệu quả: bước 1 là kỹ thuật "trích trước, làm sau" trong tài liệu của Anthropic. Trích dẫn cho bạn căn cứ để dò lại, và bạn thấy ngay nếu một nhận định không có lời nào đỡ. Cột "số người" ngăn một câu nói to của một người trở thành "người dùng muốn". Khi kiểm thử prototype Hỏi đáp ở Oreka, chúng tôi chỉ có năm người mua và năm người bán. Với mẫu nhỏ như vậy, tôi dùng kết quả để tìm chỗ vướng thay vì kết luận chung, và nhãn "tín hiệu yếu" trong mẫu này giữ đúng tinh thần đó.

Mẫu 2: viết microcopy cho trạng thái lỗi ra sao?

Tôi cần microcopy cho trạng thái lỗi trong luồng [tên luồng] của app [sản phẩm]. Người dùng đang ở bước [bước], vừa gặp lỗi: [mô tả lỗi kỹ thuật].

Ràng buộc:
- Tiêu đề tối đa [số] ký tự, vì khung hiển thị chỉ chứa một dòng trên màn 360px.
- Nội dung nói điều gì đã xảy ra và người dùng làm gì tiếp.
- Nút chính là một động từ.
- Giọng: [mô tả giọng, ví dụ: bình tĩnh, xưng "bạn"].

Đưa 3 phương án khác nhau về cách diễn đạt. Mỗi phương án ghi số ký tự của tiêu đề và một câu giải thích nó hợp với tình huống nào.

Vì sao hiệu quả: mỗi ràng buộc đi kèm lý do (khung một dòng, màn 360px), nên Claude biết vì sao phải ngắn. Ba phương án khác nhau cho bạn thứ để chọn. Yêu cầu tự đếm ký tự giúp bạn lọc nhanh, nhưng hãy đếm lại vì con số đó vẫn có thể lệch. Trong case thanh toán QR của Oreka có hẳn một mục về trạng thái khi giao dịch không khớp. Đó là loại màn hình mà mẫu này dành cho.

Mẫu 3: nhờ Claude rà soát heuristic một màn hình thế nào?

Đính kèm là ảnh chụp màn hình [tên màn hình] của [sản phẩm]. Người dùng chính là [mô tả], mục tiêu của họ trên màn này là [mục tiêu].

Rà soát màn hình theo 10 heuristic của Nielsen. Với mỗi vấn đề:
- Mô tả đúng vị trí trên ảnh (khu vực, nhãn chữ).
- Ghi heuristic bị vi phạm.
- Mức độ: 1 (thẩm mỹ) đến 4 (chặn tác vụ), kèm lý do chấm.
- Một hướng sửa.

Trả về bảng, sắp theo mức độ giảm dần. Chỉ ghi vấn đề nhìn thấy được trên ảnh. Với điều cần dữ liệu hoặc cần thử trên máy thật mới biết, gom vào mục riêng "Cần kiểm thêm".

Vì sao hiệu quả: khung heuristic có sẵn tên, nên kết quả dễ so với review của bạn. Bắt mô tả vị trí giúp bạn kiểm từng dòng trên ảnh. Mục "Cần kiểm thêm" tách điều Claude thấy khỏi điều nó đoán. Ở Car From Japan, tôi chọn heuristic review vì không đủ thời gian nghiên cứu bài bản, và review đó tìm ra năm vấn đề của form cũ. Tôi tự làm review đó. Nếu làm lại hôm nay, tôi vẫn tự review trước, rồi dùng mẫu này như một người review thứ hai để đối chiếu.

Mẫu 4: đổi brief thành checklist bàn giao ra sao?

<brief>
[dán brief của PM hoặc khách hàng]
</brief>

Tôi là designer nhận brief trên. Hãy chuyển nó thành checklist tôi dùng để tự kiểm trước khi bàn giao thiết kế cho dev.

1. Liệt kê mọi yêu cầu trong brief, mỗi yêu cầu một dòng, kèm câu gốc trong ngoặc kép.
2. Với mỗi yêu cầu, viết tiêu chí kiểm được: nhìn vào file thiết kế là trả lời được có/không.
3. Liệt kê riêng những điểm brief chưa nói: trạng thái rỗng, lỗi, đang tải, quyền truy cập, màn nhỏ. Viết thành câu hỏi để tôi gửi lại PM.

Vì sao hiệu quả: brief nằm trên đầu, chỉ dẫn ở dưới, đúng thứ tự Anthropic khuyên cho tài liệu dài. Câu gốc trong ngoặc kép cho bạn thấy dòng nào Claude tự thêm. Bước 3 là phần tôi thấy đáng giá nhất: những trạng thái brief bỏ quên thường chỉ lộ ra khi dev hỏi.

Mẫu 5: đặt tên token màu thế nào cho nhất quán?

Tôi đang dựng design system với ba lớp token màu:
- Lớp 0 (raw): chỉ giữ giá trị, ví dụ --gray-600.
- Lớp 1 (alias): thang có vai trò, ví dụ neutral-700, primary-700.
- Lớp 2 (semantic): theo công dụng, ví dụ background, foreground, muted-foreground, border.
Component chỉ được dùng lớp 2.

Đây là danh sách màu đang dùng trong file Figma, kèm nơi dùng:
[dán danh sách: mã màu, chỗ dùng]

Đề xuất tên cho cả ba lớp. Trả về bảng: Mã màu | Lớp 0 | Lớp 1 | Lớp 2 | Lý do.
Nếu hai màu chỉ lệch rất ít và dùng cho cùng việc, đề xuất gộp và nói rõ.
Nếu một màu không gán được vai trò rõ ràng, ghi "cần quyết định" thay vì tự đặt tên.

Vì sao hiệu quả: mẫu đưa luôn quy ước đặt tên kèm ví dụ thật, nên Claude không phải tự chế một kiểu mới. Đây đúng là cấu trúc ba lớp tôi dùng cho site này, mô tả trong AGENTS.md. Dòng cuối cho Claude một lối ra hợp lệ khi thiếu thông tin. Muốn đi xa hơn, hãy viết quy ước này vào một file, như tôi kể trong bài DESIGN.md là gì, hoặc lấy thẳng biến từ Figma qua Figma MCP và Claude Code.

Mẫu 6: viết release note từ danh sách thay đổi ra sao?

Viết release note cho bản [số phiên bản] của [sản phẩm]. Người đọc là [người dùng cuối / đội CS / khách hàng doanh nghiệp], họ cần biết điều gì đổi với họ và có phải làm gì không.

Danh sách thay đổi từ đội dev:
<changes>
[dán danh sách ticket hoặc commit]
</changes>

Ví dụ một mục theo đúng giọng tôi muốn:
<example>
Bộ lọc tìm kiếm: giờ bạn lưu được bộ lọc hay dùng và mở lại bằng một lần chạm. Không cần làm gì thêm.
</example>

Quy tắc:
- Nhóm theo: Mới, Cải thiện, Đã sửa.
- Bỏ các thay đổi nội bộ không ảnh hưởng người dùng, và liệt kê chúng riêng ở cuối để tôi kiểm.
- Mỗi mục một câu, bắt đầu bằng tên tính năng.

Vì sao hiệu quả: một ví dụ cụ thể định hình giọng văn tốt hơn mọi tính từ. Anthropic gọi đây là đưa ví dụ, và khuyên dùng 3–5 ví dụ khi cần độ ổn định cao. Danh sách "đã bỏ" ở cuối cho bạn kiểm xem Claude có loại nhầm thay đổi quan trọng không.

Khi kết quả chưa đúng thì sửa prompt thế nào?

1. Đừng viết lại từ đầu. Nói cụ thể chỗ sai: "mục 3 gộp hai vấn đề khác nhau, tách ra".
2. Hỏi Claude cần gì. "Để làm tốt hơn, bạn còn thiếu thông tin nào?" thường chỉ ra đúng bối cảnh bạn quên đưa.
3. Sửa mẫu gốc. Khi một chỉnh sửa lặp lại ở nhiều lần dùng, đưa nó vào mẫu hoặc vào chỉ dẫn của Project.

Bài học tôi nhớ nhất đến từ site này. Menu trên điện thoại từng mở một danh sách chọn ngôn ngữ chồng lên chính nó. Claude dựng đúng điều tôi mô tả, và mô tả đó sai. Prompt là một bản brief. Kết quả sai thường bắt đầu từ brief.

Nên đọc gì tiếp?

• Claude là gì? Hướng dẫn cho người chưa dùng AI: gói, tính năng, quyền riêng tư.
• Claude Code cho designer: khi prompt dẫn tới code thật.
• Cài Claude Code và chạy lệnh đầu tiên.

Tôi viết về cách mình làm việc ở trang giới thiệu.

Nguồn

Kiểm ngày 2026-10-04.

• Claude Docs: Prompting best practices: nhân viên mới và phép thử đồng nghiệp, nói lý do, ví dụ (3–5), thẻ XML, đặt tài liệu dài lên đầu, trích dẫn trước khi làm, nói điều cần làm thay vì điều cấm.
• Claude Docs: Prompt engineering overview.
• Claude Blog: Best practices for prompt engineering.
• Claude Help Center: What are projects?: chỉ dẫn và kho tài liệu của Project.
• Nielsen Norman Group: 10 Usability Heuristics for User Interface Design.