디자인 산출물

디자인이라는 말은 한 사람의 머릿속에서는 하나지만 남에게 건넬 때는 여러 개로 갈라집니다. 이 사실을 이름으로 구분해 두지 않으면 같은 요청이 매번 다른 물건을 뜻하게 됩니다.

페이지덱 초기에 실제로 이런 일이 있었습니다. 프로덕트 매니저 지현이 "디자인 언제 나와요" 하고 물으면 디자이너 민서는 대답할 수가 없었습니다. 민서는 그 주에 비슷한 제품 화면 마흔 장을 모아 놓고 어느 쪽 인상으로 갈지 고르는 중이었습니다. 지현이 기대한 것은 눌러 볼 수 있는 완성된 화면이었고, 개발자 태오가 기대한 것은 버튼 위 여백이 몇인지 적힌 숫자였습니다. 셋이 같은 단어를 쓰면서 각자 다른 물건을 떠올렸으니 일정 이야기가 될 리 없었습니다.

이 어긋남은 늘 같은 자리에서 값을 치렀습니다. 민서가 인상을 고르는 중인데 지현이 그것을 최종안으로 읽고 대표에게 보고했다가, 2주 뒤에 전혀 다른 화면이 나오자 왜 바뀌었느냐는 질문을 받는 식입니다. 반대 방향도 있었습니다. 태오가 색이 입혀진 화면을 받고 구현을 시작했는데 간격이 적혀 있지 않아 눈대중으로 넣었고, 나중에 검수에서 열두 군데가 어긋난 것이 드러났습니다. 둘 다 물건이 잘못 만들어져서가 아니라 무엇을 건넸는지가 서로에게 분명하지 않아서 생긴 일입니다.

그래서 단계마다 나오는 물건에 이름을 따로 붙였습니다. 이름이 붙으면 세 가지가 함께 정해집니다. 이 물건이 답하는 질문이 무엇인지, 누가 받는지, 받은 사람이 무엇을 해도 되는지입니다. 참고 이미지를 모은 판은 방향을 묻는 물건이라 보고 감상을 말하면 되고, 간격이 적힌 시안은 구현을 위한 물건이라 그대로 코드에 옮기면 됩니다. 앞엣것을 받고 개발을 시작하거나 뒤엣것을 받고 분위기 의견을 내면 그 자리가 어긋납니다.

디자인 축의 지형에서 이 갈래는 무엇을 설계하느냐가 아니라 어떻게 일하느냐 쪽에 놓입니다. 문제에서 해법까지 가는 순서를 정하는 것이 디자인 프로세스라면, 산출물은 그 순서의 각 칸에서 실제로 손에서 나가는 물건입니다. 순서만 있고 물건이 없으면 진행 상황을 확인할 방법이 없고, 물건만 있고 순서가 없으면 지금 받은 것이 어느 단계의 것인지 알 수 없습니다.

이름이 붙은 뒤로 달라진 것은 디자이너의 작업량이 아니라 주변 사람의 기다림입니다. 예전에는 화면이 다 될 때까지 아무도 무엇을 물을 수 없었고, 물어도 돌아오는 답은 하고 있다는 말뿐이었습니다. 지금은 단계 이름 하나로 지금 무엇이 정해졌고 무엇이 아직 열려 있는지가 전해집니다. 그래서 산출물 이름을 아는 것은 디자이너보다 오히려 디자이너와 일하는 사람에게 더 값이 큽니다.

디자인 산출물 아래 용어는 네 갈래입니다. 갈래는 만드는 시점 순서대로 놓여 있고, 나뉘는 기준은 완성도가 아니라 그 물건이 답하는 질문입니다. 뒤로 갈수록 정교해지는 것은 결과일 뿐이고, 각 갈래가 존재하는 이유는 앞 단계에서 답할 수 없는 질문이 따로 있기 때문입니다.

네 질문을 먼저 늘어놓으면 여섯 용어가 어디에 걸리는지 보입니다.

1. 어떤 인상으로 갈 것인가 — 탐색 단계
2. 무엇을 어디에 둘 것인가 — 구조 단계
3. 실제로 어떻게 보일 것인가 — 시각 단계
4. 이것을 어떻게 넘기고 맞는지 확인할 것인가 — 전달 단계

앞의 세 갈래는 각각 용어 하나씩을 가지고, 마지막 갈래에만 셋이 몰려 있습니다. 넘기는 일이 유독 어긋나기 쉬워서 단계가 잘게 쪼개져 있는 것입니다.

탐색 단계에는 무드보드가 있습니다. 방향을 잡으려고 참고 이미지를 한 판에 모아 둔 것입니다. 색감, 사진의 결, 글자의 굵기, 여백을 얼마나 두는지 같은 것들이 모여 인상을 만듭니다. 말로 주고받으면 어긋나는 종류의 결정이라 물건으로 만듭니다. 대표 규원이 "좀 더 신뢰감 있게" 라고 말했을 때 민서가 떠올린 화면과 규원이 떠올린 화면은 대개 다릅니다. 이미지 열두 장을 올려 놓고 어느 쪽이냐고 물으면 그 자리에서 정해집니다. 이 단계에서는 우리 제품 화면을 한 장도 그리지 않습니다. 그릴 것을 정하는 단계이지 그리는 단계가 아닙니다.

구조 단계에는 와이어프레임이 있습니다. 색과 이미지와 서체를 모두 뺀 채 무엇이 어디에 놓이는지만 회색 상자로 그린 도면입니다. 꾸밈을 일부러 빼는 이유는 그것이 대화를 가로채기 때문입니다. 색이 들어간 화면을 보여 주면 사람들은 파란색이 너무 진하다는 말부터 꺼내고, 정작 문서 목록을 왼쪽에 둘지 위에 둘지는 아무도 건드리지 않습니다. 회색 상자만 있으면 할 말이 배치밖에 남지 않습니다. 페이지덱의 문서 공유 화면은 이 단계에서 세 번 뒤집혔습니다. 공유 버튼을 문서 안에 둘지 목록에 둘지가 여기서 정해졌고, 만약 색까지 입힌 뒤에 뒤집혔다면 같은 결정에 사흘이 더 들었을 것입니다.

시각 단계에는 목업이 있습니다. 확정된 구조 위에 실제 색과 서체와 이미지를 올려 최종 화면처럼 보이게 만든 시안입니다. 이 단계에서야 비로소 위계가 눈에 보입니다. 같은 배치라도 저장 버튼만 진한 색으로 두면 사람들이 그것부터 읽고, 넷을 같은 색으로 두면 넷을 다 읽어야 합니다. 화면을 실제로 써 보게 하려고 여러 장을 눌러 넘어가게 이어 붙이면 프로토타입이 되는데, 이쪽은 산출물 갈래가 아니라 제품 축에 이름이 걸려 있습니다. 목업이 한 장의 상태를 보여 준다면 프로토타입은 장과 장 사이의 이동을 보여 줍니다.

전달 단계에는 셋이 있고 서로 역할이 다릅니다. 순서대로 값을 적고, 넘기고, 맞는지 봅니다.

1. 레드라인 — 시안 위에 간격과 크기와 색 값을 숫자로 적어 둔 것입니다. 버튼 위 여백 24, 모서리 둥글기 8, 글자 크기 14 같은 값이 화면에 표시됩니다. 예전에는 디자이너가 이 표시를 손으로 그려 넣었고, 지금은 피그마 같은 도구가 시안에서 값을 자동으로 읽어 줍니다. 손으로 그리던 일이 사라졌을 뿐 값을 맞춰야 한다는 사실은 그대로입니다.
2. 핸드오프 — 디자인을 개발에 넘기는 과정 전체입니다. 파일을 보내는 행위가 아니라 무엇이 확정이고 무엇이 아직 아닌지, 예외 상황에서 화면이 어떻게 되는지를 함께 전하는 자리입니다. 목록이 비었을 때, 글자가 아주 길 때, 요청이 실패했을 때의 화면이 여기서 빠지면 그 결정을 결국 개발자가 혼자 내리게 됩니다.
3. 디자인 QA — 구현된 화면이 시안과 맞는지 확인하는 검수입니다. 넘긴 것과 나온 것을 나란히 놓고 어긋난 곳을 찾습니다. 앞의 둘을 아무리 잘해도 이 단계가 없으면 4씩 어긋난 여백이 그대로 배포됩니다. 한 화면에서 4가 어긋나는 것은 눈에 띄지 않지만, 그런 화면이 스무 장 쌓이면 제품 전체가 시안과 조금씩 다른 상태가 되고 그때는 어디서부터 어긋났는지 되짚기가 어렵습니다.

네 갈래는 한 줄로 이어지지만 매번 넷을 다 만들지는 않습니다. 이미 답이 나와 있는 질문은 건너뜁니다. 인상이 디자인 시스템으로 정리돼 있는 제품이라면 무드보드를 다시 만들 이유가 없고, 기존 화면에 버튼 하나를 더하는 일이라면 구조 단계도 필요 없습니다. 반대로 새 제품의 첫 화면은 넷을 다 거칩니다. 어느 단계를 건너뛸지는 지금 팀에 없는 답이 무엇인지로 정합니다.

건너뛴 단계가 나중에 값을 청구하는 경우도 있습니다. 구조 단계를 생략하고 바로 색까지 입힌 화면을 만들었는데 배치가 뒤집히면, 다시 그려야 하는 것은 배치만이 아니라 그 위에 올린 색과 글자와 이미지 전부입니다. 그래서 단계를 건너뛸 때는 아낀 시간과 뒤집힐 확률을 함께 봅니다. 확실히 정해진 것 위에서는 생략이 이득이고, 아직 흔들리는 것 위에서는 생략이 빚이 됩니다.

"지금 드리는 건 무드보드라서 화면 확정으로 보시면 안 돼요. 방향만 봐 주세요."

받는 사람이 이 물건을 최종안으로 읽지 않게 미리 선을 긋는 말입니다. 이 한마디가 없으면 2주 뒤에 화면이 바뀌었을 때 말을 바꿨다는 소리를 듣습니다.

"와이어프레임 단계에서 색 이야기는 잠깐 접어 두고, 이 목록을 왼쪽에 둘지부터 정할까요."

지금 이 산출물이 답해야 할 질문은 배치이지 색이 아니라는 뜻입니다. 단계를 지키자는 말이지 의견을 막는 말이 아닙니다.

"핸드오프 전에 빈 상태랑 에러 상태 화면 두 장만 더 주세요."

정상 화면만으로는 구현을 시작할 수 없다는 요청입니다. 그 두 장이 없으면 개발자가 임의로 정하게 되고, 검수에서 다시 고치게 됩니다.

페이지덱에서 이 말들이 오가는 자리는 대개 화면 단위의 진행 점검입니다. 지현이 이번 주기에 나갈 화면 목록을 띄우면 민서가 각 화면이 어느 단계까지 와 있는지 표시합니다. 표시는 완성도가 아니라 단계 이름으로 합니다. 70퍼센트라고 적으면 아무도 무엇을 해야 할지 모르지만, 구조 단계까지 왔다고 적으면 태오는 아직 시작하면 안 된다는 것을 알고 지현은 이번 주에 색 결정을 받아야 한다는 것을 압니다.

태오는 이 목록에서 전달 단계에 들어온 화면만 가져갑니다. 시각 단계 화면을 미리 보고 구조를 짐작해 만들기 시작하는 일은 하지 않습니다. 앞서 나갔다가 시안이 한 번 바뀌면 그동안 쓴 시간이 통째로 사라지기 때문입니다. 대신 전달 단계로 넘어온 화면이 적은 주에는 그 이유를 묻습니다. 결정이 안 난 것인지 그릴 사람이 없는 것인지에 따라 다음에 움직일 사람이 달라집니다.

산출물을 단계마다 반드시 채워야 하는 체크리스트로 읽는 경우가 가장 많습니다. 네 단계가 순서대로 늘어서 있으니 하나라도 빠지면 절차를 어기는 것처럼 보입니다. 하지만 각 산출물은 답이 없는 질문에 답하려고 만드는 것이라, 답이 이미 있으면 만들 이유도 사라집니다. 설정 화면에 항목 하나를 더하는 일에 무드보드부터 시작하면 아무도 보지 않을 판 하나를 만드느라 이틀이 날아갑니다. 이 오해가 굳으면 팀은 산출물을 만드는 일 자체를 일의 진도로 여기게 되고, 실제로 결정된 것은 없는데 파일만 늘어난 상태가 됩니다.

반대 방향의 오해도 흔합니다. 화면이 예쁘게 다 그려진 목업을 곧 완성된 디자인으로 읽는 것입니다. 보기에 더할 것이 없어 보이니 자연스러운 착각입니다. 그러나 목업이 보여 주는 것은 모든 것이 잘 풀렸을 때의 한 장면뿐입니다. 이름이 스무 자인 사용자, 문서가 한 건도 없는 새 계정, 저장이 실패한 순간은 그 한 장에 들어 있지 않습니다. 이대로 넘기면 개발자가 그 자리를 혼자 메우고, 메운 결과가 검수에서 다시 뒤집힙니다. 페이지덱에서 목록 화면 하나를 두 번 만든 적이 있는데, 빠진 것은 디자인 감각이 아니라 문서가 없을 때 무엇을 보여 줄지에 대한 결정 한 줄이었습니다. 한 장의 화면이 실제로는 대여섯 개의 상태를 대표한다고 보면 이 착각은 줄어듭니다. 잘 그려진 한 장은 그중 하나가 끝났다는 뜻이지 여섯이 다 끝났다는 뜻이 아닙니다.