주니어 디자이너의 커뮤니케이션 고찰

직장에서 ‘커뮤니케이션을 잘한다'라는 건 어떤 의미일까요? 한때 저는 잘 이야기하고 잘 이해하는 것이 커뮤니케이션의 전부라고 생각했습니다. 여러 경험을 겪은 지금은, 업무 환경에서 ‘협업’과 ‘설득’이 커뮤니케이션의 목적이 아닐까 합니다. 그래서 ‘어떻게 하면 더 똑똑하게 이야기할 수 있을까?’를 고민하고 있습니다.

이번 글에서는 이전 저의 커뮤니케이션 방식을 회고하고, 더 나은 커뮤니케이션을 위해 개인과 팀에서 어떤 노력을 했는지 살펴보고자 합니다. 나아가 앞으로 커뮤니케이션에 더 능통한 디자이너가 되려면 어떤 부분이 발전되어야 할지도 함께 이야기해보겠습니다.

※ 디자인 직무 중심으로 설명해서 타 직군과 조금 차이가 있을 수 있습니다.

과거의 커뮤니케이션

신입 시절의 저를 떠올려보면 일할 때마다 모르는 용어들과 이해되지 않는 맥락들을 파악하는 데 급급했습니다. ‘내가 모르는 게 어떤 건지도 모르겠다’가 딱 맞는 표현일 겁니다. 그래서 이때는 ‘내 생각을 정확히 알려주고, 상대의 말을 정확히 이해하는 커뮤니케이션’에 집중했습니다.

잘 전달하기

개인적으로는 텍스트로 내용을 전달하는 것이 구두로 이야기할 때보다 전달하기 어려웠습니다. 대면한 상황에서는 간단한 그림을 그리거나 대상을 가리켜가며 설명할 수 있었으니까요. 반면 문서를 작업할 때는 이해를 돕는 부수적 수단을 쓸 수 없었습니다. 그래서 슬랙이나 노션 등 협업 툴로 커뮤니케이션할 때는 디자인 시안에 관한 내 나름의 논리와 고민 사항을 ‘청자가 이해하기 쉬운 구조’로 전달하는 것에 초점을 맞췄습니다.

잘 전달받기

IT 업계와 스타트업에서 일하는 사람들은 익숙하겠지만, 갓 들어온 신입은 이해하기 어려운 용어나 약어들이 많습니다. 모르는 말이 있을 땐 기억했다가 검색해보거나, 혼자서 알아내기 힘들면 도움을 요청했습니다. 또 전달받은 내용을 내가 제대로 이해했는지 다시 한번 물어보면서 상대의 의미와 의도를 넘겨짚지 않도록 했습니다.

더 나은 커뮤니케이션을 위한 노력

설득하기 위한 커뮤니케이션

시간이 흘러 작업한 디자인 시안을 리뷰할 때 다른 팀원들의 궁금점과 의문점에 대해 뾰족한 답변을 내놓지 못하는 일을 경험하면서 스스로 ‘감에 많이 의존하는 작업자’라는 걸 깨달았습니다. 감에 의존하다 보니 저의 의견은 다른 구성원들을 설득할 힘을 갖지 못했습니다. 그래서 설득의 힘을 갖기 위해 다음과 같은 방법을 시도해 봤습니다.

사용성 측면에서 중심 잡기

디자인 시안에 대한 피드백을 주고받을 때, 직무에 따라 개발 안정성이나 혹은 비즈니스 차원에서 의견을 내놓습니다. 디자이너가 사용성에 기반한 논거를 제시하지 못하면 ‘개발 편의에 맞게’, 혹은 ‘수익이 우선시되는 쪽으로' 논의가 이루어지게 됩니다.

한 번 더 신입 시절을 추억하자면, 여러 방향에서 잘 모르는 분야의 피드백을 들으면서 ‘어? 듣고 보니 그렇네. 그럼 이렇게 바꿔야겠다’라고 쉽게 설득당하곤 했습니다. 물론 제품을 설계할 때 개발 안정성과 비즈니스도 중요하게 고려가 되어야 합니다. 그러나 디자이너가 사용성 측면에서 이야기하지 못하면 제품은 의도치 않게 사용자, 즉 고객에게 덜 친화적인 방향으로 나아가게 됩니다.

정성/정량적 근거를 통해 말하기

문제를 정의하고 디자인 솔루션을 제안할 때, 구성원들을 설득할 수 있는 가장 좋은 방법은 정성/정량적 근거를 함께 제시하는 겁니다. 앞서 이야기한 것과 마찬가지로 디자이너 개인의 감으로만 논리를 피력하는 것엔 한계가 있습니다. 또 어쩌면 디자이너 스스로도 ‘정말 내 생각이 맞나?’ 하는 의문이 들 수도 있습니다.

이럴 땐 팀에서 사용하는 데이터 분석 툴에서 근거를 찾아보거나 고객상담(Voice of Customer, VoC) 의견을 함께 살펴보는 것도 좋은 방법입니다. 혹은 사용자 인터뷰를 통해 설득할 근거를 찾을 수도 있습니다. 이런 방법들을 시도할 환경이 되지 않는다면, ‘Visual Eyes’ 같은 도구를 활용하는 것도 추천합니다. Visual Eyes는 알아보고자 하는 특정 화면의 복잡도나 주목도를 히트맵으로 알려주는 서비스입니다. 시각적으로 알려주기 때문에 문제의 개선점을 파악하는 데 활용할 수 있으며, 구성원에게 보여주기도 좋습니다. 주의할 점은 데이터는 데이터이기 때문에 활용하는 수단이 되어야지 이를 맹목적으로 의존하면 안 됩니다.

디자이너에게 ‘설득의 커뮤니케이션’은 디자인 논리와 관련이 깊습니다. 신입, 나아가 주니어 시절에는 ‘우리 서비스에 왜 이런 디자인이 어울리는 걸까?’라는 이유를 생각하고 작업하는 것이 아니라 직감과 직관에 의존해 작업할 때가 많습니다. 지금까지 계속 얘기했듯이 이런 건 구성원을 설득하는 데 매우 취약하기 때문에 이제는 근거를 먼저 생각하고 디자인 시안을 작업할 수 있도록 항상 유념하고 있습니다.

협업하기 위한 커뮤니케이션

협업하지 못하는 사공이 많으면 배가 산으로 갑니다. 서로 다른 관점을 가진 사람들이 함께 일하면서, 그 일의 결과를 옳은 방향으로 끌고 가려면 협업이 잘 되어야 합니다. 협업하기 위한 커뮤니케이션은 그 자리에서 대화가 잘 이루어지는 것을 넘어, 대화가 끝난 후에 더 효율적이고 생산적인 일 처리를 가능하게 합니다. 다음은 신입 때부터 더 잘 협업하기 위해 끊임없이 고민하고 시도해 본, 그리고 시도하는 커뮤니케이션 방법들입니다.

효율적인 미팅 운영

협업할 때 미팅 운영만큼 에너지 소모가 큰 업무가 있을까요? 최소 1시간이 넘는 미팅을 준비하고 이끌어가는 건 생각보다 많은 에너지와 노련함이 필요합니다. 보통 미팅 준비의 필요성을 느끼지 못했을 때는 ‘내가 준비한 자료만 잘 이야기하면 되겠지’라고 피상적인 목표만을 생각하기 마련입니다. 그러나 사실은 전혀 다릅니다. 프로젝트 진행 상황, 여러 이해관계, 그리고 참여자에 따라 미팅의 목적이 달라지고 그에 따라 다른 방식으로 운영이 되어야 합니다. 그리고 이를 어우를 수 있는 커뮤니케이션이 중요해집니다.

미팅의 목적이 뚜렷하게 제시되지 않으면 각자의 아이디어 발산만이 이뤄질 위험이 있고, 미팅 후의 수확이 뚜렷하지 않거나 아예 없을 수도 있습니다. 이런 불상사를 막기 위해 미팅에 앞서 ‘미팅의 목적’과 ‘미팅을 통해 얻고자 하는바’를 미리 참여자에게 공유하고 있습니다. 참여자들이 미팅의 목적에 관해 알고 있는 것만으로도 더 효과적인 논의가 이루어지고, 미팅 후에 진행해야 할 액션도 구체적으로 나타납니다.

작업물 쪼개기

디자이너가 개발 코드를 다 이해할 수 있으면, 개발자가 ‘아?’ 했을 때 ‘아!’라면서 쉽고 빠른 소통이 가능할 겁니다. 그렇지만 개발자 출신 디자이너가 아닌 이상 힘든 부분입니다. 사실 개발자와의 소통은 IT 업계에서 일하는 디자이너에게 가장 큰 숙제 중 하나입니다. 개발자와 좋은 커뮤니케이션을 하기 위해 많은 시도를 했고, 그중 유의미한 성과가 있는 방법을 소개하겠습니다. 바로 ‘작업물 쪼개기’입니다.

예를 들어 온보딩 화면을 개선해보겠습니다. 3 페이지였던 온보딩 과정에서 1페이지를 추가하고, 인지성이 좋지 않았던 프로그래스 바 UI 디자인도 바꾸려고 합니다. 또 ‘뒤로가기’ 버튼도 새로 추가하려고 합니다. 그러면 개발자와 우선순위를 고려한 논의를 통해 이 작업을 효율적으로 쪼갤 수 있습니다.

이를테면 우선 온보딩 화면을 추가한 작업을 마친 뒤 프로그레스 바 UI를 변경하고, 뒤로가기 버튼 추가 작업을 하는 식입니다. 이 경우는 이해하기 쉽도록 예시를 든 것일 뿐, 세 작업을 한 번에 하는 게 효율적일 때도 있습니다. 중요한 것은 개발자와 어떤 방식으로 나누어 작업하는 게 효율적인지를 명확히 커뮤니케이션할 수 있으면 협업이 수월해지는 점입니다.

유저스토리 단위로 소통하기

서비스 화면을 설계할 때 고려해야 할 것은 한두 개가 아닙니다. 사용자 타입에 따라 다르게 나타나는 화면이 필요할 때도 있고, 특정 상황에 따라 별도의 화면이 추가되거나 다른 플로우로 이동해야 할 때도 있습니다. 그래서 가끔 디자이너 자신이 만든 화면설계를 보고 헷갈릴 정도입니다. 그러면 이를 어떤 방법으로 커뮤니케이션하면 좋을까요?

여러 방법이 있겠지만, 개인적으로는 ‘유저스토리’를 기반으로 한 화면 플로우 정리를 추천합니다. 이를 통해 사용자 플로우와 디자인 세부 스펙, 그리고 특정 상황에 따라 달라지는 여러 사례들을 구성원에게 전달하는 게 편해졌습니다. 더불어 같이 작업하는 PO, PM과는 ‘우리가 정의한 문제를 이 디자인이 해결할 수 있는 솔루션인가?’에 대해 더 뾰족하고 원활하게 소통할 수 있게 됐습니다. 무엇보다 개발자에게 여러 케이스에 따른 화면 플로우를 문제없이 전달할 수 있었으며, QA 담당자도 이 문서로 서비스의 흐름을 쉽게 이해할 수 있어서 QA를 더 원활히 진행할 수 있었습니다.

이처럼 ‘협업의 커뮤니케이션'은 일하는 방식과 관련이 있습니다. 질 좋은 커뮤니케이션은 대화 자리에서 이야기만 잘하는 것이 아닙니다. 이야기를 나누기 전에는 내가 전달하고 자 하는 바를 협업에 용이하도록 준비하고 공유해야 하며, 이야기를 나눈 후에는 그에 따라 정말 효율적인 업무처리가 가능해야 합니다. 좋은 커뮤니케이션의 결과는 대화 자리에만 국한되는 것이 아니라 업무 효율성과 일의 결과로 나타납니다.

설득과 협업, 그 다음엔?

초창기 커뮤니케이션에 어리숙했던 시절을 지나 이제는 설득과 협업을 위해 ‘어떤 방식으로 커뮤니케이션을 해야 하는가?’에 대해 고민하고 여러 방식을 시도하고 있습니다. 그래도 여전히 커뮤니케이션은 어렵습니다. 특히 내가 주장하는 바에 자신감이 없거나 다른 사람의 의견을 받아들이기 어려운 상황에서 더욱 그렇습니다. 그래서 커뮤니케이션을 더 잘하기 위해 시도해야 할 다음 단계는 커뮤니케이션의 마음가짐, 바로 ‘태도’라고 생각합니다.

내가 전문가라는 것 유념하기

디자인은 다른 사람들로부터 피드백을 받기 쉬운 작업물입니다. 같은 직무인 디자이너뿐만 아니라 다른 직무의 사람들로부터도 피드백을 받습니다. 그래서 참 흔들리기도 쉽고, 특히나 서로 상충하는 피드백을 받으면 이걸 어떻게 정리하고 진행해야 할지 머리가 아픕니다. 여러 이야기 속에서 필요한 피드백을 선별하고 좋은 안으로 개선해 나가려면, 스스로가 프로덕트 디자인 전문가라는 걸 유념하고 중심을 잡아야 합니다.

열린 마음으로 다른 의견 받아들이기

여기서 ‘내가 전문가라는 것 유념하기’가 ‘내 말이 무조건 맞아’라는 의미는 아닙니다. 함께 일하는 동료들은 모두 똑똑한 사람들이고, 그들이 낸 의견에는 합당한 이유와 논리가 있습니다. 그런데도 그들의 의견이 설득이 안 되거나 이해가 안 될 때가 있습니다. 그건 그들이 잘못된 생각을 한 것이 아니라 서로 간에 커뮤니케이션이 잘 되지 않았기 때문일 확률이 높습니다.

그런 경우 다시 한번 설명을 요청하면, 서로 오해하고 있었거나 다른 지점에서 이야기했던 걸 알 수 있습니다. 어쩌면 본인의 시안에 오랜 시간 몰두하느라 시야가 좁아진 걸 스스로도 눈치채지 못하고, 다른 팀원의 피드백을 잘 수용하지 못할 때도 있습니다. 그러나 필요한 만큼 시간을 두고 다시 생각해보면, 그때 받았던 피드백이 훨씬 좋은 방법이라는 걸 깨닫곤 합니다.

커뮤니케이션은 항상 어려운 숙제

혼자 일하지 않는 이상 커뮤니케이션 문제는 언제나 숙제처럼 따라다닐 것입니다. 또 어쩌면 연차가 쌓임에 따라 달라지는 역할에 맞게 필요한 커뮤니케이션 역량이 끊임없이 바뀌게 될 것입니다. 중요한 것은 더 좋은 커뮤니케이션을 하기 위해 내가 어떤 노력이 필요한지를 깨닫고, 그걸 실천하는 것이라고 생각합니다.

이번 글에서는 신입 시절을 떠올리며, 커뮤니케이션 방식에 대한 고찰과 시도했던 여러 방식을 소개했습니다. 오늘 이야기한 방식이 정답은 아닙니다. 다만 비슷한 고민을 하는 IT 업계의 디자이너, 혹은 커뮤니케이션이 늘 고민이었던 누군가에게 조금이나마 도움이 되었길 바랍니다.

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