public/kotalk
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

공개: KoTalk 최신 기준선

Browse source
This commit is contained in:
Ian 2026-04-16 09:24:26 +09:00
commit debf62f76e
572 changed files with 41689 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

43
문서/atlas/09-adoption-rollout/01-first-week-rollout.md Normal file
View file

@ -0,0 +1,43 @@
# 첫 주 롤아웃
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 첫 주 롤아웃을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 첫 주 롤아웃은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 첫 주 롤아웃이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 첫 주 롤아웃은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 첫 주 롤아웃 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/02-role-onboarding.md Normal file
View file

@ -0,0 +1,43 @@
# 역할별 온보딩
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 역할별 온보딩을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 역할별 온보딩은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 역할별 온보딩이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 역할별 온보딩은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 역할별 온보딩 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/03-invite-campaigns.md Normal file
View file

@ -0,0 +1,43 @@
# 초대 캠페인
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 초대 캠페인을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 초대 캠페인은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 초대 캠페인이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 초대 캠페인은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 초대 캠페인 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/04-migration-checklist.md Normal file
View file

@ -0,0 +1,43 @@
# 전환 체크리스트
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 전환 체크리스트을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 전환 체크리스트은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 전환 체크리스트이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 전환 체크리스트은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 전환 체크리스트 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/05-office-starter.md Normal file
View file

@ -0,0 +1,43 @@
# 사무형 시작 안내
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 사무형 시작 안내을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 사무형 시작 안내은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 사무형 시작 안내이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 사무형 시작 안내은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 사무형 시작 안내 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/06-lead-starter.md Normal file
View file

@ -0,0 +1,43 @@
# 리더 시작 안내
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 리더 시작 안내을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 리더 시작 안내은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 리더 시작 안내이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 리더 시작 안내은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 리더 시작 안내 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/07-support-macros.md Normal file
View file

@ -0,0 +1,43 @@
# 지원 매크로
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 지원 매크로을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 지원 매크로은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 지원 매크로이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 지원 매크로은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 지원 매크로 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/08-adoption-metrics.md Normal file
View file

@ -0,0 +1,43 @@
# 도입 지표
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 도입 지표을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 도입 지표은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 도입 지표이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 도입 지표은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 도입 지표 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/09-champion-program.md Normal file
View file

@ -0,0 +1,43 @@
# 챔피언 프로그램
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 챔피언 프로그램을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 챔피언 프로그램은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 챔피언 프로그램이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 챔피언 프로그램은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 챔피언 프로그램 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/10-training-deck.md Normal file
View file

@ -0,0 +1,43 @@
# 교육 덱
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 교육 덱을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 교육 덱은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 교육 덱이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 교육 덱은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 교육 덱 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/11-release-notes-users.md Normal file
View file

@ -0,0 +1,43 @@
# 사용자용 릴리즈 노트
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 사용자용 릴리즈 노트을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 사용자용 릴리즈 노트은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 사용자용 릴리즈 노트이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 사용자용 릴리즈 노트은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 사용자용 릴리즈 노트 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/12-team-faq.md Normal file
View file

@ -0,0 +1,43 @@
# 팀 FAQ
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 팀 FAQ을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 팀 FAQ은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 팀 FAQ이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 팀 FAQ은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 팀 FAQ 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/13-support-triage.md Normal file
View file

@ -0,0 +1,43 @@
# 지원 분류
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 지원 분류을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 지원 분류은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 지원 분류이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 지원 분류은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 지원 분류 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/14-change-management.md Normal file
View file

@ -0,0 +1,43 @@
# 변화 관리
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 변화 관리을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 변화 관리은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 변화 관리이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 변화 관리은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 변화 관리 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/15-reactivation.md Normal file
View file

@ -0,0 +1,43 @@
# 재활성화
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 재활성화을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 재활성화은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 재활성화이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 재활성화은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 재활성화 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/16-onboarding-experiments.md Normal file
View file

@ -0,0 +1,43 @@
# 온보딩 실험
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 온보딩 실험을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 온보딩 실험은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 온보딩 실험이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 온보딩 실험은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 온보딩 실험 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/17-trust-messages.md Normal file
View file

@ -0,0 +1,43 @@
# 신뢰 메시지
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 신뢰 메시지을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 신뢰 메시지은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 신뢰 메시지이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 신뢰 메시지은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 신뢰 메시지 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/18-beta-feedback.md Normal file
View file

@ -0,0 +1,43 @@
# 베타 피드백
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 베타 피드백을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 베타 피드백은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 베타 피드백이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 베타 피드백은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 베타 피드백 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/19-community-funnel.md Normal file
View file

@ -0,0 +1,43 @@
# 커뮤니티 퍼널
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 커뮤니티 퍼널을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 커뮤니티 퍼널은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 커뮤니티 퍼널이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 커뮤니티 퍼널은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 커뮤니티 퍼널 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

43
문서/atlas/09-adoption-rollout/20-persona-education.md Normal file
View file

@ -0,0 +1,43 @@
# 페르소나 교육
## 문서 목표
- 범주: 도입과 전환 운영
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
- 다루는 장면: 페르소나 교육을 통해 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
## 왜 중요한가
- 페르소나 교육은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
## UX 원칙
- 한 화면에서 사용자가 지금 해야 할 행동을 하나만 강조한다.
- 상태 설명은 기술 용어보다 사용자가 잃을 수 있는 것과 복구 가능성을 먼저 말한다.
- 목록, 검색, 보관, 내 공간의 역할을 섞지 않는다.
- 데스크톱과 모바일의 차이는 표면만 달라지고 정신 모델은 유지한다.
## 표준 흐름
1. 사용자는 페르소나 교육이 필요한 순간에 가장 가까운 표면에서 진입한다.
2. 시스템은 맥락을 잃지 않도록 현재 대화, 최근 작업, 저장된 초안을 유지한다.
3. 사용자는 최소 입력으로 필요한 행동을 끝내고 다음 대화로 이동한다.
4. 완료 후에는 다시 찾기, 복귀, 후속조치까지 이어질 수 있어야 한다.
## 현재 산출물 기준 비판적 시각
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
- 따라서 페르소나 교육은 단순 기능 제안이 아니라 현재 제품이 아직 불완전하게 느껴지는 지점을 메우는 문서로 본다.
## 측정과 릴리즈 게이트
- 첫 성공까지 걸리는 시간과 중간 이탈률을 함께 본다.
- 사용자가 페르소나 교육 흐름을 끝낸 뒤 다시 되돌아오지 않아도 되는 비율을 본다.
- 릴리즈 전에는 빈 상태, 오류 상태, 복구 상태까지 최소 한 번씩 수동 점검한다.
## 금지 패턴
- 화면을 설명 카드로 채우고 실제 행동은 뒤로 미루는 구성
- 필터, 내비게이션, 설정을 같은 계층에서 경쟁시키는 구성
- 사용자 잘못처럼 보이게 만드는 모호한 오류 카피
## 구현 연결 메모
- 관련 상위 문서: 문서/README.md, 문서/31-user-review-log-and-experience-scorecard.md, 문서/96-experience-gap-implementation-backlog.md
- 이 문서는 기획과 QA 기준을 함께 포함하므로 실제 구현 시 UI, API, 운영 문서와 같이 갱신한다.

34
문서/atlas/09-adoption-rollout/README.md Normal file
View file

@ -0,0 +1,34 @@
# 도입과 전환 운영
이 묶음은 도입과 전환 운영 관점에서 사용자 체감 간편함을 세부 주제로 분해한 아틀라스다.
## 범위
- 주요 목적: 개인 사용을 넘어 팀 도입까지 부드럽게 연결하는 구조
- 우선 사용자: 운영자 + 팀 리더 + 초기 사용자
- 우선 채널: 문서, Releases, Windows, Web, Android
## 현재 산출물에 대한 비판적 요약
- 현재 저장소는 방향과 문서가 강하지만 실제 전환 지원 표면은 더 세밀하게 다듬어야 한다.
- 오픈소스 프로젝트답게 읽히기는 하지만 처음 보는 사용자가 어떻게 시작할지 한 번에 이해하기엔 아직 문서 진입로가 많다.
## 문서 목록
- [첫 주 롤아웃](./01-first-week-rollout.md)
- [역할별 온보딩](./02-role-onboarding.md)
- [초대 캠페인](./03-invite-campaigns.md)
- [전환 체크리스트](./04-migration-checklist.md)
- [사무형 시작 안내](./05-office-starter.md)
- [리더 시작 안내](./06-lead-starter.md)
- [지원 매크로](./07-support-macros.md)
- [도입 지표](./08-adoption-metrics.md)
- [챔피언 프로그램](./09-champion-program.md)
- [교육 덱](./10-training-deck.md)
- [사용자용 릴리즈 노트](./11-release-notes-users.md)
- [팀 FAQ](./12-team-faq.md)
- [지원 분류](./13-support-triage.md)
- [변화 관리](./14-change-management.md)
- [재활성화](./15-reactivation.md)
- [온보딩 실험](./16-onboarding-experiments.md)
- [신뢰 메시지](./17-trust-messages.md)
- [베타 피드백](./18-beta-feedback.md)
- [커뮤니티 퍼널](./19-community-funnel.md)
- [페르소나 교육](./20-persona-education.md)