피그마 기초 완전 정복 - 비디자인 환경 이해 및 비요소 만들기 (UI 설계와 제작 실습 1편)

1. 오늘 학습 키워드

- UI 디자인

- 버튼 컴포넌트

- 텍스트필드 컴포넌트

- 플레이스홀더

- 유효성 검사

---

2. 오늘 학습 한 내용을 나만의 언어로 정리하기

 

<UI의 분류>
- UI 분류는 절대적인 기준이 아니라 상황과 관점에 따라 달라질 수 있음
-UI의 이름이나 분류보다 해당 UI가 어떤 상황에서 어떤 기능을 수행하는지 이해하는 것이 중요함

• 액션(Action)
  - 사용자의 주요 행동을 실행할 때 사용
  - 대표적인 예시 → 버튼
  

  

• 인풋(Input)
  - 사용자의 입력을 받는 요소
  - 대표적인 예시
  → 텍스트를 입력할 수 있는 텍스트필드(Text Field)
  → 미리 정해진 옵션 중 하나를 선택하는 셀렉트박스(Select Box)

  

• 인포메이션(Information)
  - 사용자에게 서비스의 상태나 안내 사항을 전달하는 요소
  - 대표적인 예시
  → 토스트 메시지, 스낵바, 라벨
  

  

• 컨테이너(Container)
  - 여러 컴포넌트가 결합되어 하나의 기능이나 의미를 가진 덩어리를 이루는 컴포넌트
  - 대표적인 예시
  → 카드, 바텀시트, 리스트처럼 복잡한 구조인 경우가 많음
  

  

• 내비게이션(Navigation)
  - 사용자가 서비스 내에서 페이지나 화면을 이동할 때 사용하는 컴포넌트
  - 대표적인 예시
  → 네비게이션 바, 앱 바, 화면 하단의 탭 바, 사이드바
  

  

• 컨트롤(Control)
  - 사용자가 설정이나 값을 수정할 때 사용하는 컴포넌트
  - 대표적인 예시
  → 라디오, 체크박스, 스위치
  

  

 

의사 상태(Pseudo State)

- 의사(Pseudo:수)는 가짜의, 가상의라는 의미
-  의사 상태는 컴포넌트의 가상 상태를 표현할 때 사용함

- 예시
버튼에 마우스를 올렸을 때 색깔이 바뀜
→ 실제로 다른 버튼으로 바뀐 것이 아니라, 버튼의 가상 상태(Hover)를 나타낸 것임

마우스를 올리면 색상이 변하는 것도 의사 상태임

 

 

의사 상태 설계 시 주의사항

- 의사 상태의 종류는 사용자 상호작용에 따른 다양한 경우가 있음
→ 호버, 클릭, 선택, 비활성화 등

 

- 컴포넌트마다 사용할 수 있는 의사 상태가 다름

버튼인데 체크된 것은 불가능, 체크박스가 링크인 건 존재할 수 없음

 

 

→ 컴포넌트에 의사 상태를 적용할 때는 개발자와 충분히 논의하여 구현 가능 여부를 확인하는 과정이 필요함

 

 

 

<버튼 컴포넌트>

- 액션(Action) 유형의 컴포넌트
- 사용자가 누름으로써 주요 동작을 수행하는 요소

 

 

버튼 설계 시 주의점

• 사용자가 역할을 쉽게 이해할 수 있는 직관적인 컴포넌트
  
  
• 행동 유도성 = 어포던스(Affordance)
  - 상호작용이 가능한 요소는 사용 가능 여부를 시각적으로 드러내야 함
  - 버튼은 사용자가 누를 수 있다는 것을 직관적으로 인식할 수 있도록 설계해야 함
  - 버튼은 심미성보다 기능과 목적이 명확하게 전달되도록 디자인하는 것이 중요함
  

  

 

 

버튼의 구조

 

1. 컨테이너(Container)
- 버튼 내부 요소를 감싸는 영역
- 버튼의 높이는 컨테이너의 상하 여백(Padding)과 내부 요소의 높이에 따라 결정됨

2. 라벨/레이블(Label)
- 버튼의 기능이나 동작을 안내하는 텍스트
- 사용자가 입력하는 글자는 텍스트(Text)라고 함
- UI가 사용자에게 행동을 안내하는 글자는 라벨(Label)이라고 함

3. 리딩 엘리먼트(Leading Element)

- 버튼 라벨보다 앞쪽에 위치하는 요소
- 엘리먼트(Element) → 요소라는 의미

4. 트레일링 엘리먼트(Trailing Element)

- 버튼 라벨보다 뒤쪽에 위치하는 요소

 

 

리딩과 트레일링에서의 '앞'과 '뒤'의 의미
- 글을 읽는 방향을 기준으로 정해짐
- 왼쪽에서 오른쪽으로 읽는 LTR(Left to Right)
→ 왼쪽 요소 -리딩, 오른쪽 요소 -트레일링
- 오른쪽에서 왼쪽으로 읽는 RTL(Right to Left)
→  오른쪽 요소 - 리딩, 왼쪽 요소 - 트레일링

 

 

버튼의 종류
- 버튼은 목적에 따라 다양한 형태로 사용되는 컴포넌트임
- 다양한 종류의 버튼이 존재함

 

 

버튼 만들기

텍스트필드 컴포넌트

- 인풋(Input) 유형의 컴포넌트

- 사용자가 텍스트를 입력할 때 사용하는 가장 대표적인 UI임

- 인풋은 사용자가 정보를 입력할 수 있도록 하는 컴포넌트를 의미함

 

 

텍스트필드의 구조

 

1. 인풋 컨테이너(Input Container)

- 사용자가 텍스트를 입력하는 영역

 

2. 라벨/레이블(Label)

- 사용자가 입력해야 하는 값이나 정보를 안내하는 텍스트

 

3. 텍스트(Text)

- 사용자가 직접 입력하는 내용

 

4. 리딩 엘리먼트(Leading Element)

- 텍스트보다 앞쪽에 위치한 요소

 

5. 트레일링 엘리먼트(Trailing Element)

- 텍스트보다 뒤쪽에 위치한 요소

 

6. 헬퍼 텍스트(Helper Text)

- 입력값에 대한 안내나 유효성 검사 결과를 제공하는 도움말 텍스트

 

 

플레이스홀더

- 플레이스(자리를) + 홀더(지키고 있는 것) = 자리표시자

- 입력창에 표시되는 예시 문구

- 사용자가 입력해야 하는 값의 형식이나 예시를 안내할 때 사용

- 사용자가 입력을 시작하면 사라짐

- 입력한 내용을 모두 지우면 다시 나타남

 

플레이스홀더 사용시 주의사항

- 플레이스홀더에는 입력 조건보다 예시를 제공하는 것을 권장함
- 플레이스홀더는 값을 입력하기 시작하면 사라져야함

- 조건이 복잡한 경우 사용자가 입력 중 내용을 잊어버릴 수 있음

→ 입력값의 조건을 적지 않는 것을 권장함

 

 

 

유효성 검사 (Validation Check) = 밸리데이션 (Validation)

- 사용자가 입력한 값이 올바른 형식인지 확인하는 과정

- 텍스트필드에서는 입력 오류를 줄이고 정확한 정보를 받기 위해 유효성 검사가 중요함

- 올바른 형식이 아닐 경우 입력값을 다시 확인하도록 안내함

 

유효성 검사를 하는 이유

- 사용자가 오류를 쉽게 해결하고 목표를 계속 달성할 수 있도록 돕기 위해 필요함

- 오류 발생 시 적절한 문구와 안내를 제공하여 사용자의 행동 완료를 지원함

 

유효성 검사 시 주의사항

 

 

- 유효성 검사 문구는 사용자가 문제를 쉽게 해결할 수 있도록 안내해야 함

- 오류를 단순히 지적하기보다 해결 방법이나 다음 행동을 함께 제공하는 것이 중요함

- 부정적인 표현보다 긍정적이고 친절한 표현을 사용하는 것을 권장함

 

 

텍스트필드 만들기

 

---

3. 학습하며 겪었던 문제점 & 에러

1) 

 학습에서 배운 버튼 외에도 어떤 버튼 종류가 있는지 궁금해졌다.

 이를 해결하기 위해 추가 학습을 진행한 결과, 아이콘 버튼(Icon Button), 토글 버튼(Toggle Button), 플로팅 액션 버튼(FAB), 드롭다운 버튼(Dropdown Button) 등 다양한 버튼이 존재하며, 버튼은 형태보다 역할과 사용 목적에 따라 구분된다는 것을 알게 되었다.

2)

 플레이스홀더에 입력 조건을 작성하는 것을 권장하지 않는데 예외적인 상황이 있는지 궁금해졌다.

 이를 해결하기 위해 추가 학습을 진행한 결과, 조건이 매우 간단하거나 입력 공간이 제한된 경우에는 플레이스홀더에 조건을 함께 제공하기도 하지만, 복잡한 조건은 헬퍼 텍스트를 활용하는 것이 사용자 경험 측면에서 더 적절하다는 것을 알게 되었다.

3)

 이론 중심으로 학습하다 보니 개념이 머릿속에 명확하게 정리되지 않고 헷갈리는 부분이 있었다.

 이를 해결하기 위해 직접 피그마에서 버튼과 텍스트필드 컴포넌트를 만들어 보며 학습한 결과, 각 요소의 역할과 구조를 더 쉽게 이해할 수 있었고 컴포넌트 제작 과정에 대한 이해도도 높아졌다.