본 글은 스타트업 개발자의 개인적인 생각을 바탕으로 작성한 글입니다 :)
개발자와 디자이너, 물과 기름이라는 소리 들어보셨나요?
개발자는 매일 '안돼요!'만 말한다고 하고 디자이너는 매일 '1px만 수정해 주세요!'라고 한다고 합니다..ㅎㅎ
저도 처음 디자이너와 협업을 할 때 어떻게 해야 될지 모르겠고 막막했던 적이 있었습니다.
그동안 협업을 하며 시행착오를 겪고 느낀 점들을 토대로 저만의 협업 Tip을 정리해 보려고 합니다.
| 서로의 소중함, 그리고 서로에 대한 존중
저는 예전에 개발자 4명에서 서비스 창업을 한 적이 있는데 초기 기획부터 디자인까지 하려니 정말 막막했습니다. '아 이렇게 디자인이 힘든 거구나...' 창작의 고통?을 느꼈습니다. 디자인의 소중함을 느끼고 디자이너를 존중하는 계기가 되었죠.
지금 하는 프로젝트를 혼자 진행한다고 생각해 보세요. 기획도 하고 디자인도 하고 개발도 하고 마케팅도 하고...
우리는 모두 각자 서로 다르기 때문에 온전히 서로를 이해할 수는 없지만, 그대로를 존중할 수는 있습니다. 상대방의 분야에 대해 소중함을 느끼고 그대로 인정하는 것만으로도 서로를 존중하는 마음을 느낄 수 있지 않을까요?
서로에 대한 존중은 협업에 있어 가장 중요한 부분이라고 생각합니다. 서로 힘을 주고 생산적으로 나아갈 수 있도록 하는 태도와 마음가짐은 꼭 필요합니다.
| 편안한 소통 관계 속에서 피드백은 가능한 상세하게
소통과 피드백도 협업에 있어 정말 중요한 부분입니다. (안 중요한 부분이 없네요..ㅎㅎ)
저는 디자인을 개발 적용하는 과정이 정적인 이미지를 동적인 흐름으로 만드는 것이라고 느낍니다. 정적인 이미지로 이루어진 디자인 작업물을 보고 개발을 하다 보니 디자인에 대한 이해가 완벽히 안되는 부분도, 추가로 디자인이 필요한 부분도 항상 존재했습니다.
소통을 불편하게 생각한다면 그만큼 소통이 적어지고 '이 부분은 그냥 이렇게 개발하면 되겠지?'하고 그냥 소통 없이 넘어가는 부분이 발생하게 됩니다. 이렇게 하나둘씩 넘어가면 나중에 결과물을 놓고 봤을 때 서로가 당황하는 순간이 올 수 있습니다.
그렇기에 편하게 소통할 수 있는 환경을 만들려고 스스로 노력하고 자주 소통해야 합니다.
저는 피드백에 있어서 아래의 내용을 지키기 위해 노력합니다.
- UI 툴에서 해당 작업에 대한 코멘트를 상세히 남기
- 피드백은 솔직하게 하기, 찜찜한 부분을 말하지 않고 넘어가지 않기
- 추가로 필요한 부분은 충분히 생각하고 꼼꼼히 정리해서 놓치는 것 없이 전달하기
- 내가 이해한 부분에 대해서도 피드백해서 한 번 더 디자인 의도 확인하고 개발하기
- 디자인에 대해 고쳐야 할 부분만 피드백 하는 게 아니라 좋은 부분도 아낌없이 피드백하기
- 복잡한 부분은 대면으로 피드백하기
또한 디자인 작업을 시작하기 전 개발에 필요한 부분에 대해 설명해 주는 것도 좋은 방법입니다. 저는 가이드를 만들어서 전달드리고는 했습니다. 예를 들어 '로고 사이즈는 이러이러하게 필요합니다. 화면 크기는 작은 화면, 기본 화면, 갤폴드 처럼 넓은 화면용으로 디자인이 필요합니다.' 등 시작 전에 기본적으로 필요한 부분에 대해 설명하면 나중에 다시 요청해야 되는 번거로움을 어느 정도 줄일 수 있습니다.
| 진행상태는 수시로 친절하게 공유
지금까지 만난 디자이너들은 대부분 섬세했습니다. 1px 차이에도 민감합니다. 마치 아주 어려운 틀린 그림 찾기도 잘 할 것 같은 느낌이었죠. 제가 아무리 디자인을 똑같이 개발해도 디자이너 입장에서는 다르게 느껴지는 부분이 발생할 수 있더라고요. 그래서 저는 수시로 진행 상태를 공유합니다. 그것도 친절하게 이미지와 구현 영상도 같이 공유합니다. 영상을 같이 공유하는 이유는 버튼 클릭 효과나 스크롤 효과 등 애니메이션 요소와, 사진으로는 표현하기 어려운 앱의 느낌을 전달하기 위해서입니다.
| 초기 기획.디자인 단계에 참여하기
전에 초기 기획. 디자인이 전부 픽스된 상태에서 프로젝트에 참여하게 된 적이 있습니다. 디자인 작업물을 전달받았는데 하나의 앱에 SNS 같은 메인 기능만 5개가 넘었고 개발 기간은 2개월 안에 출시를 해야 했습니다. 정말 막막했죠...
저는 다 같이 미팅을 진행했습니다. 우선 기존대로 진행하게 됐을 때 각 기능별 예상 기간을 정리해서 말씀드렸고, 기능별 난이도에 대해 설명했습니다. 기능별 우선순위에 대해 같이 얘기해 보고 출시 일정을 맞추기 위해 중요하지 않은 기능은 제외했습니다. 미팅 결과를 바탕으로 다시 기획하고 디자인 작업 후 개발에 들어갔고 야근으로 불태워 겨우 출시 일정을 맞출 수 있었습니다.
프로젝트 초기에 참여하는 상황이라면 기획. 디자인 단계에 꼭 참여하는 것이 좋습니다. 해당 기획이 개발적으로 가능한지, 개발 난이도와 기간은 어떻게 되는지 소통해야 합니다. 이 과정이 없으면 나중 가서 다시 작업을 반복하는 불필요한 시간이 발생하게 됩니다.
| 디자인은 언제든 변경될 수 있다
개발 도중 디자인은 언제든 변경될 수 있습니다. 이전 직장에서는 전체 디자인만 3번 바뀌었고 사소한 화면 디자인은 30번 정도? 정말 많이 바뀌었습니다. 개발자 입장에서 디자인을 바꾼다는 건 힘들고 까다로운 작업이지만 전체적인 프로젝트 시야에서 보면 더 나은 결과물을 만들기 위한 개선일 뿐입니다. 그렇기 때문에 디자인이 변경되는 것에 대해 미리 인지하고 최대한 모듈화를 잘하고 디자인 패턴을 사용하는 등 변화에 대비해야 합니다.
| 서로에 대한 입장 이해
디자이너) '기능 하나만 간단하게 개발하면 될 거 같은데요?'
디자이너) '지금 개발 한 거에 버튼만 살짝 추가하면 될 것 같아요.'
처음 디자이너에게 이런 소리를 들었을 때 '음...?' 딱 이 생각이 들었었습니다. 근데 사실은 디자이너 입장을 반대로 조금만 생각해 보면 이해할 수 있습니다. 제 생각에 디자이너는 시각적인 부분에 집중하는 사람이기에 버튼 하나 추가하고 기능 하나 추가하는 게 개발적으로 얼마나 복잡할 수 있는가에 대한 공감이 어려운 것 같습니다. 기능 하나 버튼 하나를 추가하는 것이 디자이너 입장에서는 간단한 작업일 수 있으니까요. 역지사지로 생각해 본다면 저런 말들에 대해 '그래 그럴 수 있지'하고 서로의 입장을 이해하게 됩니다.
| 쉬운 말 사용하기
협업을 할 때는 개발 용어를 최대한 자제하고 쉬운 말을 사용해야 합니다. 과장해서 어린이가 들어도 이해할 수 있을 만큼요.
쉬운 말을 사용하면 상대방이 이해하기 쉽고 효과적으로 의사를 전달할 수 있습니다.
| 마지막으로,
개발자와 디자이너의 목표는 같습니다. 좋은 제품을 만들고 싶다는 것.
같은 목표를 바라본다는 것을 잊지 말고 앞으로도 좋은 협업을 위해 노력해 봅시다 :)
'Think' 카테고리의 다른 글
좋은 코드를 위한 노력 (15) | 2023.02.16 |
---|---|
[창업 일기] 두 번의 값진 실패 경험 (2) | 2022.10.18 |
댓글