[Do it] 화면 정의서

1. 기획자는 화면정의서로 말한다

- SB/화면기획안/화면설계서 등으로 불린다.

 

화면정의서는 청사진이다.

- 웹사이트의 기능과 정책 등을 모두 반영한 주요 산출물이다.

- 기획자는 앞으로 발생할 모든 문제점을 미리 고민하여 대책을 세우고, 발생하는 경의 수를 예상하여 화면 정의서에 해결책을 담아야 한다.

- 디자이너 퍼블리셔 개발자 모두가 이거만 보고 기획자의 역량을 파악한다. 기획에 뜻이 있다면 목숨걸고 만들어야 할 문서.

 

화면정의서는 작업지침서다.

- 웹사이트의 모든 움직임을 상세히 담아야 한다.

- 화면정의서는 소통의 문서이므로, 디자이너/퍼블리셔/개발자의 입장에서 고민하는 습관이 중요하다.

 

- 한번 더 검토하기 : 본문의 설명은 오해가 없도록 명확히 작성하는 것이 중요하다.

- 깔끔하게 작성하기 : 설명은 한 문장에 한 가지 뜻만 전달되도록 작성한다.

- 작업자를 고민에 빠지지 않도록 한다 :

  : 이 정도는 말하지 않아도 알 수 있겠지 ? -> 모른다.

  : 에이 어떤 병신이 이걸 모르겠어 ? -> 모른다.

  : 이건 기본 중의 기본 아니야 ? -> 그 사람한테는 기본이 아니다.

 

2. 화면 정의서의 구성요소

- 표지 : 표지에는 화면 정의서 전체에 공통으로 해당하는 항목 위주로 작성하며, 항목은 필요에 따라 추가할 수 있다. 

  : 특히나 버전 표기가 중요하며, 다른 문서와 헷갈리지 않도록 문서의 최종 버전을 표기해야 한다.

 

- 문서 이력 : 개정 작업이 많으므로, 화면 정의서의 버전이 바뀔 때마다 사소한 부분도 모두 기록해야 한다. 

  : 버전, 화면 아이디, 이력 사항, 작성자 등을 명시해놓는다. 파일 이름, 표지, 문서 이력의 버전이 모두 일치하는지 항상 확인하는 습관을 들이는 것이 정신건강에 이롭다.

실제 현업에서 사용하고있는 표지 뒤 개정이력 양식

 

- 메뉴 구조도 : 웹사이트에 설계할 메뉴를 정리해놓은 문서. 웹사이트의 체계를 한 눈에 알아볼 수 있도록 작성해야 한다.

  : 표 형태로 작성해도 되고, 트리구조로 표현해도 된다. 웹사이트맵과 일치한다. 현업에서는 너무 많은 메뉴와 페이지로 인해 파일별로 분리하여 관리하기도 한다.

 

- 본문 : 통상적으로 화면 경로 및 이름 / 화면 아이디 / 화면 UI 설계 / 디스크립션(화면 설멍) 으로 구분한다. 

  : 전체적으로 화면정의서는 표지 -> 개정이력 -> 목표 및 컨셉 -> 메뉴 위치 및 구성(트리구조) -> 상세 옵션이나 정책 -> 화면 설계 

  : 현업에서 사용은 이렇게 한다.

실제 현업 화면 정의서 본문의 일부

 

3. 화면 정의서 작성

- 화면 정의서는 한장한장 완성하는 것이 아니라 흐름을 고려해서 모든 화면을 설계한 후 조금씩 구체화하는 방식으로 작성한다.

 

1단계 : 웹 사이트 제작에 필요한 화면을 화면 경로와 화면명만 작성한 채 모두 빈 슬라이드로 생성

- 웹사이트 지도를 생각하면서 화면을 모두 생성해놓는다

- 긴밀하게 연결된 이동과 관계를 생각하면서 구성한다.

 

2단계 : 모든 화면을 순서대로 대략 설계한다.

- 슬라이드가 어떻게 연결되는지 웹사이트가 작동하는 흐름에 집중하면서 대략 설계한다.

- 설계하면서 떠오르는 아이디어는 간략히 메모해놓는다

 

3단계 : 모든 화면의 설명을 대략 작성한다.

- 생각나는 대로 빠르게 일단 작성해놓는다.

- 정책 정의 단계에서 정의하지 못한 추가 정책을 결정해야 정의할 수 있는 사항도 있다.

- 예를들면 수량이 없는 재고 상품을 상품 목록에 노출시킬 것인가? 장바구니에 담긴 상품은 며칠 보관할 것인가? 하는 세부 정책들이다.

- 이렇게 다시 확인해야하는 사항은 별도 슬라이드에 일괄 기입하여 회의나 담당자와 함께 정책을 결정한다.

 

4단계 : 이용자의 이용 행태를 머릿속으로 실행해 보면서 설계한 레이아웃과 Discription을 구체화한다.

- 머릿속으로 굴려보자. 분명히 에러나 빈 공간들이 나올 것이다. 재검토하자

 

화면아이디 구성 방법

- 화면 정의서 문서에서 화면을 설계한 슬라이드를 가리키는 고유한 번호이다.

- 어느정도의 규칙이 있다.

- M - FE - GL - 10

- 구분1 : 화면의 구현 범위 (Pc, Mobile, Tablet 의 앞글자 PMT)

- 구분2 : FE(이용자 화면), BE(관리자 화면) 

- 구분3 : 설계화면의 화면 이름을 영문화 XXX-Page , XXX-List, XXX-Write 등으로 구성 후 ML GL 이렇게 함

- 구분4 : 한 화면을 설계할 때 여러 슬라이드로 나누어 설계할 경우 구분값을 숫자로 넣어준다. 숫자 아니어도 됨.

(10 단위로 구성하는게 꿀팁 : 10, 20, 30, ... ) : 중간에 추가해야하는 일도 빈번하기 때문

 

레이아웃의 설계 요령

- 레이아웃 설계는 검정 계열 색상만 사용한다. 색은 의미를 구분하거나 예외를 표현할 때 제한적으로 사용한다.

- 도형의 선 굵기는 얇게 만든다.

- 예시 문구는 실제 내용과 가깝게 작성한다.

- 시각요소를 활용한다.

- 데이터를 호출할때는 {} 를 사용한다.

- 화면이 길면 슬라이드를 나눠서 설계한다.

- 화면이 길 경우 컷아웃 도형을 사용해서 이전슬라이드/다음슬라이드와 연결됨을 표시해준다.

- 기능 설명을 위한 번호를 부여한다.

- 웹사이트의 메뉴에 따라 슬라이드를 구역으로 구분한다.

- 관리자화면을 고려한다. 상품 파라미터같은 것도 상세하게 고민해서 설계한다.

 

디스크립션 작성 요령

- 추가질문이 필요 없을 만큼 명확하고 상세하게 작성한다.

- 번호 순서대로 제목과 내용을 작성한다.

- 작업자에게 특별히 전달할 내용이 있다면 제목을 넣어 따로 구분한다. (ex: 개발자: 저렇게해주세요, 디자이너:이쁘게해주세요, 퍼블리셔:얼른해주세요)

- 기능설명은 웹에서 동작하는 사항 그대로 설명한다. 

- 정책 정의서에 작성된 내용이 기능의 정의가 될 수 있다. : 정책 정의서에서 정의된 내용을 기반으로 UI/화면이 일관적이어야 한다.

- 연결화면은 화면 경로(화면 아이디), 링크 연결 형태로 나누어 작성한다 : Link:화면아이디 혹은 url , target : _blank 나 self

- 경고 창, 선택 창은 이용자의 편익을 고려해서 사용한다.

  : 팝업이 많이 없다면 화면 정의서에 그냥 넣어도 되는데, 

  : 많다면 따로 표를 작성해서 정리할 수 있다.

  : 1~2개로 적다면 그냥 디스크립션에 작성해도 된다.

- 호출되는 데이터가 그리드라면 정렬값을 정의한다.

  : 데이터를 얼마나, 어떻게 호출할 것인지를 정의한다. 배치레이아웃이나 몇개를 어떤 방식으로 호출할지 명확히 명시한다.

  : 게시글이 없거나 호출할 데이터가 없을 경우에도 정의한다.

- 상황에 따라 다른 내용을 노출해야하는 경우 케이스로 구분해서 정의한다.

 

4. 공통 UI 구성하기

공통 UI를 만들어야하는 이유

- 유사한 기능을 기획자 간에 설계 형식을 약속해야 하므로 있어야 함.

- 보통 2회 이상 동일한 화면 설계가 필요한 경우 공통 UI로 설계한다.

- 공통UI에 웹사이트의 기능이 대부분 정의되어있다면 설계 가이드가 될 수 있다.

 

공통UI 정리하기

- 공통 UI는 IA, 기능 정의서 등을 확인하면서 필요한 UI요소를 추측하면서 정리한다.

- UI 요소 명 / UI요소 / 설명 / 활성화여부 / 설계 가이드  이런식으로 표를 만들어서 정리한다. 

- 작성예시 / 기능 / 작성가이드 형식으로 세분화가 가능하다.

 

5. GNB

- 웹사이트는 이용하기 쉽다고 매출이 오르는 것은 아니다. 이용자의 편리와 서비스 제공자의 이용 유도 전략이 중요하다.

- 이를 많이 반영해야하는 곳이 GNB이다.

이용자의 동선 및 이용 유도 고려

- 제품을 구매하려는 이용자는 GNB의 카테고리에서 물건구매 페이지 이동이 쉽도록 구성한다.

- 하지만 모두 구매하려는 건 아니고 고객센터같은 부수관점의 이용자들이 있으니 그것 또한 고려해야 한다.

- 웹사이트맵의 대분류를 반드시 네비게이션 메뉴로 해야하는 것은 아니다.

- 메뉴의 순서에 이용자의 흐름을 담아야 한다. 

- GNB가 복잡하다면 서브nav를 활용한다. 상품군이 많거나 서비스가 많은 경우에는 Depth를 통해 확장한다.

- 이름은 이용자의 입장에서 지어야한다. 짓다가보면 더 좋은 이름이 생각나서 수정하는 경우가 빈번하다.

- 공감을 얻어 고유어로 정착시키면 좋다. 근데 그게 참 쉽지가 않다.

시의성

- 일반적인 GNB 방식 외에 특정 시대의 유행을 반영한 GNB를 기획하는 것도 좋다.

- 예를들면 아이돌이 뜨는 경우 아이돌보기 같은 특수 메뉴를 추가해서 기능을 추가하는 것 등

- 유행어, 줄임말, 은어는 자제하자.