컴포넌트 설계의 목적
- 컴포넌트 : 유지보수성과 확장 가능성을 고려하여 만들어진, 의도를 가진 시각 구조 단위.
- 컴포넌트로 설계가 가능한 것들
- 버튼, 인풋 필드, 카드처럼 독립적인 기능을 가진 디자인 요소
- 검색창, 탭바처럼 인터랙션을 포함한 복합적인 UI 구조
- 배너, 상품 리스트, 게시물 피드처럼 반복 가능한 실제 디자인 패턴
- 사용자가 다루는 모든 UI 요소는 컴포넌트이며, 의도적으로 사용되어야 한다.
- 왜 이 구조를 컴포넌트화하는 것이 효율적인가 판단할 수 있는 사고력이 중요하다.
- 좋은 컴포넌트 조건
- 사용성과 활용성을 고려하여 설계하는 것이 좋은 컴포넌트의 핵심
- 실무에서 같은 기능과 목적을 가졌음에도 서로 다른 형태의 컴포넌트를 만들 경우가 생기며, 이 때 기준을 통해 의미 구조와 재사용 가능성의 설계를 염려하고 컴포넌트를 설계한다.
- 기준
1. 재사용성 : 컴포넌트는 다양한 페이지와 맥락에서 같은 의미로 사용될 수 있어야 한다.
2. 유연성 : 컴포넌트는 상황에 따라 상태나 데이터, 구조가 바뀌어도 무너지지 않아야 한다.
3. 확장성 : 컴포넌트는 다양한 조합으로 만들어져도 관리가 쉬운 구조여야 한다.
4. 일관성 : 컴포넌트는 제품 전체에서 동일한 기능은 동일한 방식으로 동작하고 보여야 한다.
5. 협업 친화성 : 역활과 속성이 명확해야 한다.
컴포넌트 네이밍
- 컴포넌트의 이름을 짓는 규칙을 컴포넌트 네이밍 컨벤션이라고 부르고, 이 규칙을 잘 세워둬야 컴포넌트를 다룰 때 만들어 둔 컴포넌트를 언제 어디에 써야 하는지 판단하기 쉬워진다.
- 네이밍은 구조적 사고의 표현의 일종으로 컴포넌트의 구성 요소와 속성의 구조를 설명하는 도구로서, 이름만 봐도 어떤 속성을 가진 컴포넌트인지 추론 가능해야한다.
- 이름이 명확하면 개발자와의 대화도 쉬워지며, 컴포넌트 재사용률이 높아지고 동일한 기능의 컴포넌트를 서로 다르게 만들 일이 줄어든다.
- 컴포넌트의 이름을 지을 경우 일반적으로 아래의 표현을 사용한다.
- Component Type: 어떤 UI 요소인지 카테고리를 의미.
- Style : 위계나 스타일을 알려준다.
- State : 인터랙션이 있거나 상태가 바뀌는 경우를 표시.
- Size : 크기가 다른 경우를 표현.
- 또한, 아래의 부분을 주의하며 작명한다.
- 누가 봐도 이해할 수 있도록 줄임말과 개인 기호는 지양한다.
- 예외 상황도 구조를 유지한 채 명확히 처리한다.
- 검색에 강한 구조로 예측 가능한 순서를 유지한다.
- 줄여도 되는 부분과 줄이면 안 되는 부분을 구분.
- 만드는 서비스의 규모에 따라 네이밍 전략을 유연하게 사용한다.
실무 배리언츠와 프로퍼티
- 컴포넌트의 규모가 점점 커지다보면 한 컴포넌트에 수십 개의 배리언츠가 존재하는 경우도 생기지만, 실제로는 아래의 요소들을 판단하여 10개 내외로 사용한다.
- 지나치게 많아서 역으로 유지보수하기 힘들면 쪼개서 사용한다.
- 사용 빈도가 낮은 조합은 과감히 제외한다.
- 아이콘 또는 테두리 여부는 Boolean 프로퍼티를 이용해 단순화한다.
- 공통 속성으로 묶이는 경우에만 배리언츠로 유지한다.
- 즉 자주 사용되는 조합만 배리언츠로 만들고, 나머지는 프로퍼티로 처리하는 게 훨씬 효율적이다.
- 복수 선택지라면 배리언트, on/off는 Boolean, 이미지나 컴포넌트 교체는 인스턴트 스왑이 적절한 구조 방식이다.
트레이드 오프
- 정교할 수록 유지보수가 어렵고, 간단할 수록 다양한 디자인이 어렵듯이 무언가를 얻기 위해 다른 것을 포기하는 상호 교환의 선택이 요구된다.
- 디자인 시스템에서도 모든 조합이 완벽해지면 구조는 명확해지나 관리 비용이 급증하고, 단순하게 유지하면 누락이 생기거나 예외 처리가 복잡해진다.
- UI 디자이너는 어느 정도를 포기하고 어느 정도까지 챙길 것인지 판단할 수 있어야한다.
디자인 시스템
- UI 정리에 있어 디자인 시스템의 부재보다 문제인 것은 정리하는 기준이 없는 것으로, 정교한 디자인 시스템이 아니라 의도가 정리된 최소 요소들이 중요하다.
- 디자인 시스템은 결국 여러 기준과 규칙이 모여서 하나의 매뉴얼을 만드는 것이다.
- 디자인 시스템 설계 시 UI를 효율적으로 운용하는 실무적인 방법은 아래와 같다.
- 모든 컴포넌트를 구조화할 필요는 없다.
재사용이 불가능한 일회성 화면이나 이벤트성 배너는 굳이 컴포넌트로 만들지 않아도 되며, 재사용 가능성이 높은 요소부터 차근차근 구조화한다.
- 배리언츠로 굳이 만들지 않아도 기본적인 UI는 갖출 수 있다.
처음부터 완성된 시스템을 가져가려고 하기보다는 제품 방향이나 사용자가 우리 서비스를 쓰는 이유 등 더 중요한 논의를 우선시한다.
-의도와 맥락을 담아 네이밍을 한다.
컴포넌트에 적당한 이름을 잘 붙이는 것만으로도 충분한 정보를 담을 수 있으며, 배리언츠도 복잡하게 만들지 않아도 네이밍 구조만으로도 유사한 구조와 맥락을 파악할 수 있다.
일관성 있는 UI를 위한 관리 전략
- 무조건 적인 오토레이아웃 배제 :
오토레이아웃은 피그마에서 시각적인 작업 위주로 사용하다보니, 실제 개발 단계에서는 구조적으로 맞지 않는 경우가 있으며, 이때는 오토레이아웃 사용을 배제해도 좋다. - 색상과 텍스트 스타일은 기본 3가지 정도로 시작한다 :
초기 단계에서 너무 많은 스타일은 오히려 정보 구조를 더 복잡하게 할 가능성이 높아, 검증 단계에서는 쉽게 인식 가능하도록 3가지 정도만 사용하는 것이 권장된다. - 컴포넌트 상태는 의미 중심으로 구분한다 :
스타일의 차이보다는 행동 상태나 속성 순서 같은 기준에 따라 분리하여 나누는 게 유지보수나 검색에 용이하다.
'UI\UX 공부 > UIUX강의정리' 카테고리의 다른 글
| [2강] 유저 리서치 (0) | 2025.08.28 |
|---|---|
| [1강] UI/UX 프로세스 이해 (2) | 2025.08.27 |
| [실전UI디자인] ch2. 구조와 흐름을 통한 UI 설계 (4) | 2025.08.07 |
| [실전UI디자인] ch1. UI 디자인의 개념 (4) | 2025.08.07 |
| [Day3] 디자인 툴과 프로토타입 (1) | 2025.08.01 |