FlOWING SINI

피그마 기초 완전 정복 - 컴포넌트 심화 활용 (버튼 컴포넌트 기초 설계) 본문

PM TIL/Tech Lecture

피그마 기초 완전 정복 - 컴포넌트 심화 활용 (버튼 컴포넌트 기초 설계)

by SINI 2026. 6. 16. 14:52

1. 오늘 학습 키워드

- 컴포넌트 프로퍼티

- 배리언츠

- 프로퍼티

- 버튼 위계

- 크기

- 상태


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

 

<컴포넌트 프로퍼티>

- 컴포넌트의 변화와 설정을 관리할 수 있게 해주는 기능

- 컴포넌트의 상태에 따라 형태가 바뀌거나 내부 요소가 변경될 수 있음

- 텍스트, 아이콘, 상태 등을 상황에 맞게 쉽게 변경할 수 있도록 도와줌

 

 

컴포넌트 프로퍼티의 필요성

- 하나의 컴포넌트를 더 효율적으로 재사용하기 위해 사용하는 기능임

- 텍스트, 아이콘, 상태 등을 쉽게 변경하여 다양한 디자인에 활용할 수 있음

 

 

<배리언츠 (Variants)> = 변종

마우스를 올렸을 때, 누를 수 없을 때 - 기본 상태의 변종 = 기본 상태의 배리언츠

 

- vari- = 변화

- 컴포넌트의 다른 형태를 만들 수 있는 기능

- 기본 컴포넌트의 변형된 모습을 관리하기 위한 기능

- 주로 컴포넌트의 상태 변화를 표현할 때 사용

Hover, Pressed, Disabled 등

 

 

프로퍼티 (Property)

기본 상태 + 아이콘 디자인은 그대로,버튼의 글자나 아이콘의 스타일 변경 시 프로퍼티로 조정

 

- 컴포넌트의 속성을 제어하는 기능

- 디자인 구조는 유지한 채 텍스트, 아이콘, 스타일 등의 요소를 변경할 때 사용함

- 구조를 바꾸지 않고 내용을 변경하기 위한 기능

 

 

컴포넌트 프로퍼티의 종류

- 배리언트를 제외하면 피그마 컴포넌트에서 설정할 수 있는 프로퍼티는 3가지가 있음

마스터 컴포넌트 를 선택하면 프로퍼티 패널이 생김

  • Boolean (불리언)
    - Y or N을 선택하는 형식
    → 참 또는 거짓, 예 또는 아니오, 켜기 또는 끄기 
    - 컴포넌트 안의 특정 요소를 표시하거나 숨길 수 있는 프로퍼티
    - 레이어를 켜고 끄는 것처럼 사용할 수 있음

    - 예시
    텍스트에 불리언 프로퍼티를 적용하면 껐다 켰다 가능
  • 인스턴스 스왑 (Instance swap)
    - 컴포넌트 내부의 인스턴스를 다른 인스턴스로 교체할 수 있는 프로퍼티
    - 주로 아이콘이나 버튼과 같은 요소를 변경할 때 사용함
    - 인스턴스가 아닌 요소로는 교체할 수 없음

    - 예시
    버튼 안에 있는 아이콘에 인스턴스 스왑을 적용하면 다른 아이콘으로 변경하기 쉬워

 

  • 텍스트(Text)
    - 컴포넌트 내부의 텍스트를 쉽게 수정할 수 있도록 하는 프로퍼티임
    - 인스턴스에서 텍스트 내용을 직접 변경할 때 사용함
    - 버튼 라벨이나 안내 문구 등을 편리하게 수정할 수 있음

    - 예시
    텍스트에 텍스트 프로퍼티를 적용하면, 텍스트 편집을 좀 더 쉽게 할 수 있음

배리언트와 프로퍼티를 구분하는 기준

- 배리언트와 프로퍼티 모두 디자인을 변경할 수 있음

- 파운데이션(디자인 토큰) 값이 변경되는지 여부로 구분됨

- 색상, 크기 등 파운데이션 값이 변경되면 배리언트를 사용하는 것이 적합함

- 구조는 유지한 채 텍스트, 아이콘, 표시 여부 등을 변경하는 경우 프로퍼티를 사용하는 것이 효율적임

- 프로퍼티로 해결할 수 있는 경우에는 배리언트보다 프로퍼티 사용을 권장함

- 실무에서는 상황에 따라 배리언트와 프로퍼티를 함께 사용하며, 목적에 맞게 판단하는 것이 중요함

 

- 예시
버튼에 적용한 파운데이션 요소인 색상, 간격, 폰트가 바뀜

파운데이션 값이 바뀌었다면 베리언츠

 

색상이나 간격, 폰트, 아이콘의 크기 등 파운데이션 값이 안바

파운데이션 값이 그대로라면 프로퍼티

 

 

 

<버튼 위계(Hierarchy & Priority)>

- 버튼은 사용자가 수행해야 하는 행동의 중요도에 따라 구분됨

- 중요한 행동일수록 더 눈에 띄는 형태로 설계함

- 일반적으로 Primary(1순위), Secondary(2순위), Tertiary(3순위)의 3단계 위계를 사용함

- 제품의 규모와 특성에 따라 위계 단계는 유연하게 조정할 수 있음

 

 

버튼 스타일

1. 세컨더리 버튼

- 일반적으로 프라이머리 버튼과 동일한 포인트 컬러 팔레트를 사용해서 아웃라인 버튼으로 제작함
- 배경색을 포인트 컬러 팔레트에서 가장 밝은 색으로 사용하는 게 일반적임

 

2. 터시어리 버튼

- 세컨더리 버튼과 유사한 컨셉

- 세컨더리 버튼보다 시각적으로 덜 강조되도록 회색조를 활용해서 만드는 것이 일반적임

 

→ 버튼 스타일은 색상 자체보다 시각적 강조 정도를 통해 위계를 구분

 

 

프라이머리 컬러와 프라이머리 버튼

- 프라이머리, 세컨더리는 프라이머리 컬러, 세컨더리 컬러와는 별개의 개념

- 버튼의 프라이머리, 세컨더리는 버튼의 우선순위를 의미함

- 컬러의 프라이머리, 세컨더리는 색상 체계에서의 역할을 의미

- 세컨더리 버튼이라고 해서 반드시 세컨더리 컬러를 사용하는 것은 아님
- 일반적으로 동일한 포인트 컬러를 활용하고 시각적 강조 수준을 조절하여 버튼의 위계를 표현함

- 버튼의 중요도는 색상 차이가 아닌 시각적 강조 정도를 통해 전달하는 것이 중요함

 

 

버튼의 위계 배리언츠 만들기

 

 

 

<크기(Size)>

- 일반적으로 Large, Medium, Small의 3가지 단계를 사용함
- 제품의 특성에 따라 하나 또는 여러 개의 크기 체계를 자유롭게 구성할 수 있음

- 버튼 크기 역시 디자인 시스템의 속성(Property)으로 관리할 수 있음

 

 

배리언트 추가 시 오류 해

- 배리언트 중 값이 똑같이 겹치는 것들이 있는 경우

- 속성 패널에서 확인 후 값 변경

 

 

버튼의 크기 배리언츠 만들기

 

 

 

<상태(State)>

- 버튼이 가질 수 있는 의사 상태는 다양하게 있음

→   Default(Enable), Hover, Pressed, Disabled 등 

 

 

버튼 상태 설계 시 주의사항

- 일반적으로 버튼을 누르고 있는 상태를 보여줄 땐 버튼의 배경색을 한 단계 더 진한 색으로 하는 편임

- 디자이너의 선택에 따라 자유롭게 변경 가능

- 버튼 전체가 동일한 규칙으로 변할 수 있도록 하는 것이 중요함

 

 

버튼의 상태 배리언츠 만들기

 

 

배리언트 정리하기

- 배리언트가 포함된 컴포넌트에도 오토레이아웃을 적용할 수 있음

- 배리언트가 많아질수록 관리가 어려워질 수 있음

- 오토레이아웃을 활용하면 배리언트를 깔끔하게 정리하고 관리할 수 있음

 


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

1) 

 학습 과정 도중 버튼 상태(State)에 Default, Hover, Pressed, Disabled 외에 어떤 상태가 있는지 궁금해졌다.

 이를 해결하기 위해 추가 학습을 진행한 결과, 제품과 플랫폼에 따라 Focus, Loading, Selected, Visited, Error 등의 상태를 추가로 사용할 수 있다는 점을 알게 되었다. 특히 접근성을 고려한 Focus 상태와 처리 진행 여부를 보여주는 Loading 상태는 실무에서도 자주 활용된다는 것을 이해하게 되었다.

2)

 학습 과정 도중 배리언트 값 충돌 오류를 수정했음에도 문제가 해결되지 않는 경우가 있는지 궁금해졌다.

 이를 해결하기 위해 추가 학습을 진행한 결과, 일부 배리언트의 값만 수정하고 다른 중복 값이 남아 있거나, 여러 프로퍼티 조합이 동일하게 설정된 경우에는 오류가 계속 발생할 수 있다는 점을 알게 되었다. 이 경우 충돌이 발생한 모든 배리언트를 확인하여 각 프로퍼티 조합이 고유한 값을 가지도록 수정해야 해결할 수 있다는 것을 이해하게 되었다.

3)

 학습 과정 도중 버튼 크기가 일반적으로 3단계(Large, Medium, Small)로 구성되는데, 실제 서비스에서는 몇 단계까지 사용하는지 궁금해졌다.

 이를 해결하기 위해 추가 학습을 진행한 결과, 서비스 규모와 특성에 따라 XS, XL과 같은 크기를 추가하여 5단계 이상으로 운영하기도 한다는 점을 알게 되었다. 특히 복잡한 디자인 시스템을 사용하는 대규모 서비스에서는 다양한 화면 환경과 사용성을 고려해 더 세분화된 크기 체계를 적용할 수 있다는 것을 이해하게 되었다.