서비스 기획 어디까지 고려해야 할까?
유저가 마주칠 모든 케이스를 찾아내기
처음 스토리보드 문서를 작성할 때 놀랐던 것은 생각보다 서비스를 기획할 때 고려해야 할 페이지가 많다는 것이다.
유저들은 서비스가 정해놓은 이상적인 Flow로만 움직이지 않으며, 서비스 또한 아무런 에러 없이 정상적인 화면만을 보여줄 수 없다. 그렇기 때문에 서비스 기획자는 유저가 겪을 수 있는 모든 케이스를 생각해 내고 유저의 도착점에서 보여줄 적절한 화면을 미리 기획해야 한다.
나를 살렸던 이탈 확인 알림들...만약 정성을 가득 들여서 쓴 리뷰나 블로그 글, 사진 보정을 저장하지 못하고 예기치 못해 이탈 행동을 했을 때 이탈 케이스 알림창이 뜨지 않았다면 유저는 매우 당황스러울 것이다.
이상적인 화면을 벗어난 예외 케이스들! 스스로 정리할 겸 부트캠프에서 서비스 기획을 하면서 고려했던 다양한 케이스들을 소개한다.
* 잘못된 정보가 있으면 언제든지 알려주세요!
텍스트 필드
회원 가입, 검색 등 서비스를 만들 때 유저가 정보를 입력하는 박스를 텍스트 필드라고 한다. 여러 가지 변수들과 인터랙션이 존재하기 때문에 텍스트 필드 구성에서 가장 많은 시간을 투자했었다.
(1) 텍스트 필드 구조
텍스트 필드는 간단하게 레이블, 입력 필드, 플레이스홀더로 구성되어 있다.
서비스에 따라서 리딩 아이콘(이미지에서 user 아이콘)이 추가되어있기도 한다.
- 레이블(Lable) : 해당 텍스트 필드의 이름 (ex. 아이디, 비밀번호, 생년월일 등)
- 플레이스홀더(Placeholder) : 텍스트 필드에 입력할 내용이 무엇인지 알려주는 힌트 문구
레이블은 아이디, 비밀번호 등 텍스트 필드에 입력해야 할 내용이 무엇인지 알려주는 역할을 한다. 레이블은 유저가 텍스트 필드를 활성화시켜도 유지된다.
플레이스홀더는 텍스트 필드 내부에서 텍스트 필드에 입력해야 할 내용의 형식 등을 안내한다. 만약 이름 레이블이라면 플레이스홀더에 '8자 이내 한글 혹은 영문' 등의 문구로 유저에게 8자 이상이 넘어가면 입력이 안된다는 힌트를 줄 수 있다. 레이블과 다르게 텍스트 필드가 활성화되면 해당 문구가 사라지는 경우가 많다.
(2) 텍스트 필드 케이스 정의
부트캠프 당시 정의했던 케이스위 4가지 케이스는 부트캠프 때 작성했던 텍스트 필드 케이스이다. 그 당시에는 4가지만 정의했으나 '입력이 불가능한 상태' 등 기획에 따라서 더 상세하게 케이스를 나누는 것이 필요하다.
- 디폴트(Default) : 유저가 아무 액션도 취하지 않았을 때 나타나는 가장 기본적인 케이스
- 포커스(Focused) : 유저가 텍스트 필드를 클릭하여 커서 활성화
- 활성(Activated) : 인풋값 입력
- 에러(Error) : 유저 인풋값이 유효하지 않음
당시에는 디폴트 케이스에서 Inactive 상태만을 가정하였으나 '비어있는 상태, 작성한 내용을 지운 상태' 등도 고려할 수 있다.
또한 포커스 상태를 활성 상태로 정의하여 한번에 나타내고, 인풋이 들어온 상태를 따로 표기하기도 한다.
이 케이스에서 유저의 화면에 키보드를 띄울지, 띄운다면 어떤 키보드를 띄울지도 함께 정의한다.
에러는 정의하지 않은 텍스트가 들어왔을 때, 필수값이 아닐 때 등의 에러 케이스, 유저에게 에러 메시지 텍스트를 안내하여 올바르게 입력할 수 있도록 유도한다.
Google Material Design 34가지 유형 외에도 텍스트 필드에 마우스를 위치시키는 호버 상태(Hover), 텍스트 필드를 사용할 수 없는 상태(Disabled) 등의 더욱 디테일한 상태를 고려할 수 있다.
(3) 유효성 검사
유효하지 않은 정보를 입력했을 때 실시간으로 피드백을 주어 유저의 실수를 줄일 수 있다.
이 피드백은 어떤 정보를 입력해야 할지 알려주는 가이드 역할을 하기도 한다.
또한 유저가 모든 정보를 유효하게 입력하였을 경우에만 다음 버튼이 활성화되도록 하여 유저의 입력 실수를 줄일 수 있다.
(4) 텍스트 필드 성격에 맞는 적절한 키보드 제공
만약 숫자만 입력 가능한 텍스트 필드를 활성화했을 때, 뜬금없이 문자 키보드가 나온다면 어떨까? 유저는 숫자를 입력하기 위해서 기본 키보드의 왼쪽 하단에 있는 작은 숫자를 누르는 번거로운 경험을 겪는다.
IOS와 안드로이드는 인풋 타입에 따라 다양한 키보드를 제공하고 있다. 기획자는 유저가 빠르게 정보를 입력할 수 있도록 적절한 키보드를 제공할 수 있어야 한다.
알림창의 종류
다양한 내용을 전달하기 위해서 선택지가 있는 알림창을 띄우는 경우가 있다. 이때 모달 팝업/바텀시트 형식을 자주 사용하는데 모달 형식은 유저가 팝업 영역 외 터치가 불가능하기 때문에 유저의 사용성을 방해하게 되므로 중요한 알림이 아니라면 자주 노출하지 않는게 좋다.
(1) 선택지 개수에 따라 종류 나누기
(왼쪽부터) 이마트, 두잇, 캐치테이블, 지그재그알림창의 선택버튼은 크게 단일 선택지와 다중 선택지가 있다. 다중 선택지라고 했지만 이중 선택이 가장 많이 보인다.
단일 선택지는 주로 알림 목적으로 어떠한 정보를 전달할 때 사용하므로 '확인' 혹은 '닫기' 버튼만 있다. 다중선택지는 유저가 생각하고 선택해야 하는 알림창으로 선택버튼의 문구가 간결하고 명확해야 바로 이해하기 쉽다. 유저가 원하는 액션은 오른쪽에, 색상으로 강조하면 행동 유도가 가능하다. (어느 아티클에서는 '긍정적인 행동'을 오른쪽에 배치하고 색상을 강조하라고 하였다.)
부트캠프에서는 단일 선택지 버튼, 다중 선택지 버튼 종류를 나누고 각 버튼이 노출되는 케이스를 한눈에 볼 수 있게 정리했었다. 케이스를 정리하면서 해당 알림창에 노출되는 안내 문구, 버튼 문구도 함께 정리하였다.
결과가 없는 화면
처음 기획을 할 때 간과했던 화면, 바로 결과가 없는 화면이다. 벤치마킹을 할 때나 서비스를 개선할 때 당연히 와이파이를 연결한 상태로 보고 있었기 때문에 연결이 끊겼을 때의 화면은 생각을 못했었다. 팀원들이랑 카페에서 프로젝트를 진행하고 있는데 마침(!) 카페의 와이파이가 너무 구려서(!) 연결이 끊긴 상태로 앱을 본 이후로는 일단 연결부터 끊고 본다.
네트워크 연결 오류 외에도 링크 연결 오류, 컨텐츠가 없는 화면을 추가로 고려했다. 어느 상황이 오더라도 유저가 어노잉하게 느끼지 않게 하기 위해 구석구석 예외 플로우를 뒤져야 한다.
(1) 네트워크 연결 오류
네트워크 연결 오류 화면을 만들어둔 앱은 유저에게 '문제 상황'과 '대처 방법'을 안내하고 있다. 이렇게 명확하게 안내하면 유저가 어떤 문제로 현재 서비스를 이용하지 못하는지 바로 알 수 있다.
위 서비스들처럼 네트워크 연결 오류 사항을 '오류 케이스'에 포함시켜 단일하게 보여주는 서비스도 있으며(단일 케이스로 통일하여 정책 및 공수를 줄인 것 같다) 네트워크 연결 오류 시 로그인이 해제되면서 로그인 화면으로 보내는 서비스도 있었다.
(2) 링크 연결 오류, 그리고 공유 링크 미리보기
우리 팀이 기획했던 서비스가 웹, 모바일 두 종류 모두 있는 서비스여서 더욱 해당 페이지를 어떻게 구성할지 고민하는 것이 필요했다. 흔히 볼 수 있는 404 페이지를 유저에게 보여줄 방법을 고민하는 것! 웹에서는 흔하지만, 모바일에서는 링크가 잘못된 페이지를 그냥 빈 페이지와 404 메시지로만 보여주는 경우가 많았다. 그러나 위 예시처럼 특정 페이지로 넘기기도 한다.
캐치테이블에는 내가 식당을 모아 두고 다른 사람과 공유할 수 있는 컬렉션 기능이 있다. 컬렉션 링크 공유 시 링크가 잘못된 경우 아무 정보가 들어가 있지 않은 상태의 기본 화면을 보여준다.
네이버맵은 보다 상세했다. 페이지를 찾을 수 없다는 것과 이 페이지가 잘못된 주소일 수 있으니 다시 확인하라는 피드백 메시지가 포함되어 있어 무엇이 잘못되었는지 바로 알 수 있다.
틱톡은 컨텐츠 노출이 중요하기 때문에 잘못된 링크로 들어가도 오류 메시지가 뜨지 않고 랜덤한 추천 영상을 노출한다. 이렇게 되면 잘못된 링크인지 유저가 알 수 있는 방법이 없을 것 같지만 잘못된 링크를 보내면 기존에 컨텐츠의 섬네일을 보여주던 공유 미리보기가 틱톡 기본 이미지로 전달되기 때문에 구분이 어렵진 않았다. (그래도 링크가 잘못되었다고 알려주면 좋을 듯)
서비스마다 다르겠지만 링크 연결 오류 케이스도 디테일하게 나눌 수 있다.
가령 노션처럼 링크의 공유 권한이 정해진 서비스라면 '링크 자체가 잘못된 상황'과 '권한을 부여받지 않은 사용자가 링크를 접속한 상황'을 나누고 각 상황마다 유저가 적절한 피드백을 받을 수 있는 화면을 보여주면 유저 입장에서는 왜 접근이 안되는지 이해하기 쉽다.
그리고 해결 방법 또한 나누어두었는데, 콘텐츠가 없으면 바로 지원팀에 문의할 수 있게 링크를 제공하고 있으며 액세스가 없을 때는 다른 이메일로 로그인할 수 있는 링크를 바로 제공한다. 이런 부분도 사소하지만 사용성이 크게 향상되는 부분이라 생각한다.
링크 얘기가 나와서 추가하는 내용이다.
친구랑 맛집을 공유할 때 링크와 함께 미리보기 이미지가 가는 것을 많이 봤을 것이다. 기사 링크를 넣기만 해도 바로 아래에 기사 섬네일과 내용 요약이 나오는 것도 바로 이것이다. 각 서비스의 특징에 따라 어떤 화면을 먼저 보여줄지 구성하게 되는데, 위치 중심의 카카오맵은 장소의 특징, 이미지보다는 위치를 섬네일로 선택하였고, 길찾기 버튼을 바로 클릭할 수 있게 구성하였으며 네이버 플레이스가 매우 활성화되어있는 네이버맵은 위치보다는 장소를 강조하고 있다. (추측이지만 카카오맵은 톡친구 위치공유, 길찾기 등의 위치 정보 기능에 집중하는 느낌이고 친구와 카카오톡으로 약속을 정하면 샵검색으로 장소 공유를 하는 유저가 많아 장소 정보가 아니라 위치 정보로 띄우는 것일까 생각했다)
이 화면은 메타(meta) 태그를 설정하면 되는데 서비스 링크를 공유할 때, 검색 엔진에 노출할 때 타이틀과 서비스 정보, 섬네일 등이 공유 정보를 보여주어 유저가 링크를 클릭하지 않아도 어떤 링크인지 인지하게 할 수 있다.
메타 태그는 HTML의 헤드에 있는 데이터로 사이트의 정보를 제공하는 태그이다. 이 메타 태그에서 오픈 그래프(open graph, og)를 설정한 부분을 크롤링하여 위와 같은 공유 미리보기를 만들 수 있다.
부캠 기획 시, 랜딩페이지를 만들어 간단한 수요조사가 필요했는데 수요조사를 위해 링크를 누르고 싶게 만들어야 했기 때문에 이 부분에 어떤 내용과 이미지를 보여줄지를 고민했었다.
(3) 컨텐츠 없음
'미션: 빈화면을 채워라', 배민다움 홈페이지다들 위와 같은 화면에 익숙할 것이다. 실제로 많이들 사용하는 서비스이고 '빈 화면을 채운' 대표 사례로 많이 쓰이고 있다. 유저가 원하는 컨텐츠가 존재하지 않을 때 유저들은 당황스러워지는데 이렇게 재치 있는 화면을 마주함으로써 불편함이 재미로 전환되며 긍정적인 이미지를 심어줄 수 있다.
위와 같은 페이지 말고도 유저가 '컨텐츠가 없는 화면'을 마주쳤을 때 추가 행동을 추천해 주어 (더 담으러 가기, 12월 내역보기, 리뷰 작성하기) 직접 컨텐츠를 채울 수 있게 유도하는 화면을 고려할 수도 있다.
검색 화면을 구성한다면, 유저가 원하는 검색 결과를 찾지 못했을 때 다른 선택지를 추천하여 유저 만족도를 올리면서 제휴사 홍보까지 겸하는 방향으로 화면을 채울 수도 있다.
마치며
부트캠프를 했을 때는 엄청 상세하게 많은 요소를 생각했다고 자신했는데 오랜만에 회고해 보니 정말 고민해야 하는 부분이 더욱 많음을 실감했다.
여기에 나온 요소들은 고려 요소 중 아주 소수일 것이고 실무에서는 디테일한 모든 화면, 운영 정책, 유관부서들의 리소스, 회사 데이터 리소스 등등 더 디테일하게 고민하고 화면을 설계하고 디자인한다. 이러한 것들을 생각하는 게 스트레스가 아니라 오히려 즐거운 일이라면 기획자에 한걸음 더 다가갔다고 생각해도 괜찮을지 모르겠다!
https://brunch.co.kr/@chulhochoiucj0/20
https://www.oopy.io/ko/guides/seo/meta-tag
https://story.baemin.com/3614/
