기획 용어 8부, 팝업과 오류 유형 정리

벌써 기획 설계를 위한 기초 용어 시리즈의 8편입니다. 팝업과 오류에 대해 이전 기고에서도 언급한 적은 있지만, 상세한 유형별 개념에 대해 언급하지는 않았습니다. 1년 전 현장에서 주니어급 기획자분께 팝업과 오류의 상세 유형에 대해 문의를 받은 기억이 있습니다. 그래서 한눈에 유형 별 정리를 확인하고, 실제 기획서에 응용하면 좋겠다는 바람에서 이번 글을 준비했습니다.

일반 팝업

서비스에 따라 시스템 팝업 형태로 제공하는 경우도 많지만, 디자인 시스템에 맞추어 레이어 팝업 형태로 제공하는 서비스가 더 성의 있어 보이는 것은 어쩔 수 없습니다. 그렇지만 작업 효율성과 상황에 맞춰 작업하며, 서비스가 고도화되어도 초기의 일관성은 유지할 수 있도록 기준을 명확하게 정의해주시면 좋겠습니다. 

• 문자 입력형

정보를 확인하기 위해 특정 문자의 입력을 요청합니다. 쿠폰번호 입력, 문자 인증, 혹은 성인 인증을 위해 생년월일을 입력해야 하는 등 사용자의 text가 입력되어야 다음 단계로 진행이 가능한 경우가 있습니다. 이런 팝업의 경우, 미입력이나 오류 입력 시에는 다음 프로세스로 진행이 되지 않습니다. 서비스 성격에 따라 인증할 text입력과 동시에 다음 프로세스로 진행되는 경우도 있고, 인증 문자를 입력하고 완료 혹은 확인을 누른 후 다음 프로세스로 진행하는 케이스도 있습니다.

• 선택형

선택 가능한 항목 중에서 특정 항목을 선택합니다. 주소록을 호출한다고 가정해봅니다. 특정 이름은 동명이인으로 다수의 항목이 노출될 수 있습니다. 특정 넘버링 혹은 항목을 터치하거나 말하여 입력합니다. 선택과 동시에 팝업이 종료되며 다음 프로세스로 진행됩니다.

• 의사 결정형

확인 또는 취소 형태로 사용자의 키 액션에 따라 팝업이 종료되며 액션이 수행됩니다. 액션 수행과 동시에 팝업은 종료됩니다. 버튼 두 개 형태의 Confirm창으로 이해하면 되지만, 책에 따라 confirm창을 alert으로 사용하는 경우도 확인했습니다. 

• 확인형

확인 버튼을 선택, 입력함에 따라 팝업이 종료되며 액션이 수행됩니다. 확인 버튼 한 개만 노출되어 Alert 개념 형태로 이해하시면 좋습니다. 

• 편집형

여러 개의 항목 중 선택 또는 이동하여 편집을 하는 용도의 팝업입니다. 사용자 맞춤형 메뉴 화면의 편집 모드를 연상하면 되고, 노출될 메뉴 혹은 아이템(항목)을 삭제 혹은 추가하거나 노출 위치를 변경합니다. 서비스 성격에 따라 팝업으로 제공되지 않고 서브 화면으로 제공해도 무방합니다.

• 토스트 팝업

자동으로 없어지는 팝업으로 어떤 사용자의 키 액션을 요청하지 않습니다. 따라서 버튼은 없으며 기획자는 몇 초 후 토스트 팝업이 사라지는지, 어떤 레이아웃으로 화면에 위치만 정의해주시면 됩니다. 알림 성격으로 사용자에게 노티를 주되, 특별한 키 액션을 필요로 하지 않을 때 사용하면 됩니다. 예외 사례로 통신 장애 같은 오류인 경우, N초 후 사라지는 것이 아니라 고정으로 화면에 노출될 수도 있습니다.  

*디테일한 용어 선택이 필요합니다. 

팝업에도 용어가 사용됩니다. 가장 흔하게 취소, 확인 또는 예, 아니오를 사용하고 있습니다. 이런 용어는 범용적으로 사용되는 예시라 문제가 없다고 생각이 들지만, 타 서비스와 차별성은 느껴지지 않습니다. 예를 들어, 상품 결제 화면에 “결제하시겠습니까”라고 노출되는 팝업에서 확인 버튼을 제공하는 것보다 “결제 확인”이란 용어나 “0,0000원 결제”라는 용어 제공이 사용자 인지성을 돕습니다. 이런 용어를 선택하는 데 있어 특히 금융 파트는 언어가 어렵기 때문에 가이드 매뉴얼도 별도로 존재하는 것 같습니다. 필자도 서비스 설계 시, 가능한 사용자에게 위트 있으나 가볍지는 않고, 직관적인 용어를 사용하기 위해 노력합니다. 

오류의 종류

어떤 서비스는 공통 오류 형태로 사용자에게 피드백을 보냅니다. 그리고 공통 오류 팝업에는 어떤 이유도 분명하게 밝히지 않습니다. 오류의 경우는 많지만 사용자 화면에 동일한 UI로 전달하니 사용자는 오류가 났다는 것만 파악하게 됩니다. 때로는 사용자 화면에서 오류 코드가 노출되기도 하지만, 사용자 관점에서 베스트는 상세한 오류의 원인을 사용자에게 알려주어 기계 혹은 시스템을 올바르게 작동하여 사용할 수 있도록 안내하거나, 위트 있는 문구 혹은 아이템으로 노출하여 불쾌함을 최소화하도록 노력한 서비스입니다. 오류에 대한 디자인은 사용자에 대한 배려심을 엿볼 수 있는 부분이라고 봅니다.

• 네트워크 연결 실패 

네트워크가 연결되어 있지 않거나 사용 중 장애가 발생했을 때 노출됩니다. 공공장소에서 잠시 자리를 비웠다가 다시 돌아왔을 때 공공 WIFI 연결이 끊어질 때가 있습니다. 이런 경우 다시 설정을 해줘야 할 때가 있기도 하고, 네트워크 재연결 시도 없이 계속 사용을 할 수 있는 경우도 있습니다. 오류 알림 피드백이 개선되어 각 케이스마다 적절한 피드백을 줄 수 있기를 바랍니다. 

• 타임 아웃 오류

프로그램 혹은 서비스를 장시간 사용하지 않았을 경우, 시스템을 강제 종료합니다. 대기 시간을 정하는 부분도 기획을 할 때 고려해줘야 할 부분입니다. 타임 아웃에는 여러 오류가 발생할 수 있으며, Connection timeout, Socket timeout, Read timeout, Write timeout, Transaction timeout 등이 있습니다. 

• 토큰 접속 에러

먼저, 토큰(Token)은 보안 인증의 한 방법을 말합니다. 구체적인 예로, 한 플랫폼 서비스에서 특정 서비스의 API 연결이 어려운 경우, 토큰 작업으로 사용자가 별도 회원 인증 없이 아웃링크 후 해당 앱 서비스를 사용 가능하게끔 합니다. 매번 회원 인증이 번거롭기 때문입니다. 토큰 접속 오류는 자바스크립트나 관리자 페이지의 ajax token 혹은 디스크 초과로 일어납니다.

• 디바이스 연결 오류(Connection Error)

여러 디바이스를 사용하는 경우가 많이 있습니다. 개인 PC, 스마트폰, 아이패드, 자동차 AVN, 집의 TV, 스피커 등 한 개인이 다수의 디바이스를 사용 및 연동하다 보면 연결의 오류가 발생할 수 있습니다. 기기를 연결할 때 BT 페어링 연결이 붙지 않는 장애도 발생합니다. 

• 동기화 오류

다수의 디바이스를 한 계정으로 사용하다 보면, 동기화 오류가 발생할 수 있습니다. 특히 유튜브나 넷플릭스 같은 유료 콘텐츠 구독 서비스인 경우, 한 사람이 다수의 계정으로 결제하지는 않습니다. 다른 디바이스에 단일의 ID로 연결 시, 오류가 발생 시에 전원을 종료했다가 재접속을 시도한다거나 얼마간의 텀을 가진 후에 재접속 시 동기화에 성공하는 경우가 많습니다.

• 시스템/서버 에러

서버 연결이 끊어지거나 시스템 자체의 장애로 오류가 발생할 수 있습니다. 이런 경우, 장애 원인을 추적하기 위한 노력이 필요한 것은 물론 서비스 사용이 어려운 사용 불편에 따라 민원이 들어오기도 합니다.  

• 금칙어 오류 

사용자가 금칙어를 입력했을 때 발생하는 오류를 말합니다. 초기 프로덕트가 아닌 어느 정도 고도화된 서비스의 기획 문서를 열어보면, 금칙어의 상세 케이스를 확인할 수 있습니다. 특히 댓글이나 아고라 성격을 가지고 있는 커뮤니티형 서비스에서는 금칙어 지정에 대한 기획이 필수입니다. 

• 데이터 로드 오류

데이터를 호출하는데 오류가 발생할 수 있습니다. 특히 다양한 입력 처리 방법과 디바이스를 연결하는 대형 서비스에서는 호출한 콘텐츠를 불러, 시각적으로 보이는 디스플레이에 노출하는데요. 이때 로딩이 상당히 걸린다거나 결국에 로드하는데 실패하는 경우를 말합니다. 

• 검색 오류

검색 결과가 없는 경우, 지원하지 않는 기능인 경우, 혹은 현재 페이지에서 해당 검색어를 지원하지 않는 경우, (위에 언급했던) 금칙어 입력 검색에 대한 오류 등이 발생할 수 있습니다. AI 음성 검색에서는 무응답 입력 혹은 사람의 말이 아닌 경우, 1차로 오류가 발생했다고 판단하며 사용자의 응답을 다시 요청하는 케이스도 있습니다. 

WRAP-UP

오류의 상태에 따라 “알림”의 형태로만 사용자에게 피드백을 보낼 것인지, 사용자 액션이 필요한 것인지에 따라 다른 형태의 팝업이나 UI를 적용해야 합니다. 특히 “오류”라는 것은 사용자 입장에서 불쾌할 수밖에 없는 경험이라 불만족스러움을 줄이기 위한 모든 노력을 다해야 할 것입니다. 보통 기획을 할 때는 프런트 기획만을 생각하는 경우가 많습니다. 모바일의 프런트 기획을 할 때, UI 그림만 그리는 것은 누구나 가능한 일입니다. 모바일 사용자 화면은 사용자로서도 이미 익숙하기 때문입니다. 그러나 그것만으로 타 업계에서 이 일을 전문성이 있는 일이라고 말하진 않겠죠. 디바이스 별로 나올 수 있는 갖가지 세부적인 오류 케이스의 확인은 실전에서만 경험할 수 있습니다. 욕심 많은 주니어 기획자라면 플랫폼을 통해 많은 프로젝트를 시도해보는 것을 추천드립니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.