이 글의 내용
UI 디자인은 캔버스를 여는 순간 시작되지 않습니다. 문제, 사용자, 흐름, 상태와 제약을 먼저 확인해야 팀이 나중에 다시 설계하지 않습니다. 이 30개 질문은 UI 디자인 메이커에서 작업을 시작하기 전에 요구사항을 준비 상태로 바꾸는 체크리스트입니다.

30개 질문으로 준비 상태 확인하기
체크리스트의 목적은 질문 수를 채우는 것이 아니라 디자인에 들어갈 수 있는 조건과 아직 막혀 있는 조건을 분리하는 것입니다. 각 답변에는 담당자, 근거 링크와 확인 날짜를 붙이고, 답이 없는 항목은 추측으로 채우지 않습니다.
질문 1–5: 문제, 대상과 결과
누구의 어떤 문제를 해결하는가? 사용자가 완료해야 할 작업은 무엇인가? 성공을 판단할 관찰 가능한 결과는 무엇인가? 제품·비즈니스 목표와 사용자 목표가 충돌할 때 어느 쪽을 우선하는가? 문제의 범위 밖에 있는 것은 무엇인가?
질문 6–10: 흐름, 규칙과 소유권
정상 흐름의 시작과 끝은 어디인가? 필수 입력·선택 입력·권한 규칙은 무엇인가? 다른 시스템에서 들어오는 데이터는 무엇인가? 예외를 결정할 담당자는 누구인가? 변경이 생겼을 때 요구사항을 승인할 사람은 누구인가?
질문 11–15: 콘텐츠, 데이터와 개인정보
화면에 실제로 표시할 문구·숫자·단위는 무엇인가? 긴 이름, 빈 콘텐츠와 번역문을 어떻게 처리하는가? 개인정보와 보존 기간은 어떻게 제한하는가? 어떤 데이터가 서버·클라이언트·로그에 남는가? 법무·보안 검토가 필요한 지점은 어디인가?
질문 16–20: 상태, 피드백과 복구
로딩·빈 상태·성공·오류·권한 없음 상태를 모두 정의했는가? 사용자가 실패 원인과 다음 행동을 이해할 수 있는가? 재시도·취소·되돌리기·중복 제출을 어떻게 처리하는가? 네트워크가 끊겼을 때 입력을 보존하는가? 복구 후 사용자가 무엇을 다시 확인해야 하는가?

질문 21–25: 플랫폼, 반응형과 접근성
웹·모바일·태블릿에서 달라지는 조작은 무엇인가? 최소·최대 화면 폭과 입력 방식은 무엇인가? 키보드 포커스 순서와 스크린 리더 이름을 정의했는가? 색상만으로 상태를 전달하지 않는가? 느린 네트워크와 확대 환경에서도 핵심 작업이 가능한가?

질문 26–30: 디자인 시스템, 구현 가능성과 증거
사용할 컴포넌트와 토큰은 무엇인가? 새 패턴을 만들면 기존 시스템에 어떻게 등록하는가? 개발자가 구현에 필요한 간격·상태·에셋을 얻을 수 있는가? 기술적 제한이나 성능 예산은 무엇인가? 결정이 바뀌었을 때 어떤 근거로 되돌아갈 것인가?
결정 로그로 체크리스트를 작업으로 바꾸기
각 질문을 확인됨·결정 필요·차단됨으로 표시하고, 차단된 항목에는 수용 규칙과 담당자를 지정합니다. 예를 들어 결제 오류 상태의 카피와 재시도 규칙이 확정되기 전에는 시각 디자인을 승인하지 않는 식입니다.

30분 요구사항 리뷰 진행하기
- 5분: 문제·사용자·완료 결과를 소리 내어 확인합니다.
- 10분: 정상 흐름과 예외 상태를 화면 순서로 그립니다.
- 10분: 데이터·권한·접근성·구현 제약의 blocker를 표시합니다.
- 5분: 담당자와 다음 결정 날짜를 로그에 남깁니다.
알려진 제약으로 디자인 시작하기
모든 답이 완벽해야 하는 것은 아니지만, 모르는 항목은 모른다고 표시해야 합니다. 확정된 사실과 가설을 분리한 뒤 대표 화면을 만들고, 새 증거가 들어오면 결정 로그와 컴포넌트를 함께 업데이트하세요.
답을 모르는 질문은 빈칸 대신 결정 필요로 표시합니다. 담당자와 확인 날짜를 붙여 회의에서 바로 다룰 수 있게 합니다.
체크리스트를 완료했다고 표시하려면 문서·로그·승인을 연결합니다. 추측이나 오래된 요구사항을 완료 근거로 사용하지 않습니다.
새 컴포넌트를 만들 때는 이름, 상태, 토큰과 사용 범위를 기록해 같은 문제를 반복하지 않게 합니다.
결론
좋은 요구사항 체크리스트는 디자인을 지연시키는 문서가 아니라 재작업을 줄이는 실행 기준입니다. 30개 질문의 답, 담당자, blocker와 수용 규칙을 갖춘 뒤 UI를 시작하세요.