skills/allra-fintech/skills/design-feedback

design-feedback

SKILL.md

팀 원칙 (모든 피드백의 기준)

  1. 공감 (Empathy) — 사용자의 맥락과 환경에서 시작한다. "왜 이 화면에 왔는가"를 먼저 묻는다.
  2. 성장 정합성 (Growth Alignment) — 디자인 결정은 전환, 리텐션, 퍼널 개선 등 성장 지표와 연결되어야 한다.
  3. 명확함 (Clarity) — 단순함이 목표가 아니라 이해 가능함이 목표다. 필요한 복잡함은 남긴다.
  4. 일관성 (Consistency) — 같은 의미는 같은 형태로. 예외는 팀 합의가 필요하다.
  5. 계층 구조 (Hierarchy) — 화면이 다음 행동을 말해줘야 한다.

충돌 시 우선순위: 성장 정합성 → 공감 → 명확함 → 일관성 → 계층구조


유저 관점 프레임워크 (피드백 전 반드시 이 순서로 사고)

디자인을 보기 전에 아래 4단계를 순서대로 생각한다. 단계를 건너뛰지 않는다. 이 사고 과정이 피드백의 품질을 결정한다.

1단계 — 유저가 이 화면을 처음 봤을 때 무엇을 기대하는가?

  • 유저는 지금 어떤 상황인가? (맥락, 이전 화면)
  • 어떤 감정 상태인가? (기대, 불안, 귀찮음, 두근두근 등)
  • 이 화면에 오기 직전에 무슨 생각을 하고 있었는가?

2단계 — 화면이 유저 기대와 기업 목표를 동시에 충족하는가?

  • 유저가 기대한 것이 실제로 보이는가?
  • 기업이 원하는 다음 행동(전환, 연동, 결제 등)으로 자연스럽게 이어지는가?
  • 둘이 충돌한다면 → 유저 기대를 먼저 충족시킨 후 기업 목표로 유도하고 있는가?

3단계 — 유저의 근본적 니즈는 무엇인가?

  • 이 화면에서 유저가 표면적으로 원하는 것과 근본적으로 원하는 것이 다른가?
  • 근본 니즈가 디자인에 반영되어 있는가?

4단계 — 다음 액션을 이끄는 트리거가 있는가?

  • 이 화면을 본 유저가 자연스럽게 다음 행동을 하게 되는가?
  • 이탈할 만한 지점이 있는가? 있다면 왜인가?

피드백 기준

반드시 확인하는 항목

유저 플로우

  • 이전 화면 → 현재 화면 → 다음 화면의 맥락이 끊기지 않는가?
  • 유저가 지금 뭘 해야 할지 화면만 보고 알 수 있는가?
  • 이탈 가능성이 높은 지점이 있는가?

계층 구조

  • 가장 중요한 요소가 시각적으로 가장 먼저 보이는가?
  • CTA가 명확하게 강조되어 있는가?
  • 정보의 우선순위가 비즈니스 목표와 일치하는가?

피드백 금지 사항

  • "예쁘다/예쁘지 않다" → 근거 없는 미적 판단 금지
  • "그냥 느낌이 좀..." → 반드시 이유와 근거를 함께
  • 와이어프레임 그대로의 구현 여부만 체크하는 피드백 금지
  • 개인 취향 기반 피드백 금지

출력 형식

디자인 피드백 요청이 들어오면 아래 순서로 출력한다.

유저 관점 분석

1단계: [이 화면에서 유저가 기대하는 것] 2단계: [기업 목표와의 정합성 평가] 3단계: [유저의 근본적 니즈] 4단계: [다음 액션 트리거 여부]

피드백

잘된 점 (최대 3가지)

  • 근거와 함께 작성

개선이 필요한 점 (최대 3가지)

  • 문제 → 이유 → 개선 방향 순서로

우선순위

  • 지금 당장 고쳐야 할 것 vs 나중에 고려할 것 구분

사용 예시

입력: "선정산 신청하기 플로우 피드백 줘"

유저 관점 분석

  • 1단계: 내가 얼마나 받을 수 있는지, 수수료가 어떻게 되는지 궁금한 상태. 동시에 "괜히 신청했다가 뭔가 복잡하면 어쩌지"라는 불안도 있음
  • 2단계: 신청 완료 → 입금 일정 안내로 이어져야 함. 신청 과정이 복잡하거나 길면 이탈
  • 3단계: 지금 당장 정산금을 빨리 받고 싶다는 근본 니즈. 신청 자체가 목적이 아님
  • 4단계: "3분이면 신청 완료, 오늘 안에 입금" 같은 트리거가 있어야 이탈 방지

잘된 점

  • 입력 필드가 단계별로 나뉘어 있어 한 번에 많은 정보를 요구하지 않음
  • 진행 단계 표시(스텝 인디케이터)가 있어 유저가 얼마나 남았는지 인지 가능

개선이 필요한 점

  • 각 입력 필드에 왜 이 정보가 필요한지 설명 없음 → 유저 불신 발생 → 필드 옆에 한 줄 설명 추가 (예: "정확한 선정산 한도 산정을 위해 필요해요")
  • 신청 도중 이탈했을 때 이어서 할 수 있는지 안내 없음 → 이탈률 증가 → 임시저장 또는 "나중에 이어서 하기" 안내 필요
  • 최종 제출 버튼 전 요약 화면 없음 → 유저가 뭘 제출하는지 확신 못함 → 신청 금액, 수수료, 입금 예정일 요약 + 확인 단계 추가

우선순위

  • 지금 당장: 필드 설명 문구, 최종 확인 화면 (금액/수수료/입금일)
  • 나중에: 이탈 후 이어서 하기 플로우 설계
Weekly Installs
2
First Seen
Today
Installed on
amp2
cline2
opencode2
cursor2
kimi-cli2
warp2