# data[].attributes.attachment_link.readable_text
화면설계서 - 구현하기 전 필요한 기능, 정책 등 화면 내 서비스의 모든 요소에 대해 정의하여 서비스 화면의 이해를 돕기 위한 문서

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) 화면설계 영역 (1) 메뉴 위치
화면이 위치한 전체 경로를 나열하는 영역이다. 보통 서비스의 경우 홈 또는 메인으로 시작하여 현재 위치한 화면명으로 끝난다.
(2) 화면명
현재 위치한 화면명을 기재한다. 되도록 화면명은 중복되지 않는 이름을 가지는 게 좋다.
(3) 화면ID
IA, 화면목록을 작성할 때 썼던 화면ID를 기재한다. 프로젝트의 규모가 클수록 화면ID를 잘못 기재하는 상황이 빈번하게 일어나기 때문에 각별히 주의해야 한다. 왜냐하면 보통 이슈를 논할 때 고객사와 수행팀은 화면ID를 기준으로 생각하기 때문이다.
(4) 화면영역
사용자에게 보이는 화면을 스케치하는 영역이다. 주의사항은 다음과 같은데

UI·UX관점에서 작성해야 함

글꼴, 색상, 도형 등의 UI 요소는 디자이너의 영역을 침범하지 않도록 최소한의 구분을 해야 함
ex) 기능의 차이에 따른 글꼴의 크기, 색상의 차이, 도형의 크기에 변화를 줘야 할 경우 화면설명에 반드시 이해하기 쉽게 요소에 대한 설명을 작성

설명이 필요한 요소의 번호와 화면설명 영역의 번호가 일치해야 함

기능이 다른 요소의 구분이 명확해야 함
ex) 서비스 중요도에 따른 버튼의 크기 구분, 제목과 내용의 글꼴 및 간격 구분 등
(5) 화면설명
화면영역에 부여된 각 번호의 요소들을 글로 풀어내야 하는 영역이다. 글과 색과 도형들이 어떤 역할을 하는지 문서를 보는 모든 사람이 이해하기 쉬워야 한다. 때문에 다음의 내용은 반드시 지켜져야 한다.

화면 이동 요소의 명확한 제시(화면명: 화면ID)

개발자, 디자이너가 이해하지 못했을 경우 잘 설명해 주기
2) 알럿, 팝업
알럿과 팝업은 서비스를 경험하는 사용자가 올바른 과정을 진행할 수 있도록 도와주는 부가적인 화면들인데, 이들은 특정 경우에 노출되기 때문에 어떤 상황에서 노출이 되는지 진입 가능한 화면에서 , 그리고 해당 화면을 닫을 시 화면의 이동은 어떻게 처리되는지 에 대해서 을 해줘야 한다. 그렇지 않다면 프로세스가 시작되고 사용자는 여행 중 길을 잃게 될 것 이다.
(1) 알럿 (2) 팝업
팝업은 광고 또는 기존 화면과 다른 새로운 정보를 알리기 위해 사용 한다. 대체로 긍정적 행동을 위해 노출이 되며 때문에 알럿 창과 다른 점으로 사용자가 내용을 인지하지 않더라도 닫을 수 있어야 한다.

다른 기획문서도 중요하지만 글쓴이는 특히 화면설계서가 중요하다고 생각한다.

"기획자는 모두를 만족시킬 수 없지만 모두를 이해시켜야 한다."라는 말을 증명할 수 있는 문서이기 때문이다. 이 글 또한 모두를 이해시킬 수 있을지는 모르겠지만 발행하는 과정에서 다시 한번 공부를 할 수 있게 된 계기가 되었다.
화면설계서는 회사마다 피그마, Adobe XD, 엑슈어, PPT 등 다양한 툴을 사용하여 작성한다. 즉, 기획자는 다양한 툴을 다룰 줄 알아야 한다고 본다. 때문에 글쓴이는 보안이 중요한 환경에서 업무를 진행하고 있어 PPT를 주로 사용하지만 피그마도 조금씩 공부하는 중이다.

# data[].attributes.attachment_link.title
기획자가 이건 할 줄 알아야지? - 화면설계서

# data[].attributes.attachment_link.description
03. 화면설계서 | 화면설계서 - 구현하기 전 필요한 기능, 정책 등 화면 내 서비스의 모든 요소에 대해 정의하여 서비스 화면의 이해를 돕기 위한 문서 =화면정의서, SB(Story Board) Why?

# data[].attributes.attachment_link.provider_name
네이버 블로그 | 웹어벤져스

# data[].attributes.attachment_link.readable_text
웹사이트 제작

안녕하세요. 웹어벤져스입니다.

웹기획에 사용되는 플로차르를 간략 소개해 드리겠습니다.

플우차트, 플로우차트 (Flow Chart)란

미리 정의된 기호와 선 등을 사용하여 프로그램 논리의 흐름이나

어떤 목적을 달성하기 위한 처리 과정을 표현한 도표입니다.

전체적인 사이트의 흐름도를 도식적으로 표현한 설계기법중의 하나라고 생각하시면됩니다.

프로그램 개발 작업을 하기 위해서는 DB 설계 내용이 나오고 프로그램 로직설계내용이 있어야 하는데

그려진 플로 차트의 흐름표를 통해서 내용을 이해하고 준수하면서 프로그램 작업을 진행하고 있습니다.

이런 흐름표가 있다면 디자인 페이지 뿐만 아니라 프로그램 페이지 내용에서도

어떤 페이지가 필요하고 또 누락되었는지 파악 하실 수 있습니다.

Web Site 하나를 구축하는 것도 커다란 프로그램을 완성하는 것과 같은 의미를 지닙니다.

플로차트는 스토리보드를 제작하는데 가장 중요한 작업 지침서입니다.

하지만 팀 호흡이 잘맞는구성원이 모여있거나..

이미 늘해왔고 간단한 로직 설계의 내용이어서 이미 눈빛만봐도 머리속으로 그리는 내용이 동일하다면

생략을 통한 불필요한 움직임을 줄일 수 있을것이라 생각됩니다.

# data[].attributes.attachment_link.description
웹사이트 제작 안녕하세요. 웹어벤져스입니다. 웹기획에 사용되는 플로차르를 간략 소개해 드리겠습니다. 플우차트, 플로우차트 (Flow Chart)란 미리 정의된 기호와 선 등을 사용하여 프로그램 논리의 흐름이나 어떤 목적을 달성하기 위한 처리 과정을 표현한 도표입니다. 전체적인 사이트의 흐름도를 도식적으로 표현한 설계기법중의 하나라고 생각하시면됩니다.