[Figma] 피그마 배리어블 꼭 써야 하나요?
저도 사실 잘 몰라요.
1. 디자이너에게 Figma Variable 기능이 필요한 이유
추상적인 시각적 아름다움을 구체적으로 수치화하는 과정
디자인 > 개발 과정에서 생기는 변화와 반영 오류를 최소화할 수 있음
단계별로 참조하는 구조이기 때문에 수정이 용이함
초기값 하나만 변경하면 초기값이 적용된 모든 대상들에게 변경사항을 일괄 적용할 수 있음
구조적인 사용방식을 통해 커뮤니케이션에 용이함
개발자가 의미를 추론하기 용이함
2. Design Token의 이해
피그마의 배리어블을 잘 활용하기 위해선, 결국 디자인 토큰 개념과 정의에 대한 이해가 필요한데, 이 내용은 이미 정리가 너무 잘 되어 있는 글들이 많기도 하고,
저는 what보단 why를 선호하는 편이라 그래서 왜 써야 하는데? 에 집중해서 글을 작성할 예정입니다.
자세히 알고 싶은 분들을 위해 잘 설명되어 있는 링크도 같이 첨부할게요!
https://specifyapp.com/guides/design-data-platforms-101/04-design-tokens-and-assets디자인 토큰은 쉽게 보자면 하나의 디자인 요소(위 그림에서 버튼 컴포넌트)에서 더 작게 나눠지는 하위 요소들의 구성이라고 볼 수 있어요.
디자인 토큰이라는 말 자체는 개념적인 의미이고, 위 버튼을 예시로 ‘디자인 토큰을 활용한다’고 했을 때, 버튼의 디자인 변경이 필요한 순간 버튼을 하나 더 만드는 게 아니라, 기존 버튼의 하위 속성값을 변경하면서 기존 컴포넌트를 재사용하는 양상으로 이해하면 될 것 같습니다.
그렇다면 저는 왜 피그마 배리어블 얘기를 하다가, 디자인 토큰을 말하고 있는 걸까요?
성인 ADHD의 영향도 조금 있겠지만, 사실 피그마의 배리어블 기능이 디자인 요소를 토큰화시키는 기능을 포함하고 있기 때문입니다.
예를 들어, 기존에는 버튼을 만들거나 수정할 때,
border-radius에 "8px" 라는 값을 입력
auto Layout(padding)에 "16px"라는 값을 입력
fill(background-color)에 "#4F46E5"라는 값을 입력
했고, 이를 코드로 변환하면 아래의 raw value값이 출력돼요.
border-radius: 8px;
padding: 16px;
background: #4F46E5;
사실 이 자체로도 큰 문제는 없지만, 다른 이해관계자가 해당 코드를 봤을 때, 해당 숫자들만으로는 규칙을 추측하기 어렵다는 단점이 있어요.
또한, 디자이너 역시 숫자보다 눈으로 입력값을 판단하기 때문에 'A'라는 컴포넌트에서는 padding을 16px을 입력했지만, 'B'라는 컴포넌트에서는 12px을 입력하는 상황이 생길 수 있고, 아무리 나름의 규칙(8의 배수)을 갖고 있어도, 예외 상황이 생기는 경우가 허다하죠.
스스로만 정의한 디자인 규칙이기 때문에, 8의 배수가 아닌 예외 상황으로 만들고, “디스크립션을 작성했으니까 반영이 되겠지”라고 생각하지만, 개발자의 입장에선 어렴풋이 들었던 8의 배수만 생각하고 예외 케이스에 대응하지 못해서 디자이너가 의도했던 아웃풋이 나오지 않는 모두가 불편한 상황..
디자이너라면 한 번쯤은 경험해 보셨을 것이라고 생각합니다.
갑자기 급발진해서 말이 길어졌네요.
다시 본론으로 돌아가서 피그마 배리어블 기능을 통해 예시의 버튼을 토큰화하면 다음과 같이 입력하게 되는데요,
border-radius에 --border-radius-sm 입력
auto layout(padding)에 —-spacing-md 입력
fill(background-color)에 --color-bg-primary 입력하면 그 결과는..!
border-radius: var(--border-radius-sm);
padding: var(--spacing-md);
background: var(--color-bg-primary);
이런 식으로 코드를 추출할 수 있습니다. 기존 코드와 비교했을 때 어떤 차이가 있는 것 같나요?
네 맞습니다. 일단 의미를 추론하기 용이하죠. padding:16px이 아니라 padding: --spacing-md이기 때문에, 개발자 입장에서
“아! 대충 이런 상황에서 쓰이는 컴포넌트는 medium정도의 padding값을 갖겠구나”
라고 생각할 수 있습니다.(개인적인 희망사항)
사실 토큰화가 커뮤니케이션에 있어서 도움이 되지만, 저는 다른 이유 때문에 토큰화를 추천하는 편인데요.
바로 스스로를 제약(?)하는 규칙을 만든다는 점입니다.
제가 주니어라서 그럴 수 있겠지만, 아무리 Principle이나 Guide를 정의해도, 디자인을 하다 보면 예외 케이스가 생기는 게 스스로 열받았는데 피그마에서 배리어블을 활용하면, 정말 규칙을 잘 지킬 수밖에 없기 때문입니다.
규칙을 지킬 확률이 높아지는 이유는 매우 심플합니다. 바로 피그마를 사용하는 방법이 아예 다르기 때문입니다. 기존에는 숫자를 입력할 때, 키보드로 직접 쳐서 입력할 수밖에 없었고 숫자를 입력하는 행동 자체가 하나의 관성으로 작용할 수밖에 없는데, 피그마의 배리어블 기능을 통해 숫자를 입력할 땐,
auto layout padding값에 variable을 입력하는 장면요렇게 숫자와 관련된 모든 상황에선 아예 다른 방식으로 사용해야 하다 보니, 리마인드 하기 쉽고, 지정한 목록에서만 선택해서 사용하다 보니 예외케이스를 효과적으로 줄일 수 있습니다. 이는 더욱더 규칙을 강화하고 잘 유지함으로써 제품의 퀄리티를 높이는데 기여할 수 있다고 생각합니다.
3. 저는 특히 이런 점이 좋았어요.
디자인 토큰이나 디자인 시스템은 결국 구성원들이 함께 정의한 규칙들의 집합라고 생각합니다. 그래서 무엇이 정답이라고 말하기 참 애매한데요, 뛰어난 외부 레퍼런스도 우리 회사의 컨텍스트와 스코프, 스테이지에 맞지 않을 수 있기 때문이죠.
그럼에도 불구하고, 따봉 몇 개 더 받기 위해 제가 개인적으로 좋다고 생각하는 정의와 활용 방식을 공유드려요.
디자인 토큰은 참조(Reference)가 전제되어 있기 때문에, 구조적으로 네이밍 규칙을 정하는 게 중요한데요, 저는 adobe spectrum의 토큰 계층을 참고해서 규칙을 정의했었습니다.
adobe spectrum design system
spectrum을 참고해서 도식화한 배리어블 계층
해외 아티클을 참고해서 이렇게 Raw value에서 Component까지의 계층을 primitive(원시값) > theme(테마) > semantic(의미적 해석 단계)으로 단계로 나눠서 배리어블을 정의했고, 그 결과로 이런 식으로 정리할 수 있습니다!
피그마에 등록한 배리어블 예시각각의 단계들이 이전 단계의 토큰값을 참조하는 구조로 제작했기 때문에,
예를 들어, primary(orange)색을 조금 더 붉은기가 생기도록 수정할 때, 가장 첫 단계인 primitive 토큰만 수정해 주면 다른 단계의 토큰과 해당 토큰을 참조하고 있는 컴포넌트의 색상이 알아서 변경됩니다.
어디서 많이 보시지 않았나요? 맞습니다. 피그마의 Component와 Instance 기능과 유사하죠?
컴포넌트 하나만 수정하면 모든 인스턴스에 자동 반영되는 것처럼, 이 색상 토큰도 원시값인 primitive color값을 변경하면 이 원시값을 1차적으로 참조하고 있는 theme color가 변경되고, theme color를 사용 중인 컴포넌트의 색이 변경됩니다.
실제로는 theme token에서 semantic token으로 단계가 더 있지만, 이해를 위해 두 단계로만 구성한 점 참고 부탁드려요~!
4. 이렇게 만든 배리어블 어떻게 사용하는 게 좋을까요?
사실 배리어블을 쓴다고 디자인 퀄리티가 비약적으로 높아지는 것도 아니고, 저도 실제로 많은 프로덕트에 적용을 해본 적도 없어서 사실 이 부분은 오히려 제가 묻고 싶은 부분이긴 해요.
다만 제가 개인적으로 좋다고 생각한 점은, 같은 semantic level이라도 적용되는 컴포넌트나 오브젝트의 속성에 따라 위계를 조정하기 수월하다는 점인데요,
semantic level 배리어블 예시같은 primary라도 text에서 primary와 fill에서의 primary의 색상과 의미가 다를 수 있는데도 불구하고, 기존에는 brand color = primary였다면 자연스럽게 다른 계열의 색들은 의미적으로 위계가 낮아지고, 다른 primary 영역에서도 해당 색들은 tertiary나 subtle 정도로 이름 붙여 사용되다 보니, 정합적이지 못하다는 인상을 받았는데
배리어블을 통해 이런 식으로 속성에 따라 semantic한 구조와 정책을 정하고 활용할 수 있다는 점이 굉장히 좋았던 것 같습니다!
여러분들은 배리어블의 어떤 점이 가장 편하고 좋으신가요?
