최근 팀에서 제품 전반의 사용성을 점검하고 피드백을 정리하는 시간을 가졌다. 이때 디자인 시스템과 관련된 부분은 내가 이야기했다.
처음에는 화면마다 버튼 모양이나 padding이 조금씩 다르고, hover 상태가 통일되지 않은 정도의 문제라고 생각했다. 그런데 실제 제품을 하나씩 눌러보니 버튼을 눌렀을 때 동작한 건지 알기 어렵거나, 로딩 중인데도 계속 누를 수 있거나, 오류 메시지가 조작한 위치와 전혀 다른 곳에 나타나는 경우가 있었다. 같은 역할의 버튼인데도 화면마다 pressed, loading, disabled 상태가 다르게 구현된 경우도 있었다.
결국 단순히 디자인이 조금씩 다른 문제가 아니라, 사용자가 현재 상태를 이해할 수 있는가에 대한 문제에 더 가까웠다.
디자인 시스템과 인터랙션
이전에는 디자인 시스템이라고 하면 컬러, 타이포그래피, 간격과 공통 컴포넌트를 맞추는 일을 먼저 생각했다. 하지만 이번에 정리하면서 인터랙션 피드백이나 보조기술과도 연결되는 부분이 많다는 걸 알게 되었다.
버튼 하나에도 기본, hover, pressed, focus, loading, disabled 상태가 필요하다. 눈에 보이는 아이콘 크기와 실제로 누를 수 있는 영역도 따로 봐야 하고, Web과 iOS, Android의 기준도 조금씩 달랐다. 토스트가 화면에 보이는 것과 스크린 리더에 상태가 전달되는 것도 별개의 문제였고, 모션 역시 reduced motion 설정에서는 어떻게 대체할지 정할 필요가 있었다.
이런 기준이 공통 컴포넌트에 없으면 새 화면을 만들 때마다 같은 결정을 다시 하게 된다. 겉으로는 비슷해 보여도 실제 동작이 계속 달라지고, 필요한 상태가 누락되는 이유도 여기에 있었던 거 같다.
그래서 다음 스프린트에서는 나는 디자인 리팩토링을 하고, 팀장님은 코드 리팩토링을 하는 방향으로 역할을 나누기로 했다. 다만 실제로 진행해 보니 두 작업을 완전히 따로 볼 수는 없었다.
Figma에서 상태와 구조를 정해도 focus, navigation, loading 같은 부분은 실제 코드에서 다시 확인해야 했다. 반대로 코드에서 공통 컴포넌트를 만들더라도 무엇을 공통 기준으로 둘지 디자인 쪽에서 정리되지 않으면 또 다른 예외가 생겼다. 역할은 나누었지만 서로 계속 확인하면서 진행해야 하는 작업이었다.
일주일이면 될 줄 알았는데…
처음에는 디자인 시스템을 전체적으로 정리하는 데 일주일 정도면 충분할 거라고 생각했다 ㅠㅠ 이미 컬러와 타이포그래피 토큰도 어느 정도 있었고, Figma 컴포넌트도 존재했기 때문에 기준을 맞추고 빠진 상태를 보완하면 될 거 같았다.
하지만 실제로 확인해 보니 코드, 디자인 문서, Storybook과 Figma가 서로 조금씩 다른 기준을 가지고 있었다. 토큰을 사용하고 있어서 얼핏 보면 통일된 것 같아도, 같은 역할의 UI가 서로 다른 컴포넌트로 구현된 경우도 있었다.
Figma에 공통 source component를 만드는 것과 기존 화면의 instance가 그 source를 실제로 사용하도록 연결하는 것도 별개의 작업이었다. 아이콘도 canonical source를 만드는 것으로 끝나는 게 아니라 기존 Production 컴포넌트가 무엇을 참조하는지 확인하고, 교체한 뒤 Light/Dark와 크기, 터치 영역, 상태별 상속까지 다시 봐야 했다.
첫 주에는 컬러, 타이포그래피, spacing, radius 같은 Foundation과 motion, 접근성 기준을 정리했다. 이후 내비게이션, 프로필, 설정, 글쓰기, 검색, 알림 컴포넌트를 Production Foundation 기준으로 다시 연결하기 시작했다.
지금은 공용 primitive와 프로필 및 관계 컴포넌트, 아이콘 시스템과 interaction state를 확인하고 있다. 내비게이션을 정리하는 중이고 알림, 게시물, 컴포저와 미디어 입력, 설정, 프로필 편집도 남아 있다.
일주일이면 될 줄 알았는데 지금 2주째 진행하고 있다… 그리고 아직 안 끝났다.
많이 만드는 게 디자인 시스템은 아니었다
중간에 멘토링을 받으면서 생각이 바뀐 부분도 있었다. 처음에는 빠지는 값이 없도록 typography나 spacing 단계를 충분히 만들어 두려고 했다. 그런데 실제 사용량보다 선택지가 많으면 오히려 어떤 값을 써야 하는지 판단하기 어려워진다는 피드백을 받았다.
그래서 사용하지 않는 typography를 정리해 14개에서 9개로 줄였고, spacing과 radius도 실제로 사용하는 값 위주로 축소했다. 컬러 역시 단계 수를 맞추기 위해 필요 없는 값을 추가하지 않기로 했다.
디자인 시스템은 모든 경우를 미리 만들어 두는 것보다 반복되는 결정을 줄이고, 지금 제품에 필요한 기준을 알아보기 쉽게 만드는 데 더 가까운 거 같다. 공통 컴포넌트도 무조건 많이 합치는 게 정답은 아니었다. 비슷하게 보여도 사용 맥락이나 정보량, 접근성 요구가 다르면 별도로 두는 게 나을 수 있었다.
이번 회고
이번 작업이 예상보다 길어진 건 처음에 결과물만 보고 범위를 추정했기 때문인 거 같다. 토큰을 정리하고 컴포넌트를 수정하는 시간은 생각했지만, 현재 상태를 조사하고 source와 consumer를 연결한 뒤 여러 화면과 상태에서 검증하는 시간은 충분히 고려하지 못했다.
다음에 비슷한 작업을 계획한다면 Inventory, 기준 정리, 코드 반영, Figma migration과 실제 화면 검증을 하나의 큰 작업으로 묶지 않고 나눌 필요가 있다. 디자인과 코드의 담당을 나누는 것뿐만 아니라 두 작업이 어디에서 만나고 무엇을 서로 확인해야 하는지도 미리 정해야 할 거 같다.
아직 전체 작업이 끝난 건 아니지만, 적어도 디자인 시스템을 단순히 예쁜 컴포넌트 모음으로 생각하지는 않게 되었다. 사용자가 동작의 결과를 이해할 수 있게 하고, 같은 결정을 계속 반복하지 않도록 만드는 기준에 더 가까웠다.
정리
- 디자인 시스템은 인터랙션 피드백과 접근성 문제에도 연결되어 있다.
- 규칙과 컴포넌트는 많을수록 좋은 게 아니라 실제 사용에 필요한 만큼 있어야 한다.
- Figma source를 만드는 것과 실제 화면이 해당 source를 사용하도록 연결하는 건 별개의 작업이다.
- 디자인 리팩토링과 코드 리팩토링은 역할을 나눌 수 있지만 완전히 분리되지는 않는다.
- 다음에는 조사, 기준 정리, migration과 검증 범위를 나누어서 estimate 하기.
- 그리고 일단 남은 작업 끝내기…