PM의 시선으로 트리플 '이 근처 장소 탐색' 개선하기
[코드스테이츠 PMB 10기] 페이퍼 프로토타입
코로나 이전에는
트리플에 이런 기능 없었는데!
1. 오랜만에 트리플 앱을 켰다
코로나19 이후의 트리플
코로나19 이후 트리플을 처음 켜보았다. 나에게 트리플은 해외 여행을 다닐 때 쓰는 앱이었기 때문이다. 코로나19 이후로도 강릉, 경주, 제주 같은 곳으로 국내 여행을 갔지만, 굳이 트리플을 쓰지는 않았다. 그런데 내가 트리플을 외면(ㅠㅠ)하던 사이 트리플에는 많은 변화가 있었다고 한다.
애플리케이션의 홈 화면부터 달라진 점이 눈에 띈다. 홈 화면의 추천 콘텐츠들의 주제가 전부 국내 여행이었다. 그중에서도 아예 '제주 여행' 카테고리를 홈 화면 최상단에 따로 빼두었을 만큼 제주도 여행에 관련한 콘텐츠에 주력하고 있었다.
해외 여행의 경우, 코로나19 상황에 맞추어 여러 가지 변화가 있었다. 여행지를 선택하면 해당 국가의 코로나19 관련 정책을 안내한다. 홈 화면에서는 코로나19와 관련한 ▲여행가능 ▲격리필요 ▲여행금지 국가를 분류하고, 각 국가별 확진자 및 백신 접종률 정보를 제공한다.
트리플이라는 서비스를 분석한 다양한 아티클에 의하면, 트리플은 코로나19로 해외 여행이 사실상 불가능에 가까워진 상황에서 국내·해외 여행을 포괄한 '여행의 모든 것'을 다루는 서비스로 피봇팅을 시도했다. 트리플의 랜딩 페이지에서도 피봇팅의 흔적을 엿볼 수 있었다. 랜딩 페이지에 삽입된 이미지(Ex. 리뷰 이미지, 지도 이미지 등)가 전부 국내 여행 관련 이미지였다. 또한, 서비스의 정체성을 드러내는 카피에도 '국내여행'이라는 키워드를 필수적으로 언급하고, 또 강조하고 있다.
나의 첫 번째 혼자 여행 (with. 트리플)
오랜만에 앱을 살펴보다 보니 내가 만들었던 여행 계획이 눈에 띄었다. 그중에서도 내가 트리플을 가장 열심히 이용했던 여행인 뉴욕 여행에 시선이 갔다. 내가 첫 번째로 떠난 혼자만의 여행이자, 자유 여행이었고, 그때 트리플의 도움을 받았다. 2주 동안의 여행을 마치자마자 코로나19 대구 신천지 사태가 터졌고, 위 사진 속 오사카 여행은 계획만 세우고 무산되었다...
어쨌거나 나의 여행 스타일을 밝히자면, 나는 열정적인 계획파이다. 10분 단위로 계획을 짜고, 1센트 단위로 예산을 짠다. 여행지에서는 무조건 음식, 명소, 예술, 체험, 쇼핑, 내가 할 수 있는 건 다 해야 직성이 풀린다.
그래서 2주 동안의 빡빡한 계획에 트리플이 많은 도움이 됐다. 특히 뉴욕 여행에서의 나는 하루에 10000보는 기본일 정도로 걷고, 또 걷길 반복했던 뚜벅이였다. 그래서 트리플로 여행 계획을 짤 때 지도에 점선으로 경로를 표시해주는 기능을 유용하게 썼다.
물론, 불편했던 점도 있다
그런데 그때 불편했던 점은, 지도 영역이 너무 작다는 것이었다. 그래서 인터렉션을 실수하는 등 불편함이 있었고, 화면의 절반밖에 움직이지 않으니 답답하단 느낌을 받았다. 그런데 2년 만에 트리플을 방문해보니 위 사진처럼 지도 영역을 선택하면 지도 영역이 커지고, 일정 영역은 보기 좋게 좁혀졌다. 물론 좋은 방향으로 개선되긴 했지만, 트리플을 조금 더 사용해보니 개선이 필요한 지점을 발견했다. 그래서 이번 포스팅에서는 페이퍼 프로토타입 Paper Prototype을 그려서 트리플의 UX/UI 중 일부를 개선해보려고 한다.
2. 유저 Flow 및 개선점
페르소나/저니 맵
* 오늘의 포스팅 주제는 '페이퍼 프로토타이핑'이므로 페르소나/저니 맵은 최대한 간략히 작성했습니다.
UX/UI의 개선점을 찾기 위해서는 먼저 유저 Flow(=페르소나, 저니 맵 등)를 고려해야 한다. 사용자가 어떤 부분에서 불편함을 느낄지 추측할 수 있어야 하기 때문이다. 그래서 나는 뉴욕 여행을 계획 중인 페르소나를 가정하고, 해당 페르소나가 트리플을 통해 뮤지컬 <라이온 킹> 감상하는 날의 여행 일정을 짜는 과정을 따라가보려고 한다. 페르소나는 현재 <라이온 킹> 티켓의 예매를 마친 상태이고, 뮤지컬 감상 이후 저녁 식사를 먹을 근사한 현지 레스토랑을 찾고 싶다는 니즈를 갖고 트리플에 접속했다.
① 트리플 접속하기
② 민스코프 극장에 대한 장소 정보 확인
③ '기본정보' 영역의 지도 선택
④ '이 근처 장소 탐색' 버튼 선택
⑤ 민스코프 극장 주변으로 맵 확대
⑥ 맵 아이콘을 선택하여 음식점 탐색
페르소나는 대략 위와 같은 여정을 거쳐 트리플에서 음식점을 찾을 것이다. 그런데 내가 페르소나에 몰입해서 트리플을 이용하던 중, 이 근처 장소 탐색이라는 프로덕트에서 개선이 필요한 UX/UI를 발견했다.
이 근처 장소 탐색
UX/UI 개선
장소 필터
먼저, ⑤ 민스코프 극장 주변으로 맵 확대 상태에서는 하단의 카드를 스와이핑하여 이 근처의 장소를 탐색할 수 있다. 그런데 이 카드가 무슨 기준으로 나열되는 것인지 알 수 없었다. 이 근처 장소 탐색에 표시되는 장소들은 음식점(빨간색 아이콘), 그리고 관광명소(보라색 아이콘)로 구분된다. 그런데 음식점을 찾기 위해 트리플에 접속한 페르소나의 입장에서는 음식점과 관광명소가 뒤죽박죽 섞여 있어서 원하는 정보를 찾기 어려웠다. 이를 해결하기 위해서 장소를 구성할 수 있는 필터 기능이 추가되어야 한다고 생각했다.
맵 아이콘 리디자인
또한, ③ '기본정보' 영역의 지도 선택 이후 지도상에 표시되는 맵 아이콘에도 개선이 필요하다. 페르소나는 근사한 현지 레스토랑을 찾고 있는데, 음식점으로 분류되는 장소는 전부 똑같은 아이콘으로 표시된다(맥도날드, 레스토랑, 심지어 푸드트럭까지...). 결국 아이콘을 하나하나 눌러서 음식점의 종류를 확인할 수밖에 없다. 그래서 아이콘만 보고도 음식점의 종류를 알 수 있도록 아이콘 디자인을 분류할 필요가 있다고 생각했다.
위와 같은 유저 Flow 분석을 거쳐 1) 장소 필터와 2) 맵 아이콘 리디자인이라는 솔루션을 도출했다. 이중에서도 맵 아이콘 리디자인은 디자이너의 영역이므로, 기획자의 영역에 가까운 장소 필터를 개선하는 데 집중하기로 했다. (물론, 디자이너에게 기획안을 전달하여야 하므로 어떤 기준으로 맵 아이콘을 리디자인해야 하는지는 다룰 예정이다.)
3. 페이퍼 프로토타입
아이패드로 끄적거린 나의 첫 번째 페이퍼 프로토타입...! 매우 약소하게 그려보았는데, 그 와중에 알아보기 어려운 부분이 있어서 설명을 덧붙이려고 한다.
총 4개의 페이지를 그렸고, 페이지마다 왼쪽 상단에 번호를 붙여 구분했다.
X표된 상자는 자리 표시자를 나타낸 것으로, 추후 개발적·디자인적 요소가 삽입될 자리이다.
대괄호로 묶인 텍스트는 특정값이 입력될 자리이다(=변수).
Ex) [장소 이름] → 사용자가 선택한 장소에 따라 텍스트가 바뀌어 삽입된다.
다음은 페이퍼 프로토타입 내 색깔 표기에 관한 내용이다.
주황색 : 화살표는 페이지 이동 경로를, 테두리는 새롭게 등장한 페이지를 의미한다.
초록색 : 사용자가 인터렉션 할 수 있는 터치 영역이다.
분홍색 : 페이지 이외의 요소에 변화가 있을 경우, 사각형과 원형으로 표시했다.
페이지별 설명
1번 페이지
오른쪽 상단에 필터 버튼을 추가했다.
이후의 프로토타입 단계에서 장소 분류에 따른 맵 아이콘 리디자인이 필요하다.
(장소 분류의 체계는 3번 페이지의 '장소 필터' 참고)
2번 페이지
직전 페이지 위로 장소 필터 창이 뜬다.
장소 필터 창은 상/하단 영역으로 분류된다.
상단 영역에서 음식점/관광명소 중 하나를 선택하면 다음 페이지로 넘어간다.
음식점/관광명소를 선택하기 전까지 하단 영역에는 로딩 애니메이션을 띄운다.
3번 페이지
상단 영역이 2번 페이지에서 선택한 음식점/관광명소 중 하나에 대한 정보창으로 바뀐다.
하단 영역이 장소 필터를 선택할 수 있는 영역으로 바뀐다.
장소 필터는 중복 선택이 가능하며(or 조건), 음식점의 장소 분류 체계는 다음과 같다.
유명 맛집 / 가성비 / 레스토랑 / 체인점 / 푸드트럭
4번 페이지
X버튼을 누르면 직전 페이지로 돌아가고, 장소 필터 창에서 선택한 필터가 적용된 모습으로 보여진다.
필터에 해당되지 않는 맵 아이콘은 지워진다.
하단의 카드 영역이 선택한 필터에 따라 재구성된다.
페이퍼 프로토타입을 그려본 소감
페이퍼 프로토타입은 로우 파이 프로토타입 Lo-Fi Prototype의 일종으로, 실제 출시될 서비스와 거리가 먼 초기 단계의 프로토타입이다. 개발적·디자인적 요소가 적용되지 않은 간이 산출물로, 새로운 의견을 바로 적용할 수 있다는 장점이 있다. 그래서 PM이 새로운 프로덕트를 기획하는 단계에서 자주 쓰이는 프로토타입이다. 이렇게 과제를 통해 페이퍼 프로토타입 실습을 해보니 개발자, 디자이너, 그밖의 이해관계자와 소통할 때 유용하게 쓸 수 있는 나만의 무기가 하나 추가된 기분이다.
'서비스 기획 산출물'에 정답은 없다
그리고 오늘 몰입 학습과 QnA 세션에서 서비스 기획 산출물에 대해 깨달은 점이 있다. 부트캠프 수강 전, 혼자서 PM이 되기 위해 이런저런 삽질... 말그대로 맨땅에 헤딩을 하던 시절에는 모든 기업에 통용되는 절대적인 서비스 기획 산출물이라는 것이 존재하는 줄 알았다.
그래서 서비스 정책서, 기능 명세서, 스토리보드, 상세 기술서, 서비스 기획서, 화면 설계서, 요구사항 정의서 등등등... 서비스 기획 산출물로 분류된 모든 문서를 완벽하게 작성할 수 있어야 한다고 생각했다. 당연히 공부를 해도해도 끝이 없었고, 나의 역량 부족인 것만 같아 구슬퍼지곤 했다(...).
그러나 서비스 기획 산출물이란 개발자, 디자이너가 참고하는 서비스 기획자(PM, PO)의 문서를 통틀어 일컫는 개념이다.일반적으로 이 문서에는 서비스 정책, 정보 계층구조도, 와이어프레임, 유저 플로우, 플로우 차트, 화면 흐름도 등이 포함되긴 하지만, 어디까지나 예시일 뿐이다.
세상에는 수많은 서비스가 존재한다. 그리고 그에 맞는 기획도 모두 다르다. 그러니 당연히 서비스 기획 산출물에도 '정답'이란 있을 수 없는 것이다. 우리 서비스에 맞는 문서를 작성하여 소통할 줄 알면 되는 것이지, 세상에 존재하는 서비스 기획 산출물을 모조리 통달(?)할 필요는 없는 것이다. 물론 알고 있는 문서의 종류가 많을수록 유능한 PM이라 여겨질 순 있겠지만, 무엇보다도 PM은 목적에 맞는 문서를 작성할 줄 알아야 한다. 오늘도 배움 덕분에 불안을 덜 수 있는 기쁜 날이었다!
