PM은 UI.UX를 어떻게, 얼마나, 언제 다뤄야 하는가?

부트캠프도 어느덧 반절이 다되어 간다. 지금까지 배운 내용은 대부분 문서 작성과 기획 위주였던 것 같다. UI와 UX에 대한 내용도 당연히 존재했지만, MVP 프로젝트를 위한 사전강의에 진입하면서 강사님도 보다 UIUX에 가까운 사례들을 많이 들어주시는 것 같다.

사실 대학 시절 원래의 꿈은 UIUX 쪽이었기에 UI나 사용자경험에 대한 기본적인 개념은 낯설지 않다. 총 3번의 개인 과제와 2번의 팀 과제 중에서 Framer로 웹사이트를 만드는 과제를 가장 익숙하게 (심지어 유일하게 처음 쓰는 툴이었음에도) 했기도 하고. 다만... 부트캠프를 들으면서 오히려 더 궁금했던 부분은 PM으로서 UI UX를 어떻게 다뤄야 하는가였다. 마침 오늘 팀에서 했던 아티클 카타가 UI UX에 대한 내용이어서 기록.

들어가기 전에

읽은 아티클:

사례를 통해 쉽게 알아보는 ui ux 뜻과 차이

국내최초 취업정보회사 - 제로베이스

 

UI나 UX나 그게 그거 아니야?

UI나 UX나 그게 그거 아니야?

 

고민에 빠지는 순간 이탈하는 사용자의 심리

고민에 빠지는 순간 이탈하는 사용자의 심리

 

UIUX 디자인 완벽 이해하기! UIUX 우수 사례, 차이점까지 총 망라!

국내최초 취업정보회사 - 제로베이스

 

시각장애인에게 ‘읽는 순서’가 왜 중요할까? | 접근성 업무일지 #1

원칙보다 사용성에 집중할 때 | 접근성 업무일지 #1

 

시각 정보를 소리로 번역하는 법 - 시각장애인을 위한 얼굴 인증 개선기 | 접근성 업무일지 #2

시각 정보를 소리로 번역하는 법 - 시각장애인을 위한 얼굴 인증 개선기 | 접근성 업무일지 #2

내가 맡은 아티클 정리글:

토스 유니버설디자인팀의 시각장애인 접근성 개선기를 읽고

 

본론

PM의 경계 : 문제 정의라는 역할 잃지 말기

우리팀 서기로서 튜터님과 면담시간에 정리 역량을 쭉쭉 기르는중... 다른 튜터님께서 나는 회의 중 논의된 내용을 바로바로 요약하고 패러프레이징해서 적는 걸 잘하는 것 같다고, 회의록 작성은 신입이 어필할 수 있는 좋은 역량 중 하나라고 칭찬해주셨음 헤헷

팀원들과 함께 비슷하게 궁금했던 부분 첫번째는 "PM이 디자인을 어디까지 알아야 하는가"였다. 튜터님은 PM이 피그마를 장인처럼 다루거나 직접 픽셀을 조정할 필요는 없고, 오히려 그런 기능적인 면보다 중요한 것은 ‘UI/UX 디자이너와 일을 잘할 수 있는 정도’의 감각을 갖추는 것이라고 답변해주셨다.

그리고 나는 토스의 접근성 개선 사례를 읽으면서 심도 있는 UX 개선의 경우 당연히 기획이 고도화되어야 할 텐데 이 경우 R&R이 어떻게 되는지 궁금해졌다. 튜터님은 심도 있는 UXUI 개선의 R&R은 회바회인데, 디자인 리소스가 많은 회사에선 디자이너가 제안하는 경우가 많은데 중간사이즈면 PM이 하는 경우 많다고 하셨다. 월권 불만은 없느냐고 여쭈니, 그런 경우가 있긴 있으나... 필요하면 제안하는 게 맞는 거라고 해주셨다.
PM이 사사건건 디자인 시안을 수정하려 든다면 그것은 협업이 아니라 방해겠지만, 오히려 또 연차 높은 시니어 디자이너와 주니어 PM이 함께 일할 때는 디자이너의 의견에 끌려다닐 수도 있다고도 말씀하셨다. 결국은 다 회바회, 케바케, 조직바이조직인 것이고... 암튼, PM은 R&R의 경계를 명확히 해야 한다.

종합해보면 PM의 화법이라면 (<프로덕트 오너> 책에서는 PO의 화법으로 나온 내용이지만) "이 버튼은 파란색이어야 해요"가 아니라 "지금 유저들이 결제 단계에서 이탈하고 있는데, 인지 부하를 줄이기 위해 정보를 분산하는 방향은 어떨까요?"라고 말하는 것이 해당된다고 할 수 있다. 이쯤 되니, 대학생 때 디자인 외주 하면서 짜증났던 클라이언트의 전형만 피해도 괜찮은 PM이 될 수 있겠다는 생각이 드는데 취준생의 우스운 착각일까?

로고가 잘 보여야 한다는 목적을 말해야지, 혼자 알아서 결론 내리고 '로고 더 크게 해주세요'라고 해버리면 안 되는 것... 우리 팀이 뭘 해야 하는지 잘 말하는 것은 생각보다 어렵다.

그리고 팀원분이 디자인 시스템 도입을 어떻게 정하냐고 질문했는데, 튜터님이 그건 PM이 결정하는 것이 아니라, 디자인 팀의 필요를 듣고 개발팀과의 3자 논의 구조를 만드는 것이 보통이라고 하셨다. 그리고 디자인 시스템 도입은 초기에 하는 것이 맞다고 하셨다. (그 말인즉슨, 대부분의 실력있는 디자이너라면 먼저 필요성을 느끼고 디자인 시스템을 만든다는 얘기겠지)

인지 부하의 역설 : 클릭을 늘려서라도 '고민' 줄이기

오늘 가장 흥미로웠던 지점은 '힉의 법칙(Hick's Law)' 이야기였다. 힉의 법칙이란 선택지의 개수가 늘어날수록 의사결정에 걸리는 시간이 로그 함수적으로 증가한다는 법칙이다. 선택지가 극단적으로 많으면 한두 개 차이가 별 게 아니겠지만, 선택지의 개수를 차츰 늘려가는 초반 구간에선 한두 개 차이가 클 수 있다. (2016학년도 수능 영어 수능특강에 비슷한 내용이 나왔었다 ㅋㅋㅋ)

부하에는 인지 부하 (Cognitive Load), 시각 부하 (Visual Load), 운동 부하 (Motor Load)가 있다. 이중에서 가장 많은 자원을 소모하는 것은 인지 부하로, 무엇을 해야 할지 생각하고 기억하는 과정에서 발생한다. 시각 부하는 화면에서 특정 객체를 찾는 과정에서 발생하고, 운동 부하는 마우스를 클릭하거나 버튼을 누르는 물리적 행위를 가리킨다. 운동 부하는 상대적으로 적은 자원을 소모한다.

사용자로선 본능적으로 느끼고는 있던 부분이었는데, 따로 가리키는 말이 있는지는 몰랐다.

흔히들 사용자의 편의를 위해 페이지 이동을 줄이고 한 화면에서 모든 걸 처리하게 만드는 방향으로 가야 한다는 얘기를 한다. 하지만 운동 부하를 가중시키고 인지 부하를 줄이는 방안도 매우 효과적이다. 토스는 이름, 주민번호, 통신사를 한 화면에 다 때려 넣는 대신, 한 번에 하나씩만 입력하게 만들었다. 이는 물리적인 클릭 횟수(운동 부하)를 늘리는 선택이다. 그런데도 사용자는 이 과정을 더 빠르고 쾌적하게 느낀다. 인간의 뇌는 생각보다 단순해서, 한 번에 처리해야 할 정보가 많아지면(인지 부하) 금세 피로를 느끼고 이탈하기 때문이다.

공식처럼 적용하면 위험하겠지만, 인지 부하 > 시각 부하 > 운동 부하라는 부하의 우선순위는 앞으로 내가 기획안을 만들 때 중요한 체크리스트가 될 것 같다. 이번 역기획 프로젝트 장표를 제작하면서도 느낀 부분인데, (화면 전환이야 발표자가 하지만) 직무스터디 때는 장표를 열댓 장 만들었지만 어떤 정보를 읽어야 할지 모르겠다는 평가를 받았고, 이번엔 72장의 장표를 만들었지만 디자인이나 정보구조에 대한 부정적 피드백은 받지 않았다. 화면 전환이 많으면 그 전환행위 때문에 피곤할 수 있지만 반대로 '지금 이 순간' 필요없는 정보를 그냥 '버리게' 해주기 때문에 보는 입장에서 훨씬 쾌적한 것이겠지.

접근성은 '착한 마음'이 아닌 '구조적 해부'의 영역

토스의 시각장애인 사용성 개선 사례를 읽으면서는 조금 부끄러운 마음이 들기도 했다. 그동안 접근성(Accessibility)을 조금 감상적으로 이해해왔는데, 아티클 속 메이커들의 접근은 굉장히 냉철하고 구조적이었다. 그리고 그 방향성이 사용자들에게 훨씬 효과적인 것 같았다.

시각장애인 사용자들이 스크린리더를 2배속으로 듣는다는 패턴을 발견하고, 문장 끝에 있는 '역할 정보(버튼, 스위치 등)'를 찾기 위해 애쓰는 고충을 파악하는 것은 문제 정의에서부터 상당히 체계적이고 철저한 프로세스가 있었을 것 같다. 단순히 관심을 가진다고 이런 걸 알게 되지는 않겠지. 사용자의 행동 패턴을 데이터와 관찰로 해부한다면 충분히 이런 인사이트를 얻을 수 있을 것이다. 얼굴 인증 과정에서 진행 상태를 소리로 피드백해주거나, 오류 시 터치 없이도 흐름이 이어지게 만든 디테일도 마찬가지다.

이 아티클에서 이런 접근성 문제가 현업에서 어떤 우선순위로 취급되는지 궁금해져서 튜터님께 여쭈었는데, "이걸 하지 않으면 유저가 이탈하는가?"라는 관점에서 본다면 우선순위가 높아질 수 있고, 그렇지 않다면 낮아질 수 있다고 말씀해주셨다. 사실 다르게 보자면 아예 서비스를 사용하지 못하게 될 정도의 불편함은 모두에게서 제거될 수 있지만, 편의성을 개선하는 측면에서는 아무래도 비장애인(+다수의 사용자)을 위주로 하게 된다는 얘기기도 하다.

리소스가 덜 들면서도 임팩트가 큰 개선방향을 생각하는 방법을 좀 연마해야지 되겠다. 리소스가 적게 들수록 의사결정권자들로부터 흔쾌히 허락이 떨어질 확률이 높으니. 특정 사용자군을 배제하지 않는 UX를 설계하려면 C레벨급의 가치관도 중요하겠으나 PM이 하고자 하기만 한다면 어느 정도는 반영할 수 있을 것 같다...라고 희망을 가져본다.

디자인 시스템 : 일관성

나는 웬만하면 모든 작업을 할 때 디자인 시스템과 스타일을 정해놓고 시작한다. 결국 IT라는 것은 계층적인 구조화에서 출발하는 것이라 어떤 '레벨'의 정보를 보여주는 방식을 수정하려면 모든 페이지에서 함께 수정하는 게 논리적으로 맞기 때문이다. (편리하기도 하고.)

그리고 디자인 시스템은 브랜딩의 영역이기도 하다. 자체 폰트를 갖고 있는 우아한형제들이나 러쉬, 현대카드도 그렇지만 구글이나 토스처럼 자체 브랜딩 폰트 없이도 충분히 '어떤 스타일의 구조'를 가지고도 브랜드를 드러낼 수 있다. 

심지어 가맹점 로고를 띄워 놔도 토스 냄새가 나니... 출처 https://www.ishopcare.co.kr/story/toss-pos-fullset-price-review

새로운 기능을 기획할 때마다 매번 버튼의 둥글기(Radius)나 폰트 크기를 고민하는 대신, 이미 약속된 시스템 안에서 블록을 쌓듯 기획할 수 있다면 PM은 훨씬 더 본질적인 로직에 집중할 수 있다. 디자인 시스템은 그 시각적 요소들이 어떻게 유기적으로 작동해야 하는지에 대한 '규칙'을 제공한다. PM은 이 규칙을 숙지함으로써 개발자, 디자이너와의 소통 비용을 획기적으로 줄일 수 있다. 내가 가고자 하는 회사가 디자인 시스템을 어떻게 운영하고 있는지, 혹은 부재하다면 어떤 지점부터 도입을 제안해야 할지 고민해 보는 것도 PM의 중요한 역량이 될 것이다.

정리하며

정답이 없는 길에서 최선의 가설을 세우는 법

결국 요약하면 UX에는 정답이 없다. 심지어 그걸 만드는 방식에도 정답이나 왕도가 없다. 어떤 서비스는 배달의민족처럼 직관적인 UI에 집중하고, 어떤 서비스는 요기요처럼 스크롤 중간의 개인화 추천 UX에 집중한다. 각자가 타깃으로 하는 유저와 비즈니스 목표가 다르기 때문이다.

또 메이커가 진리로 삼는 사용자들조차도 그다지 매순간 합리적이고 똑똑한 사람들이 아니다. (메이커 스스로도 다른 서비스에선 사용자이니 잘 알 것이다!) 대부분의 사람들은 귀찮아하고, 성가셔하고, 아무 생각이 없다. 매 순간 너무 많은 생각을 하도록 진화한 생물이 아니다. (이런 사람들은 세상 살기 힘들 것이다...)

이전에 피그마 강의에서 강사님이 말씀해주신 건데 UI에도 법칙이 없다. 토스트 팝업, 햄버거 버튼, 미트볼 버튼 등등 다양한 요소에 이름이 있지만 어떤 요소들에는 이름이 없고, 또한 어떤 상황에선 반드시 어떤 요소를 사용해야 한다는 규칙도 없다. 어느 정도 규칙이 있는 것들조차도 (다중선택은 체크박스, 단일선택은 라디오버튼 같은 것들) 어떤 합리적인 이유에서 그렇게 된 것이 아니라 '하다 보니 사용자들이 그렇게 해서' 메이커가 맞춰주는 것뿐이다.

사각형 세 개를 일렬로 놓으면 맨 오른쪽 사각형이 가장 질투심이 많게 된다. 근데 또, 위아래 화살표는 좌/우와 큰 연관이 없다. 여기에 어떤 합리적인 이유가 있단 말인가?

네모의 위치에 따라 사람들의 생각이 바뀔까?

결국 PM이 UI/UX를 다룰 때 고려해야 할 가장 본질적인 지점은 ‘우리 유저는 이 시점에서 어떤 감정을 느끼며, 우리는 그 감정을 어떤 비즈니스 지표로 연결할 것인가’에 대한 답을 내리는 (또는 답을 내리기로 정하는) 것이다. 인지 부하를 줄이기 위해 설명을 뺐는데 유저가 길을 잃는다면, 그것은 실패한 기획이다. 이때 필요한 것이 바로 A/B 테스트와 데이터일 것이고.

A/B테스트와 가설 수립

프로덕트 배포 일정을 정하고 A/B 테스트로 순차 배포하는 방법