screen-brieflisted

# screen-brief 화면 하나를 만들기 전에 **타겟·문제·목적**을 사용자 본인의 판단으로 확정하고, 그 판단을 누적형 마크다운 기획서에 화면 단위 섹션으로 쌓는다. **핵심 원칙**: 타겟·문제·목적은 AI가 그럴듯하게 대신 채우지 않는다. AI가 답을 지어내면 디자인 시안 단계에서 무엇을 비교·판단할지 기준이 사라진다. AI의 역할은 질문으로 끌어내고 사용자의 답을 정리하는 것으로 제한한다. 사용자가 "네가 정해줘"라고 요청해도, 최소한의 선택지 두세 개를 제시해 사용자가 고르게 하고 임의로 단정하지 않는다. 디자인 역량이 약한 개발자가 "일단 화면부터 그려보자"로 건너뛰기 쉬운 단계가 바로 이 기획 단계다. 타겟·문제·목적 없이 만든 시안은 무엇을 기준으로 비교해야 할지 알 수 없다. --- ## 실행 절차 ### 1. 대상 문서 확인 프로젝트에 이미 기획서 문서가 있으면 그 파일에 화면 섹션을 이어 붙인다. 없으면 사용자에게 문서 경로를 묻거나(프로젝트에 기획/문서 폴더 관례가 있으면 그걸 우선 제안) 새로 만든다. 이번에 정리할 화면/기능 이름을 먼저 확인한다. ### 2. 타겟 정의 "이 화면을 누가 쓰나?"를 구체적으로 묻는다. "사용자 전체" 같은 답이 나오면 더 좁혀지는지 한 번 더 묻는다 — 상황·숙련도·빈도가 다르면 다른 타겟이다. AI가 짐작한 타겟을 제안하지 않는다. ### 3. 문제 정의 그 타겟이 지금 무엇 때문에 불편하거나 못 하고 있는지 묻는다. 기능 나열("~할 수 있어야 한다")이 아니라 현재 겪는 어려움으로 답이 나오게 유도한다. ### 4. 목적 도출 목적은 문제에서 자동으로 따라 나온다 — 별도로 묻지 않고 "그럼 이 화면의 목적은 '(문제)를 해결해 (타겟)이 ~하게 하는 것'이 되는데 맞나요?" 형태로 정리해 확인만 받는다. 이어서 성공 기준(무엇이면 목적을 달성했다고 볼지)과 실패 조건(무엇��면 실패인지)을 각각 묻는다. ### 5. 사용자 시나리오 타겟이 이 화면에 들어와서 목적을 달성하기까지의 흐름을 1~3개 시나리오로 받는다. 정상 경로 하나는 반드시 포함하고, 필요하면 예외 경로도 받는다. ### 6. 핵심 요구사항 / 제외 항목 시나리오를 실현하는 데 필수인 요구사항만 추린다. "있으면 좋은 것"은 제외 항목으로 분리해 이번 범위에서 뺀다. 레퍼런스(참고할 기존 화면·서비스)가 있으면 선택적으로 받는다. ### 7. 문서에 반영 아래 템플릿으로 화면 섹션을 작성해 대상 문서에 추가한다. 기존 화면 섹션은 건드리지 않고 새 섹션만 append한다. ``` ## [화면/기능명] - 타겟: - 문제: - 목적: - 성공 기준: - 실패 조건: - 사용자 시나리오: - 요구사항 (필수): - 제외 항목: - 레퍼런스: (선택) ``` 작성 후 문서 경로와 방금 추가한 섹션 요약을 사용자에게 보여주고, 시안이 필요하면 `mockup-review`로 이어갈 수 있음을 안내한다. --- ## 행동 원칙 - 타겟·문제·목적 세 항목은 생략하지