인터랙션, 꼭 넣어야 해요?

제품을 인터랙티브하게 개선하면 경험이 더 좋아진다는 것은 모두 알지만, 인터랙션을 구현하는 비용 때문에 엄두가 나지 않기도 하는데요. 인터랙션 디자이너가 토스팀에 합류했을 때도 마찬가지였어요. 빠른 속도를 중요시하는 토스에서 어떻게 팀원들을 인터랙션에 대해 공감하게 하고 슬릭한 제품을 만들어나갈 수 있었는지 소개할게요.

인터랙션 팀의 고민

처음 토스에 인터랙션 팀이 생겼을 때, 인터랙션은 토스팀에게 정말 낯선 개념이었어요. 그전까지 토스 앱에 동적인 화면이 거의 없었기 때문인데요. 토스 사일로에서는 인터랙션에 대해 이런 인식이 많았어요.

“이건 구현하기 어려워요” “이번 실험에는 애니메이션 빼고 갈게요“ “모션이 개발 공수 대비 임팩트가 있을까요?”

토스팀의 온도를 바꿔나가기 위해 왜 이런 인식이 생기게 되었는지 이유를 생각해 봤는데 크게 2가지로 정리했어요.

첫 번째, 인터랙션을 단순히 예뻐지게 하는 도구라고 생각하는 것 두 번째, 인터랙션 분야 특성상 개발 공수가 너무 많이 드는 것

인터랙션을 넣으면 정적인 화면에 비해서 더 예뻐지는 건 사실이지만 심미적인 가치만 강조되는 게 아쉬웠어요. 애플이나 구글의 디자인에서 많이 볼 수 있듯이, 인터랙션은 유저에게 더 명확한 피드백을 줄 수 있고, 유저가 어떤 행동을 해야 되는지 더 직관적으로 보여줄 수도 있고, 화면 안에서 어떤 일이 일어나고 있는지 쉽게 전달할 수도 있거든요. 인터랙션 팀도 토스 앱에 이런 사례를 많이 만들어서, 팀원들의 인식을 변화시키고 싶었어요.

두 번째 이유인 인터랙션을 개발하는 공수가 많이 드는 건 어쩔 수 없는 사실이에요. 그래서 실제로 개발 공수가 적어질 수 있도록 해결책을 만들고자 했어요.

인식 변화를 위한 노력

가장 먼저 ‘인터랙션은 단순히 예뻐지게 하는 역할이다’라는 인식을 바꾸기 위해 인터랙션으로 지표를 개선하는 사례를 많이 만들었어요. 토스 제품 팀은 홈 사일로, 대출 사일로처럼 사일로별로 각 제품을 맡고 있는 구조여서 어떤 화면을 개선하고 싶으면 담당 사일로의 공감대가 필요해요. 그런데 ‘유저의 정성적 경험을 개선한다’, ‘사용성을 개선한다’는 목표로는 설득하기가 쉽지 않았어요. 그래서 사일로에서 가장 중요하게 생각하는 이탈률, 전환율 같은 지표 개선을 할 수 있는 사례를 만들었어요.

*사일로(Silo): 제품을 개발하는 작은 팀

대출 심사 로딩 화면이 그 사례 중 하나인데요. 기존 디자인은 2~30초 동안 로딩 이미지만 보여주는 화면이었어요. 화면의 정보가 가짜 정보라고 생각했던 유저 인터뷰에서 힌트를 얻어, 실시간으로 실제 상품들을 보여주고 신뢰감을 전달한 후 로딩을 기다리는 유저가 늘어나면 대출 실행률도 올라갈 것이라는 가설을 세웠어요.

결과적으로 대출 실행률까진 영향을 미치지 못했지만, 화면 이탈률과 결과화면 도달률 지표가 소폭 좋아졌고 정성적으로도 더 좋은 경험이라는 사일로의 공감대가 있어서 전체 배포할 수 있었어요. 이 외에도 카드 추천, 신용점수, 카드 한도 찾기 등 다양한 제품에서 지표가 오른 사례들을 만들었어요.

항상 지표가 오르기만 했던 건 아니에요. 전체 탭의 사이드바, 신분증 인식 화면, 카드 발급 화면 등 지표 변화가 없어 전체 배포를 하지 못한 적도 많았어요. 지표 변화가 없더라도 유저에게 더 좋은 경험이라는 공감대가 있으면 전체 배포를 하기도 하지만, 운영 상의 이슈로 배포하지 못하고 디자인을 버리게 되는 경우도 있어요. 디자이너로서 속상하지만 실패가 있어 성공한 사례가 하나씩 만들어질 때마다 더욱 값지게 느껴졌던 것 같아요.

두 번째로 앱 전반적으로 인터랙션을 자주 경험할 수 있게 개선했어요. 대출 심사, 카드 추천 등 특정 제품을 개선하는 건 제품을 쓰는 소수의 유저들만 변화를 경험할 수 있으니, 그보다 앱 전반적으로 인터랙션을 더 자주 경험할 수 있게 만들어야겠다고 생각했어요.

그래서 제일 먼저 터치 이펙트를 다듬었어요. 유저가 화면을 누를 때 회색 배경만 나오는 것이 아니라 더욱 눌리는 느낌이 나도록 간단한 모션을 추가했는데요. 공지를 하지 않았는데도 바뀐 모션이 너무 좋다는 토스팀분들 반응이 슬랙에 엄청 올라왔어요. 의도한 대로 유저가 직접 경험하면서 모션의 가치를 느끼신 것 같아 정말 뿌듯하더라고요. 그 후로도 작은 공수로 모션을 쉽게 경험할 수 있는 것들을 계속 찾아 토스 앱 곳곳에 작은 모션들을 하나씩 적용해 나갔어요.

개발 공수를 줄이기 위한 노력

첫 번째, 개발 공수를 줄이기 위해 모션의 눈속임 효과를 많이 사용했어요. 홈 화면에서 계좌를 정리해 주는 기능을 만들었는데요. 처음 개발자분들께 디자인을 보여드렸을 때, 리스트가 촤라락 들어오는 모션이 현재 구조에서는 절대 만들 수 없고, 공수도 가늠이 안된다는 부정적인 반응이셨어요.

그래서 과거에 본 Google Material 가이드를 참고해서 대안을 만들었어요. 실제로 리스트에 모션을 주는 게 아닌 홈 위에 새 레이어를 띄우고 모션으로 마치 한 화면인 것처럼 눈속임 효과를 주는 방식이었죠. 이런 방향이라면 개발자 분들도 충분히 할 수 있을 것 같다는 반응으로 바뀌어서 개발을 진행할 수 있었어요.

두 번째, 더 많은 프로덕트 디자이너와 개발자들이 어느 화면에서나 쉽게 인터랙션을 적용할 수 있도록 인터랙션 시스템을 만들었어요. 먼저 PD분들이 쉽게 모션을 만들 수 있도록 미리 정해놓은 몇 가지 모션들을 컴포넌트(Component)로 만들었어요. 무언가가 화면 안에 들어오고 나갈 때, 강조할 때, 글자에 모션을 넣을 때 등 각 상황에 맞는 다양한 컴포넌트들을 만들어서 프로덕트 디자이너분들이 Framer에서 쉽게 사용할 수 있게 했어요.

그런데 이 인터랙션 컴포넌트들을 개발하려니까, iOS, Android, Web 각각 모션 스펙 용어나 동작 방식이 너무 다르더라고요. 그래서 저와 각 개발자분들이 모여서 모션을 정의할 수 있는 플랫폼 공통 스펙을 만들기 시작했어요.

우리는 모션의 easing을 bezier랑 spring 두 가지를 사용하자. 하나의 타겟엔 하나의 모션만 붙일 수 있다는 규칙을 만들자. 여러 타겟에 모션을 붙일 때 쓸 ‘타임라인’이라는 개념을 만들자.

이런 식으로 복잡한 모션까지도 표현할 수 있는 플랫폼 공통의 언어를 만들어 나갔어요.

이런 논의를 매주 꾸준히 하면서 약 1년 만에 토스만의 인터랙션 개발 라이브러리, Rally가 만들어지게 됐어요.

이제 토스에서는 프로덕트 디자이너분들이 개발자에게 프로토타입(prototype) 영상이나 레퍼런스만 드리고 ‘똑같이 해주세요’, ‘이런 느낌으로 해주세요’처럼 모호하게 말하지 않아요. Framer에서 인터랙션 컴포넌트로 모션을 만들면, 개발자가 인스펙터에서 바로 랠리 코드를 확인할 수 있죠.

랠리는 스펙 하나하나 논의하며 만든 플랫폼 공통 언어이기 때문에 어떤 모션이든 개발 가이드를 명확하게 쓸 수 있고 QA할 때도 개발자랑 디자이너 간 소통이 훨씬 쉬워졌어요. 가끔 iOS, Android 개발자분들이 서로 랠리 코드를 공유하면서 논의하시기도 하더라고요.

인터랙션의 시스템화를 시도해보고 싶으시다면 자주 사용하는 easing 값을 토큰으로 만드는 것부터 추천드려요. 맨 처음에 했던 일은 저희가 자주 쓰던 easing 값을 모두 모아서 bezier.expo, spring.quick처럼 이름을 지어주는 일이었는데요.

개발에서도 토큰을 똑같이 정의해 두면 ‘여기는 spring.quick으로 해주세요’, ‘여기는 좀 빠른 것 같은데 spring.basic으로 바꿀 수 있을까요?’처럼 공통의 언어로 대화할 수 있게 되거든요. easing 토큰화부터 먼저 해본다면 점차 모션도 어떤 식으로 시스템화하는 게 좋을지 아이디어가 떠오르실거예요.

시스템 전파를 위한 노력

사실 시스템은 만들었다고 끝이 아니더라고요. 개발 공수를 훨씬 줄여줄 수 있는 시스템을 만들어놨지만, 사일로분들의 사용이 처음에는 저조했어요.

그래서 #animate-noti 라는 채널을 만들어서 직접 발품을 팔았어요. 회사의 모든 슬랙 채널에서 인터랙션, 모션, 랠리 등 팀과 관련된 단어를 언급하면 자동으로 이 채널에 모아지게 했는데요.

처음엔 채널에 ‘여기 인터랙션 잡아봤는데 공수 많이 들까요?’와 같은 글이 많이 올라왔어요. 그럴 때 스레드에 불쑥 찾아가서 ‘인스펙터에 랠리 코드대로 하시면 바로 적용돼요’라고 답변드렸죠. 많은 분들이 ‘이렇게 쉽게 적용할 수 있는지 몰랐다, 바로 적용해 보겠다’ 말씀해 주시더라고요.

매일 모니터링하고 팀원들과 소통하니 인터랙션 시스템이 빨리 전파되는게 체감됐어요. 점점 #animate-noti 채널에 인터랙션 ‘개발 너무 편해졌다’, ‘랠리 너무 좋다’와 같은 긍정적인 피드백이 자주 올라왔어요.

이런 노력들로 더 많은 토스팀분들이 인터랙션에 스며들 수 있도록 했는데요. 과정이 쉽진 않았지만 인터랙션과 관련된 유저들의 반응도 확인하고 지표도 올라가는 걸 보면서 큰 보람을 느끼고 있어요. 인터랙션 또는 디자인 시스템 전파와 관련된 고민을 가진 디자이너 분들께 도움이 되었길 바랍니다.

Q. 인터랙션 디자이너가 되려면 어떤 역량을 갖추어야 하고 무슨 프로그램을 다룰 수 있어야 하나요?

동적인 디자인만이 낼 수 있는 임팩트를 고민하는 역량이 중요한 것 같아요. 정적인 UI로도 전달할 수 있는 가치라면 인터랙션은 Good to have가 되거든요. 인터랙티브하게 표현했을 때 어떤 임팩트를 낼 수 있는지 설득할 수 있는 능력이 필요해요.

또 인터랙션은 구현이 까다로운 분야인 만큼, 내 디자인이 정확하게 구현될 수 있도록 개발 가이드를 잘 만드는 것도 중요한 역량이에요. 인터랙션 디자이너의 시스템적 사고 역량에 따라 개발 가이드의 퀄리티가 달라지고, 그만큼 개발자의 효율과 구현 퀄리티도 달라진다고 생각해요.

토스는 변수, 햅틱 등의 기능이 꼭 필요해서 Protopie를 주로 사용하는데, 가만히 보기만 하는 영상이 아니라 실제 터치에 반응하는 인터랙션을 만들 수 있는 Hi-Fi 프로토타이핑 툴이면 뭐든 괜찮아요.

Q. 세션에서 PD분들이 언급되는데 인터랙션 디자이너와 PD의 업무 차이는 무엇인가요?

토스에서 PD분들은 각 사일로에 소속되어 있고, 사일로 제품의 비즈니스 목표를 달성하고 사용성을 수호하기 위해 그래픽, 인터랙션 등을 자유롭게 활용하며 제품 설계를 해요.

인터랙션 디자이너도 동일한 목표를 가지고 있지만 특정 사일로가 아닌 인터랙션팀에 속해있고, 다양한 사일로들과 협업하며 동적인 디자인으로 더 큰 임팩트를 낼 수 있는 문제들을 주로 해결한다는 차이가 있어요.