화면정의서 - UX 기획 서요한

# 화면정의서 이번 글은, "UX 기획자는 무슨 일을 하나요?"에 대한 대답 중 일부입니다. 결론부터 말하자면, 기획자는 서비스의 설계도를 그리는 사람입니다. 그리고 그 기능이 **이치에 맞도록** 만들기 위해 노력하기도 하죠. 어떠한 기능이 만들어지기 위해 필요한 인터페이스(화면, 음성, 버튼 등)와, 사람 간의 상호작용을 정의하게 됩니다. 그리고 오늘은, 그 설계도를 만드는 대표적인 문서양식 중 하나인 **화면정의서**에 대한 이야기입니다. ## 그 외에 기획자가 써야 하는 다른 문서는요? 하나의 서비스를 만들기 위해서는, 생각보다 많은 문서가 필요합니다. 다행히, 어지간한 대규모 프로젝트가 아닌 이상, 아래 정도면 서비스 제작이 가능하죠. (프로젝트 관리 측면 문서는 일단 제외) 1. 화면정의서 2. 정책 문서 3. 정보 구조([[일반적인 쇼핑몰의 정보 구조]]) 화면정의서는 이번 게시물에서 설명할 내용이니까 생략하고, 정책 부분은 각 서비스별로 천차만별이기 때문에, 여기서는 정보 구조(Information Archtecture, IA)에 대해 간단히 알아봅시다. 먼저 정보구조는, 말보다는 아래 예시를 보는 편이 빠르겠네요. ![[Pasted image 20250207134456.png]] 위에 제시한 스크린샷은 예시로 제작했기때문에, 생각보다 빠진 내용(목록, 수정, 삭제, 접근권한 등)이 많습니다. 이보다 더 다양한 내용을 하나의 문서로 작성해야 하기 때문에, 스프레드시트(ex: 엑셀)로 작성하기도 하죠. 조금 간단하게는, 기능 칼럼만 추가해줘도 됩니다...만, 그정도 수준까지 가면 그냥 기능정의서와 통합할 수도 있겠습니다. 여기서 제일 중요한 부분은 화면명과 ID입니다. 화면명은 중복돼도 상관없지만, 화면ID는 반드시 고유한 명칭을 사용해야합니다. 화면 ID는 회사마다 발주사마다 다른 형식을 적용하는데, 저는 보통 아래와 같은 형식으로 많이 적었습니다. {관리자/사업자/사용자}_{화면 카테고리 알파벳 2개}_{카테고리 내에 몇번째 정의한 화면인지} Ex: A_CM_01 여기서 언더바 대신 줄표(-)나 하이픈(—)을 쓰기도 하는데, 그 또한 발주사마다 다른 형식을 적용하므로 각 상황에 맞게 사용하시면 됩니다. # 명칭 화면정의서를 부르는 이름은 꽤 다양합니다. 스토리보드(혹은 SB), UID, 와이어프레임, 화면정의서, 화면기술서, 기획문서... 이외에 다른 명칭으로도 이 문서를 지칭할지도 모르겠습니다. 그러면, 각 용어를 천천히 살펴볼까요? ## 스토리보드 화면정의서를 부르는 가장 일반적인 명칭입니다. 좀 더 일반적으로는, SB(Story Board)라 줄여 부르죠. 사실 SB는 영화, 애니메이션이나, 심지어 연극/뮤지컬 연출 작업을 할 때도 자주 쓰는 이름입니다. _연극에서는 각 배역이 표현하는 감정이나 대사, 몸동작의 큰 줄기를 대본을 통해 설명합니다. 각 배역이 사용하는 소품이나 시선의 방향 등은 SB에서 정의하죠._ 대본이 서비스 내의 콘텐츠를 정의한다면, SB는 각 콘텐츠를 사용자에게 표출하는 방식을 정의한다고 볼 수 있겠습니다. ## UID User Interface Definition(혹은 Description, Design)이라고 합니다. 사실상 화면정의서라는 말과 동일한 명칭이죠? 기획자 또는 회사마다 다른 명칭을 사용하겠지만, 저는 이 이름도 꽤 좋아하는 편입니다. 화면정의서라는 문서의 목적을 명확하게 드러낼 수 있기 때문이죠. 아쉽게도 잘 사용되지 않는 용어입니다. ## 와이어프레임 종종, 화면정의서를 와이어프레임이라 표현하기도 합니다. UI는 프레임과 직선으로 이루어져있기도 하고, 각 프레임 간에 선을 연결하여 Flow를 표현할 수도 있기 때문이죠. 하지만, 이는 UX 디자이너에게는 전혀 다른 명칭으로 다가오기도 합니다. 왜냐하면 와이어프레임은 보통 아래 스크린샷 같은 작업물을 말하거든요. ![[Pasted image 20250207134621.png]] 와이어프레임과 프로토타입에 대한 모든 것 | [Adobe Blog](https://blog.adobe.com/ko/publish/2018/03/06/everything-you-need-to-know-about-wireframes-and-prototypes.html) ## 기획문서(기획서) 혹시나 해서 넣어두기는 했습니다. 종종 화면정의서를 기획문서나 기획서로 부르는 사람도 있더라고요. 그런데, 이는 어지간하면 써서는 안되는 용어입니다. 세상에는 매우 다양한 기획서가 있습니다. 서비스기획인지 사업기획인지, 심지어 전략기획 문서도 기획서라 부르기 때문이죠. 그래서 기획자에게 가서 “기획서 주세요” 하면, 짜증이 2% 정도 담긴 “어느 기획서요?”라는 질문을 듣게 됩니다. 물론, 개발자, 디자이너, 기획자만 있는 회의실에서는 기획서라는 말을 꺼내도 돼요. 하지만 다른 곳에서 그냥 기획서라고 부르면, 커뮤니케이션이 매우 취약한 사람 취급당할지도 모릅니다. ## 화면설계서 가끔이기는 하지만, 화면설계서라는 이름으로 부르는 곳도 있었습니다. 이렇게 불러도 의사소통 자체에는 무리가 없으니 상관없죠. 다만 (개인적으로) 이렇게 부르면 화면 자체만 설계한다는 어감이 있습니다. 무언가 GUI에서 만들어야 할 것 같기도 하죠. _물론 GUI에서는 “가이드 문서”라는 것이 따로 있긴 합니다. 컴포넌트 간 여백이나 나인패치 등 GUI 구현방식을 정의합니다._ 이외에도 맥락이나 회사별로 다양한 이름이 존재할 수 있습니다. 다만 저는 화면정의서라는 이름이 편하니까 이걸로 밀고 가겠습니다. 그리고 (개인적으로) 화면정의서라는 명칭이 제일 명확하다고 생각합니다. # 구성 요소 화면정의서를 문서로 엮으면, 보통 아래와 같은 항목이 포함됩니다. ## 정책 여기에는 회원정책이나, 팝업, 알림 정책 등을 설명합니다. ![[Pasted image 20250207134629.png]] [Figma로 만든 정책 문서](https://www.figma.com/file/h4rMFw8UPU5cWOAMpLEJnd/Rosetta?node-id=0%3A1) 예약 서비스라면, 예약 시점별 요금이나 예약 취소 가능시점 등을 정의하기도 합니다. 그래서, UX의 영역을 넘어서는 경우가 많죠. 그래서, 정책 부분은 아예 문서를 분리해서 정의하는 방법을 권장합니다. 좀 더 솔직하게는, 목차 자체도 필요없고 그냥 각 항목을 개별 문서로 빼서 정의하는 방법이 훨씬 편리할 수도 있어요. ## 공통 영역 GNB, LNB, Header/Footer, 게시판 pagination 등, 문서 전역에서 사용하는 공통 양식을 정의합니다. IA가 아직 완성되지 않은 상태라도 레이아웃 정도는 정의 및 조정이 가능하기때문에, 여러 서비스에서 유사한 형태로 사용할 수도 있고, 프로젝트 시작 단계일 때 맛보기 차원에서 미리 작성해두기도 합니다. 정책과 공통 영역은 보통 문서 맨 앞에 오는 경우가 많습니다. 공통으로 사용할 부분을 미리 정의해야 앞으로 정의할 때 훨씬 편해지기 때문이죠. 그런데 여기서, **공백 페이지**에 대한 정의가 포함돼야 한다고 생각합니다. ### 공백 페이지가 꼭 필요한가요? 화면정의서를 작성할 때 생각보다 많은 사람들이 깜빡하는 부분입니다. 앱 자체적으로 정의된 UI나 콘텐츠가 아니라, 서버에서(DB, 좀 더 정확히는 SQL로) 받아오는 콘텐츠를 뿌려주는 게시판 같은 경우 반드시 정의가 필요합니다. 페이스북 타임라인을 예로 들어볼게요. 사용자가 홈 화면에 접속했을 때, 게시물이 하나도 표시되지 않는 상태가 존재할 수 있습니다. 1. 불러올 수 있는 콘텐츠가 없거나(연결불가 상태 등) 2. 검색을 실행했는데 결과가 없거나(키워드 불일치 등) 3. 로딩중이어서 아직 불러오기 전 상태거나 이 중에서 1과 2는 비슷한 맥락에서 정의할 수 있습니다. 그래서 아예 동일한 화면을 사용하기도 하죠. 무엇보다, 서비스 오픈 전에 더미콘텐츠를 만들어서 올리는 방법도 있기 때문에, 사용자가 이런 화면을 보는 경우는 많지 않죠. 검색어가 이상하다거나 한 경우, 추천 콘텐츠를 보여주는 방법도 있습니다. 그런데, 3번은 전혀 다른 접근법이 필요합니다. 이 때는 아예 가상의 UI를 표시하여, 사용자가 목적 화면 표시를 기다릴 떄 덜 지루하도록 만들어주고는 합니다. 그리고 이 화면은 내용 없이 뼈대만 존재한다 해서, 스켈레톤 스크린이라고 부릅니다. 페이스북 앱에서 댓글 목록을 불러올 때, 내용 없이 댓글창만 보이는 경우를 자주 보셨으리라 생각합니다. 3번 부분을 초반에 정의해두지 않으면, 나중에는 서버에 정보를 요청하는(쿼리문을 던지는, API를 타는...) 구조나 앱 로딩 로직 등이 얽혀서 구현 자체가 불가능해지기도 합니다. 그러므로 이 부분은 미리 정의하는 편이 좋습니다. ## 로그인/회원가입 회원제 서비스라면 당연히 로그인과 회원가입 화면이 있겠죠? 그 화면 내에서 서비스가 동작하는 방식을 설명해야 합니다. 예를 들어 비밀번호가 틀렸을 경우 어떠한 안내문구를 사용하는지, 인증번호를 전송할 경우 대기시간이나 인증가능 횟수 등을 정의할 수도 있습니다. ## 개별 카테고리 라는 명칭을 쓴다는 말이 아니라, IA에서 정의한 개별 카테고리를 각각의 챕터명으로 사용한다는 뜻입니다. 예를 들자면 다음과 같은 명칭이 가능하겠습니다. > 홈, 검색, 알림, 마이페이지... # 작성양식 화면정의서는 보통 아래와 같은 방식으로 작성합니다. ![[Pasted image 20250207134815.png]] 기존에 쓰던 문서에서 발췌하기는 어렵고, 그렇다고 새로 서비스기획부터 진행하기도 의미없다 생각해서, 평소에 쓰는 앱 중 하나인 TodoList 앱의 UX를 간략하게 정의했습니다. 위 문서를 크게 셋으로 나누면 다음과 같습니다. 1. 상단 공통정보 영역 2. 좌측 화면 영역 3. 우측 설명 영역 그리고 저는, 2와 3을 합쳐서 “화면정의”라고 부릅니다. 종종 화면정의서를 기능정의서와 헷갈려하는 경우도 있는데요, 기능정의서는 서비스/앱 정책과 정보구조(Information Archtecture)를 포괄하는 문서라고 보심이 좋습니다. 위와 같이 화면 하나하나에 화면명과 ID를 매겨서, 각 화면별로 기능을 적은(Description) 형태를 문서화하면, 그것을 화면정의서라고 부를 수 있게 됩니다. 그래서 앱 하나가 만들어질 때, 화면정의서는 보통 100장 정도가 나오게 됩니다. 물론, 증권거래나 보험 등의 금융서비스는 화면정의서가 더 길어질 수도 있고요, 위처럼 간단한 TodoList 앱은 30장 정도면 충분할 수도 있습니다. ## 상단 공통 부분 ![[Pasted image 20250207134827.png]] 위 예시는 최소화된 형태라고 봐도 좋은데요, 이외에도 작성일이나 최종 수정일, 페이지 번호(쪽수)등을 필요에 따라 넣기도 합니다. 그리고 이 형식은 화면정의서 전체(표지, 간지, EOD 등 제외)에서 사용합니다. 화면정의서 작성은 어지간하면 PPT가 제일 편하죠. 왜냐하면 - 공통되는 부분을 편집 불가능하게 문서 틀로 지정 - 반복되는 부분은 페이지 작성 시 자동입력 - 문서 레이아웃 유지 같은 이유가 있기 때문입니다. 이외에도 일괄 바꾸기나 검색 등을 XD 등의 UI툴로 구현하기에는 조금 무리가 있어요. 그러면, 상단 부분에 포함된 요소를 하나씩 알아봅시다. ### 화면명 예시: 홈 / 홈 화면 - 로딩중 / 알림 목록 / 알림 목록 - 공백 말 그대로, 화면의 이름을 말합니다. 예시를 보시면 알겠지만, 규칙을 발견하기 어렵고 전문적으로 보이지도 않는 경우가 많아요. 사실 당연한 부분인데, 화면명 자체는 그 화면이 무엇인지 식별만 할 수 있으면 상관없기 때문입니다. 다만, 화면명을 정의할 때는 Depth를 인식할 수 있도록 설정하는 편이 좋습니다. 이 부분은 잠시 후 **화면 경로** 부분에서 설명할게요. ## 화면 ID 화면정의서 상단 부분에서 사실상 제일 중요하다고 할 수 있는 영역입니다. 무슨 일이 있어도 중복이 발생해선 안되며, 어지간하면 짧게 정의하는 편이 좋죠. 다행히, 화면 ID 자체는 그리 큰 의미를 지니지 않아도 괜찮습니다. 그래서 저는 화면 ID를 정할 때, 해당 화면을 읽는 발음에서 가져오는 편입니다. 예를 들어 고객앱 홈 화면이라면, A_HM_01 같은 방식으로 적어요. 물론, 이 또한 회사(또는 발주사)마다 다르기 때문에, 요구사항에 맞게 정의하심이 좋습니다. 가끔이기는 하지만, 화면명 자체도 개발자들 변수명 작성할 때처럼, 유의미하고 명확하게 지어야 하는 경우도 많기 때문이죠. 일단, 제가 화면 ID 짓는 방식을, 좀 더 구체적인 예를 들어 설명해 보겠습니다. 1. 앱, 모바일, 웹, 관리자, 사업자 등 플랫폼 규정 2. 화면이 어떤 역할인지 알파벳 두글자 정도로 정의 3. 해당 알파벳 내에서 몇번째로 정의한 화면인지 기록 - 숫자의 크고작음은 중요하지 않고, 중복만 조심하면 OK - 굳이 홈 화면이 01 이 아니어도 무관 - 개별 카테고리에서 100개가 넘지는 않겠으나, 혹 필요하다면 001 등으로 4. 화면 내에서 특정 요소만 달라지는 경우 개별 케이스 분리 - C01(케이스 1번), P01(팝업 1번) 등 여기까지 정의가 완료되면, 화면명과 ID는 아래와 같이 정리됩니다. - 홈 화면 | A_HM_01 - 홈 화면 - 콘텐츠 없음 상태 | A_HM_01_C01 - 홈 화면 - 콘텐츠 없음 - 알림 팝업 | A_HM_01_C01_P01 - 홈 화면 - 광고 팝업 | A_HM_01_P01 - 홈 화면 - 경고 팝업 | A_HM_01_P02 - 게시물 상세보기 화면 | A_HM_02 ### 화면 경로 사실, 화면정의서에는 화면 ID만 있어도 되지만, 굳이 화면명을 공통 영역에 적어야 하는 이유이기도 합니다. 서비스는 어지간하면 1Depth만으로 이루어지지 않죠? 보통 화면을 진입/이탈하며 서비스를 제공하기 마련입니다. 예를 들어, 중고나라에 방문해서 카메라를 구입하기까지의 Depth를 한 번 알아봅시다. 네이버 홈 > 카페 목록 > 중고나라 홈 > 중고나라 카메라 게시판 > 게시물 상세보기 > 쪽지 보내기 위에서 **네이버 홈**이나 **게시물 상세보기** 등이 모두 화면명에 해당하며, 위와 같이 해당 화면에 진입하기까지의 경로를 적으면 **화면 경**로가 됩니다. 웹기획을 할 때, 대부분의 화면은 특정한 위계를 지니게되고, 상위 화면은 하위 화면 여럿을 포괄하는 구조로 구현이 이루어집니다. 이러한 위계는 IA의 정의를 따르며, IA만 작성하는 기획자가 있을 정도로 꽤 중요한 분야입니다. 물론 규모가 작은 앱이라면 상관없겠지만, 대형 포탈사이트의 구조를 정의하는 경우 정보구조는 기획단계 중 매우 큰 비중을 차지합니다. 개인적인 감상으로는, 규모가 작을수록 화면정의가 중요하고, 규모가 클수록 IA가 중요한 경우가 많았어요. ### 작업자명 기획자란 모름지기 “잘하면 본전, 못하면 망”하는 직군이라 생각합니다. 그리고 작업자명은, 못한 사람에게 가서 잘하라고 이야기하기 위해 존재합니다. 반쯤은 농담이긴 한데요, 작업자명 자체는 분명 일정부분 **책임 요소**를 담고 있습니다. ~~Git blame~~ ~~저놈 잡아라~~ 웃음기를 빼고 이야기하자면 작업자명은, “이거 무슨 뜻이에요?”를 확인하기 위해 존재합니다. 누가 기획했는지 알아야 기획의도를 명확하게 확인할 수 있고, 그래서 서로 불편한 상황을 피하고 일정에 차질이 없도록 관리가 가능하기 때문입니다. 모든 화면과 동작에 대해 프로토타입을 제작해서 보여줄 수 있다면 좋겠지만, 그러기에는 생각보다 많은 시간이 필요하고, 그만큼 효율성이 떨어지게되죠. 그냥 그 부분을 작성한 기획자에게 가서 “이거 어떻게 구현하라는 뜻이에요?”를 묻는 편이 서로 편하잖아요. ### 생성일 사실, 생성일 자체는 그리 큰 중요성이 없습니다. 이력관리(History) 측면에서 필요한 요소이기는 하지만, 그보다 더 중요한 내용은 바로 ### 최종 수정일 이기 때문이죠. 기획을 하다 보면, “이거 언제 바뀌었어요? 왜 저한테는 전달이 안됐죠?” 같은 말을 생각보다 자주 듣게 됩니다. 그런 일이 없도록 기능이나 정책 변경이 있을 때마다 각 담당자에게 잘 전달돼야하지만, 히스토리만 기록하다보면 전파가 쉽지 않습니다. 그래서 언제 바뀌었는지 설명하고, 최신화된 기능 정의임을 주장하기 위해 최종 수정일을 기록합니다. 정책이나 요구정의서, 기능정의서 등과 화면정의서가 충돌할 경우, 어떤 것이 최신인지 확인하기 위해 최종 수정일을 관리하는 셈이죠. 예를 들어, 기능정의서가 수정됐는데 화면정의서 최종수정일은 그 이전이고 기능정의서와 내용이 충돌한다면, 당연히 화면정의서를 그에 맞게 수정해야 합니다. 대부분의 서비스는 일정한 방향성을 갖고 있으나, 세부사항은 온전하게 정의되지 않은 경우가 많죠. 결국, 큰 줄기를 따르며 발전하는 방향으로 갱신이 이루어집니다. ### 버전 문서의 버전은, 최종 수정일과 유사한 목적으로 작성합니다. 보통 0.4 전후로 GUI 컨셉이 일정 부분 제작되고, 0.6쯤에는 개발 또한 대부분 진행된 상태가 됩니다. 서비스 정책 등은 0.8 전후로 이루어지고, 이후로는 상세 정의(예외처리, UX Writing, 세부 flow 등) 단계입니다. 문서 버전이 1.0을 달성한다면, 화면정의서 제작은 거의 끝났다고 볼 수 있죠. 이 즈음 QA나 베타테스트 등이 진행되며, 실제 서비스 오픈은 1.0~1.2 정도에서 이루어집니다. ## 화면 영역 ![[Pasted image 20250207134846.png]] 다음으로, 문서 내 좌하단에는 화면 예시 영역입니다. 여기에는 (당연히) 화면이 들어가고, 화면 내 요소를 지칭하기 위한 번호를 부여합니다. 그리고 긴 화면 내에서 스크롤 영역을 따로 정의하는 경우도 있습니다. ### 화면(UI) 화면 자체는 과거에는 PPT 내에서 직선과 도형으로 직접 그리는 경우가 많았습니다. PowerMockup 같은 플러그인으로 UI를 그리기도 했다고 합니다만... 저는 그보다는 이후 세대라서 잘 모르겠네요. 최근에는 XD 같은 툴에서 UI를 그리고, 그림파일 등으로 PPT에 붙여넣는 방식으로 많이 진행합니다. 그 과정을 살펴보자면 1. PPT 페이지 하나를 완성해서 문서 레이아웃을 설정하고 복사 2. XD, Sketch, Figma 등으로 UI를 그려서 3. 복사된 PPT 내 이미지에 \[그림 바꾸기] 적용 이렇게 됩니다. 여담이지만, 위와 같은 과정은 GUI에서도 쪽가이드(PPT 형식 가이드)를 작성할 때 자주 사용하는 방법이기도 하죠. 그런데 이 과정이 조금 번거로워서 [아예 Figma 만으로 화면정의서를 만들면 어떨까?](https://www.figma.com/file/h4rMFw8UPU5cWOAMpLEJnd/Rosetta?node-id=0%3A1) 라는 생각도 했는데요, 권장하지 않습니다. 되기는 합니다만, 굳이 PPT라는 문서작성 도구를 버리고 UI툴로 문서를 그리는 이상한 작업을 할 필요를 느끼지 못하겠네요. 반쯤은 막말이긴 합니다만, 사실 기획자는 UI툴을 그렇게 잘 다룰 필요가 없습니다. 스스로가 UI툴을 **편리한 도구**라 사용할 수 있을 정도면 돼요. 최소한의 단축키 정도를 기억하고, 선이나 도형 그리기나 마스킹, 컴포넌트/레이어 관리 정도면 충분합니다. 방금도 말했다시피, 예전에는 PPT로 UI를 그리기도 했죠. 자, 기획자가 UI를 그리는 목적이 뭔지 생각해봅시다. "개발자와 디자이너가 알아볼 수 있게"가 가장 큰 목적이죠? 그래서 가끔은, 기획자는 종이와 연필로 UI를 그리고, 디자이너가 UI와 GUI를 XD를 사용해서 그리기도 합니다. 그러면 기획자는 기능 정의에 집중할 수 있고, 디자이너는 UI를 GUI로 바꾸는 노력을 하지 않아도 됩니다. ### 번호 문서 내에 \[1], \[1a] 같은 식으로 번호가 붙은 사각형이 있습니다. 해당 부분의 기능을 설명하기 위해 꽂아놓는 핀이라고 생각하시면 돼요. 왼쪽 위에서 오른쪽 아래까지 순서대로 번호를 설정합니다. 모바일 화면인 경우 큰 번호(1, 2, 3)는 가로로 차지하는 영역이고, 작은 번호(1a, 1b, 1c)는 영역 내에서 상세한 기능 정의가 필요한 요소입니다. 작은 번호는 1-1이나 1-a 같은 방식으로 기록하기도 하는데요, 이것은 각 발주사나 자사의 스타일을 따르는 편이 좋습니다. 따르지 않더라도, 문서 내에서는 동일한 스타일을 적용해야 합니다. ### 스크롤 영역 관성 스크롤은 [아이폰이 세상에 등장](https://slownews.kr/65798)할 수 있게 만든 혁신적인 아이디어였습니다. 작은 화면을 길게 사용할 수 있도록 만들었죠. 그리고 지금의 UX 디자이너에게는, "어떻게 하면 사용성을 유지하면서 수익 전환을 위한 고정버튼을 충분히 표시할까" 같은 고민을 던져주기도 합니다. 그리고 이렇게 고정 버튼과 스크롤 영역을 분리해서 설명하는 편리한 화면정의가 바로 위와 같은 **화살표 표기** 방법이죠. ~~프로토타입을 조금이라도 덜 만들기 위한 노력~~ ## 기능 정의 영역 ![[Pasted image 20250207134942.png]] 마지막으로 기능 정의 부분인데, 여기는 오히려 설명할 수 있는 내용이 많지 않습니다. 각 조직마다 정의하는 방식이 매우 크게 다르고, 스타일이 달라져도 내용은 동일하기 때문이죠. 번호를 붙인 영역과 요소가 어떤 역할을 하는지만 설명할 수 있다면 상관 없습니다. 그리고 이 방법을 익히려면, 직접 레거시 문서를 보며 익히는 수밖에 없겠네요. 역기획 문서를 작성하거나, 공개된 포트폴리오를 보고 익히는 등, 여러가지 방법이 있겠습니다. 그나마 보편적인 항목을 이야기하자면... - 각 번호별로 영역과 요소의 이름을 지정 - 정렬, 상태 등의 기본(초기)값 지정 - 상호작용(ex: 버튼 탭) 시 동작 정의 이 때, 버전이 올라가면서 삭제된 내용은 취소선 표시를 해주고, 추가/변경된 내용은 붉은색으로 표시해주면 좋습니다. 예를 들자면 이래요. <aside> 2c. 더보기 팝업 - Default : ~~항상 표시~~ 표시안함 </aside> 그런데, 기능 정의만으로는 어려운 경우가 있습니다. 예를 들어 1. 스크롤 등의 모션이 특별함 2. 일반적이지 않은 UX를 피치 못하게 적용 3. Long Press, Check 등 각각 다른 모션 적용 4. 화면 내 Check 등으로 화면 내(ex: scroll) 또는 화면 간(ex: depth) 이동이 필요 위와 같은 경우, 프로토타입을 제작하여 동작을 설명해야 합니다. --- 화면정의서 어떻게 쓰는지만 간단하게 설명하려 했는데, 생각보다 길어졌습니다. 다음번에는 ASANA, Jira, WBS(or Gantt) 등의 협업 환경을 어떻게 구축할 수 있는지, 한 번 이야기해보려 합니다. 곧 다시 봅시다. [프로젝트 관리](https://www.notion.so/4492fba4227448238b236b4e4593d05b?pvs=21) --- ## **Contact** GitHub : [https://github.com/john33fiao](https://github.com/john33fiao) Email : [[email protected]](mailto:[email protected])