1. 디자이너에게 Figma Variable 기능이 필요한 이유
추상적인 시각적 아름다움을 구체적으로 수치화하는 과정
- 디자인 ➡️ 개발 과정에서 생기는 변화와 반영 오류를 최소화할 수 있음
단계별로 참조하는 구조이기 때문에 수정이 용이함
- 초기값 하나만 변경하면 초기값이 적용된 모든 대상들에게 변경사항을 일괄 적용할 수 있음
구조적인 사용방식을 통해 커뮤니케이션에 용이함
- 개발자가 의미를 추론하기 용이함
정해진 토큰 규칙에 맞춰 사용하기 때문에 디자이너가 어떤 속성을 써야할지 고민할 시간 자체를 줄여줌
- 특히 figma의 Color Scoping을 통해 원하는 속성에만 특정 Variable을 적용할 수 있음
2. Design Token의 이해
피그마의 배리어블을 잘 활용하기 위해선, 결국 디자인 토큰 개념과 정의에 대한 이해가 필요한데, 이 내용은 이미 정리가 너무 잘 되어 있는 글들이 많기도 하고 저는 what보단 why를 선호하는 편이라, 그래서 왜 써야 하는데? 에 집중해서 글을 작성할 예정입니다. 자세히 알고 싶은 분들을 위해 잘 설명되어 있는 링크도 같이 첨부할게요!
디자인 토큰은 쉽게 보자면 하나의 디자인 요소(위 그림에서 버튼 컴포넌트)에서 더 작게 나눠지는 하위 요소들의 구성이라고 볼 수 있어요.
디자인 토큰이라는 말 자체는 개념적인 의미이고, 위 버튼을 예시로 ‘디자인 토큰을 활용한다’고 했을 때, 버튼의 디자인 변경이 필요한 순간 버튼을 하나 더 만드는 게 아니라, 기존 버튼의 하위 속성값을 변경하면서 기존 컴포넌트를 재사용하는 양상으로 이해하면 될 것 같습니다.
그렇다면 저는 왜 피그마 배리어블 얘기를 하다가, 디자인 토큰을 말하고 있는 걸까요?
성인 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를 정의해도, 디자인을 하다보면 예외 케이스가 생기는 게 스스로 열 받았는데 피그마에서 배리어블을 활용하면, 정말 규칙을 잘 지킬 수 밖에 없기 때문입니다.(물론 저는 그럼에도 불구하고 깜빡해서 혼나긴 합니다 ..헤헤)
규칙을 지킬 확률이 높아지는 이유는 매우 심플합니다. 바로 피그마를 사용하는 방법이 아예 다르기 때문입니다.
기존에는 숫자를 입력할 때, 키보드로 직접 쳐서 입력할 수 밖에 없었고 숫자를 입력하는 행동 자체가 하나의 관성으로 작용할 수 밖에 없는데, 피그마의 배리어블 기능을 통해 숫자를 입력할 땐,
요렇게 숫자와 관련된 모든 상황에선 아예 다른 방식으로 사용해야 하다보니, 리마인드하기 쉽고, 지정한 목록에서만 선택해서 사용하다보니 예외케이스를 효과적으로 줄일 수 있습니다. 이는 더욱더 규칙을 강화하고 잘 유지함으로써 제품의 퀄리티를 높이는데 기여할 수 있다고 생각합니다.
3. 저는 특히 이런 점이 좋았어요.
디자인 토큰이나 디자인 시스템은 결국 구성원들이 함께 정의한 규칙들의 집합라고 생각합니다. 그래서 무엇이 정답이라고 말하기 참 애매한데요, 뛰어난 외부 레퍼런스도 우리 회사의 컨텍스트와 스코프, 스테이지에 맞지 않을 수 있기 때문이죠.
그럼에도 불구하고, 따봉 몇 개 더 받기 위해 제가 개인적으로 좋다고 생각하는 정의와 활용 방식을 공유드려요.
디자인 토큰은 참조(Reference)가 전제되어 있기 때문에, 구조적으로 네이밍 규칙을 정하는 게 중요한데요, 저는 adobe 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이라도 적용되는 컴포넌트나 오브젝트의 속성에 따라 위계를 조정하기 수월하다는 점인데요,
같은 primary라도 text에서 primary와 fill의 primary의 색상과 의미가 다를 수 있는데도 불구하고, 기존에는 brand color = primary였다면 자연스럽게 다른 계열의 색들은 의미적으로 위계가 낮아지고, 다른 primary 영역에서도 해당 색들은 tertiary나 subtle 정도로 이름 붙여 사용되다 보니, 정합적이지 못하다는 인상을 받았는데
배리어블을 통해 이런 식으로 속성에 따라 semantic한 구조와 정책을 정하고 활용할 수 있다는 점이 굉장히 좋았던 것 같습니다!
여러분들은 배리어블의 어떤 점이 가장 편하고 좋으신가요?
'study' 카테고리의 다른 글
| 우당탕탕 스프린트 도입기 - 1 (1) | 2024.06.03 |
|---|---|
| 개발자와 협업을 더 잘하고 싶은 디자이너를 위해 (0) | 2024.06.02 |
| B2B SaaS의 고객은 너무 다양해요 (0) | 2024.05.18 |