스타트업에서 디자이너는 다른 직군에 프런트엔드 개발자와 많은 시간을 보낸다. 그런데 디자이너가 생각하고 말하는 언어는 개발자의 언어와 다르다. 목업을 만들 때 디자이너는 시선을 끌면서도 매끄러운 이야기를 만들기 위해 노력하지만, 개발자는 실제 그 이야기를 구현함에서 굉장히 넓은 구조를 따지게 된다. 같은 이야기라도 보는 시선 자체가 다르다. 그래서 개발자를 향한 디자이너의 의사 전달이 굉장히 중요하다.
먼저 개발자가 아무것도 모르는 바보라고 생각해야 한다. (물론 실제로 개발자들은 굉장히 똑똑하다) 바보에게는 하나부터 열까지 일일이 알려줘야 하고, 또한 계속 반복해서 알려줘야 한다. 그래서 개발자에게 UI 개발을 요청할 때에 사소한 부분까지 자세히 설명해야 한다. 그리고 일어날 수 있는 모든 변수에 대해서도 최대한 예측하고 준비해야 한다. UI 개발 단계에서 생각지 못했던 변수들이 계속 돌출하기 때문이다. 그리고 변수가 발생할 때마다 개발자의 작업 흐름이 끊기게 마련이고, 결과적으로는 일정이 늘어진다. 그래서 디자이너가 준비한 것만큼은 개발자가 다른 생각 없이 온전히 개발할 수 있도록 사전에 철저히 준비해야 한다.
두 번째는 개발자에게 전달하는 UI 요소들을 tag로 만드는 것이다. 빨간색을 #ff0000으로 말하는 게 아니라, red란 tag로 정의하고 개발자에게 tag list를 전달하면 된다. 색상 뿐만 아니다. 레이아웃 폰트, 버튼, 여백까지 tag의 형태로 개발자와 약속할 수 있다. 실제로 개발자 역시 색상과 같은 여러 가지 값들을 tag로 정리하여 개발하기 때문에, 디자이너의 이런 전달 방식이 더 효과적이다
한편 각 페이지나 UI 요소들의 이름을 개발자와 통일하면 개발자와 혼선을 줄일 수 있다. 그리고 통일한 이름을 애셋의 파일 이름에 그대로 적용할 수 있다. 이런 여러 가지 디자이너와 개발자의 약속이 서로를 편하게 하고, 쓸데없는 낭비를 줄인다. 물론 이런 모든 요소는 기본적으로 문서의 형태를 갖추어야 한다. ‘고쳐주세요’라고 백번 말하는 것 보다 고칠 게 무엇인지 문서로 전달하거나, 협업 도구에서 개발자에게 할당하는 게 기본이다.
UI 개발은 디자이너의 일이라고 생각한다. 그래서 디자이너도 어느 정도의 코딩은 할 수 있어야 한다고 생각한다. (물론 굉장히 어렵다…) 웹사이트를 만들 때 디자이너가 html, css, js 등을 모두 책임질 수 있다면, 개발자는 온전히 기능 구현에만 집중할 수 있다. 모바일도 마찬가지다. xib 또는 xml을 편집하는 것에서 시작해, 결과적으로 더 정교한 디자인을 만들면서, 디자인에 대한 개발자의 짐을 덜어줄 수 있다.
물론 개발자와 디테일한 업무를 떠나 인간적으로 친해지는 것도 중요하다. 또한, 평상시에 어떤 디자인을 무엇 때문에 원하는지 큰 그림을 계속 설명하고 공유하는 것도 개발자가 디자이너와 같은 시선을 갖게 한다.