han's story

열심히 블로그 글 올리다가 갑자기 사라진 이유...

PM 스쿨 포트폴리오 마스터 반에 들어갔기 때문..

근데 이거 진짜 장난 아니게 빡세다.

정말 정신없이 휘몰아치는 과제들(라고 적고 피피티라고 읽는다)과

어퍼컷 연타로 때리는 피드백

그리고 리터치의 연장..

정신이 없는 수준이 아니라 한 달이 그냥 과제를 하기 위한 달이다.

5월은 가정의 달, 3월은 과제의 달.. (제정신 아님)

분석의 분석의 분석에 머리가 터질 것 같이 아파서 하기 싫다고 딴짓 좀 하다간

어이쿠야 벌써 제출일이 다가와버린다.

예 ,, 그런 삶을 살고 있고요.

친구들에게도 잠시 찡찡거렸는데, 또 이렇게 하면 실력이든 뭐든 많이 늘 거라는 소리를 들으니

맞지.. 해야 늘지. 싶어서. 그럼에도 고통의 길을 걸어야 하는구나 싶어서 몸서리치다가,

잠시 잠깐 잊고 있던 블로그에 들어와 봤다.

이 하잘 것 없고 별볼일 없는 블로그조차도 나의 한 걸음이었다.  (f.여름이었다.)

과거에 나는 PM을 뭐라고 생각했던가,, PM이란 늘 피피티와 발표의 연속이었던가.. 잠시 회고해본다. (물론 개소리다)

나는 여전히 말하는 감자고

다른 동기들은 그 짧은 시간에 어떻게 하는거지? 싶어서 자괴감도 드는 한편,

자괴감 느낄 시간도 없어서 그냥 계속 만들고 만들고 만들고 있다.

물론 근거이니 당위성이니 미래의 내가 보면 이야 이것도 근거라고? 싶을 것 같긴하다.

(왜냐 난 말하는 감자니까.)

그래도... 해야지... 내가 어 처음부터 잘했으면, 돈 내고 수업 듣냐 돈 받고 어디서 일하고 있거나 가르치고 있겠지!

라고 스스로를 다시 치얼업해본다.

여튼 그렇다,, 살아 있기는 하다.. 물론 당분간 블로그는 방치해 둘 예정이다 (이미 끊어뒀던 헬스장도 정지해놨다ㅠㅠ).

아무튼 생존 신고 겸, 이 보잘 것 없는 블로그도 누적 4만을 찍었길래 속으로 (많이) 놀라며 잠깐이라도 방문해줬던 분들에게 심심한 감사의 말씀을 전한다 (어차피 아무도 안 볼 것 같긴하다^^).

들어가며

이번 시간에는 배달의 민족 서비스를 살펴보고 배달의 민족 라이더 가게 찾기 UX 개선 방법에 대해 살펴보려고 한다.

플랫폼 비즈니스 이해

플랫폼이란?
양면 시장을 대상으로 한 사업 모델

양면 시장을 연결해 주는 플랫폼을 운영하며 수익 등의 가치를 창출하는 것

• 광고 비용
• 중개 이용료
• 부가수익 창출

배달 플랫폼 시장

음식을 주문하는 고객과 음식점 사장님 간의 주문을 연결해 주고 라이더가 음식을 받아 고객에게 전달하는 다면 시장 구조

배달 플랫폼 고객과 니즈

수요자: 배민 앱 고객

편리한 서비스 이용

• 다양한 가게와 메뉴
• 빠르고 안전한 배달

공급자: 음식점 사장님

편리한 서비스 이용
합리적인 광고 비용

• 많은 고객 주문량
• 단골 고객 Lock-in
• 합리적인 배달 비용

전달자: 배달 라이더

편리한 서비스 이용

• 많은 배달 요청
• 높은 수익

• 모든 고객을 만족시키기에는 서로 상충되는 니즈가 존재한다.
• 연결되어 있는 니즈들을 고려해서 서비스 기획을 해야 한다.

배달 플랫폼의 프로덕트 구분

음식 주문 흐름으로 프로덕트 구분하기

고객: 주문 → 결제 요청 → 결제 완료  → 주문 수락 → 주문 사항 조회 → 배달 완료

음식점 사장님: 주문 가능 여부 확인 → 주문 발생 → 주문 수락 → 라이더 요청 → 조회 → 라이더 전달

배달 라이더: 배차 수락 → 가게로 이동 → 음식 픽업 → 배달 → 배달 완료

다면 고객을 대상으로 한 배달 플랫폼 프로덕트

고객이 다양한 만큼 배달 플랫폼의 프로덕트도 다양한 고객을 대상으로 구분되어 있다.

프로덕트 매니저의 업무 흐름 알아보기

배달의 민족의 경우
배달의 민족 프로덕트와 도메인이 MSA(Micro Service Architecture) 구조로 이루어져 있어서 대부분의 과제를 유관 프로덕트 부서와 함께 진행하며 때때로 프로덕트의 전체 PO 역할로 참석한다.

과제 진행 프로세스 알아보기

과제: 라이더 가게 찾기 경험 개선 프로젝트 

• 기존 사장님이 이용하는 기능을 확대하는 과제
• 기존 현황 분석을 통해 기능, 운영, 모니터링 정책을 개선하는 작업이 중요

1. 현황 분석 및 문제 파악 

먼저 현황과 문제를 검토하고 해당 과제의 필요성과 해당 과제를 통한 기대 결과를 파악한다.

• 라이더는 어떤 불편함을 겪고 있는가?
• 기존 기능의 문제점은 무엇이며 어떻게 해결해야 하는가?
• 문제를 해결하면 어떤 파급 효과를 가져오게 되며, 충분히 효과적인가?
• 어떻게 문제를 해결하는 것이 가장 합리적이고 효율적인가?

2. 기능에 대한 기획 진행

프로젝트 진행이 결정되었을 경우, 직접적인 유관 부서와 논의 후 상위/상세 기획을 진행한다.

상위 기획 시 고려사항  → 상세 기획 시 고려사항

• 해당 프로젝트의 목적과 해결해야 하는 과제 정의 → 요구사항 별 상세 태스크 정의
• 프로젝트의 전체 스펙과 영향 범위는 얼마나 되는지 확인 → 상세 개발 스펙 정의
• 어떤 방식으로 해당 기능을 운영할 것인지 정의 → 단계별 운영/모니터링 정책 마련

3. 프로젝트 관리 및 성과 모니터링

진행 사항을 꼼꼼히 챙기며 관리 및 진행한다.
개선할 기능이 유저에게 전달된 이후로는 지속적으로 이용 행태와 성과에 대해 모니터링한다.

• 성과 측정 → 추가 개선 사항 발견
• 이용 행태 분석
• 고객 VOC 파악 → 문제 해결 여부 파악

프로젝트 배경 및 목표

라이더의 가게 방문에 대한 어려움 파악

• 크거나 복잡한 건물 안에 가게가 위치해 있어 건물 안에서 가게를 찾는 데 헤매는 일이 많음
  • ex) 백화점 내의 푸드코트, 복잡한 상가
• 가게 방문을 위해 주차를 하고자 하는데 주차장 위치를 알 수 없거나 주차가 어려움
• 가게가 복잡한 골목 안에 위치해 있어 주소지 만으로 가게를 찾기 어려움

프로젝트 진행 내용

기존 기능 분석과 개선 방향 설정

ASIS

• 주소지 정보 외에 가게를 찾는 정보를 안내하는 문구 입력 기능이 있었으나, 고객센터를 통해서만 입력이 가능했음
• 가게 사장님이 직접 입력할 수 없었기 때문에 해당 기능이 널리 활용되지 못하고 이용률이 적었음

TOBE

• 가게 사장님이 직접 입력할 수 있도록 사장님 이용 서비스인 배민 외식업 광장 셀프서비스 페이지에 '라이더 가게 방문 안내' 문구를 입력할 수 있도록 기능 확장

기능 변경 사항

정채 개선안

정책이 달라지는 사항에 대해 여러 부서의 이해관계가 있기 때문에 여러 방안을 마련하여 
유관 부서(사업 운영 부서, 서비스 팀 등)와 논의 후 결정한다.

정책 ASIS

• 입력 가능 채널:
  • 고객 문의를 통해 입력 요청
• 입력 정책:
  • 사장님 문의 요청 그대로 고객센터 담당자가 기입
• 모니터링 채널:
  • 별도 모니터링 정책이 구축되지 않았으며 요청하는 정보 그대로 저장하고 있음

정책 TOBE

• 입력 가능 채널:
  • 셀프서비스에서 사장님이 직접 입력
  • 고객 문의를 통해 내부 관리자 페이지를 통해 입력

• 입력 정책:
  • 1안: 사장님이 등록하면 즉시 저장 및 앱에 반영되며, 사후 모니터링을 통해 작성 불가 케이스에 대해 계도 요청 진행 
  • 2안: 사장님이 등록 요청 → 내부 담당자의 승인을 통해 저장 및 앱에 반영

• 모니터링 채널:
  • 1안: 운영 부서에서 직접 데이터 추출을 통해 일별 모니터링
  • 2안: 해당 문구가 수정/등록될 때마다 내부 모니터링 채널에 연동하여 상시 모니터링

기존 기능 활용 행태 분석

기존에 입력하고 있었던 데이터를 추출하여 사장님이 입력하는 문구를 분석한다.
분석한 내용을 기반으로 어뷰징 방지 및 운영 정책을 수립한다.

작성 불가 예시

• 가게의 실주소를 한번 더 기재하는 문구
• 음식의 특성을 고려하여 배차나 이동 수단을 특정하는 문구
  • 18인치 피자의 경우 자동차 라이더만 수행 부탁드립ㄴ디ㅏ.
  • 면이라 금방 불어버리니 시간 맞추기 어려우신 분들은 배차 잡지 말아 주세요.
  • 픽업 시 보온 가방이 없는 라이더 분은 배차 자제 부탁드립니다. 등
• 가게 방문과 관련 없는 문구
  • 마스크 미착용 시 출입 금지

오픈 후 모니터링

사용자들이 목적에 맞게 잘 사용할 수 있도록 기능 이용 현환에 대해 주기적으로 모니터링한다.

이를 통해 어뷰징 데이터의 비율이 얼마나 되는지, 이에 따른 운영 정책 강화 여부를 검토하고
지속적인 개선을 통해 라이더, 커넥터들이 매장을 방문할 때의 경험이 개선될 수 있도록 한다.

성과 측정

• 단기
  • 해당 기능 이용률
  • VOC 감소 여부 파악
• 장기
  • 배달 시간 개선 여부 파악

이용 행태 분석

• 기능 이용의 어려움은 없는지, UX 등 사용성 개선에 필요한 점은 없는지 분석
• 해당 기능의 목적에 맞게 잘 활용되고 있는지, 어뷰징 사례는 없는지 분석

고객 VOC 파악

• 관련 기능에 대한 반응 파악(긍정, 부정)

프로젝트 성과 정리

1. 기존 기능을 활용해 작업 범위를 설정함에 따라 효율적으로 과제 진행
2. 직관적인 문구 설명과 이용 가이드를 통해 기능, 목적에 맞는 이용률 증대
3. 기존 이용 현황 분석을 기반으로 한 운영 정책 수립으로 어뷰징 케이스 발생률 감소
4. 내부 운영 담당자에게 모니터링 툴 제공을 통해 효율적인 모니터링 운영

프로젝트 사례를 통해 확인할 수 있는 것

• 한정된 리소스로 문제를 효율적으로 해결하는 것도 PM의 역할이다.
• 기존 기능에 대한 레거시와 히스토리를 충분히 파악할 수 있어야 한다.
• 다면 시장에서는 다각면의 고객의 니즈가 연결되어 있음을 고려하여 문제를 정의 및 해결해야 한다.
• 단순히 기능을 만드는 것 외에도 기능이 오픈된 후 효과적으로 운영하기 위한 방안도 고민해야 한다.

나의 생각

배달의 민족 라이더 개선 프로젝트 사례를 통해 다면 시장에서의 문제 정의 방법에 대해 살펴보고 효율적인 대안을 찾는 방법에 대해 살펴볼 수 있었다. 이를 통해 기존 레거시에 대한 이해도가 있어야 리소스를 활용할 수 있다는 것을 배울 수 있었다. 또한 라이더의 문제를 해결하니 동시에 사장님의 고민도 해결된 것을 보고 다면 시장에서는 연결된 고객의 니즈를 찾고 이를 고려하는 기획을 해야 한다는 것을 배울 수 있었다. 나는 아직 사용자(배민에서는 배민 이용자)의 입장에서만 배달의 민족을 사용하니 사장님과 라이더의 경험에 대해서는 제대로 이해해보려 하지 않았던 것 같다. 앞으로 서비스 이용자의 시선에서 벗어나 다양한 고객을 위한 서비스를 만들기 위해서 다각도의 시야를 얻기 위해 노력해야겠다.

들어가며

29CM 고객의 행동을 관찰하고 문제를 정의한 후 가설 설정 및 검증을 거친 사례를 살펴보며 고객 행동을 기반으로 임팩트 있는 기획을 하는 방법에 대해 배운다.

고객의 행동 관찰하기

1. 고객을 직접 만나 보이스를 들어보기

2. 고객이 남긴 데이터를 분석하기

• 고객의 문제를 간접적으로 발견하고 그 원인을 유추하는 방법론

고객은 흔적을 남긴다.
팀에서 달성(개선)하고자 하는 지표를 설정한 후 해당 지표에 가장 직접적으로 영향을 주는 고객의
행동 데이터부터 살펴보는 것이 효과적이다.

29CM 고객 행동 살펴보기

재구매(Retention) 고객을 대상으로 그들의 재구매가 어디서 발생했는지 살펴보면 아카이빙(Like/장바구니)의 비중이 높다.

→ 우리 고객은 아카이빙 기능을 활용해 활발히 재구매를 하는 것으로 보인다.
→ 잘 해석한 것이 맞는지 먼저 살펴봐야 한다.

문제 정의&가설 수립

1. 분석한 고객의 행동이 사실인지 확인하기

데이터 검증을 통해 아카이빙이 재구매에 도움이 되는 것은 사실임을 확인했다.

그러나 모든 고객이 적극적으로 아카이빙 상품을 재구매한다고 일반화하기에는 어렵다.

→ 실제 상품을 아카이빙한 고객만을 놓고 보면 아카이빙 상품을 재구매하는 고객의 비율은 10%가 채 되지 않는다.

단편적인 view로 성급한 결론을 내리면 나머지 90%의 고객으로부터 창출할 수 있는 임팩트 기회를 놓치게 된다.

→ 90%의 고객은 왜 상품을 아카이빙 해두고 다시 구매하지 않는가?

고객 행동의 이유 

시간에 따른 한계 효용을 매우 심하게 체감한다.

→ 구매 타이밍이 지연되다 보면 대다수의 상품이 품절된 아카이빙 채널을 다시 방문하더라도 구매 기회가 박탈된다.

문제 설정

고객은 마음에 드는 상품을 아카이빙해두지만, 시간이 지날수록 해당 상품에 대한 관심이 떨어져 적절한 구매 타이밍을 놓치게 된다.

가설: 고객이 마음에 드는 상품을 잊지 않도록 리마인드 해주면 해당 상품에 지속적인 관심을 갖고 구매할 것이다.

가설 검증

실험: 상품을 장바구니에 담아두고 구매를 하지 않은 고객, 상품을 Like 해두고 구매를 하지 않은 고객을 대상으로 해당 상품을 리마인드 하는 메시지를 발송한다.
검증 지표: CTR(푸시 클릭율), CVR(구매 전환율)

* 고객이 상품에 관심을 가지면 푸시 CTR이 증가하고 관심 상품을 구매하면 CVR이 증가할 것

실험 결과

1. CTR, CVR은 일반 광고 푸시 대비 13배, 10배 높은 수치 기록, 기대 임팩트 대비 144% 초과 달성

2. 고객이 좋아하는 상품을 리마인드 해주는 것만으로 상품에 대한 관심이 지속하고 이 관심이 구매까지 이어진다는 것을 검증

3. 리소스를 투입해 자동화&개인화

결론&러닝

고객의 행동을 잘 관찰하는 것만으로도 새로운 기능, 비즈니스 기회를 발견할 수 있다.

어떤 문제를 왜 풀어야 하는지 뾰족하게 정의하지 않은 채 제품을 기획하면 결국 공급자가 원하는 제품을 만들기 마련이다.

> 이런 제품은 당연하게도 고객의 선택을 받지 못하고 폐기된다.

나의 생각

이번 내용을 통해 단편적인 view를 바라보기보다 더 넓은 기회를 잡을 수 있도록 정의한 문제가 맞는지, 그 문제에 해당하는 고객은 어느 정도인지를 파악해야 한다는 것을 알 수 있었다. 

플랫폼 서비스에 대한 이해

플랫폼이란?

공급자와 수요자 등의 이해 관계자가 얻고자 하는 가치를 공정한 거래를 통해 교환하도록 구축된 환경

• 플랫폼: Plat(넓은) + form(형)

플랫폼 시장의 생태계

• 플랫폼의 가치: 비즈니스 구조+플랫폼이 시스템에 차지하는 비중

플랫폼 개념의 진화

하드웨어(프로세스, 물리적 장치) → 소프트웨어(Windows, iOS, Java) → 서비스(App Store, SNS)

• 하드웨어 플랫폼
  • • 대략 생산을 위한 프로세스 자동화를 목적으로 함

• 소프트웨어 플랫폼
  • 하드웨어를 대체하는 부품 역할에서 시작
  • 여러 기능을 제공하는 공통 실행 환경을 의미

• 서비스 플랫폼
  • 사용자들이 이용하는 다른 서비스 오픈 API 등을 활용해 플랫폼이 제공하는 기능을 이용
  • 충분한 규모의 구매 + 판매자(규모의 경제)
  • 특별한 가치를 갖춰서 사용자를 Lock-in 시켜야 함
  • 소비자•생산자 모두 이익을 가져갈 수 있도록 비즈니스 모델을 설정해야 함

서비스 플랫폼 유형

1. 거래 플랫폼: 거래를 중개하는 역할
2. 생태계 플랫폼: API, SDK 등 플랫폼 내의 인프라를 중계하는 역할
3. 멀티 플랫폼: 확장형 플랫폼, 광고, 수수료, 구독료로 수익

플랫폼 비즈니스 모델의 유형

• 스토어형: 가치교환
  • 대표적인 서비스: 앱스토어
  • 차별화 기술 기반
• 상거래형: 오픈마켓 맞춤형 서비스
  • 대표적인 서비스: 이베이
  • 지속적 확장성
• 웹 서비스 게임 비즈형: 클라우드 컴퓨팅
  • 대표적인 서비스: 카카오톡, AWS
• 체인형: 가치사슬 플랫폼 구축, 현업
  • 대표적인 서비스: 리앤펑(홍콩 세계 최대 무역 회사)
  • 공동의 이익
  • 인센티브 및 공정한 배분

• Agent형: 거래 서비스 제공
  • 대표적인 서비스: 아마존

미래의 플랫폼 서비스

• 메타버스 플랫폼
• 전기차, 플랫폼
• IoT 플랫폼

Super App의 등장 배경

Super App(슈퍼 앱)이란?

하나의 앱에서 다양한 서비스를 제공하는 것

슈퍼 앱

• 앱 내에서 메신저, 모바일 결제, TV, 영화 예매, 택시 호출, 음식 주문, 쇼핑 등 다양한 서비스를 제공함
• 모바일 앱 개수는 1개(모바일 서비스의 개수와 상관없다)
• 앱 실행 후 원하는 서비스에 대한 아이콘을 클릭하여 접근

멀티 앱

• A 사에서 메신저, 모바일 결제, TV, 영화 예매, 택시 호출, 음식 주문, 쇼핑 등의 다수의 모바일 앱을 제공함
• 모바일 앱 개수 = 모바일 서비스 개수
• 원하는 서비스에 대한 모바일 앱을 설치한 후 바탕화면에 있는 모바일 앱을 클릭하여 접근

슈퍼 앱 예시

위챗

• 중국 텐센트 기업이 개발한 메시징 서비스
• 사용자 수 100만이 넘음
• 미니 프로그램을 통해 100만 개 이상의 서비스를 제공함

다양한 Super App의 케이스

Alipay(중국)

• 알비바바의 결제 서비스에서 시작
• 송금, 금융, 대출, 모빌리티, 사진, 번역 등 다양한 미니 프로그램을 제공하는 슈퍼 앱으로 확장

메이투안(중국)

• 배민과 유사한 식품 배달 서비스에서 시작
• 기차표 예매, 티켓 서비스 등의 미니 프로그램을 제공하는 슈퍼 앱으로 확장

Grab(말레이시아)

• 승차 공유 서비스에서 시작
• 월렛, 금융, 음식 배달, 호텔, 게임 등의 서비스를 제공하는 슈퍼 앱으로 확장

한국의 슈퍼 앱

카카오

• 메신저 기반 서비스로 시작
• 카카오 엔터테인먼트, 게임, 페이, 택시, 쇼핑 등을 제공하는 슈퍼 앱으로 확장

카카오 모빌리티

• 택시 호출로 시작
• 대리 운전, 카풀, 자전거 셰어 등의 다양한 서비스로 확장 

네이버

• 검색 포탈에서 시작
• 스마트 스토어, 페이, 마켓, 쇼핑 등을 제공하는 슈퍼 앱으로 확장

토스

• 간편 송금 서비스에서 시작
• 타다 인수 후 모빌리티로 확장

야놀자

• 숙박 서비스에서 시작
• 항공, 모빌리티, 식당, 티켓 등을 제공하는 슈퍼 앱으로 확장

Super App 서비스 기획 프로세스

모놀리식 서비스

• 하나로 연결되어 있어서 내부 요소 간의 의존성이 강함
• 하나의 비즈니스 컴포넌트들이 하나의 강력한 결합 구조를 가지고 통일성이 있음
• 규모가 커지게 될 경우 애플리케이션 구동 시간이 늘어나고 빌드, 배포 시간이 길어지며 유지보수가 어려워짐

마이크로 서비스

• 서비스를 기능 단위로 조직을 해서 독립적으로 운영하게 팀을 조직
• 각 서비스마다 느슨한 연결 구조를 가지고 각각 배포할 수 있게 작은 구조로 쪼개서 아키텍처를 짜는 것
• 각 기능별로 배포가 가능하기 때문에 각각 다른 프레임워크 사용이 가능하며, 다른 기능에 영향을 끼치지 않음

슈퍼 앱 방향성

1. 미니 앱 오픈을 통한 슈퍼 앱 개방

• 다른 업체들이 우리 앱 내에서 자사들의 앱을 만드는 방법

2. 자체 개발을 통한 신규 서비스 기획

• MVP 구현 및 PMF 찾기

3. API 연동을 통한 외부 서비스 연동

1. 회사 우선순위에 따라 연동 카테고리 선택
   • 회사 비전, 고객 분류, 예상 매출액 고려
2. 해당 카테고리의 제휴 대상 업체 리스트업
   • 회사의 규모, 개발력, 사업 방향성 등 고려
3. 해당 대상 업체에 제휴 문의 및 미팅 요청
   • 해당 업체의 업무 우선순위 및 일정 등에 따라 다를 수도 있으므로 2개 이상의 업체에 제휴 문의 필요
   • 해당 업무까지는 사업 개발의 영역이나, 경우에 따라서 기획자가 직접 진행하기도 함
4. 해당 업체의 API 문서 분석 및 연동 일정 공유
   • API 스펙 및 연동 시 플로우, UI 등 구성
5. 연동 작업 진행(개발자), 연동 커뮤니케이션, 테스트 및 배포 작업 진행
6. 데이터 분석, 데이터 분석을 통한 개선 방안 도출
   • 서비스 확장 및 마케팅 작업 등에 대한 고려

나의 생각

앞서 정리한 내용들을 한번 더 살펴보며 플랫폼 서비스에 대한 이해를 높이며, 역시 서비스 기획자는 플랫폼에 대해 자세히 잘 알고 있어야 한다는 점을 알 수 있었다. 그리고 슈퍼 앱이 무엇인지 사례와 방향성과 함께 살펴볼 수 있는 시간이었다. 서비스 기획자는 신규 서비스 기획, 개선뿐만 아니라 서비스 고도화 작업도 진행해야 한다는 점에서 새롭게 알게 되었고, 이미 고도화가 된 서비스들을 바라보는 관점에 대해서도 배울 수 있었다.

또한 앞으로 실무에서도 각각의 경우에 맞게 기획하고 접근할 수 있도록 더 많은 준비를 해야겠다고 생각했다.

오늘의집 서비스 기획 프로세스

1. 프로덕트 백로그 확인 또는 비즈니스 요구사항 수렴
2. 우선순위가 가장 높은 백로그 선정하여 기회평가
   • KPI 설정
   • ICE Scroing 진행
     • Impact, Confidence, Ease를 종합적으로 검토하고 우선순위를 정하는 데 사용하는 프레임워크
     • Conficene, ease 한 서비스도 Impact는 부족할 수 있음(어떤 것 하나가 부족할 가능성이 있음)
     • 따라서 우선순위를 정해서 어떤 것에 포커싱 된 기획안을 작성할 것인지?
     • Impact
       • 백로그 개발 시 Impact를 얼마나 가져올 수 있는지?
     • Confidence
       • 작업을 하면 당신이 원하는 임팩트를 얼마나 가져올 수 있는지?
     • Ease
       • 얼마나 쉽게 구현할 수 있는지?
3. 가설 구체화
4. 초기 기획안 작성(와이어프레임)
   • 초기 기획안: 가설 - 기대효과 - 요구 사항은 간략히 기재
   • 특정 프로젝트의 레퍼런스 or 시각적인 와이어프레임을 포함
5. 프로덕트 팀에 1차적으로 공유하여 피드백 수렴
   • 초기 기획안 관련 피드백: 피드백을 바탕으로 이해 관계자(개발/디자인) 담당자와 보완
6. 피드백을 바탕으로 2차 기획한 생성 후 디자인 작업 진행
7. 디자인 바탕으로 개발자 대상 2차 공유
8. 개발 ROI가 나오지 않는 기능들 축소 또는 제거
   • 개발 ROI가 낮다: 임팩트는 적은데 소요되는 리소스가 많은 경우
     
     • ex) 디자인에서 애니메이션 효과 적용
9. 기획안 확정 및 세부 사항 구체화
10. 개발 진행 중에도 지속적으로 개발 팀과 소통하며 기획안 개선
11. 론칭 후 1차 데이터 확인 후에 성과 관련된 데이터 분석 자료 기획안에 추가
    • 실제로 원하는 기대 효과, 가설에 부합했는지? 이후 단계를 어떻게 진전시켜야 하는지?

오늘의집 PO의 서비스 기획서 훔쳐보기

오늘의집 서비스 기획서 템플릿

문서 버전

• 문서에 변동이 있을 경우 상단 or 하단에 기재하여 파악하기
• 항목
  • 버전
  • 변경 시점
  • 작성자
  • 변경 사항

기회 평가

• 항목
  • 제품 / 기능명
  • 요약(설명)
  • 사업 목표
  • 타깃 유저
  • 유저 문제
  • 설루션(가설)
  • KPI: 메인 지표+가드레일 지표
    • 메인 지표(개선 기대 지표)
      • 가설을 통해서 개선을 기대하는 지표
    • 가드레일 지표
      • 개선의 부작용으로 인해 하락이 있더라도 특정 수치 이상 떨어져서는 안 되는 지표
        • 특정 설루션에서 항상 Trade-Off 관계
        • 메인 지표가 상승하더라도 가드레일 지표가 기준 이하로 하락할 경우 기능 제거 / 실험 폐기
      • 예시
        • 쇼핑몰에서 가입 없이도 물건을 둘러볼 수 있게 해주는 기능을 추가
          • 상품 조회수는 급격하게 상승할 수 있으나 가입 전화율은 반대로 떨어질 것
          • → 가입 전환율이 특정 수치 이상 떨어지지 않아야 함
          • 후행 지표인 리텐션, 매출 하락 여부 확인을 위해 가드레일 지표 설정 → 트레킹
  • ICE Score
    • Impact = Upside + Reach
    • Upside: 매출, 무엇이 좋아지는가?
    • Reach: 그 개선사항을 경험할 수 있는 유저의 수는 얼마나 되는가?
  • Confidence
    • 가설 성공에 대한 확신의 정도
  • Ease
    • 개발 기간, 개발 난도
  • 유관 자료
• 세부 요구사항 (어떤 기능의 개발&디자인이 필요한지 디테일한 부분을 작성)
  • 요구사항 개요
  • 요구사항 디테일
    • 순번(커뮤니케이션 시 편의성 상승)
    • 영역
    • 요구사항
    • As-is
    • To-be
  • 결과 분석
    • 신규 제품 팀 멤버 or 외부 직원이 볼 때 프로젝트 목적/과정/결과를 확인할 수 있어야 한다.
    • 작성자의 의도, 문제점, 기획안, 기획안 결과, 추후 보완점 등 모든 프로세스 파악이 필요하다.
  • 추후 개선 사항 / 적용 과제
    • 과제명
    • 기대효과
    • 우선순위

오늘의집 서비스 기획서 작성하기

문서 버전

• 문서에 변동이 있을 경우 상단 or 하단에 기재하여 파악하기
• 항목
  • 버전: V 1.0
  • 변경 시점: 2021.10.01
  • 작성자: 김경훈(강사/오늘의집 서비스 기획자)
  • 변경 사항: 서비스 기획안 초안 작성

기회 평가

• 항목
  • 제품 / 기능명:
    • 오늘의집 집들이 콘텐츠에서 상품 모아보기 기능 추가
  • 요약(설명):
    • 집들이에서 상품 모아보기 기능을 추가해서 한 번 해당 집들이에서 사용된 제품들을 보고 구매할 수 있도록 해 매출 증진을 도모함
  • 사업 목표:
    • 집틀이 콘텐츠를 통한 매출 증대
  • 타깃 유저:
    • 오늘의집-집들이 콘텐츠를 활용하는 유저
  • 유저 문제 정의:
    • 집들이 콘텐츠에서 유저들이 태그 된 제품을 하나하나 클릭해서 봐야 하며, 집들이 전체에서 사용된 제품 리스트를 볼 수 없음
      • 마음에 드는 제품이 발견될 경우 하나씩 상품 페이지로 이동해서 북마크를 해야 함
  • 설루션(가설):
    • 상품 모아보기 기능을 제공한다면, 유저는 집들이에서 사용된 제품 전체를 쉽게 확인하고 더 많은 제품을 구매하거나 더 많은 북마크를 할 것이다.
  • KPI
    • 메인 지표(개선 기대 지표)
      • 매출: 집들이 콘텐츠를 통한 매출
    • 상품 모아보기 기능 이용률 개선
      • 버튼 클릭률
      • 상품 모아보기 페이지 조회수
      • 상품 모아보기 페이지 내에서의 구매 전환율
      • 상품 모아보기 페이지 내에서 평균 북마크 클릭수
      • 북마크 증가율
    • 가드레일 지표
      • 상품 모아보기 버튼이 추가될 경우 좋아요, 북마크, 댓글 등 다른 버튼의 사용률이 감소할 수 있음
      • 집들이 콘텐츠 평균 조회수 / 집들이 콘텐츠 리텐션 감소
      • 집들이 콘텐츠의 완독률 - 좋아요, 댓글 등도 감소할 수 있음
  • ICE Score 8*6*7 = 336
    • Impact: 영향력 8(1~10)
      • Upside: 상품 조회 편의성 증대를 통한 매출 증대
      • Reach: 오늘의집 - 집들이 콘텐츠를 활용하는 ㄴ유저(Daily 1,000만)
    • Confidnece: 성공에 대한 확신 6
    • Ease: 개발 기간, 개발 난이도 7
  • 유관 자료(근거 제시!!)
    
    • 상품 모아보기와 비슷한 기능의 결과 리포트 제시
    • ...

세부 요구사항

• 요구사항 개요
  • 상품 모아보기 버튼 추가
• 요구사항 디테일
  • 영역
    • 집들이 콘텐츠 초회 페이지
  • 요구사항
    • 버튼 추가
      • 버튼 크기
      • 버튼 텍스트(색상, 크기)
      • 버튼 위치
      • 버튼 색상
      • 버튼 클릭 시 Action: 상품 모아보기 페이지로 이동
    • 상품 모아보기 페이지 추가
      • 레이아웃
      • 상품 순서
      • 상품 썸네일 크기
      • 상품 카드 디자인
      • 뒤로 가기 시 Action
    • As-is
      • 버튼이 없을 때 디자인
    • To-be
      • 버튼이 있을 때 디자인

나의 생각

오늘은 오늘의집의 서비스 기획자가 알려주는 오늘의집 기획 프로세스와 방법에 대해 살펴봤다. 전체적인 흐름을 톺아보며 그동안 공부한 내용들을 전반적으로 다시 짚어보는 시간이 되었고, 기획서를 작성할 때 ICE Score 점수가 중요하다는 것을 알 수 있었다. 기획자는 공력 대비 높은 임팩트를 줄 수 있는 기능을 제시할 수 있도록 유관 자료(근거) 등을 잘 준비하는 것도 중요하다는 것을 알 수 있었다. 

들어가며

이번 시간에는 카카오 기획자가 설명하는 역기획 실습 영상을 듣고 앞으로 진행할 역기획 프로젝트에서 진행 방법을 알아보려고 한다.

표지에 들어갈 내용

1. 소속

2. 제목

3. 소속 팀과 이름

4. 버전

5. 버전 업데이트 날짜

- 카카오에서는 맥북을 사용하기 때문에 대부분 Key Note 툴을 사용한다.

버전 관리 페이지에 들어갈 내용

• 버전에 맞게 작성하며 섹션에 변경된 페이지 작성 후 Description으로 변경된 내용을 작성한다.

중간 페이지에 들어갈 내용

- 대체로 BG는 회색으로 작성

- 중간 페이지가 들어가는 섹션 명을 작성

- 중간 타이틀 기재

카카오톡 채널 역기획 실습

한 가지 기능을 선정해서 진행한다.

채팅 서비스 역기획

카카오톡 채팅: 카카오 비즈니스에서 제공하는 하나의 독립적인 서비스

카카오톡 채팅의 비즈니스 모델: B2B2C

• 사용자와 사업자 모두를 만족할 수 있는 서비스를 제공해야 한다.
• 사용자 사이드에서는 채팅방을 역기획한다.
• 사업자 사이드에서는 채팅방 설정 페이지를 역기획한다.

카카오 비즈니스의 채널 채팅방에 스마트 채팅 기능을 현재는 제공하지 않는다는 가정에서 시작한다. 
신규 CRM 툴 고도화 방향으로 진행

역기획 진행 프로세스

1. 현황 파악

• 사용자가 문의사항을 작성 시 즉각적으로 답변을 해주지 않으면 불편함이 발생
• 24시간 상담을 제공할 경우 사용자 대응에 대한 공수 증가
  • 소규모 사업자의 경우 리소스가 충분치 않아 도입에 어려움

► 1:1 채팅, 챗봇의 Middle Range는 소상공인 → 공수가 많이 들지 않는 CRM 툴 제공 필요

• 중소기업의 수는 가파르게 증가하고 있으나, 이들이 활용할 수 있는 간편한 CRM 툴을 찾아보기 어려움

목표: 소규모 사업자가 활용하기 쉬운 형태의 CRM 툴 제작

* CRM(Customer Relationship Management)

외부 현황 분석

* 내부의 상세한 데이터를 알 수 없기 때문에 신뢰할 수 있는 외부 데이터를 인용한다.

• 근거 데이터: 국가 데이터(중소기업 일반현황)

서비스 레이아웃 구축

1. 사용자 측면

APP 

카카오톡은 채팅방을 기준으로 대화 기능을 제공하는 플랫폼이다.
따라서 사용자들이 카카오톡의 채팅방 포맷에 익숙해져 있음을 인지하고 신규 서비스 기획 시 이런 포맷에 따른 '메시지'를 주요 콘셉트로 접근한다.

Wireframe 작성

• 하프 뷰 형태로 기능을 제공한다.
• 드래그를 통해 비활성화/활성화 페이지를 작성한다.
  • 사용자 인터렉션을 함께 보여주는 것도 중요
• 예외 사항(오류 발생) 상황에 대한 정의를 진행한다.
• FAQ에 대한 내용이므로 노출할 FAQ 리스트의 개수를 지정해야 한다. 
  • 리스트 개수에 따른 근거 제시 필요: 경쟁 서비스의 FAQ 리스트 개수 확인, 서비스 이용자들의 FAQ 평균값 등을 확인
  • 기기별로 다른 화면 크기도 고려
    • Text 수 제한 또는 화면의 특정 %로 차지
      • 2줄로 보이지 않게끔 조절 및 논의 필요

2. 파트너 측면

WEB

• 어드민 페이지는 사용자 측면의 페이지보다 더 많은 정보를 노출하기 때문에 복잡성이 올라간다.
• 스펙 아웃: 이해 관련자와 논의 후 제거하기로 한 기능
  • 스펙 아웃의 경우 가독성 좋게 빨간색으로 표기 후 어떤 버전에서 반영했는지 해당하는 버전의 색상으로 태그 한다.

마치며

역기획의 경우 모든 서비스를 상세 기획하기보다는 서비스의 콘셉트나 서비스의 방향성 같은 부분에 대한 명시를 하는 게 좋다.

• 서비스의 스펙을 모른 상태에서는 작성하기 어려움
  도메인 지식을 쌓아나가 나는 편이 더 좋은 역기획이 될 것
  • 이 서비스는 어떤 방향으로 설정이 되어 있는 서비스인가?
  • 무엇을 목표로 만들어진 서비스인가?
  • 어떤 개선 사항이 있는가?

나의 생각

카카오 기획자의 역기획 실습을 통해 내 수준에서(회사의 내부 데이터를 알지 못하는) 기획 실습을 할 수 있는 방법을 알 수 있었다. 그리고 와이어프레임을 작성할 때 디자인적인 요소를 많이 가미하는 것보다 개발자나 디자이너가 이해할 수 있는 내용을 description 하는 것이 가장 중요하다는 것을 알 수 있었다. 특히 오늘 실습에서는 애플의 key note로 작성했는데, 어떤 툴을 사용하더라도 툴은 툴일 뿐, 내용의 밀도가 중요하다는 사실을 알 수 있었다. 오늘 실습을 통해 사용자 인터렉션을 표기하는 것도 중요하다는 걸 배울 수 있었다.

들어가며

플랫폼 비즈니스, 플랫폼이 어떻게 사업을 창출해 내는지 살펴보고 그 과정 내에서 사용자와 파트너를 고려하는 방법과 이유에 대해 알아본다.

1. 플랫폼 비즈니스란?

플랫폼이란?

수요자와 공급자 간의 거래가 가능하도로 구현된 생테계

• 플랫폼은 각자의 비즈니스 전략, 프로덕트 방향성, 사용자 카테고리, 공급자 카테고리 등에 맞춰 각자에 맞는 성장 사이클을 만들어서 더 지속적으로 성장하는 더 나은 설루션을 만드는 것을 목표로 한다.
• 생태계를 구축하고 수요자와 공급자 간의 거래를 촉진하여 특정 가치를 포착하여 수익을 창출하는 비즈니스 모델
• 공급자, 수요자에 편향된 서비스를 제공해서는 되지 않으며 많은 이해관계자의 니즈를 충족하는 것이 필요하다.

플랫폼 성장 사이클

플랫폼 비즈니스란?

생태계를 구축하고 수요자와 공급자 간의 거래를 촉진해 특정 가치를 포착하고 수익을 창출하는 비즈니스 모델

• B2C 기업의 수익 모델은 기존보다 나은 서비스를 제공하기 위해 사용자 편의를 증대시키는 것
• B2B 기업의 수익 모델은 효율적이고 효과 좋은 설루션을 제공하여 기업과 파트너사의 이윤 창출
• 회사의 생존을 위해 이윤을 추구 → 테크 기업의 비즈니스 모델 = 비즈니스 플랫폼 

2. 플랫폼 기획과 비즈니스 모델

비즈니스 모델 유형

1. 거래 플랫폼

거래 중개

- 특별한 니즈가 있는 사용자와 공급자를 매칭시킨다.

- 공급자와 수요자 양쪽 모두와 거래가 이뤄지도록 한다(거래 자체에 집중).

2. 싱글 플랫폼

인공지능 기반의 기능 제공 플랫폼

- 플랫폼 사업자의 갖춰진 인프라를 기반으로 API나 SDK와 같은 기능(설루션)을 수요자에게 제공한다.

- 공급자가 본인 플랫폼 사업자 자신이기 때문에 공급자가 별도로 존재하지 않는다.

- 싱글 플랫폼의 수요자는 대부분 기업 또는 조식의 형태를 띤다.

3. 멀티 플랫폼

트래픽 기반의 설루션 제공

- 플랫폼 비즈니스의 가장 일반적인 형태를 띤 플랫폼이다.

- 공급자와 수요자를 단순히 매칭시키는 것이 아니라, 공급자도 수요자가 될 수 있으며 수요자도 단순히 서비스를 이용하고 거래만 하는 것이 아니라 공급자가 될 수 있는 다면적인 플랫폼 형태이다.

- 다양한 이해 관계자가 함께 엮인 플랫폼이다.

- 거래 플랫폼, 싱글 플랫폼의 확장판이 멀티 플랫폼이라고 할 수 있으며, 모든 플랫폼의 궁극적인 목표가 되는 모델이다.

거래 플랫폼(2-sided Platform)

가장 기본적인 플랫폼의 형태이며, 플랫폼 사업자는 재고를 소유하지 않고 생태계를 제공한다.

주요 BM: 거래당 수수료 모델

싱글 플랫폼(1-sided Platform)

주로 기술 기반의 플랫폼 기업에서 취하는 형태로, 공급자에게 필요한 기능 혹은 설루션을 제공함으로써 사용료를 받는 방식이다.

주요 BM: 통신별 사용료(Transaction Fee), 기능별 사용료, 월별 사용료

멀티 플랫폼(Multi-sided Platform)

가장 확장된 형태의 플랫폼이며 두 개 이상의 서로 다른 유형의 제휴 고객 간의 직접적인 상호작용을 가능하게 한다.

주요 BM: 광고 비용, 거래당 수수료, 플랫폼 사용료

3. 사용자와 파트너 중심의 플랫폼 기획

광고 플랫폼에서의 균형 잡힌 플랫폼 기획

플랫폼은 광고주와 사용자 사이에서 편향되지 않은 Midrange를 유지하는 것이 중요하다.

• 광고주(비즈니스 파트너): 더 높은 광고 효과를 보기 원하기 때문에 광고 최척화 및 수익 창출을 기대
• 사용자: 광고가 없거나 필요한 광고가 나와서 콘텐츠로 받아들여질 수 있는 플랫폼을 기대

광고 상품 예시

Display AD(DA)

• 큰 면적의 이미지 형태로 제공하는 광고
• 광고는 효과적이지만 소비자에게 피로감을 유발

Search(SA)

• 포털이 많이 활용하는 방식으로 특정 키워드 검색 시 해당 페이지에 노출하는 광고
• 사용자의 행동에 따라 노출되기에 피로감은 적지만 행동이 없으면 광고 노출이 불가능함

Conversation(CA)

• 채팅 서비스를 이용하는 기업에서 활용하는 방식으로 CRM 툴을 제공하는 형식으로 광고 노출

잘못된 설계 포인트의 악순환

광고 지면을 확대하는 경우

• 광고 수익 증대 → 사용자 피로도 증가 → 사용자 이탈 → 광고 효과 감소 → 파트너사 이탈 → 광고 수익 감소

광고 지면을 축소하는 경우 

• 광고 수익 감소 → 사용자 피로도 감소 → 서비스에 투입 가능한 리소스 감소 → 만족도 ↓ → 사용자 이탈

광고 지면 추속가 아닌 로직을 설계하여 사용자들에게 유용한 광고를 적절히 노출하는 것이 중요하다.

퍼포먼스 마케팅과 타기팅

퍼포먼스 마케팅

• 데이터 수집 및 분석 → (디지털 영역) 소비자 행동 트래킹 → 맞춤형 광고 운영 마케팅
• 효율 기반의 마케팅에 해당
• 퍼포먼스 마케팅 중심의 플랫폼 선순환 사이클
  • 광고 효과 up → 사용자 피로도 down, 파트너사 up → 콘텐츠 → 타기팅 고도화 → 광고 효과 up → 광고 수익 up

타기팅 광고

• 성공적인 퍼포먼스 마케팅을 위해 적절한 대상에게 적당한 방법으로 적절한 시간에 맞춤형 콘텐츠를 발송하는 광고 형태
• 타깃팅 광고의 4가지 주요 요소
  • Right Aduience(적합한 사용자)
  • Right Place(적절한 위치)
  • Right Time(적합한 시간)
  • Right Contents(적절한 콘텐츠)
• 4R 요소가 포함된 광고가 효율 좋은 광고에 해당한다.
  • 광고 도달률을 높이기 위해 지면을 늘리기보다는 효과와 단가를 높이는 방식을 책정하는 것이 플랫폼 선순환에 도움이 된다.

타깃팅 광고의 활용 예시

도달 목적의 캠페인 → 잠재 고객 대상 타깃팅 → 액션 사용자 타깃팅

도달 목적의 캠페인

• 캠페인 집행 초기 타깃 사용자층이 명확하게 특정되지 않을 확률이 높다.
• 대규모 광고 집행을 통해 방문 및 가입을 유도한다.

잠재 고객 대상 타기팅

• 방문한 사용자의 이력, 성별, 연령, 유입 경로 등을 파악해 액션을 유도한다.

액션 사용자 타기팅

• 사용자 가운데 50%가 Action 유저인 경우 재액션 가능성이 높아진다.
• 재역선을 유도할 수 있는 콘텐츠를 발행하고 데이터 기반의 광고를 노출한다.
• 다양한 리소스로 여러 방면으로 접근할 필요성이 있다.
  • 단, 규모가 작고 집행 기간이 짧은 경우 A/B 테스트가 더 효과적이다.

• 인포그래픽 데이터: 사용자 개인 데이터를 중심으로 확보한 추정 데이터
• 리타기팅 데이터: 각 사용자의 서비스 활용 내역을 기반으로 타깃팅 하는 기법

나의 생각

오늘 정리를 통해 서비스 플랫폼의 종류와 각각의 특징에 대해 살펴볼 수 있었다. 플랫폼 비즈니스는 결국 멀티 플랫폼으로의 확장을 고려해야 한다는 것도 알 수 있었다. 더하여 사용자와 파트너사를 함께 고려하는 서비스를 분석하고 기획하는 방법에 대해 살펴볼 수 있었다. 

들어가며

이번 포스팅은 아주아주 티끌 같은 토이 프로젝트, 나를 소개하는 앱 서비스 기획을 해보려고 한다.

기획 실무에서 많이 사용하는 문서들을 해당 앱 서비스 기획을 통해 작성해 보고 현업자의 마음가짐을 세팅하려고 한다.

서비스 개요

• '대'자기 PR의 시대에 나를 PR하고 개인을 브랜드화하기 위해 나를 소개하는 앱 서비스를 제공한다.
• 'Device only' 트렌드에 발 맞춰 자신을 언제든지 PR 하고 정리할 수 있는 앱 서비스를 만들고자 한다.

기획 목적

• '나'라는 사람을 소개하고 나 스스로가 삶을 돌아보고 정리할 수 있다.

기대 효과

• 해당 서비스를 통해 '나'라는 사람이 살아온 삶을 어느정도(약 70%) 이해할 수 있다.

주요 기능

• 나의 소개
• 나의 경력
• 나의 활동
• 나의 미래

를 설명하는 화면을 구현한다.

기타 사항

• 웹 서비스는 제공하지 않는다.

Menu Tree 작성하기

안녕하은하세요의 메뉴트리는 3 Depth로 구성했다.

나를 소개하는 서비스다보니 많은 화면을 세분화하기보다 간결하고 명확한 구조로 쉽게 파악할 수 있도록 구성했다.

정보 구조도(IA) 작성하기

Flow Chart 작성하기

플로우차트에서는 크게 회원가입 시 작동되는 플로우와 데이터베이스 간 흐름 등을 고려한 BO와 관리자인 '나'를 특정하기 위한 플로우를 작성했다. 

*플로우차트는 모든 화면 대한 내용을 작성하지는 않았다.

회원가입 flow

관리자 flow

Wire Frame과 Description 작성하기

메인 UI

안녕하은하세요 어플의 메인 화면을 기획하고 기능 Description을 작성했다.

화면 간 이동을 탭 버튼으로 제공하고 한 화면에 많은 정보를 모두 보여주기보다 다른 화면으로 구성해 사용자가 보고 싶은 내용만 따로 살펴볼 수 있도록 구성했다. 또한 프로필 사진은 관리자(나)가 등록한 사진을 보여주며, 여러 장을 업로드할 수 있도록 구성했다.

MBTI UI

다음은 MBTI를 소개하는 화면 와이어프레임이다.  사진과 함께 MBTI와 관련된 '나'의 성격을 소개할 수 있는 글귀를 제공하도록 구성했다.

사용자가 보는 UI와 관리자가 관리하는 UI를 함께 보여줘 개발 및 디자이너들의 이해도를 높였다.

나의 경력 - 나의 직장 UI

다음 화면은 나의 경력 중 나의 직장 와이어프레임이다. 학교 생활과 나의 직장을 각각 상단 버튼을 통해 이동할 수 있으며, 

나의 직장에서는 '나'의 경력 활동에 대한 내용을 보다 자세히 보여줄 수 있도록 구성했다. 또한 관리자(나)는 가장 하단의 노출된 수정 버튼으로 해당 화면의 내용을 수정할 수 있도록 구성했다.

로그인 UI

안녕하은하세요 서비스 외에도 모든 앱 서비스에서 가장 기본으로 다루는 로그인 화면이다. 심플한 디자인으로 필요한 기능만 제공하도록 구성했다. 또한 나라는 사람을 소개하는 가벼운 앱 서비스이기 때문에 가장 많은 사용자를 보유한 네이버와 애플(정책상 필수) 단 2개의 간편 로그인만 제공한다.

다음은 사용자 정보 불일치 및 형식 불일치에 따른 UI다.

회원가입 UI

다음은 자사 서비스에 회원가입하는 화면이다. 

이메일 찾기 & 비밀번호 찾기 UI

이메일 찾기 및 비밀번호 찾기 화면을 기획하며 다른 일반 서비스에도 포함되는 기본 기능에 대한 이해를 높이고자 했다.

데이터베이스에 저장된 정보를 호출해 가입한 정보와 일치한 지 확인하고, 이후 과정을 진행할 수 있도록 구성했다.

나의 생각

나를 소개하는 아주 작은 토이 프로젝트를 진행하며, 한 개의 기능도 허투루 만들어지는 것이 아님을 체감할 수 있었다. 가벼운 과제라고 생각했는데 막상 기획해 보니 각각의 다른 기능들을 하나의 톤 앤 무드로 묶는 것도 어려운 과정이라는 것을 알 수 있었다. 또한 백엔드 및 데이터의 흐름을 고려해 기능과 플로우를 제시하는 것이 서비스의 퀄리티에 많은 부분을 차지한다는 것을 깨닫을 수 있었다. 

시간 관계 상 모든 페이지를 기획하지는 않았지만, 메인 화면 및 서브 화면 기획을 통해 '안녕하은하세요'의 디자인 아이덴티티와 고객에게 제공하고자 하는 정보 셀렉 등을 고민할 수 있었고, 로그인 회원가입과 관련된 화면들을 전부 기획해보고 Flow Chart를 그려보며 모든 회사에서 당연하게 서비스하는 기능을 깊이 있게 탐구할 수 있는 시간이되었다.

아주 작은 프로젝트였지만, 서비스 기획의 가닥을 잡을 수 있는 시간이었다.