사이드 프로젝트로 앱 기획하기 #1

기획, 나 잘할 수 있을까

한동안 반복되는 회사 업무에 염증이 생겨있던 나는 무력감에 사로잡혀 있었다. 반복되는 일상을 환기하고자 효과적이고 흥미로운 딴짓을 찾게 되었고 2020년 11월, 나는 재밌는 프로젝트를 시작하게 되었다.

나는 주기적으로 사이드 프로젝트를 참여하는 편이다. 이유는 간단하다. 회사 업무에 매몰될 때면 디자인이 재미없어질 때가 있는데 이럴 때 사이드 프로젝트에 참여하면 해소되는 부분이 있기 때문이다. 사실 그동안 나는 언제나 디자이너로 참여했었는데 이번에는 다른 포지션에서 다른 시각으로 서비스를 출시해보고 싶어서 기획자로 참여 가능한 프로젝트를 찾게 되었다. 이런 소망을 갖던 찰나, 원하는 포지션의 사이드 프로젝트를 찾게 되었고 한 번도 경험해보지 못한 포지션으로 참여할 수 있게 되었다는 게 큰 동력이 될 수 있었다.

약 5개월 간 기획자로 참여하며 배운 값진 경험을 그냥 경험으로 끝낼 수 없어, 기획자 관점에서 서비스를 만들 때 중요한 팁들과 프로젝트에 참여하면서 느꼈던 인사이트를 소개하고자 한다. 기획자 관점에서 만들어 보는 앱 서비스는 무엇을 고려해야 할까. 이번 연재에서 다룰 주제는 다음과 같다.

1. 아이디어 & 아이템 구체화하기
2. MVP 도출부터 요구사항 정의서 작성하기

그럼 지금부터 첫 번째 회고를 시작하겠다.

아이디어 & 아이템 구체화하기

첫 회의는 킥오프로 시작했다. 사이드 프로젝트라는 형태로 모인 만큼 각자가 선호하는 서비스, 해보고 싶은 것, 역량 등이 다양했다. 따라서 아이디어를 먼저 리스트업하고 그 안에서 선호하는 방향으로 좁히고 추후에 선택된 아이디어를 발전하는 방향으로 진행하는 것이 합리적이라고 판단되었다. 첫 정기회의 전까지 각자 생각해 둔 아이디어를 1~2가지씩 제안 후 투표를 통해 아이템을 선정하는 형태로 진행하였다.

정기 회의 전까지 4일 동안 6개의 아이디어가 모집되었다. 나 역시 2가지 아이템을 제안했는데 첫 번째는 구독 관리 서비스였고 두 번째는 스터디 메이트를 찾는 서비스였다. 특히 구독 관리 같은 경우에는 스스로 굉장히 필요하다고 느꼈던 서비스였기 때문에 제안을 하게 되었고 단순히 구독을 관리만 해주는 것이 아니라 함께 구독할 사람들을 매칭도 해주고 가족 중 다른 사람이 결제하는 구독 서비스까지 함께 리스트 업해주는 것까지가 MVP였다. 하지만 큰 난관이 있었는데, 아이디어 소재 자체는 흥미로웠으나 세부 기획까지 진행하려니 일정 상 여유가 없기도 하고 리소스가 많이 들어간다는 점, 자본이 필요하다는 점 등 난해한 부분이 있어 진행하지 못했고 다른 팀원의 환경 보호를 위해 지속적인 실천을 끌어낼 수 있는 아이디어가 더 사이드 프로젝트로 적합하다는 판단 하에 해당 아이디어를 선택하고 발전시키게 되었다.

그렇게 논의를 통해 결정하게 된 우리 팀의 아이템은 환경보호 챌린지 서비스였다.

그린 라이프가 주제인 환경 보호와 생활 습관 개선에 도움을 줄 수 있는 서비스로, 작더라도 실천을 통해 환경 보호에 기여하고 리워드를 받을 수 있는 플랫폼

기능 자체는 굉장히 심플하다. 레벨에 따라 속한 환경 보호 실천 활동을 모두 클리어하면 레벨업을 할 수 있고 챌린지를 통해 다른 사람들도 함께 환경 보호에 참여하고 있다는 것을 인지시키고 지속적인 참여를 유도하도록 하는 것이 우리 서비스의 메인 피쳐다. (+ 챌린지 성공 또는 레벨업을 하면 얻는 에코 포인트로 친환경 기업에서 사용할 수 있는 기능을 통한 수익 창출도 될 수 있다는 비즈니스적 측면도 고려해두었다.)

아래는 우리 팀의 아이템 소개 일부분으로, 선정 배경과 우리 서비스의 가치 등은 다음과 같다.

문제 (배경)

환경 보호를 실천하고 싶지만 정확히 어떤 실천을 해야 되는지 모른다.

환경 보호의 중요성은 알지만 귀찮고 자발적으로 실천하기 어렵다.

나의 사소한 행동이 환경에 미치는 긍/부정적 영향을 잘 모른다.

퍼소나

환경 문제의 심각성을 인지하고 있는 사람

환경 보호를 실천하고자 하나 무엇을 해야 될지 모르는 사람

환경 보호를 실제 일상에서 실천하고 있는 사람

핵심 가설

환경 문제의 심각성을 인지하고, 환경 보호를 실천하려는 사람이 많다.

환경 보호 관련 정보에 대한 수요가 늘고 있으며, 구체적인 실천 방안을 알고 싶어 한다.

번거롭고 귀찮은 행위더라도 이를 통해 내가 얻을 수 있는 이득이 있다면 행동한다.

내 행동의 파급력을 알면 더 큰 보람을 느끼고 더 잘 행동한다.

혼자보단 여럿이 함께할 때 동기부여가 더 잘되며, 중도 이탈률이 낮다.

진입 장벽이 낮은 행동부터 시작하면 습관 형성하기 쉽다.

알림을 통해 지속적으로 인지시키면 참여도가 높아진다.

What I learned

문제를 인지하고 핵심 가설과 서비스 가치를 설계하며 MVP를 설정하는 것까지가 1주 차 진행 목표였다. 사이드 프로젝트를 통해 앱을 만들어보고자 하는 모든 사람들이 다 겪는 고민이겠지만, 세상에 없는 새로운 서비스를 만들어보자는 생각에 집중한다면 틀에 갇혀 아이디어 하나 내기가 어려운 것 같다. 실제 있는 서비스라도 그 안에서 페인 포인트를 찾고 타 서비스와 다른 우리 서비스의 와우 포인트를 설정한다면 문제가 해결되지 않을까. 이번 주차에서는 마일스톤 상 초기이기 때문에 프로젝트의 아이템, 목표, 가설 등에 관한 논의를 많이 했었는데 일정 상 설문이나 리서치가 충분히 이루어지지 않아 개인적으로 좀 더 촘촘하게 설계하지 못한 것 같아 아쉬웠다.

MVP 도출부터

요구사항 정의서 작성하기

아이템이 정리되었다면 이제 아이템을 구체화해야 하는 단계이다. 우리 팀의 최종 아이템은 "환경 보호 챌린지 서비스"이다. 이 서비스에서 정말로 필요한 feature는 관연 무엇일까. 먼저 우리는 몇 가지 핵심 기능을 정리해 보기로 했다. 우리 서비스의 핵심 기능은 크게 두 가지로 앞서 기재한 핵심 가설에서 도출했다.

MAIN FEATURE 01.
레벨에 따라 실천할 수 있는 환경 보호 활동 To Do List

사용자의 레벨에서 실천할 수 있는 활동 리스트를 제공하고 완료 시 배지를 수여함으로써 참여를 유도하고자 했다. 작은 포인트로 레벨업이 될 때마다 적절한 환경 일러스트를 활용하여 자신의 실천 기여도를 시각적으로 노출하고자 했다.

MAIN FEATURE 02.
혼자 하는 실천이 아닌, 함께 실천 함으로써 더 큰 파급력을 줄 수 있는 그린 챌린지

환경 문제에 관심은 있지만 혼자 실천하기 어려운 사람들을 어떻게 참여시킬까. 환경 문제의 경우, 나 혼자만 지킨다고 눈에 띄는 효과가 바로 보이는 문제가 아니기 때문에 나 하나쯤이야 라는 생각을 하기 쉬운 문제하고 생각했다. 따라서 여럿이 함께 같은 문제를 해결하기 위해 노력 중이라는 것을 알게 된다면 중도 이탈률이 낮아질 수 있을 것이라 판단했고 이에 적합한 기능은 챌린지라고 생각했다. 챌린지를 통해 받은 에코 포인트로 다른 챌린지에도 참여할 수 있고 추후 비즈니스와 연결한다면 해당 포인트를 친환경 기업에서도 사용 가능할 수 있을 것이라 생각했다.

서비스의 핵심 기능을 정했다면 그다음 기획자의 역할은 무엇일까. 이제는 설계와 정의가 필요하다. 실제 회사에서 업무 할 때 경험을 생각해보면 서비스를 요청하거나 설명할 때 기획팀에서 전달해주는 필요한 문서들이 있을 것이다. 나는 회사 프로덕트팀에서 디자이너 포지션으로 일하기 때문에 기획팀과의 kick-off meeting에서 전체 플로우나 IA 문서 또는 요청사항 리스트를 받는 경우가 많다. 이렇게 받기만 했던 문서들을 실제 내가 작업해보게 되었는데 시작부터 난관이었다. Flow Chart 정의하는 것은 익숙했지만 요구사항 정의서처럼 ID, 유형 구분, Front&Back, DB 등을 구분하는 것이 익숙하지 않아 어디부터 시작해야 하는지 초반에는 헤매기도 했다. 요구사항 정의서를 작성해보면서 배운 점은 다음과 같다.

통일된 용어와 일관된 양식으로 작성해야 한다.

요구사항 정의서는 실제 필요한 기능들을 정리된 형태로 공유해야 한다. 개발 수용 여부와 완료 여부, 실제 화면 설계서나 IA와 항목 번호를 연결하여 관리하기 때문이다. 따라서 용어가 통일되지 않거나, 본인만 아는 어려운 단어를 사용할 경우 보는 이들이 쉽게 이해하기 어렵기 때문에 간결하면서 직관적인 용어를 사용하는 게 좋다.

유형 구분과 ID는 명확해야 한다.

ID는 요구사항 코드를 활용하거나 기능적으로 구분하는 방법이 있을 수 있는데 하나의 기준을 가지고 작성하는 것이 좋다.

우선순위를 규정해야 한다.

요구사항 정의서는 개발팀과의 협업에서 중요한 문서이다. 따라서 미리 우선순위를 규정해둬야 협업부서와 원활한 커뮤니케이션이 가능하다.

기획자 입장에서는 당연한 이야기겠지만, 문서를 처음 써보는 나의 경우에는 실제로 작성하면서 놓쳤던 부분이었다. 아래는 작성했던 요구사항 정의서의 일부분이다.

What I learned

짧은 마일스톤의 사이드 프로젝트로 진행해본 기획 업무다 보니 실제 회사 업무에서 작성하는 깊이 있는 문서와는 상이할 수 있을 것 같다. 경험해보고 싶었던 문서작성을 해볼 수 있었다는 것에 의의를 두며 실제 디자인 업무만 진행했을 때는 고려해보지 못한 레벨까지 챙기다 보니 시야가 넓어진 느낌이다. 다만 미숙한 부분이 있어 ID나 유형을 어렵게 구분한 것 같아 아쉽고 시간이 좀 더 많았다면 실제 협업에서 사용하는 수준만큼 디테일하게 작성해보고 싶은 부분이다.