개발자와 소통 잘하는 디자이너 되는 법

※제 개인적 경험에 근거하여 작성한 글로 정답이 아닐 수 있습니다.

 

경험담

뭐맘은 디자이너로 IT회사에서는 6년 정도 근무했었습니다. 

처음에는 IT에대한 기본기도 없고, 개발자와 협업해 본 적이 없어서 무척 막막했던 기억이 납니다.

그때의 저처럼 개발자와 처음 협업하는 디자이너분들에게 조금이라도 도움이 되고자 이 글을 포스팅합니다.

 

그들은 우리와 다르다

우선 개발자 분들은 우리(디자이너)와 다르다는 것을 인지하셔야 합니다.

너무 당연한 이야기 같겠지만 제일 중요한데 놓칠 수 있는 부분입니다.

모든 사람은 다 다르고 직업, 나이, 성별, 살아온 환경에 따라 더욱 달라집니다.

그중에서도 개발자는 디자이너와 대조점에 있는 직군으로 상당히 많은 부분이 다릅니다.

 

가령 디자이너는 텍스트보다 그림으로 소통하는 것이 익숙합니다. 또 대화를 하면서도 머릿속에 많은 이미지를 상상하곤 합니다. 그리고 결과물이나 수정사항이 모두의 눈에 보이는 직군 중 하나입니다.

그만큼 퍼포먼스를 내기도 좋지만, 지적을 받기도 좋은 직업이죠. 누구나 눈과 입은 있으니까요.

 

반면 개발자는 그림보다 텍스트로 소통하는 경우가 많습니다. 같은 공간에 있어도 말보다 텍스트로 소통이 잘 이루어지기도 합니다. 머릿속은 제가 볼 수 없지만 이미지에 대한 상상력이 디자이너보다 풍부하지는 않은 것 같습니다. (디스 아닙니다..ㅠㅠ) 마지막으로 어떤 개발이냐에 따라 다르지만 결과물을 항상 모든 사람이 볼 수는 없습니다. 그만큼 지적받는 것에 익숙하지가 않습니다.

 

대략적으로 적어도 이만큼의 차이가 있습니다. 여기서 서로의 커뮤니케이션 능력, 직급, 업무, 성격 등에 따라 더 양극단으로 치달을 수도 있습니다.

 

그렇다면 이렇게나 다른 디자이너와 개발자가 소통하려면 어떻게 해야 할까요?

제 첫 포스팅에서도 적은 적 있습니다만

 

서로의 눈높이를 맞춰야 합니다.

 

거창한 걸 말하는 게 아닙니다. 모르면 물어보고 나에게 쉬운 것이라도 상대방에게 친절히 설명해 주면 됩니다.

이렇게 몇 번 소통하다 보면 눈높이가 제대로 맞아서 채팅으로도 뚝딱 업무처리를 할 수 있게 됩니다.

 

세세하게 항목을 나누자면 이렇습니다.

 

용어 맞추기

디자이너와 개발자는 주로 사용하는 전문용어가 굉장히 다릅니다. 특히 개발자분들은 종종 일상언어처럼 개발용어를 사용하시는데, 이해 안 가는 부분을 임의로 넘기지 말고 적어두었다가 따로 찾아보거나 당사자에게 꼭 물어보시는 게 좋습니다.

개발 용어에 대한 설명을 들을 때 어렵게 설명하시는 분들이 많습니다. 나쁜 의도나 잘난 체가 아니라 남에게 그 용어를 설명해 본 적이 많이 없어서 그런 것이니 양해를 구하고 쉽게 설명해 달라고 하시거나 본인이 이해한 만큼 쉬운 말로 풀이해 "제가 OOO 이렇게 이해했는데 이런 뉘앙스가 맞나요?"라고 재차 확인하며 대화하다 보면 금세 길이 보입니다. 이런 노력을 하다보면 이상한 사람이 아닌 이상 상대방도 기특하게(?) 여겨 설명을 더 열심히 해주십니다.

 

반대로 디자인 결과물을 갖고 개발자들과 이야기할 때 디자인 용어가 들어간다면 중간중간 친절하게 설명해 주는 것이 필요합니다. 성격차이가 있겠지만 제가 경험한 대부분의 개발자 분들은 조용하고 질문이 적습니다. 모든 것이 이해가 가기 때문에 조용히 있는 것이 아니므로 부연 설명을 해주시면 좋습니다.

 

개발 지식 습득하기

필요한 용어를 그때그때 물어가며 상황을 헤쳐가는 것이 제일 좋지만 시간관계상 매번 그렇게 여쭈기는 어렵습니다.

기본적인 개발 용어나 지식을 틈틈이 공부하시는 게 좋습니다. 

"나는 디자이너인데 이것까지 해야 해?"라고 생각하지 마시고, 더 좋은 결과물을 효과적으로 만들기 위해 필요한 지식이라고 생각하시고 하나씩 배워보세요. 결국은 다 본인의 자산이 됩니다.

 

줏대 있게 설명 잘하기 

용어 맞추기 외에 본인의 디자인 결과물에 대해서 설명을 할 수 있어야 합니다.

앞서 말했듯 디자이너는 결과물이 누구에게나 보이는 직업입니다. 그만큼 한 마디씩 얹기 좋습니다. 각자의 미적 취향과 생각들이 있기 때문입니다. 이때 결과물에 대한 본인의 확실한 콘셉트가 있고 그걸 설명할 수 있어야 사람들을 설득할 수 있습니다. "파란색이 낫지 않나"라고 누군가 흘리듯 말한 멘트에 흔들리지 말고 "여기선 OOO이유로 녹색이 맞습니다"라고 말할 수 있어야 합니다.

 

피드백에 열려 있기

위의 줏대와는 별개로 업무를 하다 보면 수정사항이 생기고 피드백이 올 수밖에 없습니다. 특히 개발자와 협업하다 보면 여러 개발 이슈들로 인해 디자인을 수정해야 하는 상황이 생깁니다. 부득이한 기술적 제약으로 개발을 변경할 수 없어 디자인을 반영할 수 없는 경우도 종종 생깁니다. 개발자들의 수정은 글자 몇 개만 수정하는게 아니라 건물의 기둥을 옮기는 것과 같기 때문에 이런 부분은 납득을 해야 합니다.

 

만나러 가기

개발자는 수줍음이 많은 생물입니다. 모든 걸 이메일과 채팅으로 해결하려고 합니다. 물론 그게 효율적일 때도 많지만 때로는 만나야 해결되는 일들이 있습니다. 친해질 겸 한 번씩 만나러 가서 얼굴 보고 대화를 해보세요. 차츰차츰 내적 친밀감이 생겨 더 원활한 소통이 가능해집니다.

 

 

협업 도구 활용하기

마지막으로 다양한 협업 도구를 사용하는 것이 도움 됩니다. 많이 쓰시는 피그마, 스케치, XD 등으로 디자인은 물론 개발자가 필요한 내용도 함께 제공하여 관련된 정보를 명확하고 일관된 방식으로 전달해 보세요. 업무 효율이 상승합니다.

마치며

저는 디자이너나 개발자를 폄하하려는 의도가 전혀 없음을 말씀드립니다. 그저 제 경험에 기반하여 '개발자들과 협업 시 이렇게 하니 잘 풀렸다' 하는 내용들을 작성한 것입니다. 도움이 되시길 바랍니다. 파이팅!