피그마에서 반응형 rem 사이즈로 디자인하기
웹접근성을 고려한 디자인 시스템 구축기
디자인 시스템을 만들면서 공부하고 경험한 것을 기록합니다.
가독성은 아무리 강조해도 지나치지 않다.
서비스에서 가장 중요한 것은 정보 전달이다. 정보가 제대로 전달되기 위해서는 일정 수준의 가독성이 보장되어야 한다. 보이는 것을 이해해야 서비스를 이용하면서 원하는 목적을 달성할 수 있다. 아무리 예쁘게 디자인되어 있다고 하더라도 한국인이 아랍어로 되어있는 서비스를 제대로 이용할 수는 없다.
가독성을 위해서는 텍스트의 색상과 사이즈가 적절하게 디자인되어 있어야 한다. 이전에는 웹 접근성을 고려한 폰트 색상 시스템을 1차로 정리해보았다. 이번에는 어떻게 하면 제대로 인지할 수 있는 폰트 사이즈 정책을 정할 수 있을까 고민이 됐다.
사실 많은 서비스를 이용해보면 다양한 크기로 정보를 전달하고 있음을 발견할 수 있다. 읽는 데 큰 무리가 없는 서비스도 있었지만, 글자가 너무 작아서 잘 보이지 않거나 너무 커서 눈의 피로도를 높이는 경우도 심심찮게 볼 수 있었다.
나는 브런치 글자가 매우 작다고 생각한다...
https://www.designsystems.com/ 여긴 너무 크다우리 서비스도 디자이너마다 작업하는 기준이 달랐다. 어떤 디자이너는 매우 작게 디자인했고, 어떤 디자이너는 크게 디자인했다. 같은 정보를 전달하는 콘텐츠임에도 불구하고 페이지마다, 작업자마다 커졌다 작아지기를 반복하는 디자인을 보고 있으니 디자인 시스템의 필요성이 더욱 와 닿았다.
디자이너는 자기를 기준으로 작업하면 안 된다.
나도 작업할 때 기본적으로 사용하는 사이즈가 있었지만 '나는 이렇게 작업하고 있으니 여기에 맞춰-'라는 식의 논리로 시스템을 만들 수는 없었다. 디자이너는 자신을 기준으로 디자인하면 안 된다. '나는 눈이 나쁘니까 커야 해'도 안되고, '나는 눈이 좋아서 잘 보이니까 작아도 돼'도 안 된다. 내가 아니라 서비스를 사용하는 고객을 위하여 디자인해야 한다. 나이가 드신 분들이 스마트폰을 이용하는 것만 보더라도 글자 크기를 매우 크게 설정하고 보는 것을 발견할 수 있다. 이런 분들이 이용하는 서비스라면 당연히 그 맥락을 고려해서 디자인하는 것이 바람직한 UX 디자이너의 역할 아닐까.
웹 접근성 지침(WCAG)에는 텍스트 크기에 대하여 아래와 같은 정책을 설명하고 있다.
(LAVEL AA) 텍스트는 콘텐츠나 기능의 손상 없이, 그리고 보조공학 없이 최대 200%까지 크기 조정이 가능해야 한다. 단, 자막과 텍스트 이미지는 제외한다.
모든 고객은 신체적, 환경적 조건과 관계없이 서비스를 이용할 수 있어야 한다. 신체적인 조건이란 평범한 사람은 물론이고 색각 이상, 저시력을 포함한 시각 장애 및 고령자 등을 의미하고, 환경적 조건은 다양한 기기와 운영 체제, 브라우저 등의 모든 환경을 의미한다.
하지만...
나이가 많거나 시각 장애를 가지고 있는 분들만 이용하는 서비스도 아니었기 때문에 '무조건 크게'라는 정책을 정하기도 애매했다. 어떻게 하면 많은 사람이 쾌적하게 정보를 파악할 수 있도록 시스템화할 수 있을까?
적절한 폰트 사이즈는?
사실 지금까지 나도 명확한 정책을 정하고 작업하지는 않았다. 이런저런 서비스에서 참고하여 본문 최소는 14px, 내용 위주의 페이지에서는 16px를 사용하곤 했다. 내가 보이게도 적절하게 잘 보이는 것 같았고, 일반적인 사람들에게도 잘 보이는 사이즈라고 여겼기 때문에 이 정도 크기면 적당할 것 같았다. 하지만 너무 개인적이었고 이런 설명으로 정책을 정하기에는 디자인 논리가 부족했다. 그래서 다른 브랜드의 타이포 정책을 찾아보았다. 가장 빈번하게 사용하는 Body 기준으로.
구글 Material design (링크)
구글은 타이포 스타일을 총 5개 Display, headline, body, label로 구분한다. 그리고 Body의 기본(Medium)은 14px이다. 타이포그래피를 설명하는 페이지에서도 다음과 같이 안내하고 있다.
Material Design uses the Major Second type scale with 14 as its key base size. This anchors to the most essential style used most often for typesetting body text.
애플 Human interface guidelin (링크)
애플의 경우 정책이 너무 많아서 확실한 기준이 되는 값을 확인하기가 어려웠다(영어를 못해서 그럴 수도 있다). 일단 Default라고 적혀있는 테이블을 보면 Body가 17pt로 나와 있다.
해상도에 따라 달라지기 때문에 pt = px은 아니지만 pt에 대한 이해도가 아직은 부족해서 애플 웹 사이트의 개발자 도구를 확인했다. 본문이 17px로 되어있어서 일단 17px으로 이해하고 넘어가기로 했다. (사이즈 단위는 나중에 더 공부해서 확실히 잡고 가야겠다.)
font-size : 17px지마켓 (링크)
지마켓은 Heading, Body, Detail 3가지 텍스트 스타일이 있으며, Body 1은 16px이다.
Line (링크)
라인은 Heading, Title, Body 3가지 스타일이 있다. Body는 1~4로 나뉘어있다.
다른 서비스의 경우 S, M, L 와 같이 사이즈 관계를 파악할 수 있거나 사용 목적에 주로 사용되는 기준이 적혀있었지만, Line의 경우 자세하게 파악은 어려웠다. 그래서 서비스 페이지에서 본문처럼 보이는 텍스트를 개발자 도구로 확인해보았다. 16px, 14px이 사용된 것으로 보아 기본은 Body 1, 2일 것 같다.
PX, EM, REM
기본 사이즈는 대략 파악했지만 px는 고정값이기 때문에 처음에 목표로 했던 '고객이 자신의 환경에 맞춰서 쾌적하게 정보를 확인할 수 있게 한다.'를 해결해주지는 못했다. 텍스트도 반응형 작업이 필요했다. 해상도에 따라서 바뀌는 분기가 아니라 고객이 설정하여 변경할 수 있는 방식으로.
창피하게도 이번에 사이즈 단위를 공부하기 전까지 em과 rem의 사이즈 단위 작동 방식을 자세히 알고 있지 않았다. 단순히 반응형에 유용한 사이즈 정도로만 인식했을 뿐이다. 이전까지 자연스럽게 px 기반의 디자인을 하고 있었고, 큰 문제의식도 느끼지 못했던 것 같다.
https://codebeautify.org/px-to-rem-converterREM (Root em)
rem은 브라우저의 루트 폰트 사이즈를 기준으로 적용되는 % 개념의 사이즈다. 모든 브라우저에는 루트 폰트 크기(root font size)가 설정되어 있는데, 별도의 작업을 하지 않으면 기본은 16px로 적용되어 있다. 16px이 1rem이다. 따라서 16px = 1rem을 기준으로 8px은 0.5rem, 32px은 2rem와 같은 식으로 계산된다.
EM
em은 해당 텍스트가 포함된 요소(아마 div)에 적용된 폰트 사이즈에 영향을 받는 % 개념의 사이즈다. 요소의 폰트 사이즈가 32px이라면 1em은 32px, 2em은 64px이 된다.
사실 em은 이해하기가 가장 어려웠다. 소속된 요소의 폰트 사이즈에 영향을 받거나 정의된 폰트 사이즈가 없으면 상위 요소의 폰트 사이즈의 속성을 내려받는다고 한다. 이해하기 어려운 것을 정책으로 삼을 수는 없어서 em은 쿨하게 포기했다.
PX, EM, REM의 차이
위에서 이해한 것을 기반으로 3가지 사이즈 단위의 차이를 정리해보았다. 아래와 같이 HTML 안에 Body가 있다고 가정해보자. html에는 기본 폰트 사이즈인 16px이 적용되어 있고, body에는 폰트 사이즈를 1.25rem으로 지정해두었다. 그리고 body 안에는 px으로 환산하면 모두 40px의 사이즈를 가지는 텍스트가 각각 px, rem, em으로 적용되어 있다.
위 상태에서 html의 root font size를 16px에서 32px로 변경하면 px은 고정값이므로 변동이 없다. rem과 em으로 적용된 텍스트는 바뀐다. rem은 html의 root font size의 영향을 받고, em은 html의 root font size의 영향을 받은 body의 font size에 영향을 받아서 변경된다.
Body의 font size를 1.25rem에서 2rem으로 바꾸면 텍스트가 포함된 요소의 font size에 영향을 받는 em만 크기가 변경된다.
html과 body의 font size를 모두 바꾸면 다음과 같다. 이미지를 그리며 확인을 해보니 em의 경우 어떻게 변경될지 전혀 예측할 수 없었다. 작업 기준으로 삼기에 확실히 어렵다는 것을 느꼈다.
디자인의 레이아웃과 각 UI의 위계를 유지하면서도 사용자가 설정한 기준에 따라 크기를 크거나 작게 보여주려면 REM으로 작업하면 적절할 것 같았다.
REM으로 디자인된 서비스와 아닌 서비스
구글의 '설정 > 모양 > 글꼴 맞춤 설정'에 들어가면 브라우저 폰트 사이즈를 변경할 수 있다. (root font size를 변경한다고 보면 될 것 같다) REM 기반으로 디자인된 서비스의 경우 여기서 변경한 값에 따라서 크기가 바뀌는 것을 확인할 수 있다.
브라우저 글꼴 크기 변경 (gif)Canva
Nord design
퍼블리
rem으로 디자인된 페이지는 레이아웃과 각 UI의 위계가 유지된 채로 크기만 변경된다. 사실 레퍼런스를 찾아보니 거의 대부분 px로 작업한 서비스였고 아무런 반응이 없었다. 종종 UI의 일부만 REM으로 적용된 사이트도 있다. 이런 경우 폰트 설정을 변경하면 REM으로 작업 된 일부 UI만 변경되어서 레이아웃이 깨지는 문제가 있다.
https://disquiet.io/아마 개인적인 생각으로는 작업한 디자이너와 개발자가 모두 다르기 때문에 반응형을 중요하게 여기는 작업자의 경우 REM으로 작업을 하고 아닌 경우 PX로 작업이 되어서 이런 결과가 나오지 않았나 싶다. 결국 서비스 전체적으로 시스템화하여 통일하지 않으면 고객에게 쾌적한 경험을 제공할 수 없게 된다.
또한 꼭 브라우저 설정이 아니더라도 타이포 시스템을 잘 정립해둔다면 서비스 자체적으로도 적절한 가독성을 위한 설정 기능을 제공할 수 있을 것 같았다.
피그마에서 REM으로 작업하기
이런저런 시행착오를 거쳐서 피그마에서 root font size를 변경하여 디자인에 사용된 텍스트가 전체적으로 바뀌는 것을 확인하는 방법을 발견했다. 첨부한 이미지처럼 텍스트를 전체적으로 키우거나 줄일 수 있다.
피그마에서 root font size 변경과 디자인 변경 확인 (gif)피그마의 문제점
피그마는 px이 기본 작업 단위이며 rem으로 작업할 수 없는 환경이었다. 디자인을 개발자에게 전달하면 개발자는 Inspect에서 확인하는데, 여기서도 px 단위로만 볼 수 있었다. (웹 기반 서비스)
대안, 피그마 토큰
디자인 토큰 기반의 디자인 시스템을 만들기 위하여 피그마 토큰 플러그인을 활용하고 있었다. 디자인 토큰은 UI의 기본 단위(size, spacing, color, border, shadow, font 등)를 변수로 저장하여 통일성 있는 디자인 작업과 수정이 용이한 디자인 시스템을 만드는 방법이다. 피그마 토큰 플러그인은 아래와 같이 생겼다. 각 구성요소 단위별로 값을 입력하거나 수식을 사용하여 변수로 저장할 수 있다.
기본 프리셋이런 식으로 다른 변수를 넣어서 계산도 가능하다. 예시의 경우 body 토큰이 16px로 지정되어 있고 sm 토큰은 (body 토큰 * 0.85)로 생성되어 있어서 디자인에 적용하면 13.6px로 작동한다.
혹시나 하고 rem이 적용되는지 토큰을 만들어보았다. 놀랍게도 적용이 되었다. 이때 속으로 유레카를 외쳤던 것 같기도 하다. 여하튼 아무 단위로 적지 않고 숫자만 적으면 px이 기본이고 뒤에 rem을 적으면 rem으로 작동한다. 1rem은 16px, 2rem으 32px, 3rem은 48px로 잘 작동하는 것을 확인했다.
rem으로 font size 토큰 생성
rem 토큰 적용 (gif)rem 토큰 생성하기 1
통일성 있는 디자인을 위해서는 어느 정도의 제약이 필요하다. 따라서 텍스트로 사용할 사이즈를 일부 추려서 rem 단위의 font-size 토큰을 만들기로 했다. 피그마 내에서도 root font size가 달라질 때 전체적인 디자인도 어떻게 달라지는지 확인하고 싶었기 때문에 0.5rem, 1rem, 1.5rem… 와 같이 고정된 값으로 저장하지 않고 수식을 사용하여 저장하기로 했다.
rem을 구하는 공식 = px / root font size
그런데 토큰을 만들다가 계산되어 나온 값 뒤에 rem이 붙어야 하는데 계산식과 문자를 같이 사용하면 제대로 적용되지 않는 문제가 있었다.
둘 다 아니야...토큰 분리
결국 고민하다가 rem으로 계산만 하는 토큰 그룹 1(수식만)과 그룹 1에 ‘rem’ 단위만 뒤에 추가하는 토큰 그룹 2를 따로 나누어 사용하기로 했다. 실질적으로 디자인 작업에 사용할 토큰은 2번 그룹이다.
토큰 이름에 대한 고민
토큰 이름을 어떻게 할까 고민했다. 다른 서비스에서는 1, 2, 3, … 또는 s, m, l와 같이 표시하고 있었으나 작업할 때 저런 식으로 적혀있다면 헷갈려서 작업이 제대로 되지 않을 것 같았다. 아무래도 px에 너무 익숙해져 있기 때문에 rem 기반으로 작업을 하려고 해도 ‘이건 14px이 적당해보인다. rem으로 몇이지?’ 이렇게 생각하고 작업하지 ‘0.825rem 사이즈면 되겠군’ 이렇게 생각하지는 않을 것 같았다. 따라서 토큰 이름은 그냥 px크기를 넣어두었다. (아직 테스트 중이라 정확한 네이밍 규칙을 정하지도 않은 상태라 보기 쉽게 정리해두기로 했다.)
도큐먼트 정리
만든 토큰은 이해하기 쉽게 도큐먼트로 추가해두었다. 도큐먼트도 피그마 토큰 플러그인을 활용하면 바로바로 지정할 수 있다. 플러그인을 통해 도큐먼트에 적용된 값은 플러그인에서 값을 변경하면 자동으로 업데이트되기 때문에 관리하기 용이하다.
도큐먼트를 정리하고 대망의 root font size를 바꿔서 전체적인 사이즈가 잘 바뀌는지 확인하는 시간을 가졌다.
rem 토큰 생성하기 2
바뀌긴 바뀌었다. 반대로...! root font size 토큰을 공통 변수로 사용하기 때문에 전체적으로 바뀌었다. 처음에는 신기해서 이렇게 저렇게 수정을 해보았다. 그런데 뭔가 이상했다. root font size를 크게 바꾸면 전체적으로 커져야 하는데 텍스트는 작아졌다. 반대로 root font size를 작게 설정하면 텍스트는 커졌다.
rem 토큰 수식
px / root font size
root font size가 부모였기 때문에 값이 커질수록 계산된 값이 작아지는 것은 당연했다. 이 당연한 것을 적용을 해보고 나서야 깨닫다니 바보 같다는 생각을 하면서 어떻게 해결할 수 있을까 또 고민했다. 변경한 값에 따라서 결과 값이 같이 커지거나 작아지려면 나누기가 아니라 곱하기로 되어 있어야 했다. 그렇다고 위에서 만든 토큰 수식을 나누기에서 곱하기로 바꾼다면 rem 계산이 되지 않았다. 그렇게 토큰 그룹 3을 또 만들기로 했다.
rem은 root font size의 배수이기 때문에 rem을 계산한 토큰 그룹 1에 다시 root font size를 곱해주는 토큰 그룹 3을 만들었다. 그룹 1에서 생성한 root font size는 rem 계산용 값이기 때문에 변경하면 안 되는 토큰이고, 그룹 3의 root font size은 실제로 고객 설정에 따라서 바뀌는 값이다.
토큰 그룹 3으로 도큐먼트를 다시 정리했다. 이번에는 root font size를 변경할 때마다 같이 커지고 작아졌다. 잘 작동했다.
root font size 크기 변경 16px > 20px (gif)임시 디자인에도 적용해서 확인해보기로 했다. root font size를 계속 일일이 바꾸며 확인하기는 번거로웠기 때문에 새로운 set를 추가하여 root font size만 다른 값으로 저장을 해두었다. 기본은 16px이고 small은 14px, large는 18px로 저장해두었다. 작업을 하면서도 해당 set의 체크박스를 선택하기만 하면 바로바로 디자인이 어떻게 변경되는지 확인할 수 있다.
디자인 변경 확인 (gif)또 다른 고민, 협업
디자이너 협업
생성한 피그마 토큰은 github 등을 사용하여 다른 디자이너들에게도 전달을 할 수 있었다. 그런데 계속 플러그인을 열고 사용하는 것이 번거롭게 느껴졌다. layer, stroke, effects 등 대부분 피그마의 우패널을 통해서 작업하는데 폰트 사이즈를 설정할 때만 계속 플러그인을 열고, 닫고 작업하는 것이 효율적이지 않게 느껴졌다.
폰트 사이즈만 플러그인 창에서, 나머지는 우패널에서?개발자 협업
사실 이게 가장 큰 문제였다. 피그마 토큰을 사용해도 개발자는 inspect를 보고 개발하게 되는데, 여기서는 토큰 이름이 표시되지 않았다. 피그마 토큰 플러그인에 hand-off 기능이 있기는 했지만 디자인 하나하나마다, 또 폰트 사이즈만 이 hand off로 표시하는 것이 디자이너에게도 개발자에게도 비효율적이었다.
Inspect에서는 토큰값을 알 수 없다.텍스트 스타일 추가
작업 편의성을 높이려면 피그마 내에서 다른 디자인 요소를 작업하는 것처럼 동일하게 할 필요가 있었다. 플러그인을 계속 열고 닫을 필요 없이 피그마의 우패널에서 작업할 수 있도록 피그마 자체의 텍스트 스타일로 생성하기로 했다. 이것도 피그마 토큰 플러그인에서 가능하다. 타이포그래피 토큰에 만들어둔 font-size 토큰(그룹3)을 연결시켜 생성하면 된다. 폰트 사이즈 외에도 font style, weight, line height 다양하게 적용할 수 있다.
이건 실제로 디자인에 사용할 토큰이기 때문에 토큰 사용 맥락을 고려하여 heading, body, label로 나누어서 시맨틱 네임으로 만들었다. (완벽한 시맨틱은 아니지만 일단 임시…) 타이포 토큰을 생성한 후 스타일 추가를 하면 피그마 텍스트 스타일로 추가가 된다.
텍스트 스타일로 추가되면 우패널에서 작업을 할 수 있어서 플러그인을 열지 않아도 된다. 우패널에서 스타일을 적용해도 root font size를 변경했을 때 잘 바뀌는 것을 확인할 수 있다. (그러나 root font size를 변경하려면 플러그인을 켜야 한다…)
우패널에서 텍스트 스타일 적용 (gif)텍스트 스타일을 변수로 저장해두면 개발자도 Inspect에서 디자인 토큰이 적용된 텍스트 스타일 이름을 확인하고 개발을 할 수 있게 된다.
개발자도 확인 가능텍스트 토큰을 사용하는 서비스
요즘은 토큰 기반 디자인 시스템을 사용하는 서비스들이 많아진 것 같다. 물론 아닌 곳도 많지만 글로벌 기업이라고 할 수 있는 서비스들은 개발자 도구를 사용하면 작은 디자인 단위의 요소를 변수로 사용하고 있는 것을 볼 수 있다.
구글
Nord design
느낀점
아직 정리가 완료된 것도 아니며 실제 서비스에 적용해보지도 않은 상태다. 디자인 시스템은 타이포그래피 뿐만이 아니라 너무 많은 구성 요소가 있으므로 더 많은 고민과 시행착오 및 개선이 필요할 것 같다. 네이밍 규칙도 아직 마음에 들지 않는 상태고, 새로운 서비스를 확인하고 좋은 레퍼런스를 찾을 때마다 조금씩 달라지고 있기도 하다. 그래서 위에서 정리한 부분이 실제로 협업하고 서비스에 적용하는 과정에서 문제없이 제대로 돌아갈 수 있을지 확신할 수는 없다. 그래도 문제가 있더라도 계속 개선해나가면 되지 않을까. 분명 기준이 없이 디자이너마다 따로 작업하는 것보다는 더 통일성 있는 디자인, 더 많은 사용자를 고려한 서비스를 만들 수 있지 않을까 기대한다.
또 겉핥기식으로 보고 넘어간 부분도 많아서 이상하게 적은 부분이 있을 수도 있을 것 같기도 하다. 그래도 수집한 정보들과 생각을 정리하면서 내가 부족한 것이 무엇인지 파악하는 계기가 된 것 같다. 세상에는 알아야 할 것도, 배울 것도 참 많다. (특히 em.. 넌 아직도 명확하게 이해를 못 했다...)
