디자인-개발 피드백 루프를 줄이는 법
Article
에이전시에서 일하면서 가장 많이 들은 말이 있다. "이거 시안이랑 달라요." 디자이너는 픽셀이 어긋났다고 하고, 개발자는 시안이 케이스를 다 못 담았다고 한다. 둘 다 맞는 말이라서 더 답이 없다. 이 왕복을 줄이는 방법을 몇 년째 실험해 왔고, 지금은 세 가지로 정리한다.
토큰을 먼저 합의한다
색상, 여백, 폰트 크기 같은 값을 작업 시작 전에 토큰으로 합의한다. "이 회색은 muted, 여백은 4의 배수" 정도만 정해도 왕복이 눈에 띄게 준다. 시안의 23px 여백을 보고 개발자가 24px로 구현했을 때, 토큰이 있으면 그건 "다름"이 아니라 "정렬"이다. 토큰이 없으면 싸움이 된다.
중간 산출물을 일찍 보여준다
완성하고 나서 보여주면 피드백 비용이 가장 비싸다. 나는 레이아웃 뼈대만 잡힌 상태, 인터랙션이 절반쯤 붙은 상태를 일부러 어설픈 채로 공유한다. 디자이너는 "이 방향 아닌데요"를 이틀 뒤가 아니라 두 시간 뒤에 말할 수 있다. 어설픈 걸 보여주는 게 부끄러운 게 아니라, 다 만들고 갈아엎는 게 부끄러운 거다.
의도를 묻는 문화
시안에서 이상한 점을 발견했을 때 조용히 임의로 고치는 개발자가 제일 위험하다. "여기 hover 상태가 없는데, 의도인가요 누락인가요?" 이 한 문장이 왕복 세 번을 줄인다. 반대로 디자이너도 "이거 구현 비싼가요?"를 물을 수 있어야 한다. 질문이 오가는 팀은 수정이 줄고, 질문이 없는 팀은 수정만 는다.
통역자의 자리
디자인을 전공하고 퍼블리싱을 거쳐 프론트엔드까지 온 덕에, 나는 회의에서 자주 통역을 맡는다. 디자이너의 "여기 좀 답답해요"를 "gap을 한 단계 키우자"로, 개발자의 "그건 리플로우가 커요"를 "스크롤이 버벅일 수 있어요"로 옮긴다. 대단한 기술이 아니다. 양쪽 언어를 조금씩 아는 것뿐이다. 그런데 이 통역이 있는 프로젝트와 없는 프로젝트는 피드백 루프의 길이가 다르다.
루프를 줄이는 건 도구가 아니라 습관이다. 토큰으로 말하고, 일찍 보여주고, 고치기 전에 묻는다. 그리고 가능하면 팀에 통역자를 한 명 둔다. 없다면, 내가 되면 된다.