Lottie Creator: 작동하는 코드로 디자인하기

Motion Tokens

토큰이 늘어날수록 불편해지는 모달

Motion Tokens는 애니메이션의 텍스트, 색상, 위치 같은 속성을 토큰으로 지정하고, 파일을 다시 내보내지 않아도 코드에서 값을 변경할 수 있는 기능입니다.

초기 버전은 빠른 출시를 우선하면서 기본적인 관리 기능이 부족했습니다. 이후 회사가 팀 단위 사용자에 집중하기 시작하면서, 협업에 중요한 역할을 하는 Motion Tokens의 사용성을 개선할 필요가 있었습니다.

직접 사용하며 발견한 문제는 다음과 같습니다.

• 검색 기능이 없어 원하는 토큰을 찾기 어렵습니다.
• 콘텐츠 영역이 좁아 토큰이 많아지면 스크롤을 반복해야 합니다.
• 토큰이 없는 초기 상태에서는 새 토큰을 만들 수 없습니다.
• 다중 선택을 지원하지 않아 토큰을 하나씩 삭제해야 합니다.
• 이름을 변경할 때마다 More 메뉴를 열어야 합니다.

Approach

디자인 가이드 대신 실제 코드로 표 UI 만들기

토큰 생성, 검색, 정렬, 필터, 다중 선택은 하나의 표 안에서 서로 영향을 주는 기능입니다. 모든 상태를 디자인 가이드로 표현하려면 많은 화면이 필요했고, 정적인 화면만으로는 기능들이 함께 작동하는 방식을 확인하기 어려웠습니다.

그래서 AI를 활용해 실제 Creator 코드베이스에서 동작하는 프로토타입을 만들었습니다.

입력 셀을 클릭하면 행 선택이 해제되고, 모든 토큰을 삭제하면 초기 상태로 돌아가는 등 여러 기능이 연결된 동작을 직접 구현했습니다. 개별 화면을 설명하는 대신 하나의 링크로 전체 사용 흐름을 확인할 수 있었습니다.

Collaboration

설명 대신 직접 써보게 했습니다

화면과 가이드로 동작을 설명하는 대신, 프로토타입 링크를 공유했습니다. 주 사용자인 사내 모션 디자이너와 팀원들이 직접 사용해 보면서, 막연한 의견보다 실제 인터랙션과 사용성에 대한 구체적인 피드백을 얻을 수 있었습니다.

프로토타입이 개발의 기준이 되다

프로토타입은 디자인 검증을 위한 코드였기 때문에 제품에 그대로 병합하지 않았습니다.

대신 동작하는 프로토타입과 이를 바탕으로 작성한 개발 티켓을 공유했습니다. 개발자는 각 상태의 동작을 직접 확인하며 구현할 수 있었고, 프로토타입은 디자인 의도를 전달하는 구체적인 참고 자료가 되었습니다.

Design QA

반복되는 디자인 QA를 코드로 줄이기

기존에는 구현 화면과 디자인의 차이를 표시해 개발자에게 전달했습니다. 작은 여백이나 스타일 수정도 여러 번 피드백을 주고받아야 했고, 많게는 다섯 번 넘게 반복하기도 했습니다.

이제는 개발자가 핵심 기능을 구현하면, 디자인 QA에서 발견한 문제를 제가 직접 코드로 수정하고 병합합니다. 개발자는 기능 개발에 집중하고, 저는 인터랙션과 시각적 디테일을 다듬습니다. 여러 차례 반복하던 QA를 한두 번의 수정으로 마무리할 수 있게 됐습니다.

Code Prototypes

직접 만들어 봐야 판단할 수 있는 인터랙션

Motion Tokens 외에도 정적인 화면만으로 동작을 판단하기 어려운 작업이 있었습니다. 이런 경우에는 초기 단계부터 코드로 프로토타입을 만들었습니다.

단축키 모달: 실제 검색 동작 검증하기

단축키 모달은 검색어에 따라 결과와 카테고리가 실시간으로 달라져야 합니다. 사용자가 어떤 단어로 검색하더라도 관련 단축키를 찾을 수 있어야 했습니다. 그래서 실제 단축키 데이터로 검색 기능을 직접 구현해, 다양한 검색어를 입력할 때 인터랙션이 어떻게 이뤄지는지 확인했습니다.

타임라인: 커서의 조작감 다듬기

타임라인에서는 트랙의 보이는 구간과 숨겨진 구간, 잠긴 레이어 등 상태에 따라 커서가 달라집니다. 호버와 드래그에도 즉각적으로 반응해야 합니다.

커서가 어떤 순간에 바뀌어야 자연스러운지는 정적인 가이드만으로 판단하기 어려웠습니다. 직접 드래그하며 상태 전환과 반응을 확인하고, 조작감을 다듬었습니다.

Outcome

프로토타입을 넘어 실제 제품 코드까지

처음에는 디자인을 검증하기 위해 코드를 사용했지만, 지금은 실제 제품 코드와 문서에도 직접 기여하고 있습니다.

플러그인 패널의 작은 글자 크기를 조정하거나 모바일 화면의 경고 메시지를 닫을 수 있도록 개선하는 등, 작은 사용성 문제도 직접 수정합니다.

개발자들도 이 작업 방식을 지원해 주었습니다. 코드 규칙 위반을 푸시 전에 확인할 수 있도록 검증 스킬과 스크립트를 공유해 주었고, 덕분에 제품 코드에 더 안정적으로 기여할 수 있었습니다.

회고

코드를 직접 다룬다고 해서 디자이너가 개발자의 역할을 모두 대신할 수 있는 것은 아닙니다. 하지만 실제로 동작하는 프로토타입을 만들면서 디자인을 설명하고 검증하는 방식이 달라졌습니다.

팀원들이 같은 경험을 바탕으로 의견을 나눌 수 있었고, 개발 이후에도 직접 인터랙션과 시각적 디테일을 수정하며 제품의 완성도를 높일 수 있었습니다.

이제 코드는 디자인을 구현하는 마지막 단계가 아니라, 아이디어를 탐색하고 검증하며 다듬는 과정 전반에서 사용하는 도구가 됐습니다.