디자인 시스템 문의드립니다

안녕하세요 OH님 😀

질문내용을 정리하면 다음과 같습니다.

Q. 타 기업들의 디자인 시스템의 폰트사이즈는 소수가 아닌 정수로 떨어지는데 문제가 없을까요?

Q. 다른 디자인 시스템을 보면 px 옆에 rem또는 em으로 지정하는 이유를 알고싶습니다.

Q. 행간을 시스템상에 표기하는게 맞을까요?

Q. 토큰을 가공하지 않으면 디자인 시스템을 사용할 수 없을까요?

Q. 타 기업들의 디자인 시스템의 폰트사이즈는 소수가 아닌 정수로 떨어지는데 문제가 없을까요?

폰트의 증가 비율은 다같이 논의를 거친 후 선택할 수 있습니다.
제가 1.333배를 사용해 증가값을 설정한 이유는 타이포그래피의 디자인 이론으로 제품 또는 서비스에 균형 있고 조화로운 구성을 설정하기 위한 황금비율 이론에 기반하여 설정한겁니다.

만약 "우리는 4px씩 증가하는 폰트의 scale규칙을 가지자!" 라고 정한다면 규칙을 깨지 않고 유지한다면 문제가 생기지 않습니다.

뭐든지 시스템의 규칙은 회사와 내부 팀원들끼리 맞춰가는거니까요 😀

1.333배를 적용하면서 정수로 떨어지는 값들을 쓰는 회사들도 있습니다. 이는 토큰을 가공하는 과정에서 개발자가 디자이너와 합의하에 전부 반올림(round), 내림(floor), 올림(ceil) 처리한 것입니다.

그럼 꼭 정수로만 떨어져야 하는가? 라는 질문에는 꼭 그렇진 않습니다. 이 역시 폰트의 0.1px까지도 중요하게 여긴다면 소수로 가도 전혀 상관이 없습니다.

*티빙에 실제 서비스되는 폰트 사이즈

Q. 다른 디자인 시스템을 보면 px 옆에 rem또는 em으로 지정하는 이유를 알고싶습니다.

우리가 사용하는 웹브라우저 폰트의 기본값은 무조건 16px 입니다. CSS또는 JavaScript에서 웹브라우저는 최상의 객체인 root 라고도 부르는데, 이는 rem 단위의 앞에 r의 fullName이기도 합니다.

css에서 1rem 이라 함은 16px을 나타내는 것이죠, 다른 rem값들을 구하고 싶다면 해당 폰트사이즈 (px)에서 16을 나눠주면 rem 값을 계산할 수 있습니다. ( 28px → 1.75rem )

그럼 em은 뭔가요? 에 대한 질문은 rem은 태그의 깊이가 어떠하든 무조건 root의 폰트사이즈(16px)을 따라가는 반면에 em은 부모의 폰트 사이즈에 따라 값을 계산합니다. rem을 쓸지 em을 쓸지는 팀원들과 결정하므로 선택하여 사용합니다.

Q. 행간을 시스템상에 표기하는게 맞을까요?

행간을 150%로 설정한 이유는 WCAG2.0 웹접근성 항목에 명시된 내용에 기반하여 최소 행간의 크기를 지정했습니다.

1.4.12 텍스트 간격 (Level AA)

다음과 같은 텍스트 스타일 속성을 지원하는 마크업 언어를 사용해 콘텐츠를 구현한 경우, 다음의 모든 속성을 설정하고 다른 어떤 스타일 속성도 변경하지 않으면 콘텐츠나 기능이 손실되지 않는다.

• 줄 높이(줄 간격)를 글꼴 크기의 최소 1.5배로 설정

• 단락 간격을 글꼴 크기의 최소 2배로 설정

• 자간(추적)을 글꼴 크기의 최소 0.12배로 설정
  

• 단어 간격을 글꼴 크기의 최소 0.16배로 설정

예외: 서면 텍스트에서 이러한 텍스트 스타일 속성을 하나 이상 사용하지 않는 언어와 문자는 해당 언어와 문자의 조합에 존재하는 속성만 사용하면 된다.

토큰을 전달받은 개발자는 타이포그래피 하나하나의 속성을 들여다 보지 않고 heading-XL 라는 네이밍을 보고 토큰을 가져와 사용하기 때문에 개발자에게 명시하기 위해서는 크게 의미가 있어 보이진 않습니다.

다만 토큰을 문서화 하여 관리하고 이를 공유하는 차원에서는 명시해주는게 가독성이 더 좋을 것 같습니다.

Q. 토큰을 가공하지 않으면 디자인 시스템을 사용할 수 없을까요?

토큰을 어떠한 형태로 만드느냐에 따라 가공해서 사용하거나 가공을 하지 않고 사용하거나로 선택할 수 있습니다. 토큰을 피그마 네이티브 시스템으로 설정한 경우 (style, local variable)는 피그마의 간단한 plugin으로 css의 변수로 내보내 사용할 수 있습니다.

현재 강의에서는 토큰 스튜디오를 사용하기 때문에 토큰 스튜디오에서 만들어주는 json 파일은 후가공을 거쳐 사용할 수 있습니다. 후가공은 토큰 스튜디오 문서에 정리가 잘 되어있으며 프론트 개발자들이라면 보고 금방 후가공을 거쳐 사용할 수 있습니다.

그렇다면, 가공을 안하는 피그마 네이티브 방식이 더 좋은거 아닌가? 라고 물어보신다면, 그렇지만은 않습니다. 아직까지 피그마 네이티브 토큰들은 (style, local variable) 플러그인의 도움으로 내보내고 사용하긴 쉽지만 동기화(sync)가 어렵다는 점입니다. 새로운 토큰을 추가하면 똑같이 플러그인을 사용해 토큰을 내보내 개발자에게 전달해 줘야 하는 불편함들이 생기게 됩니다.

반면 토큰 스튜디오를 사용한다면 모든 토큰은 깃헙뿐만 아닌 다른 도구들과 연동하여 push와 pull을 할 수 있고 토큰의 수정이 일어났다면, 디자이너가 push를 통해 토큰을 올리고 개발자가 업데이트 내역을 받아 확인하고 반영할 수 있다는 장점이 있습니다.

피그마 네이티브 토큰을 동기화 하는 방법중 피그마 API를 개발자가 직접 draft파일에 연결하여 토큰을 가져오는 방법도 있습니다만, 제 개인적인 경험으론 API를 연결하는 방법보단 토큰 스튜디오로 토큰만 동기화 시키는 방법이 보다 간편합니다.

이렇듯 다양한 방법들이 존재하며 방법들마다 장단점이 있습니다.

오프라인 강의 일정이 요즘 많아져서 빠르게 답변드리지 못한 점 죄송합니다.
질문해주신 내용에 맞춰 최대한 정리하여 답변드려봅니다 🥹

감사합니다 :)