Praylist의 첫 경험을 재설계하다

기록에서 끝나는 온보딩이 맞을까?

Praylist의 온보딩을 조금 바꾸려고 한다. 현재 Praylist를 처음 실행하면 사용자는 자신이 기도하고 싶은 Category를 선택하고, 첫 번째 Pray를 작성한 뒤 바로 My Praylist로 이동한다. 처음에는 이것으로 충분하다고 생각했다. Praylist를 시작하기 위해 필요한 최소한의 데이터가 만들어지고, 사용자가 빈 화면이 아니라 자신이 직접 작성한 Pray가 있는 상태에서 앱을 시작할 수 있기 때문이다.

기존 흐름은 단순했다.

App Launch
↓
Choose Categories
↓
Write Your First Pray
↓
My Praylist

첫 번째 Pray를 작성하는 것만으로 사용자가 이 앱이 어떤 방식으로 사용되는 앱인지 충분히 이해할 수 있을까?

Praylist는 기도 제목을 모아두는 앱으로 만들고 싶었던 것이 아니다. 기도하고 싶은 것이 떠올랐을 때 기록하고, 바쁜 일상 속에서 잊지 않고 다시 만나고, 반복해서 기도하고, 시간이 지난 뒤 내가 무엇을 위해 기도해왔는지 돌아볼 수 있는 앱을 만들고 싶었다.

온보딩 목표 재정의

그래서 이번에는 온보딩의 목표 자체를 다시 잡았다.

처음 설치한 사용자가 1분 안에 Praylist가 어떤 앱인지 이해하고, 첫 Prayer Habit의 기반까지 만든다.

기존 온보딩은 사용자가 Praylist에 필요한 데이터를 만드는 데 초점이 있었다. Category와 Pray가 만들어지면 앱을 사용할 수 있었기 때문에 기능적으로는 문제가 없었다. 하지만 제품의 목적을 생각하면 사용자가 “무엇을 기록하는 앱인지”뿐만 아니라 “이 기록을 앞으로 어떻게 다시 만나게 되는지”까지 자연스럽게 이해하는 편이 더 중요하다고 생각했다. 그래서 새로운 온보딩에서는 Pray 하나를 작성하는 것에서 끝내지 않고, 사용자가 원한다면 그 Pray를 다시 만날 시간까지 설정할 수 있도록 하려고 한다.

새로운 온보딩 Flow

새로운 Activation 단계는 다음과 같이 구성하려고 한다.

App Launch
↓
Local Data Check
↓
01 / 03
Choose Categories
↓
02 / 03
Write Your First Pray
↓
03 / 03
Set Prayer Time
↓
Notification Permission
↓
Atomic Save
↓
My Praylist

기존의 Category 선택과 First Pray 작성은 그대로 유지한다. 대신 그다음에 Set Prayer Time 단계를 추가하고, 사용자가 알림을 원한다면 Notification Permission까지 자연스럽게 연결한다.

각 단계의 필수 여부는 다음과 같이 나눈다.

| Step | Required | 이유 | | --------------------- | -------- | -------------------------------------- | | Choose Categories | Yes | Pray를 어떤 삶의 영역에 기록할지 결정하기 위해 필요하다 | | Write Your First Pray | Yes | Praylist를 시작하기 위한 최소 Pray 데이터가 필요하다 | | Set Prayer Time | No | 사용자의 기도 방식과 시간은 강제하지 않는다 | | Notification | No | Habit을 돕는 기능이지 Praylist 사용의 전제 조건은 아니다 |

이 구분은 기능적인 편의 때문이라기보다 Praylist의 방향과 연결된다. Category와 First Pray는 Praylist를 시작하기 위한 최소한의 기반이지만, Prayer Time과 Notification은 사용자가 자신의 기도를 지속할 수 있도록 돕는 보조 장치다.

01. Choose Categories

첫 번째 단계는 기존과 동일하게 Category를 선택하는 것이다. Category는 단순히 Pray를 분류하기 위한 폴더라고 생각하지 않는다. 사용자가 자신의 삶을 돌아보며 지금 무엇이 중요한지 생각하게 만드는 시작점에 가깝다.

예를 들어 되고 싶은 나, 가보고 싶은 곳, 해보고 싶은 일과 같은 Category를 보면서 사용자는 자연스럽게 자신이 지금 무엇을 위해 기도하고 있는지를 생각하게 된다. Praylist에서 Category가 중요한 이유도 여기에 있다. 많은 Pray를 무한히 추가하게 만드는 것보다 지금 자신에게 중요한 기도에 집중하게 만드는 것이 더 중요하다.

02. Write Your First Pray

두 번째 단계에서는 사용자가 첫 번째 Pray를 작성한다. 이 단계까지 완료하면 최소한 하나의 Category와 하나의 Pray가 존재하기 때문에 사용자는 빈 앱이 아니라 자신의 데이터가 있는 상태에서 Praylist를 시작할 수 있다.

기존 온보딩은 여기에서 끝났다. 기능적으로 보면 문제가 없지만 제품 경험의 관점에서는 아직 한 단계가 부족하다고 느꼈다. Praylist는 Pray를 저장하는 앱이 아니라 다시 기도하도록 돕는 앱인데, 사용자는 아직 자신이 작성한 Pray를 언제 어떻게 다시 만나게 되는지 경험하지 못했기 때문이다.

03. Set Prayer Time

그래서 세 번째 단계에 Set Prayer Time을 추가하려고 한다. 사용자는 하루 중 자신이 기도하고 싶은 시간을 선택할 수 있다. 아침 7시일 수도 있고, 자기 전인 밤 10시일 수도 있다.

이 단계는 Optional이다. Praylist가 사용자의 기도 시간을 정해주거나 특정한 기도 습관을 강제해서는 안 된다고 생각하기 때문이다. 하지만 온보딩에서 한 번이라도 “언제 기도하고 싶은가?”라는 질문을 보여주는 것은 중요하다고 본다. 이 질문은 기능 설명 없이도 Praylist의 목적을 보여준다.

Write Your Pray
↓
Choose When to Return
↓
Meet It Again
↓
Pray

Praylist가 해결하려는 문제도 사람들이 기도할 내용이 없다는 것이 아니라, 기도하고 싶은 마음이 있어도 그것을 기억하고 지속할 구조가 부족하다는 데 있다. 그래서 Prayer Time은 단순한 알람 설정이 아니라 기록한 Pray와 다시 만나는 시간을 만드는 역할을 한다.

Notification은 이유가 생긴 뒤 요청한다

Notification Permission도 이번 온보딩에서 중요한 부분이다. 앱을 처음 실행하자마자 Notification Permission을 띄우는 방식은 사용하고 싶지 않다. 사용자가 아직 Praylist가 무엇을 위한 앱인지도 모르는 상태라면, 왜 알림을 허용해야 하는지 이해하기 어렵기 때문이다.

반대로 사용자가 먼저 Prayer Time을 설정한 다음 Permission을 요청하면 맥락이 생긴다. 예를 들어 사용자가 “나는 매일 오전 7시에 기도하고 싶다”고 선택했다면, 그다음 Notification은 앱이 보내고 싶은 메시지가 아니라 사용자가 방금 정한 Prayer Time을 기억하도록 도와주는 기능이 된다.

User chooses 7:00 AM
↓
Enable Prayer Reminder?
↓
Notification Permission

Permission을 요청하기 전에 Permission이 필요한 이유를 사용자가 먼저 만든다는 점이 중요하다.

Prayer Time과 Notification을 Optional로 두는 이유는 Praylist의 역할과도 연결된다. Praylist는 사용자를 가르치거나 대신 기도해주는 앱이 아니다. 어떻게 기도해야 하는지 답을 내려주거나 특정한 신앙생활 방식을 강제하는 것이 아니라, 사용자가 자신에게 중요한 기도를 기록하고 계속 이어갈 수 있도록 옆에서 돕는 도구에 가깝다. 그래서 Prayer Time 역시 “매일 이 시간에 기도하세요”라는 의미로 만들고 싶지 않다. 앱이 시간을 정해주는 것이 아니라, 사용자가 스스로 자신의 시간을 정할 수 있게 돕는 방식이어야 한다.

기술적인 개선

데이터 저장 방식도 같이 개선하려고 한다. Category를 선택할 때마다 저장하고 First Pray를 작성할 때마다 바로 저장하는 방식보다, 온보딩에서 만들어지는 데이터를 임시 상태로 관리한 뒤 마지막에 한 번에 저장하는 방식을 고려하고 있다.

selectedCategories
firstPray
prayerTime?
notificationPreference?
↓
Atomic Save

이렇게 하면 사용자가 온보딩 중간에 앱을 종료하거나 이탈했을 때 Category만 만들어지고 Pray는 없는 상태처럼 애매한 데이터가 남는 것을 줄일 수 있다.

온보딩 완료 상태 역시 명확하게 정의할 수 있다.

| Data | Completion Condition | | -------------------- | ------------------------ | | Category | 1개 이상 | | First Pray | 1개 이상 | | Prayer Time | Optional | | Notification | Optional | | Onboarding Completed | Required 조건 저장 완료 후 true |

결국 제품에서 정의한 Activation 상태와 실제 데이터 상태를 최대한 동일하게 만드는 것이 목표다.

온보딩도 하나의 작은 Prayer Journey다

이번 개선을 하면서 온보딩에 대한 생각도 조금 달라졌다. 이전에는 온보딩을 앱에 필요한 정보를 입력하는 과정이라고 생각했다면, 지금은 사용자가 앞으로 반복하게 될 핵심 경험을 가장 작은 형태로 만들어주는 과정에 가깝다고 보고 있다.

온보딩에서 앱의 전체 사이클을 경험할 수 없다. 하지만 온보딩에서 Category를 선택하고, First Pray를 작성하고, Prayer Time까지 정하면 적어도 그 사이클이 시작될 준비는 만들어진다.

다음 날 사용자가 Reminder를 통해 자신이 작성한 Pray를 다시 만나는 순간, Praylist의 진짜 경험이 시작된다. Praylist에서 중요한 UX는 처음 기록하는 순간보다 다시 만나는 순간에 더 가깝고, Pray가 시간과 함께 쌓이면서 결국 하나의 Prayer Journey가 된다.

끝으로

이번 온보딩 개선을 단순히 Prayer Time 기능을 추가했다고 정리하고 싶지는 않다. 실제로 바꾸려는 것은 Praylist를 처음 사용하는 사람이 어디까지 경험한 뒤 앱을 시작하게 할 것인가에 대한 기준이다.

기존에는 First Pray를 작성하면 온보딩이 끝났다. 이제는 한 단계 더 나아가, 사용자가 그 Pray를 다시 만나기 위한 시간까지 생각해보게 하려고 한다.

Before

Category
↓
First Pray
↓
Done

After

Category
↓
First Pray
↓
Prayer Time
↓
Reminder
↓
Return

Praylist의 핵심은 Pray를 많이 저장하는 것이 아니라 자신에게 중요한 Pray를 잊지 않고 다시 만나는 데 있다. 그렇다면 첫 경험 역시 기록에서 끝나는 것보다 다시 돌아올 준비까지 만드는 것이 더 Praylist답다고 생각한다.