figma2025년 3월 12일

eBay가 Figma로 브랜드 (새 탭에서 열림)

eBay는 브랜드와 제품 팀이 따로 관리하던 디자인 시스템을 Figma 중심의 통합 문서 플랫폼인 ‘Evo Playbook’으로 재구축했다. 300쪽이 넘는 Playbook은 접근성, 디자인, 코드 정보를 한곳에 모으고, Figma 변경 사항을 자동 검증·게시해 문서를 살아 있는 업무 흐름으로 만들었다. 핵심은 중앙화된 문서, 라이브러리 메타데이터, Component Status API, Figma 플러그인 자동화다. ## 기존 문서화 방식의 한계 - 디자인 시스템 정보가 여러 Figma 파일에 흩어져 있었다. - 디자이너, 개발자, 접근성 담당자가 각각 별도의 문서를 관리했다. - 디자이너가 Figma의 정적 파일을 수정한 뒤, 별도 티켓을 통해 문서 사이트에 반영해야 했다. - 컴포넌트 상태를 수동 테이블로 관리해 정보가 빠르게 오래되었다. - 외부 에이전시가 만든 기존 Playbook은 실제 eBay의 디자인·개발 업무와 분리되어 유지보수가 어려웠다. ## Evo와 eBay Playbook의 통합 방향 - eBay는 기존 시스템을 부분 수정하지 않고 문서화 파이프라인을 처음부터 다시 설계했다. - 브랜드 가이드, 제품 디자인 시스템, 기술 문서를 별도 사이트가 아닌 하나의 공간에 통합했다. - 2024년 11월 공개된 Evo는 약 30년 된 eBay의 시각 언어를 현대화한 디자인 시스템이다. - 300쪽 이상의 Playbook을 통해 내부 팀과 외부 에이전시가 동일한 기준을 참고할 수 있도록 했다. - 문서를 단순한 참고 자료가 아니라 영감과 사용 경험을 제공하는 제품처럼 설계했다. ## Component Status API로 구현 상태 통합 - eBay는 모든 디자인 시스템 라이브러리의 컴포넌트 상태를 추적하는 내부 API를 만들었다. - Figma 컴포넌트 설명에 컴포넌트 이름과 버전 메타데이터를 기록한다. - API는 다음 라이브러리의 구현 여부와 버전을 통합적으로 확인한다. - Figma 컴포넌트 라이브러리 - 네이티브 라이브러리 - Skin, Marko, React 등 웹 컴포넌트 라이브러리 - Playbook의 컴포넌트 페이지에는 플랫폼별 리소스 링크, 최신 버전, 상태가 표시된다. - 개발자는 자신이 사용하는 프레임워크에 컴포넌트가 존재하는지, Figma 버전 및 문서와 일치하는지 바로 확인할 수 있다. ## Figma 기반 자동화와 게시 - 모든 컴포넌트, 가이드라인, 접근성 안내는 Figma에서 작성하고 수정한다. - eBay는 문서 내보내기 기능을 수행하는 자체 Figma 플러그인을 개발했다. - 플러그인은 변경 내용을 다음과 같이 처리한다. - 문서 구조와 콘텐츠를 추출 - 린팅을 통해 형식과 규칙을 검사 - 유효성을 검증 - CMS에 자동 게시 - 과거에는 문서 업데이트에 며칠이 걸렸지만, 자동화 이후 Figma 수정 사항이 2분 이내에 Playbook에 반영된다. - 개발자가 CMS를 직접 수정할 필요가 없어 문서 업데이트의 진입 장벽이 낮아졌다. ## 브랜드와 제품 조직 사이의 사일로 해소 - OneExperience 팀은 브랜드, 디자인 시스템, 디자인 기술, 콘텐츠를 아우르는 교차 기능 조직으로 구성됐다. - 디자인과 개발 문서가 서로 다른 원천에서 관리되지 않고 동일한 workflow에서 생성된다. - 디자인 시스템 문서가 실제 라이브러리와 자동으로 연결되므로 문서와 구현 사이의 불일치가 줄어든다. - 빠른 업데이트 덕분에 팀들이 문서화를 별도의 행정 업무가 아니라 일상적인 설계 과정의 일부로 받아들이게 되었다. ## 실용적인 적용 시사점 - 디자인 시스템 문서를 정적 웹 페이지로 관리하기보다 실제 설계 도구와 연결된 살아 있는 문서로 운영하는 것이 효과적이다. - 컴포넌트 이름과 버전을 메타데이터로 표준화하면 여러 플랫폼의 구현 상태를 자동으로 추적할 수 있다. - Figma 플러그인, 린터, API를 결합하면 문서 품질 검증과 게시를 자동화할 수 있다. - 브랜드 가이드와 제품 디자인 시스템을 분리하기보다 하나의 소스 오브 트루스로 통합하면 조직 간 협업과 일관성이 향상된다.

component-librariesfigmadesign-systemsaccessibility+3

figma2024년 8월 19일

크런치롤이 개발자 (새 탭에서 열림)

글로벌 애니메이션 스트리밍 서비스인 크런치롤(Crunchyroll)은 15개의 플랫폼과 12개의 언어를 지원하는 복잡한 환경 속에서 디자인 일관성을 유지하기 위해 '유니버설 디자인 시스템(Universal Design System)'과 피그마의 '개발 모드(Dev Mode)'를 적극 도입했습니다. 과거 인수합병 과정에서 쌓인 파편화된 워크플로우와 기술 부채를 정리함으로써, 디자이너와 엔지니어 간의 협업 효율을 극대화하고 사용자에게 통일된 브랜드 경험을 제공하게 되었습니다. 이번 전환은 단순히 도구를 바꾼 것을 넘어, 복잡한 다중 플랫폼 환경에서 제품의 출시 속도와 품질을 동시에 잡는 전략적 선택이었습니다. **다중 플랫폼 환경에서의 복잡성과 레거시 문제** * 크런치롤은 웹, 모바일뿐만 아니라 게임 콘솔, 스마트 TV 등 9개의 거실용 기기를 포함해 총 15개의 플랫폼을 지원하며, 1,500만 명 이상의 글로벌 팬들에게 서비스를 제공합니다. * 과거에는 각 플랫폼별로 개별적인 디자인 시스템(iOS, Android, tvOS 등)을 운영했으며, 이는 협업 과정에서 심각한 불일치와 혼선을 초래했습니다. * 기존 워크플로우는 Jira 트리거와 Zeplin에 의존했으나, 아트보드 로딩에만 4~5분이 소요되거나 시차 문제로 인해 최신 디자인 사양을 실시간으로 공유하기 어려운 구조였습니다. **디자인 시스템을 통한 효율성 극대화: "식재료 준비(Meal Prepping)"** * 디자인 시스템을 '식재료 미리 준비하기'에 비유하여, 매번 새로운 기능을 만들 때마다 처음부터 설계하는 것이 아니라 준비된 컴포넌트를 재사용하여 리소스를 절약합니다. * 엔지니어링의 DRY(Don't Repeat Yourself) 원칙을 디자인에도 적용하여 중복 컴포넌트를 제거하고 일관된 타이포그래피, 그리드, 간격 시스템을 구축했습니다. * 이러한 표준화는 사용자의 인지 부하를 줄여 구독 전환율을 높이는 동시에, 제품 관리자가 아이디어를 빠르게 검증할 수 있는 속도 경쟁력을 제공합니다. **개발 모드(Dev Mode)를 활용한 협업 프로세스의 혁신** * 개발자가 피그마 링크를 통해 '개발 준비 완료(Ready for development)' 페이지에 접속하면, 수많은 아이데이션 과정은 생략하고 오직 구현에 필요한 최신 스펙과 코드 값만 바로 확인할 수 있습니다. * 기존에 5분씩 걸리던 데이터 파싱 속도가 획기적으로 개선되어, 엔지니어가 특정 결제 플로우나 컴포넌트의 상세 정보를 찾는 데 드는 시간을 대폭 단축했습니다. * 코드 커넥트(Code Connect) 베타 버전을 통합하여 디자인 시스템의 컴포넌트와 실제 코드를 더 밀접하게 연결함으로써 디자인과 코드 간의 괴리를 좁히고 있습니다. **디자인 시스템 운영의 철학과 변화 관리** * 디자인 시스템은 팀을 지원하기 위한 도구일 뿐, 프로세스의 포로가 되어서는 안 된다는 철학 아래 지속적인 교육과 온보딩 워크숍을 진행했습니다. * 과거의 복잡한 QA 단계나 불필요한 태그 시스템을 과감히 삭제하고, 개발자가 필요한 정보에 직접 접근할 수 있는 자율적인 환경을 조성했습니다. * 전문화된 디자인 원칙(계층 구조, 그리드 등)을 준수하는 '좋아 보이는 디자인'과 엣지 케이스까지 고려한 '잘 작동하는 디자인'을 디자인 성공의 핵심 지표로 삼고 있습니다. 디자인 시스템은 한 번 구축하고 끝나는 것이 아니라 팀의 성장에 맞춰 계속 진화해야 합니다. 크런치롤의 사례처럼 도구의 기능을 활용해 불필요한 단계를 제거하고, 개발자와 디자이너가 동일한 언어로 소통할 수 있는 환경을 만드는 것이 복잡한 글로벌 서비스를 운영하는 핵심 전략입니다.

component-librariesfigmadesign-systemsdesign-to-code+4

figma2024년 5월 21일

Code Connect의 잠재력 활용 (새 탭에서 열림)

디자인과 개발의 간극을 줄이려면 두 팀이 공유할 수 있는 언어와 단일한 작업 흐름이 필요하다. Figma의 Code Connect는 디자인 시스템의 컴포넌트 구현 정보와 문서를 Dev Mode에서 직접 제공해 개발자가 맥락을 바꾸지 않고 올바른 코드를 사용할 수 있도록 돕는다. 패널 참가자들은 작은 컴포넌트부터 시작해 점진적으로 도입하고, 디자이너와 개발자의 전문성을 서로 존중해야 한다고 강조한다. ## 디자인과 개발이 함께 쓰는 언어 만들기 - 디자이너와 개발자는 컴포넌트 이름, 속성, 구현 방식에 대해 서로 다른 용어와 기대를 가질 수 있다. - 이 차이는 다음과 같은 문제로 이어진다. - 일관되지 않은 네이밍 - 디자인과 코드의 속성 불일치 - 팀 간 요구사항과 구현 결과의 불일치 - 디자인 시스템은 공통 컴포넌트, 패턴, 용어를 정의해 두 분야를 연결하는 “제3의 언어” 역할을 한다. - 단순히 규칙을 문서화하는 것뿐 아니라, 구성원이 쉽게 찾고 실제로 적용할 수 있게 만드는 것도 중요하다. ## 단일한 기준과 개발자 워크플로 연결 - Bumble의 Raul Menezes는 디자인과 코드에서 서로 다른 기준 문서가 사용되는 것이 일관성 저하의 주요 원인이라고 설명한다. - 같은 UI 패턴을 반복해서 직접 구현하면 다음 문제가 발생한다. - 중복 코드 증가 - 커스텀 구현 확산 - 유지보수 어려움 - 디자인 시스템과 실제 제품 간의 불일치 - 디자이너는 디자인 시스템 문서를 참고하지만, 개발자는 별도의 코드 저장소나 문서를 기준으로 삼는 경우가 많다. - Code Connect는 디자인 시스템의 코드 예시와 구현 정보를 Dev Mode 안에서 제공해 개발자가 기존 코드 편집 및 개발 흐름에서 바로 참고하도록 설계됐다. ## 도입 장벽을 낮추고 작은 규모로 시작하기 - 디자인 시스템을 구축했다고 해서 자동으로 팀 전체가 사용하는 것은 아니다. 개발자가 기존 작업 방식을 크게 바꿔야 한다면 adoption이 느려질 수 있다. - 기존에는 개발자가 디자인 구현 방식을 확인하기 위해 별도의 디자인 시스템 웹사이트로 이동해야 했다. - Code Connect를 사용하면 Dev Mode에서 특정 디자인이 코드로 구현되어 있는지, 어떤 방식으로 구현하는지 확인할 수 있어 컨텍스트 전환을 줄인다. - 처음부터 모든 컴포넌트를 연결하기보다 영향도가 높고 구조가 단순한 컴포넌트부터 시작하는 것이 권장된다. - 예: 토글 같은 작은 컴포넌트 - 디자인 속성과 코드 속성을 어떻게 매핑하는지 먼저 검증 - 팀이 도구의 효과와 운영 방식을 익힌 뒤 범위 확대 - Code Connect는 완성된 최종 해법이라기보다 더 큰 디자인-코드 통합을 위한 첫 단계로 제시된다. ## 서로의 전문성 존중하기 - 디자인과 개발의 간극을 줄인다는 것은 한쪽의 방식을 다른 쪽에 강요하는 것이 아니다. - 디자이너는 사용자 경험, 시각적 일관성, 패턴 설계에 강점을 가진다. - 개발자는 컴포넌트 구조, 재사용성, 기술적 제약, 유지보수성에 전문성이 있다. - 효과적인 디자인 시스템 운영을 위해서는 두 팀이 각자의 전문성을 인정하고, 공통 언어와 도구를 통해 협업해야 한다. - Code Connect는 디자인 시스템의 의도와 실제 코드 구현을 연결해 양쪽의 지식을 공유하는 매개 역할을 한다. ## 실용적인 적용 방법 - 디자인 시스템에서 자주 사용되고 영향도가 큰 컴포넌트를 우선 선정한다. - 디자인의 컴포넌트 속성과 코드의 props·API가 어떻게 대응하는지 정의한다. - Dev Mode에서 개발자가 별도 문서 검색 없이 구현 예시를 확인할 수 있도록 연결한다. - 초기 도입 후 다음을 점검한다. - 개발자가 실제로 재사용 컴포넌트를 선택하는지 - 중복·커스텀 구현이 줄었는지 - 디자인과 코드의 명명 및 속성이 일치하는지 - 검증된 운영 방식을 바탕으로 점차 복잡한 컴포넌트와 더 넓은 제품 영역으로 확대하는 것이 바람직하다.

component-librariesfigmadesign-systemsdesign-to-code+2

figma2024년 2월 11일

디자인 시스템이란 무엇 (새 탭에서 열림)

디자인 시스템은 제품의 시각적 요소와 상호작용 방식을 일관되게 유지하도록 돕는 공통 언어이자 설계·개발을 위한 체계다. 색상, 아이콘, 버튼, 문구 같은 요소를 표준화하고 재사용함으로써 제작 시간을 줄이고 사용자 경험과 브랜드 정체성을 보호한다. 단순한 스타일 가이드가 아니라 원칙, 컴포넌트, 패턴, 기술 문서와 프로세스를 포괄하는 지속적으로 발전하는 기반이다. ## 디자인 시스템이란 무엇인가 - 제품과 서비스의 디자인·개발을 안내하는 **재사용 가능한 구성 요소와 표준의 집합**이다. - 복잡한 디지털 제품을 만들 때 팀이 공유할 수 있는 통일된 언어와 구조를 제공한다. - 요소를 매번 새로 설계하지 않아도 되므로 대규모 제품 개발에서 시간과 노력을 줄인다. - 디자인 시스템이 없으면 화면마다 스타일과 동작이 달라지는 **일관성 위기**가 발생할 수 있다. - 사용자가 인터페이스를 혼란스럽게 느낄 수 있다. - 브랜드 정체성이 약화될 수 있다. - 반복적인 디자인 작업과 구현 비용이 늘어난다. ## 디자인 시스템의 계층 구조 ### 1. 디자인 시스템 - 제품 생태계 전체를 아우르는 최상위 개념이다. - 다음과 같은 자원을 포함할 수 있다. - 기술 사양 - 디자인 토큰 - 컴포넌트 및 패턴 문서 - 모범 사례 - UX 설계 원칙 - 제품 개발 프로세스 - 고정된 규칙집이 아니라 제품과 조직의 변화에 따라 계속 발전하는 기반이다. ### 2. 컴포넌트 및 패턴 라이브러리 - 제품에서 반복적으로 사용하는 시각 요소와 상호작용 방식을 모아 둔 라이브러리다. - 컴포넌트의 예: - 버튼 - 입력 필드 - 기타 UI 요소 - 패턴의 예: - 내비게이션 흐름 - 데이터 표시 방식 - 레이아웃과 템플릿 - 반복되는 사용자 상호작용 - 코드 스니펫, 기술 사양, 사용 지침을 함께 제공해 디자인 의도를 실제 구현으로 연결한다. - 디자이너와 개발자가 동일한 기준을 참고하는 협업 지점 역할을 한다. - **컴포넌트 라이브러리**가 개별 UI 요소에 집중한다면, **패턴 라이브러리**는 더 넓은 문제 해결 방식과 사용자 흐름을 다룬다. ## 디자인 시스템과 스타일 가이드의 차이 - 스타일 가이드는 주로 다음과 같은 시각적 요소를 정의한다. - 색상 - 글꼴과 타이포그래피 - 이미지와 시각적 표현 - 디자인 시스템은 스타일 가이드보다 범위가 넓다. - 코딩 표준 - 사용성 원칙 - 상호작용 패턴 - 기술 문서 - 제품 개발 프로세스까지 포함할 수 있다. - 따라서 스타일 가이드는 디자인 시스템을 구성하는 일부로 볼 수 있다. ## 3. 기초 요소 - 제품의 전반적인 시각 언어와 목소리·말투를 정의한다. - 대표적인 구성 요소는 다음과 같다. - 색상 - 타이포그래피 - 아이콘 - 로고 - 일러스트레이션 - 접근성 가이드라인 - 브랜드 가이드라인 - 단순히 화면을 예쁘게 만드는 것을 넘어, 제품이 어떤 인상을 주고 어떤 방식으로 소통할지를 결정한다. ## 디자인 시스템과 UX - 디자인 시스템이 디자이너의 창의성을 제한하고 모든 화면을 똑같이 만든다는 것은 흔한 오해다. - 실제로는 반복적인 문제를 해결해 디자이너가 더 중요한 사용자 경험과 제품 문제에 집중하도록 돕는다. - 공통 요소와 기준을 재사용하면 일관성을 확보하면서도 제품 목적에 맞는 새로운 경험을 설계할 수 있다. - 색상, 아이콘, 버튼의 형태뿐 아니라 명확한 언어와 접근성까지 관리하므로 UX 전반에 영향을 준다. 디자인 시스템을 도입할 때는 단순히 UI 컴포넌트 목록을 만드는 데 그치지 말고, 디자인 원칙·접근성·코드·문서·협업 프로세스까지 함께 정의하는 것이 좋다. 또한 처음부터 모든 요소를 완성하려 하기보다 반복적으로 사용되는 핵심 요소부터 구축하고, 제품과 팀의 변화에 맞춰 지속적으로 관리해야 한다.

component-librariesdesign-systemsux-designaccessibility+2

figma2021년 9월 14일

Elsewhen이 고객을 위한 디지털 제품 (새 탭에서 열림)

Elsewhen은 Figma를 최종 화면을 만드는 도구가 아니라, 탐색·워크숍·프로토타이핑·협업 전 과정을 연결하는 공동 작업 공간으로 활용한다. 이를 통해 Spotify의 디자인 생산성을 체계적으로 분석하고, Inmarsat의 분산된 디자인 업무를 하나의 디자인 시스템으로 통합했다. 두 사례는 협업 환경과 공통 자산을 정비하면 반복 작업을 줄이고 창의성과 제품 출시 속도를 높일 수 있음을 보여준다. ## Figma를 중심으로 한 협업 방식 - 영국의 디지털 제품 컨설팅 회사 Elsewhen은 기업용·B2B 도구를 설계하며 고객사의 비효율적인 시스템과 업무 프로세스를 개선한다. - Figma를 디자인 결과물 제작에만 사용하지 않고 다음 전 과정에 활용한다. - 아이디어 탐색 - 워크숍과 인터뷰 - 고객과의 공동 작업 - 프로토타이핑 - 디자인 자산 공유 및 배포 - 에셋을 별도로 내보내고 업로드·배포하던 반복 단계를 줄여 팀이 문제 해결과 제품 설계에 더 집중할 수 있게 했다. ## Spotify의 디자인 생산성 개선 - Spotify는 디자인 생산성을 단순히 화면·컴포넌트 개수나 작업 시간으로 평가하는 방식에 한계가 있다고 보았다. - 창의적인 업무에서는 산출량보다 디자이너가 실제 디자인에 얼마나 집중할 수 있는지, 업무 흐름을 방해하는 요소가 무엇인지 파악하는 것이 중요했다. - Elsewhen과 Spotify는 현재의 업무 흐름을 분석하고 개선 기회를 찾기 위한 **Design Productivity Blueprint**를 공동 개발했다. - 이 자료는 공개된 Figma 파일 형태로 제공되며 다음을 포함한다. - 디자인 팀의 업무를 분석하는 워크숍 - 구성원 인터뷰 템플릿 - workflow의 문제점과 병목을 찾는 방법 - 목표는 반복적이고 부수적인 업무에 쓰는 시간을 줄이고, 디자이너가 실제 디자인과 창의적 문제 해결에 더 많은 시간을 쓰도록 하는 것이다. ## Inmarsat의 디자인 시스템 구축 - 위성 통신 기업 Inmarsat은 여러 지역에 분산된 조직과 외부 디자인 에이전시에 의존하는 구조 때문에 디자인 협업에 어려움을 겪었다. - 사내 디자인 팀이 없고 공통 디자인 자산의 단일 기준점도 없어 다음 문제가 발생했다. - 새 디자이너의 온보딩이 어려움 - 개발자와 외부 디자이너 사이에 제품 맥락이 단절됨 - 디자이너들이 컴포넌트를 반복해서 처음부터 제작함 - 제품 출시 과정이 지연됨 - Elsewhen은 Inmarsat의 기존 셀프서비스 포털 프로젝트를 기반으로 첫 번째 Figma 디자인 시스템을 만들었다. - 실제 제품에 사용되는 요소를 토대로 다음과 같은 공통 컴포넌트 체계를 구축했다. - 타이포그래피 - 버튼 - 아이콘 - 그리드 - 기타 반복적으로 사용되는 UI 요소 - Figma를 디자인 컴포넌트와 에셋의 단일 기준점으로 삼아 사내 디자이너, 개발자, 협력 에이전시가 동일한 자료에 쉽게 접근할 수 있도록 했다. - 그 결과 컴포넌트 재작업이 줄고, 새로운 제품을 더 빠르게 구축하며 기술 변화에도 대응하기 쉬워졌다. ## 두 사례에서 얻는 협업 원칙 - 생산성은 단순한 산출량이 아니라 업무 흐름의 마찰을 얼마나 줄였는지로 평가해야 한다. - 디자인 시스템은 추상적으로 한 번에 만드는 것이 아니라 실제 진행 중인 제품에서 출발하면 실용적인 기반을 마련하기 쉽다. - 디자인·개발·외부 파트너가 동일한 파일과 컴포넌트를 사용하면 정보 단절과 중복 작업을 줄일 수 있다. - 협업 도구는 결과물을 전달하는 수단을 넘어 탐색부터 검증까지 모든 참여자가 함께 작업하는 공간이 되어야 한다. 실무적으로는 팀의 반복 작업과 협업 병목을 먼저 조사한 뒤, 공통 컴포넌트와 워크숍 템플릿을 하나의 공유 공간에 축적하는 방식이 효과적이다. 이를 통해 디자인 품질뿐 아니라 팀의 작업 속도와 창의적 여유도 함께 개선할 수 있다.

component-librariesfigmadesign-systemsprototyping+2

figma2019년 11월 19일

디자인 시스템을 뒷받침 (새 탭에서 열림)

Figma는 디자인 시스템의 사용 데이터를 분석하면 팀이 실제로 어떤 라이브러리와 컴포넌트를 사용하는지 파악하고, 이를 바탕으로 시스템을 지속적으로 개선할 수 있다고 주장합니다. Design System Analytics는 라이브러리 사용 추이, 라이브러리 간 채택률, 개별 컴포넌트의 삽입·분리 현황을 제공해 디자인 시스템 운영을 정성적 피드백에서 정량적 개선으로 확장합니다. 다만 목적은 디자이너를 감시하는 것이 아니라 사용 패턴을 이해하고 더 나은 컴포넌트와 라이브러리를 만드는 데 있습니다. ## 디자인 시스템 사용 데이터를 분석하는 이유 - Figma는 클라우드 기반 브라우저 도구이므로 디자이너들이 디자인 시스템을 어떻게 사용하는지 데이터를 통해 파악할 수 있습니다. - Design System Analytics를 사용하면 다음 정보를 확인할 수 있습니다. - 라이브러리 사용량의 시간별 추이 - 여러 라이브러리 간 사용량 비교 - 개별 컴포넌트의 사용, 삽입, 분리 현황 - 분석 결과는 조직 내 누구나 확인할 수 있어 디자이너와 관리자가 필요한 리포트를 직접 살펴볼 수 있습니다. - Figma는 분석 기능을 설계할 때 디자이너의 모든 행동을 통제하거나 감시하지 않는 방향을 강조했습니다. ## 사용되지 않거나 개선이 필요한 컴포넌트 찾기 - 라이브러리와 컴포넌트별 사용량을 보면 어떤 요소가 실제 업무에 기여하는지 파악할 수 있습니다. - Microsoft의 Fluent 디자인 시스템은 다음과 같은 질문에 데이터를 활용합니다. - 거의 사용되지 않는 컴포넌트는 무엇인가? - 자주 분리(detach)되는 컴포넌트는 무엇인가? - 유지보수가 불필요하거나 개선이 필요한 컴포넌트는 무엇인가? - Google Material Design 팀은 버튼 컴포넌트가 가장 많이 사용되는 동시에 가장 많이 분리되는 현상을 발견했습니다. - 이를 통해 기존 버튼 컴포넌트가 지나치게 복잡하다는 점을 파악하고, 더 단순한 대체 컴포넌트를 추가하는 개선으로 이어졌습니다. - 즉, 높은 사용량만 보는 것이 아니라 높은 분리율도 컴포넌트 설계가 실제 요구와 맞지 않는다는 신호로 활용할 수 있습니다. ## 라이브러리 채택과 마이그레이션 추적 - 두 라이브러리의 사용량을 시간에 따라 비교해 새 라이브러리로의 전환이 제대로 진행되는지 확인할 수 있습니다. - Squarespace는 기존 공유 라이브러리를 Auto Layout 기반의 새 라이브러리로 교체하는 과정에서 이 기능을 활용하려 했습니다. - 분석 화면에서는 다음과 같은 정보를 확인할 수 있습니다. - 기간별 컴포넌트 삽입 수 - 구버전과 신버전 라이브러리의 사용량 비교 - 새 라이브러리를 적극적으로 사용하는 상위 팀 - 컴포넌트별 전체 인스턴스 수, 최근 삽입 수, 분리 수 - 이를 통해 새 라이브러리의 채택률을 측정하고, 구버전 라이브러리의 폐기(deprecation)를 관리할 수 있습니다. - 예시 화면에는 최근 60일간의 삽입 추이와 팀별 사용 비중, 개별 버튼 컴포넌트의 인스턴스·삽입·분리 통계가 표시됩니다. ## 개별 컴포넌트 사용 방식 파악 - 단순히 라이브러리 전체의 사용량만 보는 것을 넘어 개별 컴포넌트가 실제로 어떻게 활용되는지 조사할 수 있습니다. - Pluralsight는 공유 컴포넌트가 팀원들의 작업에서 어떻게 사용되는지 파악하는 데 Analytics를 활용하려 했습니다. - 조직 내 모든 디자이너와 관리자가 분석 결과와 사용 사례를 확인할 수 있으므로: - 특정 컴포넌트의 실제 활용 사례를 빠르게 찾을 수 있습니다. - 다른 팀의 사용 방식을 참고할 수 있습니다. - 디자인 시스템 팀이 개선 우선순위를 정하기 쉬워집니다. ## 디자인 초기 단계에서 영향 측정 - 기존에는 디자인 시스템 도입 효과를 개발 단계에서 측정하는 경우가 많았습니다. - Design System Analytics를 이용하면 제품 개발이 개발 단계에 도달하기 전, 디자인 과정에서 시스템이 얼마나 채택되고 있는지도 확인할 수 있습니다. - 따라서 디자인 시스템 팀은 다음을 더 일찍 파악할 수 있습니다. - 제품팀이 공통 컴포넌트를 실제로 사용하고 있는지 - 새 라이브러리가 설계 작업에 자연스럽게 도입되고 있는지 - 특정 팀이나 프로젝트가 시스템에서 이탈하고 있는지 - 이는 개발 단계의 준수 여부를 사후 점검하는 방식에서, 디자인 단계부터 채택을 높이는 방식으로 관점을 바꿉니다. ## 기능의 변화 - 원문은 2019년 발표 내용을 다루지만, 안내문에 따르면 2025년 2월 기준 Figma Library Analytics는 컴포넌트뿐 아니라 스타일과 변수 데이터도 지원합니다. - Organization 및 Enterprise 고객에게 관련 데이터가 제공되며, Enterprise 고객은 Library Analytics API를 통해 확장된 기능을 사용할 수 있습니다. - 따라서 현재 기능은 원문에 설명된 초기 버전보다 범위가 넓어졌을 수 있습니다. 실무적으로는 사용량이 낮은 컴포넌트를 무조건 제거하기보다, 삽입 수와 분리율을 함께 분석하는 것이 좋습니다. 또한 라이브러리 마이그레이션 시 팀별 채택률과 구버전 사용량을 지속적으로 추적하면 디자인 시스템 개선과 폐기 계획을 데이터에 근거해 운영할 수 있습니다.

component-librariesfigmadesign-systemsauto-layout+1

figma2019년 4월 2일

#FigmaTip 모 (새 탭에서 열림)

Figma 파일과 디자인 시스템을 효율적으로 정리하려면 레이어, 파일, 컴포넌트, 페이지를 체계적으로 관리해야 한다. 이 글은 봄맞이 정리를 위한 Figma 활용법으로 일괄 이름 변경, 사용자 지정 썸네일, 파일 정렬, 라이브러리 정리, 프레임과 페이지 활용을 소개한다. 이러한 기능을 활용하면 파일을 빠르게 탐색하고 팀 협업 효율도 높일 수 있다. ### 레이어 일괄 이름 변경 - 장기간 진행한 프로젝트에서는 레이어가 복제·수정되며 이름이 뒤섞이기 쉽다. - 여러 레이어를 선택한 뒤 마우스 오른쪽 버튼의 **Rename**을 선택하거나 `Command + R`을 누르면 일괄 변경할 수 있다. - 다음과 같은 방식이 지원된다. - 모든 레이어를 동일한 이름으로 변경 - 숫자 접미사 추가 - 접두사 추가 - 기존 이름의 일부만 변경 - 정규 표현식을 이용한 고급 이름 변경 ### 사용자 지정 썸네일로 파일 구분 - 파일에 사용자 지정 썸네일을 설정하면 파일 브라우저에서 내용을 빠르게 식별할 수 있다. - 설정 방법: - 새 페이지를 만들고 페이지 목록의 가장 위로 이동 - `640x320` 크기의 프레임 하나를 생성 - 프레임 안에 제목, 설명, 이미지 등을 배치 - 프레임 배경색과 캔버스 배경색을 동일하게 설정 - 썸네일에 프로젝트 상태나 버전 정보를 표시하면 파일 탐색과 진행 상황 공유에 유용하다. ### 파일 브라우저 정렬 - 파일 브라우저의 정렬 기능을 사용하면 불필요한 파일을 쉽게 찾을 수 있다. - **File Name**으로 정렬하면 `Untitled`처럼 이름이 정리되지 않은 파일을 확인할 수 있다. - 다음 기준으로도 정렬할 수 있다. - 생성일 - 최종 수정일 ### 팀 라이브러리의 컴포넌트 정리 - 디자인 시스템을 정리할 때는 팀 라이브러리에 등록된 컴포넌트가 실제로 필요한지 검토해야 한다. - 중복되거나 더 이상 사용하지 않는 컴포넌트는 컴포넌트 탭에서 마우스 오른쪽 버튼을 클릭한 뒤 **Remove from Library**를 선택해 제거할 수 있다. - 컴포넌트 이름 앞에 `.` 또는 `_`를 붙이는 방식으로 라이브러리에서 제외할 수도 있다. - 이를 통해 팀원이 불필요한 컴포넌트를 찾느라 시간을 낭비하는 것을 줄일 수 있다. ### 프레임과 페이지로 라이브러리 구성 - 컴포넌트 라이브러리와 디자인 시스템은 프레임과 페이지를 사용해 논리적인 컬렉션으로 나누는 것이 좋다. - 이름에 슬래시(`/`)를 여러 번 사용해 계층 구조를 표현하는 대신, 프레임과 페이지로 분류하면 컴포넌트 이름을 더 단순하게 유지할 수 있다. - 체계적인 분류는 팀원이 필요한 컴포넌트를 쉽게 탐색하고 라이브러리를 이해하는 데 도움이 된다. ### 실용적인 정리 순서 - 먼저 파일 브라우저를 이름과 수정일 기준으로 정렬해 불필요한 파일을 선별한다. - 각 파일의 레이어를 일괄적으로 이름 변경해 검색과 탐색이 쉽게 만든다. - 중요한 파일에는 `640x320` 사용자 지정 썸네일을 추가한다. - 마지막으로 팀 라이브러리에서 중복·미사용 컴포넌트를 제거하고, 남은 컴포넌트를 프레임과 페이지로 분류하는 것이 좋다.

component-librariesfigmadesign-systemsregular-expressions+1

figma2018년 12월 18일

디자인 시스템 현황 (새 탭에서 열림)

디자인 시스템은 아직 초기 단계지만, 반응형 디자인처럼 조직의 표준적인 업무 방식으로 자리 잡고 있다. 499명 설문 결과, 전담 팀이나 공개 문서를 갖춘 조직은 많지 않았지만 대부분은 더 성숙한 시스템을 원했다. 디자인 시스템은 단순한 컴포넌트 모음이 아니라 원칙·가이드·문서·운영 프로세스를 포함하는 지속적인 설계 방식이라는 것이 글의 핵심 결론이다. ## 1. 디자인 시스템은 아직 초기 단계 - 응답자의 약 3분의 2가 디자인 시스템의 초기 단계인 1~2단계에 해당했다. - 1단계: 시스템이 문서화되지 않음 - 2단계: 전담 팀이 없음 - 반면 86%는 전담 인력이 유지·관리하고 외부에도 공개된 3~4단계의 시스템을 원했다. - 브래드 프로스트의 아토믹 디자인과 2014년 구글 머티리얼 디자인 이후 관련 방법론이 확산됐지만, 많은 기업에서는 여전히 정착 과정에 있다. - 디자인 시스템은 일시적인 유행이 아니라 “조직이 일하는 방식”으로 자리 잡을 가능성이 높다고 평가된다. ## 2. 전담 팀이 없어도 시작할 수 있다 - 응답자의 절반은 디자인 시스템을 관리하는 전담 팀이 있는 회사에 근무했다. - 그러나 전담 팀이 반드시 필요하다고 생각한 사람은 약 3분의 1에 불과했다. - 특히 1인 디자이너나 소규모 팀도 시스템의 일부를 먼저 구축할 수 있다. - 전체 시스템을 한 번에 만들기보다 다음과 같이 작은 단위로 시작하는 접근이 권장된다. - 줄 간격(line height) 정의 - 색상과 타이포그래피 표준화 - 반복적으로 사용하는 버튼·입력창 등 컴포넌트 정리 - 중요한 것은 완벽한 시스템을 계획하는 것보다 작게 시작해 실제 제품에 적용하고 개선하는 것이다. ## 3. 디자인 시스템은 제품 이후에 만들어지는 경우가 많다 - 이상적으로는 제품 개발과 디자인 시스템 구축을 동시에 진행할 수 있지만, 실제로 그렇게 한 응답자는 41%였다. - 52%는 이미 존재하는 제품을 바탕으로 디자인 시스템을 만들었다. - 7%는 신규 제품과 기존 제품 모두를 지원하는 방식으로 구축했거나, 여러 회사에서 서로 다른 경험을 가진 경우였다. - 기존 제품에서 출발하면 실제 사용 사례와 문제를 기반으로 컴포넌트를 설계할 수 있다. - 처음부터 추상적인 컴포넌트를 무작정 만드는 것보다, 레거시 화면에서 반복되는 패턴을 찾아 체계화하는 방식이 현실적일 수 있다. ## 4. 컴포넌트 라이브러리와 스타일 가이드가 대표적인 산출물이다 - 디자인 시스템에 포함된 요소로 가장 많이 언급된 것은 다음과 같다. - 컴포넌트 라이브러리: 90% - 스타일 가이드: 83% - 디자인 원칙: 57% - 콘텐츠 가이드라인: 47% - 일부 응답자는 다음과 같은 코드 기반 요소도 디자인 시스템에 포함한다고 답했다. - React 컴포넌트 - 믹스인 라이브러리 - 디자인 토큰 저장소 - iOS·Android 개발 리소스 - 코드 관련 응답이 별도 선택지 없이 자유 응답으로 제시됐다는 점은 디자인 시스템의 범위가 시각 디자인을 넘어 개발 구현까지 확장되고 있음을 보여준다. - 당시 설문은 이러한 다양성을 충분히 측정하지 못했으며, 향후에는 더 폭넓은 항목이 필요하다고 지적한다. ## 5. 산출물만으로는 디자인 시스템이 될 수 없다 - 가장 큰 오해는 디자인 시스템을 정적인 패턴 라이브러리나 컴포넌트 모음으로만 보는 것이다. - 디자인 시스템은 다음을 포함하는 지속적인 프로세스에 가깝다. - 디자인 원칙 - 사용 지침 - 의사결정 기준 - 조직의 디자인 철학 - 산출물의 유지·개선 방식 - 컴포넌트 라이브러리와 스타일 가이드는 시스템의 결과물이자 살아 있는 산출물일 뿐, 시스템 전체와 동일하지 않다. - 문서화가 중요한 이유는 구성원들이 단순히 컴포넌트를 복사하는 데 그치지 않고, 언제·왜·어떻게 사용해야 하는지 이해해야 하기 때문이다. - 아무리 훌륭한 컴포넌트라도 올바른 문서와 사용 맥락이 없으면 실제 조직에서 제대로 활용되기 어렵다. 작은 반복 문제부터 실제 제품에 적용해 디자인 시스템을 시작하고, 컴포넌트뿐 아니라 원칙과 사용 지침까지 함께 문서화하는 것이 현실적인 접근이다. 전담 팀이 없더라도 점진적으로 운영 체계를 만들며 확장할 수 있다.

component-librariesdesign-systemsatomic-designmaterial-design+2