[내일 배움 캠프] 16일차

컴포넌트 설계

컴포넌트 설계는 확장성과 유지보수성을 기준으로, 화면 단위 혹은 디자인 시스템 단위로 나눠 설계 기준을 정립하는 것이 중요함

실제 제품 환경에서는 컴포넌트를 체계적으로 관리하고 재설계할 수 있는 명확한 기준점이 필요함

UI의 모든 요소(버튼, 인풋 필드, 카드 UI, 검색창, 탭바, 배너, 상품 리스트, 피드 등)는 각기 독립적 기능 혹은 반복 패턴으로서 컴포넌트로 봄

컴포넌트 사용 시에는 단순한 활용이 아니라 명확한 의도가 중요하며, 체크박스와 같은 UI 요소도 그 맥락에 맞는 기능적 목적을 가져야 함

동일한 버튼이나 UI를 매 화면마다 일일이 반복해서 그리면, 전체 UI 수정 시 몇백 장의 화면을 모두 직접 찾아서 수정해야 하는 비효율이 발생하고, 일부 누락되면 UI 일관성이 떨어짐

카드 UI는 이미지나 텍스트 변화에 따라 크기가 일관되지 않으면 사용자가 정보 구조를 예측하지 못해 사용 비용이 증가

디자이너마다 동일 기능에 대해 다른 컴포넌트를 만들 경우 협업 및 커뮤니케이션 문제가 발생하고, 개발 일정이 지연

디자인 시스템 규모에 집착하기보다, 유지보수가 쉬운 정도로 운용하는 것이 현실적으로 더 좋음

사용성과 활용성의 충족 여부가 컴포넌트의 좋고 나쁨을 판단하는 핵심 기준

사용성과 활용성은 더욱 구체적으로 재사용성, 유연성, 확장성, 일관성, 협업 친화성 5가지 기준으로 세분화해 평가할 수 있음

컴포넌트 네이밍

네이밍이란 이름을 붙이는 행위이며, 컴포넌트 네이밍은 컴포넌트에 이름을 주는 것을 의미합니다.

일관된 네이밍 전략은 검색, 재사용, 협업, 유지 보수 등 팀플레이 환경에서 반드시 필요

컴포넌트 네이밍 규칙(네이밍 컨벤션)을 정하고, 잘 만들어두는 것이 실무에서 중요

컴포넌트 네이밍은 단순한 이름 짓기가 아니라, 전체 컴포넌트들의 구조와 상호 관계를 드러내는 핵심 요소

네이밍은 보기 좋게 만드는 것이 목적이 아니라, 해당 컴포넌트의 구성 요소와 속성을 명확히 설명하는 도구

컴포넌트 이름은 컴포넌트 타입, 스타일, 상태, 사이즈 순으로 구성하는 것이 일반적

컴포넌트 타입은 UI 요소의 카테고리(예: 툴팁, 버튼, 텍스트필드 등)를 의미

이름 두 번째에는 프라이머리, 세컨더리, 터시어리, 솔리드 등 스타일 관련 속성을 추가, 세 번째로는 상태나 인터랙션(예: default)이 포함되며, 네 번째로는 medium처럼 사이즈가 붙음

베리언트는 스타일의 다양한 변형을 만들 수 있으며, 프로퍼티는 컴포넌트의 속성을 패널에서 조정할 수 있도록 해주는 피그마의 핵심 기능

피그마에서는 자유롭게 베리언트와 프로퍼티를 활용해 이상적인 컴포넌트를 만들 수 있지만, 실제 개발에서는 기술적 한계로 인해 그대로 구현하지 못하는 경우가 많음

조합 폭발은 베리언트와 프로퍼티를 활용할 때 대부분의 디자이너가 겪는 문제

실질적으로 사용하는 버튼의 조합은 10개 이하인 경우가 대부분이므로, 모든 조합을 만드는 것은 비용 낭비에 해당할 수 있음

베리언트를 만들 때는 실제 사용하는 조합만 남기고, 서비스 특성상 필요 없는 상태(예: 로딩 버튼)는 과감히 제거할 수 있습

컴포넌트 개수가 많아질 때는 사이즈별 등 구조적으로 나누어 관리하면 유지보수가 쉬워지고, 필요에 따라 통합 관리와 개별 관리 방식을 선택할 수 있음

트레이드오프란?

어떤 것을 얻기 위해 다른 것을 포기하는 ‘상호 교환의 선택’을 말함

디자인 시스템에서도 모든 조합을 완벽히 만들면 구조는 명확해지지만, 관리 비용이 급증

반대로 단순하게 유지하면 누락이 생기거나 예외 처리가 복잡해짐

컴포넌트 트레이드오프를 판단할 때 고려할 것

우리는 지금 MVP 단계인가?

이 컴포넌트를 3명이 쓸까, 30명이 쓸까?

앞으로 3개월 뒤에도 이 구조가 유효할까?

이 속성이 사용자 경험에 큰 영향을 주는가?

디자인 시스템 운용 전략

모든 컴포넌트를 구조화할 필요는 없음

배리언츠로 굳이 만들지 않아도 기본적인 UI는 갖출 수 있음

의도와 맥락을 이름에 담기

일관성 있는 UI를 위한 관리 전략

무조건 Auto Layout을 쓰지 않아도 됨

색상, 텍스트 스타일은 3가지 정도로 시작

컴포넌트 상태는 ‘의미’ 중심으로 구분

컴포넌트 관리 참고 사항

지금 내가 만든 이 컴포넌트는 3개월 뒤에도 사용 가능한 구조인가?

반복되는데 컴포넌트화하지 않은 요소가 있진 않나?

구조를 보면 누가 봐도 어떤 기능인지 이해할 수 있나?

이름만 봐도 역할을 유추할 수 있나?

프로토타입의 목적

프로토타입의 진정한 목적은 사용자의 목적에 맞는 흐름을 잘 만들었는지를 검증하는 것

프로토타입을 만드는 이유

기획서에 있는 플로우를 화면으로 구체화하고 싶어서

개발자에게 전달하기 위해

디자인 팀 내부에서 구조를 리뷰받기 위해

유저 테스트를 준비하기 위해

피그마 프로토타입의 장점

화면 간의 전환을 직관적으로 보여줄 수 있음

인터랙션 없이도 흐름을 빠르게 확인할 수 있음

공유 링크 하나로 누구와도 쉽게 리뷰할 수 있음

피그마 프로토타입의 단점

실제 동작을 보여주는 정교한 인터랙션 구현은 어려움

데이터 입력, 조건 분기, 애니메이션 등은 제한적임

모바일 앱처럼 터치에 따라 반응하는 행동을 완전히 시뮬레이션하긴 어려움

프로토타입 설계의 핵심 질문

이 흐름은 사용자 목적을 충실히 따라가고 있나?

어떤 화면이 꼭 필요한가요? 어떤 화면은 과잉인가?

중간에 사용자가 헤매거나 벗어날 여지는 없나?

이 질문들을 통해 디자인 결과물로써의 완성도가 아니라, 디자인의 목적과 흐름의 연결성을 검토할 수 있게 도와줌

사용자 흐름의 3가지 종류

Happy Path: 우리가 바라는 이상적인 사용자 흐름

Edge Case: 예상치 못한 상황에서 발생하는 예외적인 흐름

Alternate Path: 같은 목적을 다른 방법으로 도달하는 흐름

사용자 흐름 구조적으로 정리하기

플로우차트 (Flowchart)

전체 행동 흐름과 분기 조건을 시각화하는 가장 기본적인 방식

시나리오 플로우(와이어프레임이나 사용자 여정 지도)

사용자 페르소나별 또는 목적별 흐름을 나눠서 설계하는 방식
예: 신규 가입자 vs 기존 유저, 웹 vs 모바일 사용자 등

피그마 프로토타입 + 설명 텍스트

실제로 움직이는 화면으로 문서에선 놓칠 수 있는 디테일한 엣지 케이스를 찾아내기 좋은 방법요.

인터랙션 흐름과 함께, 각각의 화면 상단에 간단한 설명을 추가하는 것도 매우 효과적

프로토타입과 UX 설계 고도화

사용자가 길을 잃지 않고, 자연스럽게 다음 행동으로 넘어가게 만들기 위한 UI 전략이 필요

사용자가 멈추지 않게 만드는 UI 전략 5가지

1. Dead-end(막다른 길) 제거하기
   Dead-end는 말 그대로 사용자가 도달한 이후, 할 수 있는 행동이 아무것도 없는 상태를 말함

2. Affordance(어포던스)를 확실히 전달하기
   어포던스는 행동유도성이라는 뜻이에요. 사전적으로는 사용자에게 가능한 행동을 시각적으로 암시하거나 유도하는 UI의 성질을 말함

3. Nudging(넛징)으로 부드럽게 다음 행동 유도하기
   넛징(Nudge)은 강요하지 않고도 원하는 방향으로 유도하는 UI 전략

4. Hierarchy Back vs. History Back
   용어
   History Back(히스토리 복귀)

의미
사용자의 방문 이력을 ‘시간 순으로’ 되돌아감

예시
A → B → C → B

용어
Hierarchy Back(계층 복귀)

의미
기능·계층 구조상 ‘상위 단계’로 이동

예시
A(홈) → A.1(리스트) → A.1.1(상세) → A.1(리스트)

5. 터치 영역은 ‘보이는 것’보다 커야 함
   모바일 디자인에서 종종 누를 수 있는 영역이 너무 작아 잘 눌리지 않는 경우가 있음

프로토타입 점검의 의의

사용자가 실제로 원하는 목적을 달성할 수 있게 돕고 있는 흐름인지 점검해야 함

프로토타입 점검 체크리스트

1. 이 화면에서 사용자가 해야 할 ‘행동’이 단 하나로 잘 보이나?
2. 흐름에 꼭 필요한 화면만 포함되어 있나?
3. 사용자가 중간에 멈출 만한 지점이 있진 않나?
4. 화면 구성은 목적과 지표에 부합하나?
5. 상태에 따라 흐름이 잘 분기되나?
6. 시선 흐름이나 시각적 위계가 잘 반영됐나?

프로토타입과 커뮤니케이션

함께 제품을 만드는 구성원들과 제품 사용자에게 제품을 소개하는 과정

프로토타입의 핵심 목적은 이 제품이 어디로 가는지 모두 이해하게 만드는 것

실무 프로토타입 활용 사례

1. 디자인 리뷰
   본격적인 개발에 들어가기 전에, 기획과 디자인이 서로 이해한 바가 맞는지, 또는 디자이너들끼리 UX에 문제될 만한 부분은 없는지 맞춰보는 과정

2. 기획·개발과 스펙 협의
   개발에 필요한 자원을 가늠하고 개발 범위와 조건을 조율하는 목적

3. 유저 테스트(UT) 시나리오 구성
   실제 제품 출시 전에 사용자에게 제품와 유사한 형태의 프로토타입으로 테스트를 진행

4. 그 외 활용법
   QA나 고객지원팀에게 신기능 흐름을 설명할 때
   → 프로토타입을 보여주면 말보다 빠르게 이해됨
   마케팅팀이나 비즈니스팀에게 제품 구조를 소개할 때
   → 전체 서비스 흐름이 담긴 프로토타입은 좋은 자료가 됨
   새로 온 팀원에게 온보딩 자료로 활용할 때
   → 제품의 핵심 흐름을 빠르게 이해할 수 있음