새로운 금융 서비스를 기획하고 디자인한다는 것
혼자 정리해보는 UX 디자이너의 회의록
지금부터 한 금융업계 UX 디자이너가 비즈니스 애널리스트, 시니어 엔지니어, 프로덕트 오너와 처음 진행한 스카이프 회의에 대해 정리해보고자 한다.
금융 서비스를 기획한다니
금융 서비스는 정말 다양하고 어렵다. 주식/파생상품 등의 금융 상품에 관련된 서비스부터 관련 시장에 대한 정보를 분석한 리포트를 발행하는 리서치 웹 서비스. 이 범위가 내가 회사에 들어와서 지금까지 파악한 정도다.
그런데 새로운 서비스를 기획하는 데에 참여하게 되었고, 마침 직속 상사와 같은 존재인 루이로랑은 기나긴 휴가를 가버렸다..
그래서 본의 아니게 내가 새로운 서비스를 기획하는 회의에 유일한 UX 디자이너로서 참여하게 되었다.
도대체 무슨 말을 하는 거니
회사에서는 대부분의 회의가 비즈니스 스카이프로 이루어진다. 메일로 서로의 일정을 확인하고, 쉽게 회의를 스케줄링할 수 있다. 처음엔 얼굴을 마주 보고 하는 회의가 아니어서 적잖이 당황했다.. 하지만, 몇 번 회의를 진행해보니 효율적이고 경제적인 것 같다. 다만 상대방의 표정이나 행동을 볼 수 없으니 서로를 이해하기가 좀 더 힘들고, 통신 상태가 좋지 않으면 영어가 잘 안 들린다는 단점들이 있다.
정해진 시간이 되면 스카이프로 회의 창에 다들 모인다. 그리고 인사치레 없이 "Hi, Heesu" 하고 바로 업무에 대한 얘기를 한다.
미국 뉴욕과 몬트리올에 있는 비즈니스 애널리스트, 시니어 엔지니어, 프로덕트 오너와 나.
이렇게 회의를 할 수 있다는 것 만으로 참 신기한 일이다. 듣기엔 멋있어 보일지 몰라도, 한 시간 정도의 회의는 참 힘들었다.
일단, 어떤 내용을 말하는 건지 정확히 이해하기가 힘들었다. 왜 힘들었을까 곰곰이 생각해본 결과, 아래 두 가지 이유로 정리할 수 있다.
그 이유는 첫째, 기획하는 서비스의 사용자인 컴플라이언스 매니저나 부서가 어떤 일을 하는지 정확히 모르기 때문이고, 둘째, 그들 역시 UX 팀과 처음 일해보기 때문에 우리의 프로세스를 정확히 모르기 때문이다.
나도 그들도 서로를 잘 모르니, 새로운 프로젝트를 함께 기획, 디자인, 개발하기가 어려운 것이다. 이는 UX 프로젝트를 진행할 때 흔히 벌어지는 상황이다. 특히나 UX 디자인 팀 내부 프로젝트가 아닌 전혀 분야나 직무가 다른 사람들과 협업을 할 때에 이 문제는 더욱 심각해진다. 자, 그럼 내가 처한 문제를 발견한 것 같으니, 다음 회의 그리고 향후 이 프로젝트에 제대로 참여하기 위해서는 해결 방안을 찾아보고 대비해보자.
1) 금융권에서 컴플라이언스 매니저는 무슨 일을 하는가
Compliance managers work to identify where issues with legality and ethics within a company are taking place, and then will fix these problems quickly and effectively.
'준법감시인'이라고도 불리는 '컴플라이언스 매니저'는 회사의 여러 업무 활동이 법적으로나 윤리적으로 문제가 없는지 진단하고, 이를 빠르고 효율적으로 해결하는 역할을 한다. 특히나 금융권에는 수많은 법적 규제가 존재하기 때문에, 이 역할이 매우 중요하다. 보통 금융상품 부서 안에 각 상품을 담당하는 컴플라이언스 매니저가 있거나, 법무팀, 혹은 리스크 관리팀에 소속되어 일하는 경우가 많다고 한다. 특히 금융권에서는 최근 법적 규제가 심해지면서, 그에 들어가는 비용이 크게 늘어나고 있다. 그래서 컴플라이언스 팀을 CEO/COO/board인 이사회의 직속 부서로 두어 직접 관리하는 경우도 많다. (https://www.mckinsey.com/business-functions/risk/our-insights/a-best-practice-model-for-bank-compliance)
그들은 회사의 전반적인 업무가 '컴플라이언스'에 맞는지 감시하고 이를 보고할 의무가 있다. 그래서 그들은 회사 내의 방대한 양의 빅데이터를 검색하고(query datalake), 이를 목적에 맞는 형태의 파일로 추출하는 과정을 거친다.
여기서 내가 시작한 새로운 프로젝트의 주제와의 연관성을 찾을 수 있었다.
그들의 업무는 복잡하고 어렵기 때문에, UX 디자이너인 내가 일일이 다 파악할 수는 없다. 하지만, 유저에 대해 찾아보고 물어보면서, 그들의 니즈를 대략 이해할 수 있게 되었다.
그들의 니즈는 바로, 회사 내 방대한 양의 빅데이터를 쉽게 검색하고, 그들이 필요로 하는 정확한 데이터 결과를 얻는 것이다. 컴플라이언스 리포트를 작성하기 위해!
2) 그들에게 어떻게 UX 프로세스를 전달할 것인가
사실 우리 회사와 같은 대기업에서는 비즈니스나 매니저 단에서 어떠한 서비스가 필요한지 어느 정도의 니즈가 발견되어 UX 팀으로 업무가 넘어오는 경우가 많다. 그렇기 때문에 프로덕트 오너와 비즈니스 애널리스트들이 직접 페르소나를 설정하고 이를 ppt 템플릿에 정리하는 단계로 UX 프로세스가 시작된다.
그리고 나면 스카이프 회의를 통해 함께 페르소나를 점검하고, UX 디자이너가 향후 프로세스에 대해 설명해준다. 하지만 보통 여기서부터 UX 팀과 PO(Product Owner), BA(Business Analyst), IT(Developer) 간에 문제가 발생한다. 나와 같은 UX 디자이너가 그들에게 왜 UX 리서치를 하는지, 어떠한 방법으로 User flow를 작성해야 하는지, 그들이 짜 온 10여 개의 Persona를 왜 2-3개의 유형으로 분류하고 단순화해야 하는지 등을 명확하고 친절하게 설명하지 않으면, 그들은 우리가 무슨 일을 그리 길게 한다는 건지 이해하지 못한다. 다만, 빨리 비주얼적으로 디자인을 해서 보여주라는 식이다.
이러한 간극을 해결하는 과정은 회사마다, 팀마다, 문화마다 다를 것이다. 나도 한국에서 프리랜서로 클라이언트와 일을 할 때 이런 문제를 많이 겪곤 했다. 그들은 눈에 보이는 디자인만 빨리 원하고, 그 디자인이 나오기까지의 과정을 전혀 모르는 듯했다. 런던의 소시에떼 제네랄에서도 크게 다르진 않다. 금융권에서만 평생 일해온 사람들이 대부분이고, 디자인과는 거리가 먼 사람이 너무 많다. 우리 팀이 도대체 무슨 일을 하는 건지 이해하지 못해 궁금해하는 다른 팀 동료들도 있다.
하지만, 이번 프로젝트를 통해 내가 지금까지 생각해온 UX팀의 분위기와 크게 다른 점이 있다는 사실을 알게 되었다. 바로 상사가 큰 힘이 되어준다는 점이다. 그리고 절대 다른 팀들의 요구에 휘둘려서는 안 된다고 얘기해주는 헤드 매니저가 있다.
UX designers should not always say "yes". Say "No"!
회의를 하거나 이메일로 업무 내용을 주고받다 보면, 나도 모르게 Yes, I can.이라는 말을 자주 쓴다는 것을 깨달았다. 그리고 '신입 주제에 시니어 매니저들에게 어떻게 No라고 하겠어~'라는 마음도 깔려있던 것 같다. 그런데 이 곳의 UX팀 헤드 매니저는 나에게 No라고 말하는 법을 가르쳐주고 있다. 그리고 왜 No인지를 차근히 명확하게 설명해주면서, UX 프로세스로 리드해 나가야 한다. 그렇지 않으면 그들의 이런저런 요구에 방향을 잃을 가능성이 높다. 지난 첫 회의처럼.
다음 회의, 그리고 향후 프로젝트 과정에서 UX 디자이너로서 방향을 잃지 않고, 당당하게 그들에게 No라 말해야겠다. 쉽진 않겠지만.
