critique

Tổng quan về skill critique

Skill critique làm gì

Skill critique là một quy trình review UX và thiết kế sản phẩm có cấu trúc, dùng để đánh giá một trang, tính năng hoặc component như một trải nghiệm người dùng thực tế, chứ không chỉ như một mockup đẹp mắt. Skill này buộc model phải xem xét hệ thống phân cấp thị giác, kiến trúc thông tin, sắc thái cảm xúc, tải nhận thức, các nguyên tắc usability và những điểm ma sát theo từng persona, rồi chuyển tất cả thành phản hồi có thể hành động được.

Ai nên cài critique

Skill critique này phù hợp nhất với product designer, frontend engineer, founder và AI builder đã có sẵn màn hình, prototype hoặc giao diện đã ship, và muốn một bản review sắc nét hơn kiểu prompt chung chung như “give feedback on this UI”. Nó đặc biệt hữu ích khi bạn cần critique cho công việc UX Audit, design QA trước khi ra mắt, hoặc muốn có góc nhìn thứ hai để xác định xem một giao diện có đang tạo cảm giác quá đại trà, khó hiểu hay nặng nề hay không.

Bài toán thực sự cần giải quyết

Phần lớn người dùng không chỉ cần ý kiến. Họ muốn biết:

• điều gì đang làm tổn hại trải nghiệm trước tiên
• liệu UI có tạo cảm giác na ná, rập khuôn hoặc “AI-generated” không
• vấn đề nào chỉ là bề mặt thẩm mỹ và vấn đề nào thật sự cản trở chuyển đổi
• nên ưu tiên sửa gì khi không có cả một team thiết kế đầy đủ

Skill này được xây quanh đúng bài toán đó. Nó định vị critique như một công cụ hỗ trợ ra quyết định, chứ không phải một bài bình luận phong cách.

Điều gì khiến critique khác biệt

Điểm khác biệt mạnh nhất là skill này rất coi trọng bối cảnh và có bước “AI slop detection”. Thay vì lao ngay vào nhận xét bề mặt, nó yêu cầu phải có design context trước, đồng thời kiểm tra rõ xem giao diện có đang lặp lại những pattern AI product phổ biến giai đoạn 2024–2025 hay không, như card grid quá đại trà, dark theme lạm dụng hiệu ứng glow, hierarchy yếu, hoặc bố cục nhìn như template.

Nó cũng không dừng ở một giọng review duy nhất mà kết hợp đồng thời:

• critique theo kiểu design director
• phân tích tải nhận thức
• chấm điểm heuristic
• kiểm thử theo persona

Lưu ý quan trọng trước khi áp dụng

critique không phải skill hoàn toàn độc lập. Repository quy định frontend-design là dependency bắt buộc để lấy nguyên tắc và thu thập context, đồng thời yêu cầu chạy teach-impeccable trước nếu chưa có sẵn design context. Nếu bạn muốn một cài đặt critique kiểu zero-setup, thì chuỗi dependency này là điều quan trọng nhất cần biết trước khi quyết định dùng.

Cách dùng skill critique

Cài đủ context trước khi phụ thuộc vào critique

Repository này đặt critique trong .claude/skills/critique, và phần mô tả skill cũng nói rõ là nó phụ thuộc vào /frontend-design. Trên thực tế, critique hoạt động tốt nhất khi bạn cài cả bộ skill impeccable, chứ không nên xem thư mục này như một file prompt độc lập.

Nếu trình chạy skill của bạn hỗ trợ cài skill từ GitHub, hãy cài trực tiếp từ repository rồi xác nhận rằng critique, frontend-design và teach-impeccable đều đang sẵn sàng.

Hãy đọc các file này trước

Để quyết định cài nhanh, hãy đọc:

• SKILL.md
• reference/cognitive-load.md
• reference/heuristics-scoring.md
• reference/personas.md

Chuỗi file này cho bạn gần như toàn bộ phần quan trọng: điều kiện tiên quyết, workflow review, mô hình chấm điểm và lăng kính dùng để kiểm thử người dùng.

Skill critique cần những đầu vào gì

Skill critique hoạt động tốt hơn hẳn khi bạn cung cấp:

• hiện vật giao diện: screenshot, mockup, URL hoặc mô tả component
• phạm vi đang review: page, flow, modal, dashboard, onboarding, settings, v.v.
• mục tiêu chính của người dùng
• bối cảnh sản phẩm và đối tượng người dùng
• ràng buộc: mobile/desktop, B2B/B2C, accessibility, conversion, giới hạn kỹ thuật

Nếu không có phần context này, model vẫn có thể nhận xét về bố cục và thẩm mỹ, nhưng sẽ không thể đánh giá liệu giao diện đó có thực sự phù hợp với tác vụ hay không.

Biến một yêu cầu sơ sài thành prompt critique mạnh hơn

Prompt yếu:

• “Critique this UI.”

Cách dùng critique tốt hơn:

• “Use the critique skill on this onboarding flow. The product helps finance teams close books faster. Primary goal: get a first report generated in under 5 minutes. Audience: mid-market accounting teams. Constraint: desktop web app, dense data is acceptable but first-time clarity matters. Please evaluate AI-slop signals, hierarchy, cognitive load, heuristic score, and test it as a first-timer and power user.”

Phiên bản mạnh hơn cho kết quả tốt hơn vì nó cho skill một mục tiêu để tối ưu, chứ không chỉ một thứ để phản ứng lại.

Làm đúng bước chuẩn bị mà repository yêu cầu

Skill này nói rất rõ: hãy chạy /frontend-design trước và làm theo quy trình thu thập context của nó. Nếu chưa có design context, hãy chạy /teach-impeccable trước khi dùng critique. Nghĩa là workflow được thiết kế sẵn sẽ là:

1. thu thập design context
2. hiểu giao diện đang cố hoàn thành điều gì
3. chạy critique dựa trên mục tiêu đó
4. trả về phản hồi đã được ưu tiên

Nếu bỏ qua bước 2, đầu ra thường sẽ trở nên chung chung vì model không thể phân biệt đâu là mật độ thông tin có chủ đích và đâu là thiết kế tệ.

Dùng critique cho công việc UX Audit

Với các use case critique cho UX Audit, đừng chỉ yêu cầu “feedback”. Hãy yêu cầu:

• các vấn đề nghiêm trọng nhất theo mức độ
• tóm tắt chấm điểm heuristic
• các điểm người dùng dễ rơi rụng nhất
• failure mode theo từng persona
• đề xuất redesign cụ thể

Cách này sẽ đẩy kết quả từ mức bình luận sang đầu ra kiểu audit mà stakeholder có thể dùng để ra quyết định.

Workflow này thực sự đang kiểm tra điều gì

Dựa trên repository, skill critique mạnh nhất khi dùng để soi:

• sự na ná thường thấy trong thiết kế do AI tạo
• lỗi phân cấp thị giác
• quá tải nhận thức
• kiến trúc thông tin yếu
• pattern tương tác không rõ ràng
• khoảng trống theo heuristic usability
• sự lệch tông giữa giao diện và nhu cầu người dùng

Vì vậy, critique phù hợp hơn để đánh giá UI đã ship hoặc UI đủ thực tế, hơn là brainstorm ý tưởng hoàn toàn mới từ đầu.

Workflow critique được khuyến nghị

Một workflow thực tế:

1. thu thập màn hình và mục tiêu
2. nêu rõ loại người dùng và tiêu chí thành công
3. gọi critique cho một khu vực cụ thể, không review toàn bộ sản phẩm cùng lúc
4. xem 3 vấn đề nghiêm trọng nhất trước
5. yêu cầu khuyến nghị đã chỉnh lại sau khi làm rõ ràng buộc
6. lặp lại với flow tiếp theo

Dùng skill critique theo từng trang hoặc từng flow thường cho tín hiệu tốt hơn là yêu cầu một bài review khổng lồ cho cả sản phẩm trong một lần.

Cách giới hạn phạm vi cho hợp lý

Phạm vi tốt:

• signup flow
• pricing page
• analytics dashboard
• settings panel
• empty state
• mobile checkout

Phạm vi kém:

• “the whole app”
• “our design system”
• “everything on the website”

Skill này đủ chi tiết để khi phạm vi quá lớn, đầu ra sẽ trở nên nông. Thu hẹp vùng review sẽ giúp tăng độ cụ thể và khả năng ưu tiên.

Mẹo thực tế để cải thiện chất lượng đầu ra của critique

Để dùng critique hiệu quả hơn, hãy thêm:

• một câu về mục tiêu kinh doanh
• một câu về mức độ cấp bách của người dùng
• một câu mô tả thành công trông như thế nào
• mọi ràng buộc bạn không muốn model “sửa cho biến mất”

Ví dụ:

• “This page exists to get a team admin to invite coworkers immediately after signup. Speed matters more than education. We cannot remove required compliance messaging.”

Kiểu đầu vào này giúp skill critique phân biệt được đâu là lỗi thật sự và đâu là độ phức tạp bắt buộc phải chấp nhận.

Câu hỏi thường gặp về skill critique

critique có tốt hơn một prompt UX thông thường không?

Thường là có, nếu bạn cần một phương pháp review có thể lặp lại. Giá trị của skill critique không nằm ở “gu thiết kế thần kỳ”, mà ở cấu trúc có sẵn: context bắt buộc, phát hiện anti-pattern, chấm điểm heuristic, khung phân tích tải nhận thức và kiểm thử theo persona. Một prompt thường vẫn có thể cho ra vài nhận xét ổn, nhưng sẽ thiếu ổn định hơn và dễ trôi sang kiểu khen chung chung.

critique có thân thiện với người mới không?

Nhìn chung là có, nhưng có một điểm cần lưu ý: dependency vào frontend-design và đôi khi là teach-impeccable. Người mới vẫn dùng critique được, nhưng nên chuẩn bị tinh thần dành vài phút để hiểu workflow mà repository hướng tới, thay vì chỉ thả một prompt duy nhất mà không cần setup gì.

Khi nào critique không phù hợp?

Hãy bỏ qua skill critique này khi:

• bạn cần generate code nhiều hơn là review thiết kế
• bạn mới chỉ có ý tưởng sản phẩm mơ hồ chứ chưa có giao diện
• bạn muốn làm brand strategy hoặc copywriting trước
• bạn không thể cung cấp bất kỳ context nào về người dùng hay sản phẩm

Nó vẫn có thể nhận xét phần hình ảnh đơn thuần, nhưng đó không phải điểm khác biệt lớn nhất của skill này.

critique có chỉ dùng được cho UI đã hoàn thiện không?

Không. Nó vẫn hữu ích với wireframe, mockup thô và component ở giai đoạn sớm, đặc biệt khi xét hierarchy và tải nhận thức. Tuy vậy, phần persona testing và heuristic scoring sẽ đáng tin hơn khi mô hình tương tác đã đủ rõ để đánh giá.

Tôi có thể dùng critique cho một component đơn lẻ không?

Có, miễn là component đó có một nhiệm vụ thực tế trong đúng bối cảnh sử dụng. Filter panel, modal, table hay form đều có thể hưởng lợi từ critique. Chỉ cần giải thích nó xuất hiện ở đâu, ai dùng và họ đang cố hoàn thành việc gì.

Tôi nên kỳ vọng đầu ra như thế nào?

Một đầu ra critique tốt nên cung cấp:

• các rủi ro UX chính
• mức độ nghiêm trọng hoặc thứ tự ưu tiên
• lý do cụ thể vì sao các vấn đề đó quan trọng
• ví dụ về những gì cần thay đổi
• sự phân biệt rõ giữa phần polish bề mặt và các vấn đề UX mang tính cấu trúc

Nếu kết quả chủ yếu chỉ là một loạt tính từ, rất có thể prompt của bạn đang thiếu context.

Cách cải thiện skill critique

Hãy cho critique một thước đo thành công, không chỉ đưa mỗi màn hình

Cách nhanh nhất để cải thiện đầu ra critique là nêu rõ kết quả người dùng cần đạt được. “Review this dashboard” yếu hơn nhiều so với “Review this dashboard for whether a new manager can spot blockers in under 30 seconds.” Thước đo thành công sẽ làm sắc nét mọi đánh giá về sau.

Cung cấp đối tượng người dùng và độ trưởng thành của sản phẩm

Cùng một giao diện có thể là lựa chọn đúng cho:

• chuyên viên nhiều kinh nghiệm trong một công cụ B2B dày đặc dữ liệu
• nhưng lại sai với người tiêu dùng dùng lần đầu
• chấp nhận được trong công cụ nội bộ
• và khá yếu với một sản phẩm cao cấp hướng ra khách hàng

Nếu bạn nêu rõ audience và mức độ trưởng thành của sản phẩm, skill critique sẽ đánh giá được trade-off thay vì mặc định theo lời khuyên UX đại trà.

Yêu cầu chọn persona một cách rõ ràng

Repository có sẵn nhiều persona, nhưng không phải lúc nào persona nào cũng hữu ích. Để cải thiện critique cho các tác vụ UX Audit, hãy nói rõ kiểu người dùng nào quan trọng nhất, chẳng hạn:

• first-timer
• power user
• cautious admin

Cách này giúp đầu ra không bị phân tán vào những failure mode không liên quan.

Buộc phải ưu tiên sau vòng đầu tiên

Một lỗi thường gặp là danh sách quan sát rất dài nhưng không giúp ra quyết định. Sau lượt critique đầu tiên, hãy hỏi:

• “Which 3 issues most threaten task completion?”
• “Which issue is most likely to reduce trust?”
• “What should be fixed before launch versus later?”

Như vậy, phần phân tích sẽ được chuyển thành kế hoạch hành động.

Cung cấp những ràng buộc mà model phải tôn trọng

Nếu giao diện bắt buộc phải giữ:

• data-dense
• enterprise-looking
• compliant
• on-brand
• mobile-first
• low-engineering-effort

hãy nói thẳng ra. Nếu không, critique có thể đề xuất các phương án redesign sạch sẽ hơn nhưng thiếu thực tế.

Cẩn thận với việc sửa quá tay vì “AI slop”

Một điểm mạnh của skill critique này là phát hiện các pattern đại trà do AI tạo. Nhưng người dùng cũng không nên phản ứng thái quá rồi loại bỏ mọi quy ước hiện đại chỉ để trông “khác biệt”. Câu hỏi đúng hơn là thiết kế đó có đủ khác biệt và phù hợp hay không, chứ không chỉ đơn giản là khác. Hãy dùng phần này để tìm ra sự na ná cẩu thả, rồi kiểm chứng hướng sửa lại bằng tiêu chí usability.

Cải thiện đầu vào bằng vòng lặp before-and-after

Best practice:

1. chạy critique trên thiết kế hiện tại
2. áp dụng hoặc mô phỏng 2–3 thay đổi lớn
3. chạy critique lại trên phiên bản đã chỉnh
4. so sánh xem các rủi ro chính có thực sự giảm hay không

Skill này hữu ích hơn nhiều khi được dùng như một vòng lặp thiết kế lặp lại, thay vì một phán quyết dùng một lần rồi thôi.

Những lý do phổ biến khiến đầu ra critique bị yếu

Thông thường là đang thiếu một trong các yếu tố sau:

• không có mục tiêu người dùng
• không có context sản phẩm
• phạm vi quá rộng
• không có ràng buộc
• hiện vật giao diện không đủ chất lượng để soi
• hỏi kiểu “thoughts” thay vì yêu cầu một cấu trúc review rõ ràng

Khi các điểm này được bổ sung, hướng dẫn critique sẽ trở nên thực dụng và có khả năng hành động hơn nhiều.

Mẫu prompt mạnh để dùng critique hiệu quả hơn

Hãy dùng prompt kiểu này:

• “Use the critique skill on [area].
• Product: [what the product does]
• Audience: [who this is for]
• Primary task: [what the user needs to do]
• Success metric: [what success looks like]
• Constraints: [platform, compliance, technical, brand]
• Review for: AI-slop signals, hierarchy, cognitive load, heuristics, and 2 relevant personas.
• Output: top issues, severity, why they matter, and concrete fixes.”

Mẫu này bám rất sát cách repository muốn critique vận hành, và thường cho tín hiệu tốt hơn nhiều so với một yêu cầu mở hoàn toàn.