디자이너와 개발자, 관계 하나부터 바꾸기

닐슨 노먼 그룹(NN/g)이 디자인과 개발의 협업을 다룬 3분짜리 영상을 공개했다. 발표자는 앞서 개발용 디자인 스펙 작성법을 정리했던 켈리 고든이다. 메시지는 단순하다. 팀 간 협업 구조를 한 번에 뜯어고치려 하기보다, 개발자 한 명과의 소통 방식을 조금씩 바꾸는 데서 시작하라는 것이다.

"더 나은 협업은 하나의 관계에서 시작된다."Nielsen Norman Group

왜 중요한가

디자인과 개발 사이의 마찰은 대개 도구나 프로세스 문제로 진단되지만, 실제로는 '언제, 무엇을, 어떤 형태로' 주고받는지에 대한 합의가 없어서 생기는 경우가 많다. AI 프로토타이핑으로 디자인 속도가 빨라진 지금은 이 간극이 더 크게 벌어진다. 화면은 금방 나오는데, 그 화면이 어떤 상태·예외·접근성 요건을 가져야 하는지는 여전히 사람이 대화로 맞춰야 하기 때문이다.

실무 적용

당장 해볼 수 있는 건 세 가지다. 첫째, 개발자를 핸드오프 단계가 아니라 탐색·프로토타이핑 단계에 초대해 기술적 제약을 먼저 듣는다. 둘째, 리뷰 미팅 전에 스펙에 코멘트를 달 시간을 따로 준다. 셋째, 합의 후 바뀐 내용은 반드시 기록으로 남겨 '말로만 바뀐 디자인'을 없앤다. 큰 스펙은 구현 가능한 작은 단위로 쪼개 전달하는 것도 효과가 크다.

교차 참고

• Nielsen Norman Group: Creating Design Specs for Development — 스펙을 디자인 파일과 개발 이슈 두 축으로 나누고, 개발 이슈를 목표·범위·요구사항을 담은 팀 간 '계약서'로 다루라고 제안한다.
• Nielsen Norman Group: Your Design System Needs an Enforcer — 작은 예외 요청이 쌓여 수십 개의 호환되지 않는 변형이 생긴다며, 변경을 심사하고 시스템의 빈틈을 찾는 '집행자' 역할을 강조한다.

Wemeet의 관점

Wemeet은 협업 문제를 풀 때 규칙 문서를 먼저 만들지 않는다. 프로젝트마다 디자이너 한 명과 개발자 한 명을 짝지어 첫 화면을 같이 만들게 하고, 그 과정에서 나온 합의를 스펙 템플릿과 디자인 시스템 규칙으로 옮긴다. 위에서 내려온 프로세스는 바쁠 때 가장 먼저 무시되지만, 실제로 일해본 두 사람이 만든 규칙은 오래 살아남는다.