안녕하세요, 부산 여행 중인 디자이너 메리입니다.
사실 일하러 온 거라 여행한 거 같지 않네요?
아무튼 오늘은 잘 만든 화면 설계서는 뭘까, 항상 고민하는 저만의 문제기도 합니다.
화면설계서를 잘 만들지 않으면 여러 포지션에 타격을 줄 수 있기 때문에,
오늘은 이 뜨거운 감자인 화면설계서에 대해 써보려합니다.
💡 좋은 화면설계서엔 어떤 정보가 담겨야 할까?
1. 화면 코드 (Screen ID)
• 예: USR_01_001
• 개발자가 API 명세를 맞출 때 • QA팀이 어떤 화면에서 버그가 났는지 추적할 때 • 운영자가 로그를 찾을 때→ 이 Screen ID가 모든 기준점이 됩니다!
뭐 화면명 짓는건 기획자 (혹은 디자이너) 마음이겠지만요.
저같은 경우에는 플랫폼 / 기능을 기준으로 짓습니다.
⸻
2. 화면 설명
가장 핵심인 내용, 화면 설명은 뭐 말그대로 제곧내인데요.
저같은 경우에는 신규 팀원이 와도 빠르게 이해하는 것이 중요하다고 생각하기 때문에,
최대한 쉽고 구체적으로 쓰려고 노력하는 편입니다.
📌 [예시]
- 목적: 회원가입 시 개인정보를 입력받는 화면
- 유입 경로: 온보딩 → 이메일 인증 완료 후 자동 이동
- 대상 사용자: 신규 회원
⸻
3. 데이터 정의
• 입력 필드: 어떤 데이터가 들어오고, 어떤 제약조건이 있는지
• 출력 필드: 어떤 데이터가 사용자에게 보여지는지
• 형식까지 명확히!
📌 [예시]
- 이름: 2~20자, 한글만 허용
- 생년월일: YYYY-MM-DD 형식
- 휴대폰번호: 숫자만 입력, '-' 자동 삽입
이 데이터 정의 저어어엉말 중요한데요. 기획자도 사람이다보니 (me ㅋ) 가끔 데이터 구조를 빠뜨릴때가 있습니다. 여기서 "CRUD" 개념이 참 중요하다고 느끼는 부분입니다.
그래서 저같은 경우는 이런식으로 구조를 짜는데요.
[화면 : 게시글 상세보기]
- Create : /post/write (작성 후 DB에 저장)
- Read : /post/{id} (상세조회)
- Update: /post/{id}/edit (제목, 내용 수정 가능)
- Delete : /post/{id}/delete (작성자만 가능,삭제 시 목록에서 비노출)이렇게 CRUD 개념에 맞춰서 작성한다면, 개발단에서 작성하는 API명세서도 깔끔해지고,
무엇보다 기능 누락이 정말 적어집니다.
기획서를 만들다보면,
디폴트 화면이 아닌 데이터가 꽉꽉 채워져있는 화면을 넣게되는데요.
이럴 때 동료들이 "데이터는 어디 신이 내려주나?" 라는 생각이 안들도록,
데이터가 어떻게 오고 가는지에 대한 기재가 정말 중요합니다.
⸻
4. 권한 & 접근조건
• 관리자만 볼 수 있는지 (관리자페이지의 경우, 접근 권한이 세분화되는게 필수)
• 로그인 유저만 접근 가능한지
• 특정 역할(예: 파트너사)에게만 노출되어야 하는지
💡 예시
- 접근 권한:
partner,admin만 진입 가능- 로그인 필수 여부: O
⸻
5. 버튼 및 인터랙션 설명
• 버튼 클릭 시 어떤 API 호출?
• Modal 뜨는 조건은?
• Validation 실패 시 에러 메시지?
[저장 버튼]
- API: POST /users
- 성공 시: 알림 “저장되었습니다” + 이전 화면으로 이동
- 실패 시: 필드 옆에 에러 메시지 출력
⸻
6. 에러 케이스 세분화
• 단순히 “에러 발생”이 아니라,
• 어떤 조건에서 발생하는지
• 사용자에게는 어떤 메시지를 보여줘야 하는지
• 백엔드에선 어떤 에러코드를 내려주는지
🚨 예시
- 휴대폰번호 중복 시: “이미 등록된 번호입니다” 출력
- 서버 오류(500): “고멘나사이. 일시적인 오류입니다." 출력
이런 게 잘 정리돼 있으면,
디자인 시스템에서 상태별 컴포넌트를 정의하기도 훨씬 수월합니다.
⸻
✨ 개발자들이 칭찬하는 ‘좋은 화면설계서’의 예시
✔️ 화면코드, 유입 흐름, 요구 기능 정리가 깔끔하게
✔️ 버튼마다 API 연동 흐름 명시
✔️ 권한별 UI 동작이 분리되어 있음
✔️ 성공/실패 시 알림 or 라우팅 정의
✔️ 오류 상황 명세까지 따로 문서화되어 있음
이 정도만 돼도, “와 기획서 깔끔하다” 소리를 들을 수 있을 것 같습니다.
반대로 이런 게 없으면, 개발단에 수많은 질문을 들을 수 있습니다.
개발할 시간도 촉박하기 때문에, 상세할수록 아주 좋다고 생각이 듭니다.
무엇보다 제일 중요한건, 기획서가 자세하고 명확하지 않을 경우 추가 개발과, 서버측에서 문제가 많이 발생하기 때문에 즈엉말 중요합니다. 기획.. 참 어렵고도 먼 길입니다.
⸻
🧠 마무리하며
화면설계서는 “보는 사람이 문서를 보고 바로 구현 가능할 정도”로 상세하게 쓰는 게 핵심입니다.
깔끔한 설계서 하나가 프로젝트 전체 품질을 좌우해요.
항상 저도 화면설계를 하며, 어떻게 하면 여러가지 기능을 놓치지 않을까.. 고민이 많이듭니다만 ^^;
다양한 동료분들과 얘기하면서 나온 "좋은 화면설계서"에 대한 기준을 기록해봤습니다.
그럼 20000 !
읽어주셔서 아리가또 고자이마스입니다.
