로딩은 UX에서 필수 요소로 자리 잡았습니다. 로딩이 발생하면 사용자 대기 시간을 줄이고 시스템의 가치를 높일 수 있기 때문입니다.
하지만 페이지에 로딩 스피너를 둔 것 만으로 사용자가 머물기를 기대해야 할까요?. 이 문서는 디자이너, 개발자, QA 및 제품 담당자가 적절한 로딩 패턴을 구축하기 전에 사용자와 시스템의 컨텍스트를 모두 고려하는 데 도움을 주기 위한 내용입니다.
로딩 시간
로딩 시간은 현재 작업의 가치와 동일해야 합니다. 가끔씩 수행되는 고위험 작업의 경우 작업을 실제보다 더 길게, 더 중요한 것처럼 보이게 만드는 것을 고려할 수 있습니다. 정기적으로 수행되는 빠른 작업의 경우 실제로 목표는 대기 시간을 최소화하는게 도움이 됩니다.
UI로 기대치 설정하기
로딩 상태는 제품에 대한 사용자의 기대치를 설정하는데 도움을 줍니다. 현재 일어나고 있는 일을 설명하거나 다음에 일어날 일을 준비함으로써 사용자의 불확실성을 줄이는 역할을 합니다.
로딩 스피너를 만들 때 어떤걸 고려해야할까요?
로딩이 미리 이루어지나요?
예를 들어 사용자가 페이지를 처음 로드하고 기존 콘텐츠가 표시되기를 기대하는 경우와 같이 사전 로드 상황을 처리할 수 있습니다. 여기서는 사용자가 표시될 페이지에 익숙하지 않을 수 있으므로 기대치를 조절해야 합니다.
로딩이 사용자에 의해 트리거됩니까?
또는 양식을 제출하거나 대용량 문서를 내보내도록 요청하는 등 사용자가 시작한 작업을 따르는 로딩 상호 작용을 생성할 수도 있습니다. 이 경우 즉각적인 피드백이 가장 중요합니다. 진행 상황을 표시하기 위해 적절한 로딩 패턴을 표시하기 전에 시스템에서 요청을 이해했음을 알리고 싶습니다.
전체 화면을 차단해야 합니까?
이 로딩 상호 작용에 필요한 공간이 얼마나 되는지 스스로에게 물어보는 것이 중요합니다. 사용자 입력이 필요하지 않고 눈에 띄지 않는 작업이라면 자연스럽게 백그라운드에서 조용히 수행되기를 기대할 것입니다. 시스템이 관리하기 쉽다고 하더라도 사용자의 맥락에서 중요한 작업인 경우 전체 페이지 로딩 메커니즘은 사용자에게 보안감과 신뢰감을 줄 수 있습니다.
콘텐츠가 로드되는 시점을 예측할 수 있나요?
작업을 완료하는 데 필요한 시간에 대해 얼마나 많은 가시성을 갖고 있습니까? 정확하게 추정할 수 있나요? 이를 사용자에게 전달하는 것이 가치가 있습니까? 로드하는 데 시간이 얼마나 걸릴 것으로 예상되나요?
우리가 설정한 타이밍 임계값에 따라 다양한 동작을 시작할 수 있습니까?
긴 로딩 작업을 다른 메시지나 시각적 요소를 사용하여 더 작은 덩어리로 나누는 것을 고려할 수 있습니다.
로드해야 하는 객체의 범위는 얼마나 됩니까?
최종 결과의 범위는 무엇입니까? 3개의 카드 목록에는 페이지 매김이나 "추가 로드" 버튼 등이 포함될 수 있는 10,000개 항목 테이블과 로딩 경험에 대한 다른 반영이 필요합니다.
서버는 어떻게 정보를 페이지에 반환합니까?
사용자에게 반환하는 것이 가장 합리적인 것이 무엇인지 스스로에게 물어보세요. 콘텐츠가 로드될 때 하나씩 불러오는 것이 합리적일 수도 있습니다. 예를 들어 12개의 항목을 표시할 준비가 될 때까지 로딩 환경을 확장하는 것이 더 합리적일 수 있습니다. 이에 대해 생각할 때 일반적인 사용자 시나리오를 염두에 두십시오. 귀하의 사용자와 콘텐츠는 귀하가 가장 잘 알고 있습니다.
데이터가 동기화되어 있나요? 아니면 새로 고침 메커니즘이 필요합니까?
고려해야 할 사항은 데이터를 가져오는 방법과 시기입니다. 백그라운드에서 항상 동기화가 유지되나요? 때때로 사용자가 페이지를 수동으로 새로 고쳐야 합니까? 이벤트의 빈도와 사용자 참여에 적합한 피드백 메커니즘을 로드하는 것을 생각해 보세요.
업데이트 또는 변경 빈도는 얼마나 됩니까?
데이터가 몇 초마다 업데이트되는 경향이 있습니까? 몇 시간마다? 하루에 한 번? 이는 공간 및 사용자 흐름 중단 측면에서 로딩 경험에 추가하려는 논리에 영향을 미칩니다.
모바일 경험을 고려해 보셨나요?
모바일 경험이 어떤 영향을 받을지 생각해 보셨나요? 모바일 장치에는 UI 패턴이 있고 위치와 순간에 따라 연결 속도와 데이터 전송 속도가 다를 수 있으므로 이는 독특한 시나리오일 수 있습니다.
로직
페이지 렌더링 로직을 파악하려면 데이터 구조와 사용자의 기대를 가장 잘 결합하는 방법을 이해하는 데 시간을 투자해야 합니다. 로딩 상태는 수동적일 수도 있고 능동적일 수도 있으며, 이 두 요소의 범위에 따라 적절한 피드백 경험을 디자인하려고 합니다.
- Passive loading은 시스템이 물건을 미리 로딩하는 것입니다. 예를 들어 시스템이 처음으로 데이터가 많은 페이지를 로드하거나, 파일을 열거나, 검색 결과를 표시하는 경우입니다.
- Active loading 상태는 시스템이 사용자가 트리거한 작업에 응답하는 상태입니다. 새로 입력 데이터를 게시하거나, 대용량 파일을 내보내거나, 자동화된 작업을 실행할 때 등입니다. (작업에는 로딩 버튼(또는 자세히 읽기 버튼), 콘텐츠 영역 스크롤 등이 포함될 수 있습니다.)
범위는 처리되는 데이터의 양과 그에 따라 인식되는 작업의 중요성에 따라 달라집니다.
이제 원하는 로딩 환경의 컨텍스트를 더 잘 알게 되었으므로 몇 가지 일반적인 사용 사례를 살펴보겠습니다.
범위
로드하는 데이터의 양은 얼마나 됩니까? 개별 데이터 조각의 크기는 얼마나 됩니까? 예를 들어 이미지, 아이콘, 텍스트 및 버튼이 각각 포함된 복잡한 카드 페이지를 로드하는 것은 가벼운 텍스트 기반 행으로 구성된 테이블을 로드하는 것과는 다른 로드 고려 사항이 필요합니다.
항목을 하나씩 로드
더 복잡하고 다양한 형식의 구성 요소의 경우 대부분의 경우 하나씩 로드하고 표시하는 것이 좋습니다. 목표는 사용자 측에서 인지되는 대기 시간을 줄이는 것입니다. 사용자에게 혼란을 주지 않고 한 번에 하나의 항목만 처리할 수 있다면 더 이상 고민할 필요가 없습니다. 당신은 그들에게 즉시 작업할 수 있는 것을 제공하고 있습니다.
항목을 로드하고 한 번에 모두 표시
테이블과 같이 그룹으로 더 잘 존재하는 가벼운 구성 요소의 경우 모든 구성 요소를 한 번에 또는 적어도 일괄적으로 로드하고 표시하는 것이 더 합리적입니다. 이제 로드하는 동안 어떤 일이 발생하는지에 대해 곧 특정 로드 패턴을 다루겠습니다.
Lazy Loading
구성 요소의 복잡성에 관계없이 구성 요소 수가 많으면 지연 로딩을 선택하는 것이 좋습니다. 이렇게 하면 미리 로드해야 하는 데이터의 양이 줄어듭니다. 사용자의 뷰포트 높이가 감당할 수 있는 것보다 조금 더 채우면 됩니다. 적어도 그들이 바닥에 닿아 더 많은 것을 요구할 때까지는 말이죠.
지연 로딩은 필요할 때만 실행되도록 로딩을 연기하는 것을 의미합니다.
이는 세 가지 방식으로 발생할 수 있습니다.
1. 무한 스크롤은 자동 또는 수동 방식입니다. 사용자가 목록이나 페이지의 끝에 도달했거나 도달에 가까워졌음을 감지하면 더 많은 콘텐츠를 가져오는 트리거가 됩니다.
3. 여기서 페이지 매김이 시작됩니다. 페이지 매김은 여러 페이지에서 발생하는 지연 로딩입니다. 사용자가 언제 더 많은 콘텐츠를 보고 싶은지 결정할 수 있게 하고 콘텐츠 범위를 페이지당 표시되는 합리적인 양으로 제한합니다.
페이지 매김은 또한 사용자에게 장소감을 만들어 줍니다. 시간이 지나면 그들은 어떤 개체가 어느 페이지에 있는지에 대한 정신 지도를 구축하기 시작하며 이는 검색 가능성과 향후 참조에 도움이 됩니다. 또 다른 장점은 사용자가 '장소'를 개체와 연결할 수 있다는 것입니다. “예를들면 사용자 A가 가장 좋아하는 옵션은 3페이지에 있어 3페이지로 자주 가도록 하는 것 입니다.”
빈도
이러한 사전 로딩은 얼마나 자주 발생합니까?
매우 빈번함
콘텐츠가 항상 자동으로 동기화되는 경우 로딩 피드백이 매우 최소화되기를 원할 것입니다.
드문
페이지 변경이 더 드물고 사용자가 새로 고침을 시작해야 하는 경우 새로운 내용이 제공되는 즉시 이를 전달해야 합니다.
이러한 유형의 로딩 상호 작용에는 자동 동기화보다 약간 더 많은 공간이 필요하므로 전체 너비 상단 배너나 알림 메시지가 사용자의 관심을 효과적으로 끌 수 있습니다.
로딩 패턴
명확한 진행률 표시기는 기간에 대한 감각을 전달합니다. 시작점과 끝점이 있습니다. 이는 사용자에게 예상되는 대기 시간에 대한 추가 정보를 제공합니다. 불확실한 진행률 표시기는 지속 기간이 불확실합니다. 일반적인 예로는 반복 애니메이션 또는 스피너가 있습니다. 정보는 적지만 때로는 불가피한 경우도 있습니다.
(TL;DR) 핵심 원칙
- 항상 요청을 받은 후 바로 즉시 피드백을 제공하세요.
- 2초 이상 대기하는 경우 반복되는 애니메이션을 사용합니다(불확정).
- 10초 이상 대기하는 경우 완료율 표시기를 사용합니다(확정).
- 정적 로딩 메시지를 사용하지 말고 동적이며 상황에 맞는 메시지인지 확인하세요.
이제 다양한 활성 로딩 사용 사례(예: 사용자 작업에 의해 트리거되는 로딩)에 사용할 수 있는 다양한 로딩 패턴을 살펴보겠습니다.
0.1초 이하
0.1초 이내에 콘텐츠를 로드하는 데 성공하면 이는 즉각적인 것으로 간주되어 사용자에게 눈에 띄지 않습니다.
잘하셨습니다. 결과를 표시해 주세요. 그러나 지루한 작업 흐름의 마지막 단계를 나타내는 작업인 경우 다음 패턴을 고려해 볼 수 있습니다.
가짜 로더 (명확한 경우)
작업에 쏟은 노력에 대해 감사할 수 있는 약간의 호흡 공간을 만들 수 있는 기회입니다. 이는 실제로는 순간적임에도 불구하고 기계가 대규모 작업을 위해 "열심히 작업"하거나 콘텐츠를 저장한다는 인상을 줍니다. ( 여기에서 자세한 내용을 읽어보세요 )
작업 규모에 가장 적합한 지연을 설정하게 되므로 확정적인 진행률 표시기로 간주됩니다. 실행 취소 메커니즘을 제공하는 경우 일반적인 사용자 반응 시간을 고려할 수도 있습니다. 이는 작업을 취소할 수 있는 5초의 시간이 주어지는 이메일을 보낼 때 흔히 볼 수 있습니다.
0.1~1초 사이
이러한 지연은 온라인 소프트웨어에서 예상되는 현상이며 사용자에게는 거의 눈에 띄지 않습니다. 스피너나 애니메이션으로 "그 시간을 채우려고" 하지 마십시오. 사용자가 그렇지 않은 경우보다 더 혼란스러워질 가능성이 있습니다.
" 로드하는 데 1초도 채 걸리지 않는 작업의 경우 반복되는 애니메이션을 사용하면 주의가 산만해집니다. 사용자가 무슨 일이 일어났는지 따라갈 수 없고 화면에 깜박이는 내용에 대해 불안감을 느낄 수 있기 때문입니다." - NN 그룹
1초 이상
1초 표시를 넘기자마자 사용자는 대기 시간을 인지하게 됩니다. 귀하의 옵션을 고려하십시오.
로딩 스피너
전체 페이지 로딩 스피너는 특히 반복되고 불확실하기 때문에 진행 상황을 전혀 제공하지 않으므로 피해야 합니다. 현재 작업이 몇 밀리초 이상 걸릴 것이라는 것을 알고 있다면 다른 로딩 패턴을 사용하는 것을 고려해 보십시오.
그러나 스피너는 더 작은 규모에서도 잘 작동할 수 있습니다. 테이블 행의 내용이나 방금 클릭한 버튼과 같은 보다 간결한 구성 요소에 사용할 수 있습니다.
스켈레톤 로더 화면
고스트 요소(Ghost Element) 또는 그리스화(Greeking)라고도 합니다. 스켈레톤 화면은 불확실하며 전체 페이지 로딩 상황의 새로운 표준입니다. 실제 콘텐츠가 표시되기 전에 와이어프레임 형식의 로딩 화면을 즉시 표시하는 것으로 구성됩니다. 아마도 매일 사용하는 웹사이트와 앱에서 이미 이런 내용을 본 적이 있을 것입니다.
스켈레톤 로딩 화면은 사용자가 기다리는 동안 볼 수 있는 내용을 제공하며, 화면이 전반적으로 어떤 모습일지에 대한 기대치를 설정합니다. 이 로딩 피드백은 로딩 스피너에 비해 모든 공간을 차지하며 전체 로딩 화면입니다.
스켈레톤 화면에 희미한 효과를 추가할 수 있습니다. 추가된 움직임은 사용자의 주의를 기다림에서 벗어나 효과적으로 인지된 기다림을 줄여줍니다.
똑같이 효과적인 애니메이션 장치는 펄스입니다. 또한 일반적인 스피너의 역할과 유사한 역할을 합니다. 주의가 산만해진다고 말할 수도 있습니다.
스켈레톤 스크린의 또 다른 변형은 주요 색상을 사용하는 것입니다. UI가 허용한다면 이미지가 색상 팔레트를 안내하도록 하는 것은 어떨까요? 이는 페이지에 눈길을 끄는 역동성을 가져옵니다.
물론 UI가 주로 텍스트 기반인 경우 임의의 색상을 선택하지 마세요.
2~10초 사이
2초 후에는 더 많은 정보를 제공하는 진행률 표시기 영역으로 들어갑니다. 다음은 몇 가지 옵션입니다.
시간 표시기 (명확한 경우)
개발 측면에서는 로드 시간을 분, 초 단위로 정확하게 예측하기가 어렵습니다. 또한 만족할 것이라고 보장할 수 없는 기대치를 설정하고 싶지도 않습니다. 대신에 "몇 분 정도 걸릴 수 있습니다"와 같은 일반적인 내용을 사용하여 기대치를 설정하고 사용자가 앱을 빠르게 전환하여 다른 것을 확인할 수 있는 좋은 시간인지 결정하도록 하세요.
진행 표시 줄
진행률 표시줄은 선택 사항이며 확정적입니다. 구성 요소 내부와 페이지 수준 모두에서 잘 작동합니다.
🔥 Ease-in 애니메이션을 사용하여 진행이 가속화되는 것처럼 보이게 만드세요.
단계 표시기
사용자의 경우 이는 대기 시간을 더 작은 덩어리로 나눕니다. 각 단계에 소요되는 시간을 정확히 알 수는 없지만 총계를 추정하는 데 도움이 됩니다. 이 패턴은 불확실합니다.
시스템이 여러 항목을 처리하는 경우 완료된 항목 수를 사용자에게 표시합니다.
그렇게 세부적인 가시성이 없거나 사용자와 관련이 없다면 현재 일어나고 있는 일을 설명하는 보다 일반적인 메시지를 사용하세요. “중복 파일 정리 중”, “서버에 연결 중”
💡 프로세스를 완료하는 데 시간이 조금 더 걸리면 사용자에게 작업을 중단할 수 있는 옵션을 제공하여 사용자가 기다려야 하는 상황에 갇힌 느낌을 받지 않도록 하는 것이 좋습니다.
10초 이상
이러한 대규모 작업의 경우 사용자에게 제어권을 부여하고 싶을 것입니다. 얼마나 많은 작업이 수행되었는지에 대한 명확한 가시성 또는 시스템이 계속 작동한다는 보장과 함께 다른 작업으로 전환할 수 있는 기능 등이 포함됩니다. 다음은 몇 가지 옵션입니다.
Percentage Loader (명확한 경우)
퍼센테이지를 표시하면 사용자에게 작업이 완료될 때까지 정확한 시간(분)이 제공되지 않을 수 있지만 전체 기간을 추정하고 이에 따라 조치를 취할 수 있도록 규모에 대한 감각을 효과적으로 제공합니다.
이에 대한 예는 진행률 표시줄이나 원이 채워지는 것입니다.
진행률 99%에서 멈추지 마세요. 작업 기간을 정확하게 예측할 수 없다면 다른 접근 방식을 사용해 보세요. #마이크로소프트
완료되면 알림(대규모 작업) (미정)
더 큰 작업의 경우 "나중에 다시 방문" 유형의 상호 작용을 고려할 수 있습니다. 이것의 큰 이점은 사용자 측에서 인앱으로 인식되는 대기가 전혀 없다는 것입니다.
로딩 시간을 대략적으로 추정할 수 없을 때 유용합니다. 사용자에게 자신의 시간에 무엇을 하는지에 대한 완전한 통제권을 부여하면 사용자는 나중에 중단했던 부분부터 다시 시작할 수 있다고 믿을 것입니다.
알림 자체는 앱 내에서 수행되거나 이메일을 통해 메시지를 받을 수 있습니다.
"백그라운드에서" 실행 중인 작업 (명확한 경우)
대규모 작업을 처리하는 또 다른 방법은 사용자의 작업 흐름을 방해하지 않고 화면의 작은 부분에서 실행 중인 작업의 가시성을 제공하는 것입니다.
이에 대한 좋은 예는 Google 드라이브에 대용량 파일이나 파일 세트를 업로드하는 경우입니다. 시스템은 즉각적인 피드백을 제공하고 앱의 나머지 부분을 탐색할 수 있는 서랍에서 작업을 실행합니다.
즉각적인 피드백, 진행 상황 가시성, 중단 없는 작업 흐름; 완벽한 삼중주!
마무리
명심해야 할 중요한 점은 로딩 상태가 사용자에게 시스템 상태에 대한 가시성을 제공한다는 것입니다. 이를 수행하는 최선의 방법을 결정하려면 데이터가 구조화된 방식, 사용자 워크플로의 컨텍스트, 실행 중인 작업의 인지된 가치를 고려해야 합니다.
로딩 패턴은 본질적으로 다양한 사용자 시나리오를 위한 통신 장치입니다. 이러한 기회를 활용하여 맞춤형 피드백을 제공하고, 브랜드 개성을 불어넣고, 시스템에 대한 신뢰감을 키우십시오.
https://pencilandpaper.io/articles/ux-pattern-analysis-loading-feedback/#wrapping-up
UX Design Patterns for Loading
Loading UX takes careful consideration of both the user's and the system's context to use the appropriate loading pattern.
pencilandpaper.io
