서비스 기획을 하기 위해 서비스를 구축하는 프로세스에 있어 계획을 수립하고 분석을 통해 설계 단계로 넘어오게 되는데 여기에서 고객사의 요구 분석 즉, 다시 말해서 제안요청서를 분석하고 인터뷰하고 프로젝트의 범위를 산정하고 서비스 방향성을 수립하여 기획 정의까지 구현이 된다면 그때서야 이제 화면 설계가 가능하다는 말이다.
그렇다면, 바로 화면 설계를 하면 안 되는 부분일까? 그 부분은 회사마다 다르며, 서비스마다 다를 수 있다고 설명하겠지만, 어느 회사를 가든 간에 화면 설계부터 시키지는 않을 것이라고 생각한다. 사실 필자는 반성해야 된다. 화면 기획부터 바로 시작한 케이스이기 때문에 실행하고 깨지고 배우고 습득한 것이라고 할 수 있다.
하지만 지금 말하는 부분은 한국에서 통용되고 있는 가장 정석적인 방법이라고 할 수 있다.
화면 정의서 작성기준 (화면 설계전 정책 설정)
이전 글을 통해 '계획 단계'를 거쳐 '분석 단계'를 통해 모든 범위를 산정하면 드디어 화면 기획 및 설계를 할 수 있는 단계가 나온다. 화면 기획을 하기 전에 '어떻게 해주세요' 혹은 '설계를 통해 컨버젼이 일어나는 구조로 만들어주세요.' 혹은 '화면이 깔끔하게 나왔으면 좋겠어요.'와 같은 요청 사항을 정리하여 추후에 Description에 반영한다.
이러한 설계는 굉장히 중요한 요청사항이기에 꼼꼼하게 기록하는 것을 잊지 않는다. 이제 화면 설계에 관한 이야기를 해보자.
Ⅰ. Stage 1: 화면 기획 정책 설정
Document에 대한 History 기록은 굉장히 중요한데 이는 고객사(권한 있는 담당자) 및 서비스 기획자(혹은 PM_보통은 기획자가 PM을 하는 경우도 많음), 개발자 및 이하 팀원, 디자이너 및 팀원, 퍼플리셔 및 팀원 등 모두가 이 서류를 통해 소통이 이루어지고 커뮤니케이션이 되기 때문에 이는 굉장히 중요한 서류이다.
따라서, 서류를 작성하고 개선 사항에 대해서 업데이트를 하는 것도 굉장히 중요한데 어느 하나가 누락되면 자칫 잘못하게 되면 모든 프로세스가 꼬일 수 있기 때문에 이를 관리하는 것이 중요하다. 모두들 알겠지만, 관리란 사무를 맡아서 처리하는 것으로 관리를 통해 누락사항에 대해서 지속적인 파악이 필요하다.
그러면 Document History에 들어가는 내용은 무엇이 있을까? 다큐먼트 히스토리에는 보통 프로젝트 내용, 버전, 개정 내용, 담당자가 들어간다. 추가적으로, Date/Version/Development Item/Description/Page가 들어갈 수 있다. 이는 상황에 맞게 작성 또는 재구성이 가능하다.
1) 문서 작성 정의(Component)
문서 작성 정의를 하는 것은 굉장히 중요한 부분으로 모든 TFT이 이를 인지하고 있어야 한다. 이는 약속이고 정책이고 기호이다. 약속된 기호를 통해 화면에서 오류 및 실수를 방지가 하기 위해서 작성된다. 그렇다면 예를 들어 어떤 기호가 약속된 기호이고, 어떤 구성이 있을까? 예시를 한번 들여다보자.
알기 쉽게 특수문자로 예를 설명(참고 : 현재 사용 중인 아이콘 수 : 85가지, CSS style : 50가지)
| 부호 | 명칭 | 부호 | 명칭 |
| ≫ | 다음 | ☆ | 중요도0% |
| ≪ | 이전 | ↑ | 상 |
| ★ | 중요도100% | ↓ | 하 |
이는 윈도에서 볼 수 있는 공통기호로 누구나 알아볼 수 있고 쉬운 언어라고 생각하시면 될 것 같다. 이에 따라 구체적인 컨 포넨트가 있겠지만, UI에 따라 다르기에 패스하도록 한다.
Ⅱ. Stage 2 : 화면 정의서 작성 기준
화면 정의서 작성 기준을 큰 카테고리로 분류하자면, 기본규칙/Input/페이 번호/게시판 목록 및 상세 버튼/Touch Gesture/Header/Footer/GNB 등이 이에 해당된다.
1) 기본 규칙
기본규칙에는 기본적으로 디스크립션이 들어간다. 또한, 여기에는 폰트 및 사이즈 그리고 타이틀에 강조가 필요한 영역에 대해서는 폰트 사이즈도 지정이 가능하다. 또한, 파일명에는 공백이 포함되지 않고 언더바를 사용하고, 산물 명도 공백이 있을 경우 언더바를 사용한다.
파일 이름은 산출 물명과 메뉴 번호, 버전을 기준으로 부여한다. 예를 들어 '삼성전자 스마트에디션_PC_01_메인_20210101_V1.0'와 같은 파일명을 지정하여 작성하도록 한다.
문서는 버전이 추가될 때마다 0.01, 0.02,... 순으로 누구나 알아볼 수 있게 작성되어야 한다. 이는 규칙이다.
2) Input
인풋은 다들 한 번쯤은 보셨을 것이다. 쇼핑몰에 들어가면 카테고리를 설정하는 칸을 말한다. 예시는 다음과 같다.
위처럼 [Select Box]에서 첫 번째 항목은 기본값으로 하고 선택 유도 문구 표시를 통해 선택 옵션 항목을 표현한다. 아주 기초적인 서비스 기획의 Input이고 추가적인 형태가 궁금하시다고 하면 댓글을 남겨주시면 글을 추가적으로 쓸지에 대해서 고려해보겠습니다.
3) 페이지 번호
페이지 번호는 여러분들이 쇼핑몰에서 아래로 스크롤을 내리면 "다음장에 뭘 팔지?"에 대한 궁금증과 동시에 클릭하게 되는 물건들을 말한다. 예시는 다음과 같다.
위 그림과 같이 [페이지 번호]에 대한 것이다. 이를 보면 굉장히 고려해야 할 것들이 굉장히 많다는 사실에 대해서 알 수 있다. 정말 단순하게 [화면 예쁘게!] / [나는 PPT를 잘해!]가 아니란 사실이다.
4) Touch Gesture
터치 제스처란 말 그대로 터치를 했을 때 어떤 결과가 일어나는지에 대한 결괏값에 해당된다고 생각할 수 있다. 다만, 이 부분은 특정한 제스처이기 때문에 도와줄 수 있는 부분이 아니기에 읽고 아이데이션만 갖추면 될 것으로 사료된다.
다음 편에서 화면 정의서 작성기준②에서 팝업과 레이블링 등에 대해서 작성하도록 하겠습니다.