figma2025년 10월 20일

디자인 시스템: 기초부터 앞으로 (새 탭에서 열림)

디자인 시스템은 대규모 제품에서 시각적 일관성을 유지할 뿐 아니라 디자인과 개발 사이의 간극을 줄이는 공통 기반이다. AI로 작업 속도와 아이디어 확장이 빨라질수록, 원칙과 구성 요소를 체계화한 디자인 시스템의 중요성은 더욱 커진다. 성공적인 시스템을 위해서는 명확한 문서화와 지속적인 성과 측정이 필수적이다. ## 디자인 시스템의 기원과 발전 - 디자인 시스템은 초기 그래픽 디자인과 인쇄 매체의 스타일 가이드, 타이포그래피 표준에서 출발했다. - 20세기 중반 기업 브랜드의 중요성이 커지면서 일관된 브랜드 정체성을 위한 종합 가이드라인이 발전했다. - 디지털 전환 이후 IBM, Microsoft, Apple, Google 등은 이러한 원칙을 디지털 인터페이스로 확장했다. - 오늘날의 디자인 시스템은 운영체제 규칙과 UI 패턴을 표준화하고, 내부 팀과 외부 개발자가 일관된 제품 경험을 만들도록 돕는다. - 기존 인쇄 디자인 시스템을 디지털 인터페이스로 전환한 미국 국립공원관리청 사례처럼, 오래된 디자인 원칙도 디지털 환경에 맞게 재해석할 수 있다. ## 문서화를 통한 도입 확대 - 문서화는 추상적인 디자인 원칙을 실제 작업 지침으로 바꾸는 역할을 한다. - 디자이너와 개발자가 시스템을 어떻게 사용해야 하는지 알 수 있는 공통 참고점이 되어 사용에 대한 자신감을 높인다. - Alaska Airlines의 디자인 시스템 Auro는 도입 과정에서 문서화를 우선시했다. - Figma의 오토 레이아웃 사용법 - 브랜치 병합 방법 - 주요 기능을 작업에 적용하는 방법 - 문서화만으로 adoption이 보장되지는 않는다. - 역할에 따라 필요한 정보가 다르므로 문서는 다음과 같이 다양하게 제공되어야 한다. - 개발자에게 필요한 상세 사양 - 디자이너를 위한 사용 지침 - 전체 팀이 이해할 수 있는 고수준 원칙 - 시각적 예시와 맥락 설명 - 디자인 과정에 참여하는 직군이 늘어날수록 문서는 명확하고 쉽게 접근할 수 있어야 한다. ## 디자인 시스템의 ROI 측정 - 디자인 시스템의 비즈니스 효과는 정량적 지표로 추적할 수 있다. - 활용 가능한 주요 지표는 다음과 같다. - 구성 요소와 기능의 사용량 - 팀과 프로젝트의 도입률 - 디자인 일관성 점수 - athenahealth는 일관성 점수를 분석하는 과정에서 특정 컨테이너 컴포넌트의 detach 증가를 발견했다. - 컴포넌트가 분리되는 현상은 다음 문제를 나타낼 수 있다. - 컴포넌트의 버그 - 현재 기능으로 충족되지 않는 개선 요구 - 기존 요소를 예상하지 못한 방식으로 조합하는 사용 패턴 - 따라서 지표는 단순히 성공 여부를 판단하는 수단이 아니라, 시스템의 결함과 사용자 요구를 발견하는 피드백 수단으로 활용해야 한다. ## 디자인 시스템이 맡는 역할 - 디자인과 개발 간의 커뮤니케이션 비용을 줄인다. - 반복적인 UI 제작을 표준화해 작업 효율을 높인다. - 여러 팀과 제품에 걸쳐 일관된 사용자 경험을 유지한다. - AI가 생성한 결과물을 검토하고 조정할 수 있는 기준과 제약을 제공한다. - 조직이 커질수록 개인의 경험이나 구두 지식에 의존하지 않고, 공유된 규칙과 문서에 기반해 협업하도록 만든다. 실무에서는 처음부터 거대한 시스템을 만들기보다 핵심 컴포넌트와 사용 규칙부터 정의하고, 역할별 문서와 사용 데이터를 함께 구축하는 것이 좋다. 특히 detach, 미사용 컴포넌트, 도입률 같은 신호를 정기적으로 분석하면 디자인 시스템을 실제 팀의 필요에 맞게 개선할 수 있다.

component-libraryfigmaaidesign-systems+3

figma2025년 4월 7일

Figma에서 디자인 시스템 워 (새 탭에서 열림)

Figma의 디자인 시스템 구축은 색상·타이포그래피·간격·문서화·개발 전달을 반복해야 해 시간이 많이 걸리지만, 최신 기능과 커뮤니티 플러그인을 조합하면 작업을 크게 단축할 수 있다. 특히 모드와 컬렉션을 안전하게 재정렬하고, 변수·스타일·컴포넌트 관리를 자동화함으로써 디자인 시스템을 개념 설계부터 코드 변환까지 효율적으로 연결하는 것이 글의 핵심이다. ## 모드와 컬렉션을 안전하게 재정렬 - 라이브러리의 모드와 컬렉션을 드래그 앤 드롭으로 재배치할 수 있다. - 삭제 후 재생성할 필요가 없어 디자인이 다른 모드와 동기화되지 않는 문제를 줄인다. - 재정렬해도 모드 ID와 연결 정보가 유지된다. - 기본 모드도 간단히 변경할 수 있다. - 자주 사용하는 컬렉션을 위로 올리거나, 관련 모드를 그룹화하거나, 제품 라인 변경에 활용할 수 있다. ## 작업 흐름을 개선하는 9가지 업데이트 - 메인 컴포넌트로 바로 이동하는 단축키가 추가됐다. - 스타일을 복제하거나 복사해 반복 작업을 줄일 수 있다. - 변수 페인트를 숨기거나 다시 표시해 작업 공간을 정리할 수 있다. - 컴포넌트 설명 UI가 개선되어 내용을 빠르게 확인할 수 있다. - 변수 모달의 헤더 전체를 드래그할 수 있다. - 변수 변경 사항이 자동 저장된다. - 컴포넌트 이름에 마우스를 올리면 툴팁으로 추가 정보를 볼 수 있다. - 편집 버튼 정렬이 개선됐다. - 스타일 창에서 긴 이름이 잘리지 않도록 텍스트 오버플로 처리가 개선됐다. ## 색상 팔레트와 색상 토큰 만들기 - **CSS color-mix()** - CSS의 `color-mix()`를 활용해 색상 팔레트와 그라디언트를 생성한다. - **Colorbox** - 전체 색상 램프를 빠르게 만든다. - **The Genome Color Tool** - WCAG 접근성 기준을 만족하는 색상 스케일을 구축한다. - 색상 시스템을 수작업으로 하나씩 조정하는 대신, 다양한 명도 단계와 조합을 빠르게 실험할 수 있다. - 접근성 기준을 초기 단계부터 반영해 후속 수정 비용을 줄일 수 있다. ## 타이포그래피와 변수 문서화 - **Peppercorn** - 디자인 시스템 전체의 타입 시스템을 설정하는 데 사용된다. - **Print Variables** - 변수 컬렉션을 스티커 시트 형태로 캔버스에 출력한다. - **Auto Documentation** - 모든 변수를 시각적인 스티커 시트로 만들어 문서화한다. - **Variables and Styles List** - 변수와 스타일 목록을 캔버스 위젯으로 생성해 팀이 한눈에 확인하도록 돕는다. - 이러한 도구는 색상, 글꼴, 크기, 간격 등 토큰의 이름과 값을 시각적으로 검토하는 데 유용하다. ## 컴포넌트 구조와 스펙 정리 - **Propstar** - 컴포넌트의 프로퍼티와 가능한 변형 조합을 시각적으로 정리한다. - **Specs** - 컴포넌트 사양을 생성해 디자인 의도와 구현 정보를 전달한다. - **Similayer** - 특정 레이어나 속성을 기준으로 요소를 필터링한다. - **Style Finder** - 여러 페이지에 흩어진 스타일을 찾아 관리할 수 있게 한다. - 컴포넌트 변형이 많아질수록 어떤 조합을 지원하는지 파악하고 중복 또는 누락을 발견하는 데 도움이 된다. ## 변수와 디자인 토큰을 코드로 연결 - **CTRL Var** - 변수를 일괄적으로 이름 변경할 수 있다. - **Export Import Variables** - Figma 안팎으로 변수를 가져오고 내보낸다. - **Handoff** - CSS 변수를 즉시 복사해 개발 전달을 단순화한다. - **Variables Converter** - Figma 변수를 코드 형식으로 변환한다. - **Shaper** - 토큰 아키텍처를 관리하고 CSS 코드를 생성한다. - 디자인 토큰을 Figma에만 고립시키지 않고 개발 환경의 변수와 연결할 수 있다. ## 디자인 시스템 구축 단계별 접근 - **기초 설계** - 색상 팔레트, 색상 램프, 타이포그래피 스케일, 변수 컬렉션을 구성한다. - **문서화** - 변수와 스타일을 스티커 시트나 목록으로 정리해 팀이 쉽게 탐색하도록 만든다. - **구현과 핸드오프** - 컴포넌트 사양을 생성하고, 변수와 토큰을 CSS 등 코드로 변환한다. - Figma의 기본 기능과 플러그인을 각 단계에 맞게 조합하면 디자인 시스템을 처음부터 코드 전달까지 일관되게 관리할 수 있다. 실무에서는 먼저 모드·컬렉션 구조와 변수 명명 규칙을 정한 뒤, 색상·타이포그래피 플러그인으로 토큰을 만들고, 문서화 및 코드 변환 도구를 선택적으로 도입하는 방식이 효과적이다.

component-libraryfigmadesign-systemsdesign-tokens+4

figma2025년 1월 22일

도입을 이끄는 문서화 (새 탭에서 열림)

디자인 시스템 문서는 컴포넌트 목록을 나열하는 자료가 아니라, 디자인 의도와 구현 방법을 연결해 팀의 실제 사용을 이끄는 제품이어야 한다. 좋은 문서는 디자이너와 개발자 사이의 언어 차이를 줄이고, 일관된 의사결정·효율적인 온보딩·플랫폼 간 품질 유지를 가능하게 한다. 이를 위해 조직에 맞는 단일 진실 공급원(source of truth)을 정하고, 시스템과 함께 계속 진화하는 문서로 운영해야 한다. ## 문서화가 필요한 이유 - Razorpay는 디자인 시스템 Blade를 도입하기 전 팀마다 버튼 상태나 텍스트 필드 오류 처리 방식을 놓치는 일이 있었다. - 문제의 본질은 단순한 품질 부족이 아니라 디자인 의도와 구현 방식이 제대로 전달되지 않는 커뮤니케이션 문제였다. - 개발자와 디자이너 사이의 언어 차이로 다음과 같은 불일치가 발생할 수 있다. - 컴포넌트와 속성의 명칭이 서로 다름 - 디자인의 상태와 실제 코드 구현이 다름 - 제품의 시각적·상호작용적 기대치가 어긋남 - 문서는 단순히 “무엇이 있는가”를 보여주는 데 그치지 않고, 각 결정의 **방법(how)** 과 **이유(why)** 를 설명해야 한다. - 효과적인 문서는 다음을 돕는다. - 디자인 원칙과 구현 세부 사항 이해 - 여러 제품과 플랫폼에서 일관된 결정 - 신규 팀원의 빠른 온보딩 - 디자이너와 개발자 간 협업 개선 ## 단일 진실 공급원 정하기 문서화를 시작할 때 가장 먼저 결정할 것은 무엇을 쓸지가 아니라 **어디에 둘지**다. - 디자인 시스템이 성장하고 조직이 커질수록 정보가 여러 도구에 분산되기 쉽다. - 공유 드라이브의 정적 PDF처럼 한 번 만들어 놓고 갱신하지 않는 방식은 빠르게 낡는다. - 전용 문서 사이트, 협업 워크스페이스 등 조직의 규모와 업무 흐름에 맞는 저장소를 선택해야 한다. - 중요한 것은 도구 자체보다 팀이 “최신 정보는 어디에 있는가”를 명확히 알 수 있게 하는 것이다. - 문서는 디자인 파일, 코드 저장소, 개발자 도구와 연결되어야 하며, 디자이너와 개발자가 같은 기준을 참조할 수 있어야 한다. ## 맞춤형 문서 사이트의 역할 본문은 대규모 조직의 경우 자체 문서 사이트가 디자인 시스템을 도구와 프로세스에 깊이 통합하는 데 유리하다고 설명한다. - 여러 제품과 플랫폼을 운영하는 조직은 전용 사이트를 통해 문서 구조와 탐색 경험을 직접 설계할 수 있다. - 컴포넌트의 시각적 예시뿐 아니라 사용법, 코드 구현, 상태, 접근성 지침까지 한곳에서 제공할 수 있다. - 디자인 시스템이 사용하는 도구와 개발 워크플로에 맞춰 문서를 확장할 수 있다. - 다만 자체 사이트를 구축하는 것만으로는 충분하지 않으며, 최신 상태를 유지하는 운영 체계가 함께 필요하다. ## 도입을 이끄는 살아 있는 문서 - 문서는 디자인 시스템과 별개로 관리되는 부가 자료가 아니라 시스템의 일부여야 한다. - 컴포넌트가 변경되면 관련 사용법과 코드 예시도 함께 갱신되어야 한다. - 문서에는 컴포넌트의 외형뿐 아니라 다음 정보가 포함되어야 한다. - 언제 사용하고 언제 사용하지 않는지 - 지원하는 상태와 속성 - 상호작용 및 오류 처리 방식 - 디자인 결정의 배경과 목적 - 개발자가 실제로 적용할 수 있는 구현 정보 - 사용자가 문서를 읽은 뒤 바로 디자인하거나 코드를 작성할 수 있어야 adoption으로 이어진다. ## 실용적인 결론 디자인 시스템 문서는 “보관용 설명서”가 아니라 팀의 공통 언어이자 제품 사용 경험의 일부로 운영해야 한다. 하나의 공식 출처를 정하고, 디자인·코드·문서의 변경을 연결하며, 각 컴포넌트의 사용법과 설계 이유까지 기록하는 방식이 가장 실용적이다.

component-libraryfigmadesign-systemsdesign-tokens+3

figma2024년 11월 12일

새로운 시대를 위한 웹 (새 탭에서 열림)

Figma는 2024년 브랜드 리프레시를 계기로 figma.com의 웹 디자인 시스템을 전면 점검했다. 기존 시스템은 유사한 컴포넌트가 지나치게 많고, 색상과 타이포그래피가 확장된 브랜드와 다양한 콘텐츠를 충분히 지원하지 못했다. 사용 현황을 데이터로 분석해 컴포넌트를 단순화하고, 일관된 디자인 원칙과 재사용 가능한 템플릿을 마련함으로써 더 유연하고 미래 지향적인 웹 시스템을 구축했다. ## 브랜드와 웹 시스템을 함께 재정비한 배경 - 2020년의 figma.com은 새로운 디자인 도구를 소개하는 데 초점이 맞춰져 있었다. - 2024년의 Figma는 여러 제품 팀을 위한 플랫폼으로 확장되었고, 웹사이트 역시 제품 생태계와 다양한 사용자 요구를 보여줘야 했다. - 기존 시스템에는 다음과 같은 문제가 있었다. - 서로 조금씩만 다른 컴포넌트가 많아 적절한 컴포넌트를 선택하기 어려움 - 변화하는 브랜드 색상 팔레트를 수용할 만큼 색상 체계가 유연하지 않음 - 다양한 콘텐츠 유형을 지원하기에 타이포그래피 체계가 충분히 최적화되지 않음 - Figma Sans와 새로운 색상·일러스트레이션 스타일을 도입한 브랜드 리프레시는 웹 디자인 시스템을 재설계하는 계기가 되었다. ## 컴포넌트 사용 현황을 데이터로 감사 - Web Experience 팀은 스크립트를 작성해 컴포넌트가 다음과 같이 어떻게 사용되는지 분석했다. - 어떤 컴포넌트가 사용되는가 - 각 컴포넌트가 얼마나 자주 사용되는가 - 어떤 페이지에서 사용되는가 - 이 분석을 통해 실제 사용량과 필요성을 기준으로 컴포넌트 구조를 단순화할 수 있었다. - 디자인 시스템을 직관이나 선호만으로 관리하지 않고, 실제 페이지와 팀의 사용 패턴을 근거로 개선한 점이 핵심이다. ## Flex 컴포넌트의 48개 변형을 24개로 축소 - 가장 널리 사용되던 기본 구성 요소인 ‘Flex’ 컴포넌트는 옵션이 추가되면서 48개 변형까지 늘어나 있었다. - 사용 사례를 조사한 결과, 기능을 유지하면서도 변형 수를 24개로 줄일 수 있었다. - 중복되거나 활용도가 낮은 선택지를 제거해 속성 패널을 더 집중된 형태로 만들었다. - 예를 들어 가운데 정렬 텍스트 옵션을 없애고, 웹 시스템 전체에서 왼쪽 정렬을 기본값으로 정했다. - 그 결과: - 디자이너와 콘텐츠 제작자가 선택해야 할 옵션이 줄어듦 - 컴포넌트 사용법이 쉬워짐 - 웹페이지 전반의 시각적 일관성이 높아짐 - 새로운 브랜드 언어와도 더 잘 맞게 됨 ## 템플릿과 조합 가능한 빌딩 블록 - 단순히 기존 컴포넌트를 줄이는 데 그치지 않고, 자주 쓰는 페이지 레이아웃을 템플릿으로 만들었다. - 여러 방식으로 조합할 수 있는 “building block” 컴포넌트 세트도 구축했다. - 이를 통해 팀은: - 일반적인 페이지 구조를 더 빠르게 만들고 - 필요한 구성 요소를 조합해 다양한 페이지를 제작하며 - 별도의 커스텀 작업 없이도 Figma 브랜드에 맞는 결과물을 만들 수 있게 되었다. - 컴포넌트 선택지를 무작정 늘리는 대신, 검증된 핵심 요소와 조합 방식을 제공하는 접근이다. ## 실용적인 시사점 - 디자인 시스템을 정기적으로 감사하고 실제 사용 데이터를 확인해야 한다. - 유사한 변형이 계속 늘어난다면 기능을 유지하면서 옵션을 통합할 수 있는지 검토할 필요가 있다. - 명확한 기본값과 일관된 원칙을 정하면 사용자의 선택 부담을 줄일 수 있다. - 공통 레이아웃 템플릿과 조합형 컴포넌트를 함께 제공하면 확장성과 제작 속도를 모두 높일 수 있다.

component-libraryfigmadesign-systemstypography+1

figma2024년 7월 29일

HP, 개발자 모드로 디자인 (새 탭에서 열림)

HP는 100개가 넘는 제품군과 여러 사업부가 각기 다른 방식으로 디지털 경험을 만들던 문제를 해결하기 위해 디자인 시스템 Veneer와 Figma Dev Mode를 도입했다. Veneer는 디자인 언어, 컴포넌트, 문서화, 거버넌스를 통합하고, Dev Mode는 디자인과 개발 사이의 전달 과정을 간소화했다. 그 결과 HP는 디자인 일관성을 높이고 일부 프로젝트의 개발 시간을 50% 줄였으며, 대규모 조직에서 디자인 시스템의 채택 효과를 정량적으로 측정할 수 있었다. ## 복잡한 제품 생태계를 위한 다층 디자인 시스템 - HP는 프린터, 노트북, 게이밍 시스템 등 100개 이상의 다양한 제품군을 운영한다. - 각 제품과 사업부가 독립적으로 움직이면서 디지털 경험의 시각적·사용자 경험적 일관성을 유지하기 어려웠다. - 초기에는 단순한 프런트엔드 컴포넌트 라이브러리였던 Veneer가 다음 요소를 포함하는 종합 디자인 시스템으로 발전했다. - HP 브랜드에 기반한 디자인 언어 - 디자인 및 개발용 컴포넌트와 패턴 - 사용 지침, 원칙, 모범 사례, 코드 표준, 코드 스니펫 - 디자이너와 개발자의 피드백을 반영하는 커뮤니티와 거버넌스 - HP의 여러 서브 브랜드를 하나의 획일적인 시스템으로 지원하기는 어렵기 때문에, Veneer는 공통 기반을 유지하면서도 브랜드별 차이를 수용할 수 있는 다층 구조로 설계됐다. ## 채택률과 효율성 측정 - HP는 Veneer의 효과를 사용량 같은 정량 지표와 구성원 피드백 같은 정성 지표를 함께 활용해 평가한다. - 아이콘 라이브러리의 경우: - 320개 팀이 사용 - 915개의 아이콘 컴포넌트 제공 - 주당 평균 8만 5천 회 삽입 - 디자인 시스템을 활용하면 처음부터 구현하는 것보다 개발 속도가 크게 향상된다. 글에서는 IBM 연구의 단순 폼 개발 속도 47% 향상 사례도 언급한다. - 2023년 1월부터 12월까지 Veneer를 통해 프로젝트가 절약한 시간이 시스템 제작에 투입된 시간보다 500% 많았다. - HP 엔지니어링 리더십에 따르면 일부 프로젝트에서는 개발 시간이 50% 단축됐다. - 다만 디자이너들은 자신이 담당하는 제품과 사용자 경험에 강한 책임감을 갖고 있어, 외부 시스템의 도입을 제품의 창의성을 제한하는 일로 받아들일 수 있었다. - HP는 Veneer가 반복적인 작업을 줄이고 디자이너가 제품 고유의 문제와 창의적인 부분에 집중하도록 돕는다는 점을 보여주며 채택을 유도했다. ## Dev Mode로 디자인과 개발 연결 - Dev Mode는 개발자가 Figma 안에서 디자인 사양을 직접 확인하도록 해 디자인 핸드오프를 간소화했다. - 이로 인해 사양을 확인하기 위한 회의와 디자이너·개발자 간의 반복적인 질의응답이 줄었다. - HP가 특히 유용하게 활용한 기능은 다음과 같다. - **변경 사항 비교**: 기존 제품을 업데이트할 때 디자인 버전 간 변경점을 빠르게 확인할 수 있다. - **개발 준비 완료 표시**: 디자이너가 구현할 영역을 명시해 개발자가 작업 범위를 명확히 파악할 수 있다. - **변수**: 프리미티브 토큰이나 시맨틱 토큰과 연결된 변수를 활용해 여러 테마와 모드에 대응하고 디자인 시스템을 확장할 수 있다. - Dev Mode는 단순히 디자인 파일을 개발자에게 전달하는 도구가 아니라, Veneer의 컴포넌트와 토큰을 실제 코드 구현으로 연결하는 협업 환경으로 활용됐다. HP의 사례는 대규모 조직에서 디자인 시스템을 성공적으로 운영하려면 공통 컴포넌트만 제공하는 것보다 브랜드별 유연성, 명확한 문서화, 거버넌스, 채택 지표가 함께 필요하다는 점을 보여준다. 또한 Dev Mode처럼 디자인 변경 사항과 구현 정보를 같은 작업 흐름에서 제공하면 핸드오프 비용을 줄이고 개발 생산성을 높일 수 있다.

component-libraryfigmadesign-systemsdesign-tokens+2

figma2024년 7월 10일

Config 2024의 (새 탭에서 열림)

Config 2024의 시각 아이덴티티는 Figma의 제품 경험을 행사 공간과 디지털 접점 전체로 확장하는 데 초점을 맞췄다. Figma의 캔버스, Figma Slides, 다양한 제작 모드를 바탕으로 기본 도형이 변형·확장되는 형태 언어를 만들었으며, 이를 통해 독립적인 행사 정체성과 Figma 브랜드의 일관성을 동시에 확보했다. 1만 명 이상의 현장 참가자와 온라인 참가자를 고려해 미적 요소뿐 아니라 안내와 동선까지 아우르는 모듈형 디자인 시스템으로 구현한 것이 핵심이다. ## Figma 기능에서 출발한 형태 언어 - 브레인스토밍 단계에서 새롭게 개편된 Figma와 Figma Slides의 핵심 경험을 시각적 출발점으로 삼았다. - 작업 생성, 공유, 발표 등 서로 다른 제작 모드를 전환하는 경험에서 영감을 얻었다. - Figma 캔버스와 Figma Slides의 새로운 캔버스를 시각적으로 해석해, 형태가 확대·이동·변형되며 예상하지 못한 관점을 보여주는 시스템을 구상했다. - 주요 테마는 다음과 같다. - 작업과 맥락 사이를 이동하는 움직임 - 캔버스를 비우거나 작업을 보여주며 창작 의도를 증폭하는 것 - 협업을 통해 다양한 관점이 만나는 것 - 여러 제작 방식을 포용하는 것 ## 형태와 기능의 결합 - 행사 디자인을 단순한 장식이 아니라 사용자 경험 설계의 문제로 접근했다. - 등록부터 원하는 발표 세션의 좌석 확보까지, 참가자가 마주하는 다양한 상황을 시각 언어로 지원해야 했다. - 정교한 비주얼과 일관된 안내 체계를 결합해 복잡한 행사 경험을 이해하기 쉽게 만들었다. - 기본적인 원시 도형을 조합해 더 복잡한 대형 그래픽과 공간 요소를 제작했다. ## 공간 전체로 확장된 슈퍼그래픽 - 샌프란시스코 Moscone Center의 넓은 규모에 맞춰 건물 외벽과 다양한 표면에 그래픽을 적용했다. - 행사장 중앙에는 서로 다른 형태의 대형 물리적 슈퍼그래픽 세 개를 설치했다. - 참가자들은 이 구조물을 좌석, 사진 촬영 배경, 만남의 장소로 활용했다. - 그래픽을 평면 이미지에 머물게 하지 않고 참가자가 직접 상호작용하는 공간 경험으로 확장했다. ## 기본 도형을 활용한 모듈형 시스템 - Config 브랜드의 지속적인 모티프인 도형을 Figma 툴바의 기본 도형에서 가져왔다. - 사각형 - 원 - 다각형 - 누구나 Figma에서 디자인을 시작할 때 사용하는 단순한 도형을 복잡한 슈퍼그래픽의 구성 요소로 발전시켰다. - 동일한 브랜드를 유지하면서도 수많은 행사 자산이 반복적으로 보이지 않도록 모듈형 구조를 설계했다. - Figma 안에 슈퍼그래픽 컴포넌트 라이브러리를 구축하고, 각 그래픽마다 세 가지 변형을 제공해 서로 다른 각도와 구성을 표현했다. - 이 방식으로 행사장, 디지털 화면, 인쇄물 등 다양한 접점에서 일관성과 변주를 동시에 확보했다. ## 대규모 행사에 대응하는 디자인 시스템 - Config에는 현장 참가자 1만 명 이상과 더 많은 온라인 참가자가 참여하므로, 작은 접점까지 포함한 전체 경험 설계가 필요했다. - 키노트나 건물 외벽처럼 눈에 띄는 요소뿐 아니라 다음 항목에도 동일한 시각 언어를 적용했다. - 디지털 화면 - 안내물 - 기념품과 스웨그 백 - 행사장 내 각종 접점 - 행사 아이덴티티가 특정 장면에만 존재하는 것이 아니라 참가자의 모든 상호작용에서 이어지도록 설계했다. ## 실용적인 시사점 대규모 브랜드 경험을 만들 때는 먼저 브랜드의 핵심 기능이나 사용자 경험에서 반복 가능한 시각 원리를 추출하는 것이 효과적이다. 이후 기본 도형과 컴포넌트처럼 재사용 가능한 단위로 시스템화하면, 수많은 채널에 빠르게 적용하면서도 일관성·확장성·변주를 함께 유지할 수 있다.

component-libraryfigmadesign-systemsux-design+1

figma2024년 4월 15일

카바나가 일관성과 확장성을 (새 탭에서 열림)

Carvana는 Figma의 디자인 시스템과 변수를 활용해 빠른 성장 속에서도 제품 경험의 일관성과 확장성을 유지했다. 분산된 디자인 도구를 Figma로 통합해 단일 기준을 만들고, 변수와 테마 기능으로 디자인·개발 협업과 브랜드 확장을 효율화했다. 그 결과 반복 작업과 수정이 줄고, 새로운 사업 영역에도 기존 디자인 언어를 빠르게 적용할 수 있었다. ## 성장에 대응하는 단일 기준 마련 - Carvana는 2019년 성장세가 가속화되면서 확장 가능한 디자인 플랫폼이 필요해졌다. - 기존 디자인 시스템은 PDF 기반 UI 키트, Principle, Sketch 등 여러 도구에 흩어져 있었다. - 컴포넌트를 복사해 사용하는 방식 때문에 동일한 요소가 조금씩 변형됐고, 디자인과 개발팀이 참조할 중앙 기준이 없었다. - Figma로 디자인 시스템을 이전하면서 디자인·개발팀이 함께 참조할 수 있는 연결된 단일 소스 오브 트루스를 구축했다. - 코로나19 시기 차량 판매가 급증했을 때도 통합된 시스템 덕분에 기존 도구에서 발생하던 협업 마찰을 줄이고 수요에 대응할 수 있었다. - 약 40명의 디자인 시스템 팀이 1만 명 규모의 회사 전반에 디자인 품질을 확산시키는 역할을 담당했다. ## 변수로 디자인 일관성과 효율성 강화 - 제품 생태계가 커지면서 색상, 간격, 타이포그래피, 모서리 반경이 화면과 컴포넌트마다 달라지는 문제가 발생했다. - Figma 변수는 색상이나 수치처럼 재사용 가능한 값을 정의하고 여러 디자인 속성에 적용할 수 있게 했다. - 특히 숫자 변수를 활용해 spacing과 corner radius를 일관된 값으로 관리했다. - 변수의 값을 중앙에서 정의하면 디자이너가 픽셀 수준의 정확성을 유지하면서도 반복적인 수정 작업을 줄일 수 있다. - 초기에는 변수 설정과 학습에 비용이 들었지만, 결과적으로 디자인 완성도가 높아지고 리뷰 과정에서 되돌아오는 수정 사항이 감소했다. - 변수 기반 시스템은 장기적으로 디자이너의 반복 작업과 리비전을 줄여 효율을 높인다. ## 테마 기능으로 인수 사업 통합 - Carvana가 자동차 경매 기업 ADESA를 인수한 뒤에도 변수는 새로운 브랜드 테마를 빠르게 도입하는 데 활용됐다. - 컴포넌트의 구조와 기능은 유지하면서 변수 값만 바꾸어 ADESA 전용 색상과 스타일을 적용할 수 있었다. - 기존 방식이라면 새 스타일에 맞춰 컴포넌트 라이브러리를 다시 구축하는 데 최소 한 달이 걸렸을 작업을, 변수 기반 테마로 1주일 이내에 처리했다. - ADESA용 디자인 시안을 평소보다 약 3배 빠르게 제작할 수 있었다. - 브랜드 변경을 개별 컴포넌트의 재작업이 아니라 테마 전환으로 처리함으로써 여러 화면 너비와 제품 영역에 일관되게 적용할 수 있었다. ## 디자인과 개발 간 연결 강화 - Figma 기반 디자인 시스템은 디자이너와 개발자가 동일한 컴포넌트와 변수 기준을 참조하도록 돕는다. - 중앙화된 라이브러리와 변수는 디자인 변경 사항을 일관되게 관리하고 핸드오프 과정의 마찰을 줄이는 기반이 된다. - 글에서는 변수와 Figma REST API를 활용한 개발 연계 및 변수 마이그레이션 사례도 소개한다. Carvana 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

component-libraryfigmadesign-systemsdesign-tokens+4

figma2024년 4월 9일

컴포넌트 스프린트의 (새 탭에서 열림)

워싱턴 포스트는 디자인과 개발이 분리된 채 진행되던 컴포넌트 제작의 문제를 해결하기 위해 약 10일간의 ‘컴포넌트 스프린트’를 도입했다. 디자이너와 개발자가 처음부터 한 쌍으로 참여하고, 관련 팀의 의견을 단계별로 반영해 기술적 제약과 실제 사용 맥락을 함께 고려한다. 이 방식은 디자인 시스템 컴포넌트를 더 빠르고 일관되게 제작하면서도, 팀 전체의 공동 소유 의식을 높이는 것이 핵심이다. ## 디자인 주도·개발 주도 방식의 한계 - 초기 WPDS(The Washington Post Design System)는 컴포넌트 성격에 따라 제작 주체가 달랐다. - `select`, `radio`, `checkbox`처럼 시각적 설계가 중심인 요소는 디자인 주도로 제작했다. - `carousel`, `input search`처럼 기술적 복잡성이 큰 요소는 개발 주도로 제작했다. - 한쪽 팀이 주도하면 다른 팀의 전문 지식이 늦게 반영되어 일정 지연과 타협이 발생했다. - 개발자는 디자인 단계에서 기술적 한계를 뒤늦게 지적하거나, 구현보다 세부적인 시각 요소에 집중하도록 압박받을 수 있었다. - 디자이너는 자신의 사용 사례가 충분히 고려되지 않거나, 이미 존재하는 컴포넌트를 알지 못해 별도 솔루션을 만들기도 했다. - 그 결과 디자인 시스템에는 잦은 오버라이드와 즉석에서 판단해야 하는 기능·변형 요청이 누적됐다. ## 컴포넌트 스프린트의 운영 원칙 - 모든 컴포넌트마다 스프린트를 시작하며, 일반적으로 약 10일 동안 진행한다. - 디자이너와 개발자가 처음부터 끝까지 프로세스를 이끄는 담당자로 짝을 이룬다. - 핵심 담당자 외에도 관련 팀의 의견을 수집해 폐쇄적인 순차 작업을 개방적이고 협력적인 과정으로 바꾼다. - 프로세스는 대체로 다음 단계로 구성된다. - 킥오프 - 콘셉트 정의 - 디자인과 구현 - 개선 및 다듬기 - 문서화 - 모든 참여자가 초기에 요구사항과 기술적 제약을 공유하므로, 후반부의 재작업과 오해를 줄일 수 있다. ## 킥오프: 영향도와 노력으로 우선순위 정하기 - 매주 30분 회의에서 Jira의 후보 컴포넌트 티켓을 검토한다. - 각 아이디어를 예상 영향도와 필요한 노력의 관점에서 비교해 우선순위를 정한다. - 아이디어 보드는 단순한 목록이 아니라 다음 정보를 축적하는 협업 공간으로 활용한다. - 이해관계자의 비동기 피드백 - Slack에서 논의된 관련 정보 - 비슷한 아이디어의 묶음 - 사업 목표와의 연관성 - 시각화된 영향도-노력 매트릭스에서는 원의 크기로 투표 수나 인기도를 표현하고, 색상으로 연관된 사업 목표를 구분한다. - 우선순위가 결정되면 디자인 시스템 팀에서 디자이너와 개발자를 각각 배정한다. - 두 담당자를 초기 단계부터 정함으로써 프로세스 전반의 지속적인 커뮤니케이션을 보장한다. ## 콘셉트 정의: 범위와 목표 합의하기 - 스프린트 시작 시 전체 팀과 함께 약 2시간의 회의를 진행한다. - FigJam에서 다음 내용을 공동으로 정리한다. - 컴포넌트의 목표 - 필수 요구사항 - 작업 범위 - 기술적 요구사항 - 검토가 필요한 가정과 쟁점 - 회의 마지막 15분은 결과 검토에 사용한다. - 기술 담당자와 비기술 담당자가 같은 공간에서 의견을 남기므로, 서로 다른 관점의 기대치를 조기에 맞출 수 있다. - 이 단계에서는 구체적인 디자인 세부사항보다 문제의 범위, 사용 목적, 구현 조건을 먼저 합의한다. - FigJam을 활용하면 특정 직군이 논의를 독점하지 않고, 참여자 모두가 요구사항을 명확히 할 수 있다. ## 실용적인 적용 방향 컴포넌트 제작을 한 팀에 일괄 위임하기보다, 디자이너와 개발자를 초기부터 공동 책임자로 배치하는 것이 효과적이다. 또한 영향도·노력 기반 우선순위 보드와 공개적인 요구사항 문서를 운영하면 불필요한 컴포넌트 중복과 후반 재작업을 줄일 수 있다.

component-libraryfigmadesign-systemsfigjam+3

figma2024년 4월 7일

디자인 시스템 구축 방법 (새 탭에서 열림)

디자인 시스템은 제품 전반의 일관성을 높이고, 재사용 가능한 컴포넌트와 공통 언어를 통해 디자인·개발 업무를 효율화하는 기반이다. 성공적인 시스템은 정해진 정답을 따르기보다 조직의 목표와 문제에 맞춰 설계하고, 제품과 팀의 변화에 따라 지속적으로 발전해야 한다. 이를 위해 목표 설정, 기존 자산 조사, 협업자 확보, 적절한 구축 방식 선택이 선행되어야 한다. ## 디자인 시스템의 목표와 범위 정의 - 컴포넌트를 만들기 전에 디자인 시스템을 도입하려는 이유를 명확히 해야 한다. - 다음 질문에 답하면서 목표를 구체화한다. - 왜 디자인 시스템이 필요한가? - 어떤 문제를 해결할 것인가? - 문제가 해결되었는지 어떻게 측정할 것인가? - 플랫폼 간 UI 불일치, 반복적인 수동 수정, 디자인·개발팀 간 협업 문제 등이 주요 도입 계기가 될 수 있다. - 디자인 시스템은 소규모 팀의 단순한 컴포넌트 모음부터 대기업의 종합적인 표준 체계까지 다양한 규모로 구성할 수 있다. - 중요한 것은 조직의 현재 상황에 맞게 시작하고, 필요에 따라 확장 가능한 구조를 만드는 것이다. ## 기존 디자인과 코드 자산 조사 - 여러 플랫폼과 디바이스에서 제품 UI를 수집한다. - 일반 화면뿐 아니라 다음과 같은 변형도 함께 확인한다. - 호버·포커스·비활성·오류 등 인터랙션 상태 - 반응형 레이아웃 - 플랫폼별 또는 제품별 대체 버전 - 스크린샷을 모으면 반복되는 시각적 패턴과 일관된 요소를 파악하기 쉽다. - 디자인 파일만 조사해서는 안 되며, 코드베이스도 함께 점검해야 한다. - 개발자가 이미 구현한 다음 자산을 확인하면 기존 엔지니어링 작업을 재활용할 수 있다. - 반복적으로 사용되는 UI 요소 - 공통 CSS 변수 - 공유 컴포넌트 - 표준화된 구현 패턴 - 디자인과 코드 양쪽을 조사해야 서로 다른 시스템이 병렬로 만들어지는 문제를 줄일 수 있다. ## 패턴 분류와 문제점 평가 - 수집한 화면과 컴포넌트를 유형별로 분류해 현재 제품의 디자인 언어를 파악한다. - 같은 문제를 여러 방식으로 해결하고 있는지 확인한다. - 다음과 같은 문제는 디자인 시스템으로 개선할 후보가 된다. - 비슷한 UI가 제품마다 다르게 보이는 경우 - 중복 컴포넌트나 불필요한 변형이 많은 경우 - 디자인팀과 개발팀이 동일한 문제를 각자 다르게 해결하는 경우 - 사용자 경험이 화면이나 플랫폼에 따라 단절되는 경우 - 이 과정은 무엇을 새로 만들지뿐 아니라 무엇을 통합·정리·폐기할지도 결정하는 단계다. ## 조직 내 챔피언 확보 - 디자인 시스템은 한 직군만의 프로젝트가 아니라 디자인, 개발, 제품 관리가 함께 참여하는 팀 작업이다. - 일관된 제품 경험에 관심이 있는 사람을 조직 내 협력자로 확보해야 한다. - 개발자는 실제 코드 구현과 유지보수를 담당하므로 초기부터 참여시키는 것이 중요하다. - 개발자는 컴포넌트의 기술적 실현 가능성, API 설계, 유지보수 비용에 대한 현실적인 의견을 제공할 수 있다. - 성공적인 디자인 시스템이 반드시 대규모 전담 조직에서 시작되는 것은 아니며, 한 명의 담당자에서 출발할 수도 있다. ## 구축 방식 선택 - 디자인 시스템을 구축하는 방법은 크게 두 가지다. - 조직의 요구에 맞춰 처음부터 직접 구축하기 - 기존 프레임워크를 도입한 뒤 제품 상황에 맞게 조정하기 - 선택할 때는 현재 보유한 디자인·코드 자산, 팀 규모, 기술 역량, 유지보수 가능성을 함께 고려해야 한다. - 기존 시스템을 그대로 복사하기보다 조직의 목표와 제품 특성에 맞는 수준으로 조정하는 것이 중요하다. ## 이후의 구축 단계 - 글은 전체 과정을 다음 세 단계로 제시한다. - 기반 마련: 목표 정의, 기존 자산 조사, 문제 평가, 협력자 확보 - 디자인 기반 정의: 색상, 타이포그래피, 간격 등 공통 시각 규칙 수립 - Figma에서 구축: 디자인 자산과 재사용 가능한 컴포넌트를 체계적으로 구성 - 구축 후에도 시스템은 고정된 결과물이 아니라 제품과 팀의 변화에 맞춰 계속 관리하고 발전시켜야 한다. 실무에서는 모든 것을 한 번에 만들기보다 가장 반복적으로 사용되고 영향이 큰 패턴부터 시작하는 것이 좋다. 디자인과 코드를 함께 조사하고 개발자를 초기 단계부터 참여시키면 실제 제품에 적용되고 유지되는 디자인 시스템을 만들 가능성이 높아진다.

component-libraryfigmadesign-systemsui-design+3

figma2024년 1월 25일

디자인 시스템 도입을 가로 (새 탭에서 열림)

디자인 시스템은 대기업만을 위한 복잡한 도구가 아니라, 팀 규모와 관계없이 효율성·일관성·협업을 높이는 실용적인 체계다. 최신 유행이나 Material Design을 그대로 따르기보다 조직의 목표, 브랜드, 사용자에 맞춰 설계해야 한다. 또한 처음부터 모든 것을 직접 만들 필요 없이 공개된 리소스를 활용해 현실적인 범위에서 시작할 수 있다. ## 디자인 시스템은 대기업만을 위한 것이 아니다 - 규모가 작은 팀도 디자인 시스템을 통해 반복 작업을 줄이고 결과물의 일관성을 높일 수 있다. - 디자인 시스템의 형태는 조직마다 다를 수 있지만, 핵심 목적은 공통적이다. - 업무 효율 향상 - 제품 경험의 일관성 확보 - 디자이너와 개발자 간 협업 촉진 - 사례로 소개된 Mixpanel은 디자인 시스템을 개편해 비용을 절감하고, 일관성을 개선하며, 전사적으로 데이터 분석 접근성을 높였다. ## 최신 디자인 기법을 모두 적용해야 한다는 오해 - 디자인 트렌드는 계속 변하며, 모든 조직에 통하는 유일한 정답은 없다. - 다른 팀의 사례와 업계 동향은 참고할 수 있지만 그대로 복제할 필요는 없다. - “완벽하고 최신인 시스템”을 만드는 데 집중하면 실제 해결하려던 문제와 목표를 놓칠 수 있다. - 디자인 시스템은 유행을 보여주는 전시물이 아니라 다음을 지원해야 한다. - 조직의 구체적인 목표 - 실제 사용자 요구 - 팀의 업무 방식 - 지속 가능한 운영 ## Material Design이 모든 조직에 맞는 것은 아니다 - Google의 Material Design은 널리 알려진 표준이지만, 모든 제품에 그대로 적용할 수 있는 만능 해법은 아니다. - 조직의 디자인 시스템은 다음 요소를 반영해야 한다. - 브랜드의 고유한 정체성 - 제품 사용자의 needs - 조직의 비즈니스 목표 - 현재 조직이 처한 상황과 우선순위 - 업계 표준을 참고하되, 조직에 가장 적합한 방식과 균형을 찾아야 한다. - 글에서는 Uber Base, Google Material 3, Spotify Backstage, Pipedrive, Microsoft Teams, Salesforce Lightning 등의 디자인 시스템과 UI 키트를 비교 사례로 제시한다. ## 디자인 시스템을 처음부터 직접 만들어야 한다는 오해 - 글은 디자인 시스템을 반드시 처음부터 자체 제작해야 한다는 생각에 의문을 제기한다. - 공개된 오픈소스 디자인 시스템과 UI 리소스를 활용하면 초기 구축 비용과 시간을 줄일 수 있다. - 이미 검증된 리소스를 기반으로 시작한 뒤, 조직의 브랜드와 제품 요구에 맞게 수정하는 방식이 현실적이다. - 제공된 본문은 이 신화에 대한 설명 중간에서 끝나므로, 이후 네 번째부터 여섯 번째 신화의 전체 내용은 확인할 수 없다. 작게 시작하되 팀의 반복 문제와 실제 사용자 요구를 우선 해결하는 것이 좋다. 기존 오픈소스와 업계 사례는 출발점으로 활용하고, 최종 디자인 시스템은 조직의 브랜드·제품·업무 방식에 맞게 점진적으로 발전시키는 것이 바람직하다.

component-librarydesign-systemsopen-sourcedesign-thinking+3

figma2023년 9월 21일

코드 생성이 (진짜) (새 탭에서 열림)

코드 생성(codegen)은 디자인-개발 과정을 완전히 자동화하기보다, 개발자가 더 빠르고 정확하게 작업하도록 돕는 확장 도구로 활용할 때 가장 효과적이다. 특히 AI 코드 생성 결과는 정확성과 유용성에 한계가 있으므로, 개발자를 대체하기보다 적절한 컴포넌트·속성·코드 패턴을 제안해 초기 작업을 앞당기는 방향이 현실적이다. Figma는 이를 “0에서 1”이 아닌 “0에서 0.5”로 빠르게 이동시키는 도구로 설명한다. ### 코드 생성의 범위와 현실 - 코드 생성은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - 범위가 넓으며 다음과 같은 형태를 포함한다. - IDE의 자동 완성 기능 - 반복적인 코드 패턴을 위한 스니펫과 템플릿 - Bubble 같은 비주얼 프로그래밍·노코드 도구 - GitHub Copilot, Replit Ghostwriter 같은 AI 기반 코드 생성 도구 - Stack Overflow 2023 조사에서 개발자의 82%가 AI 도구를 사용해 코드를 작성한다고 답했다. - 반면 AI 도구의 정확성을 매우 신뢰한다고 답한 비율은 3%에 불과했다. - 따라서 코드가 생성된다는 사실보다, 실제 프로젝트의 프레임워크와 코드베이스에 맞고 개발자가 유용하게 사용할 수 있는지가 더 중요하다. ### 디자인을 코드로 그대로 변환하기 어려운 이유 - Figma는 Dev Mode를 처음 개발할 때 디자인을 코드로 자동 변환하는 것을 목표로 했다. - 초기 결과는 가능성을 보였지만, 다양한 개발자의 요구와 프레임워크를 모두 만족하는 코드를 만들기는 어려웠다. - 자동 생성된 코드가 문법적으로 맞더라도 팀의 컴포넌트 구조, 네이밍 규칙, 상태 관리 방식과 맞지 않으면 실무에서는 유용하지 않을 수 있다. - 이에 따라 Figma는 디자인을 코드로 직역하는 방식보다, 디자인과 개발 사이의 해석과 협업을 보조하는 방식으로 방향을 전환했다. ### 개발자를 대체하는 도구가 아닌 지능 증폭 도구 - 코드 생성은 개발자를 대신하는 자동화 시스템보다 개발자의 능력을 확장하는 도구로 보는 편이 적절하다. - 글은 이를 **지능 증폭(Intelligence Amplification, IA)**으로 설명한다. - 복잡한 문제를 이해하고 - 필요한 정보를 빠르게 찾으며 - 해결책을 도출하는 인간의 능력을 강화하는 접근이다. - AI가 기술이 주도하는 미래를 상징한다면, IA는 사람이 주도권을 유지한 채 기술의 도움을 받는 방식이다. - 개발자는 최종 구조와 구현 방식을 결정하고, codegen은 탐색·반복·초기 작성에 드는 시간을 줄인다. ### “0에서 0.5”까지 빠르게 이동하기 - 디자인 시스템과 컴포넌트 라이브러리를 사용하는 제품에서는 codegen이 핸드오프 과정의 추측을 줄일 수 있다. - 디자인 요소에 대응하는 컴포넌트 이름이나 속성 값을 제안해 개발자가 어떤 도구를 사용할지 빠르게 판단하도록 돕는다. - 디자인 시스템을 공구 상자에 비유하면, codegen은 상황에 맞는 공구와 사용법을 추천하는 역할을 한다. - 완성된 코드를 제공하기보다는 빈 화면에서 작업을 시작할 수 있는 출발점을 만들어 준다. - 즉, “0에서 1”까지 완성하는 자동화보다 “0에서 0.5”까지 빠르게 진입하게 하는 보조 기능에 더 큰 가치가 있다. ### 팀과 코드베이스에 맞춘 구체적인 활용 - codegen의 효과는 일반적인 자동화 도구보다 특정 팀·회사·워크플로에 맞게 적용할 때 커진다. - 디자인 시스템과 컴포넌트 라이브러리가 이미 Figma에 있다면 별도의 완전 자동화 디자인-코드 변환 앱이 반드시 필요하지 않다. - 대신 다음 기능을 활용하는 편이 실용적이다. - 디자인 토큰과 변수 참조 - 컴포넌트 및 속성 문서 확인 - 팀 전용 codegen 플러그인 구축 - 프로젝트 규칙에 맞춘 사용자 정의 코드 스니펫 생성 - 이러한 정보와 힌트는 개발자가 디자인을 빠르게 해석하고 직접 코드를 작성하도록 돕는다. ### 실용적인 결론 codegen은 생성된 코드를 그대로 채택하는 자동화 수단이 아니라, 팀의 디자인 시스템과 개발 규칙을 이해한 상태에서 적절한 컴포넌트와 구현 방향을 제안하는 보조 수단으로 사용하는 것이 좋다. 특히 토큰, 문서, 컴포넌트 메타데이터, 사용자 정의 스니펫을 코드베이스와 연결하면 개발자의 판단을 유지하면서 반복 작업과 초기 탐색 시간을 크게 줄일 수 있다.

component-libraryfigmadesign-systemsdesign-to-code+4

figma2023년 7월 18일

프롭스의 공유 언어 | (새 탭에서 열림)

컴포넌트와 props는 디자인과 코드 양쪽에서 사용되지만, 환경에 따라 의미와 목적이 달라질 수 있다. 같은 이름의 컴포넌트라도 디자이너는 시각적 일관성과 표현 방식을, 개발자는 렌더링·상호작용·데이터 처리를 중심으로 생각한다. 따라서 디자인과 개발의 협업을 개선하려면 용어를 단순히 통일하기보다 각 환경의 맥락과 차이를 함께 이해해야 한다. ## 디자인과 개발에서 달라지는 언어 - 컴포넌트는 재사용 가능한 요소이며, props는 컴포넌트가 표현될 수 있는 방식과 규칙을 정의한다. - 컴포넌트의 인스턴스는 원본 컴포넌트를 실제로 사용한 결과이며, props 값을 변경해 다양한 상태와 모양을 표현한다. - 디자인과 개발 모두 `boolean` 같은 개념을 사용하지만, 디자이너는 이를 주로 시각적 차이를 표현하는 수단으로 접한다. - Figma의 대표적인 prop 유형은 다음과 같다. - Variant: 컴포넌트의 변형 - Boolean: 표시 여부나 켜짐/꺼짐 상태 - Instance swap: 내부 인스턴스 교체 - Text: 텍스트 값 변경 - 개발자는 이러한 시각적 props 외에도 이벤트 핸들러, 데이터, 동작 제어 등 비시각적 속성을 함께 다룬다. - 같은 단어를 사용하더라도 서로 다른 의미를 떠올릴 수 있으므로, 용어의 일치만으로 공통 이해가 형성되지는 않는다. ## 버튼 사례에서 드러나는 차이 - Figma의 버튼은 시각적 일관성과 디자인 파일 안에서의 구현 방식이 중요하다. - 코드의 버튼은 시각적 표현뿐 아니라 렌더링 방식, 사용자 상호작용, 접근성, 이벤트 처리까지 포함한다. - 따라서 Figma의 `Button`과 코드베이스의 `Button`은 이름과 기본 개념은 같아도 실제 책임과 props 구성이 다를 수 있다. - 글의 사례에서는 Figma에 `Button`과 `IconButton` 두 컴포넌트가 있었지만, 코드베이스에는 버튼 관련 컴포넌트가 다섯 개 존재했다. - Figma의 두 컴포넌트는 코드베이스처럼 공통 primitive를 상속하지 않았다. - Figma에서는 코드와 같은 방식의 컴포넌트 상속이 존재하지 않는다. - 디자인 관점에서 모델링하기에 두 컴포넌트를 분리하는 편이 더 적절했다. - 크기와 색상 같은 props가 중복되었지만, 동기화가 어렵지 않고 일관성을 해치지 않아 허용할 수 있었다. - 반면 코드베이스의 버튼 컴포넌트는 더 많은 props와 기능을 제공했으며, Figma 컴포넌트에는 그중 일부만 반영되어 있었다. - 이는 디자이너와 개발자가 컴포넌트를 최적화하는 기준이 다르다는 점을 보여준다. - 디자이너: 시각적 표현, 디자인 시스템 내 일관성, 파일에서의 사용성 - 개발자: 구현 편의성, 재사용 구조, 상호작용, 데이터와 접근성 ## 공통 어휘를 만들 때 필요한 관점 - 디자인과 코드의 컴포넌트를 무조건 동일한 구조로 맞추기보다, 각각의 환경에서 컴포넌트가 수행하는 역할을 먼저 구분해야 한다. - 같은 이름을 사용하는 컴포넌트라도 실제 목적과 지원하는 props가 다르면 그 차이를 명시적으로 설명해야 한다. - 협업에서는 “이 prop이 존재하는가”보다 다음 질문이 중요하다. - 어떤 시각적 또는 기능적 문제를 해결하는가? - 디자인에서의 변화가 코드에서는 어떤 prop이나 상태에 대응하는가? - 코드의 비시각적 기능을 디자인 시스템에서는 어떻게 표현하거나 문서화할 것인가? - 서로 다른 용어를 사용하는 사실 자체는 문제가 아니다. 문제는 동일한 의미라고 가정한 채 대화하는 것이다. 디자인 시스템을 운영할 때는 Figma와 코드 컴포넌트의 이름을 가능한 한 연결하되, props 목록과 의미가 완전히 같다고 가정하지 않는 것이 좋다. 각 prop의 목적과 대응 관계를 문서화하고, 시각적 속성과 동작·데이터 속성을 구분하면 디자이너와 개발자 사이의 오해를 줄일 수 있다.

component-libraryfigmadesign-systemsreact+3

figma2020년 9월 2일

온라인 쇼핑객을 위해 디자인 (새 탭에서 열림)

Design Within Reach(DWR)는 온라인에서도 오프라인 쇼룸과 유사한 개인화된 구매 경험을 제공하기 위해 웹사이트를 전면 개편했다. DWR과 BASIC®은 Figma를 활용해 하나의 팀처럼 실시간 협업하고, 110시간의 고객 조사와 200명 이상의 사용자 테스트를 통해 제품 탐색과 상담 경험을 개선했다. 그 결과 라이브 채팅 이용자의 구매 가능성이 9배 높아졌으며, 여러 Herman Miller 브랜드로 확장 가능한 디자인 시스템도 구축했다. ### 투명한 에이전시 협업과 실시간 공동 작업 - DWR과 BASIC®은 업무를 분리하기보다 공동 창작을 중심으로 하나의 통합된 팀처럼 운영했다. - 서로 다른 회사와 시간대에서 일하는 디자이너들이 같은 Figma 파일에 동시에 접근해 작업했다. - 파일을 복사하거나 최신 버전을 전달하고 링크를 갱신하는 과정이 사라져 협업 효율이 높아졌다. - 시간대 차이를 활용해 한 팀이 작업을 마치면 다른 팀이 이어받는 방식으로 사실상 하루 14시간의 연속 작업이 가능했다. - CEO와 경영진도 Figma 프로토타입 링크를 통해 진행 상황을 쉽게 확인하고 의사결정에 참여할 수 있었다. ### 오프라인 쇼룸 경험의 온라인 구현 - 웹사이트 개편의 목표는 고객이 온라인에서 가구를 구매할 때 생기는 주요 질문에 답하고, 실제 쇼룸 방문에 가까운 경험을 제공하는 것이었다. - 총 110시간의 고객 조사와 200명 이상의 참가자를 대상으로 한 심층 사용자 테스트를 진행했다. - Figma 프로토타입을 실제 웹사이트처럼 제작해 사용성 테스트, 빠른 반복 수정, 즉각적인 인사이트 수집을 수행했다. - 2020년 7월 새 사이트를 출시했으며, 다양한 화면에 대응하는 반응형 디자인과 영업 담당자와 연결되는 영상·라이브 채팅 기능을 도입했다. - 라이브 채팅을 이용한 방문자는 그렇지 않은 방문자보다 온라인 구매 가능성이 9배 높았다. - 일반적으로 대규모 웹사이트 출시 직후에는 구매가 일시적으로 감소할 수 있지만, DWR은 출시 직후부터 구매 증가를 경험했다. ### 여러 브랜드로 확장되는 디자인 시스템 - DWR 웹사이트 개편을 계기로 Herman Miller 전체 브랜드를 위한 첫 디자인 시스템을 만들었다. - 공통 컴포넌트와 공유된 시각 언어를 기반으로 장기적으로 확장 가능한 구조를 설계했다. - 개발자는 반복 가능한 컴포넌트를 더 빠르게 구현할 수 있게 됐다. - 콘텐츠 작성자는 미리 제작된 컴포넌트를 드래그하고 이미지와 텍스트만 수정해 페이지를 직접 구성할 수 있게 됐다. - Figma의 클라우드 기반 에셋 라이브러리를 통해 내부 팀과 전 세계 외부 파트너가 디자인 자산과 시스템을 쉽게 공유할 수 있다. - DWR의 컴포넌트 라이브러리는 향후 Herman Miller의 다른 전자상거래 사이트에도 적용될 기반이 됐다. ### 실용적인 시사점 온라인 쇼핑 경험을 개선하려면 단순히 시각적으로 아름다운 사이트를 만드는 것보다 고객 조사, 실제 프로토타입 테스트, 실시간 협업을 하나의 흐름으로 연결해야 한다. 또한 반복 가능한 컴포넌트와 공통 디자인 언어를 디자인 시스템으로 정리하면 개발 속도와 콘텐츠 운영 효율을 높이면서 여러 브랜드와 채널로 일관되게 확장할 수 있다.

component-libraryfigmadesign-systemsux-design+3

figma2020년 9월 1일

멀티 브랜드 디자인 시스템 구축 (새 탭에서 열림)

멀티 브랜드 디자인 시스템은 일관성과 효율성을 제공하되, 엄격한 규칙보다 유연성을 중심으로 설계해야 한다. 기본 컴포넌트와 브랜드별 토큰, 코드 연계를 통해 다양한 요구를 수용하고 빠르게 확장할 수 있다. 또한 디자인 시스템은 완성된 산출물이 아니라 실제 사용 데이터를 관찰하며 계속 발전시키는 살아 있는 시스템이어야 한다. ## 유연성을 우선하는 설계 - 디자인 시스템을 지나치게 규정적으로 운영하면 디자이너의 창의성을 제한하고, 결국 시스템 밖에서 작업하게 만들 수 있다. - Harry’s는 복잡도와 유연성이 서로 다른 여러 계층으로 시스템을 구성했다. - 기본 컴포넌트: 단순하고 표준화된 구성 - 스타터 키트: 더 복잡하고 유연한 구성 - 대부분의 프로젝트는 단순한 계층으로 해결하되, 특수한 요구에는 커스텀 구성을 허용한다. - 기본값은 단순하게 유지하면서도 예외를 수용하면 효율성과 창의성을 동시에 확보할 수 있다. ## 토큰을 활용한 멀티 브랜드 확장 - Condé Nast처럼 여러 브랜드를 운영하는 조직에서는 브랜드마다 다른 시각적 특성을 수용해야 한다. - 모듈화된 컴포넌트와 디자인 토큰을 사용하면 동일한 구조를 유지하면서 브랜드별 값을 적용할 수 있다. - 하나의 토큰이 브랜드마다 다른 값을 가질 수 있다. - 예: `prominent text`라는 토큰에 Vogue, The New Yorker, Bon Appétit별 폰트를 각각 지정 - 이런 방식은 컴포넌트를 브랜드별로 별도 제작하지 않고도 시스템을 확장하게 해준다. ## 계속 진화하는 디자인 시스템 - 시스템을 구축한 뒤에도 실제 사용 과정에서 무엇이 잘 작동하고 실패하는지 관찰해야 한다. - Shopify는 디자인 시스템을 “휘어지지만 부러지지 않는” 기반으로 만든다는 방향을 취한다. - 디자인 시스템을 박물관의 전시물처럼 보존하려 하면 변화하는 요구사항을 반영할 수 없다. - 디자이너뿐 아니라 최종 사용자도 관찰해야 한다. - Shopify의 경우 상점 운영자인 머천트가 시스템의 실제 사용자인 만큼, 사용 중 어디서 문제가 발생하는지 확인한다. - 컴포넌트 사용량, 라이브러리 활용 추세 등의 데이터를 분석하면 개선 우선순위를 정할 수 있다. - 시스템이 어떻게 실패하는지 확인하고 이를 바탕으로 다시 설계하는 과정이 중요하다. ## 디자인과 코드의 연결 - 디자인 컴포넌트를 코드로 연결하면 디자인과 개발 간의 전달 비용을 줄이고 구현 속도를 높일 수 있다. - Condé Nast는 JavaScript 기반 사이트에서 JSON으로 토큰을 정의한다. - 커스텀 플러그인을 통해 토큰 값을 JSON으로 가져오거나 내보내 디자인과 코드의 변경 사항을 동기화한다. - 토큰 기반 구조는 새로운 시장이나 브랜드를 빠르게 구축하고 디자이너와 엔지니어 간의 핸드오프를 원활하게 한다. - 멀티 브랜드 환경이 아니더라도 색상이나 타이포그래피에 목적과 값을 연결하는 것부터 시작할 수 있다. - 예: 특정 색상을 직접 `#000000`으로 부르기보다 `text-primary`처럼 용도 중심으로 명명 - 목적과 값을 분리하면 시스템의 복잡도와 불필요한 세분화를 파악하기 쉬워진다. ## 조직에 맞는 시스템 구축 - 모든 조직에 동일하게 적용되는 디자인 시스템은 없다. - 팀 규모, 조직 구조, 브랜드 수, 개발 환경, 업무 우선순위에 맞춰 범위와 복잡도를 결정해야 한다. - 처음부터 거대한 시스템을 만들기보다 현재 반복적으로 사용되는 패턴과 컴포넌트부터 정리하는 것이 현실적이다. - 시스템의 규칙보다 실제 팀이 쉽게 사용하고 변경할 수 있는 프로세스를 만드는 것이 더 중요하다. 실무에서는 기본 컴포넌트와 목적 기반 토큰부터 시작하고, 브랜드별 차이는 토큰 값으로 관리하는 방식을 추천한다. 이후 사용 데이터와 사용자 피드백을 바탕으로 시스템을 지속적으로 수정하되, 예외와 실험을 허용해 시스템 밖으로 이탈할 필요가 없도록 해야 한다.

component-librarydesign-systemsjavascriptdesign-tokens+2

figma2020년 1월 27일

Figma on Figma: Figma (새 탭에서 열림)

Figma는 제품 디자인뿐 아니라 마케팅 웹사이트에도 디자인 시스템이 필요하다고 판단하고, 기존 페이지의 시각 요소와 제작 방식을 체계화했다. 반복되는 요소를 통합하고 재사용 가능한 컴포넌트와 조합형 섹션을 구축한 결과, 일관성을 유지하면서도 코드 작성 없이 아이디어에서 출시까지 하루, 실제 사례에서는 48시간 이내에 웹페이지를 만들 수 있게 되었다. ## 기존 웹사이트의 불일치와 유지보수 문제 - 페이지마다 디자이너와 개발자가 각자 새로운 해결책을 만들고 있었다. - 비슷하지만 조금씩 다른 컴포넌트가 반복되어 사용자 경험과 브랜드 인상이 일관되지 않았다. - 페이지를 수정하거나 업데이트하기 어렵고, 새로운 페이지를 만들 때마다 작업 방식이 달라졌다. - 제품 디자인 분야에서 활용되던 디자인 시스템의 장점을 마케팅·웹 디자인에도 적용할 필요가 있었다. ## 전체 요소를 조사하고 패턴을 통합 - 먼저 폰트, 글자 크기, 색상, 컬럼 너비, 레이아웃 등 기존 사이트의 시각 요소를 Figma 파일에 모았다. - 조사 과정에서 다음을 구분했다. - 여러 페이지에서 반복되는 패턴 - 한 번만 사용되어 스타일 가이드에 포함하기 어려운 예외 요소 - 서로 유사하지만 세부 스타일이 다른 요소 - 큰 UI 요소는 더 작은 단위로 분해해 조합 가능한 구조로 만들었다. - 서로 다른 제목 스타일 12개를 H1~H3, 본문, 기술 문서용 텍스트 등으로 단순화했다. - 블로그와 긴 형식의 콘텐츠에는 풀 쿼트, 블록 쿼트 같은 전용 텍스트 스타일도 추가했다. ## 원자적 요소와 유연한 컴포넌트 - 작은 요소를 조합해 다양한 페이지 구조를 만들 수 있도록 디자인 시스템을 구성했다. - 핵심 목표는 특정 페이지에만 맞는 고정된 디자인이 아니라, 여러 콘텐츠와 레이아웃에 대응하는 유연한 빌딩 블록을 만드는 것이었다. - 정리된 시각 언어를 공유 라이브러리로 제공해 Figma 브랜드에 익숙하지 않은 사람도 일관된 결과물을 만들 수 있게 했다. - 타이포그래피, 간격, 패딩, 행간, 색상, 그리드 등을 하나의 기준으로 통일했다. ## FLEGOs: 조합 가능한 대형 섹션 - Figma는 컴포넌트를 조합해 자주 함께 사용되는 요소와 완성된 섹션도 미리 만들었다. - 이러한 대형 조합 단위를 “Figma + LEGO”라는 의미의 **FLEGOs**라고 불렀다. - 디자이너는 개별 텍스트나 버튼뿐 아니라 페이지의 주요 섹션을 FLEGOs로 빠르게 구성할 수 있었다. - 작은 요소부터 완성된 섹션까지 단계적으로 재사용할 수 있어 페이지 제작의 속도와 일관성을 함께 확보했다. ## Contentful 기반의 제작 workflow - 약 한 달 동안 소규모 팀이 스타일 가이드와 컴포넌트 라이브러리를 구축했다. - 시스템은 Figma 파일에만 머무르지 않고 CMS인 Contentful에도 반영했다. - 디자인팀은 Figma에서 FLEGO를 사용해 와이어프레임을 만들고, 같은 파일에서 콘텐츠를 협업한 뒤 CMS의 컴포넌트로 실제 페이지를 구성했다. - 대부분의 핵심 마케팅 사이트가 이 프레임워크를 기반으로 제작되었다. - 새로운 페이지를 만들 때 별도의 코드 작성 없이 기존 컴포넌트를 활용할 수 있었다. ## 출시 속도 향상 - 디자인 시스템 도입 후 콘셉트에서 출시까지 하루 안에 진행할 수 있게 되었다. - ‘What’s New’ 페이지는 제품 마케터와 웹 제작자가 FLEGOs로 빠르게 와이어프레임을 만들고 콘텐츠를 작성한 사례다. - 아이디어에서 실제 웹페이지 공개까지 48시간 이내에 완료했다. - 재사용 가능한 시스템 덕분에 속도를 높이면서도 브랜드의 시각적 일관성을 유지할 수 있었다. 디자인 시스템은 제품 UI에만 필요한 도구가 아니라, 마케팅 페이지와 콘텐츠 제작에도 효과적이다. 기존 결과물을 먼저 조사하고, 반복 패턴을 통합한 뒤, 작은 요소부터 조합형 섹션까지 단계적으로 라이브러리화하면 개발 부담을 줄이면서 빠르고 일관된 웹사이트 운영이 가능하다.

component-libraryfigmadesign-systemsatomic-design+2