[Interview] 토스뱅크 디자이너가
말해주는 ‘UT’

Depromeet(디프만)

Published in

Depromeet

7 min readJun 26, 2024

안녕하세요. 디프만 15기 운영진입니다.

이번에는 토스뱅크 디자이너이자 디프만 14기 회장이셨던
성경님과 UT(사용성 테스트)에 관해 이야기 나눠봤어요.

오늘 성경님을 모신 이유는?

디프만은 사용성 검증을 위해 10기부터 꾸준히 UT 세션을 진행해왔어요. UT세션 덕분에 개발에 들어가기 전 놓칠 수 있는 문제점을 미리 발견하고 한 번 더 사용자 경험을 고려한 서비스를 만들 수 있었죠.

15기 운영진은 이번에 UT 세션을 기획하면서 현재 디프만의 UT 세션에 어떤 한계가 있는지, 개선할 점이 무엇인지 궁금해졌어요. 이에 대한 답을 찾기 위해 14기 UT 세션 기획 경험이 있는 성경님에게 도움을 요청했습니다. 이번 인터뷰에서 얻은 인사이트를 바탕으로 다가오는 UT 세션을 더 알차게 준비해보려고해요.

그럼, 지금부터 성경님의 이야기를 들어볼까요?

안녕하세요. 성경님 ! 간단한 자기소개 부탁드려요

안녕하세요. 저는 디프만 14기 회장이자 토스뱅크 디자이너 박성경입니다.

정확히 말하자면 저의 직무는 TPD (Tools Product Designer)인데요, 토스 내 동료분들이 일을 더 잘할 수 있도록 돕기 위한 제품들을 만들어요.

사용자를 위한 토스 앱을 만드는 PD(Product Designer)분들과 달리 효율적인 업무를 위해 최적화된 워크플로를 만들고 개선하는 것이 저의 역할이에요.

말로만 듣던 토스의 UT 문화 너무 궁금해요! 실제로 UT를 많이 하나요?

많은 분이 토스뱅크의 UT 문화에 대해 궁금해 해주시는 것 같아요.

제가 경험한 토스뱅크는 확실히 UT가 프로세스 곳곳에 녹아있고 당연한 문화로 여겨져요. TPD의 경우 PD처럼 실험을 자주 하지 않지만 입사 시 UT에 관련된 온보딩을 받고, 원하는 경우 언제든 UT를 진행할 수 있어요. 또 UT 준비, 진행 과정에서 어려움이 있는 경우 리서처팀에게 도움을 받을 수 있어 수준 높은 UT를 진행할 수 있어요.

온보딩을 받으며 이 시점에 UT를 왜 하는가를 생각해 보는 게 중요하다는 것을 배웠어요. 자세한 내용은 뒤에서 더 말씀드릴게요. 토스의 UT 온보딩은 토스 블로그에 관련 내용이 자세히 설명되어 있으니 읽어보셔도 좋을 것 같아요.

이전의 UT와 토스뱅크에서 직접 UT를 진행해 본 후 느꼈던 차이가 있을까요?

방식 자체의 차이보다는 ‘동기’에 차이가 있다고 느꼈어요.

학생 때는 포트폴리오를 어필하기 위해서, 또는 디자이너 프로세스 중에 무조건 UT가 있어야 한다는 이유로 많이 시도했어요.

그런데 오히려 현업에서 일해보니 모든 프로젝트에 UT가 필요한 건 아니라고 생각이 들더라고요. 시간이 곧 비용이기 때문에 정말 효과가 있을 거라는 확신이 들 때 시도하는 것 같아요. 우리 제품이나 기능을 더 고도화하는 데 도움이 될 거라는 게 명확할 때요. 물론 디자이너가 UT를 하겠다고 했을 때 동료들이 거부하거나 의문을 제기하지는 않아요. 하지만 스스로 꼭 필요한지를 항상 생각하는 것이 지금의 저와 학생이었던 저의 차이인 것 같아요.

성경님의 UT 경험을 소개해 주실 수 있나요?

최근에 어드민 mvp를 배포한 후, 제가 의도한 대로 잘 사용하고 계시는지, 일의 효율화를 위해 더 개선할 지점이 있을지 알아보기 위해 UT를 진행했어요. 어떻게 진행했는지 소개해 드릴게요.

처음에는 실험할 기능을 정했어요. 어드민은 워낙 많은 기능이 있기 때문에 모두 테스트할 수 없거든요. 이때 임팩트를 최우선으로 고려하는 편이에요.

[토스뱅크에서 결제를 관리하는 어드민]으로 예를 들어볼게요. 해당 제품으로 매일 업무하는 토스 동료분들이 가장 많이 사용하는 기능이 무엇인지를 살펴보니 “주문관리”과 “정산관리”였고 이때 실제 금액을 하나하나 수기 입력하고 있다고 가정해 봐요. 매일매일 사용하는 기능을 찾고 비효율적으로 반복하는 사용 패턴을 개선한다면 같은 시간을 들여도 더 큰 임팩트를 낼 수 있겠죠? 이런 식으로 기능의 중요도와 사용 빈도를 기준으로 임팩트를 고려하며 실험해 볼 기능들을 정할 수 있어요.

실험할 기능을 선정한 후에는 어떻게 하시나요?

UT로 확인해 보고 싶은 범위가 명확해진 후에는 잘 볼 수 있도록 task를 짰어요. 사용자가 UT 상황에 몰입할 수 있도록 실제 업무와 유사한 환경을 만들기 위해 노력을 하는 편인데요, 테스트를 위한 자리가 아닌 평소에 사용하던 패턴을 보기 위한 것이기 때문이에요. 옆자리 동료지만 처음 뵙는 자리이기 때문에 초반 아이스브레이킹도 시도했어요.

이후 중요한 것은 UT를 했다는 행동 자체만으로 만족하면 안 된다는 것이에요. 저도 그랬듯이 많은 분이 UT를 했다는 사실만으로 만족할 수 있다고 생각해요. 하지만 UT의 본질은 결과를 잘 분석하고 개선에 반영하는 것이라는 것을 잊지 않았으면 좋겠어요. (분석할 때쯤 되면 세부 사항이 기억나지 않을 때도 많기 때문에 촬영하는 것도 추천해요)

UT를 진행하며 어려웠던 부분도 있었나요?

그럼요. 한 번은 UT를 하러 갔는데, UT 대상자들이 화면을 조작하지 않고 대답만 하신 적이 있었어요.

UT라는 것에 익숙하지 않은 직군에 종사하시는 분들이었고 “인터뷰”라고 소개했기 때문에, 그분들은 질의응답의 시간으로 알고 있었던 것이죠. 또한 매일 사용하는 업무 툴을 다루다 보니 평소에 불편했던 점을 적극적으로 말씀하시더라고요. 제가 테스트 환경을 제대로 조성하지 못했음을 깨달았어요. 이런 경우 voc을 받는 시간과 테스트하는 시간을 명확히 구분하고 알려드리면 해결되곤 해요.

테스트 중 유저의 행동은 예상치 못한 방식으로 흘러갈 수 있어서 상황마다 적절한 꼬리 질문을 미리 준비해 놓아야 해요. 예상대로 행동하지 않는 사용자를 만났을 때 당황하지 않고 잘 대처하는 것이 UT의 성패를 좌우한다고 생각해요. 어떤 이유로 그렇게 행동했는지, 어떤 것을 기대하고 클릭했는지 등 사용자는 습관처럼 하던 일에 질문을 받고 생각하게 되는데 숨겨진 의도를 잘 끄집어내야 해요.

디자이너들이 UT 경험이 많지 않으면 실시간으로 적절한 꼬리 질문을 하는 것이 어렵다고 생각해요. 꼬리 질문이 어떤 대답을 유도하는 뉘앙스이면 안 되거든요. 저는 토스 커뮤니티 내 리서치 팀이 가이드로 제공해 주신 적절한 꼬리 질문의 예시를 많이 활용했어요.

디프만 운영진들이 “이렇게 꼬리 질문을 하면 좋다”라는 예시 질문들을 많이 만들어 놓으면 팀원들에게 도움이 될 것 같아요.

UT를 준비하는 디프만 15기 멤버 분들께 해주고 싶은 말이 있다면?

UT는 생각보다 고려해야 할 것도 많고, 일정 시간을 투자해야 하는 부분도 맞아요. UT를 할 때 왜 하는지, UT 말고 다른 방법들도 있는데 왜 이 방법을 선택했는지, 어떤 목적으로 설계했는지, 무엇을 보려고 했는지를 명확히 한다면 분명 임팩트 있는 UT를 진행할 수 있을 거예요.

리크루팅 시 디프만 내부 사람 외에도 컨택해보면 좋을 것 같아요. 디프만 내부 사람들은 결국 디자이너, 개발자들이기 때문에 디지털 수용도가 높거든요. 오히려 실제 대상자와 유사한 조건의 사용자를 찾는 게 중요해요. 예를 들어 러닝 기록을 위한 제품을 만든다고 할 때 모두가 당연히 뛰어본 경험은 있겠지만 ‘일주일에 3번 이상, 기록을 아카이빙하는, 30대 직장인’과 같은 뾰족한 세그먼트가 더 많은 인사이트를 줄 거예요. 그래서 디프만 내에서 UT를 2명 정도 진행했다면, 그 외에도 대외적으로 2명 정도를 찾아서 시도해 보는 것도 좋을 것 같아요.