화면 설계서 작성법
화면 설계서(UI 설계서, 규격서, 와이어프레임 등으로도 불림)는 기획·디자인 단계의 결과물을 개발 조직과 그래픽 디자이너에게 전달하기 위한 문서다. 명칭은 프로젝트나 클라이언트마다 다르지만, 서비스의 규모와 구조, 화면을 구성하는 기능과 요소, 각 화면의 관계와 사용 흐름을 담아 서비스의 골격(IA)과 기능별 작동 방식, 상황별 예외를 관계자들이 정확히 이해할 수 있게 하는 것이 목적이다. 전통적으로는 키노트·파워포인트로, 최근에는 스케치·XD 같은 프로토타이핑 툴로도 작성된다.
화면 설계서는 크게 7가지 성분으로 구성된다. (1) 표지에는 프로젝트명, 문서 버전, 작성일, 작성자만 간략히 담는다. (2) 히스토리는 버전이 올라갈 때마다 언제·누가·무엇을 수정했는지 추적할 수 있게 기록하는 페이지다. (3) 목차는 페이지 제목이나 화면 이름을 순서대로 나열하며, 작성 진행 상태(수정·삭제·신규)를 함께 표시할 수 있다. (4) 인터랙션 가이드는 탭·더블 탭·스크롤·클릭·호버 등 인터랙션을 문서 내에서 어떻게 표기했는지 설명하는 범례 페이지다. (5) IA(Information Architecture)는 서비스 구조를 보여주는 페이지로 프로젝트 성격에 따라 생략되기도 한다. (6) 키스크린은 리서치·분석 결과가 구체적 화면 형태로 드러나는 핵심 산출물로, 디자인 소스가 입혀지지 않은 화면과 각 구성 요소의 동작을 설명하는 디스크립션으로 구성된다. (7) 플로우(시나리오, 워크플로우)는 완성된 키스크린들을 인터랙션 표기와 함께 연결해 서비스가 어떤 순서로 흘러가는지 보여준다.
화면 설계서는 기획자·개발자·디자이너·사업 담당자 간 커뮤니케이션 문서이므로, 같은 표현도 역할에 따라 다르게 해석될 수 있다는 점을 항상 염두에 두어야 한다. 애매모호한 표현이나 근거 없는 가정을 배제하고, 고정 영역과 유동 영역, 스크롤·버튼 동작의 결과와 순서를 최대한 명확하면서도 간결하게 설명해야 한다.
이러한 문서 작성 이전에는 UX 프로젝트가 어떤 방법론으로 진행되는지 이해할 필요가 있다. Lean, Agile, Sprint 같은 방법론은 디자인·빌드·테스트를 짧은 주기로 반복하며 검증과 개선을 거듭하는 반면, UCD(User Centered Design)·전통적 Waterfall 방식은 리서치 → 분석 → 문제 정의 → 컨셉·전략 → 디자인 → 빌드 → 테스트 순서로 한 단계씩 검증하며 넘어가는 선형적 진행 방식이다. 방법론 자체보다 이를 프로젝트 상황(인력, 비용, 협업 환경)에 맞게 선택하고 잘 운영하는 것이 실제 성패를 좌우한다. 아이디어 발산과 생각 정리를 위한 포스트잇 활용도 여전히 유효한 도구지만, 수단이 목적이 되지 않도록 주의가 필요하다.
핵심 내용
- 화면 설계서 = 표지, 히스토리, 목차, 인터랙션 가이드, IA, 키스크린, 플로우의 7가지 성분
- 키스크린은 디자인 소스 없이 레이아웃·인터페이스와 동작 설명(디스크립션)에 집중
- 플로우는 완성된 키스크린을 인터랙션 표기로 연결해 사용 흐름을 보여주는 단계
- 화면 설계서는 기획·디자인·개발·사업 담당자 간 해석 차이를 줄이기 위한 커뮤니케이션 문서
- Lean/Agile/Sprint는 짧은 반복 주기, UCD/Waterfall은 단계별 선형 진행이 특징
- 방법론 선택보다 프로젝트 상황에 맞는 운영이 성패를 좌우
관련 개념
- 키스크린과 인터랙션 프레임웍 — 화면 설계서의 핵심 산출물인 키스크린이 도출되는 6단계 과정
- 정보 구조 설계 IA — 화면 설계서에 포함되는 IA의 구체적 설계 방법
- Lean UX와 Agile UX — 화면 설계서 작성 방식에 영향을 주는 애자일·린 UX 방법론
- User Story와 애자일 — Agile 진행에서 화면 설계서를 대체·보완하는 도구
- 포스트잇 활용 사용자 조사 — 화면 설계서 작성 이전 발산 단계에서 쓰이는 도구
출처
- UX가 궁금한 개발자에게 보내는 편지 — 2019-12-09, 문한별