docs(docs): 문서를 화면과 용도별 폴더로 재구성
This commit is contained in:
61
docs/screens/app/08_app_reframe_strategy.md
Normal file
61
docs/screens/app/08_app_reframe_strategy.md
Normal file
@@ -0,0 +1,61 @@
|
||||
# VibeRoom `/app` 프로덕트 고도화 및 수익화 기획안
|
||||
|
||||
## 1. 문제 정의: 왜 `/app`의 존재 의의가 애매해졌는가?
|
||||
현재 `/app` 화면은 단순히 '목표를 하나 입력하고 `/space`로 넘어가는 정거장' 역할만 수행하고 있습니다.
|
||||
사용자 입장에서는 "어차피 `/space`에서 타이머 돌리고 일할 건데, 굳이 `/app`이라는 별도 화면에서 목표 하나만 달랑 쳐야 하나?"라는 기능적 회의감이 들 수밖에 없습니다. 즉, **경험적 가치(UX Value) 없이 Depth만 하나 늘어난 상태**입니다.
|
||||
|
||||
## 2. 타겟 인사이트: ADHD & 프리랜서의 심리
|
||||
이 서비스의 핵심 타겟은 **ADHD 성향을 가진 사람들과 혼자 일하는 프리랜서**입니다. 이들의 가장 큰 페인포인트는 다음과 같습니다.
|
||||
1. **시작의 두려움 (High Activation Energy):** '무엇을 해야 할지'는 알지만, 첫 단추를 꿰는 것을 극도로 미룹니다.
|
||||
2. **작업 기억 용량 초과 (RAM Overload):** 머릿속에 해야 할 일과 잡념이 뒤엉켜 있어 하나에 집중하지 못합니다.
|
||||
3. **도파민 갈구 (Dopamine Seeking):** 즉각적인 피드백이나 보상이 없으면 쉽게 지루해하고 이탈합니다.
|
||||
|
||||
## 3. 핵심 전략: `/app`을 '단순 입력창'에서 **'몰입을 위한 의식(Ritual)의 공간'**으로 재정의
|
||||
최고의 서비스는 사용자에게 '행동'을 요구하기 전에 '감정'을 만져줍니다. `/app`은 투두리스트(To-do)를 적는 곳이 아닙니다. **복잡한 현실에서 벗어나, 고도의 집중 상태(`/space`)로 들어가기 전 마음을 다잡고 준비 운동을 하는 '감압실(Decompression Chamber)'**이 되어야 합니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. `/app` 공간의 4가지 핵심 기능 기획
|
||||
|
||||
### A. Brain Dump (뇌 비우기) & The One Thing
|
||||
ADHD 유저에게 "지금 할 목표 하나만 적으세요"라고 하면 오히려 압박감을 느낍니다.
|
||||
- **기능:** 머릿속에 맴도는 모든 잡념과 해야 할 일들을 일단 마구잡이로 쏟아내게 합니다(Brain Dump).
|
||||
- **UX:** 쏟아낸 여러 항목 중 **"지금 당장 딱 하나만 쥐고 `/space`로 들어갑시다. 나머지는 저희가 안전하게 보관해 둘게요"**라며 단 하나의 목표(The One Thing)를 선택하게 유도합니다.
|
||||
- **효과:** 머릿속 RAM을 비워줌으로써 인지적 과부하를 해결하고 안도감을 줍니다.
|
||||
|
||||
### B. Micro-Stepping (초소형 첫 단계 쪼개기)
|
||||
"제안서 작성하기"라는 목표는 너무 거대해서 시작을 미루게 만듭니다.
|
||||
- **기능:** 유저가 큰 목표를 선택했을 때, "이 목표를 위해 지금 당장 할 수 있는 5분짜리 행동은 무엇인가요?"라고 묻습니다.
|
||||
- **UX:** "제안서 폴더 열기", "노션 새 페이지 만들기" 수준으로 목표를 극단적으로 잘게 쪼개도록 유도합니다.
|
||||
- **효과:** 시작의 허들(Activation Energy)을 바닥까지 낮춰줍니다.
|
||||
|
||||
### C. Commitment Ritual (몰입 세팅과 선언)
|
||||
`/space`에 들어가서 환경을 바꾸는 것이 아니라, `/app`에서 오늘 나를 도와줄 환경을 선택하고 '입장'하는 것이 하나의 의식이 되어야 합니다.
|
||||
- **기능:** 목표를 정한 후, 오늘 나의 기분에 맞는 **Vibe(배경 씬 + 백색소음)**와 **Pace(뽀모도로 25분 / 딥워크 50분 등)**를 선택합니다.
|
||||
- **UX:** 세팅을 마치고 "집중 모드 진입하기" 버튼을 누를 때, 시각적/청각적인 전환 효과와 함께 비행기가 이륙하듯 `/space`로 부드럽게 빨려 들어가는 연출을 줍니다.
|
||||
|
||||
### D. Momentum & Streak (과거의 작은 성공 시각화)
|
||||
- **기능:** `/app` 화면 한 켠에, 최근에 내가 해냈던 작은 몰입 세션들의 기록(잔디 심기, 자라나는 식물 등)을 시각적이고 감성적으로 보여줍니다.
|
||||
- **효과:** "어제도 해냈으니 오늘도 할 수 있다"는 자기 효능감을 심어주어 도파민을 자극합니다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 비즈니스 모델(BM): 기꺼이 돈을 내게 만드는 수익화 전략
|
||||
|
||||
유저가 제품에 깊이 몰입하고 나면, 다음과 같은 **PRO 플랜(구독 모델)**을 통해 수익화를 달성할 수 있습니다.
|
||||
|
||||
1. **AI Micro-Stepping Coach (AI 목표 쪼개기 및 코칭)**
|
||||
- **무료:** 유저가 직접 첫 단계를 고민해서 적어야 함.
|
||||
- **PRO:** "기획서 쓰기"라고 치면, AI가 [1. 레퍼런스 3개 찾기, 2. 목차 5개 적기, 3. 서론 쓰기] 등으로 즉각 분해해주고 응원의 메시지를 건넴. (ADHD 유저에게 압도적인 가치 제공)
|
||||
2. **Premium Vibes (독점 씬 & 사운드스케이프)**
|
||||
- **무료:** 기본 자연음(숲, 비투비) 2~3종 제공.
|
||||
- **PRO:** 유명 아티스트가 작곡한 Lo-Fi 집중 비트, 세계 유명 도서관/카페의 3D 공간 음향, 초고화질 동적 배경(비 오는 도쿄 야경 등) 무제한 접근.
|
||||
3. **Deep Focus Analytics (심층 분석 리포트)**
|
||||
- **무료:** 오늘 하루 총 집중 시간(단순 타이머 기록)만 확인 가능.
|
||||
- **PRO:** 웹 서비스의 한계를 극복하기 위해 **세션 종료 후 유저가 직접 평가하는 '집중도 점수(1~5점)'와 Page Visibility API를 활용한 '탭 이탈(딴짓) 횟수 기록'을 결합**합니다. 이를 통해 단순히 켜둔 시간이 아니라 어떤 사운드/환경에서 가장 '질 높은' 집중을 했는지, 요일별 언제가 집중 Peak Time인지 분석하여 나만의 최적화된 루틴을 제안합니다.
|
||||
4. **Calendar & Notion Integration (업무 툴 연동)**
|
||||
- **PRO:** 구글 캘린더의 일정이나 노션의 Task를 `/app`의 Brain Dump로 자동 불러오고, 집중 세션이 끝나면 소요 시간과 함께 자동으로 기록/동기화됨. (프리랜서들의 필수 니즈)
|
||||
- **기술적 실현 가능성 (Feasibility Check):** 웹 서비스 환경에서도 **OAuth 2.0 기반의 Google Calendar API 및 Notion API**를 연동하여 완벽히 구현 가능합니다. 서버에서 유저의 접근 권한 토큰을 관리하여 웹 클라이언트와 외부 서비스 간의 양방향 데이터 동기화를 지원할 수 있습니다.
|
||||
|
||||
## 요약 (Next Action)
|
||||
`/app`은 단순히 데이터를 넘기는 껍데기가 아니라, **유저의 마음을 달래고(Brain Dump), 허들을 낮춰주며(Micro-Stepping), 몰입을 세팅(Ritual)하는 심리적 안전기지**가 되어야 합니다. 이 경험이 탄탄해지면 유저는 VibeRoom을 단순한 타이머가 아닌 '나의 루틴 파트너'로 인식하게 되며, AI 코칭과 프리미엄 환경을 위해 기꺼이 지갑을 열게 될 것입니다.
|
||||
437
docs/screens/app/15_app_stats_entry_flow_spec.md
Normal file
437
docs/screens/app/15_app_stats_entry_flow_spec.md
Normal file
@@ -0,0 +1,437 @@
|
||||
# 15. `/app -> /stats -> /app` Weekly Review Entry Flow Spec
|
||||
|
||||
Last Updated: 2026-03-15
|
||||
|
||||
이 문서는 VibeRoom의 `Weekly Review`를 **어디서, 왜, 어떤 타이밍에 열어야 하는지**를 정의하는 진입 플로우 문서다.
|
||||
|
||||
핵심 목적은 하나다.
|
||||
|
||||
> `/stats`를 고립된 summary page가 아니라, `/app`의 다음 세션 시작 성공률을 높여주는 review ritual로 코어 루프 안에 넣는다.
|
||||
|
||||
관련 문서:
|
||||
|
||||
- `./19_app_atmosphere_entry_spec.md`
|
||||
- `../../product/12_core_loop_execution_roadmap.md`
|
||||
- `../stats/14_weekly_review_reframe_spec.md`
|
||||
- `../../product_principles.md`
|
||||
- `../../current_context.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 문제 정의
|
||||
|
||||
현재 구현 기준에서 `/stats`는 route는 존재하지만,
|
||||
제품 루프 안에서의 진입 이유가 약하다.
|
||||
|
||||
현재 문제:
|
||||
|
||||
- `/stats`는 사실상 고립된 페이지다
|
||||
- 사용자가 왜 지금 review를 봐야 하는지 맥락이 없다
|
||||
- `/space`에서 바로 review로 튀면 execution 흐름을 끊는다
|
||||
- `/app`과 `/stats`가 연결되지 않아, review가 다음 세션 시작으로 이어지지 않는다
|
||||
|
||||
즉, 지금 `/stats`는 “있을 수는 있는 페이지”지만
|
||||
**사용자가 자연스럽게 보게 되는 페이지는 아니다.**
|
||||
|
||||
---
|
||||
|
||||
## 2. 한 줄 정의
|
||||
|
||||
> Weekly Review의 primary flow는 `/app`에서 review teaser를 보고, `/stats`에서 지난 7일의 집중 리듬을 짧게 정리한 뒤, 다시 `/app`으로 돌아와 다음 세션을 시작하는 흐름이다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 제품 원칙
|
||||
|
||||
### 1. `/stats`의 primary entry는 `/app`이다
|
||||
|
||||
- review는 “지금 일하는 중에 보는 것”이 아니라
|
||||
- “다음 세션을 시작하기 직전에 확인하는 것”이다
|
||||
|
||||
### 2. `/space`는 review의 메인 진입점이 아니다
|
||||
|
||||
- `/space`는 execution surface다
|
||||
- review는 boundary ritual이어야 한다
|
||||
- `/space`에서는 teaser만 허용하고, full review로의 강한 유도는 금지한다
|
||||
|
||||
### 3. review는 다음 행동으로 연결되어야 한다
|
||||
|
||||
- `/stats`는 읽고 끝나는 페이지가 아니다
|
||||
- 마지막 CTA는 반드시 `/app`의 next session start와 연결돼야 한다
|
||||
|
||||
### 4. review 진입은 “보면 좋음”이 아니라 “지금 보면 의미 있음”이어야 한다
|
||||
|
||||
- 무조건 항상 띄우지 않는다
|
||||
- 데이터가 충분하고, 지금 보는 것이 실제로 의미 있을 때만 노출한다
|
||||
|
||||
### 5. review는 planning이 아니라 focus optimization이다
|
||||
|
||||
- 할 일 정리로 이어지면 실패
|
||||
- 다음 세션의 시작 조건을 더 잘 맞추는 흐름이어야 한다
|
||||
|
||||
---
|
||||
|
||||
## 4. 왜 `/app`이 primary entry인가
|
||||
|
||||
`/app`은 commitment gate다.
|
||||
즉 사용자가 “지금 한 가지를 붙잡고 들어가겠다”는 결정을 내리는 곳이다.
|
||||
|
||||
review가 가장 유의미한 순간도 바로 여기다.
|
||||
|
||||
왜냐하면:
|
||||
|
||||
- review를 보고 바로 다음 세션을 시작할 수 있다
|
||||
- `/space`보다 맥락이 느슨해서 회고가 자연스럽다
|
||||
- `/stats`를 planner page처럼 쓰지 않고 entry ritual로 흡수할 수 있다
|
||||
|
||||
반대로 `/space`는:
|
||||
|
||||
- 이미 실행 중인 화면이고
|
||||
- review가 들어오면 흐름을 끊고
|
||||
- 제품을 dashboard처럼 보이게 만들 수 있다
|
||||
|
||||
결론:
|
||||
|
||||
- `/app`은 review를 여는 문
|
||||
- `/stats`는 주간 review desk
|
||||
- `/app`으로 돌아와 다시 시작
|
||||
|
||||
이 삼각 구조가 가장 맞다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 사용자 플로우
|
||||
|
||||
### Primary Flow
|
||||
|
||||
`/app -> /stats -> /app`
|
||||
|
||||
1. 사용자가 `/app`에 들어온다
|
||||
2. entry stage 바깥의 quiet review dock에 `weekly review entry`가 보인다
|
||||
3. 사용자가 teaser를 누른다
|
||||
4. `/stats`로 이동한다
|
||||
5. review를 본다
|
||||
6. 하단 CTA `이 흐름으로 다음 세션 시작`
|
||||
7. `/app`으로 돌아온다
|
||||
8. review에서 이어온 ritual/context를 가지고 바로 start한다
|
||||
|
||||
핵심:
|
||||
|
||||
- review는 `/app`을 대체하지 않는다
|
||||
- review는 `/app`을 보조한다
|
||||
- review를 보고 다시 `/app`으로 돌아오는 구조가 중요하다
|
||||
|
||||
### Secondary Flow
|
||||
|
||||
`/space complete -> teaser -> /stats`
|
||||
|
||||
1. 사용자가 `/space`에서 세션을 마친다
|
||||
2. complete flow가 끝난다
|
||||
3. 조건이 충족되면 작은 review teaser만 보여준다
|
||||
4. 사용자가 원할 때만 `/stats`로 간다
|
||||
|
||||
중요:
|
||||
|
||||
- `/space`에서는 full review를 메인 행동으로 밀지 않는다
|
||||
- complete tray를 review 유도 UI로 바꾸지 않는다
|
||||
|
||||
### Tertiary Flow
|
||||
|
||||
`profile / secondary nav -> /stats`
|
||||
|
||||
- 다시 review를 보고 싶은 사용자를 위한 명시적 진입
|
||||
- 메인 CTA는 아니다
|
||||
|
||||
---
|
||||
|
||||
## 6. `/app`에서 review teaser를 언제 보여줄 것인가
|
||||
|
||||
항상 보여주면 안 된다.
|
||||
“지금 봐도 의미 없음” 상태에서는 review가 노이즈가 된다.
|
||||
|
||||
### 노출 조건
|
||||
|
||||
기본 규칙:
|
||||
|
||||
- 최근 7일 started session >= 3
|
||||
|
||||
추가 강화 조건:
|
||||
|
||||
- completed session >= 2
|
||||
또는
|
||||
- returned after pause >= 1
|
||||
|
||||
즉,
|
||||
|
||||
- 데이터가 너무 적으면 teaser를 숨긴다
|
||||
- 최소한 “이번 주 리듬”이라고 부를 수 있을 만큼 쌓였을 때만 연다
|
||||
|
||||
### 노출하지 않는 경우
|
||||
|
||||
- 첫 1~2회 사용
|
||||
- 세션 기록이 거의 없는 주
|
||||
- current session이 있고 review 데이터도 거의 없는 상황
|
||||
|
||||
이 경우:
|
||||
|
||||
- `/app` no-session 상태에서는 goal/duration/atmosphere entry stage에 집중
|
||||
- resume 상태에서는 entry shell 대신 resume card 안의 조용한 secondary entry로 review를 연다
|
||||
|
||||
---
|
||||
|
||||
## 7. `/app` review dock 설계
|
||||
|
||||
### 위치
|
||||
|
||||
추천 위치:
|
||||
|
||||
- desktop에서는 entry stage 우측 또는 우상단 quiet dock
|
||||
- mobile에서는 entry stage 아래의 얇은 secondary panel
|
||||
|
||||
금지:
|
||||
|
||||
- entry stage보다 위
|
||||
- entry CTA와 같은 무게
|
||||
- card 3개 중 하나처럼 보이게 배치
|
||||
|
||||
### 형태
|
||||
|
||||
- low-emphasis secondary panel
|
||||
- 작고 조용한 one-liner + secondary CTA
|
||||
|
||||
예시:
|
||||
|
||||
- `이번 주엔 오전 시작에서 가장 오래 이어졌어요`
|
||||
- `pause 뒤 복귀 3회 · review 보기`
|
||||
|
||||
### CTA
|
||||
|
||||
- `주간 review 보기`
|
||||
|
||||
보조 문구:
|
||||
|
||||
- `다음 세션 전에 가볍게 보고 갈 수 있어요`
|
||||
|
||||
### UX 원칙
|
||||
|
||||
- teaser는 insight를 다 말하지 않는다
|
||||
- review를 보고 싶게 만들되, entry stage를 가리지 않는다
|
||||
- start CTA보다 절대 커 보이면 안 된다
|
||||
|
||||
---
|
||||
|
||||
## 8. `/stats` 내부 플로우
|
||||
|
||||
### 진입 직후
|
||||
|
||||
- 이번 주 snapshot hero
|
||||
- start / recovery / completion
|
||||
- carry forward
|
||||
|
||||
### 마지막 CTA
|
||||
|
||||
review의 마지막 CTA는 아래 중 하나여야 한다.
|
||||
|
||||
- `이 흐름으로 다음 세션 시작`
|
||||
- `이 조합으로 /app 돌아가기`
|
||||
|
||||
추천:
|
||||
|
||||
- CTA를 `/app?review=weekly&preset=...` 같은 방식으로 연결
|
||||
- 최소한 query 또는 client state로 ritual/context를 넘긴다
|
||||
|
||||
중요:
|
||||
|
||||
- `/stats`에서 바로 `/space`로 가지 않는다
|
||||
- `/app`을 다시 거치게 해서 commitment gate를 유지한다
|
||||
|
||||
왜냐하면:
|
||||
|
||||
- review 후에도 goal은 다시 내가 정해야 한다
|
||||
- VibeRoom의 핵심은 single-goal commitment이지, review에서 바로 auto-start가 아니다
|
||||
|
||||
---
|
||||
|
||||
## 9. `/app` 복귀 후 UX
|
||||
|
||||
### 복귀 상태
|
||||
|
||||
`/stats`에서 온 경우 `/app`은 plain 상태가 아니라
|
||||
review-aware state가 된다.
|
||||
|
||||
보여줄 것:
|
||||
|
||||
- “방금 본 review 기준 추천” 한 줄
|
||||
- review carry-forward hint
|
||||
- optional atmosphere / ritual hint
|
||||
|
||||
예시:
|
||||
|
||||
- `이번 주에 가장 잘 맞았던 흐름 · Forest · 50/10`
|
||||
- `이번엔 시작을 더 작게 잡아보세요`
|
||||
|
||||
### 유지할 것
|
||||
|
||||
- goal은 여전히 사용자가 직접 입력
|
||||
- goal과 duration은 여전히 사용자가 직접 입력
|
||||
|
||||
자동으로 하지 말 것:
|
||||
|
||||
- goal 자동 채우기
|
||||
- 바로 `/space`로 보냄
|
||||
- todo/list를 다시 불러옴
|
||||
|
||||
즉 review는:
|
||||
|
||||
- 방향을 준다
|
||||
- 하지만 결정을 대신하진 않는다
|
||||
|
||||
---
|
||||
|
||||
## 10. Free / Pro 차이
|
||||
|
||||
### Free
|
||||
|
||||
- `/app` teaser는 1개만
|
||||
- `/stats`에서는 이번 주 snapshot + start / recovery / completion 핵심까지만
|
||||
- return CTA는 generic
|
||||
- `이 흐름으로 다음 세션 시작`
|
||||
|
||||
### Pro
|
||||
|
||||
- teaser가 더 구체적일 수 있다
|
||||
- `Forest · 50/10에서 pause 뒤 복귀율이 가장 높았어요`
|
||||
- `/stats` 마지막 CTA가 더 개인화된다
|
||||
- `가장 잘 맞은 ritual로 /app 돌아가기`
|
||||
- `/app` 복귀 후 ritual prefill / carry-forward hint가 더 정교하다
|
||||
|
||||
핵심:
|
||||
|
||||
- Pro는 더 많은 review가 아니라
|
||||
- 더 정확한 next-session handoff를 판다
|
||||
|
||||
---
|
||||
|
||||
## 11. UI/UX 원칙
|
||||
|
||||
### `/app` review dock
|
||||
|
||||
- entry stage보다 작음
|
||||
- 한 줄 summary
|
||||
- secondary CTA
|
||||
- glass/card를 크게 쓰지 않음
|
||||
|
||||
### `/stats`
|
||||
|
||||
- calm review desk
|
||||
- 읽고 이해하고, 마지막에 행동 하나를 고르는 구조
|
||||
|
||||
### `/app` return state
|
||||
|
||||
- 다시 시작하는 감각 유지
|
||||
- review를 보고 왔다고 해서 `/app`이 dashboard처럼 바뀌면 안 된다
|
||||
|
||||
---
|
||||
|
||||
## 12. 구현 순서
|
||||
|
||||
### Slice 1. `/app` weekly review dock 추가
|
||||
|
||||
범위:
|
||||
|
||||
- teaser 노출 조건
|
||||
- teaser UI
|
||||
- `/stats` deep link
|
||||
|
||||
완료 기준:
|
||||
|
||||
- `/app`에서 review로 들어가는 primary path가 생긴다
|
||||
|
||||
### Slice 2. `/stats -> /app` return CTA 연결
|
||||
|
||||
범위:
|
||||
|
||||
- `/stats` 마지막 CTA
|
||||
- query/state handoff
|
||||
- `/app` review-aware state
|
||||
|
||||
완료 기준:
|
||||
|
||||
- review가 읽고 끝나는 페이지가 아니라 다음 세션으로 이어진다
|
||||
|
||||
### Slice 3. Pro personalized handoff
|
||||
|
||||
범위:
|
||||
|
||||
- best ritual carry-forward
|
||||
- review origin state 유지
|
||||
- CTA copy personalization
|
||||
|
||||
완료 기준:
|
||||
|
||||
- Pro가 더 자연스럽게 다음 세션으로 이어진다
|
||||
|
||||
### Slice 4. `/space` secondary teaser
|
||||
|
||||
범위:
|
||||
|
||||
- complete 이후 작은 review teaser
|
||||
- full review 강제 이동 금지
|
||||
|
||||
완료 기준:
|
||||
|
||||
- `/space`에서도 review가 존재하지만 execution을 방해하지 않는다
|
||||
|
||||
---
|
||||
|
||||
## 13. 데이터 / 인터페이스 제안
|
||||
|
||||
### `/app` teaser용 데이터
|
||||
|
||||
새 hook 또는 기존 `useFocusStats` 확장:
|
||||
|
||||
- `hasEnoughWeeklyData`
|
||||
- `weeklyTeaserLine`
|
||||
- `reviewHref`
|
||||
|
||||
### `/stats -> /app` handoff
|
||||
|
||||
추천 query:
|
||||
|
||||
- `review=weekly`
|
||||
- `entryPreset=forest-50-10`
|
||||
- `carryHint=start-smaller`
|
||||
|
||||
주의:
|
||||
|
||||
- query는 가볍게
|
||||
- 민감한 분석 전체를 싣지 않는다
|
||||
|
||||
### `/app` 복귀 상태
|
||||
|
||||
로컬 상태:
|
||||
|
||||
- `reviewSource`
|
||||
- `suggestedEntryPreset`
|
||||
- `carryForwardHint`
|
||||
|
||||
---
|
||||
|
||||
## 14. 완료 기준
|
||||
|
||||
- `/stats`의 primary entry가 `/app`에 생긴다
|
||||
- `/space`는 review의 secondary entry만 가진다
|
||||
- review를 본 뒤 사용자가 다시 `/app`으로 돌아와 다음 세션을 시작할 수 있다
|
||||
- review가 planner나 dashboard가 아니라 next-session ritual처럼 읽힌다
|
||||
- Free / Pro의 handoff 차이가 분명하다
|
||||
|
||||
---
|
||||
|
||||
## 15. 절대 피해야 할 방향
|
||||
|
||||
- `/space`에서 review로 강하게 끌어가는 것
|
||||
- review를 top nav의 메인 기능처럼 밀어올리는 것
|
||||
- `/stats`에서 바로 `/space` auto-start
|
||||
- review 결과로 goal을 자동 생성하는 것
|
||||
- review teaser가 `/app` hero보다 더 커 보이게 하는 것
|
||||
- planner/todo 회고처럼 보이게 만드는 것
|
||||
460
docs/screens/app/18_paused_session_reentry_spec.md
Normal file
460
docs/screens/app/18_paused_session_reentry_spec.md
Normal file
@@ -0,0 +1,460 @@
|
||||
# 18. Paused Session Re-entry Spec
|
||||
|
||||
Last Updated: 2026-03-15
|
||||
|
||||
이 문서는 VibeRoom에서 **진행 중인 세션 / 멈춘 세션 / 쉬는 시간**을 어떻게 다르게 취급할지,
|
||||
그리고 사용자가 `/app`에 들어왔을 때 어떤 경로로 다시 `/space`에 진입해야 하는지를 정의한다.
|
||||
|
||||
핵심 목적은 하나다.
|
||||
|
||||
> session state에 따라 `/app`과 `/space`의 역할을 정확히 나누고,
|
||||
> 사용자가 “지금 내가 어떤 상태인지”를 설명할 수 있는 premium UX를 만든다.
|
||||
|
||||
관련 문서:
|
||||
|
||||
- `./19_app_atmosphere_entry_spec.md`
|
||||
- `../space/10_refocus_system_spec.md`
|
||||
- `../space/11_away_return_recovery_spec.md`
|
||||
- `./15_app_stats_entry_flow_spec.md`
|
||||
- `../../product/16_product_alignment_audit_plan.md`
|
||||
- `../../product/17_product_alignment_findings.md`
|
||||
- `../../product_principles.md`
|
||||
- `../../current_context.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 문제 정의
|
||||
|
||||
지금까지의 혼란은 대부분 여기서 시작됐다.
|
||||
|
||||
- `세션`
|
||||
- `타이머`
|
||||
- `pause`
|
||||
- `break`
|
||||
- `return`
|
||||
|
||||
을 충분히 분리하지 않고 써 왔다.
|
||||
|
||||
그 결과:
|
||||
|
||||
- 사용자는 `타이머가 멈춰 있으면 다 paused인가?`를 헷갈린다
|
||||
- `/app`에서 `resume`이 primary인지, `새로 시작`이 가능한지 흐려진다
|
||||
- `잠시 비우기`와 `break`의 의미가 섞인다
|
||||
|
||||
이 spec은 그 상태 정의를 먼저 고정한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 한 줄 정의
|
||||
|
||||
> running session은 바로 `/space`로 복귀시키고,
|
||||
> paused session은 `/app`에서 다시 이어갈지 정하게 하되,
|
||||
> 사용자가 `이어가기`를 눌렀다면 `/space`에서는 다시 묻지 않고 바로 resume한다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 상태 정의
|
||||
|
||||
### Session
|
||||
|
||||
사용자가 현재 책임지고 있는 하나의 focus block.
|
||||
|
||||
조건:
|
||||
|
||||
- goal이 있다
|
||||
- 아직 명시적으로 닫지 않았다
|
||||
- 다시 이어갈 수 있다
|
||||
|
||||
### Running Focus
|
||||
|
||||
- 현재 focus 타이머가 진행 중
|
||||
- 사용자는 같은 goal 안에서 작업 중
|
||||
|
||||
### Paused Focus
|
||||
|
||||
- 사용자가 의도적으로 pause를 눌렀다
|
||||
- 같은 goal은 아직 살아 있다
|
||||
- 기본값은 `resume`
|
||||
|
||||
### Running Break
|
||||
|
||||
- focus block은 끝났다
|
||||
- break 타이머가 진행 중이다
|
||||
- 이건 paused session이 아니다
|
||||
|
||||
### Return
|
||||
|
||||
- 사용자가 pause를 누르지 않고 떠났다가 돌아온 상태
|
||||
- system이 recovery 선택지를 먼저 제안하는 상태
|
||||
|
||||
### Closed Session
|
||||
|
||||
- `여기서 마무리하기`로 끝낸 상태
|
||||
- 더 이상 current session이 아니다
|
||||
|
||||
---
|
||||
|
||||
## 4. 제품 원칙
|
||||
|
||||
### 1. Running은 다시 결정하게 하지 않는다
|
||||
|
||||
이미 running이면 사용자의 다음 행동은 “다시 정하기”가 아니라 “복귀”다.
|
||||
|
||||
즉:
|
||||
|
||||
- `/app`에서 hero를 다시 보여주지 않는다
|
||||
- 바로 `/space`로 보낸다
|
||||
|
||||
### 2. Paused는 자동 재생하지 않는다
|
||||
|
||||
pause는 사용자의 명시적 멈춤이다.
|
||||
|
||||
즉:
|
||||
|
||||
- `/app`에 들어왔다고 자동 resume하지 않는다
|
||||
- 사용자가 직접 `이어가기`를 눌러야 한다
|
||||
|
||||
### 3. Explicit Continue 이후에는 다시 묻지 않는다
|
||||
|
||||
사용자가 `/app`에서 `이어가기`를 눌렀다면,
|
||||
그건 이미 “다시 하겠다”는 결정을 내린 것이다.
|
||||
|
||||
즉:
|
||||
|
||||
- `/app -> /space -> 다시 start 클릭` 금지
|
||||
- `/space` 진입과 동시에 resume해야 한다
|
||||
|
||||
### 4. `/app`은 decision surface, `/space`는 execution surface
|
||||
|
||||
- `/app`: 이어갈지 / 다시 정리할지 / 새 목표로 전환할지
|
||||
- `/space`: 실제로 일하는 곳
|
||||
|
||||
이 둘이 같은 결정을 두 번 요구하면 실패다.
|
||||
|
||||
### 5. 새 시작은 current session이 없을 때만 direct
|
||||
|
||||
paused session이 있는데 새 목표를 바로 시작하게 하면
|
||||
회피 루프와 상태 오염이 생긴다.
|
||||
|
||||
즉:
|
||||
|
||||
- current session이 없을 때만 direct start
|
||||
- current session이 있을 때 새 start는 explicit takeover flow로만 허용
|
||||
|
||||
---
|
||||
|
||||
## 5. 라우팅 정책
|
||||
|
||||
### Rule A. Running Focus
|
||||
|
||||
상태:
|
||||
|
||||
- current session 존재
|
||||
- `state = running`
|
||||
- `phase = focus`
|
||||
|
||||
처리:
|
||||
|
||||
- `/app` 진입 시 즉시 `/space`
|
||||
|
||||
이유:
|
||||
|
||||
- 이미 실행 중인 일은 다시 commitment gate에 세우면 안 된다
|
||||
|
||||
### Rule B. Running Break
|
||||
|
||||
상태:
|
||||
|
||||
- current session 존재
|
||||
- `state = running`
|
||||
- `phase = break`
|
||||
|
||||
처리:
|
||||
|
||||
- `/app` 진입 시 즉시 `/space`
|
||||
|
||||
이유:
|
||||
|
||||
- break도 현재 세션의 일부다
|
||||
- `/app`에서 다시 decision을 시키면 break/return 의미가 흐려진다
|
||||
|
||||
### Rule C. Paused Focus
|
||||
|
||||
상태:
|
||||
|
||||
- current session 존재
|
||||
- `state = paused`
|
||||
- `phase = focus`
|
||||
|
||||
처리:
|
||||
|
||||
- `/app` 진입
|
||||
- `resume gate` 노출
|
||||
|
||||
이유:
|
||||
|
||||
- pause는 사용자의 의도적 멈춤이므로 존중해야 한다
|
||||
- 하지만 같은 goal을 다시 이어갈지 결정할 여지를 줘야 한다
|
||||
|
||||
### Rule D. No Session / Closed Session
|
||||
|
||||
상태:
|
||||
|
||||
- current session 없음
|
||||
|
||||
처리:
|
||||
|
||||
- `/app` 진입
|
||||
- no-session entry shell 노출
|
||||
|
||||
---
|
||||
|
||||
## 6. `/app` paused state UX
|
||||
|
||||
### 목적
|
||||
|
||||
사용자가 “멈춘 세션이 아직 살아 있다”는 것을 즉시 이해하고,
|
||||
한 번의 결정으로 `/space`에 다시 들어가게 만드는 것.
|
||||
|
||||
### 정보 구조
|
||||
|
||||
resume card 안에는 아래만 둔다.
|
||||
|
||||
- 현재 goal
|
||||
- 마지막 microStep
|
||||
- 현재 상태 문구
|
||||
- 예: `잠시 멈춘 세션이 있어요`
|
||||
- primary CTA
|
||||
- quiet secondary actions
|
||||
|
||||
### Primary CTA
|
||||
|
||||
- `이어서 몰입하기`
|
||||
|
||||
동작:
|
||||
|
||||
- 클릭
|
||||
- `/space`로 이동
|
||||
- 자동 resume
|
||||
|
||||
### Secondary
|
||||
|
||||
- `한 조각 다시 잡기`
|
||||
- `주간 review 보기`
|
||||
|
||||
### Tertiary
|
||||
|
||||
- `새 목표로 전환`
|
||||
|
||||
중요:
|
||||
|
||||
- new start가 아니다
|
||||
- takeover flow 진입점이다
|
||||
- server도 current session이 남아 있으면 direct start를 거절해야 한다
|
||||
|
||||
---
|
||||
|
||||
## 7. `/space` 재진입 동작
|
||||
|
||||
### Resume CTA 이후
|
||||
|
||||
`/app`에서 `이어서 몰입하기`를 눌렀다면:
|
||||
|
||||
- `/space`로 이동
|
||||
- 별도의 start 버튼 재요구 금지
|
||||
- 부드러운 transition 후 자동 resume
|
||||
|
||||
추천:
|
||||
|
||||
- 300~800ms 정도의 soft transition
|
||||
- 필요하면 아주 짧은 re-entry settle animation
|
||||
|
||||
금지:
|
||||
|
||||
- `/space`에서 다시 `시작`을 누르게 하는 것
|
||||
- resume 직후 또 다른 decision tray를 띄우는 것
|
||||
|
||||
### Refocus CTA 이후
|
||||
|
||||
`한 조각 다시 잡기`를 눌렀다면:
|
||||
|
||||
- refocus를 먼저 거친다
|
||||
- 그 후 `/space` 진입과 함께 자동 resume
|
||||
|
||||
즉, refocus는 decision이고, `/space`는 execution이다.
|
||||
|
||||
---
|
||||
|
||||
## 8. Takeover Flow
|
||||
|
||||
paused session이 있을 때 새 goal direct start는 허용하지 않는다.
|
||||
|
||||
대신 아래 흐름으로만 간다.
|
||||
|
||||
### Trigger
|
||||
|
||||
- `/app` paused state에서 `새 목표로 전환`
|
||||
|
||||
### Confirm Sheet
|
||||
|
||||
질문:
|
||||
|
||||
- `현재 멈춘 세션을 어떻게 할까요?`
|
||||
|
||||
선택지:
|
||||
|
||||
- `이어서 하기`
|
||||
- `이 세션은 여기서 정리하고 새로 시작`
|
||||
- `취소`
|
||||
|
||||
### 동작 원칙
|
||||
|
||||
- `이어서 하기`
|
||||
- sheet 닫기
|
||||
- resume card 유지
|
||||
|
||||
- `이 세션은 여기서 정리하고 새로 시작`
|
||||
- current session을 명시적으로 닫는다
|
||||
- 그 다음 `/app` single-goal start 상태로 전환한다
|
||||
|
||||
- `취소`
|
||||
- sheet 닫기
|
||||
|
||||
중요:
|
||||
|
||||
- silent abandon 금지
|
||||
- paused session 위에 새 session을 덮어쓰기 금지
|
||||
|
||||
---
|
||||
|
||||
## 9. Weekly Review와의 관계
|
||||
|
||||
paused state에서도 review는 열 수 있어야 한다.
|
||||
|
||||
하지만 위계는 아래처럼 고정한다.
|
||||
|
||||
### paused state
|
||||
|
||||
- primary: `이어서 몰입하기`
|
||||
- secondary: `한 조각 다시 잡기`
|
||||
- quiet secondary: `주간 review 보기`
|
||||
|
||||
즉:
|
||||
|
||||
- review를 숨기면 안 된다
|
||||
- resume보다 앞세우면 안 된다
|
||||
|
||||
---
|
||||
|
||||
## 10. 금지사항
|
||||
|
||||
- running session인데 `/app` hero를 보여주는 것
|
||||
- paused 상태에서 `/app` 진입만으로 자동 resume
|
||||
- `/app`에서 `이어가기`를 눌렀는데 `/space`에서 다시 start를 요구하는 것
|
||||
- paused session 위에서 direct new start 허용
|
||||
- break를 paused session처럼 취급하는 것
|
||||
- takeover 없이 silent abandon 하는 것
|
||||
|
||||
---
|
||||
|
||||
## 11. 구현 순서
|
||||
|
||||
### Slice 1. Session Routing Contract
|
||||
|
||||
범위:
|
||||
|
||||
- `/app` 진입 시 current session state에 따른 route policy 고정
|
||||
|
||||
포함:
|
||||
|
||||
- `running focus -> /space`
|
||||
- `running break -> /space`
|
||||
- `paused focus -> /app`
|
||||
- `no session -> /app`
|
||||
|
||||
완료 조건:
|
||||
|
||||
- 상태별 route policy가 코드와 문서에서 동일하다
|
||||
|
||||
### Slice 2. `/app` Paused Resume Gate
|
||||
|
||||
범위:
|
||||
|
||||
- paused state의 resume card UX 정리
|
||||
|
||||
포함:
|
||||
|
||||
- primary `이어서 몰입하기`
|
||||
- `한 조각 다시 잡기`
|
||||
- quiet `주간 review 보기`
|
||||
- state copy 정리
|
||||
|
||||
완료 조건:
|
||||
|
||||
- paused 사용자가 다음 행동을 2초 안에 이해할 수 있다
|
||||
|
||||
### Slice 3. `/space` Auto-Resume Handoff
|
||||
|
||||
범위:
|
||||
|
||||
- `/app` resume CTA 이후 `/space` 진입 시 자동 resume
|
||||
|
||||
포함:
|
||||
|
||||
- explicit continue 이후 double-confirm 제거
|
||||
- transition quality 보정
|
||||
|
||||
완료 조건:
|
||||
|
||||
- `/app -> /space -> start` 이중 클릭이 사라진다
|
||||
|
||||
### Slice 4. Takeover Flow
|
||||
|
||||
범위:
|
||||
|
||||
- paused session 위에서 new start를 하고 싶을 때의 명시적 처리
|
||||
|
||||
포함:
|
||||
|
||||
- confirm sheet
|
||||
- close-and-start-new 경로
|
||||
- silent abandon 방지
|
||||
|
||||
완료 조건:
|
||||
|
||||
- paused session 상태에서 새 목표 전환이 상태 오염 없이 가능하다
|
||||
|
||||
### Slice 5. Browser QA
|
||||
|
||||
반드시 확인할 시나리오:
|
||||
|
||||
1. running focus 상태에서 `/app` 진입
|
||||
2. running break 상태에서 `/app` 진입
|
||||
3. paused focus 상태에서 `/app` 진입
|
||||
4. paused -> `이어서 몰입하기`
|
||||
5. paused -> `한 조각 다시 잡기`
|
||||
6. paused -> `주간 review`
|
||||
7. paused -> `새 목표로 전환`
|
||||
|
||||
---
|
||||
|
||||
## 12. 성공 기준
|
||||
|
||||
- 사용자가 현재 상태를 설명할 수 있다
|
||||
- running이면 `/space`, paused면 `/app`이라는 규칙이 일관된다
|
||||
- paused에서의 primary CTA는 항상 `resume`이다
|
||||
- explicit continue 이후에는 다시 start를 요구하지 않는다
|
||||
- new start는 current session이 없을 때만 direct다
|
||||
|
||||
---
|
||||
|
||||
## 13. 최종 판단
|
||||
|
||||
VibeRoom이 world-class가 되려면
|
||||
`멈춤`, `쉬기`, `복귀`, `새 시작`을 같은 것으로 취급하면 안 된다.
|
||||
|
||||
가장 중요한 원칙은 이거다.
|
||||
|
||||
> 이미 실행 중인 것은 바로 복귀시키고,
|
||||
> 의도적으로 멈춘 것은 다시 결정하게 하되,
|
||||
> 다시 하겠다고 결정한 뒤에는 한 번 더 묻지 않는다.
|
||||
445
docs/screens/app/19_app_atmosphere_entry_spec.md
Normal file
445
docs/screens/app/19_app_atmosphere_entry_spec.md
Normal file
@@ -0,0 +1,445 @@
|
||||
# 19. `/app` Atmosphere Entry Spec
|
||||
|
||||
Last Updated: 2026-03-16
|
||||
|
||||
이 문서는 `/app`을 **`goal + duration + atmosphere` 중심의 premium focus entry surface**로 재설계하기 위한 기준 문서다.
|
||||
|
||||
관련 문서:
|
||||
|
||||
- `../../product_principles.md`
|
||||
- `../../current_context.md`
|
||||
- `../stats/14_weekly_review_reframe_spec.md`
|
||||
- `./15_app_stats_entry_flow_spec.md`
|
||||
- `./18_paused_session_reentry_spec.md`
|
||||
|
||||
---
|
||||
|
||||
## 1. 왜 다시 바꾸는가
|
||||
|
||||
현재 `/app`은 single-goal commitment gate로 정리되어 있지만,
|
||||
사용자가 실제로 “어떤 환경으로 들어갈지”를 고르는 감각 품질이 entry에서 충분히 살아 있지 않다.
|
||||
|
||||
문제:
|
||||
|
||||
- 시작은 빨라졌지만, entry가 아직 너무 추상적이다
|
||||
- `scene / sound / timer`가 제품 핵심 가치인데 `/app`에서는 거의 느껴지지 않는다
|
||||
- 첫 진입에서 VibeRoom만의 premium 감각이 충분히 전달되지 않는다
|
||||
|
||||
따라서 `/app`은 다시 planning home으로 돌아가면 안 되지만,
|
||||
**`goal + duration + atmosphere`를 한 화면에서 직관적으로 결정하는 premium entry stage**로 진화할 필요가 있다.
|
||||
|
||||
핵심은 이것이다.
|
||||
|
||||
> `/app`은 여전히 한 가지 목표만 정하는 화면이어야 하지만,
|
||||
> 그 목표를 어떤 분위기에서 얼마나 붙잡을지까지 함께 결정하는 stage가 되어야 한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 한 줄 정의
|
||||
|
||||
`/app`은 사용자가
|
||||
|
||||
1. 이번 세션의 목표를 한 줄로 적고
|
||||
2. 이 목표에 얼마나 걸릴지 직접 입력하고
|
||||
3. 배경 + 사운드가 묶인 하나의 `Atmosphere`를 고른 뒤
|
||||
4. 바로 `/space`로 들어가는
|
||||
|
||||
**premium focus staging screen**이다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 핵심 제품 원칙
|
||||
|
||||
### 1. Single Goal First는 유지한다
|
||||
|
||||
- goal은 1개만 입력한다
|
||||
- entry에서 multi-goal / list / planner affordance 금지
|
||||
|
||||
### 2. MicroStep은 `/app`에서 제거한다
|
||||
|
||||
- 최초 entry에서는 microStep을 묻지 않는다
|
||||
- microStep은 `/space` 안의 recovery / refocus에서 다시 잡는다
|
||||
- 이유:
|
||||
- 첫 entry는 시작 마찰을 최소화해야 한다
|
||||
- goal, duration, atmosphere만으로도 결정량이 충분하다
|
||||
|
||||
### 3. Duration은 사용자가 직접 입력한다
|
||||
|
||||
- 기존 preset `25/5`, `50/10` 중심 entry를 버린다
|
||||
- 사용자는 “이 목표를 끝내는 데 얼마나 걸릴지”를 분 단위로 적는다
|
||||
- 예: `70분`
|
||||
|
||||
### 4. 배경 + 사운드는 하나의 오브젝트로 다룬다
|
||||
|
||||
- scene과 sound를 따로 고르게 하지 않는다
|
||||
- entry에서 사용자가 고르는 것은 `Atmosphere` 하나다
|
||||
- 즉 `/app`의 선택 단위는 `scene + sound pair`
|
||||
|
||||
### 5. Review는 entry를 방해하지 않는 secondary ritual이어야 한다
|
||||
|
||||
- `/app`의 주인공은 시작이다
|
||||
- weekly review, achieved goals, “어떤 조합에서 잘 됐는지”는 보이되 start보다 앞서면 안 된다
|
||||
|
||||
---
|
||||
|
||||
## 4. 용어 정의
|
||||
|
||||
### 추천 명칭: `Atmosphere`
|
||||
|
||||
배경 + 사운드가 결합된 카드의 공식 명칭은 `Atmosphere`로 고정한다.
|
||||
|
||||
이유:
|
||||
|
||||
- scene, sound, timer보다 더 제품적인 단위로 읽힌다
|
||||
- “배경 카드”보다 premium하고 감성적이다
|
||||
- 나중에 Pro 가치(`saved atmospheres`, `best atmosphere for mornings`)와도 자연스럽게 연결된다
|
||||
|
||||
### UI에서의 노출 방식
|
||||
|
||||
- 섹션 제목: `어떤 분위기에서 들어갈까요?`
|
||||
- 카드 타입 명칭: `Atmosphere`
|
||||
- 예시 카드명:
|
||||
- Rain Window
|
||||
- Quiet Library
|
||||
- Forest Draft
|
||||
- Deep Night Desk
|
||||
|
||||
### 피해야 할 이름
|
||||
|
||||
- `배경 카드`
|
||||
- `사운드 카드`
|
||||
- `조합 카드`
|
||||
- `프리셋`
|
||||
|
||||
이런 이름은 값싸 보이거나 툴처럼 읽힌다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 정보 구조
|
||||
|
||||
`/app`은 아래 3층으로 구성한다.
|
||||
|
||||
### Layer 1. Entry Header
|
||||
|
||||
- VibeRoom wordmark
|
||||
- quiet weekly review entry
|
||||
- plan pill / account
|
||||
|
||||
### Layer 2. Primary Start Stage
|
||||
|
||||
- goal input
|
||||
- duration input
|
||||
- start CTA
|
||||
|
||||
### Layer 3. Atmosphere Grid
|
||||
|
||||
- 12개의 curated atmosphere card
|
||||
- row당 4개
|
||||
- 첫 구현은 더미 데이터
|
||||
|
||||
핵심은
|
||||
**review / archive / history가 main stage를 먹지 않고, atmosphere grid도 secondary decoration이 아니라 실제 선택 surface로 작동해야 한다**는 점이다.
|
||||
|
||||
---
|
||||
|
||||
## 6. 화면 구성
|
||||
|
||||
### A. Goal Input
|
||||
|
||||
- 가장 위, 가장 크게
|
||||
- 한 줄 입력
|
||||
- placeholder 예시:
|
||||
- `예: 여행 계획 짜기`
|
||||
- `예: 제안서 첫 문단 정리`
|
||||
|
||||
규칙:
|
||||
|
||||
- 필수
|
||||
- 한 줄
|
||||
- Enter로 start 가능
|
||||
|
||||
### B. Duration Input
|
||||
|
||||
- goal 바로 아래 또는 옆
|
||||
- 분 단위 숫자 입력
|
||||
- label:
|
||||
- `얼마나 붙잡을까요?`
|
||||
- `예상 시간(분)`
|
||||
|
||||
규칙:
|
||||
|
||||
- 필수
|
||||
- 숫자만
|
||||
- 권장 범위:
|
||||
- 최소 10분
|
||||
- 최대 180분
|
||||
- helper:
|
||||
- `이 목표를 끝내는 데 걸릴 것 같은 시간을 적어요.`
|
||||
|
||||
### C. Atmosphere Grid
|
||||
|
||||
- 12개 dummy card
|
||||
- desktop: 4열 x 3행
|
||||
- tablet: 3열
|
||||
- mobile: 2열
|
||||
|
||||
각 카드 구성:
|
||||
|
||||
- 배경 썸네일
|
||||
- 카드명
|
||||
- sound label
|
||||
- 1줄 description
|
||||
|
||||
예시:
|
||||
|
||||
- `Rain Window` / `Soft Rain`
|
||||
- `Quiet Library` / `Air + Page Rustle`
|
||||
- `Forest Draft` / `Forest Birds`
|
||||
- `Deep Night Desk` / `Low White`
|
||||
|
||||
### D. Start CTA
|
||||
|
||||
- 문구 예시:
|
||||
- `이 분위기로 들어가기`
|
||||
- `지금 시작`
|
||||
|
||||
추천:
|
||||
|
||||
- 기본 CTA는 `이 분위기로 들어가기`
|
||||
- 이유:
|
||||
- goal + duration + atmosphere가 모두 한 번에 묶여 entry action으로 읽힌다
|
||||
|
||||
### E. Weekly Review Entry
|
||||
|
||||
이건 main stage 바깥의 quiet secondary placement로 둔다.
|
||||
|
||||
권장 위치:
|
||||
|
||||
- desktop: header 아래 우상단 quiet insight panel
|
||||
- mobile: hero 하단의 얇은 secondary card
|
||||
|
||||
보여줄 것:
|
||||
|
||||
- 이번 주 가장 잘 맞았던 atmosphere
|
||||
- 시작 성공률 또는 복귀율 1줄
|
||||
- CTA: `이번 주 review`
|
||||
|
||||
보이지 말아야 할 것:
|
||||
|
||||
- achieved goals 리스트 전체
|
||||
- 작은 차트 여러 개
|
||||
- dashboard처럼 보이는 summary wall
|
||||
|
||||
---
|
||||
|
||||
## 7. Weekly Review / Achieved Goals를 어디에 둘 것인가
|
||||
|
||||
결론:
|
||||
|
||||
> `/app`에는 full review를 두지 않고,
|
||||
> `quiet review dock`만 둔다.
|
||||
> 자세한 achieved goals와 “어떤 조합에서 잘 됐는지”는 `/stats`에서 본다.
|
||||
|
||||
### 왜 `/app`에 다 보여주면 안 되는가
|
||||
|
||||
- 메인 entry의 집중력이 깨진다
|
||||
- goal 입력과 review 해석이 같은 레벨로 보인다
|
||||
- planner/dashboard처럼 읽힌다
|
||||
|
||||
### 추천 구조
|
||||
|
||||
#### `/app`
|
||||
|
||||
- 작은 weekly review dock
|
||||
- 보여주는 정보는 1~2줄만
|
||||
- 예:
|
||||
- `이번 주엔 Rain Window에서 가장 오래 이어졌어요.`
|
||||
- `여행 계획 같은 넓은 목표는 70분보다 45분에서 더 잘 닫혔어요.`
|
||||
|
||||
#### `/stats`
|
||||
|
||||
- achieved goals history
|
||||
- best-performing atmospheres
|
||||
- duration fit
|
||||
- recovery quality
|
||||
|
||||
즉:
|
||||
|
||||
- `/app`은 “review를 여는 문”
|
||||
- `/stats`는 “review desk”
|
||||
|
||||
---
|
||||
|
||||
## 8. 상태별 유저 플로우
|
||||
|
||||
### Flow A. First Entry / No Session
|
||||
|
||||
1. 사용자가 `/app` 진입
|
||||
2. goal 입력
|
||||
3. duration 입력
|
||||
4. atmosphere 1개 선택
|
||||
5. CTA 클릭
|
||||
6. `/space` 진입
|
||||
|
||||
핵심:
|
||||
|
||||
- microStep 없음
|
||||
- list 없음
|
||||
- wizard 없음
|
||||
|
||||
### Flow B. Running Session Exists
|
||||
|
||||
1. 사용자가 `/app` 진입
|
||||
2. 바로 `/space` redirect
|
||||
|
||||
이유:
|
||||
|
||||
- 이미 실행 중인 세션은 다시 decision gate에 세우지 않는다
|
||||
|
||||
### Flow C. Paused Session Exists
|
||||
|
||||
1. 사용자가 `/app` 진입
|
||||
2. paused resume gate 노출
|
||||
3. 선택:
|
||||
- `이어서 몰입하기`
|
||||
- `한 조각 다시 잡기`
|
||||
- `새 목표로 전환`
|
||||
|
||||
중요:
|
||||
|
||||
- 이 상태에서는 atmosphere grid를 메인 UI로 먼저 보여주지 않는다
|
||||
- resume가 primary다
|
||||
|
||||
### Flow D. Review Entry
|
||||
|
||||
1. 사용자가 `/app`의 quiet review dock 클릭
|
||||
2. `/stats`
|
||||
3. carry-forward CTA
|
||||
4. 다시 `/app`
|
||||
|
||||
---
|
||||
|
||||
## 9. UI 방향
|
||||
|
||||
### 톤
|
||||
|
||||
- premium
|
||||
- calm
|
||||
- stage-like
|
||||
- card-heavy dashboard 금지
|
||||
|
||||
### 중요한 시각 원칙
|
||||
|
||||
- 상단 input stage는 “form”보다 “entry surface”처럼 보여야 한다
|
||||
- atmosphere grid는 catalog처럼 보이되, ecommerce처럼 보이면 안 된다
|
||||
- card는 selection object이지 콘텐츠 카드가 아니다
|
||||
- hover, selected, focus state가 매우 명확해야 한다
|
||||
|
||||
### Selected Card
|
||||
|
||||
- 다른 카드보다 1단 더 선명
|
||||
- subtle border glow
|
||||
- sound label이 더 읽히게
|
||||
- 선택되면 CTA 문구가 `이 분위기로 들어가기`와 연결돼야 함
|
||||
|
||||
### Unselected Card
|
||||
|
||||
- 너무 장식적이면 안 된다
|
||||
- 배경 썸네일이 주인공
|
||||
- 텍스트는 간결
|
||||
|
||||
---
|
||||
|
||||
## 10. 비즈니스 모델 관점
|
||||
|
||||
이 redesign은 BM에도 직접 연결된다.
|
||||
|
||||
### Free
|
||||
|
||||
- curated atmosphere 12개 제공
|
||||
- goal + custom duration + basic review dock
|
||||
- best atmosphere insight는 1줄만
|
||||
|
||||
### Pro
|
||||
|
||||
- personalized atmosphere recommendations
|
||||
- saved favorite atmospheres
|
||||
- goal type / time-of-day 기반 추천
|
||||
- “이 목표 유형에서 잘 맞았던 조합” 인사이트
|
||||
- duration suggestion
|
||||
- deeper review
|
||||
|
||||
즉 Pro는 “카드를 더 많이 준다”가 아니라
|
||||
**더 잘 맞는 atmosphere를 더 빨리 고르게 해준다**가 되어야 한다.
|
||||
|
||||
---
|
||||
|
||||
## 11. 서버 / 데이터 영향
|
||||
|
||||
이번 redesign은 backend contract까지 건드린다.
|
||||
|
||||
### 필요한 변화
|
||||
|
||||
1. `startSession`이 custom duration minutes를 받도록 확장
|
||||
2. session에 `focusDurationMinutes` 저장
|
||||
3. break duration 계산 정책 정의
|
||||
4. atmosphere 선택 단위를 위한 `sceneId + soundPresetId` 조합 저장
|
||||
|
||||
### break duration 정책 제안
|
||||
|
||||
- 10~30분: 5분
|
||||
- 31~60분: 10분
|
||||
- 61~120분: 15분
|
||||
- 121분 이상: 20분
|
||||
|
||||
이건 사용자가 break를 직접 고르지 않아도 자연스럽게 이어지게 하기 위한 기본 정책이다.
|
||||
|
||||
---
|
||||
|
||||
## 12. 구현 순서
|
||||
|
||||
### Slice 1. Atmosphere Model / Dummy Data
|
||||
|
||||
- atmosphere card dummy 12개 정의
|
||||
- 카드명 / scene / sound / thumbnail 연결
|
||||
|
||||
### Slice 2. `/app` Entry Shell Redesign
|
||||
|
||||
- goal input
|
||||
- duration input
|
||||
- 4x3 atmosphere grid
|
||||
- selected card state
|
||||
- start CTA
|
||||
|
||||
### Slice 3. Paused Gate Coexistence
|
||||
|
||||
- paused session일 때는 새로운 entry shell 대신 resume gate를 우선 유지
|
||||
- no-session일 때만 새 shell 노출
|
||||
|
||||
### Slice 4. Custom Duration Contract
|
||||
|
||||
- web -> server `custom minutes`
|
||||
- break duration policy
|
||||
- `/space` timer HUD와 연동
|
||||
|
||||
### Slice 5. Weekly Review Dock
|
||||
|
||||
- `/app`의 quiet secondary review entry를 새 shell에 맞게 재배치
|
||||
- `/stats` entry/handoff 유지
|
||||
|
||||
### Slice 6. Pro Personalization
|
||||
|
||||
- recommended atmosphere
|
||||
- best-fit insight
|
||||
- duration suggestion
|
||||
|
||||
---
|
||||
|
||||
## 13. 검증 기준
|
||||
|
||||
- 사용자가 `/app`에서 10초 안에 goal + duration + atmosphere를 정하고 들어갈 수 있다
|
||||
- atmosphere grid가 decorator가 아니라 실제 선택 surface로 읽힌다
|
||||
- weekly review가 start보다 앞서지 않는다
|
||||
- `/app`이 planner/dashboard처럼 보이지 않는다
|
||||
- paused session에서는 resume gate가 새 entry shell보다 우선한다
|
||||
- `70분` 같은 custom duration이 실제 세션 길이로 반영된다
|
||||
Reference in New Issue
Block a user