디자인 QA

넘기는 것까지는 잘 됐는데 나온 것을 아무도 확인하지 않던 시절이 있었습니다. 디자이너는 시안을 넘긴 시점에 그 화면에서 손을 떼고 다음 화면으로 갔고, 개발자는 받은 대로 만들었다고 생각했고, 배포는 그대로 나갔습니다.

문제는 어긋남이 작다는 데 있습니다. 여백 24로 적힌 자리가 20으로 나오고, 글자 크기 14가 13으로 나오고, 회색 하나가 한 단계 옅게 나옵니다. 화면 한 장에서는 아무도 눈치채지 못합니다. 그런데 그런 화면이 스무 장 쌓이면 제품 전체가 시안과 조금씩 다른 상태가 되고, 그때 가서 어디서부터 어긋났는지 되짚기는 어렵습니다.

페이지덱에서도 같은 일이 있었습니다. 민서가 배포된 문서 공유 화면을 열어 보고 "이거 제가 준 거랑 다른데요" 라고 말했는데, 태오는 시안대로 만들었다고 답했습니다. 둘 다 거짓말이 아니었습니다. 민서가 본 것은 여백과 글자 크기였고 태오가 맞춘 것은 배치와 기능이었습니다. 무엇을 맞춘 것으로 볼지가 합의된 적이 없었습니다.

디자인 산출물의 전달 단계는 셋으로 나뉩니다. 값을 적고, 넘기고, 맞는지 봅니다. 디자인 QA는 그 마지막 칸이고, 앞의 둘을 아무리 잘해도 이 칸이 비어 있으면 4씩 어긋난 여백이 그대로 배포됩니다.

시안과 실제 화면을 나란히 띄워 놓고 위에서 아래로 훑는 것이 전부입니다. 다만 훑는 순서와 적는 방식이 정해져 있어야 두 번째 회차가 빨라집니다.

1. 대상과 환경을 정합니다. 어느 화면 묶음을 보는지, 어떤 브라우저와 화면 폭에서 보는지, 다크 모드도 보는지를 먼저 적습니다. 환경을 안 정하면 민서는 노트북에서 보고 태오는 외부 모니터에서 보면서 서로 다른 것을 이야기하게 됩니다.
2. 정해진 순서로 훑습니다. 배치가 맞는지, 간격과 크기가 맞는지, 색과 서체가 맞는지, 그다음에 상태를 봅니다. 상태란 목록이 비었을 때, 제목이 아주 길 때, 불러오는 중일 때, 요청이 실패했을 때의 화면입니다. 여기서 가장 많이 걸립니다. 정상 화면은 시안이 있지만 이 넷은 시안이 없을 때가 많기 때문입니다.
3. 어긋난 곳을 목록으로 적습니다. "버튼이 좀 이상해요" 가 아니라 "문서 목록 화면, 저장 버튼 위 여백 24여야 하는데 20입니다" 처럼 위치와 두 값을 함께 적고 스크린샷을 붙입니다. 피그마 같은 도구가 시안 값을 읽어 주므로 값을 외울 필요는 없습니다.
4. 심각도를 나눕니다. 배포 전에 고쳐야 하는 것, 이번 주 안에 고칠 것, 나중에 볼 것 셋이면 충분합니다. 전부 같은 무게로 던지면 개발 쪽은 결국 쉬운 것부터 합니다. 긴 제목이 잘려 읽을 수 없는 것은 앞칸이고, 1픽셀 차이는 뒷칸입니다.
5. 고친 뒤 다시 봅니다. 항목을 닫는 사람은 고친 사람이 아니라 올린 사람입니다. 이 규칙이 없으면 고쳤다고 표시된 항목이 실제로는 절반만 고쳐진 채 닫힙니다.

남은 항목은 개발 쪽이 쓰는 이슈 도구에 그대로 남깁니다. 같은 항목이 회차마다 되풀이되면 그건 개인의 실수가 아니라 디자인 시스템에 그 값이 없다는 뜻이라, 고칠 곳은 화면이 아니라 시스템입니다.

기본은 둘입니다. 화면을 그린 디자이너와 그 화면을 만든 개발자가 같은 자리에 앉습니다. 판정은 디자이너가 하고, 고칠 수 있는지와 값이 왜 그렇게 나왔는지는 개발자가 답합니다. 셋째 줄에 접근성 확인이 붙는 팀도 있습니다. 글자 색과 배경 색의 차이가 충분한지, 마우스 없이 키보드만으로 버튼에 닿는지를 이 자리에서 함께 봅니다.

의견이 갈리면 지현이 들어옵니다. 디자이너는 고치자고 하고 개발자는 이번 배포에 넣기 어렵다고 할 때, 그 항목이 사용자에게 얼마나 보이는지를 기준으로 어느 칸에 넣을지 정합니다. 이 판단을 둘이서만 하면 대개 목소리 큰 쪽으로 기웁니다.

시점은 기능이 다 붙어 개발 환경에 올라간 뒤, 배포 이틀쯤 전입니다. 더 일찍 보면 아직 만들지 않은 부분을 어긋났다고 적게 되고, 더 늦게 보면 고칠 시간이 없어 목록만 남습니다. 화면이 많으면 한 번에 몰지 않고 묶음이 하나 완성될 때마다 끊어서 봅니다. 스무 장을 한 번에 보면 항목이 80개씩 나오고, 그 목록은 대개 열리지 않습니다.

"이번 주 배포 전에 디자인 QA 한 번 잡죠. 목록 화면이랑 공유 모달 두 개만요."

대상을 좁혀 검수 자리를 만들자는 제안입니다.

"디자인 QA 목록 올려 뒀어요. 위 세 개만 이번 배포에 부탁드리고 나머지는 다음 주에 봐도 됩니다."

심각도를 이미 나눠 놓았으니 전부 오늘 고칠 필요는 없다는 뜻입니다.

"이건 디자인 QA 항목이 아니라 새 요청이에요."

시안과 다른 게 아니라 시안 자체를 바꾸자는 말이니 이 자리에서 처리할 일이 아니라는 지적입니다.

페이지덱은 배포 전날 오후에 민서와 태오가 30분씩 잡습니다. 한 사람은 시안을, 다른 사람은 개발 환경 화면을 띄워 놓고 같은 순서로 내려갑니다. 지난 분기에 이 30분에서 나온 항목이 평균 열두 개였고 그중 배포 전에 고친 것이 넷이었습니다.

숫자보다 눈에 띄는 변화는 되풀이되는 항목이 줄었다는 쪽입니다. 처음 두 달은 여백 값이 매번 걸렸는데, 그 값들을 디자인 시스템에 넣고 나서는 같은 항목이 거의 나오지 않습니다. 검수가 하는 일은 이번 배포를 고치는 것만이 아니라 같은 어긋남이 다음에 안 생기게 만드는 것입니다.

디자인 QA를 디자이너의 트집으로 읽는 경우가 가장 많습니다. 1픽셀을 두고 시비를 거는 자리처럼 보이기 때문입니다. 그렇게 보이는 데는 이유가 있습니다. 목록에 값 차이만 적혀 있으면 정말 그렇게 읽힙니다. 하지만 실제로 이 자리에서 가장 많이 걸리는 것은 값이 아니라 빈 목록과 긴 제목과 오류 화면처럼 시안에 없던 상태들이고, 그건 누구의 취향 문제가 아니라 아직 아무도 설계하지 않은 화면입니다. 트집으로 여겨 이 자리를 없애면 사용자가 그 화면을 대신 발견합니다.

또 하나는 이 자리에서 더 나은 안이 떠오르면 그것까지 고친다는 생각입니다. 화면을 오래 들여다보는 자리라 자연스럽게 생기는 일인데, 시안과 다른 것을 찾는 일과 시안을 바꾸는 일은 다릅니다. 검수 중에 시안을 바꾸면 개발 쪽은 무엇이 확정인지 알 수 없게 되고, 배포 전날에 새 작업이 들어옵니다. 떠오른 안은 따로 적어 두고 다음 회차의 디자인 리뷰로 가져갑니다.