화면 정의와 기능 정의 3부, 유용한 상세 가이드 꿀팁

1차로 화면에 정의된 내용을 확인하고, 2차로 디스크립션을 보며 구체적인 내용이나, 이해되지 않은 부분을 추가로 작성하는 경우가 있습니다. 따라서 더 정확한 기획 내용을 전달하기 위해 상세 가이드가 필요하며, 이런 세세한 부분들을 챙긴다면 다른 기획자와 차별화된 경쟁력을 갖출 수 있습니다. 반면에 일을 발주한 입장이거나 개발자들도 상세 가이드의 내용을 정확히 안다면 기획서에서 빠진 부분을 금방 캐치할 수 있습니다. 단, 디바이스나 프로젝트 성격에 따라 모든 꼭짓점이 기획 문서에 있어야 하는 것은 아닙니다. 

UX 방법론이 프로젝트의 맨먼스(Man/Month)나 정황, 부대 비용 등에 따라 가장 적합한 방법론을 적용하듯이 문서를 작성하는 데에도 여러 상황에 따라 유연하게 반영 요소가 달라질 수 있습니다. 그런 유연성은 아쉽게도 실전 경험을 통해 체득할 수 있습니다. 화면 정의와 기능 정의에서 언급된 원칙을 실제로 반영해보고, 또 여러 타입의 선배들을 따라 겪으며 배워갈 수밖에 없습니다. 

1. 공통 가이드

대략 200페이지 전후의 분량으로 1개의 화면 설계서가 필요한 경우, 공통 가이드는 문서 앞 장에 표기됩니다. 기획 문서를 구성하는 내용이나 메뉴 별 반복을 방지하거나, 메뉴 별 상이성을 줄이기 위해 존재하는 부분입니다. 공통 가이드 섹션이 마무리된 다음 홈 메인 화면으로 이어집니다. 서비스에서 사용되는 SNS 종류나 SNS에 공유하는 동작 플로우가 반복적으로 들어간다면 공통 가이드가 됩니다. 참고로 공통 가이드는 가이드를 말하는 것이지 공통적으로 쓰이는 공통 화면 문서와는 다른 성격을 가집니다. 

• UI 레이아웃 & 타입

해당 UI 레이아웃이나 타입을 문서에 삽입하는 경우가 있고, 생략되는 경우도 있습니다. 때에 따라 다르지만 반복되는 UI 레이아웃을 몇 장 기입하는 것도 괜찮습니다.

• 팝업 상세 정의

일반 팝업은 문자 입력형, 선택형, 의사 결정형, 확인형, 편집형이 있고 토스트 팝업이 있습니다. 팝업의 각각 UI 레이아웃에 따라 버튼이 한 개인 경우와 2개인 경우가 있으며, 이 기능 버튼을 선택 시, 각각의 액션을 기술해줍니다. 토스트 팝업은 키 액션 없이 N초 후 사라진다고 언급해주시면 됩니다. 각각의 팝업은 UI 레이아웃과 팝업의 유형, 어떤 케이스에 노출되는지를 기술해줍니다. 때로는 노출 문구만 별도로 기입해줍니다. 초기 서비스인 경우 사실 팝업의 케이스가 많지 않습니다. 따라서 오류 케이스도 상세하게 오류의 원인을 알려주는 것보다 공통 문구를 제공합니다.

• 알림 정책

알림이 디바이스 성격에 따라 띠 배너로 노출되는 경우도 있지만, 일반적으로 푸시 알림을 제공하죠. 푸시 알림은 케이스 별 문구 기술뿐만 아니라 DB 쪽 담당자와 의논하여, 배치 기간도 고려하여 기획합니다. 아주 초기 서비스 설계가 아니라면 이전에 제공되고 있던 알림 문구를 확인하고 추가로 설계할 필요가 있습니다. 

• 메뉴 & Navigation

메뉴 트리나 내비게이션의 동작 가이드, 기본 법칙을 서술해줍니다. 예를 들어, 최대 몇 depth까지 발생하고, 2 depth에서 바로 페이지 이동인지 아니면 하위 뎁스가 펼쳐지는지 등 액션에 대한 정의가 필요합니다. 각 페이지마다 서술해줄 필요는 없고, 메뉴는 단일하니 공통 가이드에서만 언급해주시면 됩니다.

• 용어 정리

계속하여 사용될 용어를 테이블 형태로 언급해주면 어떨까요? 신기술이 접목되는 경우, 클라이언트 측에서 기획 문서를 확인하다 용어의 생소함을 느끼거나, 각 장표의 메뉴마다 미세하게 다른 용어를 사용하는 것을 방지하기 위함입니다. 

• UI Flow

어떤 화면이 이다음 어떻게 이동하고, 이전에 어떤 동작으로 이 화면에 진입하는지를 한눈에 확인할 수 있습니다. 맨 앞장에 추가되는 장표로 각각 개별의 메뉴들의 이동 흐름을 파악하여, 서비스를 쉽게 확인할 수 있습니다.

2. 상세 가이드

화면 정의와 디스크립션 정의 외에도 추가 설명이 필요한 경우가 있습니다. 그런 경우 바로 이해가 가능하게끔 뒷장에 추가하여 보충 설명을 해줍니다. 상세 가이드의 성격으로는 페이지나 배너 등 콘텐츠를 롤링하는 경우, 노출되는 텍스트 문구나 UI 레이아웃, 추가 서비스 정책, 인터랙션 가이드를 포함합니다. 앞서 말씀드린 공통 가이드와 다르게 특정 페이지에 해당되는 사례를 설명해주는 페이지라고 이해하시면 좋습니다. 

• 인터랙션 가이드

개발자들이 빠르게 인터랙션 동작의 흐름과 캐치하도록 돕습니다. 최근에는 목업 툴을 활용하여 기획자가 기획하는 일도 늘었지만, 인터랙션 표현의 한계가 있어 문서로 정리하는 것이 가장 정확합니다. 모든 케이스의 동작을 설명할 필요는 없고, 설명해줄 필요가 있는 사례에 한해서만 그려줍니다.

• 콘텐츠(상품 아이템)

화면의 특정 영역에 자동으로 롤링, 노출되는 이미지나 광고가 있다고 가정해봅니다. 추가로 상품의 특성이나 해당 아이템마다 UI가 어떤 형식으로 노출되는지에 대한 설명이 필요할 텐데요. 이때 각 아이템 별로 어떤 정보 요소를 포함하고 있는지를 그려주면 한눈에 파악하기 더 쉬울 것입니다.

• 서비스 정책

서비스 기획이란 무엇일까요? 바로 정책을 잡는 일이라고 할 수 있습니다. UI 이전의 어떤 유즈 케이스가 발생할지 미리 예측하고, 이를 잡아내서 일이 시작되기 전에 정책을 바로잡는 부분입니다. UI 기획자 포지션이라도 서비스 기획을 잘 알고, 관점/포인트를 제안할 수 있어야 기획자로서 더 존중받을 수 있습니다. 또한 UI 그래픽 디자인 담당자 역시 정책적인 부분을 잘 알고 있어야 합니다.

2-1) 사용자 별(회원 별) 상세 유형

• 유저 별로 화면이 다르게 제공됩니다. 

2-1-1) 로그인한 사람 / 비 로그인 

2-1-2) 관리자 / 관리 권한의 정도(설정으로 구분)
2-1-3) VIP / 프리미엄 고객인지, 멤버십을 구매했는지, 또 정확히 어떤 상품 구매자인지에 따라 노출되는 콘텐츠 양과 화면이 다를 수 있습니다. 

2-1-4) 19세가 넘은 성인 / 미성년

미디어 콘텐츠 서비스 설계 시, 미성년과 성인의 개념이 포함됩니다. 예를 들어, 미성년인 경우에 콘텐츠를 어디까지 노출하는지 정의해줍니다. 성인 서비스를 이용 시, 성인 동의를 받고 문자 인증번호를 입력하는 프로세스를 정의해 줄 필요가 있습니다. 그 밖에 몇 시가 되면 스크린 보호기가 작동하는지를 정의해주기도 합니다. 

2-2) 데이터와 개발을 고려한 정의

콘텐츠가 많은 서비스라면 개발에서 고려해야 할 부분은 무엇이 있을까요? 첫 번째, 데이터가 무거울 수 있어요. 그렇다면 데이터를 불러오기 전에 어떻게 사용자에게 화면을 제공할지, 오류 발생 시, UI 화면에 데이터를 어떻게 노출할지 정의합니다. 

2-3) 배너 정책

배너는 종류가 많습니다. 띠 배너, 풀 팝업 이벤트 배너, 프로모션 빅 배너 등이 있습니다. 보통 이벤트나 광고성 성격, 신규 아이템 홍보 콘텐츠를 담고 있습니다. 배너가 프런트 화면에 노출되는 경우에 어드민에서는 해당 배너를 어떻게 등록하고, 자동 롤링인지 수동 롤링인지, 몇 초마다 노출되고 총 몇 개의 배너가 전환되는지, 신규 배너가 최초로 노출되는지 등의 상세한 액션을 정의해야 합니다. 이 외에도 전체 회원을 대상으로 제공되는지, 특정 고객에게만 노출되는지 노출 정책을 규정합니다. 어느 쪽에서 노출되며 선택 시엔 어느 화면으로 랜딩 하는지도 기획해야 합니다.

• 문서 정리 방식은 어떻게? → 삽입되는 이미지 & Text & 테이블 형태로

앞 장에 추가적으로 삽입되는 이미지나 노출되는 문구(ex. 팝업에 노출되는 예시 문구), 또는 상품 아이템, 광고 배너 아이템의 타입을 테이블 형태로 정리하여 보여줍니다. 레퍼런스나 어펀디스용 자료를 첨부해도 좋습니다.

※ 실전 리포트: ‘글로 배운’ 기획의 부작용

연애를 글로 배운다 라는 말이 있죠. 실제 상황이나 개개인의 캐릭터와 경험의 중요성을 모르는 융통성 없는 사람을 일컫는 말입니다. IT 필드에서도 비슷한 케이스를 종종 접합니다. 완벽하게 전공자들만 또는 경력자들만 모여 일을 할 수는 없습니다. 마치 끝과 끝이 잘 맞물려 돌아가는 나사 바퀴처럼 실제 상황들은 그리 이상적이지 않으니까요. 입문자나 초급 기획자들이 문제라는 뜻이 아닙니다. 예를 들어 애자일을 글로 배워, 해당 방법론만이 정답이라고 생각하는 사람이 있습니다. 혹은 대기업에 맞는 방법론만 아는 사람이 있습니다. 이들이 만일 더 작은 조직체에서 방법론을 적용해야 하는 상황이나 본인이 아는 방법론만을 고집한다고 가정해보죠. 이들은 프로젝트 상황과 별개로 본인이 일이나 실무를 잘 안다고 생각하는 경우도 많습니다. 

여기다 고집스러운 태도까지 갖추고 있다면 실무자들과 충돌이나 갈등은 부지기수 발생하게 합니다. IT 관련 종사자들 즉 디자이너, 개발자 기획자들은 다른 업종 종사자들보다 개개인의 프라이드가 강한 편이니까요. 연애도 책이 아닌 실전이 중요하듯이 기획과 관련한 실전 경험을 늘리고 상황마다 적합한 해결방법, 방법론을 적용할 수 있는 응용력을 키우는 것이 중요합니다. 다른 사람들의 경험이나 문제 해결방법도 중요한 팁이 됩니다. 적절하게 믹스하여 경험이라는 소스를 늘려 보다 위로 올라갔을 때, 더 유능하고 적합한 판단을 내릴 수 있는 리더가 될 수 있습니다. 소통을 할 때 본인이 아는 내용을 통해 다른 사람에게 설득시키는 방법도 있지만, 그 이전에 아는 게 많아야 다른 사람의 말을 정확히 이해할 수도 있는 것입니다. 결국은 모두 경험이 풍부하지 않아 일어나는 일들입니다. 

WRAP-UP

화면 정의와 기능 정의 마지막 3부의 상세 가이드 원칙을 확인했습니다. 계약 사항과 투입되는 맨먼스 등에 따라 유연하게 기획 문서에 포함될 요소들을 점검하고 구성하면 됩니다. 기획 문서란 표준 전과처럼 정해진 정답이 없습니다. 모든 것은 기획자인 여러분의 판단이고, 문서의 구성도 여러분이 결정할 수 있습니다.

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

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.