Product Manager로 서비스 만들기
하나의 어플리케이션이 만들어지기 까지의 과정
길거리에 사람들로 북적이던 작년 12월,
기획, 디자인, 개발자들이 합숙하며 하나의 서비스를 만들기 위해 프로젝트를 진행했다.
기획 2. 디자인3. 서버3. 안드로이드 3. iOS 2명 총 13명이 함께 프로젝트를 진행하였으며
결과적으로는 "APPJAM 15th Conference"에서 대상을 수상했다.
많은 우여곡절이 있었던 이 프로젝트를 경험하며
하나의 서비스가 만들어지기 까지의 과정과 Product Manager의 역할에 대한 고민들을 끄적입니다.
일하며 발견한 문제, 나만 겪고 있는 게 아니라고?
9월을 시작으로 IT 창업 동아리 SOPT에서 기획 파트로 활동을 시작했다.
이 동아리에서는 7차로 이루어진 세미나를 듣고 PM 경선을 통해 선출된 인원들이 각자 팀을 꾸려 장기간 해커톤인 APPJAM을 2주(혹은 3주)간 진행하는데, 여기서 기획자는 앱잼에서 PM(Product Manager) 혹은 TI(Team Improvement) 역할을 수행한다. 개인적으로 PM이라는 포지션에 욕심이 있어 이것저것 아이디어를 도출시키다가, 다니던 직장과 외부 클라이언트 회사에서 공통적으로 가지고 있던 문제를 발견한다.
"사내 정보 공유가 단방향이다"
제직 하던 회사에서 대표님의 요청으로 매일 아침마다 사내 뉴스레터를 작성했는데,
당시 IT 컨설팅 회사를 제직 중에 있어 관련된 뉴스 기사나 블로그 컨텐츠들을 모아 전사에 공유를 했다.
내부적으로 Slack, MS Teams 등의 툴이 아닌 카카오톡, Microsoft365를 사용하기에 정보를 공유할 수 있는 창구가 없어 Outlook을 활용해 이메일을 보내는 방식으로 공유했다.
마침 외부 클라이언트 회사 프로젝트에 참여할 기회가 있어, 약 3달간 클라이언트가 사용하는 회사 메일 계정을 받았는데, 마찬가지로 매일 아침 한 직원이 뉴스 레터를 정리에 전사에 공유하는 일을 하고 있었다.
뉴스 레터의 이메일 형식. 기사의 제목과 URL, 언론사가 표시된다.그러나 이러한 형식의 뉴스 레터 공유는 다양한 문제점을 가지고 있는데,
1. 단편적인 공유만 가능하다.
2. 좋은 주제에 대해 의견을 나눌 공간이 없다.
3. 기사 컨텐츠 축적이 안된다.
4. 원하는 기사를 스크랩하기 어렵다.
이러한 문제들은 클라이언트뿐만 아니라 재직 중인 회사에서도 공통적으로 가지고 있던 문제였다.
실제로 이와 관련된 사용자 리서치를 진행하였는데,
"회사에서 자료를 찾는 게 구글에서 뭔가를 검색하는 것처럼 쉽고 효율적이기를 원한다 (94%)"
"기업의 근무 환경에서 사용되는 기술 역시 아마존이나 인스타그램을 사용하는 것처럼 간편하고 편리한 방향으로 변하기를 기대한다(80%)"
의 결과를 얻을 수 있었다.
즉, 사용자는 현재 사용하는 툴보다 개인화되며 정보 접근이 용이하며 사용에 편리한 툴을 찾고 있었다.
이메일을 사용하는 그룹의 경우 특히 이러한 문제의식을 가지고 있었는데,
조금 더 개인에 맞게 개인화되며 사용이 편리하며 정보 접근이 용이한 툴을 찾고 있었다.
이러한 문제의식으로 "사내 정보 공유 어플리케이션" 어플리케이션을 만들게 된다.
UX를 고려한 화면 설계하기
1. 서비스의 뼈대, IA 설계서 작성
I.A. 는 간단하게 말해서 서비스의 목차 역할을 수행하는 도구인데, 웹 혹은 어플리케이션이 어떻게 구성되는지 보여주며 어떤 기능의 화면으로 보이는가를 전체적으로 보여주는 도구 역할을 한다. 이러한 문서를 통해 개발자와 디자이너가 편하게 작업할 수 있도록 만든 문서이기도 하며 콘텐츠 구성뿐만 아니라 디자인, 개발의 일정 관리도 통합해서 진행한다. 모바일에서는 주로 개발 페이지 목록의 역할을 수행한다.
Flood의 기능 명세서사실 앱잼이라는 특성상 IA를 통한 개발자들과의 소통이 거의 없기에, 각 페이지별로 필요한 정보(data)와 2주라는 짧은 기간 동안 기능적인 우선순위를 적어두는 방식으로 작성을 했다.
이렇게 러프하게 작성한 IA를 바탕으로, 화면의 청사진 Wireframe(와이어프레임)을 그린다.
2. 서비스의 청사진, 와이어프레임(Wireframe)
Adobe xd를 이용한 와이어프레임IA에서 나온 화면의 구성을 토대로 와이어프레임을 그린다.
와이어프레임을 그릴 수 있도록 지원하는 많은 툴들 (Adobe xd, Sketch, Figma 등...) 이 있지만, 당시 나에게 익숙했던 툴인 Adobe xd를 통해 화면을 그려나갔다. 많은 분들이 손 스케치 이후 화면을 그리지만, 개인적으로 툴을 통해 화면을 바로 그려나가는 방식이 편해 XD를 사용해 스케치를 바로 진행했다.
UX설계에 들어가기에 앞서, 우리 어플리케이션과 유사한 서비스에 대한 벤치마킹을 진행했다.
"사내 정보 공유 어플리케이션"라는 주제의 특성상, SNS 형태를 갖춘 UX가 필요했는데 Facebook, instagram 등의 어플리케이션들을 벤치마킹한다.
(좌) 인스타그램 / (우) Facebook이렇게 참고한 레퍼런스로 화면을 구성해 나가는데, 내 서비스의 경우 "정보"를 공유하는 어플리케이션이기에 세 가지의 기능을 더했다.
하나는 상단에 카테고리를 선택하는 영역을 배치시켜 모든 정보들에 대해 카테고리를 분류시켜 정보의 접근을 용이하게 한다는 것인데, 기존 시장의 서비스들과 차별화될 수 있는 중요한 요소이며 사용성 측면에서 가장 핵심적인 기능으로 여겼다.
두 번째는 기존 최신 순으로 정렬하는 순서가 아닌, 상단에 Top 3 게시물을 노출시켜 가장 질 좋은 정보를 보
여준다. 여기에 더해 원하는 기사를 내가 정해놓은 카테고리에 저장하는 "Flip"기능을 추가함으로써 양질의 정보를 아카이빙 할 수 있으며 유의미한 정보들을 노출시킨다.
어플리케이션의 홈 화면. 상단의 Top 3 게시물과 게시물 오른쪽 하단에 정보를 저장하는 Flip기능이 있다.서비스 설계에 있어 중요한 요소가 있는데, 바로 팝업, 알림 창 등 상세한 화면에 대한 설계 및 오류 페이지에 대한 화면을 그리는 것이다. 단순히 보이는 페이지가 아닌, 어떠한 기능이 동작하기까지의 모든 요소들을 고려하여 자세한 화면을 그려나가야 한다.
위 어플리케이션 역시 상세한 화면을 그리기 위해 여러 요소들을 고민하며 그렸는데,
예를 들어 게시물의 경우 텍스트만 있는 것, 텍스트의 길이가 긴 경우, 이미지가 한 장인 경우 or 여러 개인 경우, 파일을 업로드한 경우, 외부에서 URL를 공유한 경우 등 여러 가지 구성 요소들을 생각하며 화면을 설계한다.
동일한 화면임에도 다양한 구성이 존재한다.이렇게 구성된 화면을 바탕으로 디자이너와 협업을 통해 최종적으로 와이어프레임 수정 작업에 들어가며 이후 GUI(graphical user interface)작업을 통해 화면의 색을 입힌다.
해당 제품의 이름은 Flood로, 한글로 직역하면 "홍수"라는 의미이다.
위 네이밍을 가져간 이유는 정보의 홍수를 통해 사용자들에게 유의미한 글들을 많이 공유자는 의미로 지었으며, 홍수의 색인 "파랑"을 브랜드 컬러로 정했다.
사실 블루는 신뢰를 뜻하는 색으로 정보의 신뢰성을 중요시하며 나아가 넘쳐나는 정보 안에 Flood 어플리케이션이 있다는 의미를 내포한다. 그렇게 정한 이름 "정보를 공유하는 가장 쉬운 방법, Flood"의 최종 디자인이 정해진다.
3. 서비스의 최종 산출물, Storyboard
스토리보드는 디자이너 / 개발자가 참고하는 최종적인 산출물이며 서비스에 대한 정책프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의 등 서비스 구축을 위한 모든 정보가 담겨있는 문서입니다.
IA(Information Architecture)과 와이어프레임(Wireframe)이 서비스를 통해 서비스에 대한 전체적인 청사진을 그렸다면, 스토리보드를 통해 어플리케이션의 정책부터 프로세스, 핵심기능에 대한 와이어프레임뿐만 아니라 예외. 오류 처리 등 전체적인 설계가 들어간 문서이다.
사실 해당 프로젝트의 특성상, 합숙을 통해 서비스를 만들기에 엄청 디테일한 화면 설계보다는 러프하게 작성을 했다. 스토리보드에는 화면별 특징과 세부 기능들에 대해 다루었으며, 개발자들이 1차적으로 이 문서를 통해 작업하고 이해가 안 되는 부분 혹은 이슈에 대해 즉각적인 대화를 통해 수정을 하며 진행을 했다.
서비스의 스토리보드. 기능에 대한 상세 설명을 작성한다.이렇게 작성된 문서를 토대로 협업을 거쳐 서비스를 만들어 낸다.
우리들만의 문화를 만드는
Flood 팀의 협업 방법
1. 팀의 문화는 PM이 이끌어가는게 아닌, 모두가 만들어 가는 것이다.
사실 브랜딩은 디자이너의 영역에 가깝다. 메인 컬러를 잡고 우리 서비스가 가져갈 방향성을 정해 이에 맞는 디자인과 텍스트를 구성하는 작업이기에 개발자가 이 작업을 수행하지 않는다. 그러나 우리 팀은 기획,디자이너,개발자 구분 없이 서비스에 대해 서로의 의견을 말하며 함께 수정을 했다. 브랜딩도 그 중 하나로, 서비스에 대한 핵심 가치들을 13명이 모여 하나씩 맞춰 나갔다.
13명이 모여 함께 서비스의 핵심 가치를 정하는 과정이러한 서비스의 핵심 가치를 함께 설정함으로써 "남의 서비스"가 아닌 "우리의 서비스"라는 인식을 부여했다. 단순히 시키는 일에 따라 움직이는 팀이 아닌, 서로 의견이 있을때 자유롭게 의견을 제시하며 서비스를 발전시켰다.
최종적인 의사결정권자가 "Product Manager"가 아닌, 의견이 조율되는 과정을 통해 모두가 의사결정권자가 되는 문화를 만들어냈다.
어떤 프로젝트를 할 때 항상 중요시 여기는 부분은 바로 "주체성을 가지고 본인이 하는 일에 책임을 지는, 사소한 의사결정을 스스로 할 수 있으며 팀 모두가 하나의 방향을 가지고 일하는 것" 이다.
자유롭게 의견을 도출하고 일에 대한 고민을 하며, 모두가 의사결정권을 가지는 것. 이러한 문화를 추구하기 때문에 위 프로젝트도 이를 위해 끊임없이 노력했다.
2. 파트별 이슈를 공유하는 데일리 스크럼 미팅
프로젝트를 진행하면서 하루에 한번씩, 각 파트들과 모여 데일리 미팅을 진행했다. 짜여진 일정을 칸반보드 형식으로 가장 잘 보이는 위치에 배치시켜 일정을 맞춰 나갔으며 이를 토대로 데일리 스크럼을 진행함으로써 진행 과정에서 발생한 이슈들과 문제들 혹은 개발 일정을 수정해나갔다.
벽에 붙은 칸반보드. 매일 이를 보며 파트별 데일리 스크럼을 진행했다.이를 통해 매일 개발 진행상황을 체크하며 각 파트별 상황을 듣고 여러 이슈들에 대해 이야기 함으로써 개발 진행을 조금 더 수월하게 할 수 있으며 나아가 일을 하며 미쳐 놓친 부분들이 체크됐다.
3. 우리의 이야기를 하는 시간, 회고
개인적으로 프로젝트나 일을 할때 회고를 반드시 하는데, 회고를 통해 팀원들이 그동안 미쳐 말못한 부분들과 일을 진행하면서 개선할 부분들을 찾아내는 아주 중요한 자리이다. 오랜 기간 프로젝트를 진행하면 어렵거나 힘든 부분들이 반드시 존재하며, 특히 팀원들끼리의 보이지 않은 갈등들이 존재한다. 이러한 문제점들을 회고를 통해 솔직히 이야기 나누며 팀원들과 서로의 상황을 공유하고 최종적으로 우리 팀이 일을 하며 개선해야 할 부분들을 도출해낸다.
팀원들과 도출한 좋았던점 / 아쉬웠던 점 / 흥미로웠던 점.사실 회고를 하기 전, "회고가 필요한 이유"를 팀원들에게 이해시키지 못했다.
우리 팀은 너무 잘하고 있고, 개선할 점들이 없다고 이야기를 해줬지만, 막상 본격적인 회고에 들어가자 모두 생각이 바뀌었다. 생각보다 말못한 점들도 많았고 우리가 성장하기 위해 필요한 부분 역시 여러가지가 있었다. 이러한 점들 덕분에 팀원들과 나 역시 만족스러운 회고를 진행할 수 있었다.
2주간 모여 진행한 프로젝트.
기획으로써 아이디어 구체화 부터 시작해 약 2달간 프로젝트를 진행했는데, 아쉬움이 크게 남는 프로젝트다. 제대로된 첫 번째 PM 경험이기에 부족한 점도 많았으며 시간에 쫒겨 일했던 기억이 있다. 그러나 이를 통해 어디서든 얻지 못하는 값진 경험을 할 수 있었으며 기획자로써 더욱 더 성장할 수 있었다. Product이 만들어 지는 전체적인 과정을 이해하고 디자이너, 개발자와 협업하는 법. 더 나아가 팀의 문화를 만드는 일은 정말 좋은 경험이였다. 덕분에 소중한 사람들도 얻을 수 있는...
개인의 성장과 사람을 얻을 수 있었다.
긴 글 읽어주셔서 감사드립니다:)
