핵심 비유
'주문한 음식 기다리기' 비유 — 식당에서 음식이 안 나올 때, 점원이 "5분 뒤 나와요"라고 말해주면 안심하고 기다린다. 아무 말 없이 깜깜하면 "주문이 들어가긴 한 거야?" 불안해진다. 앱 로딩도 똑같다. 빈 화면 + 빙글빙글 스피너만 돌면 고장 같지만, 곧 나올 콘텐츠의 윤곽(스켈레톤) 을 미리 보여주면 같은 시간도 짧게 느껴진다. 기다림의 핵심은 속도가 아니라 정보다.
핵심 포인트
- 스켈레톤 UI — 콘텐츠가 들어올 자리를 회색 박스로 미리 보여주면 "곧 여기 뜨겠구나" 예측돼 체감 대기가 짧아진다.
- 빈 화면 + 스피너만 = "얼마나 기다려야 하지? 고장났나?" → 3초 넘으면 이탈.
- 3초 이상 걸리면 진행률(%)이나 단계 표시를 추가 — 끝이 보이면 기다린다.
- 실패하면 '다시 시도' 버튼 필수 — 막다른 길로 두지 않는다(D4 에러와 연결).
- 로딩도 디자인이다 — 유튜브·인스타가 스켈레톤을 쓰는 이유는 '빨라 보이게' 하기 위해서.
- 아주 짧은 작업(1초 미만) 엔 오히려 로딩 표시를 안 넣는 게 낫다 — 스피너가 번쩍하고 사라지면 화면이 깜빡여 더 어수선해 보인다.
교사 팁
유튜브 로딩(스켈레톤) vs 빈 화면 대기를 나란히 재생/캡처해 보여주면 학생들이 바로 "스켈레톤이 더 빨라 보인다"고 말한다(design-sense loading-pattern classGuide). "실제로 둘 다 같은 3초인데 왜 다르게 느껴질까?"를 물으면 '체감 시간 = 정보의 유무'라는 핵심에 도달한다. design-sense 분석 탭에 로딩 중 스크린샷을 올려 어떤 앱이 스켈레톤을 쓰는지 확인한다.
좋은 예 vs 나쁜 예
- ✅ 스켈레톤 UI + 진행률: 콘텐츠 형태 예고, 대기가 짧게 느껴짐, 포기 안 함. (design-sense
loading-pattern)
- ❌ 빈 화면 + 스피너만: 얼마나 기다릴지 모름, "고장났나" 의심, 3초 넘으면 이탈.
- ✅ 유튜브 앱: 영상 목록이 뜨기 전 회색 썸네일·제목 자리가 먼저 깔림 → "곧 여기 뜨겠구나". ❌ 파일 업로드 중 진행률 없이 멈춘 듯한 화면: 끝이 안 보여 취소하고 다시 시도.
실습·평가
- 실습: '피드가 뜨는 동안'의 로딩 화면을 두 버전(빈 스피너 / 스켈레톤)으로 스케치 → 짝에게 어느 쪽이 덜 답답한지, 왜인지 설명.
- O/X 퀴즈: "로딩 중에는 빙글빙글 도는 스피너 하나면 충분하다." → X (스켈레톤·진행률로 정보 제공이 체감 단축)