누구를 위하여 팝업은 울리나
애플리케이션과 게임을 서비스하기 위해 테스트하고 사용하는 과정에서 에러가 발생하면 우리는 위와 같은 에러 팝업을 마주하게 됩니다.
테스트 진행 중 에러 팝업이 발생하면 이를 이슈로 분류하고 BTS에 등록을 합니다. 이후 수정이 가능한 이슈는 수정을 진행하여 해당 에러의 발생 원인을 제거합니다. 하지만 네트워크 단절, 계정 오류 등 라이브 환경에서 피할 수 없이 발생하는 에러는 해당 서비스의 전체 콘셉트와 어울리게 디자인된 에러 팝업으로 사용자에게 제공됩니다.
이렇게 우리가 라이브 환경에서 사용자에게 제공하는 에러 팝업의 퀄리티에 대해 이야기해 보고자 합니다.
처음 예시처럼 최근 우리의 에러 팝업은 상당히 심플합니다. 보통 'Error'라는 텍스트를 포함하고 해당 에러와 매칭 되는 숫자와 확인 버튼을 제공합니다. 이러한 에러 팝업을 마주하고 확인 버튼을 선택하는 사용자는 어떠한 생각과 경험을 하게 될까요?
잠시 다른 상황의 예시를 통해 생각해 보겠습니다.
여기에 두 종류의 임베디드 운영체제가 있습니다.
두 OS에서 동일하게 메모리 누수 이슈가 발생하여 활성화 상태의 기본 애플리케이션이 종료가 되는 현상이 발생하였습니다. 동일한 원인으로 발생한 이슈이지만 두 OS는 사용자에게 다른 현상을 제공합니다.
1번 OS: 애플리케이션이 종료되면서 팝업을 호출하고 해당 팝업에 발생한 에러 번호를 포함한 상세 정보와 로그를 출력하여 사용자에게 제공.
2번 OS: 애플리케이션이 종료되지만 별도로 사용자에게 제공하는 팝업 및 정보 없음.
이렇게 정 반대의 현상을 제공하는 상황에서 어떤 OS가 사용자에게 좀 더 긍정적인 반응을 보일 수 있을까요?
이에 대한 정답은 없습니다. 이는 사용자의 환경과 성향에 따라서 매우 다르기 때문이며, 사용자에 따라서 두 현상 모두 장단점이 있습니다.
조금은 극단적인 분류로 두 명의 사용자 관점을 가정해서 생각해 보겠습니다.
우선 두 OS를 만든 사람은 개발자입니다. 개발자의 관점에서 에러가 발생하는 경우 당연히 에러 코드와 함께 상세 정보가 제공되어야 합니다. 그래야 원활하고 빠르게 디버깅을 할 수 있기 때문입니다.
하지만 개발과 큰 관련이 없는 일반 사용자의 관점에서는 어떨까요?
당최 무슨 소리인지 모르겠고 이해가 불가능한 텍스트가 빨간색 X 표시와 함께 팝업으로 출력된다면 어떠한 생각이 들까요? 거기에다가 난생처음 보는 영어 단어로 말이죠.
마치... 출근길 지하철 역 앞에서 얼핏 고양이가 그려진 전단지를 나눠주길래 무심히 받아서 ‘회사 근처에 펫 샵이나 고양이 카페가 새로 생겼나?’ 하고 자세히 봤더니 양자역학에 대한 논문이었을 때의 느낌일 듯합니다.
단순히 무슨 소리인지 모르겠다는 느낌 정도면 다행일 수도 있습니다. 사용자에 따라서 빨간색 X 표시는 ‘내가 무언가 잘못 조작해서 고장이 난 건가?’ 하는 두려움이 생기는 경우도 있습니다.
물론 이 두 사용자의 예시는 상당히 극단적인 분류의 관점이며, 아무런 안내 없이 종료가 된 현상이 팝업 호출보다 긍정적이라는 이야기 또한 아닙니다. 결론은 바로 사용자가 불안하거나 이해가 불가능한 정보가 아닌 충분한 이해와 대응이 가능한 정보의 제공이 필요하다는 생각입니다.
그렇다면 우리는 에러 팝업을 통해 어떠한 정보를 사용자에게 제공을 해야 될까요? 발생 에러에 대한 상세한 정보? 해설? 또한, 사용자가 충분히 이해가 가능한 정보는 어떠한 정보이며 어느 정도의 정보가 이해가 가능할까요?
모바일 단말기가 대중적으로 출시된 초기와는 다르게 현재는 모바일 장치와 이에 사용되는 OS는 이제 사용자에게 익숙한 환경이 되었습니다.
이러한 상황에서 게임 사용자의 경우 에러 팝업 발생 시 단순히 에러 번호뿐만 아니라 사용하는 단말기의 모델명, OS 정보, 계정 정보, 발생 시간, 발생 상황, 스크린숏과 동영상 등 QA가 테스트 중 발생한 이슈를 BTS에 등록할 때만큼 상세한 정보를 포함하여 문의를 진행하는 사용자도 있습니다.
가끔 ‘이 사용자는 혹시 다른 회사의 QA가 아닐까?’라는 생각이 들 정도입니다.
물론 이 예시 또한 일부 사용자의 경우이며 이러한 사용자는 기존에 다수의 게임 서비스를 사용하며 에러 발생으로 인한 문의 접수를 통해 에러 번호 외 이러한 정보가 필요하다고 반복 학습이 된 상황입니다. 이와 함께 관련 커뮤니티와 같은 제3의 정보 제공처를 통해 문의 접수 시 이와 같은 정보 제공이 필요하다는 학습 또한 진행이 되고 있습니다. 결론적으로 사용자의 이해도는 점점 더 높아지고 있지만 그렇다고 모든 사용자의 이해도가 높다고 할 수도 없는 상황입니다.
여기서 잠시 우리가 서비스하는 애플리케이션이 아닌 다른 분야를 한번 살펴보겠습니다.
우리가 일상생활에서 일반 가전제품 사용 중 에러가 발생하면 장비에 부착된 7 세그먼트 표시장치를 통해 에러 넘버를 보여줍니다. 사용자는 동봉된 매뉴얼을 통해 발생한 에러 넘버를 확인하고 스스로 수정이 가능한 부분은 수정을 하고 그렇지 않은 경우에는 A/S를 접수합니다. 한두 자리의 숫자 표시만 가능한 디스플레이와 동봉된 매뉴얼을 활용하여 사용자에게 필요한 정보를 제공하고 이를 통해 불편을 해소하며 사용자의 경험을 긍정적인 방향으로 개선하고 있습니다.
반면 우리가 서비스하는 모바일 단말기는 일반 가전제품과는 비교가 불가능할 정도의 월등한 해상도를 기반으로 숫자뿐만이 아닌 텍스트와 이미지, 영상, 사운드 재생, 심지어 네트워크 연결까지 가능한 환경입니다. 하지만 이러한 환경에서 매뉴얼 조차 동봉하지 않은 채로 단순히 한두 자리의 숫자 정보만 사용자에게 제공하고 있지는 않은지 생각해 보게 됩니다.
다시 우리의 애플리케이션과 게임으로 돌아와 보겠습니다. 우리의 제품에서 에러 팝업은 해당 이슈와 매칭 되는 번호를 사용자에게 제공하고 있습니다.
기능 테스트의 영역으로 본다면 이러한 팝업은 아무런 이슈도 없는 상태입니다.
에러 발생 시 예약된 팝업을 호출하고 해당 팝업 내 에러 코드를 출력하는 기능이 정확히 작동을 하기 때문입니다.
하지만 퀄리티. 바로 UI/UX 퀄리티의 관점에서 본다면 사용자에게 충분히 이해 가능한 정보 전달이 수행되지 않았습니다. 따라서 결과적으로 사용자에게 만족스러운 경험을 전달하지 못하는 이슈가 발생했습니다.
바로 UX 퀄리티에 이슈가 있다고 판단됩니다.
일반적으로 UI/UX와 같은 디자인의 영역은 사람의 취향과 생각이 다양한 만큼 테스트가 불가능하거나 결과가 모호하다고 여겨지고 있습니다.
하지만 정말 테스트가 불가능한 항목일까요? UI/UX는 테스트가 가능하지도, 불가능하지도 않은 항목이라고 생각합니다. 좀 더 정확히 말하자면 가능한 항목이 있고 불가능한 항목이 있다고 할 수 있겠습니다.
바로 서비스를 사용하는 사용자 경험(User eXperience)입니다.
우리는 개발에 속해 있지만 항상 사용자의 입장과 관점에서 생각하며, 개발과 사용자를 연결하는 다리 역할을 한다고 말합니다. 개발 상황과 사용자의 입장을 충분히 이해하면서 상황과의 타협을 경계하고 우리가 퀄리티를 만들 수 있는 영역을 찾아가는 과정을 지금 테스트하고 있는 제품에서 발생한 에러 팝업을 BTS에 등록하고 수정을 요청하며 생각해 보고자 합니다.
사용자의 입장에서 팝업에 필요한 정보는 무엇인지 생각하며, 이와 함께 오류 팝업을 기반으로 해당 이슈를 빠르게 해결하기 위한 내부 개발 프로세스는 무엇인지도 함께 말입니다.
또한 지금까지 우리가 스스로도 이해하지 못하는 팝업을 사용자가 이해하도록 강요하고 있는 것은 아닌가 하는 생각도 해 봅니다. 사용자와 개발자 모두 만족할 수 있는 상황을 만들 수 있다면 매우 좋겠지만 두 마리의 토끼를 모두 잡으려다 놓치는 것보다는 최소한 UI/UX의 앞글자. 즉 사용자(User)의 입장과 관점에서 긍정적인 경험을 가져올 수 있는 방법에 대한 부분을 말이죠.
끝으로 에러 팝업에서 제공하는 정보뿐만 아니라 메뉴 간 일치되지 않는 명칭, 무심코 사용되는 개발 용어, 쉽게 노출되는 시스템 텍스트 등 우리가 찾을 수 있는 퀄리티의 영역이 아직 많이 남아 있습니다.
우리는 우리의 생각보다 많은 영역에서 퀄리티를 찾고 만들어 낼 수 있는 QA입니다.