상세 컨텐츠

본문 제목

22년차 웹/앱 서비스 기획자의 앱 기획 노하우를 공개합니다

카테고리 없음

by nononi 2022. 11. 17. 23:00

본문

적당한 아이디어 하나를 정하겠습니다.

'자전거 이동 서비스'

자전거를 타고 나갔다가 힘들면 차 타고 집에 돌아오고 싶습니다.

회사 갈 때는 지하철로 갔다가 퇴근길에 자전거를 타고 돌아오고 싶습니다.

(서울 근교로 자전거 싱글 라이딩을 나갔다가 부품이 부러지거나 여분의 타이어가 없는데 펑크가 난 경우 근처의 자전거 샵이 어디 있는지 모릅니다. 내가 있는 여기가 어딘지도 모르겠고. 연락만 하면 근처의 샵이나 집으로 자전거를 가져다줬으면 좋겠습니다.)

자전거를 이동시켜주는 앱 서비스 기획을 시작하겠습니다.

1. 무엇을 하는 서비스인가를 정의하라. (가장 중요)

내 자전거를 내가 원하는 장소로 이동시켜 주는 서비스

단축시켜 '자전거 이송 서비스' 영문으로 sendbike

(자신의 서비스를 단순하게 정의하지 못하고 한참 설명하며 설득하고 있다면 자신의 서비스가 어떤 사람들의 어떤 필요를 충족시켜주고 있는지 모르고 있는 것입니다.  )

도메인은 send.bike으로 합니다.

서비스명을 지을 때 해당 도메인을 살 수 있는지 중요합니다.

com이나 net으로 살 수 없으면 비싸지만 다양한 도메인으로 구입하는 것도 좋습니다.

(휴대폰 번호가 011, 016이던 시절 010으로 일원화된다고 좋은 번호로 빨리 바꾸라 했지만 기다리기만 하다 결국 이상한 번호로 번호 이동하던 기억이 있을 것입니다. 역사를 교훈 삼아 com, net 아니어도) 원하는 영문 서비스명과 일치하는 도메인으로 삽니다.

2. 초간단 서비스 구조를 그려라. (너무 중요)

이 초간단 서비스 구조가 서비스의 척추입니다.

지금의 위치에서 다른 위치로 자전거를 이동시켜준다.

다양한 부가 서비스 요소들도 간단한 기초를 해치지 않는 선에서 붙게 됩니다.

앱으로 '자전거 이동 요청'을 통해 이동시킬 장소를 입력하면 내 자전거를 옮겨주고 언제 어디로 이동하는지까지도 앱에서 확인할 수 있다.

내가 어디 있는지도 모를 곳에서 자전거가 고장 나면 호출 서비스를 이용하여 미캐닉이 부품 차를 타고 와서 자전거를 고쳐준다.

3. 사용자의 예상 사용 방식을 흐름도로 만들어라.

큰 그림은 그렸고 자세한 단계로 들어갑니다.

현재 위치에서 앱을 켜서 이동할 장소를 입력 후 자전거 이동 서비스를 호출합니다.

자전거 이동 서비스가 오면 진짜 자전거 이동 서비스인지 자전거 이동 서비스를 가장한 도둑인지 구별하기 위해 앱에서 인증번호를 사용자와 자전거 이동 서비스에 보내 서로를 확인하게 합니다.

맡긴 자전거는 어느 위치에 있는지 지도에 항상 표시해 줍니다.

찾기로 한 시간에 가서 자전거를 찾습니다. 내가 자전거 찾는 사람임을 증명하기 위해 인증번호를 받아 증명합니다.

내 자전거에 이상은 없는지 혹시 중고부품으로 바뀌어있거나 없어진 것은 없는지 확인합니다.

정상적으로 찾았음을 상태 체크해 자전거 이동 서비스를 완료합니다.

4. 어떤 정보가 필요한지 마인드맵으로 나열하라.

조금 더 신경 써야 하는 부분입니다. 이제 머릿속에서 모두 기억해 내지 못할 자료의 범주입니다.

정보 마인드맵은 화면 작업할 때 어떤 내용을 보여주고 입력할지 확인하게 됩니다.

회원가입 시 회원정보, 자전거 맡길 시 필요 정보, 찾을 시 필요 정보 등

5. 서비스에서 가장 중요한 활동을 5가지 이내로 선택하라.

자전거 맡기기, 자전거 위치 확인, 자전거 찾기, 이용내역

6. 중요도에 따라 메뉴를 만들어라.

이동 요청, 자전거 수령

가장 중요한 메뉴입니다.

7. 기본적으로 있어야 할 메뉴를 배치하라.

긴급 호출, 이동 요청, 자전거 수령, 마이페이지, 고객센터

마이페이지는 로그인 정보, 회원정보, 이용내역을 모아 놓기 위한 메뉴 그룹

고객센터는 문의, 서비스 소개, 이용안내, 공지사항, 이용약관, 개인 정보 취급방침을 담기 위한 메뉴 그룹

긴급 호출을 새로이 만든 것은 내가 있는 곳이 어디인지도 모르는데 자전거가 고장 난 경우 난감함을 해결해주기 위한 출장 서비스로 넣었습니다.

혹은 자전거 사고를 당해서 도움을 요청해야 할 때도 사용할 수 있습니다.

8. 사이트맵을 만들어라.

로딩은 앱이 시작되면서 첫 페이지가 나오기 전까지 잠깐 동안 보일 화면

인트로는 앱을 최초 설치 시 앱에 대한 간단한 소개를 3장 정도 보여줄 화면

메인 페이지는 앱 소개 페이지 이후 첫 서비스 화면이며 앱 최초 설치 이후 항상 앱을 시작하면 처음에 나올 화면입니다.

메인 페이지는 지도 화면이며 내 위치, 자전거 이동 서비스를 사용 중에는 맡긴 내 자전거 위치를 알 수 있습니다. 맡 긴 내 자전거가 2대 이상이면 어떻게 하지??

내 자전거 위치를 클릭할 때마다 다음 자전거, 다음 자전거로 위치를 넘겨주면 무한대로 맡길 수 있겠죠.

자전거를 맡기지 않으면 아무 효용가치가 없는 서비스이므로 비로그인 상태로 사용하다가 로그인을 요구하는 단계에서 로그인을 시킬 수도 있고 처음부터 로그인을 전제로 할 수도 있습니다.

로그인을 전제로 하는 서비스 사이트맵으로 바꾸겠습니다.

 

 

9. 서비스 프로세스를 만들어라.

긴급출동에 대한 서비스 프로세스입니다.

호출을 하려면 현재 위치를 입력해야 하고 현재 위치는 스마트폰의 GPS로부터 받아옵니다.

긴급상황의 종류를 선택하고 연락 받을 이름과, 휴대폰 번호를 확인합니다.

모든 입력항목에 입력이 되었으면 긴급 호출을 할 수 있습니다.

단계를 더 단순화해서 긴급상황 종류를 선택하고 나면 현재 위치를 보여주고 위치정보에서 호출을 할지 말지 버튼을 주면 호출을 위해 단계를 줄일 수 있습니다.

호출 프로세스의 경우 누가 출동하며 출동하는 사람은 비용은 누구에게서 얼마큼 받는가는 기본 기획 이후 세밀한 조정을 할 때 정해야 합니다.

서비스 프로세스는 가설이기 때문에 어떤 방식이 좋은지 다양한 안이 나올 수 있습니다. 서비스 기획의 핵심이라고 할 수 있습니다.

사이트맵을 만들었고 서비스 흐름도를 그렸으면 화면구성의 단계인 스토리보드로 넘어가면 됩니다. 화면 흐름도와 화면별로 코드를 부여하는 것은 할 수 있을 때 하시면 되고 꼭 하려고 시간을 보내는 것보다 화면을 구성하고 출력해서 벽에 잘라 붙여서 흐름을 확인해도 괜찮습니다.

혹은 포스트잇을 통하여 화면 명을 적은 후 서비스 프로세스에 따라 화면이 어떤 순서로 진행되는지 살펴볼 수도 있습니다.

방법은 가장 쉽게 할 수 있는 것으로. 꼭 해야 할 때만!

 

 

10. 화면 흐름도를 만들어라.

화면 흐름도는 페이지 기준으로 링크(페이지 이동)을 보여줍니다.

이쯤 작업했으면 아쉽게 진 게임처럼 머릿속에서 서비스가 모바일로 어떻게 어떻게 흘러가는지 떠올라야 합니다.

화면에 대하여 코드를 부여합니다. 코드를 부여한다는 것은 페이지를 번호로 구분하고 자료를 단계에 따라 2자리 씩 증가시키며 분류하는 방식을 적용합니다.

11. 화면을 만들어라.

이제 화면을 만들 차례입니다.

일단 그립니다.

백지 위에 그리는 경우 그려놓은 네모의 크기에 따라 글씨를 적어놓기 어려울 정도로 여백이 없을 수도 있고 화면에 어떤 요소가 얼마큼 들어가는지 짐작할 수 없을 수도 있어 이를 보완해주기 위해 App UI Sketch라는 것을 사용합니다.

(해외에서는 다양한 스케치 패드를 파는 것 같긴 한대 아쉬운 대로 직접 만들어서 사용하고 있습니다.)

App UI Sketch에 기본 화면을 구상해 놓으면 실제 스토리보드 문서 작업 시에도 유사하게 그려지게 됩니다.

서비스 기획은 스토리보드로 완성됩니다.

 

12. 모바일 화면에는 규칙이 있다.

 

iOS 디자인 가이드, 안드로이드 머티리얼 디자인 가이드와 같은 모바일 가이드들이 존재합니다.

가장 쉬운 참고서는 휴대폰에서 알만한 앱을 켜서 참고하는 것입니다. 왜 이 위치에 이런 것이 있고 클릭 영역은 어떻게 되며 페이지 이동은 어떤 규칙이 있는가 하는 것은 모바일 디자인 영역으로 들어가야 되는 만큼 필요하다면 공부해야 합니다.

수없이 많은 앱을 일상적으로 사용하고 있어도 서비스를 제공하는 입장에서 화면을 만들려 하면 "대체 내가 무슨 앱을 어떻게 사용하고 있었던 것이지?" 막막하기만 할 수도 있습니다.

몇 가지 앱을 자세히 살펴보면 일정한 패턴을 알 수 있을 것입니다.

 

 

돈 주고도 들을 수 없는 너무나 중요한 팁

전제는 도미노이다.

어떤 서비스든 서비스가 잘 될 것이라는 가상의 확장 스토리가 있습니다.

자전거 이동 서비스를 확장하는 계획

'자전거 이동'서비스의 경우 라이딩을 나간 사람들은 반드시 집으로 돌아가야 합니다. 그런데 자전거는 집으로 돌려보내도 라이더는 땀을 흠뻑 흘렸기 때문에 대중교통 타고 집으로 돌아가기 힘드니 샤워 서비스와 티셔츠, 바지, 속옷, 양말을 제공하는 서비스를 제공하겠습니다.

자신의 자전거가 맞는지 확인시키기 위해 NFC 스티커를 발급해서 자전거에 부착하도록 하면 매번 이동 서비스 신청할 때와 수령 시 편리하게 될 것입니다.

이왕이면 패키지로 도시락과 커피도 팔까요? 자전거를 이동시킬 때 정비나 청소 서비스도 좋겠네요. 부품 업그레이드도 쉽고, 자전거 중고 거래 시 배송 서비스까지도 할 수 있을 것 같군요.

잘 되면 다 좋겠지만 이 모든 좋은 이야기들은 다 꿈입니다.

다른 예를 들어보겠습니다.

만나지도 않은 이성과 30주년 결혼기념 여행을 계획하다

내가 관심 갖은  이성과 결혼 30주년에 이탈리아로 한 달 여행을 가면 너무 행복하겠다는 계획은 성공할까요

그런데 결혼 30주년이 되려면 반드시 거쳐야만 하는 단계가 있습니다. 일단 관심 갖은 이성을 만나야 합니다. 서비스 제작입니다.

 연애를 해야 합니다. 서비스 오픈과 운영입니다.

결혼을 해야 합니다. 서비스가 잘 돼서 성장이 된 것입니다.

30년을 기다려야 합니다. 서비스가 중간에 망하지 않고 잘 유지되야 합니다.

결혼 30주년이 되기 위해 이전 단계 하나라도 이루어지지 않으면 결혼 30주년은 이탈리아 여행은 존재하지 않습니다. 도미노처럼 무너져 버리죠.

전제가 여러 개 이면 그만큼 실현 가능성은 낮아집니다.

한 고개만 넘자

서비스 제작을 하는 단계에서 넘어야 할 고개는 한 고개입니다.

이 서비스를 만들어야겠다고 생각했던 그 동기 이유를 충족시키는 것.

많은 사람들은 상상에 그치고 인생을 마치며 많은 창업자와 팀은 서비스를 출시하지도 못하고 와해되며 많은 스타트 업은 서비스를 출시하자마자 서비스를 중단하고 맙니다. 그리고 1년을 넘겨 성장하는 스타트업은 매우 극소수이고 음식 배달, 자취생 이사, 메신저, 사진 공유라고 했을 때 떠올릴 수 있는 서비스는 카테고리 킬러 앱은 손에 꼽습니다.

이것 하나 불편하니 이것 하나 해결하고, 이것이 좋겠으니 이것을 제공하는 일차원적인 서비스 제작이 필요합니다.

한 고개 한 고개 넘어 수도에 도착하다

서비스의 복잡도는 좋은 것들이 하나씩 하나씩 붙으면서 시간을 두고 이루어집니다. 지금 잘 되고 있는 서비스들의 지금이 최초의 서비스 그대로인 경우가 없습니다. 하나씩의 발전 과정을 통해 잘 되는 서비스가 되어 있는 것입니다.

내일 보면 더 좋은 안이 나온다.

오늘 작업해 놓은 것을 내일 보면 '대단히 잘 했는데'라는 생각보다 '어떻게 이렇게 해놨지?!' 싶을 것입니다.

대부분 고치면 이전보다 좋은 결과물을 만들어 낼 수 있습니다. 작게 만들고 계속 고치라는 말과도 일치합니다.

스타트업의 앱 서비스 제작의 경우에서 사용하는 '린'한 방식이나 'MVP'개념은  가설을 작게 세우고 이를 빠르게 증명해서 방향을 제대로 잡으라는 의미가 큽니다.

서비스를 좋게 만드는 단 하나의 원칙

쉽게 단순하게.

적당히 하다 보면 안 한 것이나 마찬가지

"개발기간, 일정에 떠밀려 이것은 그냥 이렇게 하고 이건 이번에 하지 맙시다. 이것도 일반적인 셀렉트로 하고 달력 방식도 구현하려면 시간이 걸리고 화면 로딩도 느리니 하지 맙시다."

이러다 보면 특징적인 사용 방식이 잘려나가 결국 특징 없는 앱이 될 수 있습니다.

특징이 없어도 쉽게 사용할 수 있다면 좋지만 사용하기 불편한데 보기 좋아서 유지하는 것처럼 난감한 경우가 없습니다.

서비스 기획 노하우를 따라 하는 것도 어렵다면

확실히 서비스 기획이 개발에 앞서 필요하긴 한데 직접 하기가 어렵다면 서비스 기획자에게 맡길 수 있습니다.

 planner@nononi.kr

(서비스 기획 프리랜서가 있는 줄 몰랐다. 서비스 기획 외주제작이라는 것이 있는 줄 모르시는 분들이 많습니다. 앱 서비스를 만들고 싶고 좋은 아이디어가 있는데 제작을 해주는 에이전시를 찾아가서 얼마에 만들 수 있는지 물어보면 3,500~5,000만 원, 물어 물어 지인에게 소개받은 개발 프리랜서에게 물어보면 2,000~3,500만 원, 인터넷에서 찾아봤더니 위시켓, 프리모아라는 외주 발주 사이트가 있어 들어가 보니 앱 제작이 2,000~3,000만 원.

비용은 2.500~3.500까지 되는 것 같긴 한데 아이디어만 이야기해주면 알아서 잘 만들어주겠지. 핀터레스트나 에어비앤비 같은 서비스가 만들어질 거야.

매일 앱 서비스만 제작하고 있는 사람들이 만드는데도 그렇게 알아서 잘 만들어지지 않습니다. 무엇을 만들 것인지. 어떤 기능들이 들어가서 어떻게 사용하게 하는 것인지가 제시되어야 합니다.

무엇을 어떻게 만들지의 부분이 서비스 기획이며 서비스 기획의 결과물이자 디자인, 개발의 가이드가ㅏ 되는 스토리보드가 만들어져야 합니다.

비용은 앱 제작 시 최소 2,500만 원이 들며 기획이 총 제작 비용의 1/4 정도 소요됩니다.

팀을 구성해서 직접 만들지 못하는 경우 '턴키'라는 일괄 발주보다 처음에는 기획, 디자인, 개발을 분리해서 단계별로 발주하는 편이 안전합니다.  

제작 과정에 참여되어 어떻게 제작이 되고 무엇이 중요하며 만들고 있는 서비스에 대하여도 이야기를 나누어야 합니다.

서비스 제작에 대하여 잘 모르는 분야라 맡기게 되는데 이번에 마음에 꼭 드는 서비스로 제작이 되지 않았더라도 바로 추가 개발이나 차기 다른 서비스를 제작할 때는  이전 제작 시의 시행착오 없이 의도한 대로 서비스가 잘 나오도록 해야겠지요.

기획 후, 디자인 후 다음 작업을 누구에게 맡길지 소개해 달라는 요청을 거의 대부분 받습니다. 프리랜서를 소개하는데 잘 하는 사람들은 어찌나 바쁜지 필요한 시점에 작업을 할 수 없어 소개, 추천이 불발되는 경우가 많습니다.

파트너 디자이너, 개발자를 통하여 서비스 제작이 될 수 있도록 연결하기도 합니다.)

저에게 서비스 기획을 의뢰하시는 분들은 아래의 링크를 참고해 주세요.

작업의 방식, 기간, 금액에 관한 안내입니다.

https://nononii.tistory.com/7

이메일로 먼저 연락을 주세요.

어떤 것을 만드시려고 하는지 이해하고 미팅을 잡아 구체적인 이야기를 나눌 수 있습니다.

만들려고 하는 서비스에 대한 이야기, 제작의 방식, 어떤 유사한, 잘 되는 서비스들이 있는가 이야기하다 보면 미팅은 3~5시간 하게 됩니다.

여러 에이전시를 만나보고 여러 작업자들과 인터뷰를 해보아도 누가 진짜 잘 하는 사람일까를 알아내기는 어렵습니다. 말 통하는 사람을 찾는 정도랄까. 이런 측면에서 부분 발주가 가장 조심하는 방식이 될 수 있습니다.

팀 합류 권유는 신중하게

"지분 줄 테니 우리 팀에 합류해서 무료로 서비스 좀 만들어 줄래."라는 하지 마세요. 이성을 소개받자마자 "같이 살래" 하는 것처럼 합류할 이유가 전혀 없습니다. 기본적으로 사람들은 사용하고 있지도 않은 남의 서비스에 흥미가 없습니다.

일단 같이 작업을 하면서 서로의 스타일도 잘 맞고 아이템에 대하여 제작자가 흥미를 느끼거나 성공 가능성을 강하게 느끼면 합류하고 싶다고 할 것입니다.

초기 제작 비용을 아낄 의도로 팀 합류를 권유하지 마세요. 빚내서라도 같이하고 싶은 사람이라는 확신이 들 때 합류를 권하시고 팀에 합류한다는 것은 단지 굉장한 제작 능력을 풀타임으로 사겠다는 것이 아니라 운명 공동체가 되겠다는 것입니다. 친구가 된다는 것이죠.

연애하고 결혼하는 것입니다. 보자마자 달려들지 마세요.

아이디어 유출 염려하지 마세요.

매일 새로운 서비스 제안서를 받는 벤처캐피털도 대박 나는 서비스들 죄다 퇴짜 놓습니다. 서비스 제작자들도 많은 아이디어를 듣습니다. 하지만 그 많은 제작자들 누구도 혹해서 남의 아이디어를 훔치지 않습니다. 많이 이야기하면 파악하지 못했던 단점이나 유사 서비스에 대한 정보를 더 많이 얻을 수 있는 장점이 있습니다.  

서비스가 잘 될지 제작자는 모릅니다.

제작자에게 물어보는 것 중에 "이 서비스 잘 될 것 같아요?"가 있습니다. 잘 될지 안 될지는 창업자가 지고 가야 할 부분입니다. 제작자는 잘 될 수 있도록 서비스를 잘 만들어 주는 역할입니다.

스타트업 유의 사항

정부지원사업에 선정되게 해주겠다는 브로커 조심

법인명을 빌려줄 테니 아이디어를 가지고 같이 정부지원사업에 지원하자고 하는 경우 고용된 노동자로 전락될 가능성이 큽니다. 문서상 모든 소유권은 지원 주체인 법인이 됩니다. 절대같이 하지 마시길.

정부지원사업을 받게 해줄 테니 돈을 달라거나 지원금의 일정 비율을 달라는 경우 모두 안 됩니다.

투자하겠다고 하고 투자가 지연되는 경우

스타트업은 투자에 목말라 있어 몇 천만 원이라도 투자하겠다고 하면 내 서비스의 가치를 알아봐 주는 사람이 생겨 신이 납니다. 그러나 계약이나 투자나 통장에 돈이 들어와야 투자입니다. 투자를 해주겠다는 곳에 목매지 마세요. 투자도 서비스의 구성 요소 중 하나입니다. 돈만 있다고 어떤 서비스가 나올 수 있는 것은 아닙니다. 수많은 아이디어, 수많은 창업자, 수많은 제작자가 있는 것처럼 수많은 돈입니다.

이면계약 요구

아이템은 너무 좋습니다. 서비스가 엄청나게 성공할 것으로 기대됩니다. 1차 투자로 10억, 2차로 100억, 3차로 1000억 단위로 갈 수 있습니다. 단 창업자의 전문 경영인으로서의 네임밸류가 약해 투자에 걸림돌이 될 수 있으니 서류상 대표를 다른 사람으로 하고 지분관계에 대하여 이면계약을 해드리겠습니다.

일단 아이템이 대단하다고 평가한 것에 대하여 기뻐하세요. 그리고 당장 미팅을 끝내고 자체적으로 서비스를 만들어 오픈하세요.

정도를 걸어라

할 수만 있다면 첫 서비스는 가능한 크기 내에서 빠르게 만들어 서비스가 좋다는 것을 검증시켜야 합니다.

투자유치, 사업설명, 정부지원사업 문서작성, 도움이 될지도 모르는 네트워킹 행사 참석에 시간들이기 보다 서비스를 만들고 더 좋은 서비스가 되도록 고민하는데 시간을 써야 합니다.

마케팅에 돈을 들이고 싶은 유혹

서비스는 잘 만들었는데 알리지 못해서 망하면 어떡하지. 제작 비용은 최소 홍보는 크게. 투자 받으면 우리도 빨리 알릴 수 있을 텐데.

망하는 스타트업의 공식입니다.

첫 번째: 서비스. 즉 제품입니다.

서비스를 더 잘 만드세요.

두 번째: 홍보

좋은 음악을 들려주고 싶은 마음입니다. 좋은데 몰라서 못 쓰는 사람들에게 알려주는 것입니다.

세 번째: 투자

서비스가 좋고 투자 가능성이 있으면 투자하게 될 것입니다.

사람에게 투자하기 때문에 팀 구성이 가장 중요하다는 말을 많이 듣습니다. 그러나 어떤 투자자도 망하는 좋은 팀에게 투자하지 않습니다.

결론

단순화해서 서비스를 일단 만들자. (서비스 기획 공개했어요)

서비스를 계속 발전시키되 하나씩 고쳐나가자.

좋은 서비스를 만들고 나서 팔러 다니자. 홍보든 투자든

댓글 영역