디자인 시스템 개편의 시작 두 번째
2. 컴포넌트 재정의 및 개선
컬러에서 시작된 문제,
컴포넌트에서도 드러나다
컬러 시스템을 역할과 강도 기준으로 정리하면서,
한 가지 사실이 더 분명해졌다.
이 문제는 색상에만 국한된 것이 아니었다.
컴포넌트 역시 비슷한 구조를 가지고 있었다.
기존에 작업되어 있던 컴포넌트들은 존재했지만,
각 컴포넌트가 어떤 역할을 전제로 사용되는지에 대한 기준은
명확하게 정리되어 있지 않았다.
그 결과, 컴포넌트를 두고도
이게 사용자의 행동(Action)을 유도하는 요소인지
아니면 정보를 전달하는 (Info) 요소인지
작업하는 사람에 따라 다르게 해석될 여지가 있었다.
기존 컴포넌트 일부분컴포넌트마다 Interaction, Size 등
다양한 Variant는 정의돼 있었지만,
그 Variant들이 어떤 역할을 기준으로
설계된 것인지에 대한 설명은 충분히 드러나지 않았다.
결국 컴포넌트 선택은
구조가 아니라 개인의 판단에 의존하게 되었고,
디자인 시스템을 처음 접하는 입장에서는
이해하는 데 많은 시간을 할애해야 하는 구조였다.
따라서 컴포넌트를 단순히 나열하는 방식이 아니라,
컴포넌트의 역할을 먼저 정의하고
그 역할에 맞게 Variant와 명칭을 정리하는 방향으로
컴포넌트 개선을 진행하기로 했다.
컴포넌트 재정의 및 개선
개선한 컴포넌트 중에서는
버튼 컴포넌트를 기준으로 이야기를 풀어보았다.
버튼 컴포넌트를 새롭게 정의할 때
가장 먼저 정리한 것은 버튼의 역할(Role)이었다.
기존에는 버튼처럼 보이는 요소라도
행동(Action)을 유도하는지,
단순히 정보(Info)를 전달하는지가
구조만으로는 명확하지 않은 경우가 많았다
따라서, 사용자의 행동을 전제로 하는 버튼을
‘Action Button’으로 별도 정의하고,
컴포넌트 상단 타이틀에서부터
해당 버튼의 목적이 바로 드러나도록 설계했다.
그 결과, 디자인 단계에서
이 버튼이 실제로 눌러야 하는 요소인지를
혼동 없이 판단할 수 있는 기준이 생겼다.
개선한 Action Button 컴포넌트내가 작업하던 서비스는
SaaS(Web)와 모바일 App(AOS/iOS)을 동시에 운영하는 구조였다.
그래서 버튼 컴포넌트 상단에는
이 요소가 AOS / iOS / Web 중 어떤 환경에서 사용되는지를
먼저 표기했다.
같은 버튼처럼 보여도 플랫폼별로
사용 가능 여부
구현 규칙
이 달라지는 경우가 있었다.
(버튼뿐만 아니라 다른 컴포넌트도 역시 동일하다.)
컴포넌트 내부에서 플랫폼별 사용 범위를 명확히 구분해 두는 것만으로도
디자인·개발 과정에서의 혼선을 크게 줄일 수 있다.
그래서 버튼의 역할 정의와 함께
개발 환경을 구조적으로 드러내는 방식을 우선 반영했다.
개발 환경을 구분한 뒤에는,
버튼 안에서 어떤 선택지가 존재하는지 한눈에 파악할 수 있도록
Variant 구조를 다시 정리했다.
여러 속성을 개별적으로 설명하기보다,
컴포넌트 패널만 보고도 필요한 조합을 바로 이해할 수 있도록
구조 전체를 단순하고 직관적으로 구성하는 데 집중했다.
오른쪽 상단 Variant 패널을 통해 모든 상태를 변경이 가능하다버튼 구조를 정리한 뒤에는,
하나의 컴포넌트 안에서 필요한 Variant를 모두 제어할 수 있도록 재설계했다.
오른쪽 패널에서 Variant, Size, Icon, State 등을 선택하면
별도의 컴포넌트를 찾을 필요 없이
하나의 버튼 안에서 다양한 형태로 전환할 수 있도록 구성했다.
이제 디자이너는 패널에 노출된 속성 목록만 봐도
이 버튼이 어떤 속성 값을 지원하는지,
어디까지 변형이 가능한지를 한눈에 파악이 가능했다.
하지만, 실제 작업에서
또 다른 문제가 있었다
Variant 구조를 정리해도 해결되지 않는 문제가 있었다.
바로 버튼의 State(Interaction)을 구현하는 과정이었다.
이전 방식에서는
상태가 바뀔 때마다 직접 색상을 선택하고,
프로토타입 연결도 매번 수동으로 붙여야 했다.
그 과정에서
매 작업마다 반복되는 시간적 소모
상태 색상 선택 시 잘못된 값 입력 가능성
프로토타입 연결 누락 또는 오류 발생
을 완전히 배제하기는 어려웠다.
이 문제를 해결하기 위해
버튼 내부에 직접 색을 선택하도록 하는 방식을 완전히 제거하고,
Interaction 컴포넌트를 별도로 설계해
해당 컴포넌트를 포함하는 것만으로
색상과 프로토타입이 자동으로 연결되도록 개선했다.
Interaction을 적용하면,
상태가 자동으로 연결
새롭게 설계한 Interaction 구조의 핵심은 단순하다.
Interaction 컴포넌트를 컴포넌트에 배치하기만 하면,
그 안에 Normal / Hover / Pressed 상태가 자동으로 함께 따라온다.
즉, 디자이너가 Interaction 컴포넌트를 첨부하면
실제로는 3개의 상태가 동시에 세팅되는 효과가 만들어지는 것이다.
이 구조 덕분에
상태별로 색상을 다시 고를 필요도 없고
Hover, Pressed를 매번 수동으로 만들 필요도 없고
프로토타입 연결을 반복 작업으로 처리할 필요도 없다
상태 전환은 Interaction 컴포넌트 안에서 이미 설계되어 있기 때문에,
Interaction 컴포넌트를 첨부하는 것만으로 모든 상태가 ‘완성된 형태’로 제공된다.
Interaction 컴포넌트를 첨부하여 모든 버튼에 상태가 적용된 모습결국 Interaction 컴포넌트를 첨부하면
여러 상태를 가진 컴포넌트를 자동으로 만들어주는 시스템적인 장치가 되었다.
정리하며
컴포넌트를 다시 정의하고 개선하는 과정을 거치면서
가장 크게 느낀 점은, 결국 역할과 기준이 명확해야 한다는 것이었다.
디자이너는 혼자 화면을 만드는 직군이 아니라
개발자, 기획자와 함께 하나의 제품을 만들어가는 사람이다 보니,
컴포넌트를 이해하는 기준이 조금만 달라져도
서로에게 의도치 않은 부담을 주게 된다.
사실 이런 문제는 나도 예전에 1인 디자이너로 일할 때
누구보다 많이 겪어본 부분이라 더 와닿았다.
그 당시 기준이 없어서 개발자분들이 여러 번 확인해야 했고,
돌이켜보면 지금 와서야 미안함도 느껴진다.
(도게자라도 하고 싶은 심정이다.)
그래서 이번 개선에서는
누가 봐도 같은 판단을 할 수 있는 기준을 만드는 것에 집중했다.
역할을 다시 정의하고, Variant와 상태를 구조적으로 정리한 이유도
결국은 함께 일하는 사람들에게
불필요한 해석의 여지를 줄이고 싶은 마음에서 출발한 일이었다.
이번 과정을 거치며
디자인 시스템은 결국 나 혼자 편하자고 만드는 도구가 아니라,
함께 일하는 사람 모두가 편해지도록 만드는 약속이라는 걸 다시 느꼈다.
디자인 시스템 프로토타입 링크
figma.com/design/J6xmrGedkzKdVTC3tP1rR7/티키타-디자인시스템-일부분?node-id=16287-5267&t=kAA5PR0t9F9GxlUb-1