UX 개선
앱을 실행시켰을 때 내가 원하는 이벤트가 작동이 안 되고 기다리게 되는 경우가 생긴다. 이와 같이 어떤 이벤트가 실행이 안되고 기다리게 되는 상황을 로딩중이라고 하고 우리는 서비스를 이용할 때 종종 로딩을 마주하게 된다.
재밌는 사실은 사용자들이 로딩을 기다리는 최대의 한계점이 바로
3초라고 한다.
구글 리서치 자료에 따르면 모바일 웹 사이트의 로딩 시간이 3초 이상일 때 32%, 5초 이상은 90%, 6초 이상은 106% 마지막으로 10초가 넘으면 123%의 이탈률이 발생한다고 한다.
이미지 출처: Google / SOASTA Research, 2017
위와 같은 자료에서 증명하듯 로딩 시간이 길어지게 되면 사용자에게 답답함과 지루함을 주게 되며, 오류가 발생한 것 같은 생각이 들게 하기도 한다.
그렇다면 로딩 시간을 단축하면 되지 않나 !?
하지만 시간을 단축시키는건 쉽지 않다. 항상 최선의 로직으로 코드를 작성하려고 노력 했음에도 불구하고 로딩시간이 생기기 때문이다. 그래서 디자인적으로 개선할 방법이 필요한 것이다. 비슷한 예시를 생각해보면 이해하기에 더 쉬운데,
엘리베이터가 올라가는 동안 속도가 너무 느리다며 불평하는 사람들을 위해 엘리베이터를 빠르게 개선 한 것이 아닌 엘리베이터 안에 거울을 설치 하여 이용객들의 불만도를 현저히 줄인 경우가 있다.
로딩 페이지도 이와 같이 로딩페이지를 만들어 답답함과 지루함을 해소시켜주기 위한 디자인적 요소를 적용하곤 한다.
그래서 우린, 로딩중 일 때 디자인적 요소를 로딩페이지에 추가하였고 그는 다음과 같다.
스피너 로딩은 무한 루프 애니메이션으로 계속해서 반복되는 로딩이다.
대부분의 스피너 로딩은 짧은 로딩 시간에 사용 되곤 한다.
실제 프로젝트에서는 로그인 후 로딩이 될 때 위와 같은 스피너 로딩을 활용하였다.
프로그래스 바 로딩은 스피너 로딩과 다르게 시각적으로 남은 시간의 정보를 보여주곤 한다. 이것은 로딩이 어느 정도 남았는지 이미지를 통해 짐작할 수 있다.
하지만 진행 시간이 어느정도 됐는지에 대한 정확한 수치 정보를 기입해놓지 않을 경우 얼마나 기다려야 하는지 가늠만 할 수 있기 때문에, 정확한 수치정보와 함께 기입해주면 사용자에게 안심을 주며 더 좋은 프로그래스 바 로딩을 만들 수 있다.
스캘레톤은 빈 화면 대신에 다음 화면에 나올 것을 미리 보여주는 로딩이다.
위에서와 같이 board로 페이지 이동을 선택하면 card가 나오기 전 card의 모습들을 보여준다.
스캘레톤은 앞서 말한 스피너 로딩과는 달리 다음에 나올 화면을 보여주면서 대기시간이 아닌 진행상황에 집중 할 수 있는 로딩이다.
주로 이미지가 보여지는 페이지위에서는 스캘레톤 로딩을 사용한다.
프로젝트에 적용한 애니메이션은 이 정도 이지만
이 외에도
브랜드 아이덴티티를 담은 로딩이나
배달의 민족 앱 홈 화면에서 새로고침을 할 때 마다 나오는 로딩 화면 처럼
다양한 로딩 화면이 존재한다.
어떤 책에서는 ‘물리적인 시간과 거리는 정확하게 예측하고 계산할 수 있지만 기다림에 대한 사람들의 인식은 물리학이 아닌 심리학의 지배를 받는다.’ 라고 했다.
때문에 우리는 사용자들이 불편을 느끼지 않게 하기 위해선 체감상 로딩이 빠르게 되는 것 같은 속임수를 줘야한다.
로딩과 관련된 재밌는 테스트가 하나 시행되었는데, 어떤 로딩 화면이 제일 빠르게 느껴졌는지에 관해 설문조사를 한 테스트였다.
결과를 말해보자면,
빠른 속도보단 느린 속도의 애니메이션,
펄싱(pulsing) 애니메이션 보단 웨이브(wave) 애니메이션을 사용했을 때
기다리는 체감속도가 빠르다고 느꼈고,
방향도 영향을 받았는데
왼쪽에서 오른쪽으로 보여주는 것이 로딩 시간이 더 짧게 느껴졌다고 한다.
우리는 모든 로딩이 발생할 때 현재 프로젝트에서 적용한 2가지 종류의 로딩 요소들을 넣는 다고 해서 모두 다 알맞게 적용되는 것이 아니다. 사용하고자 하는 환경, 상황, 목적에 맞게 알맞은 방법으로 로딩을 사용해야 한다.
- 사용자가 오류라고 받아들이지 않는 시간인 ‘3초’ 의 로딩 시간을 사용
- 계속 반복되는 로딩의 특성을 고려하여 시작과 끝이 자연스럽게 이어지도록 주의하며 제작.
- 브랜드의 아이덴티티 적용
다음과 같은 3가지 요소들을 잘 고려하여 또 다른 로딩현상이 발생할 때 상황에 맞는 디자인적 요소를 적용하는 일은 서비스를 사용하는 사용자들을 위해서 중요한 요소라고 생각한다.
https://blog.rightbrain.co.kr/?p=12479
사용자가 원하는 대로 어떠한 작업이 실행되지 않았을 때 우리는 사용자에게 에러 메세지를 제공해주곤 한다.
에러 메세지를 써줘야 할 때 알아둬야 할 원칙들이 있는데 프로젝트를 진행하며 고안한 점과 함께 병행하여 이야기 해보도록 하겠다.
원칙들에 대해 말하기 전 모든 에러 메세지에는 공통적으로 중요시 여겨져야 할 부분이 존재한다.
상황을 예를 들어보자.
로그인을 하기 위해 아이디를 입력하고 패스워드를 입력했는데, 에러메세지에
‘로그인이 실패하였습니다.’
라는 문구만 뜨고 계속해서 로그인이 안된다고 생각해보자.
로그인 중에 에러가 생기는 이유는 다양할 것이다. 아이디 오류 / 비밀번호 오류 / 보안 오류 / 혹은 서버 내부 오류 등 이렇게 많은 이유중에 로그인이 실패하였다는 정보만 계속해서 제공해주면 해결할 방법을 찾기 어려울 것이다.
에러 메세지를 쓸 때 가장 중요한 것은 Navigating, 즉 ‘사용자가 다음 단계로 무엇을 해야 할지 안내하고 있는가’ 이다. 좋은 에러 메세지에는 다음과 같은 내용들이 포함되어야 한다.
- 지금 사용자가 어떤 상황에 처했는지(상황 설명)
- 그것이 왜 발생했는지(이유)
- 해결하려면 어떻게 해야하는지(해결책)
이 내용을 녹여내면서, 사용자가 다음 단계로 잘 갈 수 있게 돕는 에러 메세지 원칙 6가지에 대해 이야기를 시작해보도록 하겠다.
에러가 발생할 만한 요소들을 처음부터 보여지지 않게 하는 것이라고 설명하면 이해가 쉬울 것 같다.
토스에서의 한 서비스를 예로 들어보자면, 스스로 송금하는것은 계좌로만 가능하기 때문에 연락처 송금을 쓸 수 없다고 한다.
사용자가 연락처로 송금을 진행했을 때 에러 문구를 띄우는 것이 아니고, 처음부터 내 연락처를 연락처에 띄우지 않는 방법을 써서 에러 메세지를 띄우지 않는 방식을 선택했다고 한다.
에러 메세지를 생성하기 전에 항상 생각해야하는건 이 에러가 꼭 있어야 할까? 이다.
충분히 설명이 필요한 상황인데 다이얼 로그를 쓰지 않고 toast로 짧게 전달하여 오해를 불러 일으키는 경우가 있다.
예를 들어
코넥트 홈페이지에서 사용자의 필수 정보를 입력하는 모달창이 존재하는데, 사용자의 닉네임이나 슬로건은 필수로 입력해줘야하는 정보이다.
따라서 닉네임이나 슬로건을 입력해주지 않았을 경우엔 해당 text를 작성해주라는 설명과 함께 에러 메세지가 뜨게 끔 제작해두었다.
공급자는 매번 에러를 해결 해 줄 수 없다. 서비스를 사용하며 발생한 간단한 에러는 사용자 스스로 해결을 해야 한다. 그래서 에러 메세지에 설명을 함께 적어주는 것이 중요하다.
예를 들어 코넥트 페이지 내부에서 회원가입 화면에는 비밀번호를 입력하는 창이 있다. 비밀번호를 입력할 때 숫자와 문자 그리고 특수문자 그리고 특정 길이를 넘기지 않으면 해당 비밀번호로 회원가입이 불가능한데,
어떤 조건을 가지고 비밀번호를 입력해야하는지 알려주는 에러메세지를 입력창 하단에 바로 표시되게 적용해두었다.
공급자가 아닌 사용자의 입장에서 해결책을 전달하는 것이 중요하다.
예를 들어 에러메세지가 다음과 같이 뜨게 되면 어떨까?
“input 창에 value 값이 없어 다음 섹션으로 이동하기 위한 api 요청이 불가합니다.”
조금은 과장하여 작성하긴 했지만, 만약 이 에러메세지를 처음 보는 사용자들은 이해하기가 어려워 문제를 해결 할 수 없을 것이다.
사용자가 에러메세지를 보고 원인을 파악하고 스스로 해결 할 수 있게 도와주는 에러메세지를 작성해주어야 한다.
예를들어 코넥트에 로그인을 하고 몇시간 뒤에 다시 코넥트 페이지를 들어갔다고 생각해보자.
코넥트 페이지는 로그인 유지를 jwt를 이용하여 진행하고 있는데, 일정 시간이 초과 되면 로그인 유지가 풀려버리게 된다.
그래서 자동적으로 로그아웃이 되면 로그인 이후에만 이용할 수 있는 서비스를 이용하지 못하게 되는데,
이때 페이지에서는 토큰이 만료 됐다는 에러메세지만 띄워주는게 아닌 로그인 페이지로 이동하여 사용자가 재로그인을 할 수 있도록 도와 준다.
~할 수 없습니다. 라는 말투 보다는 어떻게 해야 가능한 지에 대해 설명해주는 긍정적인 말투가 훨씬 더 적절한 에러 메세지라고 할 수 있다.
사용자는 어떤 이벤트를 기대하며 작동을 시켰을텐데 에러메세지가 났다는 건 그 이벤트가 발생하지 않았다는 것을 의미하게 된다. 이런 상황 속에서는 좌절하는 감정을 가지게 되니 그 점을 배려하며 커뮤니케이션 해야한다.
다음과 같이 6가지 사항들을 지켜 에러메세지를 작성하면 사용자들도 더 간편하게 에러를 해결 할 수 있을 것이다.
이번 프로젝트에 6가지 사항중 몇가지는 지키고 몇가지는 아직 부족한 거 같은데, 차차 보완해 나가며 더 좋은 에러 UX를 만들어내야겠다는 생각이 들었다.