밀리의 서재, 개선안을 구체화하자 : 기획의 모든 것
[코드스테이츠 PMB 10기] 밀리의 서재 : 3주차, UX 개선
도서 제안 기획 구체화하기
(ft. 서비스기획 산출물)
1. 기획의 첫 시작
드디어 위클리 과제 4주차에 접어들었다! 그리고 이번 위클리 과제는 3주차 과제에서 내가 정의한 기획안을 구체화시키는 것이다. 아래의 포스팅에서 이전에 기획한 내용을 볼 수 있다.
과제를 시작하기 전 간단하게 정리하자면, 내가 제시한 밀리의 서재 개선안은 다음과 같다.
1. 도서를 검색하였을 때, 도서가 없다면 바로 '도서 제안하기' 를 클릭하여 도서 제안 서비스를 이용할 수 있다.
2. 기존 서비스와는 달리, 도서명, 저자명, 출판사명 3개의 정보만 입력하여 도서를 제안할 수 있다.
3. 희망도서 내역을 확인하는 탭을 눌러 이때까지 제안했던 도서와 그에 대한 처리상태를 확인할 수 있다.
4. 관리 탭을 누르면 바로 '나의 도서제안' 탭이 존재하고, 바로 도서를 신청하거나 내역을 확인할 수 있다.
그렇다면 이 기획안을 어떻게 개발자나 디자이너와 소통할 수 있을 만큼 만들 수 있을까? 그 내용을 우리는 코드스테이츠 W4 동안 배워왔다!
그래서 이번 포스팅에서는 기획했던 내용을 실제 서비스를 실현화시키기 위해 요구사항 정의서, 와이어 프레임을 작성하고 피그마를 활용하여 프로토타입까지 작성해보도록 하겠다.
2. 요구사항 정의서
개발자님, 우리는 이런 기능이 필요해요!
먼저, 고객의 요구사항을 유저 스토리로 정의를 해보고자 한다.
여기서의 '유저 스토리'란, 고객의 요구사항을 바탕으로 제품팀의 '공유된 이해' 를 만드는 것을 목적으로 하며 WHY, HOW, WHAT 의 물음을 던져서 '우리가 왜 이 기획을 해야 하고, 어떻게 접근해야 하며, 가장 적합한 솔루션은 무엇일까?' 생각해보는 과정이다.
이제부터 만들고자 하는 기능은 다음과 같은 유저스토리를 가진다.
밀리의 서재에서 읽고 싶은 책을 못 찾은 고객은 '도서 제안 서비스'를 이용하여 자신이 원하는 도서를 얻고자 할 것이다. 그러므로 밀리의 서재는 고객들이 도서 제안 서비스를 사용하기 쉽도록 서비스를 기획해야 한다.
그렇다면 위의 유저스토리를 해결하기 위한 요구사항 정의서를 표로 정의해보도록 하자.
사용자의 유저 플로우를 상상해보며 개발자와 디자이너와 충분히 소통이 될 수 있도록 최대한 자세하게 작성해보려 노력하였다. 여기에서 사용자는 밀리의 서재를 사용하는 독자를 의미하고, 관리자는 제안된 도서를 파악하고 관리할 밀리의 서재 관리자를 의미한다.
우선순위는 모두 최우선으로 설정을 하였는데, 왜냐하면 [도서 제안하기] 서비스 자체에 위의 모든 기능들이 충족이 되어야 정상적으로 작동할 수 있다고 말할 수 있기 때문이다. 그럼에도 가장 중요한 기능이 무엇이냐고 물어본다면 [관리자] - [제안된 도서 확인하기] 기능이라 할 수 있다.
밀리의 서재는 모두 전자책을 제공하기 때문에 전자책 IP가 없는 도서라면, 해당 도서를 제공하기가 어렵다. 그러므로 고객이 긴 시간을 기다리지 않도록 제안된 도서의 전자책 IP 유무를 빠르게 확인할 수 있어야 한다. 유저 인터뷰에서도 피드백이 빠르지 않으면 사용하지 않을거라고 말이 나온 적이 있다. (참고)
3. 정보 계층 구조도 (IA)
한 요정도에 넣으면 되지 않을까요?
다음은 만일 실제로 해당 서비스가 도입된다면, 고객들은 어디에서 찾을 수 있을 지를 살펴보고자 밀리의 서재 정보 계층 구조도를 작성해보았다. 현재 기획하고 있는 서비스가 어디에 위치될 지를 고민하며, 해당 내용을 중심으로 작성해보고자 한다.
① 밀리의 서재 첫 화면
밀리의 서재에 처음 들어가면, 간단히 상단 내비게이션, 탭바, 탭바에 따라 나오는 콘텐츠, 그리고 하단 내비게이션을 확인할 수 있다. 하지만 NOW 탭바가 가장 기본으로 나오는데 그렇게 되면 25개나 되는 하위 콘텐츠가 있어서 다음과 같이 간단히 정리하고자 한다.
현재 내가 기획하고자 하는 서비스는 검색이 안 되었을 때 표시되어야 함으로, 하단 내비게이션을 중심으로 살펴보려고 한다. 이때 놀라운 점을 발견했는데, 밀리의 서재에서 '카테고리를 빠르게 찾을 수 없다' 라는 VOC를 확인했는지, 검색 창을 눌렀을 때 바로 하단에 카테고리를 표시했다!
이전 글을 확인하면 바로 카테고리를 확인할 수 없다는 사실을 알 수 있다. (밀리의 서재는 열일 중�)
그래도 아쉬운 점은 밑에 카테고리 탭이 보이길래, 탭하면 바로 카테고리 쪽으로 내려갈 줄 알았는데 그렇지는 않았다. 스크롤을 조금만 내리면 바로 카테고리가 보이기 때문에 그렇게 까지 필요로하는 기능은 아니지만, 그래도 보통은 저렇게 표시되어 있을 때 shortcut으로 내려가주는 기능을 같이 탑재하고 있으므로 해당 기능까지 추가되면 좋을 것 같다!
다시 본론으로 돌아와, 하단 내비게이션의 IA는 다음과 같다.
② 하단 내비게이션
관리탭에서 [도서 제안하기] 를 통하여 이번 기획한 서비스를 사용할 수 있도록 제작해보았다. 실제 적용이 된다면 우측의 사진처럼 나올 듯 하다.
4. 화면 디자인 (Wireframe)
디자이너님, 우리는 이렇게 제작하고 싶어요!
페이퍼 프로토타입
그렇다면 이제껏 나왔던 내용들을 통합하여 피그마 툴로 프로토타입을 제작하기 전, 먼저 Lo-fi 프로토타입을 제작해보았다.
Lo-fi 프로토타입의 경우, 핵심적인 페이지만을 작성했다. 그리고 이를 피그마 툴로 제작해보던 중, [도서 제안하기] 버튼을 눌렀을 때, 제안이 정상적으로 처리되었음을 알려주는 페이지 역시 있으면 좋지 않을까? 하는 생각이 들어 아래의 Frame 5 페이지 역시 작성하였다.
이때, UX Writing 의 경우 밀리의 서재의 기존 브랜딩과 유사하게 제안을 요청하는 경우, 또는 제안한 내역을 확인하는 경우에는 '-요' 어미를 사용하여 말을 건내듯이 작성을 하였고 정상적으로 처리되었음을 알리는 경우에는 '-다' 어미를 사용하였다.
그 결과, 아래의 이미지와 같은 Figma 결과물이 나왔다!
Mid-Fi Prototype
모든 플로우를 기록하지는 않았지만, 간략하게 어떤 식으로 플로우가 흘러가는 지를 빨간 화살표로 표시해보았다.
4. 스토리보드 (PRD)
아마 우리의 사용자는 우리 기능을 이렇게 사용할 거에요!
페이지들은 나왔는데, 상세한 설명이 없다면 이 기능을 함께 제작할 팀원들 (개발자, 디자이너) 이 혼란을 겪을 수 있다. 그러므로 이번에는 팀원들이 잘 이해할 수 있도록 우리의 사용자들은 어떤 식으로 사용할 지 스토리보드를 작성해보도록 하겠다.
① 검색 결과가 없을 시
② [나의 도서 제안] - [희망도서 제안]
③ [도서 제안하기 성공 페이지]
④ [도서 제안 내역 확인 페이지]
⑤ [관리 페이지] (NEW!)
관리 페이지에서는 새롭게 추가된 내용만 디스크립션을 넣어보았다.
그리고 위의 내용물을 play 해보면 아래와 같은 흐름도를 가지게 된다. (방황하는 마우스 포인터는 덤)
