디자인 리뷰

시안이 다 되면 디자이너가 개발에 파일을 보내고 끝나던 시절이 있었습니다. 문제는 그 파일을 받기 전에 그 화면을 본 사람이 디자이너 한 명뿐이라는 데 있습니다.

페이지덱에서 실제로 이런 일이 있었습니다. 태오가 받은 시안대로 사흘을 만든 뒤에 지현이 화면을 보고 "결제 전에 확인 단계를 하나 더 넣기로 한 적이 없는데요" 라고 말했습니다. 민서는 고객 문의가 많아 넣었다고 했고, 지현은 이번 분기에 결제 이탈을 줄이기로 해서 단계를 늘리면 안 된다고 했습니다. 셋 다 각자 맞는 말이었는데, 그 말들이 처음 만난 자리가 개발이 사흘 지난 뒤였습니다.

승인이 흐릿한 것도 같은 문제를 만듭니다. 복도에서 대표가 "좋은데요" 라고 한 것이 승인인지 감상인지 아무도 모르는 채로 일이 진행되고, 출시 직전에 뒤집히면 그때는 누가 무엇을 언제 정했는지 되짚을 기록이 없습니다.

디자인 프로세스 아래의 협업 갈래는 셋입니다. 셋 다 만든 것을 남에게 보이는 자리인데, 무엇을 얻으려고 보이는지에 따라 이름이 갈립니다. 디자인 리뷰는 그중 결론을 얻으려고 여는 자리입니다.

끝에 결론이 남아야 하므로 순서도 결론을 향해 짜입니다. 여섯 칸입니다.

1. 하루 전에 자료를 돌립니다. 시안 링크와 함께 오늘 무엇을 정해야 하는지를 한 줄로 적습니다. "공유 권한을 문서 단위로 둘지 폴더 단위로 둘지 정합니다" 처럼 구체적이어야 합니다. 이 줄이 없으면 사람들은 준비 없이 들어와 그 자리에서 처음 화면을 봅니다.
2. 배경을 3분 안에 말합니다. 어떤 문제를 풀고 있는지, 무엇이 이미 정해져 바꿀 수 없는지입니다. 제약을 먼저 말하지 않으면 이미 닫힌 선택지를 두고 10분이 갑니다.
3. 화면을 흐름대로 보여 줍니다. 한 장씩 늘어놓는 대신 사용자가 지나가는 순서로 넘깁니다. 실제로 눌러 볼 수 있게 이어 붙인 프로토타입이 있으면 그것을 씁니다. 장과 장 사이에서 막히는 지점은 정지된 그림으로는 잘 보이지 않습니다.
4. 질문을 먼저 받고 의견을 나중에 받습니다. 이 순서를 뒤집으면 오해에서 나온 의견이 먼저 쌓이고, 그 오해를 푸는 데 남은 시간을 씁니다.
5. 결론을 그 자리에서 말합니다. 셋 중 하나입니다. 이대로 개발로 넘긴다, 무엇 무엇을 고치면 다시 모이지 않고 넘긴다, 다시 본다. 셋째라면 언제 다시 보는지를 같이 정합니다.
6. 정해진 것과 정해지지 않은 것을 적어 남깁니다. 미결 항목에는 누가 언제까지 답할지를 붙입니다. 이 기록이 나중에 핸드오프에서 무엇이 확정인지를 말해 줍니다.

한 회차는 30분에서 45분, 안건은 두세 개를 넘기지 않습니다. 다섯 개를 올리면 마지막 둘은 시간에 밀려 "일단 진행하시죠" 로 끝나는데, 그건 결론이 아니라 미룸입니다.

부르는 기준은 관심이 아니라 영향입니다. 그 결정으로 자기 일이 바뀌는 사람만 부릅니다.

늘 들어오는 자리는 셋입니다. 시안을 만든 디자이너, 무엇을 왜 만드는지 정한 프로덕트 매니저, 그리고 그 화면을 실제로 만들 개발자입니다. 지현은 이번 분기 목표와 어긋나는지를 보고, 태오는 만드는 데 얼마나 걸리는지와 기술적으로 걸리는 게 있는지를 그 자리에서 답합니다. 이 셋이 모이면 대부분의 뒤집힘이 개발 착수 전에 끝납니다.

사안에 따라 붙는 자리도 있습니다. 가격 화면이나 제품의 인상이 걸린 건에는 규원이 들어오고, 고객사에 이미 약속한 내용이 걸려 있으면 수아가 들어옵니다. 반대로 결정에 걸리지 않는 사람은 부르지 않습니다. 열 명이 앉아 있으면 의견은 열 개가 나오는데 그중 결정에 쓰이는 것은 서넛이고, 나머지는 반영하지 않은 이유를 나중에 따로 설명해야 하는 빚으로 남습니다.

시점은 여러 안을 하나로 좁힌 직후, 개발이 시작되기 전입니다. 안을 아직 펼치고 있는 중이라면 이 자리는 이릅니다. 고르지도 않은 것을 두고 승인 여부를 묻게 되기 때문입니다. 더블 다이아몬드로 보면 두 번째 다이아몬드가 좁혀지는 자리가 리뷰의 시점입니다. 기능이 크면 두 번 엽니다. 흐름을 확정할 때 한 번, 화면을 확정할 때 한 번입니다. 한 번에 둘을 다 정하려 하면 흐름 이야기와 여백 이야기가 섞여 둘 다 안 정해집니다.

"이번 주 디자인 리뷰에 올릴게요. 공유 권한 범위만 정하면 됩니다."

안건을 하나로 좁혀 결론을 받아 가겠다는 말입니다.

"리뷰에서 조건부로 통과했어요. 오류 문구만 고쳐서 바로 넘기기로 했습니다."

다시 모이지 않고 지정된 부분만 고쳐 진행한다는 뜻입니다.

"그건 리뷰에서 정한 게 아니라 그냥 나온 의견이었어요."

기록에 남은 결정과 그 자리에서 오간 말을 구분하는 지적입니다.

페이지덱은 목요일 오후에 45분을 고정으로 잡아 둡니다. 민서가 하루 전에 시안과 정할 것 한 줄을 올리고, 지현과 태오가 그것을 보고 들어옵니다. 올릴 안건이 없는 주에는 그냥 취소합니다.

이 자리가 자리를 잡은 뒤로 달라진 것은 개발 착수 뒤에 화면이 뒤집히는 횟수입니다. 예전에는 분기마다 서너 번 있었는데 지금은 한 번 있을까 말까입니다. 대신 리뷰 자체가 늘어난 것은 아닙니다. 늘어난 것은 시안을 넘기기 전에 지현과 태오가 그것을 보는 횟수입니다.

리뷰를 디자이너가 평가받는 자리로 읽는 경우가 많습니다. 여러 사람 앞에서 자기가 만든 것을 펼쳐 놓고 의견을 듣는 모양이라 그렇게 느껴집니다. 하지만 이 자리에서 판정하는 대상은 사람이 아니라 다음 행동입니다. 평가받는 자리로 여기기 시작하면 디자이너는 방어할 수 있는 안만 들고 오게 되고, 확신이 덜 선 쪽은 아예 올리지 않습니다. 그러면 정작 남의 눈이 필요한 결정들이 리뷰를 건너뛰고 바로 개발로 갑니다.

사람을 많이 부를수록 안전하다는 생각도 흔합니다. 나중에 "나는 못 들었다" 는 말이 나올까 봐 부르는 범위를 넓히게 되는데, 참석자가 늘면 결론이 오히려 늦어집니다. 여섯 명이 넘어가면 그 자리는 정하는 자리가 아니라 공유하는 자리가 되고, 실제 결정은 회의가 끝난 뒤 두세 명이 남아서 내립니다. 알아야 하는 사람과 정해야 하는 사람은 다르고, 앞쪽은 회의가 아니라 기록으로 채웁니다.