기획 일을 시작하고 가장 먼저 부딪힌 것이 화면설계서였습니다.
선배들의 문서를 보면 형식이 다 달라서, 무엇을 써야 하는지 감이 잘 안 잡혔어요.
그래서 제가 직접 쓸 수 있는 템플릿을 만들어 보기로 했습니다.
아직 배우는 중이라 완벽하다고 할 수는 없고, 지금까지 정리한 구성을 적어 봅니다.
화면설계서는 디자이너와 개발자에게 이 화면이 무엇이며 어떻게 동작해야 하는지를 전달하는 문서입니다.
그림만 있으면 동작이 비고, 글만 있으면 화면이 안 그려지기 때문에 둘이 한 장에 같이 있어야 해요.
읽는 사람마다 필요한 것도 조금씩 다릅니다.
디자이너는 어떤 요소가 어디에 필요한지, 개발자는 어떤 조건에서 무엇이 바뀌는지, 검수하는 사람은 어떤 상태가 정상인지를 찾아봅니다.
이 세 시선을 한 문서에 담는 것이 템플릿의 목표라고 생각했습니다.
템플릿을 쓰면 좋은 점은 문서마다 형식이 달라지는 것을 막아 준다는 것입니다.
화면이 서른 개쯤 되는 사이트를 가정해 보면, 화면마다 설명하는 순서가 다를 때 읽는 사람이 매번 어디에 무엇이 있는지 찾아야 해요.
같은 칸에 같은 종류의 정보가 있으면 읽는 속도가 빨라지고, 빠진 칸이 있으면 바로 눈에 띕니다.
그래서 내용을 쓰는 것만큼 형식을 고정하는 일도 중요하다고 느꼈습니다.
제가 만든 템플릿은 화면 하나당 아래 네 부분으로 나눕니다.
- 화면 개요: 화면 이름, 화면 번호, 목적, 진입 경로, 대상 사용자
- 화면 그림과 요소 설명: 화면 와이어프레임, 각 요소에 번호를 달고 번호별 설명
- 예외와 상태: 데이터가 없을 때, 오류가 났을 때, 권한이 없을 때
- 이력: 작성일, 작성자, 변경 내용
각 부분에서 무엇을 적는지 조금 더 풀어 볼게요.
먼저 화면 개요입니다.
화면 이름과 번호는 다른 문서나 대화에서 이 화면을 가리킬 때 쓰는 이름표입니다.
번호 규칙을 일관되게 정해 두지 않으면 나중에 회의에서 "그 화면"이라는 말만 오가게 돼요.
목적은 한두 줄이면 충분합니다.
예를 들어 "회원이 주문 내역을 확인하고 배송 상태를 보는 화면"처럼 쓰는 식입니다.
진입 경로를 적어 두면 이 화면에 어디서 들어오는지가 보여서, 앞뒤 화면과의 연결을 점검하기 좋아요.
화면 그림 위의 각 요소에 번호를 붙이고, 아래 표에 번호별로 설명을 적습니다.
표의 항목은 이름, 형태, 동작, 비고 정도로 정했어요.
가정 예시로 로그인 화면을 적어 보겠습니다.
- 1번 이메일 입력 칸: 직접 입력, 형식이 맞지 않으면 칸 아래에 안내 문구 표시
- 2번 비밀번호 입력 칸: 입력 내용은 가려서 표시
- 3번 로그인 버튼: 두 칸이 모두 채워지면 활성화, 누르면 확인 중 상태로 전환
- 4번 비밀번호 찾기 링크: 비밀번호 찾기 화면으로 이동
이렇게 적으면 개발자가 어떤 조건에서 버튼이 켜지는지 따로 묻지 않아도 됩니다.
요소 번호는 화면 번호와 이어서 부르면 대화가 쉬워집니다.
예를 들어 로그인 화면이 화면 번호 03이라면 "03화면의 3번 버튼"이라고 말하는 식이에요.
회의에서 "그 파란 버튼"이라고 가리키는 것보다 오해가 훨씬 적습니다.
화면 사이의 이동은 요소 설명 안에 "누르면 어느 화면으로 가는지"를 적어 두면, 별도의 연결도를 만들기 전에도 흐름을 따라갈 수 있습니다.
처음에 제가 가장 자주 놓친 부분이 예외였어요.
정상 흐름만 그려 두고 넘어가면, 개발이 시작되었을 때 "목록이 비어 있으면 뭘 보여 주나요"라는 질문이 쏟아집니다.
그래서 템플릿에 예외 칸을 고정으로 넣었습니다.
- 데이터가 하나도 없는 경우
- 서버 응답이 늦거나 실패한 경우
- 입력값이 규칙에 맞지 않는 경우
- 권한이 없는 사용자가 접근한 경우
모든 화면에 네 가지가 다 필요한 것은 아니지만, 칸이 있으면 해당 없음이라도 한 번 생각하게 됩니다.
가정 예시로 주문 내역 화면의 예외 칸을 채워 보겠습니다.
주문이 한 건도 없으면 빈 목록 대신 "아직 주문 내역이 없습니다"라는 문구와 상품 보러 가기 버튼을 보여 줍니다.
서버 응답이 늦으면 목록 자리에 기다림 표시를 먼저 보여 주고, 실패하면 "다시 불러오기" 버튼을 둡니다.
로그인하지 않은 사용자가 들어오면 로그인 화면으로 보내고, 로그인을 마치면 이 화면으로 되돌아오게 합니다.
이 정도만 적어도 개발 중에 오가는 질문이 눈에 띄게 줄어듭니다.
문서는 한 번 쓰고 끝나지 않고 계속 바뀝니다.
언제 무엇이 바뀌었는지 적어 두지 않으면, 개발 중에 어떤 버전이 최신인지 헷갈려요.
이력에는 날짜, 작성자, 바뀐 내용을 한 줄씩 적습니다.
바뀐 부분을 문서 안에서 눈에 띄게 표시해 두면 읽는 사람이 변경 지점만 빠르게 확인할 수 있습니다.
예를 들어 이력 칸에는 "8월 20일, 로그인 버튼 활성 조건 변경, 비밀번호 칸이 비어 있으면 비활성"처럼 한 줄로 적습니다.
날짜와 이유가 함께 있으면 나중에 왜 바뀌었는지 되짚을 수 있어요.
처음에는 귀찮아 보이지만, 이전 버전을 보고 일하는 사람이 생기는 것을 막아 주는 가장 값싼 방법이었습니다.
템플릿은 모든 걸 적게 만드는 도구가 아니라, 빠뜨리기 쉬운 것을 떠올리게 하는 체크리스트라고 생각합니다.
빈 문서 앞에서 막막할 때 칸이 있으면 훨씬 수월하더라고요.
다만 칸을 다 채우는 일이 목적이 되면 문서가 무거워집니다.
화면이 단순할 때는 어디까지 줄여도 되는지, 팀마다 선호가 다른 형식은 어떻게 맞춰 가야 하는지는 앞으로 선배들에게 더 물어보며 다듬어 보려고 합니다.
'Planning · PM > 서비스 기획' 카테고리의 다른 글
| 애플리케이션 화면설계서 템플릿 v0.5 (0) | 2014.09.07 |
|---|---|
| 모바일 사이트 화면설계서 템플릿 v0.3 (0) | 2014.09.05 |
| 개인 맞춤형 맛집 추천 앱 아이디어 노트 (0) | 2014.07.03 |
| 개인 맞춤형 맛집 추천 애플리케이션 포크 (0) | 2014.07.01 |
| The 9 Best To-Do List Apps (0) | 2014.06.26 |