기획 산출물 #2 화면 설계서
기능 정의서 다음은 무엇이지?
화면을 어떻게 구성하지?
나의 머릿속에는 앱이 하나 있다. 많은 고민 끝에 기능 정의서에 녹여내었던 여러 가지 기능이 내 상상 속에서는 이미 구현이 되어 있는 것이다. 하지만 문제는 그다음이다. 과연 어떤 화면의 모습으로 이 기능을 나타낼 것인가? 디자인은 또 어떻게 해야 하는가? 단순히 기능만 동작하는 앱이면 사람들이 잘 써줄 수 있을까? 또는 이 기능, 이 버튼을 어디다 넣어야 할지도 그려야 하지 않을까? 그런 고민을 하기 시작했다면 이제 준비가 된 듯하다. 기획의 꽃이라 불리는, 화면 설계서를 작성해보자.
이번 글은 기능 정의서에 정리한 내용을 어떻게 화면으로 녹여낼지를 그리는, 화면 설계서에 대한 생각을 정리해 보았다.
글의 순서는 아래와 같다.
1. 화면 설계서는 무엇이며, 왜 작성하는 걸까?
2. 화면 설계서, 어떻게 작성하는 걸까?
3. 그래서 화면 설계서로는 무엇을 할 수 있을까?
화면 설계서는 무엇인가요?
화면 설계서는 화면을 어떻게 표현할지를 그려놓은 와이어프레임과 기능을 구현하기 위해 작성하였던 기능 정의서를 합쳐놓은 것이라고 생각하면 이해하기 쉽다. 하나의 화면을 그려보고, 그 화면에서 구현되는 기능을 기능 정의서에서 가져와서 기재하는 것이다. 이를 통해 기획자가 구상한 앱의 화면이 어떠한 형태로 존재하는지를 디자이너에게 전달할 수 있고, 해당 화면은 어떠한 형태로 어떠한 동작을 수행하는지를 개발자에게 전달할 수 있다. 이를 전달받은 디자이너는 화면을 디자인하고, 디자인 한 내용을 개발자에게 전달하고, 개발자는 전달받은 이미지 위에서 동작하는 요소들을 설계하고, 배치함으로써 하나의 화면이 완성되는 것이다. 화면을 만들어내기 위한 요소들을 모두 준비할 수 있는 문서이다 보니 앞서 말했듯, 화면 설계서가 기획의 꽃이라 불리는 것이다.
화면 설계서는 왜 작성하는 거예요?
화면 설계서는 구상한 화면의 모습에 기능의 동작을 함께 작성함으로써 최종적으로 유저에게 보일 화면의 모습을 작성한 문서이다. 결국 기획자의 머릿속에 존재하던 앱의 모습을 디자이너, 개발자에게 전달하기 위함인 것이다. 이를 전달받은 디자이너가 UI 및 UX를 설계하고, 개발자는 동작을 구현함으로써 하나의 앱을, 하나의 프로젝트를 구현하게 된다.
어떻게 작성하는 걸까요?
나는 앞서 기능 정의서와 동일하게 버전 관리를 별도로 작성한다. 기획 프로세스, 산출물에 통일성을 부여하여, 협업을 하는 과정에서 일관된 경험을 제공하기 위한 방법이다. 화면 설계서에는 화면 ID, 화면 이름, 화면 경로를 상단에 작성하고, 하단에는 화면, Description, 컴포넌트의 Type을 작성한다. Description은 화면에 대한 설명을 진행하거나, 화면에 위치한 기능들에 대한 설명을 기재하는 영역이다.
화면 설계서를 작성할 때는 추가적으로 진행해야 하는 작업이 있다. 단순히 화면을 넣는 곳에는 서툴게 그려본 와이어프레임을 넣기만 하는 것이 아니라 화면에 존재하는 각 컴포넌트들을 하나하나 분리하는 작업이다. 분리한 각각의 컴포넌트에는 숫자나 또는 알파벳 같이 구분자를 추가해서 작성함으로써 Description에서 설명하기 용이하게 작업한다. 나는 숫자와 알파벳을 모두 사용한다. 하나만 사용하지 않는 이유는 더 명확하게 설명하기 위함인데, 나는 유저가 선택 또는 터치하였을 때 동작이 발생하는 지를 기준으로 구분하여 작성하고 있다. 하지만 회사 프로세스나 또는 프로젝트에서 필요에 따라서 다르게 작성하기도 한다. 일반적으로 화면 설계서는 파워포인트로 작성하나 나의 경우는 회사 프로세스 상 Confluence(컨플루언스)에 템플릿을 만들어 작성하고 있다.
1. 버전 / 수정 이력 관리하기
기능 정의서에서도 설명했듯 버전 / 수정 이력을 남기는 건 꽤나 중요하다. 반드시 작성해주자.
버전 / 수정 이력을 관리하는 부분에 대해서는 앞서 기획자의 산출물 #1 기능 정의서에서 설명해놓았으니까 참고하자. 간단하게 다시 설명하자면 버전 관리는 회사 내 일정한 프로세스를 수립하는 것이 좋다. 나의 경우에 기능 정의서와 동일하게 기획 내부에서의 변경사항들은 마이너 업그레이드로 조정하고, 개발자 및 디자이너와 리뷰를 진행하고, 리뷰를 통해서 나온 수정, 보완, 개선 사항을 반영하게 될 경우 메이저 업그레이드를 진행(1.0 -> 2.0)한다. 혹은 주요 기능이 추가되거나, 변경되는 경우에 메이저 버전을 업데이트하는 경우도 있다. 아래에 위치한 공통 사항 부분은 화면 설계서 전반에 공통적으로 적용되는 사항을 기재함으로써 문서를 보게 될 사람들의 이해도를 돕기 위해 작성하였다.
2. 화면 설계서 작성하기
버전 및 수정 이력을 작성했으면, 이제 화면 설계서를 작성해보자. 딱히 정해진 양식은 없다. 이해 관계자들과 논의를 통해 반드시 들어가야 하는 내용들을 정하는 것이 좋다. 이번 글에서는 화면 설계서 작성에 대한 이해도를 돕기 위해 브런치 화면을 통해 간단하게 작성해보았다. 실제로는 아래 예시보다 더 많은 내용이 담긴다.
가. 화면 ID 부여하기
ID를 부여하는 방식 또한 기능 정의서의 방식과 동일하다. 차이가 있다면, 맨 앞에 화면 설계서임을 명시하는 구분자 정도이다. ID는 각 화면별로 부여하며, 고유한 번호로써 하나의 화면에 하나의 ID만 부여한다. ID를 부여하는 이유는 추후에 해당 ID를 토대로 화면을 검색하기 쉽게 하기 위함이며, 의사소통 간에도 다소 긴 명칭 대신 아이디를 이용해서 명확하게 의사를 전달하기 위함이다. 화면 ID를 부여하는 방법은 딱 정해진 것은 없고, 회사 내에서 규칙을 수립하면 된다.
나. 화면 이름
화면의 이름을 기재하는 영역이다.
다. 화면 경로
현재 작성하고 있는 화면에 도달하기까지의 경로를 기재하는 영역이다. 이때, 모든 경로를 다 기재하는 것이 좋다. 이는 개발에도 용이하고, 추후 QA를 진행할 때도 좋다.
라. 화면
와이어프레임을 추가하는 영역이다. 위의 화면 설계서에서 넣은 화면의 모습은 원활한 이해를 위한 예시이기 때문에 이미 디자인이 되어있는 화면이다. 어느 정도 디자인이 되어있는 와이어프레임이면 좋지만, 와이어프레임은 사실 손그림의 형태로 나오기도 하고 네모 박스, 원, 텍스트 박스 등 기본적인 구성만 갖춘 모습이기도 하다. 중요한 점은 화면을 구성하는 컴포넌트를 쪼개어 공들여 작성함으로써 Description에서 설명할 수 있도록 만드는 것이다. 그래야 디자이너도 개발자도 이해하고 결과물을 만들어낼 수 있는 좋은 기획서가 된다.
나는 컴포넌트를 쪼개어 작성할 때 숫자와 알파벳을 모두 사용한다. 이를 구분 짓는 요인은 해당 컴포넌트를 선택 또는 터치하였을 때 동작이 발생하는지에 대한 여부다. 아무 동작도 하지 않는 요소라면 숫자로, 동작이 있는 요소라면 알파벳으로 구분 짓는다. 이는 화면 설계서를 보게 되는 각 이해관계자들이 본인들의 영역에 해당하는 부분들을 빠르게 캐치하고, 구현을 위해 더 고민할 수 있도록 하게 하기 위함이다. 다만 이렇게 작성하는 방법은 나의 기준이기 때문에 기획자 별로 방법이 상이할 수 있다.
마. Description
화면에 대한 설명, 컴포넌트에 대한 설명을 기재하는 영역이다. 나는 앞서 컴포넌트를 동작 여부를 기준으로 구분 지었다. 그래서 동작하지 않는 영역에 대해서는 해당 컴포넌트를 설명하는 정도만 작성하였고, 동작하는 영역에 대해서는 기능/동작에 대해 상세히 기재한다. 이때, 때로는 기능 정의서에 있는 내용들을 그대로 가져와서 Description에 기재하기도 한다. 동작에 대한 부분을 기재할 때는 특히 아래의 사항들에 유의하여 작성한다.
1. 어떤 기능(동작)인지
2. 사용자 액션(Input)은 무엇인지
3. 사용자 액션의 세부 내용은 무엇인지
4. 사용자 액션에 따른 기능(OutPut)은 무엇인지
예를 들어서 회원가입을 위한 아이디를 입력하는 단계를 가정해보자. 아이디 입력만 해도 꽤나 많은 정보들이 필요하다. 간단히 적어보자면 다음과 같다.
1. ID 입력 상자
가. 유저가 사용할 ID를 입력하는 영역
나. 입력 가능한 Data : 한글, 영문, 숫자, 특수문자
1) 입력 가능 byte(또는 글자 수) : 최대 20Byte
2) 20Byte 초과 시 : 20Byte 초과 부분은 입력되지 않음
다. Hint 사용 : "ID를 입력해주세요."
라. 중복 체크 여부 및 표현 방법
1) 텍스트 박스 하단에 중복 여부 표현
2) 중복 시
가) 문구 : "ID 사용이 불가능합니다."
나) 빨간색으로 ID가 중복되어 사용 불가함을 유저에게 전달
3) 사용 가능 시
가) 문구 : "ID 사용이 가능합니다."
나) 초록색으로 ID 사용이 가능함을 유저에게 전달
마. 빈(empty) 영역 선택 시 : 키보드 호출 -> 입력 유도
바. Type
컴포넌트의 속성을 기재하는 영역이다. 반드시 필요한 영역은 아니다.
화면 설계서로 무엇을 할까?
화면 설계서를 완성했다면 디자이너와 개발자와 리뷰를 진행하자. 최종 결과물이 나오기 전까지 화면 설계서는 앱을 만들어가는 데 방향성이 되어주고, 내가 기획한 요인들이 잘 반영되었는 지를 하나하나 체크할 수 있는 유용한 문서가 되어준다.
정리
철저히 주관적으로 그리고 개인적인 경험을 토대로 작성한 글이다. 현재 몸담고 있는 회사에서 진행하는 방식들을 위주로 정리하였기 때문에 다른 의견이 얼마든지 있을 수 있고, 더 좋은 의견들도 있을 수 있다.
1. 화면 설계서는 화면과 기능을 모두 기재한 문서이다.
2. 정해진 양식은 없지만 프로젝트를 진행하는 구성원들과의 협의를 통해서 일정한 양식을 정하자.
3. 버전 / 수정 이력 관리는 반드시 필요하다.
4. 최종 결과물을 만들어 낼 수 있는 문서인만큼 끊임없이 고민하고, 고민해서 상세하게 기재하자.
