| name | user-guide |
| description | 제품/기능의 사용자 가이드·도움말을 초심자 기준으로 초안 작성한다. 온보딩(첫 사용), How-to(과업별 단계), FAQ, 에러 대처까지 과업 중심으로 구조화한다. "사용법 문서 써줘 / 사용자 가이드 / 도움말 만들어줘 / 온보딩 문서 / How-to / 가이드 / FAQ 정리해줘 / 매뉴얼 초안"이라고 할 때 트리거. |
작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].
사용자 가이드·도움말 작성 (user-guide)
기능 설명서가 아니라 **"사용자가 하려는 일을 끝내게 돕는 문서"**다. 화면 순서대로 나열하지 말고, 사용자의 과업(하고 싶은 일) 기준으로 쓴다. 읽는 사람은 늘 초심자라고 가정한다.
0. 왜 과업 중심인가 (제일 먼저)
사용자는 "이 버튼이 뭐냐"가 아니라 **"내가 하려는 걸 어떻게 하냐"**를 알고 싶어 온다. 그래서 목차부터 기능명이 아니라 **동사(할 일)**로 잡는다.
- 나쁨: "대시보드 / 설정 / 리포트" (기능 나열 → 사용자는 자기 일이 어디 있는지 모름)
- 좋음: "처음 시작하기 / 광고 소재 만들기 / 성과 확인하기 / 결제·페이백 보기" (할 일 기준)
먼저 확정할 것 — 지어내지 말고 물어라: "누가(초심자/실무자), 어떤 상황에서, 무슨 일을 끝내려고 이 문서를 여나요?" 여기가 어긋나면 뒤가 다 헛수고다.
1. 기존 컨텍스트 먼저 (헛발질 방지)
있는 걸 먼저 본다 — 없는 내용을 상상해서 쓰지 않는다.
- 제품 실제 정보·톤·용어:
data/context.md, data/brand.md(있으면).
- 실제 화면 흐름을 모르면 [[research]]로 확인하거나 사용자에게 직접 물어 채운다. 기능이 실제로 어떻게 동작하는지 **확인 안 된 단계는 지어내지 말고 "확인 필요"**로 표기.
2. 표준 구조 (각 섹션 옆에 '왜' 한 줄)
문서 유형에 맞게 아래에서 골라 쓴다. 셋을 한 문서에 합칠 수도 있다.
A. 온보딩 (처음 시작하기)
- 이게 뭐고, 뭘 할 수 있나 — 한 문장 + 이걸로 해결되는 대표 상황 2~3개. (왜: 초심자가 "나한테 맞는 도구인지"를 빠르게 판단)
- 시작 전 준비물 — 계정/권한/연결할 것. (왜: 중간에 막혀 이탈하는 걸 앞에서 막음)
- 첫 성공까지 최단 경로 — 짧은 시간 안에 "됐다!" 하는 경험 한 번. 단계는 최소로. (왜: 첫 성공이 있어야 계속 쓴다)
- 다음엔 이걸 해보세요 — 자연스러운 다음 과업으로 연결.
B. How-to (과업별 단계) — 과업 하나당 한 섹션
- 이걸로 뭘 하나 + 언제 쓰나 (왜: 맞는 문서를 찾아온 게 맞는지 확인)
- 단계 — 번호로, 한 단계 = 한 동작. 각 단계는 "무엇을 누른다 → 그러면 무엇이 보인다"까지.
- [스크린샷: (화면·강조할 위치를 한 줄로)] — 이미지 자리표시. 실제 이미지는 사람이 캡처해 넣는다(아래 3번).
- ✅ 다 됐는지 확인하는 법 — 성공 상태를 눈으로 확인할 신호.
- ⚠️ 여기서 잘 막힙니다 — 흔한 실수·헷갈리는 지점 미리 경고.
C. 에러 대처 / 문제 해결
- 증상 → 원인 → 해결 순의 표. "이 메시지가 뜨면 → 이렇게" 형태. (왜: 급한 사람은 증상으로 검색한다)
- 해결 안 되면 어디로 문의하는지(채널·연락처)까지.
D. FAQ
- 실제로 자주 나오는 질문만. 지어낸 Q 금지 — VOC·문의 로그·팀 경험에서 뽑고, 근거 없으면 "확인 필요".
3. 스크린샷·시각 자료
- 글로 여러 줄 설명할 걸 이미지 한 장이 대신한다. 단계마다
[스크린샷: 무엇을/어디를 보여줄지] 자리표시를 남기고, 강조할 영역(예: "우상단 '만들기' 버튼")까지 지시문으로 적어 사람이 그대로 캡처하게 한다.
- 간단한 안내 이미지·다이어그램이 필요하면 [[simple-design]], 화면 시안이 필요하면 [[mockup]]으로 넘긴다. 실제 제품 스크린샷은 클로드가 지어내 그리지 않는다 — 자리표시만.
4. 문체 규칙 (초심자 기준·용어 일관)
- 쉬운 말: 전문용어는 처음 나올 때 한 줄로 풀어 준다. 모르는 약어 금지.
- 용어 통일: 같은 대상을 여러 이름으로 부르지 않는다(예: "소재"면 끝까지 "소재", "크리에이티브"와 섞지 않기). 문서 앞이나 뒤에 용어 미니 사전을 둔다.
- 2인칭·명령형: "~하시면 됩니다 / ~을 누르세요"처럼 독자가 따라 하기 좋게. 존댓말 유지.
- 한 단계 = 한 동작, 화면에 실제로 보이는 라벨을 그대로 인용("'만들기' 버튼").
5. 반자동 (초안까지만)
AI는 초안·뼈대·자리표시까지. 실제 스크린샷, 최종 문구, 공개 게시는 사람이 결정. "여기까지 채웠고, 이 스크린샷/이 수치는 확인 필요"라고 솔직히 넘긴다. 자동 게시 금지.
6. 저장·공유 (선택)
- 완성 초안은
data/docs/에 날짜-유형 이름으로 저장 제안. 예: 2026-07-26-user-guide-imagefactory-onboarding.md.
- 헬프센터/노션 등에 올리려면 초안 페이지 생성 제안 → 사람 승인 후 게시.
흐름 예시
1) "누가·무슨 일을 하러 오나요? (온보딩/특정 How-to/FAQ)" → 유형·과업 확정
2) context.md·실제 흐름 확인 → 모르는 단계는 "확인 필요"로 표시
3) 과업 기준 목차 → 단계별 초안 + [스크린샷: ...] 자리표시
4) ⚠️막힐 지점·에러 대처·FAQ 채움 → 용어 통일 점검
5) 초안 완성 → "초심자가 이대로 따라 할 수 있나" 사람(초심자 눈높이) 검토 제안
체크리스트 (넘기기 전)
코칭 (신입이면)
"기능 순서로 쓰면 쓴 사람은 편하지만 읽는 사람은 자기 일을 못 찾아요. 사용자가 뭘 하러 왔는지부터 잡고, 그 일이 끝나는 지점까지를 한 과업으로 묶으세요. 그리고 좋은 가이드는 '잘 될 때'가 아니라 '막힐 때'를 대비한 문서예요 — ⚠️와 에러 표가 진짜 실력입니다."
관련: [[method]](사고 흐름) · [[research]](실제 흐름·VOC 확인) · [[plan-doc]](다른 기획 문서) · [[write-spec]](기능 스펙) · [[mockup]]·[[simple-design]](화면·안내 이미지) · [[metrics-report]](가이드 이후 사용률 확인) · [[decision-log]](용어·정책 결정 기록)
