critique

critique 스킬 개요

critique 스킬이 하는 일

critique 스킬은 페이지, 기능, 컴포넌트를 단순한 비주얼 목업이 아니라 실제 사용자 경험으로 평가하는 구조화된 UX 및 프로덕트 디자인 리뷰 워크플로입니다. 이 스킬은 모델이 시각적 위계, 정보 구조, 감성 톤, 인지 부하, 사용성 휴리스틱, 페르소나별 마찰 지점을 점검한 뒤, 이를 실행 가능한 피드백으로 바꾸도록 유도합니다.

critique를 설치하면 좋은 사람

이 critique 스킬은 이미 화면, 프로토타입, 혹은 실제 배포된 인터페이스가 있고, “이 UI 피드백 좀 줘” 같은 범용 프롬프트보다 더 날카로운 리뷰가 필요한 프로덕트 디자이너, 프론트엔드 엔지니어, 창업자, AI 빌더에게 특히 잘 맞습니다. 특히 UX Audit 용도의 critique가 필요하거나, 출시 전 디자인 QA를 하고 싶거나, 인터페이스가 너무 뻔한지, 헷갈리는지, 답답하게 느껴지는지에 대해 한 번 더 검토받고 싶을 때 유용합니다.

실제로 해결하려는 핵심 과제

대부분의 사용자는 단순한 의견이 아니라 다음을 알고 싶어 합니다:

• 무엇이 사용자 경험을 가장 먼저 망치고 있는지
• UI가 식상하거나 “AI가 만든 느낌”이 나는지
• 어떤 문제가 단순 미관 수준인지, 어떤 문제가 전환을 막는지
• 전담 디자인 팀 없이도 무엇부터 고쳐야 하는지

이 스킬은 바로 그 과제에 맞춰 설계되어 있습니다. critique를 스타일 코멘트가 아니라 의사결정 도구로 다룹니다.

이 critique가 다른 점

가장 큰 차별점은 맥락을 반드시 요구한다는 점과 “AI slop detection” 단계가 들어 있다는 점입니다. 겉핥기식 피드백으로 바로 들어가지 않고 먼저 디자인 맥락을 요구하며, 2024–2025년형 AI 제품에서 흔히 보이는 패턴—예를 들어 뻔한 카드 그리드, 과한 글로우의 다크 테마, 약한 위계, 템플릿처럼 보이는 구성—이 있는지 명시적으로 확인합니다.

또한 단일 리뷰어 시점에 그치지 않고 다음을 결합합니다:

• design-director 스타일 critique
• cognitive load 분석
• heuristic scoring
• persona 기반 테스트

도입 전에 꼭 알아둘 점

critique는 완전한 단독형 스킬이 아닙니다. 저장소에서는 원칙과 맥락 수집을 위해 frontend-design을 필수 의존성으로 두고 있으며, 디자인 맥락이 아직 없다면 먼저 teach-impeccable을 실행하라고 안내합니다. 별도 준비 없이 바로 쓰는 critique 설치를 기대했다면, 도입 전에 가장 먼저 알아야 할 부분이 바로 이 의존성 체인입니다.

critique 스킬 사용 방법

critique에 의존하기 전에 먼저 맥락을 설치하세요

이 저장소에서는 critique를 .claude/skills/critique 아래에 두고, 스킬 문서에서도 /frontend-design에 명시적으로 의존합니다. 실제로는 이 폴더만 떼어내 독립 프롬프트 파일처럼 쓰기보다, 더 넓은 impeccable 스킬 세트를 함께 설치했을 때 critique 사용성이 가장 좋습니다.

스킬 러너가 GitHub 기반 스킬 설치를 지원한다면 저장소에서 설치한 뒤, critique, frontend-design, teach-impeccable이 모두 사용 가능한지 확인하세요.

먼저 읽어볼 파일

빠르게 설치 여부를 판단하려면 다음 파일부터 보세요:

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

이 경로만 읽어도 핵심은 거의 파악됩니다. 선행 조건, 리뷰 워크플로, 점수 모델, 사용자 테스트에 쓰는 관점까지 확인할 수 있습니다.

critique 스킬에 필요한 입력

critique 스킬은 다음 정보를 함께 줄 때 훨씬 더 잘 작동합니다:

• 검토할 인터페이스 산출물: 스크린샷, 목업, URL, 또는 컴포넌트 설명
• 리뷰 범위: 페이지, 플로우, 모달, 대시보드, 온보딩, 설정 등
• 사용자의 핵심 목표
• 제품 맥락과 대상 사용자
• 제약 조건: mobile/desktop, B2B/B2C, accessibility, conversion, 기술적 한계

이 맥락이 없으면 모델이 레이아웃이나 미감에 대해서는 코멘트할 수 있어도, 그 인터페이스가 실제 과업에 적합한지는 제대로 판단하기 어렵습니다.

두루뭉술한 요청을 강한 critique 프롬프트로 바꾸기

약한 프롬프트:

• “Critique this UI.”

더 나은 critique 사용 예시:

• “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.”

이처럼 더 강한 요청이 잘 먹히는 이유는, 단순히 반응할 대상을 주는 것이 아니라 무엇을 기준으로 최적화해야 하는지까지 알려주기 때문입니다.

저장소가 요구하는 준비 단계를 따르세요

이 스킬은 분명하게 말합니다. 먼저 /frontend-design을 실행하고, 그 컨텍스트 수집 프로토콜을 따르라고 되어 있습니다. 아직 디자인 맥락이 없다면 critique 전에 /teach-impeccable을 실행해야 합니다. 즉, 의도된 워크플로는 다음과 같습니다:

1. 디자인 맥락 수집
2. 인터페이스가 무엇을 달성하려는지 이해
3. 그 목표를 기준으로 critique 실행
4. 우선순위가 있는 피드백 반환

2단계를 건너뛰면, 모델이 의도된 정보 밀도와 단순한 나쁜 디자인을 구분하지 못해서 결과가 흔한 총평 수준으로 흐르기 쉽습니다.

UX Audit 작업에 critique 활용하기

UX Audit 용도로 critique를 쓸 때는 단순히 “피드백”만 요청하지 마세요. 대신 다음을 요청하세요:

• 심각도 기준 상위 이슈
• heuristic scoring 요약
• 사용자가 이탈할 가능성이 큰 지점
• 페르소나별 실패 패턴
• 구체적인 리디자인 제안

이렇게 해야 결과가 감상평이 아니라, 이해관계자가 실제로 움직일 수 있는 audit 수준의 산출물에 가까워집니다.

이 워크플로가 실제로 점검하는 것

저장소 기준으로 보면 critique 스킬이 특히 강한 지점은 다음을 점검할 때입니다:

• AI가 만든 듯한 디자인의 획일성
• 시각적 위계 문제
• 인지 과부하
• 약한 정보 구조
• 불분명한 인터랙션 패턴
• 사용성 휴리스틱의 빈틈
• 인터페이스 톤과 사용자 니즈의 불일치

따라서 완전히 새로운 아이디어를 브레인스토밍하는 용도보다는, 이미 출시됐거나 현실성 있는 UI를 평가하는 데 더 잘 맞습니다.

추천하는 critique 사용 워크플로

실무적으로는 다음 흐름이 좋습니다:

1. 화면과 목표를 수집한다
2. 사용자 유형과 성공 기준을 명시한다
3. 제품 전체가 아니라 특정 영역에 critique를 건다
4. 가장 심각한 상위 3개 이슈부터 검토한다
5. 제약 조건을 명확히 한 뒤 수정 제안을 다시 받는다
6. 다음 플로우로 반복한다

critique 스킬은 제품 전체를 한 번에 훑는 거대한 리뷰보다, 페이지 단위 혹은 플로우 단위로 나눠서 쓸 때 대체로 더 신호가 좋습니다.

요청 범위를 잘 잡는 법

좋은 범위:

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

좋지 않은 범위:

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

이 스킬은 충분히 디테일해서, 범위가 지나치게 넓으면 결과가 얕아집니다. 리뷰 대상을 좁히면 구체성과 우선순위 판단이 좋아집니다.

결과 품질을 높이는 실전 팁

더 나은 critique 사용을 원한다면 다음을 포함하세요:

• 비즈니스 목표 한 문장
• 사용자 긴급도 한 문장
• 성공의 정의 한 문장
• 모델이 멋대로 “없애버리면 안 되는” 제약 조건

예:

• “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.”

이런 입력이 있어야 스킬이 실제 결함과 불가피한 복잡성을 구분할 수 있습니다.

critique 스킬 FAQ

critique는 일반 UX 프롬프트보다 나은가요?

대체로 그렇습니다. 특히 반복 가능한 리뷰 방식이 필요할 때 그렇습니다. critique 스킬의 가치는 “디자인 감각이 마법처럼 좋다”는 데 있지 않습니다. 핵심은 내장된 구조에 있습니다. 선행 맥락, 안티패턴 탐지, heuristic scoring, cognitive load 관점, persona 테스트가 이미 포함되어 있습니다. 일반 프롬프트도 괜찮은 의견을 줄 수는 있지만, 일관성이 떨어지고 뻔한 칭찬 쪽으로 쉽게 흘러갑니다.

critique는 초보자도 쓰기 쉬운가요?

대체로는 그렇지만 한 가지 걸림돌이 있습니다. frontend-design, 경우에 따라 teach-impeccable까지 의존한다는 점입니다. 초보자도 critique를 쓸 수는 있지만, 아무 준비 없이 프롬프트 하나만 넣는 방식이 아니라 의도된 워크플로를 몇 분 정도 이해해야 한다고 보는 편이 맞습니다.

critique가 잘 맞지 않는 경우는 언제인가요?

다음 상황이라면 이 critique 스킬은 건너뛰는 편이 낫습니다:

• 디자인 리뷰보다 코드 생성이 더 필요할 때
• 인터페이스 없이 제품 아이디어만 아주 모호하게 있을 때
• 브랜드 전략이나 카피라이팅이 먼저일 때
• 사용자나 제품 맥락을 전혀 제공할 수 없을 때

비주얼만 보고 코멘트는 가능하지만, 그건 이 스킬의 차별점이 가장 잘 드러나는 쓰임새는 아닙니다.

critique는 완성도 높은 UI에만 쓸 수 있나요?

아니요. 와이어프레임, 러프 목업, 초기 컴포넌트에도 유용할 수 있습니다. 특히 위계와 인지 부하를 보는 데 그렇습니다. 다만 persona 테스트와 heuristic scoring은 인터랙션 모델이 어느 정도 드러나 있을수록 신뢰도가 높아집니다.

critique를 단일 컴포넌트에도 쓸 수 있나요?

네, 그 컴포넌트가 맥락 안에서 실제 역할을 갖고 있다면 가능합니다. 필터 패널, 모달, 테이블, 폼 모두 critique 사용 대상이 될 수 있습니다. 단, 어디에 나타나는지, 누가 쓰는지, 사용자가 무엇을 완료하려는지 설명해야 합니다.

어떤 출력 결과를 기대하면 되나요?

좋은 critique 결과라면 다음이 나와야 합니다:

• 주요 UX 리스크
• 심각도 또는 우선순위
• 왜 그 이슈가 중요한지에 대한 구체적 이유
• 무엇을 바꿔야 하는지에 대한 예시
• 겉보기 다듬기와 구조적 UX 문제를 분명히 구분한 설명

결과가 형용사 위주라면, 대개 프롬프트에 맥락이 부족했던 것입니다.

critique 스킬을 더 잘 활용하는 방법

화면만 주지 말고 성공 지표를 함께 주세요

critique 결과를 가장 빠르게 개선하는 방법은 사용자가 도달해야 할 결과를 명시하는 것입니다. “Review this dashboard”보다 “Review this dashboard for whether a new manager can spot blockers in under 30 seconds”가 훨씬 낫습니다. 성공 지표가 있으면 이후의 모든 판단이 더 날카로워집니다.

대상 사용자와 제품 성숙도를 알려주세요

같은 인터페이스라도 다음 상황에서는 적절할 수 있고:

• 밀도 높은 B2B 툴을 다루는 숙련 사용자
• 처음 쓰는 일반 소비자에게는 부적절할 수 있고
• 내부용 툴에서는 용인될 수 있으며
• 프리미엄 고객 대상 제품에서는 약하게 보일 수 있습니다

대상 사용자와 제품 성숙도를 알려주면, critique 스킬이 무조건적인 대중 UX 조언으로 흐르지 않고 실제 트레이드오프를 판단할 수 있습니다.

어떤 페르소나로 볼지 명시적으로 요청하세요

저장소에는 여러 페르소나가 포함되어 있지만, 매번 모든 페르소나가 유효한 것은 아닙니다. UX Audit 작업에서 critique를 더 잘 쓰고 싶다면 다음처럼 어떤 사용자 유형이 중요한지 지정하세요:

• first-timer
• power user
• cautious admin

이렇게 해야 출력이 중요하지 않은 실패 패턴까지 넓게 퍼지지 않습니다.

첫 번째 리뷰 뒤에는 반드시 우선순위를 강제하세요

흔한 실패 패턴은 관찰 목록만 길고, 정작 의사결정에 도움이 안 되는 경우입니다. 첫 critique 뒤에는 이렇게 물어보세요:

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

이 질문이 분석을 실행 계획으로 바꿔줍니다.

모델이 지켜야 할 제약을 분명히 주세요

인터페이스가 반드시 다음 상태를 유지해야 한다면:

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

직접 명시하세요. 그렇지 않으면 critique가 더 깔끔하지만 현실성 없는 리디자인을 제안할 수 있습니다.

일반적인 “AI slop”을 과하게 교정하지 않도록 주의하세요

이 critique 스킬의 강점 중 하나는 AI가 만든 듯한 진부한 패턴을 잡아내는 것입니다. 하지만 그렇다고 해서 “독특해 보여야 한다”는 이유만으로 최신 UI 관례를 모조리 제거하는 식으로 반응해서는 안 됩니다. 더 좋은 질문은 단순히 남들과 다른가가 아니라, 디자인이 구별 가능하면서도 맥락에 맞는가입니다. 이 섹션은 게으른 획일성을 찾아내는 데 쓰고, 수정안은 반드시 사용성 기준으로 다시 검증하세요.

전후 비교 반복으로 입력 품질을 끌어올리세요

권장 방식:

1. 현재 디자인에 critique를 실행한다
2. 큰 수정 2–3개를 적용하거나 시뮬레이션한다
3. 수정본에 다시 critique를 실행한다
4. 핵심 리스크가 실제로 줄었는지 비교한다

이 스킬은 한 번의 판정 도구로 쓸 때보다, 반복적인 디자인 루프로 쓸 때 훨씬 더 유용해집니다.

critique 결과가 약하게 느껴지는 흔한 이유

대개 다음 중 하나가 빠져 있습니다:

• 사용자 목표 없음
• 제품 맥락 없음
• 범위가 너무 큼
• 제약 조건 없음
• 검토할 만큼 충분한 품질의 산출물 없음
• 구조화된 리뷰 대신 막연한 “생각”만 요청함

이 부분을 보완하면 critique 가이드는 훨씬 더 실행 가능한 결과를 내줍니다.

더 나은 critique 사용을 위한 강력한 프롬프트 템플릿

다음 같은 프롬프트를 써보세요:

• “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.”

이 템플릿은 저장소가 critique를 작동시키려는 방식과 매우 가깝고, 대체로 열린 요청보다 더 신호가 좋은 결과를 냅니다.