2023-03-04 [프롬디자이너] UX/UI 해외 인기 아티클 스터디 8기 중 1주차 발표자료입니다. - 색상 대비 접근성에 대한 7가지 오해 - UX 리서치 케이스 스터디 : 틴더 - 개발자들에게 사랑받는 피그마 디자인 만들기

1. 이민호
해외 인기 아티클 8기
2022년 9월 2주차 아티클
색상 대비 접근성에 대한 7가지 오해
UX 리서치 케이스 스터디 : 틴더
개발자들에게 사랑받는 피그마 디자인 만들기

2. 색상 대비 접근성에 대한 7가지 오해
디자이너는 모든 사용자가 접근 가능한 인터페이스를 만들어야 한다는 인식이 많아지고 있습니다.
장애가 있는 사용자를 고려하는 것은 중요하지만, 색상 대비 접근성에 대한 잘못된 정보가 널리 퍼져 있습니다.
이러한 이유로 실제로는 문제가 없는데 인터페이스의 접근성이 떨어진다고 오해하는 경우가 있습니다.
이 글에서는 색상 대비 접근성에 대한 잘못된 상식을 바로잡으려고 합니다.
https://modus.medium.com/the myths of color contrast accessibility 4b7fcba77317

3. 오해 1 : WCAG 요구사항은 항상 최적의 기준입니다?
Myth 1 The WCAG requirements are always optimal
웹 콘텐츠 접근성 가이드라인 WCAG 은 접근성을 만족하는 색상 대비를 결정하기 위한 원칙을 제시합니다.
하지만 이러한 가이드라인이 항상 실제 상황에 적합한 것은 아닙니다.
WCAG 표준이 적용되지 않는 사례로 흰색 텍스트의 밝기 대비 문제가 있습니다.

4. 오해 1 : WCAG 요구사항은 항상 최적의 기준입니다?
Myth 1 The WCAG requirements are always optimal
흰색 텍스트의 밝기 대비 문제
아래 두 버튼의 배경은 모두 파란색이지만 하나는 흰색 텍스트, 다른 하나는 검은색 텍스트입니다.
설문조사를 통해 어떤 버튼이 더 읽기 쉬운지 의견을 받으면 대부분의 사람들이 흰색 텍스트가 있는 버튼을 선택합니다.
하지만 접근성 색상 비율 대비값을 보면 다른 결과가 나옵니다. 검정색 텍스트의 대비 비율은 5.41로 기준을 통과하지만 흰색 텍스트는 2.94로 통과하지 못합니다.
흰색과 검은색 버튼 텍스트를 비교한 다른 연구에서도 동일한 결과가 나타났습니다. 정상 시력을 가진 사용자 뿐만 아니라 색맹 사용자도 흰색 텍스트를 더 쉽게 읽었습니다.
Add to cart Add to cart
EASIER TO READ HARDER TO READ
FAILS PASSES
가독성
Contrast ratio: 2.94
Required ratio: 4.5
Contrast ratio: 5.41
Required ratio: 4.5
접근성 기준

5. 오해 1 : WCAG 요구사항은 항상 최적의 기준입니다?
Myth 1 The WCAG requirements are always optimal
흰색 텍스트의 밝기 대비 문제 : 왜 이런 현상이 발생할까요?
이런 현상은 파란색과 주황색 배경에 흰색 텍스트를 사용할 때 발생하는 것으로 보입니다.
흰색은 색조나 채도가 없이 순수하게 휘도로 구성되어 있으며 대비가 가장 강한 형태입니다.
따라서 버튼에 흰색 텍스트를 쓰면 가독성이 높아집니다.
그런데, 텍스트와 배경의 휘도가 모두 높을 때는 밝은 배경에 밝은 텍스트라서 대비값이 낮습니다.
이로 인해 흰색 텍스트의 대비 비율이 실제 가독성을 반영하지 못하는 경우가 발생합니다.
가독성
Add to cart
EASIER TO READ
FAILS
Contrast ratio: 2.91 4.5 Required
접근성 기준
Add to cart
HARDER TO READ
PASSES
Contrast ratio: 5.45 4.5 Required
가독성
접근성 기준

6. WCAG에는 접근성에 대한 다양한 적합도 단계가 있습니다.
어떤 사람들은 모든 텍스트가 최고 수준의 요구 사항 AAA 를 준수해야 하며, 그렇지 않으면 많은 사용자가 접근할 수 없는 인터페이스가 된다고 생각합니다.
AAA 요구사항이 어떻게 만들어진 것인지 살펴보면 이런 생각이 오해라는 것을 알 수 있습니다.
AAA 요구사항은 20/80 이상의 시력 손실을 가진 저시력 사용자를 위해 7:1의 대비 비율을 기준으로 합니다.
AAA 요구사항은 시력 보조 기술을 사용하지 않는 20/80 저시력 사용자를 대상으로 합니다.
해당 그룹에 속하는 사용자 비중은 훨씬 적습니다.
20/80의 시력 손실은 일반인에게는 드물게 발생하며, 대부분 노화로 인한 안과 질환을 앓고 있는 노인에 해당됩니다.
사용자 기반의 대다수가 70세 이상인 경우에는 AAA 요구사항 중 일부를 만족하도록 디자인하면 도움이 될 수 있습니다.
특정 콘텐츠의 경우 AAA 요구 사항을 모두 만족하는 것이 불가능하기 때문에 WCAG에서는 이를 권장하지 않습니다.
오해 2 : 텍스트의 접근성이 최고 수준 AAA 을 만족하지 못하면 접근성이 없는 상태입니다?
Myth 2 Text must meet the AAA requirement, or its inaccessible

7. 오해 2 : 텍스트의 접근성이 최고 수준 AAA 을 만족하지 못하면 접근성이 없는 상태입니다?
Myth 2 Text must meet the AAA requirement, or its inaccessible
대부분의 사용자는 AA 요구사항을 만족하는 것으로도 충분합니다.
AA 요구사항은 20/40 시력을 가진 사용자를 위해 4.5:1 대비 비율을 기준으로 합니다.
연구에 따르면 대부분의 사람들이 80대까지 20/40 이상의 시력을 유지한다고 합니다.
따라서 이 연구 결과에 따르면 AA 요구사항을 만족할 경우 대부분의 사용자가 텍스트를 잘 읽을 수 있을 것이라고 볼 수 있습니다.

8. 오해 3 : 인터페이스 구성 요소의 대비 기준은 텍스트와 동일하다?
Myth 3 Interface components have the same contrast ratio standard as text
많은 사람들이 인터페이스 구성 요소에 텍스트와 동일한 대비 기준을 적용하는 실수를 합니다.
인터페이스 구성 요소의 대비 비율은 3:1 이지만 텍스트는 4.5:1 입니다.
텍스트는 사용자가 읽어야 하기 때문에 더 높은 대비를 요구합니다.
인터페이스 컴포넌트는 읽을 필요가 없기 때문에 기준이 낮습니다.
인터페이스 구성 요소나 텍스트를 대비 비율 기준에 맞추기 전에
올바른 상황에서 적용하고 있는지 확인해야 합니다.
Read only
UI Components
TEXT
Contrast ratio: 3.44 3.0 Required
Contrast ratio: 5.74 4.5 Required
Checkbox
Checkbox label

9. 오해 4 : 회색 텍스트와 버튼은 접근성이 낮고 활성화되지 않은 것처럼 보인다?
Myth 4 Gray text and buttons are inaccessible and look disabled
널리 퍼진 오해 중 하나는 회색 텍스트의 접근성이 매우 낮다는 것입니다.
회색 텍스트는 대비가 낮기 때문에 사용자가 잘 읽을 수 없다고 생각합니다.
하지만 실제로 대비 검사기를 통해 확인해보면 AA 기준을 만족하며, 대비 비율도 상당히 높습니다.
또 다른 오해는 회색 버튼이 대비 기준을 만족하지 못하기 때문에 접근성이 떨어진다는 것입니다.
클릭 영역을 나타내는 시각적 경계는 좋은 버튼을 판단하는 기준에 포함되지 않은 것으로 확인되었습니다.
텍스트가 있는 버튼에 경계면이 존재한다면, 텍스트 대비 이상의 대비 요구사항은 필요하지 않습니다.
따라서 많은 사람들이 접근성이 낮다고 생각하는 회색 버튼도 대비 비율의 기준을 통과합니다.
Add to cart
BUTTON CONTRAST PASSES
TEXT LABEL이 대비 기준을 통과하면
버튼에는 대비 요구사항이 적용되지 않습니다.
TEXT LABEL CONTRAST PASSES
text: #444, 14px / background: #EEE
Contrast ratio : 8.39

10. 오해 4 : 회색 텍스트와 버튼은 접근성이 낮고 활성화되지 않은 것처럼 보인다?
Myth 4 Gray text and buttons are inaccessible and look disabled
텍스트 레이블이 4.5:1 의 대비 비율을 만족하면, 버튼 옆 아이콘은 대비 비율 기준이 필요 없습니다.
하지만 아이콘에 텍스트 레이블이 없을 경우 아이콘에 3:1의 대비 비율 기준을 적용합니다.
ICON TEXT LABEL
Text: #DDD, 16px
Background: #444
Contrast ratio: 7.17 4.5 Required PASSES
ICON Only
Icon: #888
Background: #444
Contrast ratio: 2.75 3 Required FAILS

11. 오해 4 : 회색 텍스트와 버튼은 접근성이 낮고 활성화되지 않은 것처럼 보인다?
Myth 4 Gray text and buttons are inaccessible and look disabled
회색 버튼이 비활성화된 것처럼 보인다는 의견도 있습니다.
이러한 의견은 비활성화 를 표현하기 위한 기호를 제대로 이해하지 못한 결과입니다.
비활성화된 버튼은 텍스트 레이블과 대비를 낮게 둡니다.
버튼이 읽기 어려워지면 사용자가 버튼에 신경쓰지 않게 되고, 이를 통해 비활성화 를 표현합니다.
비활성 컴포넌트에는 대비 비율 요구사항이 적용되지 않습니다.

12. 오해 5 : 색맹 사용자는 대비되는 색상의 차이를 구분할 수 없다?
Myth 5 Color blind users can t tell the difference between contrasting colors
색맹 사용자도 대비의 차이를 인식하는 것은 문제가 없습니다.
색상 대비를 통해 정보를 전달하면 색맹 사용자가 구분하지 못할 것이라고 생각하는 경우가 있습니다.
색상의 색조와 대비는 서로 다른 차원입니다.
색맹 사용자는 특정 색조를 구별하는 것을 어려워하지만 대비는 잘 인식합니다.
예를 들어, 아래 버튼을 보면 한 가지 색상만 사용하며 대비 차이가 충분합니다. 이 경우에는 색맹 사용자도 명확하게 구분할 수 있습니다.

13. 오해 5 : 색맹 사용자는 대비되는 색상의 차이를 구분할 수 없다?
Myth 5 Color blind users can t tell the difference between contrasting colors
색조를 사용해 상태를 구분하는 경우에는 색상 외에 다른 시각적 단서가 있어야 합니다.
색상 대비만 사용하여 상태를 구분하면 색맹 사용자도 문제없이 사용할 가능성이 높습니다.
색맹에는 다양한 유형이 있지만 적녹 색맹에 집중하는 것이 좋습니다.
적녹 색맹은 전체 색맹 중 99 이상의 사용자에게 영향을 미칩니다.
색맹 시뮬레이터를 사용하면 색맹 사용자가 어떻게 보는지 확인할 수 있습니다.
적녹 색맹과 청황 색맹 사용자는 색상 대비를 구별하는데 문제가 없습니다.
녹색과 빨간색의 명도가 거의 같을 때는 적녹 색맹 사용자가 구분하기 어려울 수 있습니다.
예시 Colorblindly Chrome extensions

14. 오해 6 : 색상 단서만으로는 정보 전달에 충분하지 않다?
Myth 6 Using a color cue alone isn t sufficient in conveying information
색상 사용 요구사항 명확하게 이해하기
많은 사람들이 색상 사용 요구사항을 명확하게 이해하지 못한 상태로 인용하고 있습니다.
색상을 정보 전달, 동작 표시, 요소 구분을 위한 유일한 시각적 수단으로 사용해서는 안된다. 고 명시합니다.
하지만 이 기준은 다양한 색상에 특정한 의미를 부여하는 경우에만 적용됩니다.
다시 말해 색상 차이를 통해 정보를 전달하는 경우 추가 단서가 필요하지만
밝기와 어두움을 통해 정보를 전달하는 경우, 대비 차이가 충분히 크면 추가 단서가 필요하지 않습니다.
예를 들어, 다음 토글 버튼은 파란색을 통해 활성 상태를 나타내지만
파란색에 특별한 의미가 있는 것은 아닙니다.
활성 상태라는 것은 색조가 아니라 색상의 대비를 통해 전달되고 있습니다.
활성 상태를 나타낼 때 색조는 임의로 선택할 수 있습니다.
비활성 상태와 높은 대비를 유지하기만 하면 됩니다.
따라서 이 경우에는 색상 사용 요구 사항이 적용되지 않습니다.

15. 오해 6 : 색상 단서만으로는 정보 전달에 충분하지 않다?
Myth 6 Using a color cue alone isn t sufficient in conveying information
색상에 특정한 의미를 부여하는 경우
1 양식 필드에 오류가 발생한 상태
텍스트 필드에서 오류를 나타낼 때 빨간색을 자주 사용합니다.
이 경우 색맹 사용자는 오류 상태를 볼 수 없기 때문에, 빨간색만으로는 오류를 표시하기 충분하지 않습니다.
따라서 오류를 표시하려면 텍스트나 아이콘 같이 추가적인 단서가 필요합니다.
2 색상을 사용해 페이지에서 시스템 상태를 표시할 때
녹색과 빨간색은 시스템 문제의 심각성을 나타내기 위해 종종 사용됩니다.
색조에 의미를 부여하고 있기 때문에 색상 사용 요구사항을 적용합니다.
색맹 사용자가 각 시스템 상태를 구분할 수 있도록 아이콘을 추가해야 합니다.

16. 오해 6 : 색상 단서만으로는 정보 전달에 충분하지 않다?
Myth 6 Using a color cue alone isn t sufficient in conveying information
색상 대비 뿐만 아니라 시각적 깊이도 사용자가 경험하는 단서입니다.
시각적 깊이는 배경과 대비되는 물체가 더 가깝고 강조되는 반면, 대비가 부족한 물체는 더 멀고 차분하게 보일 때 발생합니다.
다음 예시에서 파란색 버튼이 사용자에게 가장 가깝게 보입니다.
강조되거나 눈에 띄는 것은 결과적으로 활성 상태라는 것을 표현하게 됩니다.
배경과의 대비를 통해 버튼에 깊이를 부여하고 사용자가 활성 상태를 구분할 수 있게 해야 합니다.
두 버튼의 대비 수준이 같으면 사용자는 깊이를 시각적 신호로 인지하지 못합니다.

17. 오해 7 : 접근성을 만족하는 디자인은 모든 사용자의 요구를 만족한다?
Myth 7 An accessible design meets the needs of every user on the planet
디자이너는 모든 사용자의 요구를 만족하고 싶어합니다.
하지만 아무리 노력해도 모든 WCAG 요구 사항을 달성하는 것은 불가능합니다.
어떻게 디자인하더라도 불편하다고 느끼는 사용자는 항상 존재합니다.
달성할 수 없는 이상보다는 현실적인 목표를 추구하세요.
접근성 높은 디자인은 모든 사용자의 요구를 충족시킬 수는 없지만, 가능한 많은 사용자의 요구를 만족할 수 있습니다.
소수의 사용자는 대다수의 사용자만큼 좋은 경험을 할 수 없다는 것을 깨닫게 됩니다.
하지만 고대비 모드 등 소수의 사용자를 위한 다양한 보조 기술이 존재합니다.
접근성을 진정으로 이해하는 디자이너라면, 환상이 아닌 현실적인 목표를 실현하기 위해 노력할 것입니다.

18. 결론
사용자를 위한 디자인을 할 때는 항상 접근성을 최우선으로 고려해야 합니다.
WCAG 가이드라인은 최고 수준의 접근성을 달성하는데 도움이 되는 효과적인 도구입니다.
WCAG 가이드라인을 잘못 해석하여 발생한 오해는 사라져야 합니다.
색 대비 접근성의 미묘한 차이를 이해하면 WCAG 표준을 정확하게 적용하는데 도움이 됩니다.
시각적으로 단순하며 아름다우면서도 접근성과 균형을 맞출 수 있습니다.
결과적으로 거의 모든 사람을 만족시킬 수 있는 포용적인 인터페이스를 만들어낼 수 있습니다.

19. UX 리서치 케이스 스터디 : 틴더
Tinder 는 널리 사용되고 있는 온라인 데이팅 플랫폼으로,
많은 사람들이 서로 알아가거나 관계를 맺는데 도움을 주고 있습니다.
여기서는 Tinder 의 사용자 경험에 대해서 살펴보려고 합니다.
이 프로젝트는 UI/UX Bootcamp 의 과제로 진행했습니다.
FROM Midjourney. Prompt : photography of an iphone with a tinder like dating
app interface on the screen inspired by Behance and Figma and dribbble
https://tirtabudhi.medium.com/ux research case study tinder 5455fbece461

20. Background
프로젝트 목표
Tinder 앱 내에서 발생하는 유저 행동을 이해합니다.
Tinder 앱에 대한 사용자들의 인식과 기대를 파악합니다.
구독자 수를 늘릴 수 있는 방법에 대해 고민합니다.
리서치 방법론
Design Thinking 접근을 사용해 5단계로 나누어 진행합니다.
Empathize Define Ideate Prototyping Usability Testing
인터뷰
6명의 무료 사용자와 6명의 구독자를 대상으로 인터뷰를 진행했습니다.
대상자 : Tinder 앱 사용자, 20 30세, 도시에 거주하는 사람
인터뷰 대상자를 모집하기 위해, 지인들을 대상으로 스크리닝 질문을 수행했습니다.
실제 인터뷰를 진행하기 전에 어떻게 질문을 해야 할지 가이드를 작성했습니다.

21. Result
리서치 결과 정리
12명의 사용자 대상으로 리서치한 데이터에 여러 가지 기법을 적용하여 결과를 정리했습니다.
어피니티 다이어그램
데이터를 목적에 맞게 정리하기 위해
사용합니다.
유저 페르소나
서로 다른 사용자 특성을 설명하기 위
해 가상의 캐릭터를 설정합니다. 사용
자의 행동, 니즈, 경험, 목표를 이해하
는데 도움이 됩니다.
고객 여정 지도
여정 지도는 한 사용자가 목표를 달성
하는 과정을 시각화합니다.
아이디어 우선순위
여러 기회를 확인한 다음에는
Eisenhower 의사결정 방법으로 우
선 순위를 정리합니다.

22. Result
현재 문제점과 기회
기회
추천 마케팅을 통해 앱을 설치하지 않은 사람들을 대상으로 인지도를 높입니다.
추천 1일 2일 단위로 더 짧은 기간의 구독 패키지를 제공합니다.
추천 오래된 사용자는 피드에 더 이상 등장하지 않도록 합니다.
그 외의 기회들
긍정적인 인식을 위한 브랜딩
할인 행사 또는 무료 체험
라이브 비디오, 인기도, 커뮤니티 기반의 기능 추가
문제점
데이팅 앱에 대한 인식이 아직 부족합니다.
가짜 유저 프로필이 너무 많습니다.
사기가 너무 많습니다.
성희롱에 대한 우려가 있습니다.
가격이 너무 비쌉니다.
기능이 아직 부족합니다.
할인을 하지 않습니다.
취향에 맞을 때도 있지만 그렇지 않을 때도 많습니다.

23. Prototyping Usability Testing
사용자의 관점에서 특정한 작업을 완료할 때 까지 필요한 과정을 단계별로 표현합니다.
유저 플로우
화면을 구성하기 위해 필요한 정보를 적절한 구조에 맞게 정리합니다.
IA
Information Architecture
프로토타입
제품을 실제로 만들기 전에 어떤 식으로 동작하는지 검증하기 위한 샘플입니다.
UI 디자인 작업의 시작 단계이며, 더 구체적인 작업으로 넘어가기 전에 이 단계에서 많은 것을 바꿔보는 것이 좋습니다.
디자인 시스템 제품 개발 과정에서 디자이너와 개발자들이 재사용할 수 있도록 표준화한 컴포넌트 및 코드입니다.
목업
Mock up
실제 제품에 반영했을 때 어떤 형태가 될지 가정하고 그려낸 디자인 결과물입니다.
사용성 테스트 새로운 디자인을 적용하면 사용자가 작업을 완료하는데 도움이 되는지 확인하는 단계입니다.

24. What I ve Learned
사용자의 요구와 제약이 무엇인지 이해해야 한다는 것을 알게 되었습니다.
디자인 시스템과 디자인 프로세스를 적용했을 때의 장점을 이해할 수 있었습니다.
사용성 테스트를 통해 사용자로부터 인사이트를 얻을 수 있었고, 우리의 디자인이 사용자의 요구사항과 불편한 부분을 해결하고 있는지 확인할 수 있었습니다.

25. 개발자들에게 사랑받는 피그마 디자인 만들기
Figma Config 2022 개발자들에게 사랑받는 피그마 디자인 만들기 발표를 정리한 글입니다.
https://uxdesign.cc/how to create figma design loved by developers cb03d5b4e0ec

26. What is Design loved by Developers
개발자들에게 사랑받는 디자인이란 무엇을 의미할까요?
1 의도를 쉽게 파악할 수 있는 디자인
2 디자인이 변경되었을 때
쉽게 개발단의 구현을 변경할 수 있는 디자인
구조화된 디자인
Structured Design
디자인 시스템
Design System
기준
달성 방법

27. What is Design loved by Developers
구조화된 디자인 Structured Design
구조화된 디자인이란, 2021년 Figma Schema 의 Keynote 발표에서 처음 소개된 개념입니다.
https://www.youtube.com/watch?v BhocoPQTUDE
디자인에는 자유형 Freeform 과 구조형 Structured 이 있습니다.
Freeform : 외형만 구성된 비구조화된 디자인
Structured : 외형 이외의 동작을 정의하고, 디자인 데이터를 구성

28. What is Design loved by Developers
왜 서로 다른 형태의 디자인이 필요할까요?
디자인에는 두 가지 목적이 있기 때문입니다.
1 UI에 대한 가설을 검증하는 것
이 단계에서는 다양한 UI를 시도해보고 어떤 UI를 사용할지 결정하는 것을 목표로 합니다.
아직 UI의 형태가 결정되지 않았고 다시 만드는 과정을 반복할 것이기 때문에, 이 단계에서 디자인을 구조화하는 것은 비효율적일 수 있습니다.
2 디자인의 의도를 개발자와 커뮤니케이션 하는 것
디자인 작업의 최종적인 목표는 실제 제품으로 구현하는 것입니다.
이를 위해서는 필요한 정보를 쉽게 얻을 수 있도록 디자인해야 하고, 오해가 발생할 수 있는 부분을 최소한으로 줄여야 합니다.
디자인을 쉽게 수정할 수 있게 하려면
디자인의 의도를 잘 설명 하려면
어떻게 해야 할까요?

29. Tell the intent of Design
디자인의 의도란 무엇일까요?
개발자는 디자인을 실제 작동하는 화면으로 구현하는 과정에서 다양한 값을 코드에 반영합니다.
이 과정에서 디자인의 의도 를 빠르고 정확하게 전달하는 것이 중요합니다.
디자인 의도 에는 다음과 같은 4가지 주요 카테고리가 있습니다.
1 시각적인 속성 색상, 폰트 등
2 레이아웃
3 반응형
4 상태

30. Tell the intent of Design
1 시각적인 속성
이 부분은 피그마의 디자인 창에서 확인할 수 있습니다.
보통은 커뮤니케이션 과정에서 문제가 발생할 여지가 적지만, line height를 제대로 설정하지 않으면
겉으로 보이는 마진과 실제 캔버스에서 읽어오는 마진 값이 달라질 수 있으니 주의해야 합니다.

31. 레이아웃의 관점에서는 Auto Layout 같은 기능을 적절하게 사용하여 최대한 코드처럼 레이어를 구축하는 것이 중요합니다.
그렇게 해야 안티패턴을 피해 디자인의 의도를 쉽게 파악할 수 있고, 쉽게 구현할 수 있습니다.
예를 들면 다음과 같은 안티패턴이 있습니다.
여러 줄의 텍스트가 줄바꿈으로 처리되어 있고, 마진 값을 확인할 수 없습니다.
아래쪽 패딩이 설정되지 않아서 개발자에게 해석의 여지가 있습니다.
이로 인해 실제 구현이 디자이너가 의도한 것과 달라져 유지 관리가 어려워집니다.
그렇다면 코드처럼 레이어를 쌓기 위해서는 어떻게 해야 할까요?
피그마와 실제 코드는 많은 부분에서 유사한 점이 있기 때문에 해당 기능을 적극 활용하면 좋습니다.
Auto Layout 은 CSS의 Flexbox와 거의 동일합니다.
Constraints 도 상대적인 너비/높이나 position:absolute 를 표현할 수 있습니다.
Tell the intent of Design
2 레이아웃
참고.
이 글에서 코드 는 JS 부분은 제외하고, HTML과 CSS로 만드는 시각적인 부분만 의미합니다

32. Tell the intent of Design
3 반응형
반응형이라는 말을 들으면 데스크탑, 태블릿, 모바일 등 다양한 중단점에 맞는 디자인을 떠올릴 겁니다.
하지만 추가적으로 동일한 디바이스 타입에서 스크린 크기가 변하는 것도 고려해야 합니다.
이러한 작업은 Constraints 로 구현할 수 있습니다. Constraints 는 상위 프레임의 크기가 변할 때 레이어가 어떻게 변해야 또는 변하지 말아야 하는지 정의합니다.
Auto Layout 의 Resize 속성을 사용하면 너비와 높이가 자식의 높이에 따라 변경되어야 하는지 아니면 고정된 값을 가져야 하는지 설정할 수 있습니다.

33. Tell the intent of Design
4 상태
UI는 동적이고, 다양한 상태를 가집니다.
UI Stack 에서 정의하는 다양한 상태 중에서 Blank Empty , 로딩, 에러 등은
종종 누락되어 엔지니어가 UI를 구현하기 전까지 발견되지 못할 수 있습니다.
프로토타입을 만들어서 유저 트랜지션을 쉽게 볼 수 있도록 하면 작업하는데 도움이 됩니다.
프로토타입의 인터렉션을 기준으로 플로우를 그려주는 ProToFlow 같은 플러그인을 사용하면
prototype pane 으로 전환하지 않아도 트랜지션을 확인할 수 있습니다.
베리언트와 인터렉티브 컴포넌트도 중요합니다.
베리언트는 컴포넌트의 여러 상태를 표현할 수 있습니다.
인터렉티브 컴포넌트는 각 상태 간의 전환을 표현할 수 있습니다.
https://www.figma.com/community/plugin/989539821393693492/ProToFlow

34. Tell the intent of Design
점진적으로 디자인 개선하기
앞에서 언급한 모든 작업을 한 번에 할 필요는 없습니다. 점진적으로 할 수 있습니다.
디자인 단계와 핸드오프 단계를 분리하는 것이 좋습니다.
디자인 단계
최적의 디자인을 항상 유지하는 것은 어렵습니다.
새로운 요구사항에 대응하다가 최적의 상태에서 멀어지는 것은 일상적인 일입니다.
부채는 항상 쌓인다는 것을 전제로 했을 때 디자인을 개선할 수 있는 메커니즘을 만들어야 합니다.
핸드오프 단계
다양한 UI를 시도해보고 어떤 UI를 사용할지 결정하는 단계입니다.
Lo fi , Hi fi 프로토타입을 만듭니다.
시각적인 디테일을 너무 챙기거나 디자인의 과도하게 구조를 잡으려고 하면 안됩니다.
완료되면 핸드오프 단계로 넘어갑니다.
디자인을 구조화하고, 개발자들이 디자인을 잘 이해할 수 있도록 설명을 달아둡니다.
디자인 자체를 유지보수하기 쉽게 만드는 리팩토링 작업입니다.

35. Make Design easy to update
수정하기 쉽게 디자인하기
수정하기 쉬운 디자인이란?
개발자의 관점에서 봤을 때 수정하기 쉬운 디자인 이란 디자인이 새롭게 만들어지거나 수정되었을 때 코드도 쉽게 수정할 수 있어야 한다는 것을 의미합니다.
이러한 목표를 달성하기 위해서는 디자인을 체계적으로 구성해야 합니다. 다시 말해 디자인 시스템을 만들어야 합니다.
디자인 시스템을 만드는 것이 개발자에게도 도움이 되는 이유가 무엇일까요?
디자인이 시스템화되면 미리 만들어둔 디자인 토큰과 컴포넌트를 바탕으로 일관적인 UI를 만들 수 있습니다.
그 결과 개발 작업도 간결해지고, 이미 만들어둔 리소스를 재활용할 수 있기 때문에 작업 속도도 더 빨라집니다.
피그마로 디자인 시스템을 구성할 때 다음 두 가지를 고려해보세요.
디자인 토큰
컴포넌트 / 베리언트

36. Make Design easy to update
디자인 토큰 Design Token
디자인 토큰은 색상, 간격, 타이포그래피 비율처럼 디자인 시스템에서 분리할 수 없는 구성요소를 의미합니다.
피그마에서 디자인 토큰을 적용하는 방법 중 하나는 Style 기능을 적용하는 것입니다.
이 기능을 잘 활용하면 좋지만, 해당 세팅을 코드에서 쉽게 사용할 수 있도록 내보내거나 세팅값을 불러오는 기능이 존재하지는 않습니다.
Tokens Studio 플러그인을 추천합니다.
피그마에서 Style 로 정의할 수 없는 항목까지 정의할 수 있습니다. 간격, 모서리 반지름 등
JSON 파일로 내보낼 수 있으며 Github 등을 통해 동기화 할 수 있습니다.
https://www.figma.com/community/plugin/843461159747178978

37. Make Design easy to update
컴포넌트와 베리언트 Components/Variants
피그마에서는 컴포넌트를 정의할 수 있고, 컴포넌트의 다양한 상태를 베리언트로 정의할 수 있습니다.
컴포넌트를 정의할 때는 디자인과 코드 상의 입자감, 이름, 속성 등을 최대한 맞추는 것이 좋습니다.
이렇게 하면 디자인에 대한 공통의 언어가 생긴다는 장점이 있습니다.
디자인과 코드 상의 차이가 많아질수록, 디자인 변경시 코드를 수정하는 복잡도가 올라갑니다.
컴포넌트를 디자인할 때 다음 항목을 신경쓰는 것이 좋습니다.
1 컴포넌트가 어떤 상태에서 변경될 수 있는지 고려합니다.
2 컴포넌트가 하나의 책임을 갖도록 합니다.
위 항목은 개발자들이 업무를 하면서 일상적으로 신경을 쓰는 것들입니다.
디자이너도 같은 고민을 한다면, 디자이너와 개발자가 굉장히 효과적으로 협업할 수 있을 겁니다.
참고. 입자감 granularity
정보를 얼마나 정밀하게 제공할 지, 아니면 얼마나 큰 덩어리로 정리할 지를 결정하는 정도

38. Make Design easy to update
커뮤니케이션 Communication
기술적인 부분에 대해 계속 얘기했지만 커뮤니케이션에 대해서도 이야기해야 합니다.
최적의 디자인은 조직에 따라 달라질 수 있기 때문에, 커뮤니케이션을 통해 각 조직에 가장 잘 맞는 디자인 프로세스를 찾아야 합니다.
디자인 결과를 개발자들에게 전달할 때 핸드오프 미팅을 진행하는 것도 좋습니다.
초기 디자인 단계부터 구현 가능성을 함께 고민할 수 있다면 전체 작업 속도를 높일 수 있습니다.
디자인을 구조화하는 것도 중요하지만, 너무 엄격하게 적용하지 말고 유연하게 대응하는 것이 좋습니다.

39. Conclusion
디자인 결과물을 만들어내는 방식은 전체 개발 프로세스의 속도와 퀄리티에 영향을 미칩니다.
디자인을 구조화하고 유지보수하기 쉽도록 작업하면 개발자가 디자인의 의도를 쉽게 파악할 수 있고, 구현 퀄리티를 높이며, 작업 속도를 빠르게 합니다.
디자인이 구조화되어야 하는 방식은 조직에 따라 다릅니다. 그러니 많이 소통하시고 최적의 방식을 찾아보세요!

40. 감사합니다 :
lumiamitie gmail.com