화면 정의와 기능 정의 2부, 기획자를 위한 디스크립션 작성 원칙

화면 레이아웃 구성과 기본 요소 배치가 끝나면 디스크립션 정의가 필요합니다. 개발자와 디자이너가 기획 문서를 볼 때 1차적으로 화면 그림을 확인 후, 이해가 안 되는 부분이나 화면 전환 같은 자세한 기술 내용을 디스크립션에서 확인하게 됩니다. 보통은 그림책을 읽거나 그림이 콘텐츠에서 먼저 보이듯 개발자나 디자이너가 이해를 돕도록 가능한 그림을 통해 동작 가이드를 제공하는 편이 좋습니다. 그 밖에도 되도록 간단하게 서술될 부분만 언급하고 자세한 서술이 필요한 경우 뒤 장에 별도의 장표를 추가하여 상세 가이드를 두는 것이 좋습니다. 이번 편은 화면 옆 혹은 아래 배치된 디스크립션 박스 안에 TEXT 작성 원칙과 순서 등을 알려드립니다. 해당 글은 기획 초보자나 입문자를 위한 화면 기획서 가이드라인입니다.

화면 기획 후 text로 상세 기술을!

<기획서의 와이어프레임에 들어가는 text는 최소 5.5 포인트 사용을 합니다. 너무 작으면 가독성이 떨어집니다. 기획서를 송부하거나 이관하기 전에 추가로 불필요하게 와이어프레임 아래 깔려 있는 이미지가 있는지 확인해봅시다.>

1. Text 디스크립션 작성 대 법칙

• Hierarchy(우선순위)대로 기술해주세요!
• Grouping(그룹)하여 서술해주세요!
• 넘버링과 Bullet을 붙이시고 되도록 간결하게 작성해주세요!
• 중요한 부분은 Highlighting(예:볼드) 처리해주세요!

1-1) 기능 버튼 & 인터렉션 (필수 입력)
기능 버튼, 실행 버튼의 동작 정의는 필수로 언급되어야 할 부분입니다. 예를 들어, 특정 버튼을 Tap 시, 레이어가 노출된다. 형식으로 문장형으로 대게 기술합니다. 전 후로 나누어 선택하면 혹은 액션을 가하면 어떻게 변화하는지 기술해주시면 됩니다. 혹은 전 후를 화살표 형태로 언급을 해주기도 합니다. 특히 토글 버튼인 경우 화살표 형태로 언급하는 형식에 적합합니다. 더불어 선택 시라고 두리뭉실하게 언급하는 것도 좋지만, 정확하게 tap인지 long tap인지 click인지도 제스처와 인터렉션을 정확하게 서술하는 습관을 가지는 편이 좋습니다.

1-2) 링크

링크의 속성(아웃링크, 딥 링크, 인 링크)을 먼저 서술하신 후 더불어 웹사이트 URL 주소나 앱 실행 프로세스를 언급해주시면 됩니다. 특히 링크는 기울기 표시하여 작성하고 URL 주소는 웹 링크를 직접 걸기도 합니다.
예시) – 위시켓 요즘IT : https://yozm.wishket.com/magazine/

1-3) 콘텐츠

• 콘텐츠 구성 요소: 콘텐츠 구성 요소를 그룹핑을 하고 각 구성 요소를 가장 먼저 언급해주십니다. 각각의 구성 요소는 하이러키(우선순위)에 따라 작성해주시면 됩니다.
• 화면의 각 영역이 대 타이틀은 볼드 처리해줍니다.
• 그루핑은 일반적인 상식의 흐름에 따라 즉 하이러키에 따라 (예:대그룹 소그룹 순)으로 정의해주시면 됩니다. 혹은 1번 콘텐츠 안에서 1-1), 1-2) 형식으로 넘버링하여 분류해주시면 문서 읽기에 편리하겠습니다.
• 최대/최소 범위(개수) 정의: 테스트 최대 개수가 정해지면 xx자 이후로 말줄임(…) 표시로 형태로 서술합니다. 직접 유사 케이스는 몇 자가 출력되는지 벤치마킹하셔서 제안해주셔도 좋고 때에 따라 GUI테스트가 필요한 경우도 있습니다.
• 삽입되는 이미지가 어떠한지 혹은 애니메이션이 있다면 어떤 형식으로 움직이는 지도 서술해주세요
• 어드민의 배너 이미지를 호출하는 경우 최대 몇 개의 이미지가 호출되고 회전이 되는지 자동 롤링 여부 등을 정의해주세요. 그밖에 프로젝트 상황에 따라 하드코딩 여부도 언급해주시거나 코드 번호도 간략히 서술해주세요.
• 콘텐츠(배너, 광고 이벤트 이미지 등)는 한 두 개의 콘텐츠가 노출되지 않고 다수가 노출되는 경우가 많아 Ordering(노출 순서)를 반드시 정의해줄 실 필요가 있습니다.
  예시) 배너 노출 순서: 배너 1 타이틀 → 배너 2 타이틀 → 배너 3 타이틀

1-4) 기능 동작 시 일련의 프로세스가 있다면

해당 기능을 선택 시 동작하는 프로세스가 단계 별로 구분되어 있다면 간략하게 넘버링 붙여서 text로 서술해줍시다.  

예시) *이후 진행 프로세스

1. 회원 가입 절차 실행
2. 운전면허 인증 단계 실행
3. 운전면허 인증 성공 시 메인화면으로 랜딩

1-5) 예외 케이스 & 공통 영역

• Description 최 상단에 영역 넘버링과 상관없이 해당 화면에 어떤 경위로 진입되었고 노출되었는지 언급해줍니다.
• GUI나 디자인에서 해주어야 할 부분은 GUI에서 테스트 후 fix라던가 하는 문장을 삽입해줍니다.
• 개발 퍼포먼스에 따라 생략 가능한 부분도 있겠지만 모든 단계를 생략 없이 정의해줍시다.
• 일반적인 동장 정의가 아니라 예외 변수 상황에서는 Case 1, Case2 형태로 달아 일반적인 동작 정의 후 아래에 기술합시다.
• Highlighting(강조)를 위해 의도적으로 영어 단어를 사용기도 합니다.
• 예시를 반드시 들어줍시다. 일반적인 글 쓰기와 동일합니다. 예를 들어 이해도를 도울 수 있습니다.

예시) %{Number Name}% 형식으로 노출됩니다. 

2. Default(고정 값)와 각 상태 값과 상태 변화를 반드시 정의해주세요.

이전 시간에 언급했던 것과 마찬가지로 초기 상태 혹은 고정값으로 보이는 Default 상태를 반드시 서술 해주 실 필요가 있습니다. Default로는 어떻게 화면에 노출된 상태이지만 동작(액션)을 가한 후에 어떻게 변화하였는지 각 구성 요소를 언급해 준 이후 아래에 서술해줍시다. 

3. Hidden(숨김) 여부에 따라 화면 노출 여부를 정의해주세요.

앞서 그린 화면에 (가능한 그림으로 언급되어도 되지만) 노출되지 않고 어떠한 액션에 따라 숨겨져 있던 UI가 호출될 수도 있습니다. 이런 부분도 놓치지 마시고 언급해주시길 바랍니다.

4. 지금 이 한 장이 아니라 Seamless한 서비스의 연결성을 늘 숙지해주세요

어떤 화면 팝업이 노출되는지 혹은 서브 화면으로 들어가는지 초기 화면 혹은 메인 화면으로 랜딩 하는지 등 진입 점과 랜딩 포인트를 반드시 언급해주셔야 합니다. 화면마다 스크린 ID가 넘버링되어있는 경우 스크린 넘버 ID를 언급해주는 편이 작업 효율성이 가장 좋습니다. 해당 기획 문서 장표 페이지 수를 기술 시, 업데이트함에 따라 페이지가 추가, 혹은 삭제에 따라 변경 가능성이 있습니다.

5. 영역 넘버링과 카테고리화(분류화)

디스크립션 설명을 위해 우리는 화면 특정 영역마다 넘버링을 표시하여 영역을 구분합니다. 구부 된 영역에 맞추어 디스크립션에 상세 기술을 하는 거죠. 그러면 읽는 분들이 매칭 하여 상세 서술을 확인하는 구조입니다. 이런 경우 디스크립션 각 영역 타이틀을 기술해줍니다.

예시) 설정 토글 버튼 
     → 메뉴 호출인 경우 %{메뉴}% +%{UI Element}%으로 디스크립션에 입력합니다.

각 영역을 설명할 수도 있지만 기획자에 따라 기능 버튼 작동만 서술하시는 분들이 계시다고 말씀드렸습니다. 이런 경우 기능 버튼에만 넘버링 표시하고 디스크립션에 해당 기능 버튼 작동에 대해서만 언급하는 구조로 진행됩니다. 기능 버튼만 간략히 서술 시 타이틀을 언급하지 않는 경우도 있습니다.

*기획서 작업 공수 줄이기 & 문제 해결 요령

프로젝트 규모가 크고 상위 클라이언트가 많다면 우선적으로 화면 UI 정의만 마치고 디스크립션은 공백으로 비워둡시다. 클라이언트 컴펌까지 완료되고 변수가 발생하지 않을 것이 확실시된 후 디스크립션을 작성하기 시작하여 가능한 작업 공수를 줄이도록 합니다. 

산업 특성 별로 비즈니스 기획과 기술을 이해해야 하기 때문에 지식이 많고 사고 유연성이 큰 사람이 유리합니다. 그러나 모든 내용을 잘 아는 기획자는 드뭅니다. 따라서 한 사람의 기획 노하우와 문제 해결법이 모든 상황에서 정답이 될 수 없습니다. 따라서 여러 사람들의 상황과 문제 해결법을 들어보는 것도 나쁘지 않고 가장 그 상황을 잘 아는 기획자는 바로 같은 환경에서 함께 일을 해온 선배일 수 있습니다. (*단, 너무 많은 사람들 즉 이 사람 저 사람 모두의 이야기를 참조하면 최종 결론과 선택을 내리기 어려워집니다. 기획자 나름의 기준과 주관으로 결론을 내리며 어떤 결정과 선택은 모든 협력사와 동료들을 만족시킬 수는 없음을 명심합니다.)

마무리하며

문서 작업 기술은 난이도가 높은 일이 아닌 트레이닝에 해당되는 작업이라고 생각합니다. 잘 기술된 레퍼런스를 구해 확인하신 후 자신의 것으로 소화를 하다 보면 어느 정도의 반복되는 골격이 보입니다. 개발과 디자인 업무의 상식도 알고 있어야 기술이 가능한 부분도 있지만 규칙이 보이기 시작하면 예외 변수나 기타 오류는 개발자와 디자이너에게 직접 확인 후 기획서에 추가하면 됩니다. UI 기획도 점차 목업 사용으로 추세가 바뀌어가고, 해당 직업을 사라진다고 보는 분들도 계십니다. 그러나 사람이 기획을 위한 글쓰기는 없어지지 않을 거라 생각합니다. 글쓰기에 필요한 일련의 체계와 논리성은 계속 필요할 것이라 봅니다. 적어도 디지털과 IT가 세상에 존재하는 한 말이죠.