1. UI의 최소 단위: 파운데이션
- 파운데이션(UI의 기초 재료) -> 컴포넌트(파운데이션의 조합)
- color, radius, grid, elevation, spacing/gap, font/typography, icon 등
grid, icon은 파운데이션으로 안 보기도 함.
2. 컬러 스타일 (Color Style)
- 가산혼합 (RGB): 모바일과 PC 스크롤 화면은 빛의 3원색(Red, Green, Blue)을 섞어 색을 만드는 방식. 빛은 더할수록 밝아지기 때문에 이를 이해하고 색상을 설계. (Hex Code로 표현: 각 hue의 256가지 색을 16진수로 표현함)
- 컬러 스타일: 디자인에서 사용할 색상 모아두는 라이브러리 아카이브, 팔레트라고도 함.
기본으로 2-3가지로 구성. primary color, background color(일반적으로 흰색), secondary color( Tertiary,서브 컬러, 잘 안 씀) - 1:3:6 법칙
- 실제로 컬러 스타일 만드는 건 어려운 일: 테스트, 인터뷰, 계산 등을 거침
- 시맨틱 컬러 스케일
3. 폰트 스타일 (Font Style)
- 스케일: 일정 규칙에 따라 정렬된 하나의 세트
material design이라는 구글의 가이드 참조
| 폰트 속성 | 실무 관점 및 협업 팁 |
| 패밀리 (Family) | 프로젝트에 사용할 폰트의 종류(서체)를 통일. |
| 굵기 (Weight) | 디자인의 시각적 위계(중요도)를 결정하는 '무게감'. • 디자이너:Thin, Light Regular, Bold 같은 명칭 선호 • 개발자: 400, 700 같은 수치형태 선호 (소통 시 매칭 필요) 일반적으로 Normal 400 Medium 500 |
| 크기 (Size) | 가독성을 고려한 서체의 절대적인 크기(px 단위 등). 일반적으로 16기준, 11까지는 사용 20부터는 4씩 증가 웹사이트 기본 폰트 사이즈가 16 |
| 행간 (Line Height) | 글 줄과 줄 사이의 간격. 텍스트가 여러 줄이 되었을 때 가독성에 결정적인 영향을 끼침. 일반적으로 알려진 적당한 행간값 제목 120-135% 본문 135-170% 본문의 경우 150% 근데 서체마다 고유한 기본적인 여백 있음... 처음에는 프리텐다드 추천, 노토산스 기반 폰트들 |
| 자간 (Letter Spacing) | 글자와 글자 사이의 간격으로, 폰트 스타일에 함께 묶어 등록. |
4. 마스터 컴포넌트와 인스턴스
개발의 클래스(Class)와 객체(Object) 개념과 동일. 복사된 디자인 한번에 수정하거나 편집할 수 있도록 해주는 기능
- 컴포넌트: 파운데이션을 조합해 만든 구성품
- 마스터 컴포넌트 (◆): 프로젝트에 단 하나만 존재하는 '원본'. 이 원본의 크기나 색상을 수정하면, 프로젝트 전체에 뿌려진 수백 개의 복사본들이 한 번에 실시간으로 변경. 피그마의 컴포넌트 기능의 핵심.
- 인스턴스 (◇): 마스터를 복사해서 배치한 '복사본'. 원본의 속성을 그대로 이어받지만, 특정 복사본만 글자를 바꾸거나 아이콘을 바꾸는 등 '오버라이드(Override; 덮어쓰기)'가 가능.
- (마스터)컴포넌트 지워도 인스턴스 남아있음. 다만 인스턴스 수정 편집할려면 컴포넌트 복구해야
- 주의! 인스턴스를 수정하는 것이 컴포넌트 변경사항 받는 것보다 우선 적용
- Detach: 일반 프레임으로 변경
5. 디자인 시스템의 핵심 패러다임
- 디자인 시스템: UI 디자이너의 핵심 종착지
- 웹/앱=프로덕트 디자인: 사용자의 문제 개선하는 디자인적인 솔루션 도출을 목적으로 함.
- 디자이너도 같은 방법으로, 개발자도 같은 생각으로 만들 수 있도록, 재사용해서 효율성 높이고 문제에 집중
UI 키트 vs. 디자인 시스템
- UI 키트: 단어장의 '단어'처럼 단순히 재사용 가능한 디자인 요소들을 모아놓은 리소스.
- 디자인 시스템: 단어뿐만 아니라 문장을 만드는 '문법'과 '규칙'을 포함. 즉, 제품을 만드는 팀 전체가 동일한 규칙과 사용법을 공유하고 이해하는 하나의 거대한 약속이자 제품 개발 환경.
- UI 규격, 스펙, 사용 사례, 주의 사항 총망라한 종합적인 제품 가이드라인임. 문서의 형태를 갖춤
- 플랫폼 디자이너가 이 일을 함
- 장점: 효율, 품질 통일 // 단점: 구축 오래 걸림, 아이디에이션 고착화
6. 기능에 따른 UI 컴포넌트 6대 분류(머티리얼 디자인 기준)
*구글 머티리얼 디자인 가이드라인 - 반드시 즐겨찾기, 통째로 공부
*컴포넌트의 뜻, 정의, Affordance가 중요
- 액션 (Action): 사용자가 클릭하거나 누름으로써 서비스 내에서 중요한 동작을 실행하게 함. (Button)
- 인풋 (Input): 사용자로부터 데이터나 정보, 텍스트를 직접 입력받는 창. (TextField, SelectBox)
- 인포메이션 (Information): 시스템의 현재 상태나 성공/실패 등의 안내 사항을 유저에게 전달. (Toast Message, Snackbar, Label)
- 컨트롤 (Control): 사용자가 정해진 여러 선택지 중 원하는 옵션을 명확하게 고를 수 있도록 도움. (Radio, Checkbox, Switch)
- 네비게이션 (Navigation): 유저가 원하는 화면이나 메뉴로 길을 잃지 않고 이동할 수 있도록 돕는 나침반 역할. (Tab, GNB)
- 컨테이너 (Container): 다양한 정보와 요소를 시각적으로 묶어주고 구조화해 주는 박스 모델. (Card, Modal)
- 컨트롤 요소의 핵심 특징 비교
- 컨트롤: 사용자가 선택지 중 선택할 수 있게 하는 컴포넌트
- 실제 그래픽 크기는 작더라도 주변에 충분한 '최소 터치 영역'을 빈 공간(Padding 등)으로 확보해 주는 것이 필수.
- 라벨과 같이 쓰임. 라벨만 누르더라도 터치되도록 터치 영역으로, 간격을 충분히!
- 컨트롤 요소를 라벨 행간으로 맞춰두면 좋음!
| 컴포넌트 이름 | 작동 방식 및 기획 규칙 | 실무 UX 적용 팁 |
| 체크박스 (Checkbox) | 1개 이상 선택 가능. | 전체 동의 버튼과 하위 체크박스 간의 연동 유기성을 고려. |
| 라디오 (Radio) | 여러 선택지 중 딱 1개만 고를 수 있음. 옛날 아날로그 라디오 버튼(하나를 누르면 다른 버튼이 튀어나오는 구조)에서 유래. | • 아무것도 선택하지 않는 '빈 상태'는 불가능. • 사용자가 가장 많이 고를 법한 항목을 기본값으로 opt-in해두는 게 좋음. |
| 스위치 (Switch/Toggle) | 전등 스위치처럼 어떤 상태를 즉시 '쾀(ON)' 또는 '끔(OFF)'으로 전환할 때 사용. | 누르는 즉시 시스템에 반영되는 설정 페이지 등에 적합. |
| 슬라이더 (Slider) | 볼륨 조절이나 가격 범위 지정 등 연속된 값의 범위를 직관적으로 조절. | 최소값과 최대값의 범위를 명확히 인지할 수 있는 라벨이 동반되어야 함. |
컴포넌트가 가지는 의사 상태 (Pseudo State)
Pseudo State란? 상황에 따라 스타일 바뀌는 것(e.g. 버튼에 마우스 올렸을 때 색깔 바뀌는 경우)
- Default (기본): 사용자가 아무런 상호작용을 하지 않은 깨끗한 형태의 기본 상태.
- Hover (호버): 데스크톱 환경에서 유저가 마우스 커서를 컴포넌트 위에 올렸을 때의 반응. (터치 기반의 모바일에서는 생략되기도.)
- Focused (포커스): 텍스트필드를 클릭하여 커서가 깜빡이거나, 특정 요소가 선택되어 테두리가 강조된 활성화 상태.
- Disabled (비활성화): 필수 조건을 충족하지 못해 현재 클릭하거나 입력할 수 없음을 나타내는 회색 톤의 상태.
- Error (오류): 입력된 정보가 유효성 검증(Validation)을 통과하지 못했을 때 나타나는 상태.
유저 혼내지 말고 긍정적인 해결책 제시!
06. 디자이너가 가져야 할 UI 학습의 올바른 관점
UI를 기능주의적 관점으로 생각하자!
변화하지 않는 디자인은 죽은 디자인! 만드는 순간 개선 시작이다!
UI의 기능, 목적 이해하는 게 중요.
컴포넌트 이름에 집착하지 말자!
컴포넌트의 형태가 아니라 본질인 기능, 목적을 이해해야 함!