공지: 번역이 매끄럽지 않은 부분이 있다면 지적해 주시기 바랍니다. 원문 링크: Response Times: The 3 Important Limits, 감사합니다.
《Usability Engineering》 제5장(1993년)에서 발췌
응답 시간에 관한 가장 기본적인 권고 사항은 지난 30년 동안 변하지 않았습니다(1968 ~ 1991):
0.1초: 사용자가 시스템이 즉각적으로 응답하고 있다고 느끼는 한계입니다. 이는 결과를 표시하는 것 외에 특별한 피드백이 필요하지 않음을 의미합니다.
1.0초: 사용자의 사고 흐름이 유지되는 한계입니다. 비록 사용자가 지연을 느낄 수는 있지만요. 일반적인 경우 0.1초~1.0초의 지연에 대해 특별한 피드백을 제공할 필요는 없지만, 사용자는 데이터를 직접 조작하는 유연함을 잃게 됩니다.
10초: 사용자의 주의가 대화에 집중될 수 있는 한계입니다. 지연이 이보다 길어지면 사용자는 기다리는 동안 다른 작업을 수행하고 싶어 하므로, 작업이 완료되었을 때 반드시 피드백 알림을 주어야 합니다. 지연 시간 동안의 피드백은 매우 중요합니다. 응답 시간이 크게 요동칠 경우 사용자는 무엇을 해야 할지 알 수 없기 때문입니다.
일반적으로 응답 시간은 가능한 한 빨라야 하지만, 컴퓨터의 응답 속도가 너무 빨라 사용자가 반응하지 못하는 상황이 발생할 수도 있습니다. 예를 들어, 리스트가 너무 빨리 스크롤되어 대상 요소가 화면에 나타났을 때 멈추지 못하는 경우입니다. 실제로 컴퓨터는 UI 변화를 매우 빠르게 표현할 수 있으므로, 애니메이션은 컴퓨터의 처리 속도가 아닌 시계 시간(clock time)을 기준으로 타이밍을 맞춰야 합니다. 더 빠른 컴퓨터가 보급되더라도 UI는 사용성을 유지해야 하기 때문입니다.
컴퓨터가 즉각적으로 응답할 수 없는 경우, 백분율 완료 표시기(Myers 1985)의 형태로 사용자에게 지속적인 피드백을 제공해야 합니다. 소요 시간이 10초를 초과하는 작업에는 백분율 진행 표시기를 사용해야 한다는 것이 황금률입니다. 진행 표시기에는 세 가지 주요 장점이 있습니다. 첫째, 시스템이 다운된 것인지 아니면 작업을 수행 중인지에 대한 사용자의 의구심을 없애줍니다. 둘째, 사용자가 기다려야 할 시간을 적절히 알려주어 긴 대기 시간 동안 다른 일을 할 수 있게 합니다. 셋째, 시각적 피드백(최소한 기다려야 한다는 표시)을 제공하여 지루한 대기 시간을 조금이나마 견디기 쉽게 해줍니다. 마지막 장점을 과소평가해서는 안 되며, 이것이 숫자로 표시된 남은 시간 대신 그래픽 프로그레스 바를 권장하는 이유입니다.
소요 시간을 미리 예측할 수 없는 작업의 경우 백분율 완료 표시기를 사용할 수 없지만, 작업 완료에 걸리는 절대적인 시간을 기준으로 진행 피드백을 제공할 수는 있습니다. 예를 들어, 시스템이 개수를 알 수 없는 원격 데이터베이스를 검색하고 각 데이터베이스의 이름을 출력하는 과정이 그렇습니다. 이마저도 불가능하다면 마지막 수단은 회전하는 공, 화면을 날아다니는 바쁜 꿀벌, 상태 표시줄의 점들 또는 시스템이 작동 중임을 나타낼 수 있는 구체적이지 않은 진행 표시기를 사용하는 것입니다. 무엇을 하고 있는지 보여주지 못해도 괜찮습니다. 이 기사의 웹 버전에 추가된 노트: 대부분의 웹 브라우저는 전체 페이지 다운로드 완료 백분율을 표시하지 않기 때문에 유용한 프로그레스 바를 제공하지 못하고 있습니다.
2초에서 10초 정도 소요되는 비교적 빠른 작업의 경우 백분율 표시기를 사용하는 것은 과해 보일 수 있습니다. 실제로 프로그레스 바를 표시하는 것은 표시 관성(화면에 변화가 너무 빨리 나타나면 사용자가 평온함을 유지하지 못하거나 스트레스를 느낌) 원칙에 어긋납니다. 이럴 때는 덜 두드러지는 진행 피드백을 제공할 수 있습니다. 일반적인 해결책은 '바쁨' 커서 모양과 화면 하단의 작은 영역에 빠르게 변하는 숫자를 조합하여 얼마나 완료되었는지 표시하는 것입니다.
함께 보기:
website response times 및 응답 시간을 개선하는 방법에 관한 기사
웹 기반 애플리케이션의 응답 시간
2014년 업데이트: 유사한 질문을 다시 받아 여기서 답변하기로 했습니다.
Q: "응답 시간이 중요하다는 점을 여러 번 언급하셨고 응답 시간을 측정하는 도구도 많지만, 웹 기반 애플리케이션의 응답 시간은 어느 정도가 적절한가요? 쇼핑 경험을 제외하고 대화형 애플리케이션만 놓고 본다면 사용자의 인내심(상한선)은 어느 정도입니까?"
A: 저는 '웹 기반 애플리케이션'이라는 용어가 완전히 사라지기를 바랍니다. 왜냐하면 이 용어는 애플리케이션 UI 디자인(우리는 이 주제로 며칠 동안 강의를 진행합니다)의 실제 문제를 흐리기 때문입니다. C++나 JavaScript로 구현된 애플리케이션을 위한 별도의 가이드라인은 존재하지 않습니다. 기본적인 사용성 권고안은 구현 방식과 상관없이 동일합니다. 우리가 논의하는 것은 코딩이 아니라 사용자 경험이기 때문입니다.
따라서 웹 기반 애플리케이션의 응답 시간 가이드라인은 다른 모든 애플리케이션과 동일합니다. 이 가이드라인은 나온 지 46년이 되었으며, 신기술이 등장한다고 해서 바뀔 가능성은 희박합니다.
0.1초: 사용자가 UI 객체를 직접 조작하고 있다고 느끼는 감각의 한계입니다. 예를 들어, 사용자가 표의 열을 선택했을 때 해당 열이 하이라이트 되거나 선택되었다는 피드백이 사용자에게 전달될 때까지의 간격입니다. 이상적으로는 열 정렬에 대한 응답 시간도 이 정도여야 합니다. 이 경우 사용자는 자신이 직접 표를 정렬하고 있다고 느끼게 됩니다.
1초: 사용자가 과도하게 기다리지 않고 컴퓨터 명령 공간에서 자유롭게 작업할 수 있는 감각의 한계입니다. 0.2초~1.0초의 지연은 사용자가 알아차릴 수 있는 수준이며, 따라서 컴퓨터가 명령을 '처리 중'이라고 느끼게 됩니다. 이는 사용자 행동에 즉각적으로 반응하는 명령과는 구별됩니다. 예를 들어, 선택한 열을 기준으로 표를 정렬하는 작업을 0.1초 이내에 완료할 수 없다면 반드시 1초 이내에 완료해야 합니다. 그렇지 않으면 사용자는 UI가 느려졌다고 느끼고 작업 수행 중의 '흐름(flow)' 경험을 잃게 됩니다. 1초를 초과하는 지연의 경우 커서 모양을 바꾸는 등의 방법으로 컴퓨터가 문제를 해결 중임을 사용자에게 알려야 합니다.
10초: 사용자가 작업에 집중할 수 있는 한계입니다. 10초를 초과하는 모든 작업에는 백분율 진행 표시기가 필요하며, 사용자가 작업을 쉽게 중단할 수 있도록 명확하게 표시된 방법이 제공되어야 합니다. 사용자가 10초 이상의 지연을 겪은 후 원래 UI로 돌아오면 다시 적응해야 할 것입니다. 사용자의 업무 흐름에서 10초 이상의 지연은 작업을 전환하는 것과 같은 자연스러운 중단 시점에만 허용될 수 있습니다.
아직 댓글이 없습니다