PM을 위한 디자이너/개발자와의 커뮤니케이션 꿀팁
직전에 포스팅한 글을 쓰는 중에 옆에서 PM인 친구가 소재를 하나 추천했다.
"그 있잖아 모달, 팝업, GNB, 플레이스홀더 같은 거!"하고 자주 들은 단어들을 마구 언급하며 PM이 알아야 할 UX/UI 용어들을 쉽게 정리해달라고 말이다. 직업 특성상 기획자, 디자이너, 개발자 모두와 긴밀하게 협업해야 하기에 절실히 필요성을 느낀 것 같다.
귀찮아서는 절대 아니고 나도 모르게 처음 튀어나온 대답은 "그분들도 아마 서로 다른 용어로 대화하실 걸?"이었다. 딱 아래의 상황이 떠올랐다.
(Banksalad 블로그) 진짜 진짜 흔한 상황 1예전에 뱅크샐러드 블로그 포스트에서 보고 재밌어서 저장해둔 짤인데, 웬만한 실무자는 공감할 것이다. (본 포스트에서는 어떻게 뱅샐의 프로덕트 팀이 서로의 관점 차이를 극복하고 'Banksalad Product Language'를 구축했는지 알려준다. 흥미로우니 추천추천.) 이렇게 겉보기에 대화가 잘 통하고 있는 것 같지만 안 통하고 있는 신기한 상황은 자주 있는 일이다.
위 짤을 자세히 뜯어보자면, 기획자가 이야기하는 '다이얼로그'는 사용자에게 정보를 주거나 액션을 수행시킬 때 사용하는 안드로이드 컴포넌트다. 오해의 소지가 될 수 있는 부분은 다이얼로그가 구현될 수 있는 기능적/형태적 폭이 아주 다양하다는 점이다.
위 이미지 둘 다 다이얼로그다. 권한 설정이나 가벼운 정보 제공의 수준에서는 왼쪽 이미지처럼 모달 형태의 다이얼로그를 쓰고, 신청 폼을 받거나 수행시킬 액션이 많다면 풀 스크린 형태의 다이얼로그도 쓸 수 있다. 또한, 운영체제 별로 최적화된 UX/UI를 제공하기 위해 iOS에서는 alert, action sheet, bottom sheet 등으로 대체하는 옵션도 고려할 수 있다.
디자이너가 언급한 '팝업'은 본래 새 윈도우를 띄우는 기능을 말한다. 레이어로 기존 화면을 덮는 모달로 많이 대체되었다. 형태적으로 유사해 보이고, 팝업이라는 익숙한 이름 자체가 원체 익숙해 둘을 번갈아 쓰는 경우가 많지만, 개발자는 구분한다.
(스티비 블로그 포스트: 헷갈리는 UI, 스티비는 이렇게 씁니다.) pop하고 뜬다고 다 팝업은 아님개발자가 말한 알럿은 단어에 내포된 의미 그대로 경고창이다. 정보의 중요도 심각성, 액션 유도 필요성에 따라 스낵바, 배너, 토스트 ui, 다이얼로그 등의 컴포넌트를 활용할 수 있다. 아, 아니면 개발자가 iOS 개발자라 iOS 컴포넌트인 알럿을 가리키는 걸 수도 있겠다.
(Material Design) 왼쪽은 Banner, 오른쪽은 Snackbar이렇게 유사해 보이는 용어들이 엄밀히 따지면 성격이 다르거나 기능적으로 차이가 크기 때문에 비슷한 걸 상상해 별 탈 없이 넘어가면 다행이지만, 아주 다른 상상하고 있는 경우 문제가 발생할 수 있다. 결과물이 달라짐은 물론이고, 서로가 예상하는 공수의 차이로 심한 오해와 비효율을 초래할 수 있다는 말이다.
그러면, PM은 어떻게 해야 기획자, 디자이너, 개발자 모두와 커뮤니케이션을 잘할 수 있을까? 짤 하나 설명하는데도 이렇게 많은 용어가 튀어나오는데, 처음부터 작정하고 다 외우기에는 현실적으로 어렵지 않을까? 그래서 범위를 줄여주자면, 내가 같이 일하는 사람들과만 말이 잘 통하면 된다. 그러기 위한 팁은 다음과 같다.
서비스를 이해하고 활용하기(=개발자 이해하기)
담당하는 서비스의 플랫폼이 웹인지 앱인지, 디바이스는 PC인지 모바일인지, 운영 체제는 윈도우인지 맥인지, iOS인지 안드로이드인지를 아는 것이 첫 번째다. 이에 따라 사용되는 컴포넌트와 용어가 조금씩 다르기 때문이다. 그 차이가 어느 정도 보이기 시작하면, 무엇보다 개발자의 말을 이해하기 수월해질 것이다.
Material Design에 Andriod, Web, 약간의 iOS 등 웬만한 기초적인 용어들은 다 담겨있다.
Humans Interface Guidelines는 Apple의 디자인 시스템이라 Mac OS, iOS일 경우 상세히 알기 좋다.
현실적인 방법 또 하나는, 화면을 같이 보면서 커뮤니케이션하는 것이다. 아무래도 말만 할 때보다 오해를 줄일 수 있다. 담당하는 서비스의 화면을 참고하는 것이 가장 효과적이다. 새로운 화면을 기획 중이라면 디자인 에셋을 활용해 화면을 빨리 구성해보거나, 레퍼런스를 참고해 이야기해도 좋다.
내 관점에서 인과적으로 이해시키기
특히 추상적인 수준에서 디자이너나 개발자에게 요청해야 하는 경우에 해당된다. 목적과 의도를 먼저 설득한 뒤 화면 단위보다 플로우 단위로 설명해주는 것이 좋다. 너무 당연한 팁처럼 들릴 수 있지만 생각보다 "이 화면에 무엇을 추가해주세요, 이 화면에서는 이 정보를 수집해주세요" 등 결과론적으로 지시했다가 대화가 원활하지 못한 경우를 많이 봤다.
예를 들어, PM이 "(상품을 많이 노출시키려면 사용자가 상품 피드를 많이 탐색해야 해. 흐름이 끊기지 않아야 하는데 상품의 옵션을 확인하거나 장바구니에 담으려면 상세 페이지로 진입해야 하다 보니 번거롭기도 하고, 이탈률도 느는 것 같아. 사용자에게 화면 이동을 안 시키고 피드에서 바로 장바구니에 팍팍 담을 수 있게 하면 좋을 것 같은데... 그러니까) 상품 피드에 상품 옵션 셀렉트랑 장바구니 추가 버튼 넣어주세요."라고만 말하면 디자이너와 개발자는 요청 사항이 얼마나 구린지에만 집중해 방어적으로 나올 가능성이 크다.
결론만 이야기해 더 좋은 방안을 생각할 여지를 없애는 대신 의도와 목적을 상세히 설명해주면, 원래의 제안보다 훨씬 좋은 대안이 나올 수 있다.
(왼) PM 제안, (오) 디자이너가 이해하고 내는 대안내부적으로 정의하고 정리하기
우리는 고객사에게 가이드를 제공할 때 보통 제너럴 섹션을 따로 만들어 주요 컴포넌트를 정의해준다. 시작을 거창하게 할 필요 없이 내부적으로 합의된 용어와 컴포넌트를 잘 정리해두면 서비스가 복잡해지고 조직의 규모가 커져도 문제없다.
