구독자님, 반가워요! 방구석 디자인 사수입니다.
이번주 주제는 "디자인 QA, 어디까지 체크해야 하나요?"입니다.
오늘 이 레터를 열어보신 분이라면, 아마 이런 경험이 한 번쯤은 있으실 거예요.
오프닝 : 그 불안한 '전송' 버튼
Figma 링크를 개발팀 슬랙에 공유하는 순간.
'혹시 내가 빠뜨린 거 없나?
'"개발자님이 이 상태는 어떻게 되는 거예요?" 하고 물어보면 어쩌지?'
'다 만들었는데 또 수정 요청 오면... 나 때문에 일정 밀리는 거 아닌가?'
저도 주니어 때 이 불안감을 정말 많이 느꼈어요.
한번은 로그인 화면을 넘겼는데, 개발자님이 이런 질문을 하시더라고요.
"비밀번호 틀렸을 때 에러 메시지는 어디에 뜨나요? 인풋 아래요? 토스트요?"
...아. 그걸 안 그렸구나.
그때부터 슬랙 알림이 올 때마다 심장이 덜컥했어요.
'또 빠뜨린 거 있나?' 하고요.
그 뒤로 일주일 동안 슬랙 알림이 계속 울렸어요.
전부 "이건 어떻게 처리해요?" 계열 질문이었어요.
혹시 지금 이 글을 읽으면서 고개를 끄덕이셨나요?
그렇다면 오늘 레터가 도움이 되실거예요.
🔍 원인 분석 : 왜 우리는 항상 '무언가 빠뜨린 것 같은' 불안함을 느낄까?
이건 여러분의 실력이 부족해서가 아니에요.
디자이너와 개발자는 화면을 보는 방식 자체가 다르기 때문이에요.
| 디자이너 | 개발자 | |
|---|---|---|
| 보는 것 | 완성된 한 장의 화면 | 조건과 분기의 흐름 |
| 생각하는 것 | "정보 배치 깔끔한가?" | "데이터 없으면? 에러 나면?" |
| 결과물 | UI 결과물 시안 1장 | 수십 가지 상태를 처리하는 코드 |
이 간극이 바로 핸드오프에서 구멍이 생기는 이유예요.
한마디로, 디자이너가 '정리된 UI 화면'만 그리면 개발자 입장에서는 이케아 가구를 설명서 없이 받은 것과 같아요. 부품은 있는데 조립 순서를 모르는 거죠.
그리고 주니어 디자이너가 가장 자주 하는 실수가 있어요.
이상적인 화면 '딱 한 장'만 만들어서 전달하는 것.
실제 사용자 환경에서는 예쁘게 채워진 데이터만 들어오지 않아요.
이름이 30자일 수도 있고, 프로필 사진이 없을 수도 있고, 인터넷이 끊길 수도 있어요.
이런 '예외 상황'을 미리 그려두지 않으면, 그 빈 칸은 전부 개발자의 몫이 됩니다.
결국 개발자가 혼자 판단해서 만들거나, 다시 디자이너에게 물어보게 되고, 그때마다 디자이너는 자책에 빠지게 되는 거죠.
여기서 하나 더 중요한 개념이 있어요.
바로 '디자인 부채(Design Debt)'예요.
핸드오프할 때 빠뜨린 작은 디테일들이 하나둘씩 쌓여서 나중에는 "이 프로젝트 전체적으로 뭔가 어설프다"는 느낌을 만드는 거예요.
버튼 색이 화면마다 미묘하게 다르다거나, 간격이 들쑥날쑥하다거나...
사용자는 정확히 뭐가 문제인지 모르지만, "이 앱 뭔가 신뢰가 안가"라고 느끼게 돼요.
무서운 건, 이 디자인 부채는 나중에 갚으려면 처음보다 몇 배의 시간이 든다는 거예요.
그래서 핸드오프 전에 잡는 게 가장 효율적인 거죠.
하지만 이건 경험으로 채울 수 있는 영역이고, 오늘 드리는 체크리스트만 있으면 그 불안감을 절반 이상 줄일 수 있어요.
✅ 해결책 : 핸드오프 전 '궁극의 셀프 QA 체크리스트'
이 체크리스트의 기준은
"개발자가 코드로 옮길 때 빈틈이 없는가?" 예요.
총 10개 카테고리를 하나씩, 찬찬히 가볼게요.
1️⃣ 숨겨진 상태(States) — "이 버튼 눌렀을 때 어떻게 되나요?"
디자이너가 가장 많이 놓치고, 개발자가 가장 많이 되묻는 부분이에요.
정적인 화면 하나만 그리면 안 됩니다.
모든 인터랙티브 요소에는 여러가지 상태가 존재해요.
🔘 버튼/링크 — 최소 5가지 상태
| 상태 | 설명 | 놓치면 일어나는 일 |
|---|---|---|
| Default | 아무것도 안 한 기본 상태 | 거의 안 놓침 |
| Hover | 마우스 올렸을 때 | 웹에서 "이 버튼 맞나?" 혼란 유발 |
| Pressed | 누르고 있는 순간 | "클릭된 건지 안 된 건지" 피드백 부재 |
| Disabled | 조건 미충족(예 : 필수 항목 미입력) | 개발자가 임의로 회색 처리 → 디자인 불일치 |
| Focus | Tab 키로 이동했을 때 | 접근성 위반, 키보드 사용자 이동 불가 |
| Loading | 클릭 후 처리 중 | 사용자가 버튼을 연타 → 중복 요청 발생 |
📝 입력 필드(Input) — 상태가 가장 많은 컴포넌트
| 상태 | 세부 체크 |
|---|---|
| Default | 기본 테두리 색상, placeholder 텍스트 |
| Active/Focus | 커서 깜빡임, 테두리 색상 변화, 라벨 이동 여부 |
| Filled | 입력 완료 후 모습, "x" 지우기 버튼 유무 |
| Error | 빨간 테두리 + 에러 메시지 위치 + 아이콘 유무 |
| Success | 초록 체크 + 성공 메시지(필요한 경우만) |
| Disabled | 회색 배경, 입력 불가 표시 |
| Read Only | Disabled와 다른 점 : 복사는 가능, 수정만 불가 |
| Placeholder | 입력 시작하면 사라지나요? 위로 올라가나요?(Float Label) |
그리고 여기서 진짜 중요한 질문이 있어요.
에러 메시지, 언제 보여줄 건가요?
이건 개발자가 가장 헷갈려하는 부분이에요.
왜냐하면 방법이 여러 가지 거든요.
| 유효성 검사 타이밍 | 설명 | 장단점 |
|---|---|---|
| 실시간(On Typing) | 한 글자 칠 때마다 검증 | ✅ 즉각적 피드백 ❌ 타이핑 중 에러 뜨면 짜증 |
| 포커스 아웃(On Blur) | 입력 필드에서 빠져나올 때 검증 | ✅ 가장 자연스러움 ❌ 서버 검증 불가 |
| 제출 시(On Submit) | 폼 전체를 제출할 때 검증 | ✅ 서버 검증 가능 ❌ 한번에 에러 쏟아짐 |
| 혼합형 | 기본은 On Blur, 이메일 중복 같은 건 On Submit | ✅ 가장 현실적 ❌ 설계가 복잡 |
NNGroup(닐슨 노먼 그룹)에서는 인라인 검증(Inline Validation), 즉 사용자가 필드를 벗어나는 순간 바로 에러를 보여주는 것을 권장해요.
타이핑 중이 아니라 입력을 마치고 다음 필드로 이동할 때 검증하는 게 가장 사용자 친화적이에요.
이걸 시안에 어떻게 표현하느냐?
상태 플로우 다이어그램을 만들어 두면 돼요.
Default → Active(입력 중) → Blur(벗어남) → [조건 충족?] → Success / Error → [수정] → Active → ...
이 흐름을 Figma에 한번만 그려두면, 개발자가 "에러 언제 띄워요?"라고 물어볼 일이 없어져요.
📊 데이터 상태 — 4총사 (이건 화면마다 의무!)
| 상태 | 무엇을 보여줄까? | 세부 체크 |
|---|---|---|
| Loading | 데이터를 불러오는 중 | 스피너? 스켈레톤 UI? 프로그레스 바? 어느 방식인지 명시 |
| Empty | 데이터가 0건 | 일러스트? 텍스트만? "아직 내역이 없습니다" + CTA 버튼? |
| Error | 서버 오류, 네트워크 끊김 | "다시 시도" 버튼 유무, 에러 코드 표시 여부 |
| Partial | 일부만 로드됨 (텍스트 O, 이미지 X) | 이미지 자리에 placeholder 표시 방법 |
사수의 팁
모든 화면에 Loading / Empty / Error를 '의무적으로' 옆에 붙여두는 습관을 들이세요.
처음엔 귀찮지만, 한번 습관이 되면 개발자 되물음이 확 줄어듭니다.
스켈레톤 UI와 스피너를 언제 쓰는지도 정해두면 좋아요.
보통 첫 로딩은 스켈레톤, 새로고침/추가 로딩은 스피너로 구분하는 게 자연스러워요.
🔔 피드백 상태 — 사용자에게 "잘 됐어요" 말해주기
이건 '상태'라기보다 '사용자에게 결과를 알려주는 방식'이에요.
| 상황 | 피드백 방식 | 디자이너가 정해야 할 것 |
|---|---|---|
| 폼 제출 성공 | 토스트? 성공 페이지? 모달? | 위치, 지속 시간(3초?), 자동 닫힘 여부 |
| 삭제 확인 | 컨펌 다이얼로그 | 제목 + 본문 + 버튼 라벨 2개 (취소/삭제) |
| 저장 완료 | 인라인 메시지? 토스트? | "저장되었습니다" 문구 + 체크 아이콘 유무 |
| 에러 알림 | 토스트? 에러 페이지? | 재시도 가능 여부, 고객센터 연결 링크 유무 |
| 복사 완료 | 툴팁? 토스트? | "복사되었습니다" 피드백 위치와 지속 시간 |
토스트 메시지를 쓸 때 특히 주의할 점이 있어요.
토스트가 에러가 발생한 입력 필드와 너무 멀리 떨어져 있으면 사용자가 에러 메시지를 읽으면서 동시에 문제를 수정할 수 없어요.
그래서 폼 에러는 토스트보다 인라인 에러 메시지가 훨씬 효과적이에요.
2️⃣ 극한의 데이터(Edge Cases) — "이름이 30자면요?"
디자인 시안에는 항상 이름이 "김민수", 제목이 "프로젝트 A" 같은 예쁜 데이터만 들어가죠.
하지만 현실은 그렇지 않아요.
📏 텍스트 길이
| 체크 항목 | 구체적으로 명시할 것 |
|---|---|
| 최대 길이 | 몇 글자에서 말줄임표(...)? 최대 몇 줄? |
| 최소 길이 | "A" 한 글자일 때 레이아웃 깨지지 않나? |
| 줄 바꿈 기준 | 단어 단위(word-break)? 글자 단위(break-all)? |
| 다국어 | 한국어 → 영어 번역 시 1.5~2배 길이 증가, 일본어 세로쓰기 등 |
| 특수문자 | 이모지(😀), HTML 태그, URL이 포함되면? |
| 말줄임 후 전체 보기 | "더보기" 클릭? 툴팁? 새 페이지? |
🖼️ 이미지
| 체크 항목 | 구체적으로 명시할 것 |
|---|---|
| 미등록 시 | 기본 아바타(Default Avatar) 디자인 |
| 비율 불일치 | Crop 기준(Center? Top? Face Detection?) |
| 로딩 실패 | 깨진 이미지 대신 보여줄 fallback 이미지 |
| 파일 형식 | PNG/JPG/GIF/WebP 구분, 용량 제한 있다면 에러 처리 |
| 동영상 썸네일 | 재생 아이콘 오버레이 유무, 자동 재생 여부 |
🔢 숫자와 날짜
| 체크 항목 | 구체적으로 명시할 것 |
|---|---|
| 큰 숫자 | 999,999,999원 → 레이아웃 견디나? 10억으로 단위 변환? |
| 0일 때 | 좋아요 0개 → "0"? "없음"? 숫자 자체를 숨김? |
| 음수 | 수익 -50,000원 → 빨간색 처리? 마이너스 기호? |
| 날짜 형식 | 2025.02.08 / 2025-02-08 / 2월 8일 중 어떤 것? |
| 상대 시간 | "3분 전" → "2시간 전" → "어제" → "2025.02.07" 전환 기준은? |
| 시간대(Timezone) | 해외 사용자가 있다면 UTC 기준? 현지 시간? |
📋 리스트와 콘텐츠
| 체크 항목 | 구체적으로 명시할 것 |
|---|---|
| 대량 데이터 | 100개 이상 → 페이지네이션? 무한 스크롤? "더보기" 버튼? |
| 검색 0건 | "검색 결과가 없습니다" + 추천 키워드/다른 카테고리 가이드 |
| 권한 없음 | 잠금 화면? 업그레이드 유도? 이전 페이지로 리다이렉트? |
| 정렬/필터 | 기본 정렬 기준(최신순?), 필터 적용 후 0건이면? |
사수의 팁
Figma에서 시안을 보여줄 때, 일부러 "최악의 데이터" 시안을 한 벌 따로 만들어 두세요.
이름 30자, 제목 없음, 이미지 없음, 가격 10자리... 이걸 보여주면 개발자가 "오, 이것까지 생각했네?"라고 신뢰를 보내줍니다.
실제로 실무에서 "Happy Path(정상 경로)"만 그리고, "Unhappy Path(예외 경로)"를 안 그리는 게 가장 흔한 주니어 실수예요.
3️⃣ 폼(Form) 디자인 상세 — "에러 메시지가 어디에 어떻게 뜨나요?"
폼은 디자인 QA에서 가장 디테일이 많이 필요한 영역이에요.
에러 메시지 하나에도 정해야 할 것이 이렇게 많아요.
📋 폼 전체 설계 체크리스트
| 항목 | 체크 내용 |
|---|---|
| 필수/선택 구분 | 필수 필드에 * 표시? "선택"이라고 명시? |
| 입력 포맷 가이드 | 전화번호 형식(010-0000-0000), 생년월일 형식 표시 여부 |
| 비밀번호 조건 | 입력 전에 조건 목록을 미리 보여줄 건지? 입력 중 실시간 체크? |
| 비밀번호 보기 | 👁️ 아이콘으로 텍스트 표시/숨김 토글 가능한지? |
| 자동완성 | 브라우저 자동완성(autofill) 허용할 건지? |
| 키보드 타입(모바일) | 이메일 필드는 @ 키보드, 전화번호는 숫자 키패드 |
| 폼 이탈 경고 | 뒤로 가기/탭 닫기 시 "저장하지 않은 내용이 있습니다" 팝업 |
| 제출 버튼 상태 | ㅍ |
에러 메시지 디자인의 핵심 원칙들 (NNGroup + Material Design 가이드라인 기반)
- 에러는 해당 필드 바로 아래에 — 폼 상단에 에러 목록만 보여주는 건 사용자가 위아래로 왔다 갔다 해야 해서 비효율적이에요
- 색상만으로 에러를 표시하지 말 것 — 색맹 사용자를 위해 아이콘(⚠️)이나 텍스트도 함께
- 에러 메시지는 구체적으로 — ❌ "입력값이 올바르지 않습니다" → ✅ "이메일 주소에 @가 빠져있어요"
- 비난하지 않고 해결책을 제시 — ❌ "잘못된 비밀번호" → ✅ "비밀번호가 일치하지 않아요. 다시 확인해 주세요"
- 에러 메시지가 뜰 때 원래 입력값을 가리지 않도록 — 사용자가 뭘 잘못 쳤는지 보면서 수정할 수 있어야 해요
사수의 팁
폼이 있는 화면을 핸드 오프할 때, "유효성 검사 명세서"를 Figma 옆에 테이블로 정리해 두면 개발자가 정말 감동해요.
각 필드별로 "언제 검증 / 조건 / 에러 메시지 문구"를 적어두는 거예요.
예시 :
| 필드명 | 검증 시점 | 조건 | 에러 메시지 |
|---|---|---|---|
| 이메일 | On Blur | 이메일 형식 | "이메일 형식을 확인해 주세요" |
| 이메일 | On Submit | 중복 체크 | "이미 가입된 이메일이에요" |
| 비밀번호 | On Typing | 8자 이상 | "8자 이상 입력해 주세요" |
| 비밀번호 확인 | On Blur | 일치 여부 | "비밀번호가 일치하지 않아요" |
4️⃣ 인터랙션과 로직(Logic) — "'그냥 슝~' 하고 나오면 돼요"는 사양합니다
개발자에게 통하지 않는 말 1위가 바로 이거예요. 😅
🔀 화면 전환 (Navigation)
| 전환 방식 | 설명 | 정해야 할 것 |
|---|---|---|
| Push | 오른쪽에서 밀고 들어옴 | 일반적인 페이지 이동 |
| Modal | 위/아래에서 올라오는 팝업 | 배경(Dim) 클릭 시 닫히나요? |
| Bottom Sheet | 아래에서 올라오는 시트 | 스와이프 다운으로 닫기 가능? 최대 높이? |
| Full Screen Modal | 전체 화면 덮는 모달 | 닫기 버튼 위치(좌상단? 우상단?) |
| Drawer | 옆에서 슬라이드로 나옴 | 좌/우 어느 방향? 배경 클릭 시 닫힘? |
| Replace | 현재 화면 자체가 바뀜 (히스토리에 안 남음) | 뒤로 가기 시 어디로? |
⬅️ 뒤로 가기 (Back Navigation) — 가장 많이 빠뜨리는 영역
| 상황 | 정해야 할 동작 |
|---|---|
| 일반 뒤로 가기 | 이전 페이지로 |
| 안드로이드 하드웨어 백 버튼 | 모달이 열려있으면 모달만 닫기? 페이지 이동? |
| 폼 작성 중 뒤로 가기 | "저장하지 않고 나가시겠습니까?" 경고 팝업? |
| 결제 프로세스 중 뒤로 가기 | 결제 취소 처리? 어디로 돌아가나? |
| 웹 브라우저 뒤로 가기 | 앱 내 뒤로 가기와 동일하게 동작? |
| 딥링크로 바로 진입한 경우 | 뒤로 가기 시 홈? 이전 앱으로 돌아감? |
✨ 애니메이션과 트랜지션
| 정해야 할 것 | 구체적 스펙 |
|---|---|
| Duration (지속 시간) | 0.15s? 0.3s? 0.5s? (보통 0.2~0.3s가 자연스러움) |
| Easing (가속 곡선) | ease-in, ease-out, ease-in-out, spring 중 어떤 것? |
| 레퍼런스 | Dribbble/Lottie 링크, 또는 직접 만든 GIF/영상 첨부 |
| 애니메이션 없는 곳 | "여기는 즉시 전환(no animation)"이라고 명시 |
🔄 유저 플로우 (User Flow)
| 체크 항목 | 설명 |
|---|---|
| 전체 화면 연결 | 화살표로 페이지 간 이동 관계 표시 |
| 분기점 표시 | 로그인 O → 메인, 로그인 X → 로그인 페이지 |
| 에러 분기 | 결제 실패 → 재시도 화면, 서버 에러 → 에러 페이지 |
| 딥링크 진입 | 중간 화면에 바로 들어왔을 때의 동작 |
| 최초 사용자 경험 | 첫 방문 시 온보딩/가이드 표시 여부 |
사수의 팁
Figma 프로토타입을 만들어 두면 말보다 빨라요.
하지만 프로토타입만으로 전달이 어려운 부분(뒤로 가기 로직, 딥링크, 폼 이탈 경고 등)은 반드시 텍스트 메모(Annotation)로 적어두세요.
Figma Dev Mode에서는 Shift + T로 바로 Annotation을 추가할 수 있어요.
5️⃣ 타이포그래피 일관성 — "같은 본문인데 왜 여기는 14px이고 저기는 15px이죠?"
눈에 잘 안 띄지만, 개발 단계에서 가장 자주 어긋나는 영역이에요.
"디자인이 어설퍼 보이는 이유의 80%는 간격과 타이포그래피 불일치 때문"이에요.
🔤 체크할 것들
| 항목 | 구체적 체크 |
|---|---|
| 폰트 패밀리 | 화면마다 같은 폰트? (중간에 다른 폰트 섞여 있지 않나?) |
| 사이즈 체계 | H1(28px) > H2(24px) > H3(20px) > Body(16px) > Caption(12px) — 일관적? |
| Weight(무게) | Regular(400), Medium(500), Bold(700) 등 사용 범위 정의 |
| Line Height(줄 간격) | 본문 150~160%, 제목 120~130% — 화면마다 제각각 아닌지? |
| Letter Spacing(자간) | 의도적으로 조정한 곳 명시 (특히 대문자 텍스트) |
| 정렬 | 좌측? 가운데? 화면마다 통일? |
| 폰트 파일 | 웹폰트 링크 또는 로컬 폰트 파일을 개발자에게 전달했나? |
여기서 실무에서 자주 일어나는 문제 하나!
같은 폰트인데 OS마다 다르게 보여요.
macOS Safari와 Windows Chrome에서 같은 폰트가 미묘하게 다르게 렌더링돼요.
이건 디자이너가 100% 통제할 수 없는 영역이지만, 알고 있으면 개발자와 소통할 때 도움이 됩니다.
"완벽히 똑같지는 않을 수 있다"는 전제 하에, 눈에 띄게 다른 부분만 수정 요청하는 게 현실적이에요.
이번 주는 여기까지!
다음 주에 나머지 6번째부터 보너스까지 다 알려드리겠습니다!
그럼 "디자인 QA, 어디까지 체크해야 하나요? 2편"을 기대해 주세요!
다음 주에 또 만나요!
의견을 남겨주세요