역대급 콜라보를 위한 '협업의 자세' for 디자이너
원만한 협업을 위해 기획자, 디자이너, 개발자가 지녀야 할 자세
# 신과 함께 - 강림도령, 이덕춘, 혜원맥
귀인이요~최근에 '신과 함께'라는 영화를 봤습니다. 영화에 대한 평가 보다도, 저는 참 이자홍 씨가 부럽더군요. 자신의 뒤를 든든히 지키는 저승 삼차사 덕분에 그 어렵다는 저승의 관문들을 통과하는 모습을 보면서 나에게도 저런 동료들이 있다면! 하는 생각마저 들더라고요. 좀 오바해봤습니다만... 강림도령, 이덕춘, 혜원맥같은 기획, 디자이너, 개발자가 되어 누군가에게 나도 든든한 동료가 되어보는 것은 어떨까요??
# 목적이 같으면 협업이 쉬워진다.
대학생 때 참 교수님들은 조별 과제를 많이 내주셨습니다. 협동심, 사회성 등을 키우고 팀 단위 프로젝트의 사전 경험이라는 명목 하에 우리들은 얼마나 큰 고통을 받았습니꽈아!! 우리들의 조별 과제가 늘 산으로 가고 흑역사로만 남았던 이유는 팀원들의 생각이 서로 달랐고 마음이 딴 데(주로 놀 생각) 가있었기 때문일 겁니다. 이렇듯 프로젝트 진행의 목적이 서로 다르거나, 혹은 사공이 많을 경우 원만한 협업이 이루어지기 어렵습니다. 특정 목표와 얻고자 하는 성과에 대해 서로 공유하고 공감대를 형성하는 것이 우선이 되어야 합니다. 영화 '신과 함께' 에서 저승 삼차사의 목적이 분명했던것 처럼 말이죠.
우리의 협업이 조별 과제 잔혹사가 되지 않으려면...UX/UI 프로젝트의 목적은 깊게 들어가 보면 다양하겠지만, 결국은 '사용자 중심'일 것입니다. 더 나은 사용자 경험 설계가 가장 중요한 첫 번째 항목이라고 생각합니다. 개인이 일하는 목적은 다양할 수 있겠지만, 협업하는 시간만큼은 더 나은 UX 설계에만 집중해야 합니다. 모든 선택과 결과물은 사용자, 고객 중심이어야 한다는 것을 명심!
이 디자인(기획, 개발)이 스스로 만족스러운지?
이 디자인(기획, 개발)이 더 나은 사용자 경험을 제공하는지?
이 디자인은 실제 사용자에게 충분히 테스트되었고 긍정적인 수치와 결과를 얻었는지?
위의 세 가지를 스스로에게 끊임없이 질문해야 합니다. 특히 작업 과정 중 선택의 기로에 섰을 때 말이죠. 나를 더 뽐내거나 생색내기 위해 하는 것이 아니고, 내가 더 편하려고 하는 것도 아닙니다. 더 나은 사용자 경험 설계와 개발이 목적이 되어야 합니다.
# to be clarified - 명확하게 전달하기
'나도 날 모르는데 네가 뭘 알아ㅠ_ㅠ'
상대방이 내 마음을 알아주길 기다리지 말고 내가 뭘 했는지 정리하고 뭐가 더 필요한지 명확히 요청하는 것. 협업에 있어 굉장히 중요한 부분입니다.
ㅇㅏ니, 아무거나말고 뭐 먹고 싶냐고...협업은 여러 명의 상호작용이고, 각자가 본인의 업무에 집중하기 때문에 각자가 무엇을 하고 있고 어떤 상황인지 구체적으로 알기가 쉽지 않습니다. 또한 상대방에게 요구할 때도 마찬가지입니다. 모호한 요구는 모호한 결과로 이어질 수밖에 없습니다. 대충 요구하고 던져놓고 알아서 척척 해오길 바란다면, 그건 욕심! 물론 시키는 대로 하라는 일방적인 업무지시 방법도 피해야 합니다.
FREITAG을 설명하는 명확한 한장의 이미지그렇다면 어떻게 해야 명확한 소통이 가능할까요? '내가 아는 것을 상대방도 알고 있을 거야'라는 생각을 버려야 합니다. 우리의 직무는 꽤나 전문적이어서 각자의 영역을 깊게 알기란 쉽지 않습니다. 그리고 6하 원칙이 꽤나 도움이 됩니다. 내가 어떤 일을 해야 하는지, 왜 하는지, 언제까지 해야 하는지, 효과는 무엇인지 등 을 머릿속에서 정리하거나 글로 써보면 더욱 명확해집니다.
# 모든 일은 반드시 수정하게 되어 있다(근엄진지)
그 시절의 윈도 95는 약 3500개의 버그가 있었다.1995년 8월 24일, 윈도 95가 세상에 나온 순간, 이미 3500개의 버그가 존재했고 빌 게이츠 이하 MS의 프로그래머들은 이를 알고 있었다고 합니다. 하지만 대부분의 일반 사용자들은 버그가 있는지조차 몰랐고, 윈도 95는 출시 직후 전 세계를 제패했죠. 소프트웨어에서 버그를 완전히 잡아내는 것은 사실 불가능합니다. 프로젝트의 규모가 클수록 더욱 그렇죠. 대세에 영향을 끼치지 않는 3500개의 미미한 수정은 출시 이후에도 계속 이어졌다고 합니다. 이와 같은 경우는 모바일 디바이스에서도 이어집니다. App Store의 업데이트 알람은 하루가 멀다 하고 늘어나고 '버그 해결, 앱의 안정성을 더욱 강화했습니다.'라는 버전 업데이트 설명은 App 업데이트 시 늘 따라붙는 수식어처럼 느껴집니다. 심지어 글을 작성 중인 오늘 Dropbox의 iOS App 업데이트 설명은 '눈에 띄지 않는 성능 및 기능 개선'이네요 :) 기억하세요, 보완과 수정은 일을 끝낸 후에도 충분히 가능합니다. 너무 완벽한 모습만을 고집하지 말아주세요.
# Over-communicate
요즘처럼 빠르게 변화하는 시장에서는 긴밀한 협업과 적극적인 커뮤니케이션이 더욱 중요해지고 있습니다. 하하... 참 진부하지만 그렇습니다. 특히나 각 단계가 명확하게 구분된 조직일수록 효율적인 커뮤니케이션이 중요하죠. 기획-리서치-디자인-개발-QA 등이 나눠져 있고 각 단계가 구분된 상태에서 받아쓰기식 업무를 한다면 결코 좋은 결과물이 나올 수 없겠죠. 빠르게, 그리고 다양한 방법으로 자주 커뮤니케이션해야 합니다. 특히나 업무 중 막히거나 의심되는 부분이 있다면 무조건!
공유는 좋다... 아니 자주해야 좋다대부분의 디자이너들은 혼자 하는 작업에 익숙합니다. 크리에이티브를 다투는 작업이다 보니 디자이너들은 보통 중간 과정을 공유하는 것에 대한 두려움이 있기 마련입니다. 자신의 기준에서 최대한 정제되고 만족할만한 작업 결과물만을 보여주고 싶어 하죠. 방금 전에 말씀드렸듯이 모든 일은 반드시 수정하게 되어있는데도 말이죠. 남에게 평가받는 것에 대한 심리적 불안감을 떨치고 자주 공유하고, 테스트와 프로토타입을 통해서 중간중간 수정해나가는 건 어떨까요? 물론 한 가지 일에 깊게, 끈기 있게 몰두하는 자세도 중요하죠. 그래야 더 좋은 서비스가 나올 수 있습니다. 하지만! (특히 IT업계에서는) 처음부터 끝까지 자신의 계획대로 완벽할 수 없으니, 마감 직전까지 일을 미루거나 공유를 미루지 말고! 평가 공포증으로부터 벗어나 중간과정을 자주 공유하고 하나씩 개선해 나가고 서로의 공감대를 얻는 방법을 추천합니다.
# 그땐 그랬지... 회고하기
노벨 문학상 후보 클라스...프로젝트를 되돌아보며 각자의 생각과 아쉬웠던 점, 잘된 점 등을 나누는 시간을 갖는 건 어떨까요? 회고하는 자리이지만 '형식에 얽매이지 않고 자유롭게' 의견을 주고받는 시간... 참 듣기만 해도 불편하고 부담스럽나요?? 하지만 이 회고의 자리는 생각보다 유익합니다. 좋았던 점과 고쳐야 할 점들을 추후 다른 프로젝트에 적용할 수 있고 같은 실수를 방지할 수 있습니다. 방금 나와 함께 일했던 동료들은 이대로 안 볼 사이가 아니라, 내일도 모레도 또 봐야 하는, 그리고 계속 함께 일해야 하는 '동료'이기 때문에 각자의 일하는 방식과 생각을 공유하는 자리는 그 어떤 대화보다 가치 있을 것입니다.
그랬군... 그랬구나ㅏㅏㅏㅏ대부분 자기만의 일하는 방식이 있고 습관이 있을 것입니다. 기획자, 디자이너, 개발자는 서로 생각하는 방식마저 다릅니다. 일을 처리하는 방법 역시 다르며, 각자 좋아하는 분야와 관심사도 다릅니다. 앞서 말한 Over-communication의 연장선으로 프로젝트를 마친 후 쿨하게 이러한 점들을 공유할 수 있는 '회고의 자리'는 이런 우리의 차이점을 조금은 이해할 수 있게 도와줍니다.
지나고 나면 다 아름다운 기억이 아닐까요!? 지나고 나서야 비로소 보이는 것들이 있듯 말이죠. 물론 회고 자체로도 의미가 있지만 더욱 중요한 건 이후 실행입니다. 다음번엔 다음에 있을 협업과 새로운 프로젝트의 성공을 위한 회고라는 점을 잊지 말아주세요!
# 마치며
내 글은...팀 프로젝트를 하면 늘 과정은 힘들기 마련입니다. 하지만 잊지 말아야 할 한 가지! 혼자가 아니라는 것입니다. 목적지까지 가는 길이 쉽지 않더라도, 그 고통을 알아주고 함께 나눌 동료가 옆에 있습니다. 지나고 나면 다 좋은 추억이 되어 같은 마음을 공유할 수 있는 나의 동료가 생긴다는 게 참 좋습니다. 오늘도 동료들을 통해 참 많은 영감을 얻고 많은 것을 배우고 있는 것 같습니다.
