팀으로 일하는 디자이너의 커뮤니케이션 팁

디자이너에게 더없이 중요한 커뮤니케이션 능력

업계 아티클을 즐겨 보시는 분이라면 디자이너의 커뮤니케이션에 대한 글을 심심치 않게 보셨을 겁니다. 이는 그만큼 디자이너에게는 디자인 못지않게 커뮤니케이션 능력도 중요하다는 의미일 것입니다. 디자인 자체가 수학처럼 명확한 정답이 없거니와 작업물이 당장 눈앞에 보이기 때문에 디자인 전공자가 아니더라도 이런저런 의견을 쉽게 낼 수 있습니다. 그러므로 디자이너는 결과물에 대한 탄탄한 논리와 근거를 남들에게 잘 말할 수 있어야 합니다.

디자이너는 업무 특성상 주로 기획자, 개발자와 부대끼며 일합니다. 때에 따라 사업부, 협력사와 일하기도 하고요. 통상적으로 디자이너의 목표는 최적의 경험을 디자인하는 것이라면, 기획자는 비즈니스 목표를 달성하는 것, 개발자는 오류 없는 높은 품질의 서비스를 구현하는 것입니다. 같은 배를 탔지만, 각자의 목표와 이해관계가 다르기 때문에 잘못하면 배가 이리저리 휘청거릴 수 있습니다. 이때 함께 일하는 사람들과 서로 윈윈하며 공동의 목표를 달성할 수 있는 디자이너의 커뮤니케이션 팁을 몇 가지 알려드리겠습니다.

기획자와 하는 커뮤니케이션

기획자는 비즈니스 목표, 리소스, 우선순위 등 프로젝트의 큰 틀을 다지는 역할을 합니다. 그래서 디자이너는 기획자가 구상하고 있는 맥락과 의도를 먼저 파악하는 게 좋습니다. 상품을 잘 판매하기 위해, 회원 수를 늘리기 위해, 품질을 높이기 위해 등 프로젝트의 목적이 무엇인지 알게 되면 그 이후 디자인 방향성 정립에도 도움이 됩니다.

작업 도중 추가할 정책이 생겨나거나, 기존 정책을 수정해야 할 때도 있습니다. 문제 정의, 정책 설정 때부터 디자이너와 기획자가 함께 협업하면 이런 상황이 많이 발생하지 않겠지만, 대체로 우리에겐 시간이 없으니까요. 이럴 땐 망설임 없이 정책 수정이나 조율을 요청합니다. 이때, 질책하는 뉘앙스를 풍겨선 안 됩니다. 협업하는 사람들끼리 얼굴 붉히는 일은 최소화해야 하므로 감정은 빼고 팩트만 담백하게 전달한다면 상대방도 수정 사항에만 집중해 원활한 업무가 이루어질 수 있을 것입니다.

그리고 기획 의도에 맞게 설계했는지 작업 중간에 공유가 필요합니다. 기획서를 보며 혼자 작업하다 보면 자신도 모르게 추측을 하게 되어, 기획과는 다른 결과물이 나올 수 있습니다. 그 때문에 중간 공유를 하며 기획자와 디자이너 모두 원하는 디자인이 맞는지 의견을 맞추는 과정이 필요합니다.

개발자와 하는 커뮤니케이션

일하다 보면 시간이 없다는 핑계로, 혹은 프로덕트 스케일이 그다지 크지 않다는 이유로 서비스 초기에 개발자를 제외하고 기획자, 디자이너끼리 논의하는 경우가 있습니다. 하지만 그렇게 되면 개발 도중 예기치 못한 이슈가 생겨 오히려 시간이 더 걸릴 수도 있습니다. 그렇기 때문에 프로젝트 초기에 서비스 기본 구조, 기능, 정책, 히스토리 등을 개발자와 함께 논의해야 시간을 효율적으로 사용할 수 있습니다.

디자인 시스템

회사에서는 크게 두 가지로 소통합니다. 하나는 언어, 다른 하나는 문서입니다. 디자인 시스템은 일관성 있는 디자인을 위해 디자인 팀 내부에서도 쓰지만, 개발자와 의사소통하기 위해서도 쓰는 문서라고 볼 수 있습니다.

디자인 시스템은 업무를 효율적으로 처리할 수 있는 장점이 있습니다. 또 디자인 시스템을 잘 다져놓으면 업무 방식이 애자일이든 워터폴이든 간에 디자인과 개발을 병렬적으로 진행할 수 있어 시간 단축에 효율적입니다. 때론 기획서를 보고 알아서 먼저 작업하는 천사 같은 개발자를 만날 수도 있습니다.

‘design systems repo’는 여러 기업의 디자인 시스템을 모아 놓은 사이트입니다. 제일 유명한 구글 머티리얼 가이드부터 IBM, Uber 등 해외 기업들의 가이드까지 한눈에 볼 수 있습니다.

참고로 저희 팀 역시 디자인 시스템을 쓰고 있는데, 컬러 코드, 아이콘, 타이포그래피 스타일, 쉐도우 값과 같은 파운데이션 단위부터 인풋, 버튼 컴포넌트, 실제 페이지에 어떻게 사용되는지 가이드까지 정리해 개발 팀과 함께 공유하고 있습니다.

사업부와 하는 커뮤니케이션

개발자나 기획자와 협업할 때와 사업부와 협업할 때는 또 다릅니다. 사업부는 지극히 비즈니스 관점으로 업무를 바라보기 때문에, 그들의 니즈를 디자인에 어떻게 잘 녹여 내야 할지 고민해야 합니다.

마케팅 팀과 협업할 때의 일입니다. 마케팅 팀은 클릭 지표를 늘리는 게 목표였기에 상품을 최대한 크게 보여줬으면 했고, 고객을 후킹할 만한 약간은 자극적인 문구를 함께 제안했습니다. 하지만 요구사항을 그대로 반영하게 되면 서비스 품질 및 디자인 일관성을 흩트릴 수 있다는 우려가 있었어요. 그렇다고 해서 고상하게 가이드를 준수한 디자인만 할 수는 없었습니다. 고심 끝에 서비스 룩을 유지하면서도 클릭률을 높일 만한 다른 방법을 제안했고, 마케팅 팀도 의견을 수렴하여 서로 윈윈한 결과를 얻을 수 있었습니다.

간혹 사업부에 모바일 서비스 이해도가 낮은 분들이 있는데, 그땐 상대방의 눈높이에 맞춘 언어로 설명해야 합니다. 협업 경험이 적은 디자이너들이 디자인 리뷰할 때 전문 용어를 써가며 디자인을 그럴듯하게 포장하는 경우를 봤으나, 이는 청자를 배려한 대화법과는 거리가 멀죠. 전문 용어가 아닌 쉬운 언어로 상대방이 이해할 수 있도록 설명하는 게 진정한 커뮤니케이션이 아닐까 합니다.

파트너사와 하는 커뮤니케이션

서비스에 들어갈 일러스트가 필요해 일러스트 작가 또는 에이전시와 협업하는 경우, 인하우스 인원으로는 부족해 파트너사와 함께 일하는 경우 등 생각보다 회사 외부 사람들과 협업하는 상황이 자주 발생합니다. 이때 더욱 상대방을 신뢰하고 존중하는 태도로 임해야 합니다. 물론 한 울타리에 있는 사람이 아닌지라 불안할 수 있고, 때에 따라 보이지 않는 갑을 관계가 형성될 수 있습니다. 하지만 파트너사의 전문성을 최대한 존중하며 바라는 바를 명확하게 전달하고, 파트너사는 궁금한 점이 있으면 망설임 없이 질문하여 최고의 프로덕트를 만들기 위해 서로 노력해야 합니다.

염두에 둬야 할 팁 세 가지 

정보의 불균형을 최소화하자

내가 아는 정보도 상대방이 안다고 착각하면 안 됩니다. ‘내가 아니까 상대방도 알겠지.’라고 추측하며 말하지 않고 그냥 넘어가게 되면, 나중에 예상치 못한 곳에서 문제가 발생할 수도 있고, 결국 작업자들끼리 마음이 상할 수도 있습니다. 정기적인 스크럼을 통해 개발, 기획, 디자이너 모두 모여 현황을 체크하거나, 온라인에서 일어난 작은 논의라도 관계자들을 참조하여 최대한 많은 사람이 히스토리를 알 수 있게 공유한다면 미래에 발생할 리스크를 최소화할 수 있습니다.

글쓰기는 생각보다 더 중요하다

직접 만나서 대화하기도 하지만 회사에서 가장 많은 커뮤니케이션이 일어나는 곳은 온라인입니다. 메일, 슬랙, 메신저, 지라 등 사실상 업무 대부분이 글로 이루어져 있다고 봐도 과언이 아닙니다. 이럴수록 더욱 심혈을 기울여야 하는 건 글쓰기입니다. 하고자 하는 말은 일목요연하게 정리하고, 제삼자가 봐도 이해할 수 있게 글을 작성하는 게 중요하죠. 시중에 비즈니스 글쓰기와 관련된 온라인 강의도 많이 있지만 가장 쉽고 빠른 방법은 사내에 글 잘 쓰는 동료를 찾아 그 동료가 글 쓰는 방법을 참고하는 것입니다.

오픈 마인드로 상대방의 의견 경청하기

필자도 디자이너지만 오로지 디자인만 중요시할 순 없습니다. 우리는 일정도 챙겨야 하고 개발 스펙도 중요하고 비즈니스 임팩트도 고려해야 하니까요. 같이 일하는 상대방의 입장을 적극 공감하며 “맞아요. 개발 일정이 생각보다 타이트하니 이번 디자인은 최대한 수정 없이 짧은 기간 내에 완성해 볼게요.”라고 말할 수 있는 오픈 마인드를 가져보는 게 어떨까요? 상대방도 나의 우호적인 태도에 마음이 누그러질 수 있습니다.

마치며

사람과 사람 사이에서 일어나는 대화에는 정해진 답이 없습니다. 직책, 회사 문화, 사람, 업무 프로세스 등 다양한 변수에 따라 커뮤니케이션의 온도와 스킬이 달라집니다. 열린 태도로 상대방의 입장을 공감하는 기본적인 자세부터 장착하면 이런 다양한 케이스에서도 긍정적인 의사소통을 할 수 있을 것입니다. 업계는 좁고 우리는 어디에서 어떻게 또다시 만날지 모르니까요.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.