포스타입의 신규 기능을 기획하자 : 백로그부터 SB까지
[코드스테이츠 PMB 10기] 포스타입 : 3주차, UX 개선 및 개발
* 이번 포스팅에서는 위 포스팅에서 MVP 기획을 했던 '포스타입 스티커' 기능을 구체화할 예정입니다. 따라서 이 포스팅에서는 생략된 부분이 많으므로 위 포스팅을 읽고 오시는 것을 추천합니다.
서비스 기획 산출물을 총동원해서
'포스타입 스티커'를 구체화하자
1. 기능 정의(백로그 작성)
이번 포스팅에서는 W3, 그리고 W4에 학습한 다양한 서비스 기획 산출물을 활용하여 '포스타입 스티커'를 구체적으로 기획하려고 한다. MVP 기획 단계(참고)에서는 웹을 기준으로 기획했으나, Figma로 와이어프레임까지 그려보아야 하는 이번 포스팅에서는 포스타입 앱을 기준으로 기획을 진행하려고 한다.
기능 리스트업
먼저, 포스타입 스티커라는 커다란 프로덕트 안의 세부적인 기능들을 나열해봤다. MVP 기획에서 구상한 기능을 메뉴별로 간단하게 정리했다. 포스타입 스티커에 필요한 포스타입의 메뉴는 세 개로, 덧글창/알림창/스티커 상세페이지가 있다. 이중에서 덧글창과 알림창은 포스타입에 이미 존재하는 메뉴이고, 스티커 상세페이지는 내가 새로 구상한 메뉴이다.
① 덧글창
이전 포스팅에서 제작한 덧글창 프로토타입- 스티커 삽입
- 스티커 보러가기
② 알림창
이전 포스팅에서 제작한 알림창 프로토타입- 스티커 노출
- 좋아요 수 노출
- 확인하기 버튼 노출
③ 스티커 상세페이지
이전 포스팅에서 제작한 스티커 둘러보기 프로토타입- 스티커 다운로드
- 스티커 업로드
- 스티커 리스트
- 스티커 관리자
요구사항정의서
위와 같이 리스트업한 기능을 요구사항정의서 양식에 맞추어 다시 작성했다. 이 과정에서 기능에 대한 설명(=디스크립션), 이해를 돕기 위한 레퍼런스, 그리고 기능별 우선순위를 추가했다.
포스타입 스티커 요구사항정의서개발자, 디자이너, 기타 이해관계자들과 실제로 소통한다고 가정하고 최대한 상세하게 작성해봤다. 이해를 돕기 위한 레퍼런스에는 하이퍼링크도 삽입했다. (삽입한 하이퍼링크는 다음과 같다. 다음카페 '댓글쓰기-스티커 삽입'/네이버 OGQ 마켓 '스티커'/트위치 '이모티콘 관리 대시보드') 위 요구사항정의서에서 헷갈릴 수 있는 워딩을 살짝 해석해보자면 다음과 같다.
사용자는 '다운받는 사람', 관리자는 '업로드하는 사람'을 의미한다.
나는 이전 포스팅부터 포스타입의 사용자를 독자/창작자로 분류해왔다. 그러나 사실 포스타입과 같은 오픈 콘텐츠 플랫폼의 특성상 독자와 창작자의 구분이 뚜렷하지 않다. 독자로서 포스타입을 이용하던 사람도 '내 채널'을 만들고 포스트를 업로드하면 그 순간 창작자가 되기 때문이다. 따라서 '스티커를 다운받는가? 혹은 스티커를 업로드하는가?'를 기준으로 사용자를 구분했다.
우선순위를 매긴 기준
포스타입 스티커에서 우선적으로 개발되어야 할 기능은 무엇일까? 바로 포스타입 스티커가 역할과 기능을 수행하는 데 필수적인 기능들일 것이다. 그래서 내가 지난 포스팅(참고)에서 도출한 포스타입 스티커의 역할과 기능을 다시 살펴봤다.
1) 창작자를 향한 팬심을 드러내는 수단
2) 창작자의 브랜딩
3) 창작자의 창작 활동을 정신적으로 지지하고 금전적으로 지원
여기서 3번의 경우, 개발자 A씨와의 대화를 통해 생략하게 됐다. 마켓 시스템이 도입되면 프로덕트의 크기가 매우 커지고, 그만큼 프로덕트 개발에 필요한 인풋이 막대해지기 때문이다. 따라서 현재로서 포스타입 스티커는 1번과 2번을 만족할 수 있어야 한다. 그런 의미에서 '좋아요 수 노출'과 '확인하기 버튼 노출'은 유용한 기능이지만, '스티커'와는 직접적으로 관련이 없는 추가 기능이므로 우선순위 2순위로 분류했다.
2. 정보 계층 구조도(IA)
다음으로는 포스타입 스티커를 실제 서비스에 도입하게 되었다는 가정 하에 정보 계층 구조도(IA)를 그려보려고 한다. 맨 위에 설명한대로 포스타입 앱을 기준으로 IA를 작성했다. 포스타입 스티커가 IA의 어떤 위치에 추가되면 좋을지 고민하는 과정을 그대로 담기 위하여 IA를 그리는 중간중간 캡쳐를 했다.
① HOME
포스타입 앱을 처음으로 접속하면 위와 같은 홈 화면을 마주하게 된다. 이러한 홈 화면에서 작가 페이지로 이동하는 과정은 매우 다양하다. 탭 바 - 시리즈, HOME - 상단 배너 영역, 하단 내비게이션 - 보관함 등등... 그래서 이 포스팅에서는 내가 가장 자주 이용하는 작가 페이지 접속 방법인 하단 내비게이션 - 구독을 중심으로 IA를 그려보려고 한다.
② 하단 내비게이션 - 구독 - 구독한 채널의 포스트 - 포스트 - 포스트 영역 - 정보 영역 - 작가 아이콘
하단 내비게이션 중앙의 구독 버튼을 누르면 구독한 채널의 신규 포스트를 확인할 수 있다. 리스트업된 포스트 중 하나를 선택하면 해당 포스트로 이동한다. 위 IA에서 표현한 포스트 영역 - 정보 영역 - 작가 아이콘의 경로를 따르면 최종적으로 작가 페이지에 도착할 수 있다. 나는 이와 같은 과정을 통해 도착할 수 있는 작가 페이지에 포스타입 스티커를 추가할 생각이다.
③ 작가 페이지
그리고 작가 페이지까지 도달해서야 비로소 내가 기획한 기능, 포스타입 스티커가 등장하게 된다. 위 캡쳐 사진의 빨간색 동그라미로 표시된 부분이 스티커라는 메뉴를 추가할 자리이다. 위 IA 상에서는 스티커 메뉴를 노란색 바탕으로 표시했다.
3. 화면 디자인(Wireframe)
페이퍼 프로토타입
요구사항정의서에 따르면, 포스타입 스티커를 도입했을 때 포스타입 앱에 추가되어야 할 메뉴는 덧글창/알림창/스티커 상세페이지이다. 실제 사용자에게 제공될 버전은 이보다 deep하겠지만, 현재는 MVP 기획 단계이므로 각 메뉴의 대표격이 되는 페이지만 프로토타이핑하기로 했다. Figma로 와이어프레임을 구성하기 앞서, Lo-Fi Prototype을 그렸다.
초록색 영역은 포스타입 스티커로 인해 새롭게 추가된 UX/UI 요소들이다. 아예 새로운 페이지를 구상하는 것보다는, 어떻게 하면 기존의 페이지를 바탕으로 새로운 기능을 선보일 수 있을지에 집중했다. 다음과 같은 포스타입 앱의 기존 홈페이지를 밑바탕으로 페이퍼 프로토타이핑을 진행했다.
스토리보드
덧글창 스토리보드
알림창 스토리보드
스티커 상세페이지 스토리보드최종적으로 Figma를 통해 Mid-Fi Prototype을 그리고, 디스크립션을 덧붙여 스토리보드를 만들었다. Lo-Fi Prototype 단계에서 실수로 누락한 부분, 보완이 필요한 부분 등을 중점적으로 완성도 있는 프로토타입을 만들고자 노력했다.
이렇게 와이어프레임을 그려 보니, 고작 세 개의 페이지에도 수많은 요소가 삽입되어 있다는 걸 깨달았다. 시간 관계상 오늘 포스팅의 주제인 포스타입 스티커에 관한 디스크립션만을 남겼지만, 실제로 페이지 내 모든 기능을 정의하는 일은 그야말로 엄청난 작업이라는 사실을 인지하는 계기가 됐다. 심지어 모든 경우의 수를 따져서 오류 없는 디스크립션을 적어야 하는 것까지 PM의 몫이므로, 앞으로 내가 나아갈 길이 조금 더 까마득해지긴 했지만(...).
거기에, 최대한 전문적인 워딩을 활용해서 그 어떤 이해관계자가 열람하더라도 막힘없이 소통할 수 있는 산출물을 만들고 싶었는데 아직 나의 PM 어휘력(?) 수준이 낮아 뒤죽박죽, 체계 없는 디스크립션에 그친 것 같다. 이러한 나의 고민을 디스코드 QnA 채널에 남겼더니, 윤제님께서 PM 단어장을 만들어보는 것을 추천해주셨다. 단어장을 만들다 보면 언젠가는 어려운 워딩도 술술 입에 붙을 거라 믿는다. 내일부터 차곡차곡 나의 무기가 될 수 있는 단어들을 쌓아가보려고 한다.
+ 2022. 02. 21. 수수나 멘토님의 피드백을 바탕으로 추가 공부
1. IA를 구성하는 각 요소는 무엇을 의미하는가?
쉽게 말하면 '클릭했을 때 별도의 페이지로 이동하는 것들'이다.
작가 설명 하단에 배치된 [메시지 쓰기]를 클릭했을 때 별도의 새 창으로 열린다면, '메세지 쓰기'는 IA에 반드시 포함되어야 하는 요소가 된다.
그러나 내가 IA에 포함시킨 작가 아이콘/작가 이름의 경우, 클릭이 어려우므로 IA에 포함되는 개념은 아닌 것이다.
2. 디스크립션 작성법
세 가지 스토리보드의 '1번' 디스크립션의 타이틀(볼드체 영역)의 경우, 진입경로에 해당한다. 진입경로는 화면 요소에 대한 디스크립션이 아니기 때문에 별개로 다뤄주는 방향으로 수정하는 것이 좋다. (이때 하이픈(-) 대신 중괄호(>)를 사용하면 이해가 더 빠르다.)
3. 스토리보드상에 등장하는 모든 요소들은 명확하게 정의되어 있어야 한다
멘토님이 피드백에 적어주신 고민해봐야 할 지점“엄청 깐깐한 개발자가 와서 이것저것 물어본다고 생각하면서 SB 디스크립션을 적어라”라는 멘토님의 조언처럼, PM이 작성한 스토리보드는 모든 케이스를 고려하고, 모든 게 정의되어 있어야 한다. 그래야 모든 상황에서 제대로 기능하는 프로덕트를 만들 수 있기 때문이라고 한다.
가령 버튼 터치 리스트 노출 방식의 경우, 위 포스팅에서 말하는 '토스트 팝업' 방식이 적합할 것 같다. (토스트 팝업의 사례들이 내가 기획하고자 하는 스티커 리스트의 목적과 부합하기 때문이다.)
출처: <iOS UI 디자인 용어 스터디>이밖에도 나는 포스타입 iOS 애플리케이션을 기준으로 스토리보드를 작성했으므로 위와 같은 자료를 바탕으로 운영체제별 명확한 용어를 사용할 수 있도록 꾸준히 공부해야겠다.
참고자료
