화면 정의서

디자인 시안은 정상 상태 하나만 보여 줍니다. 목록에 문서가 세 개 들어 있고 이름이 알맞은 길이이고 아무것도 잘못되지 않은 화면입니다. 실제 제품에서 그 화면은 훨씬 여러 모습을 가집니다. 목록이 비어 있을 때, 불러오는 중일 때, 이름이 스무 자를 넘을 때, 권한이 없는 사람이 주소를 직접 열었을 때가 모두 다른 화면입니다.

시안만 들고 만들던 시절에는 그 차이가 전부 질문으로 돌아왔습니다. 개발자가 "문서가 0개면 뭘 보여 주죠" 하고 물으면 디자이너가 그 자리에서 답을 만들고, 두 시간 뒤에 "이메일 형식이 틀리면요" 가 또 옵니다. 답은 채팅창에 흩어지고, 두 주 뒤에 같은 질문이 다시 나오면 아무도 그때 무엇으로 정했는지 찾지 못합니다.

화면 정의서는 그 질문들을 만들기 전에 한곳에 모으려고 생기는 문서입니다. 화면을 하나씩 세워 놓고 그 안에 놓이는 것을 빠짐없이 세고, 항목마다 있을 수 있는 상황을 미리 적습니다. 질문의 수가 줄어드는 것이 아니라 질문하는 시점이 앞으로 옮겨집니다.

화면 하나를 기준으로 다섯 묶음을 채웁니다.

1. 화면 식별 — 화면 이름과 주소, 그리고 사용자가 어디서 이 화면으로 들어오는지를 적습니다. 같은 초대 화면이 설정에서도 열리고 문서 안의 공유 버튼에서도 열리면 두 경로를 다 적어야 합니다.
2. 요소 목록 — 화면에 놓이는 것을 전부 셉니다. 버튼과 입력칸만이 아니라 안내 문구, 아무것도 없을 때 대신 보이는 화면, 불러오는 동안 보이는 표시까지 항목으로 세웁니다.
3. 요소별 상태 — 항목마다 비었을 때·입력 중일 때·오류일 때·누를 수 없을 때를 붙입니다. 이 칸이 이 문서의 몸통입니다. 이메일 입력칸 하나가 빈 상태, 형식이 틀린 상태, 이미 초대된 주소인 상태로 세 줄이 됩니다.
4. 동작과 조건 — 누르면 무엇이 일어나는지를 조건과 짝지어 적습니다. "보내기를 누르면 초대가 발송된다" 는 절반이고, 권한을 고르지 않았을 때와 한도를 넘겼을 때가 붙어야 한 칸이 찹니다.
5. 예외와 오류 문구 — 정상 경로가 아닌 경우와 그때 화면에 뜨는 문장을 그대로 적습니다. 문구를 개발 단계에서 즉석으로 지으면 제품 안의 말투가 화면마다 달라집니다.

다 끝났다고 인정하는 기준은 인수 조건으로 따로 적습니다. 체크할 수 있는 문장으로 쓰는 목록이고, 검수하는 사람이 그대로 따라가며 하나씩 확인합니다. 반대로 화면 하나를 넘어 제품 전체에 걸리는 규칙은 제품 정책으로 빼고 여기서는 링크만 겁니다. 초대 권한을 누가 가질 수 있는지는 모든 문서와 모든 플랜에 걸리는 문제라 두 곳에 적으면 한쪽만 고쳐지는 날이 옵니다.

거치는 화면이 여럿이면 플로우 차트로 순서와 갈라지는 지점을 함께 그리고, 한 대상이 여러 상태를 오가면 상태 다이어그램을 곁들입니다.

쓰는 쪽은 대개 그 기능을 맡은 프로덕트 매니저입니다. 화면 안의 상태가 많으면 디자이너가 3번 칸을 함께 채웁니다. 와이어프레임, 곧 요소의 자리만 잡아 놓은 밑그림을 먼저 그려 두고 그 그림을 보며 항목을 세는 순서가 흔합니다.

읽는 쪽은 셋이고 각자 다른 칸을 봅니다.

1. 개발자 — 동작과 조건, 예외와 오류를 보고 얼마나 걸릴지 답합니다. 상태가 세 개인 줄 알았던 화면이 아홉 개면 추정이 세 배로 늘어납니다.
2. 디자이너 — 요소 목록과 상태 칸을 보고 그려야 할 화면이 몇 장인지 셉니다.
3. 품질 보증을 맡은 쪽 — 인수 조건과 예외 칸을 그대로 검수 목록으로 옮깁니다.

그래서 한 칸이 비면 그 칸을 읽는 사람만 멈춥니다. 예외 칸이 없으면 개발은 굴러가는데 검수에서 합격과 불합격을 가릴 기준이 없습니다.

쓰는 일은 한 번으로 끝나지 않습니다. 만드는 동안 바뀐 결정이 문서로 돌아오지 않으면 두 주 만에 낡습니다. 낡은 문서는 없는 것보다 나쁩니다. 없으면 사람들이 물어보지만, 낡은 문서가 있으면 아무도 의심하지 않고 그대로 만듭니다.

"이 화면 정의서에 빈 상태가 없어요. 문서가 0개인 팀은 뭘 보게 되죠?"

요소 목록은 있는데 상태 칸이 비었다는 지적입니다.

"버튼 배치는 시안대로 가고, 오류 문구는 정의서에 적힌 걸 그대로 씁니다."

시안과 이 문서가 각각 무엇을 정하는지 선을 긋는 말입니다.

"정책이 바뀌었으니 화면 정의서부터 고치고 개발 티켓을 올립시다."

문서를 고치지 않고 구현만 바꾸면 검수 기준이 어긋난다는 뜻입니다.

페이지덱에서 지현이 초대 화면 정의서를 쓰고 태오와 민서가 함께 읽는 자리를 가졌습니다. 한 시간 동안 나온 질문이 열한 개였고 그중 아홉 개가 예외 칸에서 나왔습니다. 같은 주소를 두 번 초대하면 어떻게 되는지, 한도를 넘긴 팀에게 무엇을 보여 줄지 같은 것들입니다. 아홉 개를 그 자리에서 정해 문서에 적고 나서야 태오가 일정을 답했습니다.

시안이 있으면 이 문서가 필요 없다고 보는 경우가 많습니다. 화면을 눈으로 볼 수 있으니 적을 것이 없어 보이기 때문입니다. 하지만 시안이 보여 주는 것은 여러 상태 가운데 하나이고, 나머지는 그림이 아니라 글로만 적힐 수 있습니다. 시안만 들고 만들면 빠진 상태는 만드는 사람이 그 자리에서 정하게 되고, 그렇게 정해진 것은 어디에도 남지 않아 검수에서 판정할 수 없습니다.

한 번 쓰면 끝이라고 보는 오해도 흔합니다. 문서를 만들기 전 단계의 산출물로 배우기 때문입니다. 실제로는 만드는 동안 결정이 계속 바뀌고, 바뀐 것이 돌아오지 않으면 문서와 제품이 갈라집니다. 석 달 뒤 새로 온 사람이 그 문서를 읽고 지금 제품에 없는 동작을 사실로 알게 되면, 고치는 비용은 처음 쓸 때의 몇 배가 됩니다.