목업

화면을 만들기 전에 그려 보는 도면이 와이어프레임입니다. 색과 이미지를 일부러 빼고 무엇이 어디에 놓이는지만 회색 상자로 그린 것이라, 배치를 정하는 대화에는 잘 맞습니다. 그런데 배치가 정해지고 나면 이 도면으로는 더 답할 수 없는 질문이 남습니다. 실제로 어떻게 보이느냐입니다.

회색 상자 도면을 보고 모두가 고개를 끄덕인 다음, 개발이 끝난 화면 앞에서 대화가 다시 시작되는 일이 잦았습니다. 규원이 "이건 생각한 거랑 다른데요" 라고 말하고, 민서는 "도면대로 만든 건데요" 라고 답합니다. 둘 다 맞는 말입니다. 배치는 도면과 같고, 인상은 도면에 없던 것에서 나옵니다.

같은 배치라도 저장 버튼만 진한 색으로 두면 사람들이 그것부터 읽고, 버튼 넷을 같은 색으로 두면 넷을 다 읽어야 합니다. 글자 크기를 14에서 16으로 올리면 한 화면에 들어가던 목록이 여덟 줄에서 여섯 줄로 줄어듭니다. 이런 것들은 도면 위에서는 아무 차이도 만들지 않다가 실제 화면에서 처음 드러납니다.

목업은 그 차이를 만들기 전에 보자고 만든 단계입니다. 구조가 정해진 뒤에 색과 서체와 이미지를 올려서, 개발에 들어가기 전에 완성된 화면을 한 번 보고 합의합니다.

한 장의 목업에는 최종 화면에서 눈에 보이는 것이 모두 들어갑니다. 여섯 가지로 나뉩니다.

1. 확정된 배치 — 앞 단계에서 정해진 구조를 그대로 받습니다. 목업 단계에서 배치를 다시 뒤집으면 그 위에 올린 색과 글자를 전부 다시 얹어야 해서, 배치는 여기 오기 전에 끝내 둡니다.
2. 색 — 배경, 글자, 강조, 경고에 각각 쓸 값을 정합니다. 목적은 예쁘게 만드는 것이 아니라 위계를 만드는 것입니다. 한 화면에서 가장 진한 색은 사용자가 가장 먼저 하길 바라는 동작 하나에만 씁니다.
3. 서체 — 글꼴과 크기, 굵기, 줄 간격을 정합니다. 제목 20, 본문 14, 보조 설명 12 처럼 단계를 몇 개로 둘지가 여기서 정해지고, 단계가 너무 많으면 어느 것이 더 중요한지 읽히지 않습니다.
4. 이미지와 아이콘 — 자리만 잡아 두던 회색 사각형에 실제 사진과 아이콘이 들어갑니다.
5. 진짜 내용 — "제목입니다" 같은 임시 문구 대신 실제로 들어갈 문장과 데이터를 넣습니다. 이름이 두 글자인 사람과 열두 글자인 사람, 문서 제목이 40자인 경우를 함께 넣어 봐야 그때 화면이 어떻게 되는지 보입니다.
6. 상태별 화면 — 한 화면은 한 가지 모습이 아닙니다. 목록이 비었을 때, 불러오는 중일 때, 요청이 실패했을 때를 따로 그립니다. 이 셋이 빠지면 결국 개발자가 그 화면을 혼자 정하게 되고, 대개 아무 안내 없는 빈 화면이 됩니다.

만드는 사람은 프로덕트 디자이너 한 명이고, 보는 사람은 넷입니다. 같은 한 장을 놓고 각자 다른 것을 봅니다.

1. 프로덕트 매니저 — 기획한 기능이 화면에 다 들어갔는지, 빠진 경우가 없는지 봅니다. 목업에 없는 상태는 개발에도 없습니다.
2. 개발자 — 무엇을 만들어야 하는지 읽습니다. 다만 보이는 것만으로는 부족해서, 간격과 크기를 숫자로 적어 둔 레드라인과 예외 상황을 함께 전하는 핸드오프가 뒤에 붙습니다. 피그마 같은 도구는 시안에서 값을 자동으로 읽어 주지만, 무엇이 확정이고 무엇이 아직 아닌지는 사람이 말해야 합니다.
3. 대표와 팀 — 인상을 확인합니다. 말로 주고받으면 어긋나는 종류의 결정이라 화면을 놓고 정합니다.
4. 세일즈와 마케팅 — 아직 없는 기능을 고객에게 보여 줄 자료로 씁니다. 다만 이 자리에서는 목업이 실제와 다를 수 있다는 것을 함께 말해야 합니다.

만든 뒤에 구현된 화면과 나란히 놓고 어긋난 곳을 찾는 검수가 디자인 QA입니다. 목업은 그때까지 기준으로 남습니다.

"목업까지 나왔으니 색은 확정으로 봐도 될까요?"

이 단계를 지났으면 시각 요소는 더 안 바뀐다고 봐도 되는지 확인하는 질문입니다.

"이 목업은 제일 이상적인 데이터만 들어 있어요. 제목이 40자 넘는 경우도 한 장 주세요."

짧은 예시로만 만든 화면은 실제 데이터에서 깨진다는 지적입니다.

"목업 말고 눌러 볼 수 있는 걸로 주실 수 있어요? 흐름을 보고 싶어요."

한 장의 모습이 아니라 화면 사이의 이동을 확인하고 싶다는 요청입니다.

페이지덱이 문서 공유 화면을 만들 때 민서가 목업을 다섯 장 냈습니다. 기본 화면 한 장, 공유한 사람이 아무도 없을 때 한 장, 링크를 만드는 중 한 장, 권한이 없어 실패했을 때 한 장, 공유 대상이 서른 명을 넘을 때 한 장이었습니다. 처음 요청은 기본 화면 한 장이었지만 태오가 나머지 넷을 물었고, 그 자리에서 그리는 편이 개발 중에 되묻는 것보다 빨랐습니다.

지현은 이 다섯 장을 보고 기획에서 빠뜨린 것을 하나 찾았습니다. 공유 대상이 서른 명을 넘는 화면을 보다가, 이미 공유한 사람을 지우는 방법이 어디에도 없다는 것을 알아챘습니다. 화면으로 만들어 놓으면 문서로만 볼 때 안 보이던 구멍이 드러납니다.

목업이 나오면 디자인이 끝났다고 여기는 경우가 많습니다. 보이는 것이 완성돼 있으니 자연스러운 오해입니다. 그런데 목업 다음에는 넘기는 단계가 남아 있습니다. 값을 숫자로 적고, 예외 상황을 함께 전하고, 구현된 화면이 시안과 맞는지 확인하는 일입니다. 이 단계를 건너뛰면 여백이 24여야 할 자리가 20으로 나가고, 그런 화면이 스무 장 쌓이면 제품 전체가 시안과 조금씩 다른 상태가 됩니다.

목업이 좋아 보이면 쓰기도 좋을 것이라고 읽는 것도 잦습니다. 잘 만든 목업은 이상적인 조건을 담고 있어서 더 그렇게 보입니다. 데이터는 알맞은 길이이고, 목록에는 적당한 수가 들어 있고, 아무것도 실패하지 않습니다. 실제 사용자는 그 조건 밖에서 씁니다. 쓸 만한지는 한 장의 그림이 아니라 눌러서 넘어가 보는 것으로 확인하고, 그래서 목업 다음에 프로토타입을 따로 만듭니다.