구독자님, 반가워요! 방구석 디자인 사수입니다.
오늘은 "디자인 QA, 어디까지 체크해야 하나요?" 2번째 스토리를 풀어보겠습니다.
핸드오픈 전 '궁극의 셀프 QA 체크리스트' 6번부터 시작합니다!
6️⃣ 컬러 시스템 - "이 빨간색이랑 저 빨간색이 다른 거예요?"
🎨 체크할 것들
| 항목 | 구체적 체크 |
|---|---|
| 컬러 토큰 | Primary, Secondary, Error, Success 등 이름(토큰)으로 관리하고 있나? |
| 일관성 | 같은 역할의 색이 화면마다 미묘하게 다르지 않나? (#FF0000 vs #E53935) |
| 다크 모드 | 지원한다면 전체 화면의 다크 모드 시안이 있나? |
| 투명도(Opacity) | 배경과 겹칠 때 의도한 대로 보이는지 확인 |
| 시멘틱 컬러 | 에러=빨강, 성공=초록, 경고=노랑, 정보=파랑 - 일관적? |
컬러에서 가장 많이 일어나는 핸드오프 사고가 있어요.
디자이너는 #3A7BF2라고 넘겼는데, 개발자가 눈대중으로 #4080F0을 쓰는 경우.
이걸 방지하는 방법이 바로 디자인 토큰(Design Token)입니다.
색상을 #3A7BF2 같은 헥스 코드가 아니라, color-primary-500 같은 이름으로 관리하는 거죠.
Figma에서는 Variables(변수) 기능으로 이걸 할 수 있어요.
변수로 연결해 두면 나중에 "Primary 색상 전체를 바꿔주세요"라는 요청이 와도 변수 하나만 바꾸면 전체가 바뀌어요.
7️⃣ 접근성(Accessibility) - "우리 서비스는 아직 그 단계 아닌데..."
이렇게 생각하실 수 있어요.
하지만 접근성의 기본은 모든 사용자의 사용성 입니다.
밝은 햇빛 아래에서 앱을 보는 사람, 한 손으로 조작하는 사람, 노안이 시작된 사용자 모두를 위한 거예요.
👁️ 색상 대비 (Color Contrast) - WCAG 2.1 AA 기준
| 요소 | 최소 대비 비율 | 예시 |
|---|---|---|
| 일반 텍스트 (16px 이하) | 4.5:1 | 흰 배경에 회색 텍스트 → #757575 이상 |
| 큰 텍스트 (18px Bold+) | 3:1 | 제목, 부제목 등 |
| 비텍스트 UI (아이콘, 그래프) | 3:1 | 아이콘 색, 차트 바 색 등 |
| 색상만으로 정보 구분 금지 | - | 빨강=에러 + ⚠️ 아이콘 병행 (색맹 대응) |
👆 터치 타겟 (Touch Target)
| 가이드라인 | 최소 크기 |
|---|---|
| iOS (HIG) | 44x44pt |
| Android (Material Design) | 48x48dp |
| WCAG 2.2 | 24x24px (주변 여백 포함 가능) |
작은 아이콘(예: 16x16px)이라도 터치 영역은 44px 이상으로 잡아야 해요.
그리고 인접한 클릭 요소 사이에 최소 8px 이상의 간격이 있어야 실수로 옆 버튼을 누르는 걸 방지할 수 있어요.
⌨️ 키보드 & 포커스
| 체크 항목 | 설명 |
|---|---|
| Tab 이동 | Tab 키만으로 모든 기능에 접근 가능한가? |
| 포커스 순서 | 시각적 순서와 일치하나? (좌→우, 위→아래) |
| 포커스 표시 | 포커스 상태가 눈에 보이나? (outline 스타일 삭제하지 않았나?) |
| 모달 포커스 트랩 | 모달이 열리면 모달 안에서만 Tab 키 순환? |
🏷️ 대체 텍스트 (Alt Text)
| 이미지 유형 | 처리 방법 |
|---|---|
| 의미 있는 이미지 | Alt text 가이드 제공 (예: "프로필 사진") |
| 장식용 이미지 | Alt 비워두기(alt="") 명시 |
| 아이콘 버튼 | 아이콘만 있고 텍스트 없으면 aria-label 필요 |
사수의 팁
접근성 전체를 완벽하게 하려면 부담이 크지만, 색상 대비 체크 + 터치 타겟 확보 + 포커스 상태 정의 이 세 가지만 습관화해도 "접근성을 고려하는 디자이너"라는 인상을 줄 수 있어요.
Figma 커뮤니티에서 Stark WCAG Checklist 위젯을 찾아보세요.
WCAG 항목별로 체크할 수 있는 무료 리소스예요.
8️⃣ 플랫폼별 차이 (iOS vs Android) — "이 버튼, iOS랑 안드로이드에서 다르게 해야 하나요?"
앱 디자인이라면 반드시 챙겨야 하는 부분이에요.
iOS(HIG)와 Android(Material Design)는 생각보다 많은 부분이 다릅니다.
| 요소 | iOS (Human Interface Guidelines) | Android (Material Design) |
|---|---|---|
| 시스템 폰트 | San Francisco | Roboto |
| 기본 단위 | pt (포인트) | dp (density-independent pixel) |
| 네비게이션 바 위치 | 화면 상단 | 화면 상단 |
| 뒤로 가기 | 화면 좌상단 < 뒤로 | 좌상단 ← 화살표 + 하드웨어 백 버튼 |
| 기본 탭 바 | 하단 Tab Bar (5개까지) | 하단 Navigation Bar + FAB 버튼 |
| 주요 CTA 버튼 | 우상단 텍스트 버튼 | FAB (플로팅 액션 버튼, 우하단) |
| 검색 | 화면 상단 Pull-to-Search 또는 Tab Bar 안 | 상단 App Bar 안 검색 아이콘 |
| 모달/시트 | 페이지 시트(Page Sheet), 카드형 | Bottom Sheet, Full-screen Dialog |
| 스와이프 제스처 | 왼쪽 가장자리에서 스와이프 = 뒤로 가기 | 없음 (하드웨어 백 버튼 사용) |
| 얼럿(Alert) | 가운데 팝업, 좌측=취소/우측=확인 | 가운데 팝업, 좌측=취소/우측=확인 (비슷) |
| 토스트 | 공식적으로 없음 (커스텀 사용) | Snackbar (하단, 액션 버튼 포함 가능) |
디자이너가 정해야 할 결정
- 두 플랫폼에서 동일한 디자인으로 갈 건지, 각 플랫폼 가이드라인에 맞게 별도로 만들 건지?
- 동일하게 간다면, 안드로이드 하드웨어 백 버튼 동작은 어떻게 할 건지?
- iOS 스와이프 뒤로 가기를 지원할 건지?
사수의 팁
작은 팀이나 스타트업에서는 대부분 두 플랫폼 동일 디자인으로 갑니다.
이때 가장 많이 빠뜨리는 게 안드로이드 하드웨어 백 버튼 동작이에요.
모달이 열려있을 때 백 버튼을 누르면 모달만 닫히는 건지, 이전 페이지로 가는 건지 꼭 명시해 주세요.
9️⃣ 카피(Copy)와 마이크로카피 - "Lorem ipsum은 절대 금지"
의외로 많이 놓치는 부분이에요.
"텍스트 영역"이라고만 적혀 있으면 개발자는 뭘 넣어야 할지 모릅니다.
✍️ 전체 체크리스트
| 카피 유형 | 정해야 할 것 | 예시 |
|---|---|---|
| 버튼 라벨 | 정확한 문구 | "확인" vs "저장하기" vs "다음 단계로" |
| 에러 메시지 | 필드별 구체적 문구 | "이메일 형식을 확인해 주세요" |
| 빈 화면 안내 | 텍스트 + CTA | "아직 알림이 없어요. 설정에서 알림을 켜보세요!" |
| Placeholder | 힌트 텍스트 | "이메일을 입력하세요" |
| 툴팁 | 마우스 오버 설명 | "이 설정을 켜면 매주 요약을 받을 수 있어요" |
| 토스트/알림 | 피드백 메시지 | "저장되었습니다 ✓" |
| 컨펌 다이얼로그 | 제목 + 본문 + 버튼 2개 라벨 | "삭제할까요?" "삭제하면 복구할 수 없어요" [취소] [삭제] |
| 로딩 메시지 | 긴 로딩 시 안내 | "잠시만요, 데이터를 불러오고 있어요..." |
| 법적 문구 | 약관 동의, 개인정보 관련 | PM/법무팀과 협의 필요 → 최소한 자리 확보 |
🌐 다국어 대응 (해당되는 경우)
| 체크 항목 | 설명 |
|---|---|
| 텍스트 길이 | 한국어 → 영어 번역 시 1.5~2배, 독일어는 더 길어짐 |
| 날짜/숫자 형식 | 미국(MM/DD/YYYY) vs 한국(YYYY.MM.DD) |
| 통화 기호 | ₩ / $ / € 위치와 형식 |
| RTL(아랍어 등) | 우→좌 레이아웃 미러링 필요 여부 |
사수의 팁
카피를 직접 작성하기 어려우면, 최소한 "이 화면에서 필요한 문구 목록"을 정리해서 PM/기획자에게 요청하세요. 빈칸으로 넘기는 것보다 "여기에 이런 성격의 문구가 필요해요"라고 메모만 남겨도 훨씬 나아요.
🔟 파일 정리 & 에셋 & 반응형 - "마지막 관문"
📂 파일 정리(Hygiene) - '개발자를 향한 배려'
| 항목 | 체크내용 |
|---|---|
| 스타일 연결 | 색상/폰트가 Variables(변수)에 연결되어 있나? |
| 레이어 이름 | Group 123 아닌 btn_primary, card_product 등 의미 있는 이름 |
| Auto Layout | 사용했나? → 개발자가 padding/gap을 바로 읽을 수 있어 구현이 쉬움 |
| 컴포넌트 연결 | Main Component에 연결? (Detach된 인스턴스 아닌지 확인) |
| 불필요한 요소 | 숨김 레이어, "v1", "최최최종" 프레임 삭제 |
| 소수점 값 | 13.5px, 7px 같은 비정수 값 없는지? (4px/8px 배수로) |
| 페이지 구조 | 작업 중 / 최종 / 컴포넌트 등 페이지 분리 |
🔷 아이콘 에셋
| 항목 | 체크 내용 |
|---|---|
| SVG 내보내기 | 패스(Path)가 깨지지 않았는지 Flatten(합치기) 처리 |
| Stroke → Outline | 선(Stroke) 기반 아이콘은 Outline Stroke로 변환 |
| 터치 타겟 | 아이콘 크기와 별개로 터치 영역 44px 이상 |
| 일관된 사이즈 | 24x24px, 20x20px 등 아이콘 그리드 통일 |
🖼️ 이미지 에셋
| 항목 | 체크 내용 |
|---|---|
| 해상도 | @1x, @2x, @3x 설정 |
| 파일 형식 | PNG/JPG/WebP 용도별 구분 |
| Export 설정 | Figma에서 미리 걸어두기 |
📱 반응형 (웹인 경우)
| 항목 | 체크 내용 |
|---|---|
| 브레이크포인트 | Mobile(375px) / Tablet(768px) / Desktop(1440px) - 개발자와 합의 |
| 레이아웃 변화 | 각 브레이크포인트별 시안 있는지 |
| 요소별 동작 | 이미지 줄어듦? 컬럼 스택? 사이드바 숨김? |
| 최소/최대 너비 | min-width, max-width 기준 명시 |
| 터치 대응 | 모바일에서 Hover 없음 → 대체 인터랙션은? |
사수의 팁
핸드오프 전 10분만 투자해서 레이어 정리를 해보세요.
"이 사람은 일을 깔끔하게 하는 사람이구나"라는 인상은 개발팀과의 협업에서 엄청난 자산이에요.
Figma에서 Rename It 플러그인으로 레이어 이름 일괄 변경하면 시간도 절약돼요.
📋 한눈에 보는 '궁극의' 셀프 QA 체크리스트
| # | 카테고리 | 핵심 체크 항목 |
|---|---|---|
| 1 | 상태 | 버튼 5상태(Default/Hover/Pressed/Disabled/Focus), 인풋 상태(Error/Success 포함) |
| 2 | 데이터 상태 | Loading(스켈레톤/스피너), Empty(빈 화면+CTA), Error(재시도 버튼), Partial |
| 3 | 피드백 | 성공/실패 토스트, 삭제 확인 다이얼로그, 저장 완료 피드백 정의 |
| 4 | 폼/유효성검사 | 검증 시점(OnBlur/OnSubmit), 에러 메시지 위치+문구, 비밀번호 조건 표시 |
| 5 | 텍스트 극한 | 최대(말줄임+줄 수), 최소, 줄바꿈 기준, 특수문자/이모지 처리 |
| 6 | 이미지 극한 | 기본 이미지, Crop 기준, 로딩 실패 fallback, 동영상 썸네일 |
| 7 | 숫자/날짜 | 형식 통일, 상대시간 전환 기준, 0/음수/큰 숫자 처리 |
| 8 | 인터랙션 | 전환 방식(Modal/Push/Sheet), 뒤로 가기 동작, 팝업 닫기 조건 |
| 9 | 애니메이션 | Duration, Easing 명시 또는 레퍼런스 영상, 없는 곳은 "no animation" |
| 10 | 유저 플로우 | 전체 흐름 연결, 분기점, 에러 분기, 딥링크 진입 시 동작 |
| 11 | 타이포그래피 | 폰트/사이즈/무게/줄간격 일관, 디자인 시스템 체계 준수 |
| 12 | 컬러 | 토큰으로 관리, 화면별 일관성, 다크모드(해당 시), 투명도 확인 |
| 13 | 접근성 | 색상 대비 4.5:1, 터치 타겟 44px+, 포커스 상태, Alt text |
| 14 | 플랫폼 | iOS/Android 차이 대응, 하드웨어 백 버튼, 스와이프 제스처 |
| 15 | 카피 | 버튼 라벨, 에러 메시지, 빈 화면, 툴팁, 다이얼로그 문구 완성 |
| 16 | 반응형 | 브레이크포인트별 시안, 요소별 반응형 동작, 모바일 Hover 대체 |
| 17 | 파일 | 레이어명 정리, 변수 연결, 숨김 레이어 삭제, 소수점 값 제거 |
| 18 | 에셋 | 아이콘 SVG(Flatten), 이미지 @2x/@3x, Export 설정 |
| 19 | 메모 | 빠뜨린 부분에 Annotation 남김, "Ready for Dev" 상태 표시 |
🛠️ Figma Dev Mode 200% 활용하기
핸드오프를 더 깔끔하게 만들어주는 Figma Dev Mode 기능들이에요.
"Ready for Dev" 상태 표시
- 완성된 프레임/섹션에 Ready for dev 상태를 걸어두면, 개발자가 Dev Mode에서 "아, 이건 작업해도 되는 거구나" 하고 바로 알 수 있어요.
- 아직 작업 중인 화면과 완성된 화면이 섞여 있으면 개발자가 혼란스러워해요.
Annotation(주석) 추가하기
- Dev Mode에서 Shift + T로 Annotation을 추가할 수 있어요.
- 컴포넌트의 동작, 예외 상황, 특이 사항을 메모로 남기면 개발자가 Dev Mode 안에서 바로 확인 가능.
- 외부 문서(Jira 티켓, Storybook, Confluence 등)의 링크도 연결할 수 있어요.
버전 비교 (Compare Changes)
디자인이 수정되면 개발자가 "어디가 바뀐 거예요?"라고 물어보는 경우가 많죠?
Dev Mode의 Compare Changes 기능으로 이전 버전과 현재 버전의 차이를 시각적으로 확인할 수 있어요.
디자인 수정 후에는 상태를 다시 "Ready for dev"로 업데이트하고, 변경 내용을 코멘트로 남겨주세요.
사수의 팁
Figma 링크를 공유할 때, 일반 링크가 아닌 Dev Mode 링크를 공유하세요.
개발자가 파일을 열었을 때 바로 Dev Mode로 진입해서 필요한 정보를 빠르게 확인할 수 있어요.
🦴 완벽하지 않아도 괜찮아요 - '메모(Annotation)'를 남기세요
위의 19개 항목을 보고 "와, 이걸 다 한다고?" 하셨을 수도 있어요.
당연히 매번 전부 다 할 수는 없어요.
시간도 부족하고, 아직 결정 안 된 것도 있고요.
그럴 때는 메모 하나만 남겨도 개발자는 안심합니다.
"이 부분 텍스트가 두 줄 이상 넘어가면 말줄임(...) 처리 부탁드려요!"
"Hover 효과는 기존 디자인 시스템의 버튼 스타일 따라가면 됩니다."
"Empty 상태는 아직 디자인 전이에요. 일단 '데이터가 없습니다'로 넣어주시면, 다음 스프린트에서 디자인 드릴게요!"
"에러 메시지 문구는 PM님과 논의 중이에요. 확정되면 바로 업데이트할게요."
"이 애니메이션은 이 레퍼런스 참고 → [Dribbble 링크]. Duration 0.3s, ease-out이면 좋겠어요."
"안드로이드 백 버튼 누르면 이 모달은 닫히고 이전 화면 유지해 주세요."
핵심은 이거예요.
"모르는 건 괜찮다. 모르는데 모른 척하는 게 문제다."
빠뜨린 부분을 솔직하게 메모로 남기는 디자이너와, 아무 말 없이 화면만 던지는 디자이너.
개발자가 더 신뢰하는 쪽은 당연히 전자겠죠?
🔁 보너스 : 핸드오프 '후'에도 QA가 있다는 거, 알고 계셨나요?
여기까지는 핸드오프 '전' 이야기였어요.
그런데 사실, 진짜 디자인 QA는 개발이 끝난 후에도 한 번 더 해야 해요.
이걸 '디자인 구현 리뷰(Design Implementation Review)'라고 불러요.
왜 필요할까요?
아무리 꼼꼼하게 핸드오프해도, 개발 과정에서 디테일이 빠지거나 달라지는 건 100% 일어나는 일이에요.
실무에서 자주 발견되는 불일치 유형
| 유형 | 예시 | 발견 빈도 |
|---|---|---|
| 시각적 불일치 | 폰트 사이즈 1~2px 차이, 색상 미묘하게 다름, 간격 불일치 | ⭐⭐⭐⭐⭐ 매우 흔함 |
| 상태 누락 | Hover/Disabled 상태 미구현, 에러 화면 없음 | ⭐⭐⭐⭐ 흔함 |
| 인터랙션 차이 | 애니메이션 속도/이징 다름, 전환 방식 다름 | ⭐⭐⭐ 보통 |
| 기능적 불일치 | 뒤로 가기 동작 다름, 스크롤 동작 다름 | ⭐⭐⭐ 보통 |
| 반응형 문제 | 특정 화면 크기에서 레이아웃 깨짐 | ⭐⭐ 가끔 |
디자인 구현 리뷰 5단계 프로세스
Step 1. 스테이징 환경에서 직접 만져보기
- 테스트 환경에 접속해서 주요 유저 플로우를 직접 따라가요
- 가능하면 다양한 디바이스/브라우저에서 확인 (Chrome, Safari, 모바일)
Step 2. 오버레이 비교 (프로 팁!)
- 스테이징 환경 스크린샷을 캡처 (Chrome의 FireShot 확장 프로그램 추천)
- Figma에서 원본 시안 위에 스크린샷을 올리고 **투명도 50%**로 설정
- 겹쳐보면 어디가 다른지 바로 보여요 - 간격, 크기, 위치 차이가 '유령'처럼 드러남
Step 3. 스트레스 테스트
- 필드에 일부러 잘못된 데이터 입력해보기
- 페이지 중간에 창 닫기, 뒤로 가기 반복
- 빠르게 버튼 연타해보기
- 극단적으로 긴/짧은 데이터 넣어보기
Step 4. 이슈 문서화 + 우선순위 매기기
| 우선순위 | 기준 | 예시 |
|---|---|---|
| 🔴 필수 수정 | 사용자 경험에 직접 영향 | 버튼 클릭 안 됨, 에러 화면 누락 |
| 🟡 가능하면 수정 | 품질 저하지만 기능은 작동 | 간격 4px 차이, Hover 색상 다름 |
| 🟢 다음에 수정 | 미세한 차이 | 폰트 렌더링 미묘한 차이, 그림자 강도 |
Step 5. 개발자와 리뷰 미팅
- 문서를 공유하고, 각 항목에 대해 "수정 / 다음 스프린트 / 패스" 결정
- 기술적 제약이 있는 경우 대안 디자인 제안 (예: CSS 한계로 완벽한 그라데이션 불가 → 단색으로 대체)
사수의 팁
구현 리뷰에서 모든 걸 고치려고 하면 일정이 터져요.
"사용자가 바로 체감하는 문제"와 "나만 보이는 미세한 차이"를 구분하는 것도 디자이너의 중요한 판단이에요.
대부분의 디자이너가 원하는 건 돋보기로 봤을 때 완벽한 게 아니라, 눈으로 봤을 때 자연스러운 거예요.
⚡ 10분 미션 : 내 최근 핸드오프 점검하기
지금 당장 해볼 수 있는 미션이에요.
Step 1.
최근에 개발팀에 넘긴 (또는 넘기려고 하는) 화면 하나를 열어보세요.
Step 2.
위 체크리스트 19개 항목 중, 가장 자주 빠뜨리는 Top 3만 골라서 체크해 보세요.
(대부분의 주니어에게는 상태(States), 에러 처리(Form Validation), 뒤로 가기(Back Navigation) 이 3개가 가장 빈번해요.)
Step 3.
빠진 항목이 있다면, 지금 바로 Figma에 메모(Annotation) 1개만 추가해 보세요.
완벽한 핸드오프는 하루아침에 만들어지지 않아요.
하지만 "오늘 메모 하나"가 쌓이면, 어느 순간 개발자가 먼저 이렇게 말해줄 거예요.
"디자이너님, 요즘 전달 주시는 거 진짜 깔끔하네요!"
그 한마디, 생각보다 기분이 좋을 거예요. 😊
📌 오늘의 한 줄 요약
핸드오프는 '예쁜 화면 전달'이 아니라, '개발자가 빈틈 없이 코드로 옮길 수 있는 설계도 전달'이다.
완벽하지 않아도 괜찮다 - 메모 하나면 빈틈을 메울 수 있다.
📢 잠깐, 공지가 있어요!
다음 호부터 발행 주기가 매주 → 2주에 1편으로 바뀝니다.
개인적인 사정으로 매주 뉴스레터를 발행하기가 어렵게 되었어요.
2주에 한 번, 대신 더 단단한 글로 찾아올게요.
기다리는 동안 궁금한 점이나 고민이 생기시면 언제든 댓글이나 메일로 보내주세요.
여러분의 고민이 다음 레터의 주제가 됩니다! 🙌
다음 주 주제가 궁금하신가요? 댓글로 투표해 주세요!
- 디자이너도 코드를 알아야 하나요? - 개발자와 더 잘 소통하기 위한 최소한의 개발 지식
- 사수 없이 성장하는 법 - 1인 디자이너의 셀프 성장 루틴
그럼, 다다음 주에 또 만나요!
의견을 남겨주세요