2022-11-05 [프롬디자이너] UX/UI 해외 인기 아티클 스터디 7기 중 1주차 발표자료입니다. - 작업을 깔끔하게 유지해줄 6가지 피그마 규칙 - 디자인 시스템 색상표의 "진한 노란색 문제” - 보다 빠른 디자인-개발 핸드오프를 위한 접근성을 준수하며 조화로운 타이포그래피 시스템을 만드는 프레임워크

1. 이민호
해외 인기 아티클 7기
2022년 7월 1주차 아티클 작업을 깔끔하게 유지해줄 6가지 피그마 규칙
디자인 시스템 색상표의 진한 노란색 문제
보다 빠른 디자인 개발 핸드오프를 위한 접근성을 준수하며 조화로운 타이포그래피 시스템을 만드는 프레임워크

2. 작업을 깔끔하게 유지해줄 6가지 피그마 규칙
https://bootcamp.uxdesign.cc/6 figma rules to keep your work clean 351cd53a6f24

3. 1. 피그마 파일에 커버 이미지를 추가하세요
Add a cover photo to your Figma file
다양한 프로젝트와 피그마 파일을 관리하다 보면,
원하는 프로젝트를 빠르게 찾기 어려울 때가 있습니다.
피그마 파일에 Cover photo를 설정하면 도움이 됩니다.
다음과 같이 설정해주세요.
1 프레임을 추가하고 이름을 cover 로 해주세요.
2 브랜딩이 잘 반영된 커버 이미지를 등록하고, 파일 이름을 추가해주세요.
3 프레임을 오른쪽 클릭하고 Set as thumbnail 을 선택해주세요.
발표자 코멘트 커버 이미지에 프로젝트에 대한 간략한 정보를 추가하거나, 색상 등을 통해 카테고리 구분을 해주면 편리합니다.

4. 2. 페이지에 체계적으로 이름을 붙여주세요
Give names to all Pages systematically
모든 페이지에는 이름이 있어야 합니다.
그리고 아이콘처럼 프로젝트를 인식하는데 도움이 되는 표시를 추가하는 것이 좋습니다.
다음과 같이 해보세요.
1 ⇒ 아이콘을 눌러서 페이지를 추가합니다.
2 페이지를 더블클릭해서 페이지 이름을 변경할 수 있습니다.
3 이모지를 추가하고 적절한 페이지 이름을 작성합니다.

5. 3. 모든 항목에 스타일을 정의하여 사용하세요
Use styles for everything
디자인할 때 공통 스타일을 정의하여 디자인하다가 다양한 색상, 획, 폰트 스타일 등을 수정해보고 싶다면,
간단한 수정만으로 디자인이 적용된 모든 인스턴스에 수정사항이 반영되게 할 수 있습니다.
색상 선택 도구로 직접 수정하는 대신, 색상 스타일을 사용하여 변경사항을 빠르게 반영할 수 있도록 하는 것을 추천합니다.
색상 스타일을 빠르게 만들기 위해서는 다음과 같이 해보세요
1 먼저 Styler 플러그인을 추가합니다.
https://www.figma.com/community/plugin/820660579767995949

6. 3. 모든 항목에 스타일을 정의하여 사용하세요
Use styles for everything
2 모든 레이어 이름을 변경합니다.
여러 레이어를 한 번에 선택한 다음 Rename 을 선택합니다. Cmd/Ctr R
색상 그룹 이름에 번호를 붙여서 변경합니다.
Primary/ N00 Primary/1000, Primary/900, Primary/800, …
Primary/ n00 Primary/100, Primary/200, Primary/300, …

7. 3. 모든 항목에 스타일을 정의하여 사용하세요
Use styles for everything
3 스타일로 정의하려는 색상들을 선택한 다음, Plugin Styler Generate styles 를 실행합니다.

8. 3. 모든 항목에 스타일을 정의하여 사용하세요
Use styles for everything
항목을 선택한 다음 Fill 우측에 있는 Style 버튼 ⇒ 아이콘 왼쪽에 있는 버튼 을 누르면
색상 스타일을 선택할 수 있습니다.
스타일을 적용한 이후에는, 원본 스타일을 수정하면 연결된 항목들이 모두 일괄 변경됩니다.

9. 4. 컴포넌트를 사용하세요
Use of Components
다양한 종류의 버튼이나 인풋 필드들이 있다면
작업할 때 엄청난 시간이 소요될 겁니다.
컴포넌트를 사용하면 이러한 문제를 해결하는데 도움이 됩니다.
메인 컴포넌트는 컴포넌트의 속성을 정의합니다.
인스턴스는 재사용 할 수 있는 컴포넌트 복사본입니다.
인스턴스는 메인 컴포넌트에 연결되어 있어서
컴포넌트의 변경사항이 반영됩니다.
컴포넌트를 만들기 위해 중앙 상단의 아이콘을 클릭합니다.
컴포넌트 하나를 생성하거나
여러 컴포넌트를 동시에 생성할 수 있습니다.

10. 4. 컴포넌트를 사용하세요
1 Create a single component
1 컴포넌트에 포함시킬 레이어를 모두 선택해주세요.
2 컴포넌트를 생성하기 위한 여러 방법 중 하나를 선택해주세요.
toolbar 에서 Create Component 를 클릭합니다.
메뉴에서 Object Create Component 를 클릭합니다.
선택한 레이어에 오른쪽 클릭 후 Create Component 를 클릭합니다.
피그마는 특별한 컴포넌트 프레임 안에 레이어를 배치하게 됩니다.
Layers 패널에서 보라색 아이콘으로 표기됩니다.
컴포넌트를 선택하면 우측 사이드바에서 컴포넌트에 대한 설명과 문서 링크를 추가할 수 있습니다.
등록한 정보는 Inspect 패널에서 확인할 수 있습니다.

11. 4. 컴포넌트를 사용하세요
2 Create components in bulk
1 컴포넌트로 만들고자 하는 레이어를 모두 선택합니다.
2 툴바에서 Create multiple components 를 선택합니다.
3 각 프레임, 그룹, 불리언 연산 Boolean operation , 패스 단위로 컴포넌트가 생성됩니다.

12. 5. 플로우 차트를 만드세요
Create flow diagrams from your screens
디자인 파일이 거대해질수록 다른 팀원이나 클라이언트들이 내용을 파악하는데 어려움을 겪을 수 있습니다. 따라서 플로우를 깔끔하게 정리해야 합니다.
흐름을 표시할 수 있도록 펜 도구를 사용해 프레임 사이에 화살표를 추가해보세요.
발표자 코멘트 피그마 플러그인 Autoflow를 사용하면
두 오브젝트 사이에 화살표를 쉽게 추가할 수 있습니다.
https://www.figma.com/community/plugin/733902567457592893/Autoflow

13. 6. 항상 사본을 만들어두세요
Always create a copy file
안전한 작업을 위해
항상 원본을 어딘가에 복사해두세요.
작업 중에 어떤 문제가 발생할지 모릅니다.
복사는 간단합니다.
파일을 오른쪽 클릭하고, Duplicate 를 선택하세요.

14. 디자인 시스템 색상표의 진한 노란색 문제
https://uxdesign.cc/the dark yellow problem in design system color palettes a0db1eedc99d

15. 디자인 시스템에서 색상 팔레트를 정의하다가, 노란색과 노란색 사이의 균형을 잡으면서 접근성 요구사항을 만족해야 하는 진한 노란색 문제 를 발견했습니다.
목표는 간단합니다 :
WCAG에서 정의한 상대적 휘도 Relative Luminance 가 서로 가까워지도록 메인 색상을 정의하는 것입니다.
이렇게 하면 상태 색상을 바꾸더라도, 디자인 시스템에 의해 색상 대비 비율 color contrast ratio 이 접근성 요구사항을 만족하도록 보장할 수 있습니다.
Introduction
https://contrastchecker.online/color relative luminance calculator
IN PROGRESS 태그가 FINISHED 태그보다 더 강조되는 것을 원하지 않을 때,
상대적 휘도를 가이드로 삼으면 비슷한 수준으로 강조하는데 도움이 됩니다.

16. Problem
그런데 노란색에 동일한 기준을 적용하려고 하니 문제가 발생했습니다.
다른 상태 색상들이 모두 0.15 정도의 상대적 휘도를 가지는데, 노란색으로는 도저히 0.15를 맞출 수 없었습니다.

17. Problem
노란색을 어둡게 해봤지만, 그러면 갈색이 됩니다.
신호등의 색상 체계 빨간색은 나쁨, 노란색은 경고, 초록색은 좋음 에 익숙한 사람들에게는
오히려 혼란을 줄 수 있습니다.

18. Problem
노란색의 색조를 변경하면 색상이 살짝 초록색이나 빨간색에 가까워집니다.
이것도 역시 보는 사람을 혼란스럽게 할 수 있습니다.
이것이 바로 진한 노란색 문제 입니다.
접근성을 챙기면서 팔레트 내 다른 색상과 정렬할 수 있도록 노란색 음영 Shade 을 만들려고 했습니다.
하지만 짙은, 진한 노란색 이라는 건 없습니다.
노란색은 그 정의에 맞게 밝게 유지되어야 합니다.

19. 노란색 자체를 바꿀 수는 없습니다. 그래서 노란색이 사용되는 방식을 통제하는데 집중하기로 했습니다.
다른 색상과 달리 노란색 조금 더 넓게 보면 오렌지색까지 은 다음과 같은 형태로 사용해야 합니다.
1 전경색 foreground color 으로 사용해서는 안되며
2 근처에 어두운 요소 없이 단독으로 사용해서는 안됩니다.
Solution

20. Solution
1 No Foreground Yellow
노란색은 흰색이나 밝은색 배경과 함께 사용할 수 없습니다.
개인적으로 어두운 노란색 음영 갈색 을 텍스트로 사용할 것을 권장합니다.

21. Solution
2 Accompanied Dark Element
노란색 요소는 그 의미를 분명하게 하기 위해 더 어두운 shade가 포함된 UI 요소와 함께해야 합니다.

22. Solution
2 Accompanied Dark Element
공간이 부족한 대시보드 같은 영역에서는 색상이 여러 개 포함된 아이콘을 사용하거나, 아예 아웃라인이 존재하는 아이콘을 사용하는 것도 방법입니다.

23. Solution
2 Accompanied Dark Element
데스크탑에서는 노란색이 눈에 띄지 않다가 사용자가 액션을 하기 전에 경고하는 방식으로 사용할 수도 있습니다.
Default Hover Click

24. Three Shades of Yellow
메인 팔레트를 정의할 때 각 색상에서 Light, Main, Dark의 3가지 shade를 정의합니다.
이 방식은 MUI의 테마 구조에서 아이디어를 가져왔습니다.
노란색은 다른 색과 비교했을 때 사용 방법이 다르기 때문에, Main 과 Dark 의 색상 차이가 더 뚜렷합니다.

25. Three Shades of Yellow
색상 범위를 50에서 900까지 숫자로만 표현해서 구분하는 대신 토큰 형태로 사용할 경우,
노란색을 다른 UI 색상과 함께 사용할 때 어떤 점을 주의해야 하는지 쉽게 정리할 수 있습니다.

26. 보다 빠른 디자인 개발 핸드오프를 위한
접근성을 준수하며 조화로운 타이포그래피 시스템을 만드는 프레임워크
https://blog.prototypr.io/10 practical steps to create a predictable accessible and harmonious typography system a case 6c85d901bedd

27. Introduction
Practice Fusion 에서 EHR 건강 기록부 제품을 개발할 때,
접근성을 만족하면서도 그리드와 조화를 이루는
타이포그래피 시스템을 만들기 위해 사용했던
10단계 과정을 소개합니다.
기존의 타이포그래피 시스템에서는 색상과 폰트 굵기 조합까지
포함하여 50개가 넘는 타입 스타일이 있었지만,
새로운 시스템에서는 6개의 타입 스타일만 정의하게 되었습니다.
새로운 시스템에서는
개발자와 디자이너 모두의 관점에서 봤을 때
타이포그래피 사용 규칙이 보다 예측 가능한 형태로 구성됩니다.
제품의 가독성을 개선하고 일관성을 유지하는데 도움이 됩니다.

28. 10 PRACTICAL STEPS
제품을 분석하여 의미적인 위계를 확인하세요
시각적인 위계를 조사하세요
본문 텍스트를 위한 기본 폰트 크기를 결정하세요
본문 폰트 크기와 잘 어울리는 줄 높이를 결정하세요
여러 개의 조화로운 폰트 크기를 구할 수 있도록 적당한 모듈러 스케일 비율을 고르세요
h1을 정의하는 것부터 시작하세요
헤더 레벨이 몇 개나 필요할지 결정하고 각각의 값을 결정하세요
모든 폰트 크기에 대한 줄 높이를 정의하세요
헤더의 폰트 굵기를 결정하세요
타입 시스템을 모든 페이지에 적용할 때 DOM 아웃라인에 대해 고민하세요 탑다운 접근으로
이 중에서 Step 1과 2는 이미 존재하는 타이포그래피 시스템을 다시 정의해야 할 때만 유효한 단계입니다. 아예 처음으로 시작하는 거라면 Step 3 부터 시작하세요.
여기서는 어떤 타입페이스를 사용할지 이미 결정했다고 가정합니다. 타입페이스를 어떻게 선택해야 하는지에 대해서는 언급하지 않습니다.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10

29. Step 1 제품을 분석하여 의미적인 위계를 확인하세요
Audit product for semantic hierarchy
WAVE 크롬 플러그인을 설치하여 각 페이지의 DOM 구조를 조사합니다.
조사 결과 의미적 위계 Semantic hierarchy 가 명확하지 않았습니다.
페이지의 최상단 헤더로 h5 또는 h3를 사용하고 있었습니다.
어떤 페이지에서는 테이블 헤더로 h6를 사용하기도 했습니다.
h1 태그는 어디에서도 사용하지 않았습니다.
이상적으로는 h1, h2, h3 이 순서대로 등장해야 합니다.
그리고 단계를 스킵하지 않는 것이 좋습니다.
https://chrome.google.com/webstore/detail/wave evaluation tool/jbbplnpkjmmeebjpijfedlgcdilocofh

30. Step 2 시각적인 위계를 조사하세요
Inspect visual hierarchy
기존에 페이지에서 사용하고 있는 모든 폰트 크기와 폰트 굵기를 내림차순으로 나열합니다.
이 때 헤더 레벨 h1, h2, h3, … 은 의도적으로 무시합니다. 시각적으로 보이는 위계에 더 집중합니다.
관찰한 결과는 다음과 같습니다.
문제점
1 헤더 종류가 너무 많습니다 :
DOM 아웃라인 상의 정보 위계를 분석한 결과를 보면 이렇게 많은 헤더 종류가 필요하지 않습니다.
2 이름 붙지 않은 자잘한 값이 너무 많습니다 :
만약 논리적으로 의미가 있는 이름을 붙일 수 없다면, 명확한 의미 없이 사용되고 있다는 것을 의미합니다.

31. Step 3 본문 텍스트를 위한 기본 폰트 크기를 결정하세요
Determine base font size for body text
저희 제품에서는 본문의 텍스트 크기를 13px 로 결정했습니다.
그 이유는 기존의 값이 13px 이었으며, 이렇게 사용했을 때 정보 집약적인 저희 시스템에서 잘 동작했기 때문입니다.
잘 동작하고 있는 것을 굳이 변경할 필요는 없었습니다.
적절한 폰트 크기는 선택한 폰트 종류에 따라 달라집니다.
하지만 보통 10pt 를 최소로 봅니다. 10pt를 px로 환산하면 대략 13px 정도가 됩니다.

32. Step 4 본문 폰트 크기와 잘 어울리는 줄 높이를 결정하세요
Determine line height that works for body font size Goldilocks approach
이 단계에서는 시각적으로 많은 탐색을 해야 합니다.
1 처음에는 font size: 13px line height: 16px 로 시작했습니다.
이후에는 font size / line height 형태로 표기합니다.
일반적으로 사용하는 8pt 단위의 베이스라인 그리드를
사용할 수 있을지 살펴보고 싶었고,
이 경우 16px의 line height 는 적절한 후보군이었기 때문입니다.
탐색 과정을 통해 해당 선택이 적절한지 확인할 수 있습니다.
2 16px의 line height 는 너무 좁아보입니다.
그래서 8px을 더해 24px 로 확인해보니 너무 간격이 넓습니다.

33. Step 4 본문 폰트 크기와 잘 어울리는 줄 높이를 결정하세요
Determine line height that works for body font size Goldilocks approach
3 그렇다면 16에서 24 사이의 값을 골라야 합니다. 그 중에서 짝수 값 18, 20, 22 을 사용하기로 결정했습니다.
이 값은 다른 값들로 나누어 떨어지는데, 해당 값은 여백 간격의 기준으로 활용할 수 있습니다.
18px을 선택하면 6pt 베이스라인 그리드를 사용하게 됩니다.
표기해야 할 정보의 양이 많은 상황에서는 6pt 베이스라인 그리드를 사용했을 때 정보가 너무 밀집된 상태로 표기될 우려가 있습니다.
또한 18px을 선택할 경우 첫 번째 줄의 descender 가 두 번째 줄의 ascender 와 너무 가까워집니다.
22px 은 2와 11로만 나누어지기 때문에 후보군에서 제외했습니다.

34. Step 4 본문 폰트 크기와 잘 어울리는 줄 높이를 결정하세요
Determine line height that works for body font size Goldilocks approach
4 그래서 결국 20px 의 line height 를 사용하기로 결정했습니다.
20은 4의 배수이기 때문에 4pt 베이스라인 그리드를 사용할 수 있습니다.
시각적 구분을 위해 결과적으로 8의 배수를 주로 사용하긴 했지만, 4의 배수를 기반으로 하기 때문에 더 많은 선택지를 가질 수 있었습니다.
결과적으로 13px의 본문 크기와 20px 의 줄 높이를 사용하는 것으로 최종 결정했습니다.
13/20 이라는 기준은 WCAG Success Criterion 1.4.8 Line spacing 은 적어도 단락의 1.5배가 되어야 합니다 에도 부합합니다.
13/20 은 줄높이 비율이 1.538 로 매우 적절합니다.

35. Step 5 여러 개의 조화로운 폰트 크기를 구할 수 있도록 적당한 모듈러 스케일 비율을 고르세요
Pick a ratio for the modular scale such that you have enough number of harmonious usable values
서로 다른 폰트 크기들이 조화를 이룰 수 있도록 Modular Scale을 사용합니다.
디자인 시스템에 맞는 스케일 비율을 찾아야 합니다.
줄 높이 line height 값인 20px 에서 시작하는 것도 좋은 방법입니다.
본문의 줄 높이 비율은 20 / 13 1.538 입니다.
하지만 해당 비율을 사용했을 때는 너무 퍼져보이는 것을 확인했습니다.
112px, 73px, 48px 같은 값은 정보가 밀집된 레이아웃에서 사용하기에 너무 큰 헤더 크기였습니다.
보다 타이트하지만 여전히 20px 을 포함하는 다른 비율을 찾아보기로 했습니다.
20px 을 포함하게 되면 본문의 줄높이와 리듬을 유지하게 됩니다.
major third 비율 1.25 을 선택하니 현실적으로 사용할 수 있는 값들이 도출되었습니다.
가능한 경우에는 4의 배수로 반올림했습니다.
이렇게 하면 4pt 베이스라인 그리드를 바탕으로 했을 때 보다 예측 가능한 값이 됩니다.
결과적으로 타입 스케일로 활용할 수 있는 조화로운 폰트 비율을 확보했습니다 :
40, 32, 24, 20, 16, 13, 11, 8px
https://www.modularscale.com/

36. Step 6 h1을 정의하는 것부터 시작하세요
Start with defining h1
항상 접근성 기준을 준수할 수 있도록 h1 태그부터 시작합니다.
이상적으로는 어떤 일이 있어도 h1 태그를 생략하지 않는 것이 좋습니다. 아래의 내용은 WCAG의 G.141 테크닉 을 풀어서 설명한 내용입니다.
여러 화면에 걸친 시각적 탐색에 대해 고민할 단계입니다.
어떤 페이지에서는 h1 이어야 하는 정보가 16px regular 의 span 태그로 표현되었으며, 어떤 곳에서는 32px light 의 h5 태그였습니다.
모든 페이지에 걸쳐서 일관적으로 h1 태그에 사용할 수 있는 값이 있을까요?
이전 단계에서 도출한 타입 스케일 중 본문의 폰트 크기보다 큰 값 중에서 적절한 값이 무엇일지 확인했습니다.
h1 태그에 40px, 32px 을 대입했을 때는 너무 큰 값이었습니다. 24px regular 를 대입했을 때 드디어 모든 시나리오에 잘 동작했습니다.

37. Step 7 헤더 레벨이 몇 개나 필요할지 결정하고 각각의 값을 결정하세요
Determine how many header levels you need and values for each
h1 을 정의한 뒤, 제품 내의 다른 레이아웃을 조사해서
헤더 종류가 몇 가지 필요한지 확인해야 합니다.
Practice Fusion 의 EHR 에서는 보통 3가지의 헤더가 필요했지만,
정보가 집약적으로 표시되어야 하는 일부 레이아웃에서
2가지의 헤더가 추가로 필요했습니다.
헤더의 개수를 결정한 뒤 타입 스케일에서 정의한 폰트 크기를 순서대로 적용합니다.
만약 타입 스케일에서 충분한 종류의 폰트 크기를 확보할 수 없다면,
비율을 변경하는 것을 고려해보는 것이 좋습니다.
우리의 제품에서 h5는 라벨, 필드의 범례, 표의 캡션, 컬럼의 헤더 등에
적용되는 것과 동일한 스타일을 적용합니다.
해당 UI 컴포넌트가 시각적 위계에서 가장 끝에 위치하고 있으며
리프 노드 leaf node 라고도 합니다 그 안에 컨텐츠를 담고 있기 때문입니다.
라벨과 같은 리프 노드의 헤더를 사용하면,
사용자들이 봤을 때 해당 값이 정보 계층이 가장 끝에 있다는 것을
명확하게 인지할 수 있습니다.

38. Step 8 모든 폰트 크기에 대한 줄 높이를 정의하세요
Define line heights for all font sizes
모든 폰트 크기에 해당하는 줄 높이는 서로 비례하도록 만들어서 세로 방향의 시각적인 리듬을 유지해야 합니다.
한 가지 방법은 본문의 줄높이 폰트크기 비율을 계산하여 모든 폰트 크기에 적용하는 것입니다.
하지만 이렇게 계산한 값은 베이스라인 그리드 단위의 배수가 아닐 수도 있습니다.
이런 경우에는 계산한 값에서 가장 가까운 베이스라인 그리드 단위의 배수를 선택하는 방법도 있습니다.
2가지의 가능한 줄높이 후보가 잡히면 다양하게 테스트하여 하나를 선택했습니다.

39. Step 9 헤더의 폰트 굵기를 결정하세요
Determining font weight for headers
시각적 위계는 폰트 굵기를 통해서도 명확해질 수 있습니다.
각 헤더 단계에 어떤 폰트 굵기를 설정하는 것이 좋을지 확인하기 위해, 다양한 조합을 시도했습니다.
h3 태그의 16px regular 는 13px regular 와 획의 두께가 비슷해 보였습니다. 이 경우에는 정보가 밀집되어 있는 레이아웃에서 식별하는 것이 어려워집니다.
더 헤더처럼 보이게 만들기 위해 16px semibold 를 적용했습니다. 이렇게 하니 가독성이 훨씬 개선되었습니다.

40. Step 9 헤더의 폰트 굵기를 결정하세요
Determining font weight for headers
h1 태그를 24px light 로 적용하면 눈에 잘 띄지 않게 됩니다. 반면에 24px semibold 는 너무 강조되는 경향이 있습니다.
24px regular 를 사용할 경우 20px regular 나 16px semibold 와 비슷한 획 두께를 가지게 됩니다. 보기에도 나쁘지 않고, 전체적인 위계 구조를 고려했을 때 적절합니다.

41. Step 10 타입 시스템을 모든 페이지에 적용할 때 DOM 아웃라인에 대해 고민하세요 탑다운 접근으로
Think about DOM outline top down approach to apply entire type system to any page
DOM outline 은 텍스트 읽어주기 기능을 사용하는 사람들이 컨텐츠를 넘나들 때 중요한 요소입니다.
가끔 탭이 헤더 역할을 맡게 되는 경우가 있습니다.
이 경우 시각적으로는 해당 탭의 컨텐츠를 위한 별도의 헤더가 필요하지 않습니다.
하지만 화면 리더기 입장에서는 탭을 헤더라고 생각하지 않습니다.
따라서 이 경우에는 명시적으로 헤더를 지정하는 것이 좋습니다.
만약 고객들이 화면 리더기를 사용하지 않을 것이라 확신한다고 해도, DOM outline 에 최대한 의미를 담도록 노력하는 것이 좋습니다.
헤더 레벨을 탑다운 방식으로 일관성 있게 관리할 수 있습니다.
이렇게 하면 헤더 레벨을 건너뛰는 일을 줄일 수 있으며 모든 페이지에서 DOM 구조를 비슷하게 유지할 수 있습니다.
제품의 모든 영역에서 일관성을 유지하는데도 도움이 됩니다.
Android Talkback
Apple VoiceOver

42. Step 10 타입 시스템을 모든 페이지에 적용할 때 DOM 아웃라인에 대해 고민하세요 탑다운 접근으로
Think about DOM outline top down approach to apply entire type system to any page
예시 h2 를 숨겨서 세부적인 정보를 포함했습니다.
h2는 DOM에 포함되어 있지만, CSS를 통해 시각적으로 보이지 않습니다.

43. In conclusion
다음과 같은 효과를 기대할 수 있습니다.
1 시간이 지나면서 누적될 수 있는 중복된 타입 스타일을 제거할 수 있습니다.
2 디자이너가 언제 어떤 유형의 타입을 선택해야 할 지 명확하게 할 수 있습니다.
3 개발자들이 모든 유형을 알고 있기 때문에 디자인에서 개발로 넘어가는 핸드오프가 빨라집니다.
디자이너들이 모든 요소들에 적절한 값을 표시해두지 않아도 되고, 목업에 투입하는 시간을 줄일 수 있습니다.
4 UI를 개발하는 사람들과 QA 담당자가 더 나은 삶을 경험할 수 있습니다.
5 디자이너와 개발팀의 시간을 아껴서 다른 일에 집중할 수 있습니다.
타입 크기와 줄 높이는 퍼즐의 일부분에 불과합니다. 줄 높이 말고도 고려해야 할 공간이 많습니다.

44. 감사합니다 :D
lumiamitie gmail.com