프로덕트 디자인 가이드 제작 - 02. 폰트 가이드
스트릿 출신의 프로덕트 디자이너가 가치 있는 제품을 만들려는 노력의 기록
타이포는 컬러 다음으로 정보를 시각화할 때 중요한 역할을 한다.
어떤 타이포를 쓰느냐에 따라 정보의 성격을 파악할 수 있고 더불어 사용자의 읽기 속도를 높이기도 한다.
또한 잘 설계된 타이포 간의 크기 비례는 정보를 효과적으로 전달하여 사용자의 여정을 성공으로 이끈다.
이 타이포들을 웹상에서 설계하기 위해 우리는 폰트를 고른다.
잘 설계된 폰트 시스템은 웹/앱 프로덕트를 구동하는 속도에도 영향을 미친다.
반대로 잘못 설계된 폰트는 기능적 영향 뿐만 아니라 해당 브랜드의 아이덴티티까지 잘못 전달할 수 있다.
이렇게나 중요한 폰트는 쓰는것만큼이나 가이드화하는 것도 중요하다. 디자이너를 위해서도 중요하지만 협업을 매끄럽게 하는 역할도 하기 때문이다.
폰트가 가이드화 되어 있지 않으면 개발단에서 마크업 시 폰트의 크기나 자간, 행간 등등을 매번 지정해줘야한다. 소스코드가 길어지면 작업자들끼리도 좋지 않고 결과적으로 사용자에게 제공하는 환경에도 영향을 미친다.
그렇다면 어떻게 만들어야 할까?
폰트를 정할 때
알면 도움 되는 것
1) 웹폰트와 이미지폰트의 차이
같은 제조사라도 디바이스 제작사 마다, os마다 기본 서체가 다르다. ios와 안드로이드가 다를뿐더러 삼성과 엘지폰은 또 다르다. (엘지가 스마트폰 사업을 종료하긴 했지만 기기는 아직 세상에 남아있다.)
또한 사용자가 본인이 지정한 폰트를 적용하여 사용하는 경우도 있다.
그래서 많은 서비스 프로덕트들이 다양한 이유로 자신들이 지정한 폰트가 보이도록 설정한다.
방법에는 웹폰트를 사용하는 방법과 이미지 폰트를 사용하는 2가지 방법이 있다. 두개가 어떤 차이가 있는지 살펴보자.
■ 웹폰트
폰트 파일을 서버에 업로드 하여 내보내는 방식이다. 사용자의 디바이스에 해당 폰트가 깔려있지 않아도 해당 폰트로 텍스트가 표현된다.
'눈누'나 '구글폰트' 사이트에서 무료 웹폰트를 확인 및 내려받을 수 있다. 어도비에서도 유료로 다운이 가능하다.
단점으로는 용량이 크기때문에 트래픽 증가를 불러올 수 있다는 점이 있다. (해결책이 있는데 아래에서 다루겠다)
눈누 : https://noonnu.cc/
구글폰트 : https://fonts.google.com/
■ 이미지폰트
포토샵 등의 그래픽 툴을 통해 원하는 폰트로 텍스트를 쓴 뒤 그 이미지를 서버에 업로드 하여 내보내는 방식이다. 이 역시 사용자의 디바이스에 해당 폰트가 없어도 그 폰트로 쓴 텍스트를 볼 수 있게 만든다.
주의할 점은 용량과 화질 저하에 대한 부분이다.
이미지가 몇개 안될때는 상관없지만 이미지가 많아지면 용량이 커짐으로서 트래픽 증가를 불러올 수 있다.
또한 많은 디바이스의 크기에 대응할 수 없다는 단점이 있다. 모바일의 경우 ios를 포함한 요즘의 많은 디바이스는 고해상도 디스플레이를 가지고 있다. 이런 스마트폰에서는 1배수 이미지를 사용할 경우 화질이 저하되어 가독성이 떨어진다. 물론 3배수 이상의 고화질 이미지로 업로드 하면 보완할 수 있지만 용량에 대한 고민이 추가로 필요하다. 그리고 텍스트를 수정하는 과정도 번거롭다.
2) 웹폰트의 용량에 대하여
웹폰트로 진행하기로 결정했다면 용량에 대해서도 고민하고 넘어가는것이 좋다.
서버에 올라가는 모든 파일은 서비스 로딩 속도에 영향을 끼치는데 이는 곧 사용자의 만족도와 연결되기 떄문이다.
■ 웹폰트는 용량이 크다
웹폰트는 서버에서 다운받아 화면에 내보내는 방식이기에 사용자의 디바이스 화면에 노출되기까지 다운받는 시간이 걸린다. 그런데 웹폰트 파일이 용량이 크다보니 사용자의 인터넷 환경에 따라 소요되는 시간이 길어질 수 있다. 특히 우리 서비스의 타겟이 저가형 폰을 많이 사용하는 집단이라면 최대 10초까지도 소요될 수 있음을 인지하고 해결책을 고민해야 한다.
물론 폰트를 못불러온다고 해서 페이지의 내용이 아예 안나오는건 아니다. 사용자의 디바이스에 기본으로 탑재되어 있는 폰트로 텍스트가 표현되었다가 폰트 다운로드가 끝나면 해당 폰트로 변환된다.
이 과정에서 사용자는 이질감을 느낄 수 있을뿐더러 해당 행위가 페이지 로딩 시간 자체를 느리게 할 수도 있다. 그렇다면 디자이너는 어떤것들을 확인해야할까?
■ 그러니 웹폰트를 경량화 한다
웹폰트를 경량화 하는 방법은 3가지정도가 있다.
상황에 따라 3가지 중 한가지만 적용해도 되지만 가능하면 3가지 방법 모두 적용하는것이 좋다.
최악은 이중 아무것도 적용하지 않는 것이다.
첫번째, 서브셋을 사용한다.
서브셋은 쓰지 않는 한글 조합들을 제거하여 폰트의 갯수를 줄인 것을 말한다. 서브셋을 제공하는 대표적인 한글 폰트로는 '노토산스' 나 '스포카 한 산스'가 있다.
두번째, 고객 디바이스에 맞는 포맷의 폰트를 사용한다.
폰트는 TTF, OTF, WOFF, WOFF2, EOT 같은 여러개의 확장자를 가지고 있다.
(이 확장자들의 차이에 대해서는 추후 따로 다루겠다. 지금은 그냥 그렇구나 하고 넘어가면 된다)
이 중 웹폰트를 사용하기 위해 무엇을 선택해야 하냐면, 결론은 정답이 없다. 내가 만드는 서비스의 고객군의 디바이스에 맞춰 결정해야 한다.
일단 속도면에서는 WOFF2가 가장 좋다. 압축률이 가장 높기 때문이다. (woff보다 3~50%의 압축률이 우수하다고 한다.) 하지만 모든 브라우저를 지원하는 것은 아니기에 지원하는 브라우저와 버전을 확인해야 한다.
그 다음으로 속도가 빠른건 WOFF이다. 이 역시 브라우저 지원을 확인해야한다. WOFF2보다는 지원범위가 넓다.
이렇게만 보면 무조건 WOFF나 WOFF2를 이용하면 될 것 같다. 하지만 그렇지 않다. 고려해야 하는 기준이 또 하나 있다.
브라우저를 탄다는 말은 웹뷰를 기준으로 한다는 말이다. 그렇기에 웹이나 모바일웹, 웹뷰앱, 하이브리드앱 등에서는 위를 기준으로 하면 된다. 하지만 네이티브 앱일 경우 안드로이드는 WOFF를 지원하지 않는다. TTF만 지원하는데 TTF는 WOFF처럼 압축하지 않기에 속도면에서 느릴 수 있다.
세번째, 폰트의 굵기 타입 중 필요한것만 사용한다.
폰트를 다운받으면 굵기가 다양하게 있다. 그 굵기를 모두 사용하고자 한다면 모두 다 서버에 올려야 한다. 이는 좋은 방법은 아니다. 디자인 시 정보를 구조화 할 때 폰트 굵기간의 차이가 너무 다양하면 오히려 정보 습득에 부정적 영향을 미친다. 그보다는 크기를 다양하게 하는것이 좋다. 그러니 꼭 필요한 2~3개 정도의 굵기만 사용하는 것이 디자인할때도 좋고 사용자의 속도 환경 개선에도 좋다.
'Medium' 과 'bold' 정도만 써도 충분하며 추가로 'Regular' 나 'Light'중 하나를 추가하는 것도 좋다.
웹/앱 디자인 시
필요한 폰트 구성
가이드를 만들때 중요한건 '작업하는 모든 사람이 이해하기 쉬운 구조'로 만드는 것과 '통일성'을 지키는 것이다. 이 두가지는 가이드를 만드는 이유이기에 계속 상기해야 한다.
텍스트는 콘텐츠 안에서 헤드라인, 타이틀, 바디 등의 명칭으로 구성되는데 이 명칭을 처음부터 잘 정해야 한다. 이게 곧 구조가 되고 통일성이 되기 때문이다.
■ 헤드라인 (필수)
특정 정보의 머리가 되는 정보를 말한다. 크기는 6개정도 만들어두면 좋다.
크기에 대해서는 'H1,H2,H3...'이렇게 뒤에 순서대로 번호를 붙이거나 'H48, H34, H24..' 이렇게 폰트 크기를 붙이는 경우도 있다.
네이밍도 headline이라고 쓰는가 하면 Headline, Heading, H, title 등등 자유롭다.
사이즈는 [머터리얼 디자인 가이드] 에서는 96, 60, 48, 34, 24, 20 으로 제시하는데 꼭 지킬 필요는 없다. 머터리얼 가이드의 경우 영문이 기준이고 웹과 모바일 모두 통용한 것이다. 우리가 어떤 서비스를 만드느냐에 따라 정보구조도 다르고 그에 따라 시각적 표현도 달라지기에 비율 등에 대해서 참고만 해도 충분하다.
내가 만드는 서비스의 특성과 디바이스의 종류, 그리고 타겟 연령, 환경 등에 맞춰서 '우리 서비스에게 적합한' 폰트 구성을 만들면 된다.
■ 서브헤드라인 or 서브타이틀 or 타이틀 (선택)
먼저 '서브헤드라인'은 '헤드라인'과 어떻게 구분을 줄 것인지를 명확히 하는 것이 좋다.
주로 서브헤드라인은 정보의 머리와 내용 사이에 들어가는 중간 머리 정보를 말한다. 컨텐츠 아티클이 여러개로 쪼개지는 경우 유용하게 쓰인다.
필수가 아닌 선택으로 둔 이유는 서비스의 정체성이나 목적, 고객에 따라 정보 구성이 달라질 수 있기 때문이다. 주로 커머스처럼 제품 위주인 곳보다는 컨텐츠 위주인 곳에서 서브타이틀을 만들어주는 것이 좋다.
갯수는 'Sub Headline 1' ~ 'Sub Headline3' 정도로 최대 3개를 넘어가지 않는것이 좋다.
헤드라인과 바디 사이에서 서브타이틀이 너무 많이 쪼개어 지면 정보 간의 시각적 계층이 두드러지지 않아 정보 습득에 어려움을 줄 수 있기 때문이다.
(단, 조심할 사항이 있다. 위의 이야기는 시각적 크기만 고려했을 때 적용되는 이야기이다. 구분의 목적을 시각적 표현에만 두는것이 아닌 목적에 따른 표현에 둔다면 헤드라인과 서브 헤드라인의 크기가 서로 겹칠수도 있다. 이럴땐는 서브 헤드라인의 크기가 3개 이상이 될 수도 있다. )
■ 바디 (필수)
바디는 가장 많은 정보를 품고있는 컨텐츠의 뭉치를 말한다.
크기 갯수는 3가지 정도면 충분하다. 실무에서 막상 쓰면 1~2개정도만 쓰게 된다. 그럼에도 3개를 만들어두는건, 서비스를 운영하고 개선하고 기능이 추가되면서 어떤 정보 계층구조가 추가될지 모르기 때문이다.
네이밍은 주로 'body', 'paragraph' 등으로 쓴다.
■ 라벨 (필수)
라벨은 input form과 함께 쓰이는 타이틀을 말한다.
크기 갯수는 2~4개 정도 만들어두면 좋은데 막상 해보면 폼은 회원가입, 주문하기 등 일부에만 쓰이기에 1개만 쓰이는 경우가 많다. 그럼에도 위의 바디와 같은 이유로 추가로 만들어두면 좋다.
■ 버튼 (필수)
버튼은 버튼안에 쓰이는 텍스트를 말한다.
이걸 정의하기 위해서는 무엇을 버튼으로 정의할것인지를 먼저 정립하는 것이 좋다.
나같은 경우는 '클릭 후 어떤 액션을 하게 만드는 것'은 모두 버튼으로 정의하고 있다.
버튼 설계는 조금 까다로운 편에 속한다. 화면을 만들면서 버튼이 얼마나 많이 나올지도 알 수 없고 버튼별로 어떻게 목적을 구분하고 중요도를 구분할지도 미리 알수는 없기 때문이다. 또한 앞으로 운영 및 기능 개선, 추가등을 통해 어떤 새로운 버튼이 추가될지도 알 수 없다. 이런 이유로 버튼은 처음부터 최대한 많은 변수를 고려하여 다양하게 만들어두는 것이 좋다.
기본적으로 사용되는 곳은 '회원가입' 이나 '구매' 등의 cta(Call To Action)버튼, '우편번호 찾기' 나 '인증번호 받기' 등의 '보조 버튼이 있다. '신상만모여', '인스타맛집' 같은 클릭하면 넘어가는 태그 형태의 버튼도 고려해두면 좋다.
또한 이 버튼들은 모두 기본상태, 클릭 후의 상태, 클릭을 못하는 상태 등 각종 상태별로도 구분되어야 한다.
■ 기타 (선택)
헤드도 아니고 서브헤드도 아니고 그렇다고 바디도 아니며 또 라벨이나 버튼이 아닌 경우가 있을 수 있다. 그게 무엇인지는 서비스별로 다르기에 알 수 없다. 이건 화면을 만들어가면서 추가하는 것이 좋다.
이제 폰트를
가이드화 해보자
폰트를 가이드화 하는 과정을 예시를 통해 풀어보면 아래와 같다.
생생한 예시를 위해 '10대~20대 초반 여성'을 타겟으로 한 '문구류 커머스 모바일 웹'을 '리뉴얼'한다는 설정을 해보겠다.
■ 폰트를 지정한다.
우리 서비스와 고객 환경을 고려한 폰트를 지정한다.
모바일의 생명은 속도이다. 빠른 속도를 위해 이미지 폰트가 아닌 웹폰트를 사용하기로 한다.
서체는 'spoqa han sans neo'를 사용하고자 한다.
■ 폰트 경량화를 한다.
해당 폰트의 서브셋 파일을 준비한다.
본격적으로 내부 데이터를 확인해보니 접속 비율이 가장 높은 os는 안드로이드이며 주요 기기는 갤럭시 저가형폰으로 분석된다.
저가형폰은 고성능 폰이 아니기에 폰트로 인한 성능저하를 최소한으로 해야한다. 적합한 확장자는 WOFF2이지만 안드로이드는 WOFF2 폰트를 쓸 수 없다. 아쉬울 뻔 했으나 다행히 우린 네이티브 앱이 아닌 모바일웹이기에 WOFF2를 쓸 수 있다.
기쁜 마음으로 스포카 한 산스 서브셋 파일 중 WOFF2를 준비한다.
폰트 굵기는 medium과 bold만 사용하는 것으로 했다.
■ 폰트 구성을 짠다.
커머스는 제품 위주이다. 또한 10대~20대의 경우 디지털 세대라서 글자를 읽는 세대가 아니라 보는 세대라는 트렌드 리포트가 있다. 그들은 글자가 아닌 영상이나 이미지를 통해 정보를 확인한다.
그러니 글자로 구구절절하게 가치를 전달하는 일은 해당 서비스에서는 없을 예정이다.
이런 점을 고려하여 서브헤드라인을 제외하고 헤드라인 3가지, 바디 2가지, 버튼 4~5가지, 라벨 2가지 정도로 설계하면 될 것 같다.
작업하면서 추가되거나 오픈 후 운영 및 개선에 따라 추가할 것을 고려하여 설계에 들어간다.
■ 가이드는 상세하게 만든다.
설계한 것들을 시각적 문서로 만든다. 이 때 상세한 가이드를 같이 적어두었다.
헤드라인은 어떨 때 쓰이고 바디는 어떨때 쓰이며 예외일땐 어떻게 하는것이 좋은지 등등에 대한 이야기이다. 자세할수록 커뮤니케이션 오류를 줄일 수 있기에 예상할 수 있는 모든 모호한 부분들에 대해 적어두었다.
'헤드라인은 해당 페이지의 목적을 안내할 때 쓴다. 또한 해당 페이지 내에서 쓰인 정보를 함축적으로 안내하는 텍스테에서 쓰이며 한 페이지에서 중첩 사용할 수 없다.' 등으로 작성하였다.
■ 개발팀과 피드백을 주고받는다.
준비한 폰트와 가이드를 개발팀에 전달하고 미팅 일정을 잡아 설명하였다.
특히 폰트의 구조화에 대한 이유와 목적을 설명하는데 집중했다. 그러면 개발단에서도 그걸 참고하여 모듈화 해놓을 수 있기 때문이다. 네이밍을 맞추는 등의 이야기도 나누었다.
더불어 디자인 하면서 추가 및 수정되는 내용들에 대해서 어떻게 개발팀에 안내할지에 대해서도 이야기 했다. 피그마에서 코멘트를 남기고 코멘트의 형식도 정했다.
'[스타일가이드 보완] 버튼 텍스트 1개 추가' 라고 남겨놓기로 했다.
궁금한게 있으면 개발자에게 물어보기도 하고 의견을 반영하기도 하면서 보완해 나가야 한다. 개발자와 사이좋게 지낼수록 가이드의 퀄리티는 좋아진다.
왜냐면 지금 만드는 이 디자인 시스템 가이드가 가장 필요한 직군이 디자인과 개발이기 때문이다.
■ 에셋화 한다.
피그마, 스케치, xd등에서 제공하는 에셋화를 이용하여 가이드를 에셋화 한다.
이제 본격 화면 작업에 들어간다.
디자인 가이드 중 '폰트 가이드'에 대한 이야기를 해보았다.
위에서 이야기한 것 처럼 폰트는 색상만큼이나 탁월한 사용자 경험에 중요한 역할을 한다.
사용자가 '매끄러운 정보 습득'을 잘 할 수 있게 해주기 때문이다.
이렇게나 중요한 '폰트' 에 대한 가이드를 만들 때 막막하다면 나의 이야기가 도움이 되길 바래본다.
웹/앱 디자인 가이드 시리즈
최소한의 웹/앱 디자인 가이드를 만드는 4가지 방법
https://brunch.co.kr/@kkokkodaec/6
앱/웹 디자인 가이드 제작 - 01. 컬러 가이드
https://brunch.co.kr/@kkokkodaec/5
