대기 UX
대기 UX (Wait UX)
대기 UX(Wait UX)는 지연이 발생하는 순간, 즉 시스템이 데이터를 처리하거나, 로딩하거나, 검색하는 동안의 사용자 경험 설계를 말해요. 이런 순간을 잘 처리하지 않으면 좌절, 이탈, 신뢰 상실로 이어질 수 있어요. 잘 설계된 대기 경험은 명확하게 소통하고, 사용자 맥락을 유지하며, 인지된 지연을 최소화해요. 이 프레임워크는 Copilot 같은 AI 우선 경험과 Microsoft 365 전반의 전통적인 생산성 시나리오 모두에 적용돼요.
출처: 문서
본문
원칙 (Principles)
명확하고 정직하게 소통하기 (Communicate clearly and honestly)
사용자는 항상 무슨 일이 일어나고 있는지, 그리고 왜 그런지 알아야 해요. "Uploading photo …(사진 업로드 중 …)"이나 "Loading dashboard …(대시보드 로딩 중 …)" 같은 설명적 라벨은 불확실성을 줄이고 신뢰를 쌓아요. 가능한 한 정확하고 설명적인 메시지를 사용하세요. 가능하면 실제 진행 상황을 보여주는 결정적(determinate) 지표를 사용하세요. 진행 상황을 측정할 수 없다면 짧은 대기에서만 비결정적(indeterminate) 지표를 사용하세요.
무슨 일이 일어나고 있는지 명확하게 전달하는 설명적 라벨
무슨 일이 일어나고 있는지, 얼마나 걸리는지 알려주지 않는 지표
인지된 성능 최적화하기 (Optimize perceived performance)
시각적 피드백은 지연의 인지된 시간을 줄일 수 있어요. 마이크로 인터랙션, shimmer 효과, 스켈레톤 화면은 대기 시간에서 주의를 돌리고 시스템이 작동 중이라는 것을 안심시켜줘요. 빈 화면이나 정적 로더는 피해야 해요. 1초 미만의 짧은 대기에서는 어떤 애니메이션도 보여주지 마세요. 사용자를 혼란스럽게 할 수 있으니까요.
콘텐츠 로딩을 위한 shimmer가 있는 스켈레톤 화면
피드백이 없는 빈 화면
맥락 유지와 동시 피드백 제한하기 (Maintain context and limit simultaneous feedback)
내비게이션이 절대적으로 필요하지 않는 한, 대기 상태 동안 사용자는 같은 뷰에 머물러야 해요. 피드백은 가장 관련 있는 콘텐츠나 동작과 연결되어야 하고, 여러 지표가 주의를 두고 경쟁해서는 안 돼요. 이렇게 하면 사용자가 집중을 유지하고 인지 부하를 줄여요.
사용자의 동작에 연결된 하나의 진행 토스트
화면에 흩어진 여러 스피너
시각적 패턴 (Visual patterns)
스피너 (Spinner)
스피너는 일반적으로 3초 미만의 짧고 비결정적인 대기에 가장 좋아요. -ing 동사를 사용하고 타원(ellipsis)으로 끝나는 짧은 라벨과 함께 제공되어야 해요. 계속 진행 중임을 나타내기 위해서죠. 예로 "Loading …(로딩 중 …)", "Connecting …(연결 중 …)", "Retrieving …(검색 중 …)"이 있어요. 적절한 서식을 보장하려면 타원 앞에 끊김 없는 공백(nonbreaking space)을 사용하세요.
타원 앞에 끊김 없는 공백이 있는 "Searching …(검색 중 …)" 라벨의 스피너.
진행 바 (Progress bar)
진행 바는 진행 상황을 추적할 수 있는 더 긴 대기에 이상적이에요. 진행 중인 작업을 나타내는 라벨을 바 위에 포함하고, 선택적으로 기대를 설정하는 상태 메시지를 아래에 포함해야 해요. 예를 들어 "Applying settings …(설정 적용 중 …)" 뒤에 "Estimated time: 1 minute(예상 시간: 1분)"이 올 수 있어요. 기다리지 않으면 결과가 있다면, 복구 지침을 포함하세요.
상단 라벨: "Uploading file …(파일 업로드 중 …)" | 하단 상태: "30% complete – about 20 seconds remaining(30% 완료 – 약 20초 남음)"
스켈레톤 (Skeleton)
스켈레톤 화면은 콘텐츠 렌더링 지연에 유용해요. Copilot 같은 AI 우선 경험에서는 Copilot 그라데이션 shimmer를 사용해 테마를 강화하고 콘텐츠가 로딩 중임을 안심시켜줘요.
shimmer 효과와 Copilot 테마가 적용된 스켈레톤 카드
토스트 (Toast)
진행 토스트는 현재 콘텐츠에 영향을 주는 긴 백엔드 프로세스에 적합해요. 뷰에 머물지 않고 다른 작업을 방해하지 않으면서 진행 상황을 모니터링할 수 있게 해줘요. 명확한 라벨과 상태 업데이트를 포함해야 해요.
라벨: "Generating report …(보고서 생성 중 …)" | 상태: "Estimated time: 1 minute(예상 시간: 1분)"
모스 부호 (Morse code)
모스 부호 애니메이션은 AI 우선, Copilot 시나리오에서 특별히 사용돼요. 사람 간 채팅 경험의 타이핑 점 애니메이션을 흉내 내면서, AI를 의인화하지 않는다는 우리의 책임 있는 AI 원칙에 부합하게 기계적인 느낌의 균형을 맞춰요.
펄스 점 (Pulsing dot)
펄스 점 애니메이션은 Chain of Thought에서 더 가벼운 대기 애니메이션으로 사용돼요.
동작 (Behavior)
시간 임계값 (Timing thresholds)
대기 지표를 표시할 때 시간 간격을 고려하는 것이 중요해요. 대기가 1초 미만이면 지표를 표시하지 마세요. 화면의 번쩍임이 사용자를 혼란스럽게 할 수 있으니까요. 1초에서 3초 사이의 대기에는 스피너가 적합해요. 대기가 3초를 초과하면 진행 바로 전환하거나 콘텐츠 문자열을 표시해 프로세스가 활성 상태임을 안심시켜주세요. AI 채팅 시나리오에서는 대화 흐름을 유지하기 위해 응답 지표가 즉시 나타나야 해요.
폴백 메시징 (Fallback messaging)
진행 세부 사항을 사용할 수 없을 때 폴백 메시지는 여전히 안심을 제공해야 해요. "Working on it …(작업 중 …)"이나 "Getting things ready …(준비 중 …)" 같은 일반적이지만 유익한 문자열을 사용해 시스템이 활성 상태임을 나타내세요. 이 메시지는 타이밍을 예측할 수 없는 대화형 AI 경험에서 특히 유용해요.
하드코딩 vs 생성 문자열 (Hardcoded vs. generated strings)
Outlook 같은 생산성 앱에서 하드코딩된 문자열은 일관성과 명확성을 보장해요. AI 채팅 경험에서는 동적으로 생성된 문자열이 더 개인화되고 맥락 인식적인 피드백을 허용해요. 두 접근 모두 생태계 전반의 응집력을 유지하기 위해 같은 콘텐츠 원칙을 따라야 해요.
접근성 (Accessibility)
대기 지표가 모든 사용자에게 접근 가능한지 확인하세요. ARIA 라벨을 사용해 상태 변경을 알리세요. 예를 들어 role="status", 그리고 끊김 없는 공백을 사용해 타원을 올바르게 서식 지정하세요. 이렇게 하면 화면 읽기 도구가 현재 상태를 정확하게 전달할 수 있어요.
콘텐츠 패턴 (Content patterns)
라벨링 (Labeling)
진행 중 상태에는 -ing 동사를, 완료 상태에는 과거형을 사용하세요. 예를 들어 "Uploading file …(파일 업로드 중 …)"은 프로세스가 활성 상태임을 전달하고, "File uploaded(파일 업로드됨)"는 완료를 확인해요. "File is being uploaded(파일이 업로드되고 있습니다)" 같은 수동태 구성은 비인격적이고 불명확하게 느껴질 수 있으니 피하세요.
진행 중 상태에는 짧은 -ing 동사 사용하기 (Use short -ing verbs for in-progress states)
수동태 구성 피하기 (Avoid passive constructions)
간결성 (Conciseness)
메시지는 짧고 직접적이어야 해요. 이상적으로는 한 구절이나 문장 조각이에요. 이렇게 하면 불필요한 세부 사항에 압도되지 않고 사용자가 무슨 일이 일어나고 있는지 빠르게 이해할 수 있어요.
대기 메시지를 짧게 유지하기 (Keep wait messages short)
불필요한 세부 사항 피하기 (Avoid unnecessary detail)
기대 설정 (Setting expectations)
비(非)AI 시나리오에서는 가능하면 예상 시간을 포함해 사용자가 다음 단계를 계획하도록 도와주세요. 예를 들어 "About 30 seconds remaining(약 30초 남음)"은 명확한 기대를 설정해요. 대화형 AI 시나리오에서는 시간을 추정하는 것보다 프로세스가 여전히 활성 상태임을 나타내는 것이 더 중요할 수 있어요.