화면 정의와 기능 정의 1부, 기획자를 위한 화면 정의 원칙

이번 시리즈를 통해 기획서의 화면 정의와 디스크립션에 들어가는 기능 정의의 원칙을 안내해드리려 합니다. 안내해드리는 지침대로 따라 하시면 적어도 욕을 먹지는 않을 것입니다. IT에서는 디지털 트랜스포메이션 흐름에 따라 다양한 소재와 다양한 성격의 프로젝트가 있습니다. 작업 방식에 따라 상식 선이 조금씩 다를 수 있지만요. 우선 범용적으로 사용 가능한 기초 공통 가이드를 알려드리고 뒤이어 디바이스와 UI화면 특성에 따른 원칙과 실제 사례, 구체적인 정책 등을 안내해드릴 예정입니다. 해당 글은 커리어 전환과 입문을 꿈꾸는 IT기획 입문자와 디스크립션에 더 자신감을 가지고 싶으신 분들께 적합합니다. 괜찮습니다! 한두 개 프로젝트만 가이드라인에 따라 경험해보시면 금방 감 잡으실 수 있습니다!

화면 정의 필수 원칙

1. 빠진 것 없나? 화면 구성 요소 체크하고 레이아웃 고민하기!

웹, 앱의 화면 기획서를 UI스토리보드, UI 가이드라인, 또는 UI시나리오라고 부르죠? 해당 문서에 UI Description 즉 화면 정의 페이지를 작성해본다고 가정해봅시다. 해당 디스플레이 화면을 기획한다, Wireframe을 기획한다고 보면 해당 화면에는 최 상단에 Status 상태 바(*공통 영역 섹션에 정의해준 경우 생략 가능합니다!), 글로벌 내비게이션 영역, 그리고 콘텐츠(텍스트, 동영상, 이미지, 광고 이벤트 영역), 액션 버튼, 링크 등으로 구성됩니다. 

1-1) 글로벌 내비게이션

최근 글로벌 내비게이션은 최하단에 바텀 바 형태로 제공되는 사례가 가장 많은 것 같습니다. 메인화면으로 돌아갈 수 있는 홈 아이콘, 서브 화면인 경우 이전으로 돌아갈 수 있는 백 버튼, 그리고 해당 화면이 레이어 형태라면 팝업 종료 버튼이 있어야 합니다. 그리고 1 depth 혹은 슈퍼 카테고리 메뉴, 메뉴를 열 수 있는 메뉴 버튼 등을 정의합니다. 

1-2) 인터렉션(제스처) 표시

파워포인트로 기획을 할 경우 인터렉션 표시를 정확하게 해주어야 하겠죠? 별도 범례 장표도 추가하여 해당 서비스 기획에 사용되는 마크를 설명해주면 좋겠습니다. 일반적인 터치 스크린인 경우, Touch(Tap), Long Tap, Double tap, Swipe, Flick, Scroll 등이 일반적입니다. Swipe, flick, scroll은 어느 방향으로 움직이는지 정의해주며 더불어 꼼꼼한 기획자인 경우 그림으로 중간 과정을 그려주는 경우도 있습니다만 보통 마크를 표시해주기만 하거나 간략하게 디스크립션으로 서술만 해줍니다

1-3) 콘텐츠 

콘텐츠는 이미지, 텍스트, 동영상 파일로 구성되는 것으로 이벤트, 배너, 그리고 베너에 해당되는 영역을 연상하시면 좋습니다. 디자인을 하여 하드코딩 형태로 작업되는 경우, (*특정한 액션 ui가 없다면) 글로벌 내비게이션을 제외한 전체 영역이 콘텐츠라고 봐도 좋을 것 같네요. 이미지 파일이 들어간다면 어떤 파일 형태인지, 애니메이션 등 움직이는 콘텐츠라면 움직이는 대충의 가이드라인도 명시해줍시다. 참고 이미지를 벤치마킹하여 기획서 안에 넣어주어 개발, 디자이너의 이해를 도와도 괜찮습니다. 상세 별도 화면을 분리하여 케이스 별로 제공되는 콘텐츠를 정의해주기도 합니다. 개인적인 경험으로는 미디어 서비스를 기획할 경우, 콘텐츠 상세 정의가 체계화되어 있고 정의해 줄 분량이 많았습니다.

1-4) 기능 버튼

기능 버튼 선택 시, 동작을 하며 화면이 전환되거나 특정 레이어 화면이 기존 화면 위에 노출되는 행위를 연상하면 좋은데요 쉽게 말해 동작을 유도한다고 보면 좋습니다. 따라서 동작을 누르기 전과 후의 화면이 다르겠죠? 

1-5) 링크

링크도 특성 별로 아웃 링크, 외부 링크, 딥 링크 등이 있습니다. 링크가 존재하는 경우, 화면 안에 UI를 넣어 사용자에게 액션을 유도하고 디스크립션에 필히 어떤 주소로 이동하는지 혹은 App인 경우 어떤 프로세스가 필요한지 언급해주시면 좋습니다. 

1-6) 기타

1 depth만 제공하는 경우보다 하위 항목이 있는 서비스가 더 많은데요! 하위 항목이 있는 경우 LNB(left, navigation bar)로 호출하여 내비게이션을 조정하는지 아니면 각 화면 안에 탭 메뉴 형태로 노출될 것인지 등을 정의해 줄 필요가 있습니다. 그 밖에도 위젯이나 알림 푸시 UI가 노출되는 경우 레이어가 어떤 방식으로 호출될 것인지 변화하는 UI 레이아웃을 정의해 주어야 합니다. 

• 하위 메뉴 UI 
• 팝업 (컨펌, 알럿, 일반 레이아웃 팝업) 정책

2. 공통 UI 규격서가 있으면 좋은 이유!

IT 프로젝트 규모에 따라 10명이 투입되는 프로젝트가 있고, 1명만 투입되는 규모가 있다. 대형 프로젝트인 경우 1명이 공통 기획서를 담당하는데 단일 서비스를 기획하는데 각각 기획자의 기획안이 너무 상이할 경우를 대비하고 글로벌 영역의 기획을 담당하는 것을 목적으로 진행하며, 단 한 명의 기획자가 지원하더라도 기획서 앞 장에 별도로 공통 화면 레이아웃과 요소를 1회 언급해주면 개별 페이지마다 반복되는 업무를 줄일 수 있어 편리하다. 

3. Default의 감을 길러라~!

처음 기획 안을 잡는 초보 기획자인 경우 Default뷰를 잡는 것도 어려워하는 경우가 더러 있습니다. 보통은 스크롤이나 Flick, Swipe 시, 추가 콘텐츠가 노출되는 경우가 많음으로 사용자에게 Hidden 된 콘텐츠가 있음을 알리기 위해 반 즈음 걸쳐 Default뷰를 그립니다. 사용자 액션을 유도하도록 적절한 큐를 기획해주시면 됩니다. 피그마 툴로 기획 작업을 하는 경우 디자인처럼 전체 콘텐츠를 노출해서 기획 하지만 때에 따라 파워포인트로 작업할 경우 물결무늬 표시로 아래 내용이 더 있음을 알려드리면 됩니다. 

*Default, Hidden 용어에 대한 자세한 설명은 링크로 확인해주세요!

4. 예외 케이스 정의

각 사용자 타입에 따라 혹은 데이터 유무에 따라 다른 화면을 노출되는 경우가 있습니다. 그런 경우 각 세부 케이스 별로 화면 정의가 필요한데 별도 장표로 추가하여 스크린 넘버 아이디를 부여하여 그려주어도 되고, 어떤 기획자는 작은 화면으로 장표에 넣어주거나 또는 디스크립션에 ~한 경우라고 기입하며 짧게 언급되기도 합니다.

* 범용적인 예외 케이스 몇 가지

• 콘텐츠 데이터 유무 (예. 최근 검색한 콘텐츠 이력이 있는 경우와 없는 경우 화면)  
• 회원/비회원 또는 로그인/비 로그인
• 권한의 유무 혹은 멤버십 회원 
• 개발 퍼포먼스에 따라 노출되는 화면 혹은 Skip 되는 프로세스 (예. 로딩 화면) 
• 오류 & 알림 푸시 등 돌발 이벤트 시

5. 화면 해상도, 디바이스 정의

프로젝트 발주 시 명료하게 클라이언트의 지시에 따라 디바이스나 규격이 정해져서 나오는 경우도 있지만 아닌 경우도 있습니다. Kick-off나 이 전 계약을 할 때 명확하게 의견 제시를 하고 정한 다음에 작업을 진행하기 바라며 휴대폰 디바이스도 많기 때문에 후에 테스트를 할 휴대폰 기기를 정하고 작업 사이즈, 해상도를 정의해주십시오. 반응형 웹 작업이 진행될 경우, 각 모듈에 따라 UI 레이아웃이 어떻게 되는지 별도 페이지를 통해 기획 안을 보여드릴 필요가 있습니다. 그 밖에 APP인지, WEB인지, 그리고 APP인 경우 네이티브 작업인지 안드로이드 혹은 ios 별개 작업인지 정의해주어야 합니다. 이에 따라 커스텀 형태로 화면 작업 한 벌만 하는지 아니면 각 OS별로 작업할지 명확해지겠죠? (보통은 커스텀 형태로 화면 작업이 되지만 그래도 확인해봅시다!) 이후 화면과 디스크립션 기획 작업 시, web과 app인 경우가 실행 프로세스 정의가 다를 겁니다.

※잘못된 기획 사례 하나를 소개해드립니다! (Feat. 우리에게 올바른 정의가 필요한 이유)

현장에서 정말 목격한 실제 사례를 소개해드릴게요. 프리랜서 기획자로 일하는 중, 어느 날 다른 초급 기획자 분의 기획서를 읽다고 깜짝 놀라고 말았습니다. (*보통 다른 영역을 담당하는 기획자의 기획서를 꼼꼼히 읽게 될 기회는 많지 않지만, 하나의 서비스를 만들고, UI 가이드라인에는 공통적으로 맞추어야 하는 부분이 존재하기 때문에 업무상 검토할 일이 있었거든요.) 그 기획자 분은 참고로 IT업계에서 디자인이나 개발 업무의 경험 없이 UXUI 혹은 서비스 기획자가 된 케이스였고, 사수를 두고 서포트를 하면서 차츰 업무를 배워나가는 과정 없이 바로 한 업무 영역을 맡았던 경우였어요. 

IT 관련 지식 기반 없이 기획 일을 시작한 것이기 때문에 나이도 이미 많았고, 무엇보다 배우려는 자세가 많이 부족한 분이었습니다. 본문으로 돌아가, 화면 디스크립션 정의를 읽어보니 이렇게 쓰여있더군요. “쿠폰 카드가 빨갛습니다. 파랗습니다.” 이미 눈치챈 분들도 계시겠지만 특정 화면에 들어가는 콘텐츠의 칼라를 지정하는 경우 기존 어드민 페이지에서 콘텐츠가 분류되는 방식을 언급해준다거나 분류의 새로운 기준을 테이블 형태로 화면 정의 뒤 페이지에 상세하게 정의해주어야 합니다. (*굳이 해줘야 한다면요) 그 마저도 사실 그런 문장을 넣는다는 게 어떤 현업 분들께는 비상식적일 일일 수도 있습니다. 왜냐하면 수주를 받은 프로젝트이던 인 하우스 작업장이던 칼라 지정은 기획자가 하는 일은 아닙니다. 엄연히 디자인 공통 가이드가 있으며 바꾸더라도 그것은 윗 분들이 권한을 가지고 변경을 지시할 수는 있는 정도입니다. (예. 은행 SI 프로젝트 부행장급에서 색 변경 지시) 

참 어렵죠? 업무 현장의 Role을 상세히 가이드를 받고 팁을 받아 나가는 분위기가 많이 사라졌다고 합니다. 그런 반면에 여러 방식으로 지식을 공유받을 수 있는 방법이 생겨나 그나마 다행이라고 생각하고 있어요. 커뮤니티 활동이던 실제 MVP 프로젝트이던 아르바이트 형태이던 IT의 각 분야 별로 업무 형식이 다르고 상식 선이 조금씩 다를 수 있으니 초급 중급의 레벨까지는 위시켓 같은 IT 프로젝트 플랫폼을 통해 부지런히 여러 지식과 노하우를 쌓아 갈 것을 추천드리는 바입니다.

Summary

아래와 같은 기본 원칙을 유의하여 화면을 정의하시면 좋습니다. 다음 편에는 구체적인 디스크립션의 기능 정의 법칙에 대해 알아보겠습니다. 

* 화면 정의 기본 원칙 5가지

• 화면 구성 요소 체크와 레이아웃 정의  
• 공통 규격 가이드의 필요성  
• Default의 감
• 예외 케이스 정의
• 화면 해상도 정의