기획자가 이건 할 줄 알아야지? - 화면설계서
03. 화면설계서
화면설계서 - 구현하기 전 필요한 기능, 정책 등 화면 내 서비스의 모든 요소에 대해 정의하여 서비스 화면의 이해를 돕기 위한 문서
=화면정의서, SB(Story Board)
Why?
- 구현 단계에서 디자이너, 퍼블리셔, 개발자들이 업무를 하는 데 있어 참고할 수 있는 문서
- 구현 단계 전 기능, 정책 등의 요소에 대한 정의 및 전반적인 테스트 가능
How?
- 표지 | 개정이력 | 플로우차트(연동, 화면 관점의 흐름도) | 설계화면 순 작성
- 본 문서 작성 전 UI, 정책, 컴포넌트 등 공통 요소에 대한 가이드를 정의하면 작성이 수월함
- 문서를 보는 모든 담당자들이 화면과 설명에 대해 일관성 있는 이해가 가능해야 함
- 특히 디자인 영역을 침범하지 않는 선에서 화면을 그려야 함
0. 버전 및 파일명
파일명 관리 기준실제 설계 단계에서 화면설계서를 작성하다 보면 수시로 내용이 바뀌어 많은 버전의 문서가 생성된다. 수십 가지의 문서를 헷갈리지 않고 효율적으로 관리하기 위해서는 문서 작성 전 버전 관리에 대한 가이드를 잡고, 동시에 동일한 규칙으로 작성된 파일명의 구분이 반드시 필요하다. 특히 에이전시의 문서는 고객사와 내부 수행팀이 서로 다른 버전의 문서를 볼 경우 말로 설명하기 어려울 정도의 혼란을 가져올 수 있으니 각별히 신경 써야 한다.
버전 관리
버전은 통상 N.NN을 기준으로 하며 프로젝트의 규모 및 가이드에 따라 다를 수 있음
최초 오픈 시 버전은 1.0으로 기재, 이후 수정 시 1.NN, 재오픈 시 N.O으로 표기
소수점 각 자리 수의 표기는 프로젝트 내부 가이드를 따름
파일명 관리
위 '파일명 관리 기준'사진을 참고하여 작성
ex - CCUR(찰리네초콜릿UI개선)_SB01(문서코드)_화면설계서(문서명)_NMA(PC/Mobile App/Web, Admin 구분)_상품(메뉴명)_V0.10(버전 관리 기준 반영).ppt
작성 중이거나 내부 수행팀의 업무 간 사용되는 문서의 경우 파일명 뒤에 날짜(yyyy.mm.dd), 상태(작성 중, 검토, 삭제 예정 등)를 표기할 수 있으나, 이후 산출물 제출 등으로 사용 시 지워야 함
1. 개정이력
기획자는 최종 산출물을 제외한 모든 문서들의 개정이력을 파악할 수 있어야 한다. 특히 화면설계서에서는 개정이력을 통해 각 화면의 추가, 삭제, 변경사항에 대해 파악할 수 있고 이의 책임담당자 및 검토/승인자를 알 수 있다. 이런 내용들은 추후 테스트나 서비스 오픈 후 발생하는 여러 가지 이슈에 대해서 수행사 - 고객사 간의 책임 논쟁에 있어 중요한 근거가 되기 때문에 반드시 작성하도록 해야 한다.
개정이력 관리 기준
반드시 화면ID와 그에 해당하는 내용을 기재
개정 일자는 YYYY/MM/DD, YYYY-MM-DD 등 여러 방식을 사용해도 좋지만, 표기방법은 반드시 통일시켜 검색할 때 혼란이 없어야 함
단순한 개정일 경우 개정이력에 적지 않고 해당 화면 영역에 기재 후 별도의 표시
2. 플로우차트
Flow Chart - 순서도, 흐름도라고도 불리며, 미리 정한 기호와 연결선으로 서비스의 흐름을 그림으로 표현한 문서이다. 플로우차트를 정확하고 이해하기 쉽게 작성한다면 특히 개발자는 화면과 설명을 보기 전 어느 정도 정리된 생각을 가지고 보다 수월하게 개발을 할 수 있다.
플로우차트는 관점에 따라 연동, 화면 흐름도로 구분 지어 작성할 수 있는데, 각 흐름도의 이해와 작성방법을 알아보도록 하겠다.
1) 연동 흐름도
연동 흐름도프로세스 안에서의 객체의 행동과 상호작용을 시스템 속 데이터의 흐름을 중심으로 작성하는 방법이다. 데이터가 변환되는 매체들을 표현하는데 중점을 두고 작성하여 작성된 화면과 프로그래밍을 연결시켜줄 때 사용한다. 글쓴이도 공부할 때 한 번 작성했던 경험이 전부인데, 연차가 낮은 기획자라면 작성하기 쉽지 않겠지만 적어도 자신이 수행하는 프로젝트에서 발생하는 데이터의 흐름을 파악하는데 도움이 될 것이다.
2) 화면 흐름도
화면(서비스) 흐름도서비스의 시작부터 끝까지의 흐름을 화면과 기능 단위로 쪼개어 작성하는 방법이다. 연동 흐름도와 마찬가지로 개발자에게 굉장히 유용한 그림인데, DB를 설계하거나 프로그램 로직을 짤 때 기획자와 플로우차트로 소통하게 된다. 또한 서비스에 대한 이해도가 낮은 사람은 모든 과정을 한눈에 파악할 수 있다.
작성 시 주의할 점
국제표준기구(ISO: International Standardization Organization)에서 지정한 기호와 흐름선을 활용해야 함
최대한 간략한 내용을 기입해야 나열된 많은 흐름을 어렵지 않게 파악할 수 있음
비교 및 판단에 대한 입·출력은 반드시 1개이며, 결괏값은 Yes·No로 나뉘어야 함
3. 화면설계
실질적으로 구현될 화면을 작성하는 단계이다. 각 화면에는 사용자가 마주할 모든 요소가 담겨있기 때문에 UI·UX, 기능/비기능 등 고려할 수 있는 모든 사항을 염두에 두고 작성해야 한다. 또한 실제로 프로젝트 수행 시 고객사에 의해 하루에도 몇 번씩 수시로 화면과 기능이 바뀌기 때문에 버전도 철저하게 관리할 수 있어야 한다.
1) 화면설계 영역
화면설계 영역의 구성은 다음과 같은데 글쓴이는 모바일 기준으로 메뉴 위치(location), 화면명, 화면ID, 화면영역, 화면설명으로 나누어 설명하도록 하겠다.
설계 작성 화면(1) 메뉴 위치
화면이 위치한 전체 경로를 나열하는 영역이다. 보통 서비스의 경우 홈 또는 메인으로 시작하여 현재 위치한 화면명으로 끝난다.
(2) 화면명
현재 위치한 화면명을 기재한다. 되도록 화면명은 중복되지 않는 이름을 가지는 게 좋다.
(3) 화면ID
IA, 화면목록을 작성할 때 썼던 화면ID를 기재한다. 프로젝트의 규모가 클수록 화면ID를 잘못 기재하는 상황이 빈번하게 일어나기 때문에 각별히 주의해야 한다. 왜냐하면 보통 이슈를 논할 때 고객사와 수행팀은 화면ID를 기준으로 생각하기 때문이다.
(4) 화면영역
사용자에게 보이는 화면을 스케치하는 영역이다. 주의사항은 다음과 같은데
UI·UX관점에서 작성해야 함
글꼴, 색상, 도형 등의 UI 요소는 디자이너의 영역을 침범하지 않도록 최소한의 구분을 해야 함
ex) 기능의 차이에 따른 글꼴의 크기, 색상의 차이, 도형의 크기에 변화를 줘야 할 경우 화면설명에 반드시 이해하기 쉽게 요소에 대한 설명을 작성
설명이 필요한 요소의 번호와 화면설명 영역의 번호가 일치해야 함
기능이 다른 요소의 구분이 명확해야 함
ex) 서비스 중요도에 따른 버튼의 크기 구분, 제목과 내용의 글꼴 및 간격 구분 등
(5) 화면설명
화면영역에 부여된 각 번호의 요소들을 글로 풀어내야 하는 영역이다. 글과 색과 도형들이 어떤 역할을 하는지 문서를 보는 모든 사람이 이해하기 쉬워야 한다. 때문에 다음의 내용은 반드시 지켜져야 한다.
용어의 통일
오탈자 최소화
화면 이동 요소의 명확한 제시(화면명: 화면ID)
개발자, 디자이너가 이해하지 못했을 경우 잘 설명해 주기
2) 알럿, 팝업
알럿과 팝업은 서비스를 경험하는 사용자가 올바른 과정을 진행할 수 있도록 도와주는 부가적인 화면들인데, 이들은 특정 경우에 노출되기 때문에 어떤 상황에서 노출이 되는지 진입 가능한 화면에서, 그리고 해당 화면을 닫을 시 화면의 이동은 어떻게 처리되는지에 대해서 반드시 설명을 해줘야 한다. 그렇지 않다면 프로세스가 시작되고 사용자는 여행 중 길을 잃게 될 것이다.
(1) 알럿
알럿 화면
알럿 설명알럿은 사용자에게 중요한 알림이나 경고를 나타내야 할 때 사용한다. 예를 들면 정보의 오입력, 접근 불가능한 영역의 접근 시도 등 부정적 행동에 대한 제지를 할 경우가 해당된다. 알럿 창은 사용자가 내용을 인지하게끔 만들고 닫을 수 있도록 직접적인 내용을 노출시켜야 한다.
(2) 팝업
팝업 화면팝업은 광고 또는 기존 화면과 다른 새로운 정보를 알리기 위해 사용한다. 대체로 긍정적 행동을 위해 노출이 되며 때문에 알럿 창과 다른 점으로 사용자가 내용을 인지하지 않더라도 닫을 수 있어야 한다.
팝업은 정말 다양한 종류의 팝업이 있다. 모달, 시스템, 컨펌, 레이어, 토스트 등 다양한데, 글쓴이도 가끔씩 팝업의 종류에 대해 궁금해 찾아보면 돌아오는 답은 항상 똑같았는데, 회사by회사라는 것이다. 물론 이론적으로 접근하면 dimmed 영역의 제어 가능 여부, 기존 화면과의 관계(새로운 화면 or 레이어) 등 다양한 기준으로 구분이 가능하지만 이는 내부 팀에서 조차 충분히 헷갈릴 수 있는 부분이기 때문에 팀에서 용어를 통일하여 사용하는 게 편할 것이다(시간이 된다면 추후 팝업의 종류와 정의에 대해 설명할...).
다른 기획문서도 중요하지만 글쓴이는 특히 화면설계서가 중요하다고 생각한다.
"기획자는 모두를 만족시킬 수 없지만 모두를 이해시켜야 한다."라는 말을 증명할 수 있는 문서이기 때문이다. 이 글 또한 모두를 이해시킬 수 있을지는 모르겠지만 발행하는 과정에서 다시 한번 공부를 할 수 있게 된 계기가 되었다.
화면설계서는 회사마다 피그마, Adobe XD, 엑슈어, PPT 등 다양한 툴을 사용하여 작성한다. 즉, 기획자는 다양한 툴을 다룰 줄 알아야 한다고 본다. 때문에 글쓴이는 보안이 중요한 환경에서 업무를 진행하고 있어 PPT를 주로 사용하지만 피그마도 조금씩 공부하는 중이다.
