로딩, 오류, 빈 화면 UI/UX 패턴

• 모든 상황에 적절한 공통 로딩, 오류, 빈 화면은 없습니다.

• 항상 빈 화면, 스피너, 특정 문구를 보여주는 화면이 항상 적절할 수는 없습니다.

1. 로딩, 오류, 빈 화면의 필요성

1-1. 적절한 로딩 화면의 필요성

로딩 시간의 비용은 이탈률

• 로딩 시간에는 이탈률이라는 비용이 있는데요, 이는 데이터로 검증이 된 사실입니다:
• ‣
• ‣
• (요약) 로딩 시간 증가 시의 비용:
• 1 → 3초: 이탈률 32% 증가
• 1 → 5초: 이탈률 90% 증가

• 또한 평균적인 로딩 속도는 매년 높아지고 있기 때문에 로딩 시간의 상한선은 점점 낮아질 것입니다.

로딩 화면의 효과 - 인지되는 로딩 시간 감소

• 로딩 화면은 인지되는 로딩 시간을 줄일 수 있습니다.

• 즉, 로딩 시간이 줄어드는 효과를 만들기 때문에 이탈률이 줄어들 수 있습니다.

• 다소 오래된 연구(2004)이지만, 로딩 바가 사용자로 하여금 더 기다릴 수 있게 만들어준다는 데이터가 있습니다.
• 로딩 바가 있는 경우, 로딩 바를 본 참가자 그룹의 중간 대기 시간은 22.6초,
• 로딩 바를 전혀 볼 수 없는 참가자 그룹의 중간 대기 시간은 9초
• ‣

로딩 화면의 효과 - 즉시 응답 제공

• 로딩 화면도 응답의 한 종류입니다.

• 로딩 상태는 응답을 대기하고 있는 상황이기 때문에 응답을 즉시 제공할 수 없는데요, 이를 대신해 응답을 즉시 제공하는 역할을 합니다.

로딩 화면의 효과 - 잘 처리되고 있음을 응답

• 로딩 화면은 사용자의 요청이 정상적으로 접수되었으며 처리되고 있음을 전달합니다.

• 만약 로딩 화면이 없어 텅 빈 페이지를 보게 된다면 사용자는 이를 오류라고 생각할 수밖에 없습니다.

• 사용자는 즉각적인 응답을 원하기 때문에, 로딩 화면의 즉시성은 로딩이라는 불쾌한 상황에서의 적절한 차선책입니다.

1-2. 적절한 오류 화면의 필요성

• GA, Chrome 같은 데이터 수집 측에서 임의의 사이트의 특정 페이지가 오류 페이지인지 아닌지를 정확히 결정할 수 없을테니 당연한 결과일 수도 있습니다.

오류 화면의 필요성 - 좌절감, 대립감 해소

• 오류는 사용자의 행동의 결과이기 때문에, 사용자의 노력이 좌절된 상황일 확률이 높습니다.

• 그래서 어떤 오류는 굉장히 불쾌할 수 있고, 잘 처리하지 못한다면 서비스가 사용자를 막아선다는 인식을 줄 수 있습니다.

• 충성 사용자일수록 서비스의 사용 빈도가 높고, 오류 화면을 만날 확률은 그에 비례하기 때문에, 오류 페이지의 이탈에는 충성 사용자의 비율이 비교적 높을 수도 있습니다.

오류 화면의 필요성 - 문제를 쉽고 빠르게 해결할 수 있게 안내 제공

• 오류가 발생한 상황에서는 사용자에게 원인이 무엇이고, 어떻게 해결할 수 있는지 쉽고 명확하게 제공해야 합니다.

• 적절한 안내가 중요합니다. 문제를 빠르게 해결하는 방법을 제공해 서비스가 사용자를 막아선다는 인식을 최소화해야 합니다.

• 응답이 없거나 stacktrace를 그대로 노출하는 경우 사용자의 불쾌감이 줄어들 수 없습니다.

1-3. 적절한 빈 화면의 필요성

빈 화면의 효과 - 조회 결과가 빈 것이라는 사실을 명확히 전달

• 조회 요청이 정상적으로 처리되었지만, 표시할 데이터가 없는 경우에 빈 영역만을 표시하는 경우 사용자는 정상적으로 처리되었는지 인지하기 어려울 수 있습니다.

• 이 때 애플리케이션은 “정상 조회 결과, 데이터가 없습니다”라는 의도를 사용자에게 명확히 전달해야 합니다.

2. 로딩 패턴

2-1. 로딩 UX 패턴

레퍼런스

• ‣

• ‣

• ‣

• ‣

• ‣

• ‣

• ‣

• ‣

• ‣

즉각적인 로딩 표시

• 요청을 받은 직후에는 항상 즉각적인 피드백을 제공합니다.

미리 결정되어 있는 로딩 소요 시간

• 사용자는 명확한 로딩 소요 시간을 알면 더 오래 기다릴 수 있습니다.

• 정확한 시간 추정치는 사용자가 스스로 기대치를 조절할 수 있게 해 대기 시간 동안의 불쾌함을 완화하는데 도움이 됩니다.

로딩 소요 시간 별 적정 로딩 UI

• 0.1 ~ 1초:
• 표시하지 않음.
• 사용자가 로딩 UI를 인식하기 어려움

• 1 ~ 2초:
• 로딩 스피너
• 스켈레톤

• 2 ~ 10초:
• 실제 남은 시간 표시, 남은 시간에 비례한 로딩 바 표시
• 실제 남은 시간을 알 수 없는 경우에는 임의의 로딩 단계 표시

• 10초 이상:
• 백그라운드 실행 옵션 제공
• 남은 시간을 알 수 있는 경우
• 남은 시간 표시

먼저 로딩된 내용을 먼저 표시 (Incremental Loading)

• 데이터를 최대한 일찍 표시하기 위해 먼저 로딩된 데이터를 먼저 표시해 더 일찍 상호작용할 수 있게 합니다.

• 단, 동시에 스피너가 과도하게 표시되면 좋지 않습니다.
• 각 작은 단위들마다 스피너를 띄워 한 화면에 스피너가 3-5개씩 보이는 것보다는, 인접한 로딩 영역은 하나로 통합해 더 적은 개수의 스피너를 띄우는 것을 지향합니다.

로딩 스피너의 레이아웃 시프트 최소화

• 로딩 대상 영역 내에 스피너가 위치해야 로딩 완료 시 레이아웃 시프트를 최소화할 수 있습니다.

로딩 대상의 명확화

• 특정 인터페이스 내에 로딩 UI를 통합하면 무슨 작업에 대한 로딩인지 명확해집니다.
• (ex) 유튜브 오프라인 다운로드 버튼

로딩 중 컨트롤(버튼) 비활성화

• 행동에 따른 로딩 발생 시, 제대로 실행 중인지 혼동하지 않게 하기 위해 컨트롤을 비활성화하여 요청이 접수됐음을 명확히 표현합니다.

빈 화면보다 스켈레톤 우선

• 스켈레톤으로 인지적인 로딩 시간을 감소시킬 수 있습니다.

• 스켈레톤은 빈 화면보다 더 부드럽게 실제 데이터로 전환할 수 있습니다.
• 0 → 1 (빈 화면)
• 0 → 0.5 → 1 (스켈레톤)

작업이 길어지는 경우 백그라운드로 실행

• 파일 업로드 등의 작업의 경우 전체 화면을 블로킹하지 않고 백그라운드 UI로 표현합니다.

로딩 화면에 흥미로운 인터렉션 표시 혹은 정보를 제공

• 브랜드/서비스의 특성을 반영한 인터렉션을 표시합니다.

2-2. 로딩 UI 사례 수집

전역 로딩 바: 페이지 상단

컴포넌트 단위 로딩 스피너

 

컴포넌트 단위 스켈레톤

로컬 스피너

로딩 중 버튼 비활성화

남은 시간 표시 + 백그라운드

n단계 + 단계 별 작업 내용

n단계 + 진행률에 비례한 로딩바

저화질 샘플 (low quality image placeholder)

3. 오류 패턴 (TBD)

3-1. 오류 UX 패턴

3-2. 오류 UI 패턴

4. 빈 화면 패턴 (TBD)

4-1. 빈 화면 UX 패턴

4-2. 빈 화면 UI 패턴