플랫폼 디자이너가 효율을 만들어내는 법

토스에는 디자인 플랫폼 팀이 있고, 그 안에 플랫폼 디자이너라는 직군이 있어요. 플랫폼 디자이너는 무슨 방법을 써서라도 메이커의 디자인 작업 과정의 비효율을 효율화하는 사람이에요. 디자인 시스템을 만들기도 하고, 디자인 툴을 바꾸기도 했죠.

오늘 소개해드릴 프로젝트는 툴을 바꾸면서 새로운 환경에 맞게 작업 과정을 효율화했던 작업이에요.

극단적인 효율화로 미친 생산성 만들기

제가 처음 토스의 플랫폼 디자이너로 입사했을 때는 스케치에서 프레이머로 이사가 진행되고 있었던 시점이었어요. 스케치에 있는 컴포넌트를 프레이머로 옮겨야 했는데, 그중에 플로우차트를 옮겨보기로 했어요. 플로우차트는 버튼을 누르면 어느 화면으로 가는지, 사용자의 상황에 따라 어떤 화면을 그려줄 것인지 등, 화면끼리의 관계나, 흐름을 표현하기 위해서 쓰이는 도구예요.

스케치와 프레이머의 가장 큰 차이점은 스케치는 드로잉 기반의 툴이고, 프레이머는 코드 기반의 툴이라는 거예요. 사실 이런 차이를 고려하지 않고, 그냥 스케치에 있는 플로우차트를 그대로 옮길 수도 있었죠. 하지만 저는 여기서 극단적인 효율화를 추구하고 싶었어요. 둘은 전혀 다른 툴이기 때문에, 스케치에서 사용하는 방식 그대로 프레이머에 옮기는 것은 큰 의미가 없다고 생각했거든요. 툴에 특성에 맞게 코드를 활용해서 가장 효율적으로 사용할 수 있는 방법을 적용하고자 했어요.

더하기가 아닌 곱하기

스케치에서 쓰던 플로우차트는 위 이미지처럼 여러 가지 형태의 화살표 중 지금 필요한 형태의 화살표를 찾아서 선택한 다음 대지에 넣는 방식이었어요.

사실 프레이머에 스케치에서 사용하던 것들을 그대로 옮겨올 수는 있었어요. 하지만 그렇게 만든다면, 스케치에서 쓰던 사용 방식을 그대로 차용해야 했죠.

만약 스케치에서 사용하던 방식을 그대로 프레이머에 옮기게 된다면, 프레이머에는 스케치와 달리 좌우 반전이나 상하 반전의 기능이 없었기 때문에 일자와 ㄱ,ㄴ 모양만 해도 관리해야 하는 옵션이 1+1+1+1…. 이렇게 늘어나면서 스케치보다도 가짓수가 많은 24개가 됐어요.

더구나 프레이머는 스케치처럼 드롭다운을 단계별로 나눌 수도 없었기 때문에 모든 화살표를 한 번에 보면서 골랐어야 했어요. 저는 이렇게 필요한 옵션을 하나하나 추가하는 방식을 더하기 방식이라고 불렀어요.

프레이머에서의 디자인 컴포넌트로 그리게 되면 모양과 색을 한방향으로 쌓아서 고르게 돼요, 일자와 ㄱ,ㄴ모양만 해도 관리해야 하는 가짓수가 8*3 = 24개가 돼요

여기에 화살표를 그리는 데에 당연히 있을 법한 ㄷ이나 , Z 모양의 화살표를 추가하게 된다면, 모양의 선택하는 데에 있어서 걷잡을 수 없이 복잡해질 것이 눈에 보였어요.

화살표 위 아래 방향을 바꾸고 싶은데.. 반대 방향이 어딨더라… 아! 지금 쓴것과 반대 모양의 화살표를 180도로 뒤집어야 하는구나!

그냥 위아래가 바뀐 화살표를 쓰고 싶었을 뿐인데 왜 다른 화살표를 써야 할까? 의문이 들었죠. 우리가 좀 더 상식적으로 플로우차트를 쓰기 위해서는 더하기 방식이 아닌 곱하기 방식을 써야 했어요. 1+1+1…+1=24가 아니라 4x2x3=24 이런식으로요.

곱하기 방식으로 그리기 위해 총 28가지 화살표를 돌려보거나 반전했을 때 공통으로 겹치는 가장 기초의 형태를 찾았고, 단 4가지의 타입으로 화살표의 형태를 정의할 수 있었어요.

가장 기초의 형태를 찾기 위해 시도해봤던 흔적들

그렇게 해서 나온 4가지 형태

그 외에도 색상만 바꾸고 싶다거나, 레이블을 화살표 선 위에 올려놓고 싶다거나, 선의 스타일을 바꾸고 싶거나 하는 당연히 되어야 할 것만 같은 옵션들도 점차 추가해가면서 하나의 컴포넌트로 아래와 같은 수많은 옵션을 그릴 수 있도록 만들었어요. 곱하기 방식을 사용했기 때문에 지속적인 확장이 가능했죠.

하지만 곱하기 방식으로 옵션을 만들어 낸다는 것이 쉽지만은 않았어요. 하나씩 그리는 더하기 방식이 아니다 보니, 예상치 못하게 동작하는 모습이 나오기도 했기 때문이에요.

가장 의도와 다르게 나왔던 옵션은 레이블이었어요. 상하 반전, 좌우 반전, 90도 회전으로 방향 바꾸기 등등 어떤 조작을 해도 화살표는 이미지이기 때문에 문제가 없었지만, 레이블에는 텍스트가 들어가기 때문에 텍스트는 반전도, 회전도 하면 안 됐어요.

반전은 화살표를 반전시킨 이후에, 텍스트박스를 다시 반전시키면 정상적으로 보이게 됐기 때문에 쉽게 해결할 수 있었지만, 회전과 반전을 함께 하니 레이블의 위치가 예상과 달리 움직이게 되면서, 정확한 레이블의 위치를 찾을 수 있는 규칙을 만들어가며 문제를 해결했어요.

우린 깐부… 아니 디자이너잖아

화살표 사용 방식은 잘 정의했지만, 그것을 직접 구현할 때 또 문제가 생겼어요.

곱하기 형식을 적용하기 위해선 코드로 컴포넌트의 모양을 그려줬어야 했는데요. 코드를 단순하게 짜면, 쉽게 만들 수 있지만, 모서리가 뾰족하게 각져있는 형태의 보기 불편한 플로우차트를 그릴 수밖에 없었어요.

하지만 저는 이런 플로우차트로 화면을 그린다는 건 참을 수가 없었고, 심미적으로 아름다운 플로우차트를 그리기 위해서 아래와 같은 문제를 해결해 나갔어요. 마름모 꼭짓점을 둥글게 만들거나, 화살표 모양을 둥글게 만들고, 화살표와 선이 만나는 지점이 둔탁해 보이지 않게 모양을 바꾸기도 했어요.

PO까지 즐겨 쓰는 플로우차트

이렇게 사용성과 심미성을 챙긴 플로우차트는, 원래는 디자이너분들을 위해 만들었던 것이지만 유려한 결과물이 되어 다른 직군까지도 쓰게 되었어요. 토스의 몇몇 제품은 아주 복잡도가 높아요. 화면 하나를 그리는 것보다 그것들이 어떻게 연결되어있고 어떤 상황에 쓰이는지 구조도를 그리고 메모하는 게 중요한 제품들이 있죠. 그런 제품을 다룰 때 플로우차트가 매우 큰 역할을 했어요.

위 이미지가 좋은 사례인데요. 일부분만 캡쳐해도 얼마나 복잡한 제품인지 느껴지시죠? 플로우차트가 없었다면, 또 있다해도 불편한 사용성을 갖고 있었다면 이 제품을 설명하기 위해서 정말 많은 시간을 허비해야 했을 거예요. 그런데 플로우차트를 개선한 후에는 심미성은 물론 사용성도 매우 좋아졌기 때문에 프레이머에 익숙하지 않은 PO도 이런 결과물을 만들 수 있었어요.

앞으로도 플랫폼 디자이너로서 작은 단위의 효율성도 꼼꼼하게 챙겨가며 큰 임팩트를 내려고 해요. 기대해주세요!