공개: KoTalk 최신 기준선
This commit is contained in:
commit
debf62f76e
572 changed files with 41689 additions and 0 deletions
43
문서/atlas/03-meetings-approvals/01-agenda-room.md
Normal file
43
문서/atlas/03-meetings-approvals/01-agenda-room.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 아젠다 룸
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 아젠다 룸을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 아젠다 룸은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/02-brief-before.md
Normal file
43
문서/atlas/03-meetings-approvals/02-brief-before.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 회의 전 브리프
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 회의 전 브리프을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 회의 전 브리프은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/03-live-decisions.md
Normal file
43
문서/atlas/03-meetings-approvals/03-live-decisions.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 실시간 결정 기록
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 실시간 결정 기록을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 실시간 결정 기록은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/04-action-items.md
Normal file
43
문서/atlas/03-meetings-approvals/04-action-items.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 후속 액션 정리
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 후속 액션 정리을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 후속 액션 정리은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/05-approval-requests.md
Normal file
43
문서/atlas/03-meetings-approvals/05-approval-requests.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 승인 요청 흐름
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 승인 요청 흐름을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 승인 요청 흐름은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/06-summary-after.md
Normal file
43
문서/atlas/03-meetings-approvals/06-summary-after.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 회의 후 요약
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 회의 후 요약을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 회의 후 요약은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/07-followup-reminders.md
Normal file
43
문서/atlas/03-meetings-approvals/07-followup-reminders.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 후속 리마인더
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 후속 리마인더을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 후속 리마인더은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/08-participant-state.md
Normal file
43
문서/atlas/03-meetings-approvals/08-participant-state.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 참여자 상태 보기
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 참여자 상태 보기을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 참여자 상태 보기은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/09-presenter-mode.md
Normal file
43
문서/atlas/03-meetings-approvals/09-presenter-mode.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 발표자 모드
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 발표자 모드을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 발표자 모드은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/10-minute-selfchat.md
Normal file
43
문서/atlas/03-meetings-approvals/10-minute-selfchat.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 미팅 메모 셀프채팅
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 미팅 메모 셀프채팅을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 미팅 메모 셀프채팅은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/11-quick-votes.md
Normal file
43
문서/atlas/03-meetings-approvals/11-quick-votes.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 빠른 투표
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 빠른 투표을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 빠른 투표은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/12-task-from-message.md
Normal file
43
문서/atlas/03-meetings-approvals/12-task-from-message.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 메시지에서 할 일 생성
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 메시지에서 할 일 생성을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 메시지에서 할 일 생성은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/13-due-date-flow.md
Normal file
43
문서/atlas/03-meetings-approvals/13-due-date-flow.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 마감일 흐름
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 마감일 흐름을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 마감일 흐름은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/14-meeting-pin.md
Normal file
43
문서/atlas/03-meetings-approvals/14-meeting-pin.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 회의 고정 공간
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 회의 고정 공간을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 회의 고정 공간은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/15-doc-sharing.md
Normal file
43
문서/atlas/03-meetings-approvals/15-doc-sharing.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 문서 공유 흐름
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 문서 공유 흐름을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 문서 공유 흐름은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/16-search-presets.md
Normal file
43
문서/atlas/03-meetings-approvals/16-search-presets.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 회의 검색 프리셋
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 회의 검색 프리셋을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 회의 검색 프리셋은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/17-handoff-after.md
Normal file
43
문서/atlas/03-meetings-approvals/17-handoff-after.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 회의 후 인계
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 회의 후 인계을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 회의 후 인계은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/18-async-board.md
Normal file
43
문서/atlas/03-meetings-approvals/18-async-board.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 비동기 보드
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 비동기 보드을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 비동기 보드은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/19-approval-escalation.md
Normal file
43
문서/atlas/03-meetings-approvals/19-approval-escalation.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 승인 에스컬레이션
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 승인 에스컬레이션을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 승인 에스컬레이션은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/20-fatigue-controls.md
Normal file
43
문서/atlas/03-meetings-approvals/20-fatigue-controls.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# 회의 피로 제어
|
||||
|
||||
## 문서 목표
|
||||
- 범주: 회의와 승인 흐름
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
- 다루는 장면: 회의 피로 제어을 통해 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
|
||||
## 왜 중요한가
|
||||
- 회의 피로 제어은 반복 사용 단계의 체감 시간을 줄이는 핵심 장면이다.
|
||||
- 이 문서는 기능 추가보다 사용자가 헷갈리지 않고 바로 행동하게 만드는 기준을 다룬다.
|
||||
- 업무형 소통과 친근한 소통 모두에서 과도한 설명보다 짧은 실행을 우선한다.
|
||||
|
||||
## 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/03-meetings-approvals/README.md
Normal file
34
문서/atlas/03-meetings-approvals/README.md
Normal file
|
|
@ -0,0 +1,34 @@
|
|||
# 회의와 승인 흐름
|
||||
|
||||
이 묶음은 회의와 승인 흐름 관점에서 사용자 체감 간편함을 세부 주제로 분해한 아틀라스다.
|
||||
|
||||
## 범위
|
||||
- 주요 목적: 회의 전후 맥락 손실을 줄이고 승인 소통을 빠르게 끝내는 구조
|
||||
- 우선 사용자: 리더 + 실무자 + 승인자
|
||||
- 우선 채널: Windows 우선 + Mobile Web 보조
|
||||
|
||||
## 현재 산출물에 대한 비판적 요약
|
||||
- 현재 산출물은 실시간 대화 자체는 되지만 회의 후 남는 결정과 후속조치를 구조화하지 못한다.
|
||||
- 업무형 사용자의 승인 요청, 일정, 후속 작업이 아직 채팅 로그에 묻히기 쉽다.
|
||||
|
||||
## 문서 목록
|
||||
- [아젠다 룸](./01-agenda-room.md)
|
||||
- [회의 전 브리프](./02-brief-before.md)
|
||||
- [실시간 결정 기록](./03-live-decisions.md)
|
||||
- [후속 액션 정리](./04-action-items.md)
|
||||
- [승인 요청 흐름](./05-approval-requests.md)
|
||||
- [회의 후 요약](./06-summary-after.md)
|
||||
- [후속 리마인더](./07-followup-reminders.md)
|
||||
- [참여자 상태 보기](./08-participant-state.md)
|
||||
- [발표자 모드](./09-presenter-mode.md)
|
||||
- [미팅 메모 셀프채팅](./10-minute-selfchat.md)
|
||||
- [빠른 투표](./11-quick-votes.md)
|
||||
- [메시지에서 할 일 생성](./12-task-from-message.md)
|
||||
- [마감일 흐름](./13-due-date-flow.md)
|
||||
- [회의 고정 공간](./14-meeting-pin.md)
|
||||
- [문서 공유 흐름](./15-doc-sharing.md)
|
||||
- [회의 검색 프리셋](./16-search-presets.md)
|
||||
- [회의 후 인계](./17-handoff-after.md)
|
||||
- [비동기 보드](./18-async-board.md)
|
||||
- [승인 에스컬레이션](./19-approval-escalation.md)
|
||||
- [회의 피로 제어](./20-fatigue-controls.md)
|
||||
Loading…
Add table
Add a link
Reference in a new issue