뒤로가기 버튼 기능 설계
UX/UI 기획자들이 가볍게 생각하는 기능 중 하나가 뒤로가기 기능입니다. 모든 화면의 뒤로가기가 동일한 기능을 수행하지 않고 각각 다른 변수와 상황을 고려해야 하기 때문에 사실 더 많이 고민하고 설계해야 하는 부분입니다.
얼마전 개발 완료한 모바일 플랫폼을 사용하는 기획자가 의문을 제기합니다. 리스트 화면에서 상세 화면 진입 후 리뷰 탭 화면 이후 후 뒤로가기를 터치 시 바로 리스트 화면으로 이동해야 하는게 아닌가요?
사실 이 부분은 익숙한 경험이 다 다르며 플랫폼 개발 목적에 따라 다를 수 있는 부분입니다. 대형 포털인 다음 카카오와 네이버만 비교하더라도 하위 서비스 메뉴로 이동 후 그 하위 뎁스로 이동하더라도 뒤로 가기 터치 시 이동 동선을 모두 거친 후 리스트 또는 메인 화면으로 돌아올 수 있습니다.
- 다음 메인에서 뉴스 홈 진입 >
- 뉴스 홈에서 IT 탭 화면 진입 후 뉴스 클릭
뉴스 화면에서 뒤로가기 터치 시 이동했던 모든 화면을 모두 경유 후 홈으로 돌아왔습니다.
네이버도 마찮가지입니다.
- 네이버 메인에서 메뉴 리스트 진입 후 뉴스 화면 진입 >
2. IT/과학 탭 화면 진입 후 여러 뉴스를 터치 후 뒤로가기 터치 >
네이버도 마찬가지로 터치했던 모든 화면을 경유 후 뉴스 메인으로 돌아올 수 있었습니다.
포털사이트의 수입원 중 하나가 광고이기 때문에 화면별 트래픽이 중요합니다.
뉴스 화면 이동 후 여러 화면 경유 후 뒤로가기를 터치했다고 바로 뉴스 홈이나 네이버 메인으로 돌아오지 않습니다.
물론 사용자 편의를 고려하여 뉴스 홈 바로가기를 한번 거친 후 네이버 메인으로 돌아올 수 있도록 구성되어 있기는 합니다.
많은 정보를 노출하고 체류 시간을 길게 하는 것을 주 목적이라면 서브 화면을 모두 경유하여 체류 시간을 높여 주도록 설계할 수 있으며 반대로 체류 시간 보다는 다른 화면이 이동을 좀 더 빠르게 진행할 수 있도록 구성해야 한다면 하위 뎁스에서 바로 상위 뎁스 또는 홈으로 노출할 수 있는 방법을 제시해야 합니다.
여기서 더 중요한 부분이 있습니다. 단순히 정보를 이용하는 과정의 뒤로가기가 아니라 정보를 입력하거나 수정하는 단계를 거친 후 뒤로가기를 클릭했을 때 변수가 발생합니다.
로그인 후 뒤로가기를 터치했거나 글 작성 후 뒤로가기를 터치했을 때는 입력 화면을 경유할 필요가 없습니다. UI 기획자는 이러한 부분을 모두 고려하여 정의할 줄 알아야 합니다.
네이버 카페를 예로 들어 보겠습니다.
- 카페에서 글작성 아이콘 클릭 >
- 글작성 화면에서 글작성 후 등록 클릭 >
- 글작성 완료 후 이동하게 되는 리스트 화면에서 뒤로가기 터치
- 뒤로 가기 터치 시 다시 글작성 화면이 노출됨
글작성 완료 후 다른 글을 읽고 뒤로가기를 몇 번 터치하면 위 화면처럼 글작성 화면이 노출됩니다.
브라우저 뒤로가기 제어 방식과 앱의 뒤로가기 제어 방식이 차이가 있을 수 있지만 테스트한 화면은 네이버 앱의 뒤로가기 버튼 테스트였습니다.
이러한 부분은 주문/결제 화면에서 더욱 주의를 기울여야 합니다. 결제를 완료 후 다시 주문 화면으로 넘어가는 앱을 많이 보게 됩니다.
모바일 웹/앱 뿐만이 아니라 PC 웹도 마찬가지입니다. 우리가 너무 쉽게 생각하고 놓치는 부분이지만 중요하게 짚고 넘어가야 할 부분으로 몇 가지 사례를 들어 설명했습니다.