구현이 올라오면 디자이너는 시안과 화면을 나란히 놓고 다른 점을 찾습니다. 그리고 목록을 보냅니다 — “여백 2px 크네요”, “글자가 1px 작습니다”, “이 회색이 조금 진해요”. 이 리뷰는 성실하지만 끝나지 않습니다. 다음 화면에서 같은 종류의 차이가 다시 나오기 때문입니다.
같은 지적을 두 가지 말로 적어 보기
차이 하나를 두 방식으로 적어 보면 무엇이 다른지 분명해집니다.
픽셀 지적은 디자이너를 검수 도구로 만듭니다. 사람이 자를 대고 재는 일을 계속하게 되고, 그 일은 화면이 늘어날수록 감당할 수 없어집니다. 규칙 지적은 반대로 규칙을 검수 도구로 만듭니다 — 사람이 아니라 목록이 검사합니다.
리뷰 항목의 우선순위
모든 차이가 같은 무게는 아닙니다. 아래 순서로 보면 중요한 것이 먼저 잡힙니다.
맨 아래 항목이 사라지는 것은 아닙니다. 다만 순서가 뒤로 갑니다. 빈 화면이 구현되지 않은 상태에서 자간 논의를 하면, 배포 후에 방문자가 보는 것은 자간이 아니라 빈 화면입니다.
어떤 화면을 보고 리뷰하는가
시안과 나란히 놓고 보는 방식은 함정이 있습니다. 시안에 있는 화면만 검토하게 되기 때문입니다. 시안에 없던 화면을 먼저 보는 습관이 훨씬 많은 것을 잡아냅니다 — 항목이 하나뿐인 목록, 제목이 가장 긴 항목, 이미지가 없는 항목, 필터를 걸어 0건이 된 화면.
실제 기기에서 보는 것도 같은 이유입니다. 브라우저 창을 줄여서 보는 모바일과 실제 휴대폰에서 보는 모바일은 글자 크기 · 스크롤 · 터치 영역이 다르게 느껴집니다.
리뷰를 남기는 형식
리뷰는 화면 단위가 아니라 규칙 단위로 묶어 보내면 개발자가 한 번에 처리할 수 있습니다. “카드 컴포넌트 전체에서 아래 여백이 척도 밖” 이 “목록 화면 · 상세 화면 · 관련 글에서 각각 2px” 보다 짧고 정확합니다.
그리고 리뷰의 마지막에는 규칙이 부족했던 부분을 적습니다. 개발자가 자유롭게 만들 수밖에 없었던 자리가 있었다면 그것은 구현의 실수가 아니라 핸드오프의 빈칸입니다. 그 빈칸을 채우는 것이 다음 프로젝트의 시작점입니다.
리뷰와 검증 절차를 실제 작업 순서로 보고 싶다면 작업 과정에 단계별로 공개돼 있고, 관련 글은 개발 워크플로우 아카이브에 모여 있습니다.
다음 회차
마지막 회차입니다. 지금까지 다룬 것들을 배포 직전에 한 번에 확인하는 디자인 QA 체크리스트로 연재를 마무리합니다.