지극히 개인적인 앱 기획 프로세스
대부분 설득에 관한 이야기
최근에 회사 동료 2명이 기획을 어떻게 하느냐고 물어왔다. 대답하고 하고 나서 내가 더 정리해보고 싶어서 글로 써본다.
우리 팀은 나, 디자이너 1명, 개발자 3명, 총 5명이 함께 앱을 개발하고 있다. 개발자를 비롯한 팀원 모두가 기획에 참여하는 건 스타트업에서 꽤 흔한 일이다. (다 같이 스토리보드를 그린다는 말로 생각하는 사람은 없겠지.) 우리 팀도 그렇다. 내가 주로 하는 일은 기획안을 작성해서 회의를 진행하는 일과 회의에서 공유하고 결정된 사항을 다시 잘 정리하는 거다.
팀원 모두가 기획 회의에 참여한다고 할 때 팀원들과 공유하고 있는 의사결정방식은 꽤 중요하다. 수평적 조직 문화를 지향하는 경우에 특히 그렇다. 수평적인 조직문화를 가진 스타트업이라면 왠지 민주적으로 다수결로 결정할 거라는 환상이 있을 수 있다. 우리 팀의 경우 논의는 수평적이고 적극적으로 하되, 영역에 따라 의사결정권과 책임은 한 명의 담당자에게 있다는 것을 알고 그 이유를 이해하고 있다.(고 생각한다.) 뽑아서 벽에 붙여놓음.
그렇다고 충분한 논의나 공감 없이 권위나 권한에 호소해서 어떤 결정이 이뤄진다면 같이 일하는 사람들도 짜증 날 거다.ㅠㅠ 일방적인 의사결정이 속도면에서 장점이 있다지만 꼭 그렇지만도 않다. 많은 사람들이 왜 하는지 모르겠는 일에 대해서 몰입도가 떨어지고 결국 업무효율에 영향을 미치기 때문이다. 물론 이왕 결정된 일이라면 빨리 실행해서 결과를 보자는, 책임자의 결정을 따르자는 주의다. 아마 더 많은 고민을 했으리라. 믿어줭...
그래서 기획자는 (적정한 시간을 들여) 본인이 옳다고 생각하는 기획 방향에 대해 동료들을 잘 설득하고 이해시켜야 한다.당연한말이자나 기획이 공감을 얻으면 디자이너와 개발자가 제품에 혼을 넣어준다. 어플리케이션 영혼설.
각기 다른 배경과 직무를 가진 동료들이 제품에 애정을 가지고 기획회의에 참여한다고 가정하면 설득의 과정이 수월친 않다. 기획에 대한 의견은 디자인만큼이나 주관적인 부분이 크고, 제품에 애정이 있는 만큼 원치 않는 방향일 경우 자기 의견을 강하게 피력하기 때문이다. (본인 자존심 등을 이유로 자기 의견만 일관되게 우기는 팀원은 없다고 가정한다.)
누구는 제대로 된 근거를 가지면 설득할 수 있다고 말할 수도 있다. 하지만 생각보다 그렇지 않다. 내가 아직 부족하기도 해서. 권위 있는 학술지나 사용자 데이터를 근거로 내밀어도 그 근거들이 우리 타깃과 서비스와 방향성 등에 맞아떨어지느냐고 따져보면 주장과 반론이 둘 다 맞는 얘기인 경우도 많다.
설득은 완벽한 근거와 논리만으로 하는 건 아닌 것 같다. 그냥 꽂혀서 바로 공감하기도 하고, "나 이건 정말 이렇게 하고 싶어! 사람들이 좋아할 것 같단 말이야!"라는 호소가 먹힐 때도 있다. 어떤 기능은 왜 존재해야 하는가로 실컷 토론을 하는데 어떤 기능은 재밌을 것 같다는 이유로 별 이견없이 다음 업데이트 목록에 이름을 올리기도 한다.
회의를 진행하다 보면 어떤 의견은 이미 많이 고민하고 마음의 결정을 내린 내용일 때도 있고, 중요한 고려사항인데 누락된 것에 대한 내용일 때도 있다. 전자의 경우, 내 지나친 고민의 결과보다 동료의 딱-보고-딱-오는 느낌이 맞을 때도 있었던 것 같다. 후자는 개발 전에 발견했으니 다행이지 싶고.
회의 중에 생각지도 못한 새로운 아이디어가 나오는 경우는 많지 않다. 아무래도 일정한 시간 내에 떠올릴 수 있는 사람들의 생각이 비슷한 것도 이유 중의 하나고, 앱에 넣으려는 어떤 기능 자체가 완벽히 새로운 경우가 별로 없기 때문이기도 하다. 분야가 다르더라도 여러 앱에 이미 잘 구현되어 있는 사례가 많기 때문에 이미 익숙할 수도 있는 여러 가지 방법들 중에서 우리 사용자 우리 서비스에 가장 적합한 형태로 결정하는 경우가 많다. 언젠가 획기적이고 새로운 방식으로 구현하겠어. 막 날아다니고.. 제스처로만 막...
앱 기획 어떻게 하는 거냐는 질문이 스토리보드를 그리고 프로토타이핑하는 법을 알려 달라는 질문이었을지도 모르지만 기획자로서 커뮤니케이션에 대한 고민을 많이 했다 보니 사족을 길게 늘어놨다. 만약 기획회의가 너무 원활하다면 본인이 확실한 카리스마를 지녔거나 참여자들이 별 관심이 없거나가 둘 중에 하나가 아닐까.(배아파)
이제 단계에 따라 어떤 툴을 어떤 목적으로 사용하는지 정리해보겠음.(음?) 초기에 컨셉 잡고 첫 서비스를 오픈할 때나 대대적인 업데이트를 진행하는 상황은 아니고, 일상적인 업데이트에서 사용하는 프로세스와 툴에 대한 내용이다. 리서치와 상위 기획에 대해서는 다음 기회에 정리할 거다. 과연
먼저 하는 일은 다음 업데이트할 기능 정하는 일부터. 이슈나 아이디어들을 쌓아놓는 목적으로 이전에는 트렐로를 썼었는데, 최근에 회사 툴을 통일하면서 깃랩을 쓰고 있다. 주간회의에서 깃랩에 쌓인 이슈들을 다음 업데이트나 다다음 업데이트, 언제가로 마일스톤으로 이동시킨다. 이슈로 쌓여있는 내용들은 버그, 문제, 아이디어, 사용자 의견, 다른 팀에서 필요한 기능 같은 것들이다. 중요도와 긴급도에 따라 우선순위를 정해서 보통 개발 기간이 1~2주 내가 되는 (것으로 추측되는) 선에서 기능을 정한다.
기능이 확정되면 이어 회의 중에 팀원들과 함께 와이어프레임을 그린다. 와이어프레임은 구성요소의 상대적인 중요도를 표시하는 목적으로 그린다고 배웠으나... 그건 그리면서 자연히 녹아드는 것 같고 우리는 상세기획하기 전에 대략적인 구조, 기능 배치에 대한 팀원 간 생각을 동기화하는 목적이 더 크다. 우리가 지금까지 말한 기능이 대충 요래요래 들어가고 요래요래 생긴 거 맞지? 하면서.
간단한 업데이트면 손으로 5분 내로 그릴 때도 있고, 업데이트 규모에 따라 생각을 맞춰가며 그려보면 30분~1시간 정도 걸릴 때도 있다. 검정회색네모네모의 향연. 이 시간 동안에 같은 내용으로 적혀있는 기능을 각자 얼마나 다르게 생각하는지 알 수 있다. ㅋㅋ 같이 와이어프레임을 그려보는 과정은 상세기획 단계에서 너무 많은 길을 돌아가지 않도록 도와준다. 꼭 최종 기획안이 와이어프레임에 기반하고 있을 필요는 없다. 왜 다르게 개선 혹은 변경했는지 설명하면 될 일이다.
다음으로 상세기획이 진행된다. 기능 명세 작성과 화면 그리기를 오가며 스토리보드를 만든다. 스토리보드의 역할은 기획 의도대로 동일한 결과물이 나오도록 하는 것이기 때문에 디자이너와 개발자가 보고 동일한 제품을 원활하게 만들 수 있다면 그 형태는 어떻든 상관없다. 대충 그려도 철석같이 만들어주는 웹 개발자와 일할 때는 프로토타입이 스토리보드를 대체할 때도 있다. 스토리보드 그릴 땐 개발을 진행할 동료들 많이 떠올린다. '이거 알아먹을까? ㅇㅇ알아먹을 거야.', '이건 이렇게 안 하면 분명히 빼먹을 거야.' '이건 표시 안 해도 알아먹을 거야. 아니다 그냥 표시해야겠다.'하면서.
그치만 일반적으로 스토리보드는 꼼꼼하고 상세할수록 좋은 것 같다. 웹앱이 아니고 native앱으로 구현할 경우에는 더욱 그렇다. 한 번 수정하려면... 아이폰은 검수기간이 길고(긴급으로 올려도 거절될 때가 있다.), 안드로이드는 배포 시간이 짧더라도 잦은 앱 업데이트를 사용자가 좋아할 리 없기 때문이다. ㅠㅠ
스토리보드는 파워포인트로 제일 많이 그렸다. 워낙 손에 익은 툴이기도 하고 인쇄해서 보는걸 좋아해서 power mockup을 설치해서 썼다. 지면이 넓어 플로우를 그리기 더 편한 일러나 스케치로도 그려보았지만 무겁기도 하고(뼉다구만 그리는 내가 굳이 디자인 툴을...) 버튼이나 텍스트 요소를 배치하는 것에 집중해야 하는데 나도 모르게 디자인을 하고 있는 나를 막기가 힘들어서 파워포인트로 돌아왔다. A4용지에 갇혀서(?) 화면, 흐름, 상세 설명 포함해서 스토리보드 그리고 A4용지에 촷촷 뽑아보면 괜히 뿌듯하다.
그리고 화면 캡처해서 프로토타이핑을 한다. (디자인단계에서도 한 번 더 프로토타이핑함.) 주어진 시간 내에 가장 나은 UI를 선택하면서 누락된 화면이나 기능을 최소화하려면 프로토타이핑은 정말 필수인 듯. 아주 간단한 기능일 땐 굳이 만들 필요 있을까 싶어서.. 패스 할까 하다가도 만들어보고 후회한 적이 없어서. 지면 위에 누워있는 화면을 보는 거랑 직접 써보는 거는 정말 느낌이 다르다.
프로토타이핑 툴로는 주로 Flinto를 쓴다. lite버전. 그냥 가볍고 빨라서. 사용법도 매우 쉽다. 프로토타이핑 툴은 fidelity에 따라서 high와 low로 구분하는데, 쉽게 말하면 진짜 진짜 같은 거랑 진짜 같은데 가짜 티가 나는 차이다. high fidelity툴로 만들어서 공유하면 개발 다 된 줄 아는 사람도 있단다.
프로토타입을 동작하다 보면 순간 보이는 서비스 텍스트나 사소한 배치들이 사용 흐름을 끊기게 하거나 뭔지 모르겠다는 느낌을 주는 구간을 발견할 수 있다. 전체 흐름을 이미 다 알고 있는 제작자가 아니라 하나의 작은 모바일 화면을 바라보는 사용자 입장에서 더 잘 상상해 보게 된다. 프로토타입은 혼자 해보는 용으로도 만들어 보고 기획안을 공유할 때 스토리보드와 함께 공유해서 피드백을 받을 때도 쓴다.
시나리오상 프로토타이핑할 화면이 20개 정도라고 했을 때 만드는 시간은 5분도 안 걸린다. 오히려 프로토타이핑 시간보다 시나리오에 맞는 콘텐츠를 임의로 넣어두는 게 더 시간이 든다. 커뮤니티 화면에 '이름 들어감. 내용 내용 내용 내용 내용 이곳에 내용이 들어갑니다' 이런 내용을 넣어서 만들었더니 실제 내용이 들어가는 상황을 또 한번 머리로 상상해야 되는 상황이 생기더라. 그래서 '1월의 신부. 제가 어제 예물을 보러 갔는데요...'라고 내용으로 넣어서 만들어본다. 나 혼자 보는 게 아니고 팀원이나 사내 공유/피드백 목적으로 만들 때는 더욱 필요하다.
화면을 스케치로 작업하는 사람이라면 프로토타이핑 툴로 Invision을 더 추천한다. 나는 스케치로 작업하는 게 아니어서 그냥 더 가벼운 Flinto를 쓰지만. 스케치랑 인비전 조합으로 한 번 연동해두면 화면 내 변경사항으로 다시 프로토타입에 반영할 필요 없이 자동으로 반영되어서 짱 편하다. 화면에서 네비게이션처럼 반복되는 버튼들은 일일이 화면 링크할 필요 없이 바로바로 적용할 수 있는 hot spot기능도 내가 좋아하는 기능이다. (Flinto도 원래는 low fidelity만 지원했는데 최근에 좀 더 디테일하게 구현 가능한 Flinto for mac 서비스도 추가되었다.)
우도리님의 UX수업 듣고 뽐뿌와서 진짜 진짜 같은 느낌으로 구현할 수 있는 pixate도 공부해보았으나 진짜 진짜처럼 애니메이션이나 인터렉션을 구현할 수 있다 보니 제작하는데 시간이 많이 걸려서 업무에는 쓰지 않는다. 제품이 디자인만 진행되었고 개발 전인데 중요한 사업 발표가 있다면 그때는 이 툴을 더 잘 배워볼 의사가 생길 것 같다.
이렇게 사용성 테스트를 하더라도 개발 가성비(투입시간 대비 얻을 수 있는 효과 같은 거)를 따지고 우선순위를 정하다 보면 최선의 UX/UI가 선택되지 않을 때가 있다. 사용성을 크게 해치진 않으면서 빠르게 기능을 구현해서 테스트할 수 있을 때가 그렇다.
그렇게 구현된 기능을 보면 괜히 아쉽다. 그럴 땐 '지금 이거 우리만(만든 사람만, 특히 디자이너) 거슬리는 거야. 사용자들은 별로 신경 안 쓸 거야'라고 위로하며 다음을 기약한다. 하지만 가끔은 개발하는 동료가 "이거 되게 번거로운 작업인데 비해 사용자들은 별로 신경 쓸 것 같지 않아. 안 하는 게 좋겠어."라고 할 때 "사용자가 크게 신경 쓰지 않는다는 것엔 동의해. 하지만 승혜가 다른 디자이너들에게 놀림당하면 좋겠어? 이렇게 수정해주라구~~~~!!!"(장난)라고 디자이너를 빌려 기획자나 디자이너 눈에만 보인다는 디테일을 살려달라고 설득할 때도 있다.
기능 선정 → 기획/프로토타이핑 → 리뷰 → 반영 → 리뷰... 과정을 거치다 보통 리뷰 2번 정도 하면 다음 업데이트 기획이 확정된다. 리뷰 할 때 마지막 스퍼트 올려야 한다. 여기서 기능 누락되거나 문제 발견 못하면 개발과정이나 일정이 고달파지기 때문에. 기획이 진행 중인 어느 즈음에 디자이너는 디자인을 시작한다. 어느 정도 확정적인 화면에 대한 디자인 고민을 시작하는 거다. GUI 디자인이 진행되면 화면 내 기능의 배치나 표현방식이 종종 달라진다. 뼈다귀에 옷 입히는 모습 보면 나는 그냥 좋아라...막 디자인될 때 기분이 좋다.
상세기획이 확정되면 서버 api개발을 시작하고, 앱 프론트 개발은 디자인까지 확정되면 시작한다. 이 화면 디자인 확정..!을 외치기 전엔 만들지 않는다. 미리 만들었다간 수정될 수 있다는 거슬... 우리 팀 개발자들은 너무 잘 알고 있기 때무네... 개발이 시작되면 남은 내 할 일은 기능추가병으로부터 나를 자제시키는 것과 기획 간섭들을 다음 업데이트 고려 목록에 추가하는 것 말고는 없다. 아, 개발팀 응원하기. 말 시키지 않기. 그다음 업데이트가 마지막 업데이트에 영향을 받지 않을 경우에는 다음 업데이트 준비가 바로 진행된다.
우리 팀의 경우 나는 인터뷰나 데이터로 사용자 피드백을 수집하는 일과 서비스의 뼈대를 만드는 것을 맡고 있고, 디자이너는 근육과 살을 채워주는 역할을 담당하고 있다. 더 나은 사용자 경험과 우리의 필요 사이를 줄다리기하면서 말이다. 우리의 필요가 이기고 있는거 아니겠지. 팀원 다섯에 분업이 확실하고 같이 앱을 만들어온지가 2년이 넘은 동료들이라 알아서 일정 추정과 관리를 잘해서 ㅎㅎ PM으로서 하는 일은 별로 없다.
팀마다 기획자의 유무와 역할 분담, 개발자를 포함한 팀원들이 기획에 참여하는 정도는 다를 거다. 우리 팀처럼 팀이 직무단위가 아니라 프로젝트 단위로 구성되어 있고 모든 팀원이 기획 회의에 참여하는 경우라면 내 얘기와 더 잘 비교해 볼 수 있을 것 같다. 누구에게든 도움이 되었으면 좋겠다.
프로세스와 툴은 더 나은 업무 환경이나 효율을 위한 거니 본인과 내 팀에게 맞는 걸 취사선택하면 되는 거고, 기획자로서 꾸준히 잘 해야 하는 건 유저 탐구생활 와 커뮤니케이션이라고 생각한다. 나도 이걸 참 잘하고 싶다... 끗.
+
근래에는 기획에 나와 디자이너만 참여해서 팀원간 설득의 시간보다 제품에 대해 생각하는 시간을 더 많이 쓰고 있다. 구성원이 누구냐에 따라 프로세스는 달라진다. (16년 9월 덧붙인 글)
+
또 요즘은 업데이트에는 디자이너가 만든 스케치에 손을 대서 기획하거나 프로토타이핑을 한다. 여름에 framer를 배워서 1번 실무에 써봤는데(https://brunch.co.kr/@shootst/45) 평소엔 적용하기 어렵다.(코딩으로 어느세월에 프로토타이핑해~~) 개발 중에 UI 바꾸기를 돌같이 하던 것도 바뀌었다. (기능추가병은 여전히 자제되지만) 진짜 개발되어 동적으로 움직여야만 발견되는 사용성 문제들이 있다. 테스트 기간 중에 빠르게 더 좋은 안으로 변경하기도 한다. 우리 팀원들이 서로간 더 유연해졌다. (16년 11월 덧붙인 글)
P.S 개발자에게 하고 싶은 말 : 빈틈없는 기획은 버그 없는 소프트웨어래. 빼먹었다고 너무 미워말아. (=3=3=3)
※ 완전 개인경험에만 기반해서 작성한 글입니다. 더 좋은 앱 개발 프로세스/툴에 대한 것이나 개선이 필요해 보이는 부분이 있으면 조언해주세요.
