12 화면설계서 - 1편
IA, 용어 정리, 서비스 플로우
화면설계서 작업은 이제 본격적으로 프로젝트가 되어 결과물을 내놓기 위한 첫 단계입니다. 이벤트를 위한 한 페이지를 위해서도 화면설계서 작업을 거치고 이를 토대로 디자인, 퍼블리싱, 개발 산출물이 나오듯 경중의 차이 없이 무조건 필요한 과정인데요. 여기에서는 상위기획 단계를 거친, 즉 규모가 제법 큰 프로젝트 기준으로 화면설계서 작성에 대한 스킬을 언급하겠습니다.
1. IA
우선 상위기획 단계에서 작성했던 IA를(11회 참고) Index 1번으로 붙여넣기 하여 시작합니다. 이해관계자들(유관부서 모든 사람들, 외주라면 외주 직원들에게까지)에게 상위 기획서가 모두 공유되어 목적과 목표가 동일한 선상을 바라보고 있다는 전제 하에서 시작하는 것입니다.
IA는 앞으로 본인이 기획해야 할 각 기능(요소)들에 대한 전체 지도가 되어줄 것입니다. 그 표에서 우측에 '페이지 코드'라는 필드를 하나 더 생성한 후 각 기능(페이지)마다 임의의 코드(Ex. MUI_001, MUI_002...)를 부여해 주세요. 화면설계서 우측에 작성하게 될 디스크립션 영역 상단에도 그 '페이지 코드'를 함께 입력해 두면 향후 프로젝트를 진행하면서 이해관계자들과 커뮤니케이션할 때 유용하게 쓰입니다. 지속적으로 IA & 화면설계서를 업데이트(추가/수정/삭제) 하게 되면서 파일 버전에 따라 페이지 번호가 계속 바뀌고, 누구나 최신 파일로 다운로드하여 보고 있는 것이 아니기 때문에 '페이지 코드'로 커뮤니케이션하면 많은 혼선을 줄일 수 있습니다.
2. 용어 정리
여러 차례 언급했듯 동일한 무언가를 가리킬 때 각자의 경험에 의해 사용하는 IT용어들이 다른 경우가 매우 많습니다. 저는 화면설계서라 지칭했지만 스토리보드, 상세기획서, UI기획서, UID(User Interface Design) 그리고 요즘에는 미국에서 통칭하는 UX Design(User Experience Design) 용어를 많이 사용하기도 합니다. 어드민(Administrator)도 관리자 사이트, BO(Back Office), 관리 시스템, 약간 속성이 다르긴 하지만 CMS(Contents Management System) 등 혼용하여 사용하고 있습니다. 적어도 같은 프로젝트를 진행하는 이해관계자들 사이에서 만큼은 용어를 통일해서 사용해야 이 역시 혼선을 아주 많이 줄일 수 있습니다.
동일한 용어를 어디서는 '사용자'라고 했다가 몇 페이지 뒤에서는 '유저'라고 했다가 또 어디서는 '고객'이라는 단어를 사용하는 화면설계서는 기획자의 경험 부족 때문입니다.
아주 큰 대형 프로젝트를 단시간에 진행해야 할 때 한꺼번에 많은 기획자들이 투입되기도 합니다. 이때 기획자들이 각자 본인들만의 용어들을 사용하면 전체 화면설계서로 봤을 때 통일성을 떨어트려 이 역시 혼선을 가져다주게 됩니다. 향후 프로젝트를 진행하는 데 있어 전체 커뮤니케이션에 영향을 줄 만큼 중요한 요소이니 절대 간과해서는 안 됩니다. 또한 마지막 테스트 과정(QA)까지 이르게 되었을 때 수십 명의 이해관계자들과 일하며 가장 피곤하고, 가장 힘든 사람은 바로 기획자(이면서 PM) 본인이 될 수 있으니 반드시 용어 통일부터 했으면 합니다.
3. 서비스 플로우(Service Flow)
Workflow, Flowchart라 불리기도 하는데 저는 제가 처음 이 부분 기획을 하게 됐을 때 들었던 용어로 사용하겠습니다. 서비스 플로우를 그리는 이유는 모든 UI(페이지)에 대한 경우의 수를 전부 표출시켜(Draft UI를 기획할 땐 미처 생각하지 못했던 부분까지) 화면설계서를 그리는데 도움을 주기 때문입니다. 처음 서비스 플로우를 그려봤던 서비스가 지금은 추억이 된 '네이트온과 미니홈피 연동'으로 친구의 이름 또는 닉네임 옆에 미니홈피 아이콘을 표기하여 '미니홈피 바로가기' 기능을 제공하기 위해서였습니다. 각각의 흐름은 'Yes'와 'No'로 갈라지게 됩니다. 미니홈피 연동 버튼 클릭이 시작이며 '싸이월드 회원가입' 여부에 따라 갈라지고,(Yes면 로그인으로 이동하고, No면 회원가입 페이지가 팝업으로 뜹니다) Yes인 경우 로그인 여부에 따라 또 다른 경우의 수가 생기지요. 로그인까지 완료된 경우 아이콘 노출 범위(전체, 친구만) 알림 여부를 묻고, 알림도 친구 요청, 댓글, 방명록 알림까지 받을지 일부만 받을지 선택하게 됩니다.
추가적인 플로우 예를 들면 요즘에는 보안이 더 중요하게 됨에 따라 폰 인증 플로우가 특히 모바일에서는 필수 요소이고, 인증 수단 선택(로그인, 공인인증서 로그인, 지문 인식, 패턴 인식 등)에 따른 플로우, 회원가입 선택(소셜 로그인, 자체 회원가입 등)에 따른 플로우, 회원 속성(신규회원, 기존회원, 준회원, 정회원 등)에 따른 플로우 등입니다. 일반 유저들은 알지 못하는 또는 느끼지 못하는 수많은 갈림길들에 대한 경우의 수를 예외 케이스들까지 전부 기획자는 디테일하게 살펴 표면 위로 도출시켜야 합니다. 만약 여기에서 누락되면 화면설계서에서도 누락하게 되는데 너무 걱정할 필요는 없습니다. 저도 초보 시절 개발자가 DB Schema(데이터베이스의 전체적인 구조를 형식 언어로 정의한 것)를 설계하면서 '이 부분에 대한 UI가 없는 것 같다'라는 얘길 많이 들었고, 그때 추가한 경우도 많았습니다. 그러면서 배워가는 것이지요.
이해를 돕고자 구글에서 이미지 검색으로 서비스 플로우를 검색한 결과 페이지를 샘플로 링크했습니다.
저작권이 적용되는 이미지일 수도 있어 특정 이미지가 아닌 검색 결과 페이지를 링크했으며 여기에서 Yes와 No로 흐름이 나눠지는 플로우 위주로 참고 바랍니다.
개인적으로 심플한 기획을 지향하지만 서비스 플로우는 서비스가 거대하고, 복잡할수록(페이스북의 숨겨진 모든 기능들까지 생각해 보세요) 최대한 디테일하게 모두 담아내야 하다 보니 복잡하게 보일 수도 있습니다. 하지만 매우 심플한 서비스인 경우 UI를 보고도 충분히 모두 이해할 수 있다면 서비스 플로우 단계는 생략해도 괜찮습니다. 용어정리 또한 혼선의 여지가 없는 경우라면 생략해도 상관 없습니다.
