figma·2024년 9월 15일·3분 읽기큐레이션 요약

Figma on Figma: 최신

Figma는 디자이너 중심 도구에서 개발자·PM·제품팀 전체가 사용하는 생태계로 확장한 현실을 반영해 브랜드의 시각 언어를 재정비했다. 정적인 커서와 굵은 검은 윤곽선 중심의 기존 표현 대신, 공동 창작과 다양한 역할을 상징하는 프리미티브·색상·타이포그래피·모션을 도입했다. 새 브랜드는 누구나 아이디어를 현실로 만들 수 있는 협업 공간으로서의 Figma를 표현한다. ### 디자이너 도구에서 제품 개발 생태계로 - 지난 10년 동안 Figma는 순수한 디자인 도구에서 개발자, 제품 관리자, 전체 제품팀을 지원하는 플랫폼으로 성장했다. - 기존 브랜드는 벡터 그래픽의 문법에 가까웠다. - 정적인 마우스 커서 - 굵은 검은 외곽선 - 디자인 작업 자체에 초점을 둔 시각 표현 - 새로운 정체성은 아이디어 구상부터 개발, 협업, 완성까지 여러 사람이 참여하는 제품 제작 과정을 담는 데 초점을 맞췄다. ### 새 시각 언어를 구성하는 네 가지 기반 - **다목적 프리미티브** - 공동 창작에 참여하는 다양한 사람과 역할을 상징한다. - 특정 직군이나 작업 단계에 종속되지 않는 기본 형태로 활용된다. - **동적인 구성** - 만들고, 조정하고, 협업하는 다양한 작업 방식을 표현한다. - 정적인 결과물보다 제작 과정의 움직임과 상호작용을 강조한다. - **확장된 색상 팔레트** - 더 생생하고 폭넓은 색을 사용한다. - 색상 변수를 활용해 다양한 매체와 상황에 쉽게 적용할 수 있도록 설계했다. - **통합된 모션 원칙** - 창작 과정에서 발생하는 행동과 흐름을 애니메이션으로 표현한다. - 브랜드의 움직임이 단순 장식이 아니라 작업 과정과 연결되도록 했다. ### Figma 전용 서체 체계 - Figma는 Grilli Type과 협업해 독자적인 그로테스크 서체인 **Figma Sans**를 제작했다. - 브랜드에는 다음 네 가지 서체가 포함된다. - **Figma Sans**: 일반적인 브랜드 커뮤니케이션과 본문 - **Figma Sans Condensed**: 더 압축된 인상과 공간 효율이 필요한 표현 - **Figma Mono**: 개발, 코드, 정밀한 제작 작업을 연상시키는 표현 - **Figma Hand**: 브레인스토밍과 팀 협업처럼 인간적인 분위기를 전달 - 서로 다른 서체를 조합해 디자인, 엔지니어링, 협업 등 다양한 역할과 작업 방식을 표현한다. ### 샌드박스에서 시작한 탐색 - Figma Brand Studio는 사람들이 Figma를 사용하는 전 과정을 살펴보며 탐색을 시작했다. - 브레인스토밍 - 초기 아이디어 구상 - 요소 검사 - 최종 결과물의 세부 조정 - 팀은 여러 활동이 하나의 공유 공간에서 동시에 이루어지는 모습에 주목했다. - 이 개념은 사람들이 같은 공간에서 각자 놀고 만들며 상호작용하는 **parallel play**와 연결됐다. - Figma 캔버스를 사람들이 함께 만들고 실험하는 장소로 보고, 놀이터에서 시각적 영감을 얻었다. - Isamu Noguchi의 놀이터와 조경 작품 - Mitsuru Senda의 다채로운 패널형 놀이터 - 정교한 타일 작업과 인프라 구조 - 초기에는 놀이터의 형태를 직접적으로 차용했지만, 최종적으로는 이를 단순한 모방이 아니라 공동 창작과 실험을 상징하는 추상적 시각 언어로 발전시켰다. ### 실용적인 시사점 브랜드 리뉴얼은 로고나 색상만 바꾸는 작업이 아니라, 사용자의 역할과 제품이 지원하는 행동 범위를 다시 정의하는 과정이다. 특히 제품이 여러 직군의 협업 도구로 성장했다면, 시각 체계도 결과물뿐 아니라 아이디어 구상·소통·개발·수정 같은 전체 제작 흐름을 표현하도록 확장하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템typography+2

figma·2024년 8월 20일·3분 읽기큐레이션 요약

개발 모드와 함께한

Figma Dev Mode를 1년간 도입한 Decathlon의 경험에 따르면, 이 도구는 디자인과 개발 사이의 협업을 크게 개선할 수 있다. 특히 Code Connect를 활용하면 Figma 컴포넌트와 실제 코드 간의 속성, 명명 규칙, 상태를 직접 연결할 수 있어 디자인 시스템 운영이 정교해진다. 다만 기존 업무 방식을 한 번에 바꾸기보다 작은 성공 사례부터 시작하고, 명확한 문서화와 완료 기준을 마련하는 것이 중요하다. ## 디자인과 코드의 연결: Code Connect - Dev Mode의 가장 큰 효과는 Figma 컴포넌트를 실제 컴포넌트 코드와 연결하는 **Code Connect**에서 나타났다. - 디자인과 코드에서 컴포넌트 구조가 다르더라도 다음 문제를 조정하는 데 도움이 된다. - 속성 및 프로퍼티 정렬 - 컴포넌트 이름 규칙 통일 - 상태 관리 방식 일치 - 디자인 토큰을 Figma에서 명확히 표현하면 개발자가 시각적 의사결정을 코드 수준에서 이해하기 쉬워진다. - 색상 값과 토큰 이름을 연결하면 디자인 토큰 변경 사항이 대응하는 코드 변경으로 즉시 이어진다. ## 작게 시작하고 확장하기 - 개발자에게 새로운 도구는 기존 업무 흐름을 방해할 수 있으므로, Dev Mode를 전면 도입하기보다 작은 범위에서 시작했다. - 초기에는 Figma Variables를 활용한 디자인 토큰 관리처럼 빠르게 효과를 확인할 수 있는 영역에 집중했다. - **변수 별칭(variable aliasing)**을 사용하면 원시 토큰과 의미론적 토큰 사이에 계층을 만들 수 있다. - 테마 구현이 쉬워진다. - 팀원이 토큰 체계를 이해하고 적용하기 쉬워진다. - 변수 스코핑을 설정하면 특정 변수가 적용될 수 있는 속성을 제한할 수 있다. - 배경색을 텍스트 색상에 사용하는 실수 방지 - 간격 값을 테두리 반경에 사용하는 잘못된 적용 방지 - 변수의 코드 표기법을 플랫폼별 개발자 명명 규칙에 맞게 사용자 지정할 수 있다. ## 고급 검사 기능으로 레이아웃 확인 - Dev Mode는 복잡한 UI 레이아웃과 Flexbox 기반 구조를 검사하고 구현 가능한 코드로 확인하는 데 유용하다. - 개발자는 다음 플랫폼의 구현 속성을 직접 살펴볼 수 있다. - 웹 CSS - iOS의 SwiftUI와 UIKit - Android의 XML과 Compose - 디자이너와 디자인 시스템 담당자는 컴포넌트가 요구사항에 맞게 구현될 수 있는지 구체적으로 검증할 수 있다. - Figma VS Code 확장을 이용하면 CSS, Compose, SwiftUI 코드 탐색과 자동완성을 IDE 안에서 처리할 수 있다. - 결과적으로 디자인 파일을 별도로 해석해 코드를 작성하는 부담이 줄어든다. ## 완료 기준과 문서화 통일 - 디자인 시스템 문서는 지속적으로 최신 상태를 유지하기 어렵고, 디자인 의도나 세부 요구사항이 개발 과정에서 누락되기 쉽다. - Dev Mode의 문서화 및 주석 기능을 사용하면 디자인 파일 안에 필요한 정보를 직접 남길 수 있다. - 주석에는 다음 내용을 포함할 수 있다. - 자유로운 설명 문장 - 정렬 및 크기 같은 명시적 값 - 간격과 치수를 보여주는 측정 정보 - 디자이너는 개발자에게 특정 주석을 직접 연결해 의도와 구현 조건을 명확히 전달할 수 있다. - 팀에서는 각 컴포넌트에 다음 자료를 함께 연결하는 문서화 체계를 구축했다. - GitHub 소스 코드 - README - 관련 플레이그라운드 - 이를 통해 “디자인 완료”와 “개발 완료”의 기준을 팀 전체가 같은 방식으로 이해할 수 있다. ## 적용 시 권장 방식 - Dev Mode를 도입할 때는 기존 개발 프로세스를 즉시 대체하기보다 디자인 토큰이나 변수처럼 효과가 명확한 영역부터 시작하는 것이 좋다. - 토큰 계층, 변수 스코핑, 코드 명명 규칙을 먼저 정리하면 이후 Code Connect와 컴포넌트 문서화의 효과가 커진다. - 검사 기능만 사용하는 데 그치지 말고, 주석·소스 코드·README·플레이그라운드를 연결해 디자인 시스템의 단일한 참고 지점을 만들어야 한다.

원문 읽기(새 탭에서 열림)

디자인 토큰디자인 시스템swiftuiflexbox+4

figma·2024년 7월 29일·3분 읽기큐레이션 요약

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처럼 디자인 변경 사항과 구현 정보를 같은 작업 흐름에서 제공하면 핸드오프 비용을 줄이고 개발 생산성을 높일 수 있다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템dev-mode+2

figma·2024년 4월 17일·3분 읽기큐레이션 요약

The Long and Short of

Figma의 뉴스레터 「Find your framework」는 디자인 시스템 구축과 확산에 도움이 되는 Framework 행사 발표와 관련 콘텐츠를 소개한다. 핵심 메시지는 디자인 시스템이 단순한 UI 산출물이 아니라, 조직 전체가 사용해야 가치를 발휘하는 제품이라는 점이다. 이를 위해 기능 개발뿐 아니라 내부 마케팅, 교육, 데이터 기반 adoption 전략이 필요하다. ## Framework 행사에서 발표한 기능 - Figma의 가상 디자인 시스템 행사인 **Framework**에서 제품 개발자와 디자인 시스템 담당자를 위한 기능을 공개했다. - 주요 발표 내용: - **Code Connect**: 디자인 시스템의 컴포넌트와 실제 코드 구현을 연결해 디자이너와 개발자 간 협업을 지원한다. - **Typography variables**: 글꼴, 크기, 행간 등 타이포그래피 속성을 변수로 관리할 수 있다. - **Gradient variables**: 그라디언트 관련 값을 변수화해 일관된 스타일 관리와 변경을 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황을 분석해 디자인 시스템 adoption을 높이는 데 활용할 수 있다. - 행사에서 진행된 라운드테이블과 전문가 Q&A를 통해 디자인 시스템 운영 사례와 실무 관점도 공유했다. ## 디자인 시스템을 제품처럼 운영하기 - 디자인 시스템을 조직의 필수 도구로 만들려면 단순히 좋은 컴포넌트를 만드는 것만으로는 부족하다. - 제품처럼 다음 요소를 관리해야 한다. - 사용자의 요구와 문제 파악 - 명확한 가치 제안 - 지속적인 개선과 업데이트 - 사용 현황과 피드백 수집 - 사용자에게 변화와 이점을 알리는 커뮤니케이션 - 디자인 시스템의 성공은 완성도보다 **얼마나 많은 팀이 실제 업무에서 사용하는가**에 달려 있다. ## 내부 마케팅과 사용 확산 - 디자인 시스템은 일관성, 효율성, 확장성을 약속하지만, 실제 효과는 조직 전체의 사용이 전제되어야 나타난다. - 담당자는 “사용하라”고 지시하기보다 각 팀이 얻는 구체적인 이점을 설득해야 한다. - 디자인·개발 작업 시간 단축 - 중복 작업 감소 - 제품 간 시각적 일관성 향상 - 변경 사항을 여러 화면과 플랫폼에 빠르게 반영 - 내부 구성원을 대상으로 명확한 adoption 전략을 세우고, 교육·문서화·사례 공유를 통해 지속적인 참여를 유도해야 한다. ## 디자인 시스템 입문 - 아직 디자인 시스템을 시작하지 않은 팀을 위해 기본 개념과 구축 방법을 소개하는 입문 시리즈를 제공한다. - 디자인 시스템은 재사용 가능한 컴포넌트, 스타일, 규칙, 가이드라인을 모아 제품 제작 방식을 표준화하는 체계다. - 이를 활용하면: - 반복적인 디자인 결정을 줄일 수 있다. - 팀 간 협업 방식이 통일된다. - 제품이 성장해도 일관된 경험을 유지하기 쉽다. - 디자인과 개발 사이의 구현 차이를 줄일 수 있다. ## 성장과 확장을 지원한 Carvana 사례 - 온라인 중고차 거래 기업 **Carvana**는 급격한 고객 수요 증가와 사업 확장에 대응하기 위해 디자인 시스템을 활용했다. - 디자인 시스템과 변수를 사용해 제품 전반의 디자인 세부 사항을 일관되게 유지했다. - 특히 변수는 색상이나 기타 디자인 속성을 중앙에서 관리하고 변경할 수 있게 해, 여러 화면과 제품 영역에 일관된 수정 사항을 적용하는 데 도움을 줬다. - 이는 디자인 시스템이 시각적 통일성뿐 아니라 빠른 성장과 운영 효율성을 뒷받침하는 기반이 될 수 있음을 보여준다. 디자인 시스템을 도입할 때는 컴포넌트 제작에만 집중하기보다, 실제 사용자를 위한 제품으로 정의하는 것이 좋다. 명확한 사용 가치와 교육·홍보 전략을 마련하고, 사용 데이터를 분석하며 지속적으로 개선해야 조직 전체에서 정착시킬 수 있다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템API+2

figma·2024년 4월 15일·3분 읽기큐레이션 요약

Framework 2024

Figma는 디자인 시스템 구축보다 더 어려운 과제인 조직 전체의 도입과 활용을 지원하기 위해 Framework 2024에서 세 가지 기능을 공개했다. Code Connect는 디자인과 실제 코드 사이의 간극을 줄이고, 타이포그래피·그라디언트 변수는 디자인 토큰의 범위를 확장하며, Library Analytics API는 디자인 시스템 사용 현황을 측정하도록 돕는다. 결론적으로 Figma는 디자인 시스템을 만드는 도구를 넘어, 개발자 adoption과 조직 내 확산까지 지원하는 방향으로 발전하고 있다. ### 디자인 시스템의 핵심 과제: 조직 전체의 도입 - 디자인 시스템은 일관성, 효율성, 확장성을 제공하지만 실제 효과는 팀 전체가 이를 사용할 때 발생한다. - 시스템이 강력하고 정교해질수록 복잡성도 커지며, 디자이너와 개발자의 적극적인 참여를 이끌어내는 일이 어려워진다. - Figma는 변수, 테마와 상태 관리, 고급 프로토타이핑, Dev Mode 등을 통해 디자인과 코드의 연결을 강화해 왔다. - 이번 발표의 중심 목표는 디자인 시스템을 “구축”하는 데서 나아가 조직 전반에서 “채택”되도록 만드는 것이다. ### Code Connect: 디자인과 코드의 연결 - Code Connect는 Dev Mode에서 디자인 시스템 컴포넌트에 대응하는 실제 코드 스니펫을 제공한다. - 개발자는 별도의 문서나 저장소를 검색하지 않고 Figma에서 필요한 코드를 확인하고 복사할 수 있다. - 이를 통해: - 구현 시간을 줄일 수 있다. - 디자인과 코드의 불일치를 완화할 수 있다. - 개발자가 디자인 시스템 컴포넌트를 사용하는 진입 장벽을 낮출 수 있다. - 임의로 유사한 컴포넌트를 새로 만드는 일을 줄일 수 있다. - Organization 및 Enterprise 요금제에서 베타로 제공되며, React·iOS·Storybook을 지원한다. - 향후 더 많은 프레임워크와 플랫폼으로 지원 범위가 확대될 예정이다. - Bumble, GitHub, HP 등의 팀은 디자인 시스템과 실제 프로덕션 코드 사이를 연결하는 문제와 Code Connect의 활용 가능성을 논의했다. ### 타이포그래피 변수: 디자인 토큰의 확장 - 기존 변수 기능만으로는 디자인 시스템의 중요한 영역인 타이포그래피를 충분히 표현하기 어려웠다. - 타이포그래피 변수를 사용하면 글꼴 크기, 행간, 글꼴 스타일 등 타이포그래피 속성을 변수와 토큰 체계 안에서 관리할 수 있다. - 주요 활용 방식: - 폰트 스케일을 한 번 정의하고 전체 시스템에 일관되게 적용 - 플랫폼별 타이포그래피 설정 조정 - 반응형 또는 테마별 텍스트 스타일 관리 - WCAG 기준을 고려한 접근성 높은 스케일 구성 - 디자인 시스템의 색상과 간격뿐 아니라 텍스트 표현까지 체계적으로 관리할 수 있게 된다. ### 그라디언트 변수: 더 풍부한 시각 스타일 관리 - 그라디언트도 변수로 정의하고 재사용할 수 있도록 지원한다. - 여러 화면과 컴포넌트에서 동일한 그라디언트 스타일을 일관되게 적용할 수 있다. - 브랜드 테마나 모드별로 그라디언트를 교체하기 쉬워진다. - 변수 기반 관리로 디자인 시스템이 단순한 색상 팔레트를 넘어 더 표현력 있는 시각 언어를 다룰 수 있다. ### Library Analytics API: 디자인 시스템 사용 현황 측정 - Library Analytics API는 조직 내 디자인 시스템 라이브러리와 컴포넌트의 사용 데이터를 분석할 수 있도록 제공된다. - 디자인 시스템 관리자는 다음과 같은 질문에 답할 수 있다. - 어떤 라이브러리와 컴포넌트가 실제로 사용되는가? - 어느 팀이나 프로젝트가 디자인 시스템을 적극적으로 채택하는가? - 사용되지 않거나 개선이 필요한 컴포넌트는 무엇인가? - 정량적인 사용 데이터를 바탕으로 문서화, 교육, 컴포넌트 개선, 도입 전략을 세울 수 있다. - 디자인 시스템의 성공을 단순히 “만들었는가”가 아니라 “얼마나 사용되는가”로 평가할 수 있게 한다. ### 실용적인 결론 디자인 시스템 팀은 컴포넌트와 토큰을 만드는 데 그치지 말고, 개발자가 실제 코드로 쉽게 사용할 수 있는 경로와 사용 현황을 측정할 방법까지 함께 마련해야 한다. Code Connect로 개발자 경험을 개선하고, 타이포그래피·그라디언트 변수로 토큰 범위를 확장하며, Analytics API로 채택률을 추적하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템React+3

figma·2024년 4월 15일·3분 읽기큐레이션 요약

알래스카 항공, 변

Alaska Airlines는 Figma의 디자인 시스템과 Variables를 활용해 웹·모바일·디지털 사이니지·키오스크 전반의 경험을 일관되게 관리하고 있다. 45명 규모의 디자인 팀은 이를 통해 디자이너당 주당 평균 11시간을 절약했으며, 개발팀과의 협업과 접근성·구현 정확성도 개선했다. 특히 Auro 디자인 시스템의 재사용 컴포넌트는 긴급한 서비스 개편을 한 스프린트 안에 완료하도록 도왔다. ## 기존 도구와 단일 기준 부재의 문제 - Sketch와 InVision을 사용하던 시기의 디자인 시스템은 여러 도구가 뒤섞인 “프랑켄슈타인” 같은 상태였다. - 재사용 위젯이 직관적이지 않았고, 프로토타이핑과 실시간 협업 기능도 부족했다. - 디자인과 개발을 연결하는 단일 진실 공급원(Single Source of Truth)이 없어 다음 문제가 발생했다. - 컴포넌트와 패턴의 간격·색상 등이 몇 픽셀씩 어긋남 - 플랫폼별로 변경 사항을 수동 복사·붙여넣기 - 버튼, 체크박스, 모달, 색상, 날짜 선택기 등의 불일치 - 접근성 기준을 놓칠 가능성 증가 - 최신 파일이나 올바른 버전을 찾기 어려움 - 결과적으로 개발자는 실제 웹사이트와 맞지 않는 디자인을 전달받는 경우가 많았다. ## Auro 디자인 시스템과 Figma 도입 - Alaska Airlines는 Figma를 도입하며 디자이너와 엔지니어 모두를 위한 디자인 시스템 문서를 구축했다. - Auro는 웹 컴포넌트와 대응되는 디자인 컴포넌트를 제공해 설계와 구현 사이의 차이를 줄였다. - 컴포넌트, 색상, 패턴 등을 공통으로 참조할 수 있어 여러 인터페이스에서 일관된 사용자 경험을 유지할 수 있게 됐다. - 디자인 시스템 운영 과정에서 Auto Layout, 브랜치 및 병합 기능 등의 사용법도 문서화해 팀 내 채택률을 높였다. - 교육을 강화한 결과 디자이너의 Figma 활용도가 높아졌고, 디자이너와 엔지니어 간 충돌도 줄었다. ## 재사용 컴포넌트로 긴급 대응 속도 향상 - 심각한 폭풍으로 항공편 지연이 급증했을 때, 기존에 충분히 활용되지 않던 항공편 상태 페이지를 빠르게 개편했다. - 디자인·개발 타이거 팀은 개편에 필요한 컴포넌트의 90%를 Figma의 Auro 디자인 시스템에서 재사용했다. - Figma가 없었다면 최소 4~5개 스프린트가 필요했을 작업을 단 한 스프린트에 완료했다. - 개편 후 항공편 상태 페이지의 평균 체류 시간은 다음과 같이 증가했다. - 기존: 36초 - 변경 후: 5분 10초 - 증가율: 761% - 새 페이지에는 항공편 추적 정보와 항공기 세부 정보 등 고객에게 필요한 정보가 추가됐다. ## 디자인과 개발 간 신뢰 강화 - Figma는 처음에는 디자이너 간 협업 도구로 도입됐지만, 점차 엔지니어가 Auro의 설계 원칙을 이해하는 수단으로도 활용됐다. - 엔지니어가 실제로 사용하는 웹 컴포넌트와 유사한 디자인 컴포넌트를 참조할 수 있어 구현 가능성을 더 쉽게 판단하게 됐다. - 디자인이 구현 결과와 가까워지면서 팀 간 신뢰가 높아졌다. - 디자인 시스템 문서와 기능 교육은 디자이너가 Figma의 기능을 제대로 활용하도록 돕고, 협업 과정의 불필요한 충돌을 줄였다. ## Variables를 통한 다중 환경 대응 - Figma Variables를 활용해 23,000명 이상의 직원과 다양한 조직·파트너의 요구에 맞춰 디자인을 조정할 수 있게 됐다. - 다음과 같은 조건을 체계적으로 관리할 수 있다. - 다양한 화면 크기 - 라이트 모드와 다크 모드 - 팀별 테마 - 외부 파트너를 위한 테마 - 여러 환경에 맞는 디자인을 개별적으로 수정하는 대신, 변수 기반으로 체계화해 반복 작업을 줄였다. - 그 결과 Alaska의 디자이너들은 평균적으로 주당 11시간의 작업 시간을 절약했다. Alaska Airlines 사례는 디자인 시스템을 단순한 컴포넌트 모음이 아니라 디자인·개발·문서·교육을 연결하는 운영 체계로 구축해야 효과가 커진다는 점을 보여준다. 여러 플랫폼과 테마를 동시에 지원해야 하는 조직이라면 공통 컴포넌트와 Variables를 함께 도입하고, 이를 뒷받침할 문서화와 팀 교육까지 병행하는 것이 실용적이다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템사용자 경험+4

figma·2024년 4월 15일·3분 읽기큐레이션 요약

카바나가 일관성과 확장성을

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 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템사용자 경험+4

figma·2024년 4월 7일·3분 읽기큐레이션 요약

디자인 시스템 구축 방법

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

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템사용자 경험+3

figma·2024년 2월 13일·3분 읽기큐레이션 요약

원활한 핸드오프를

핸드오프는 디자인이 끝나는 한순간의 전달이 아니라, 작업 중인 디자인과 맥락·커뮤니케이션이 지속적으로 오가는 과정이다. 원활한 협업을 위해서는 개발자가 필요한 정보를 명확히 확인할 수 있도록 주석을 정리하고, 디자인·개발 간 공통 언어를 만들며, 파일 구조를 체계적으로 정리해야 한다. 특히 “Ready for dev”가 실제 구현 가능한 상태를 의미하도록 팀의 기준과 작업 방식을 맞추는 것이 중요하다. ## 주석과 콜아웃을 간결하고 명확하게 정리하기 - 주석은 디자인 결정의 의도와 개발자가 놓치기 쉬운 세부 사항을 전달하는 수단이다. - 모든 간격이나 색상을 반복해서 설명하기보다, 이미 변수나 스타일로 정의된 정보는 생략하고 다음과 같은 내용을 우선적으로 표시한다. - 새로 사용하는 컴포넌트 - 프로토타입만으로는 명확하지 않은 인터랙션 - 플랫폼별로 다르게 보여야 하는 요소 - 특정 레이어의 속성, 크기, 동작 방식 - 개발자와 먼저 어떤 정보가 유용한지 합의하면 불필요한 주석을 줄일 수 있다. - Figma의 annotations와 Dev Mode를 활용하면 스펙, 측정값, 설명을 최종 디자인에 직접 고정할 수 있다. - 주석은 디자이너와 개발자 간 대화를 대체하는 것이 아니라, 대화가 필요한 지점을 명확하게 해 커뮤니케이션을 개선한다. ## 디자인과 개발의 공통 언어 만들기 - 디자인과 개발은 서로 다른 분야이므로 같은 용어가 다른 의미로 해석될 수 있다. - 예를 들어 디자이너가 “toggle”이라고 했을 때 개발자가 “switch”를 떠올릴 수 있다. - 프로젝트 초기에 컴포넌트와 속성의 명칭을 합의하면 이후 구현 논의에서 불필요한 혼선을 줄일 수 있다. - 색상, 폰트, 간격처럼 기초적인 디자인 요소는 변수와 스타일로 관리해 디자인과 코드가 동일한 기준을 사용하도록 한다. - 개발팀에 이미 네이밍 규칙이 있다면 디자인 시스템에도 이를 반영하는 것이 좋다. - 예를 들어 `bg-primary-active`, `body text`처럼 공유된 명칭을 사용하면 특정 색상의 헥스 코드나 폰트 세부 정보를 매번 설명하지 않아도 된다. - 디자인 시스템의 색상 휠과 같은 도구를 활용하면 색조와 명도를 일관되게 선택하고 적용할 수 있다. ## 파일과 캔버스를 라벨로 정리하기 - Figma의 무한 캔버스는 아이디어를 자유롭게 펼치기 좋지만, 개발자가 처음 파일을 열었을 때 필요한 화면을 찾기 어렵게 만들 수 있다. - 브레인스토밍과 반복 작업 단계에서는 파일이 다소 복잡해도 괜찮지만, 개발에 넘길 시점에는 구조를 정리해야 한다. - 관련 디자인을 섹션으로 묶어 캔버스 내 탐색 범위를 좁힌다. - 구현이 준비된 섹션이나 프레임에는 “Ready for dev” 상태를 표시해 개발자가 우선 확인할 대상을 알 수 있게 한다. - 팀 차원에서 동일한 파일 템플릿을 사용하면 매번 구조를 새로 파악해야 하는 부담과 컨텍스트 전환을 줄일 수 있다. 실무에서는 주석을 많이 다는 것보다 필요한 정보만 남기고, 변수·스타일·공통 명칭을 디자인 시스템에 정착시키는 것이 효과적이다. 또한 개발 전달 전에는 파일을 정리하고 구현 범위를 명확히 표시해 “Ready for dev”가 팀 내에서 실제로 신뢰할 수 있는 상태가 되도록 관리하는 것이 좋다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템dev-mode+3

figma·2024년 2월 11일·3분 읽기큐레이션 요약

디자인 시스템이란 무엇

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

원문 읽기(새 탭에서 열림)

디자인 토큰디자인 시스템사용자 경험접근성+2

figma·2024년 1월 8일원문

Razorpay가 개발자 워크플 (새 탭에서 열림)

인도 최대의 금융 서비스 기업인 Razorpay는 1,000만 개 이상의 비즈니스를 지원하기 위해 디자인 시스템 'Blade'를 구축하여 일관된 사용자 경험과 개발 효율성을 동시에 확보했습니다. 웹과 모바일을 아우르는 단일 API 구조를 통해 플랫폼 간 전환 비용을 최소화하고, 전용 플러그인과 Figma Dev Mode를 적극 활용해 디자이너와 개발자 간의 협업 마찰을 획기적으로 줄였습니다. 결과적으로 Blade는 단순한 가이드를 넘어 제품의 신뢰성을 높이고 시장 출시 속도를 앞당기는 핵심 동력으로 자리 잡았습니다. **크로스 플랫폼을 위한 단일 라이브러리 체계** * 웹, iOS, Android 등 다양한 플랫폼에서 동일한 API와 속성을 공유하는 단일 디자인 시스템을 운영하여 개발자가 플랫폼을 옮겨가더라도 기존 지식을 그대로 활용할 수 있게 했습니다. * 하드코딩으로 인해 발생할 수 있는 텍스트 필드의 에러 처리나 버튼 상태값 누락 등의 세부적인 오류를 방지하고, 모든 컴포넌트에 접근성(Accessibility)을 기본적으로 내장했습니다. * 디자이너와 개발자가 동일한 언어를 사용함으로써 커뮤니케이션 비용을 줄이고, 디자인에서 보는 결과물이 코드와 일치하도록 보장합니다. **지표 기반의 도입 전략과 조직 내 확산** * 새로운 기능을 개발할 때는 디자인의 70%, 기존 화면을 수정할 때는 50% 이상 Blade 컴포넌트를 사용하도록 KPI를 설정하여 디자인과 개발 팀이 공동의 목표를 추구하게 합니다. * 'Blade Coverage' 플러그인을 통해 디자이너가 시스템에서 얼마나 벗어나고 있는지 실시간으로 확인하게 함으로써, 핸드오프 단계 이전에 피드백을 주고받을 수 있는 환경을 조성했습니다. * 리더십의 지지를 바탕으로 전담 슬랙 채널 운영, 오피스 아워, 시연 영상 공유 등을 통해 내부 고객(직원)들의 채택률을 높이고 연간 NPS(순추천지수) 설문을 통해 만족도를 관리합니다. **RazorSharp와 Dev Mode를 통한 코드 자동화** * 개발자가 일일이 속성을 검사하던 비효율을 제거하기 위해 디자인을 코드로 자동 변환해주는 자체 플러그인 'RazorSharp'를 개발했습니다. * Figma의 Dev Mode를 도입하면서 기존 편집 권한이 필요했던 플러그인 제약을 극복했고, 개발자가 편집 권한 없이도 코드를 복사하고 Storybook 링크를 통해 바로 컴포넌트 환경으로 이동할 수 있게 했습니다. * VS Code 플러그인을 연동하여 개발 환경 내부에서 직접 디자인 사양을 확인하며 코드를 작성하는 워크플로우를 구축했습니다. **Variables를 활용한 토큰 관리 및 성능 최적화** * 기존의 복잡한 토큰 명명 규칙(surface/text/subtle)을 개발자 친화적인 구조(surface.text.subtle)로 변환하고, 간격(spacing) 토큰을 변수화하여 개발 편의성을 높였습니다. * 여러 테마와 라이트/다크 모드를 개별적으로 만들던 방식에서 변수(Variables) 기반 시스템으로 전환하여 메모리 소모를 대폭 줄이고 디자인 작업 속도를 개선했습니다. * 이를 통해 하나의 테마 안에서 다양한 모드를 유연하게 구현할 수 있게 되어 시스템의 복잡성을 낮추고 관리 효율을 극대화했습니다. **디자인 시스템 운영을 위한 실용적 제언** 디자인 시스템의 성공은 단순히 컴포넌트를 만드는 것에 그치지 않고, 개발자가 실제 작업 환경에서 얼마나 편리하게 코드를 추출하고 적용할 수 있느냐에 달려 있습니다. Razorpay처럼 자체 플러그인을 개발하거나 Dev Mode를 적극 활용하여 '디자인 검사'에 들어가는 시간을 줄이고, 정량적인 사용량 지표(Coverage)를 통해 팀의 성과를 객관화하는 접근 방식이 권장됩니다. 또한, 시스템의 복잡도가 커질수록 Variables 기능을 활용해 성능 저하를 방지하고 개발 생산성을 높이는 전략이 필수적입니다.

디자인 토큰Figma디자인 시스템웹 개발+3

figma·2023년 12월 5일·3분 읽기큐레이션 요약

Headspace와 함께 살아

Headspace는 제품·파트너십·브랜드 확장에 대응하려면 수작업과 플러그인 중심의 디자인 시스템을 확장 가능한 구조로 전환해야 했다. 이를 위해 Figma의 변수와 디자인 토큰을 도입하고, 단일 브랜드용 시스템을 여러 브랜드와 플랫폼을 지원하는 시스템으로 재구축했다. 그 결과 디자인·엔지니어링 팀이 공유할 수 있는 소스 오브 트루스를 마련하고, 반복적인 색상·타이포그래피 변경 작업을 크게 줄일 수 있었다. ## 확장에 한계가 있던 기존 디자인 시스템 - Headspace는 앱, 웨어러블, VR, 다양한 브랜드 협업 등 100개국 이상에서 여러 접점을 운영하고 있었다. - 기존 시스템은 수작업과 플러그인에 크게 의존해 규모가 커질수록 유지보수가 어려웠다. - 색상이 고정된 hex 코드로 관리되어 동일한 색상에 여러 값이 생겼고, 화면과 제품 간 사용자 경험이 일관되지 않았다. - 색상 팔레트처럼 단순한 변경에도 디자인 시스템 담당자가 몇 시간에서 며칠을 소비해야 했다. - 플러그인은 임시 해결책이었지만 다음과 같은 문제가 있었다. - 디자이너가 자주 사용하지 않으면 학습 비용이 높았다. - Figma의 스타일을 수정할 때마다 플러그인을 다시 설정해야 했다. - 디자인·엔지니어링 팀이 신뢰할 수 있는 단일 기준점을 제공하지 못했다. ## 여러 브랜드를 위한 시스템으로 전환 - 2021년 Ginger와의 합병이 발표되면서 Headspace는 단일 브랜드용 시스템의 한계를 해결해야 했다. - 새 시스템은 Headspace뿐 아니라 Headspace Care와 향후 파트너 브랜드까지 수용할 수 있어야 했다. - 기존 시스템을 감사한 뒤 컴포넌트와 패턴을 다시 구축해 디자이너와 엔지니어가 쉽게 찾고 참조할 수 있도록 했다. - 이 과정에서 Headspace 최초의 디자인 토큰 시스템을 만들었다. - 색상, 타이포그래피 등 반복적으로 사용되는 디자인 속성을 추상화해 브랜드별로 재사용하고 변경할 수 있는 기반을 마련했다. ## Figma 변수와 디자인 토큰 도입 - Headspace는 기존 플러그인 중심 워크플로를 Figma의 네이티브 변수 기능으로 대체했다. - 색상 값을 직접 입력하는 대신 의미 기반 토큰으로 관리했다. - 예: 특정 hex 코드가 아니라 배경색, 텍스트색, 강조색과 같은 역할 중심 이름을 사용 - 변수에 값을 연결하면 하나의 값을 변경해 이를 사용하는 여러 컴포넌트와 화면에 일괄 반영할 수 있다. - 테마와 브랜드가 달라져도 같은 컴포넌트 구조를 유지하면서 변수 값만 교체할 수 있다. - Steven은 약 2년 동안 플러그인 기반 시스템을 구축했지만, 변수 도입 후 색상 토큰과 타이포그래피를 하루 만에 변수로 구현했다고 설명한다. - 변경 사항은 한 달 이내에 디자이너와 엔지니어에게 배포되었다. ## 디자인·엔지니어링 협업 개선 - 토큰과 컴포넌트를 명확하게 구조화해 디자인과 코드 사이의 대응 관계를 쉽게 만들었다. - 디자이너는 반복적인 스타일 수정 대신 제품 경험과 시스템 개선에 집중할 수 있게 되었다. - 엔지니어는 임의의 색상값이나 스타일을 해석하는 대신 공유된 토큰을 기준으로 구현할 수 있다. - 디자인 시스템이 브랜드 가이드 문서에 머무르지 않고 실제 제품 제작 과정에서 작동하는 소스 오브 트루스가 되었다. - 여러 제품과 플랫폼이 늘어나도 동일한 원칙과 컴포넌트를 재사용할 수 있는 확장성을 확보했다. Headspace 사례는 디자인 시스템을 단순히 컴포넌트 모음으로 관리하기보다, 변수와 토큰을 활용해 브랜드·테마·플랫폼 변화를 흡수하는 구조로 설계해야 한다는 점을 보여준다. 특히 제품과 조직이 빠르게 성장한다면 하드코딩된 스타일과 플러그인 의존성을 줄이고, 의미 기반 토큰과 네이티브 변수부터 정비하는 것이 실용적인 출발점이다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템design-variables+2

figma·2023년 12월 5일·3분 읽기큐레이션 요약

변수에 관한 모든 궁금증 해결

Figma의 변수(Variables)는 단순한 디자인 토큰을 넘어 여러 상태와 플랫폼에 따라 디자인 값을 동적으로 바꾸고, 디자인과 코드를 더 밀접하게 연결하는 기능이다. 이번 업데이트로 효과, 선 두께, 투명도, 레이아웃 그리드, 모서리 반경, 중첩된 컴포넌트 인스턴스까지 변수로 제어할 수 있게 되어 반응형·다중 플랫폼 디자인의 유연성이 크게 향상됐다. Figma는 앞으로 타이포그래피 영역까지 변수 활용을 확장할 계획이다. ## 변수의 확장된 활용 - 변수는 색상이나 간격 같은 고정된 토큰을 대체하는 데 그치지 않고, 모드에 따라 값이 달라지는 유연한 설계 단위로 사용된다. - 데스크톱·모바일, 라이트·다크 모드, 브랜드별 테마 등 서로 다른 조건에 맞춰 디자인을 한 번에 조정할 수 있다. - Headspace처럼 디자인 시스템의 일관성을 유지하면서도 다양한 제품 상황과 협업 요구에 대응하는 데 활용할 수 있다. - 변수의 개방적인 구조 덕분에 일반적인 디자인 시스템뿐 아니라 Figma 안에서 게임과 인터랙티브 작품을 만드는 등 창의적인 용도로도 사용된다. ## 효과와 시각적 속성의 반응형 제어 - 블러 크기, 드롭 섀도의 색상, 오프셋 거리 등 효과의 다양한 속성에 변수를 바인딩할 수 있다. - 모드가 바뀌면 효과 값도 함께 변경되므로, 플랫폼이나 테마에 맞는 시각적 표현을 자동으로 적용할 수 있다. - 레이어의 불투명도 역시 변수로 제어할 수 있으며, 불투명도 필드를 마우스 오른쪽 버튼으로 클릭해 변수를 연결한다. - 개별 모서리 반경을 변수에 연결해 네 모서리를 동일하게 처리하지 않고 각각 세밀하게 조정할 수 있다. ## 플랫폼별 반응형 디자인 - 선 두께를 변수로 관리해 데스크톱과 모바일 등 플랫폼별로 다른 스트로크 값을 적용할 수 있다. - 레이아웃 그리드도 변수와 모드에 따라 변경할 수 있어 화면 크기나 기기별 레이아웃을 더욱 정밀하게 설계할 수 있다. - 동일한 컴포넌트 구조를 유지하면서 모드만 전환해 픽셀 단위로 최적화된 디자인을 만들 수 있다. ## 중첩된 컴포넌트 인스턴스 제어 - 컴포넌트 내부에 포함된 다른 컴포넌트 인스턴스의 변형(variant)에도 변수를 연결할 수 있다. - 이를 통해 복잡한 컴포넌트 구조에서도 내부 요소의 상태와 속성을 상위 시스템에서 유연하게 제어할 수 있다. - 여러 단계로 중첩된 디자인 시스템을 구성할 때 반복적인 수동 수정이 줄어든다. ## 변수와 스타일의 관계 - 스타일은 특정 색상, 텍스트, 효과 등을 재사용하는 데 적합한 반면, 변수는 조건이나 모드에 따라 값이 바뀌는 동적 상황에 더 적합하다. - 변수는 기존 스타일을 대체하기보다는 스타일과 함께 사용해 디자인 시스템을 확장하는 방식으로 이해할 수 있다. - 변수의 활용 범위가 넓어지면서 디자인 파일의 값과 실제 코드에서 사용하는 토큰 사이의 연결도 더 자연스러워진다. ## 디자인과 코드의 연결 강화 - 변수 기반으로 디자인 값을 관리하면 개발자가 사용하는 플랫폼별 토큰 및 테마 값과 디자인 시스템을 맞추기 쉬워진다. - 모드와 변수 구조를 코드의 상태값이나 디자인 토큰 구조에 대응시킬 수 있어 핸드오프 과정의 불일치를 줄일 수 있다. - Figma는 이러한 연계를 앞으로 타이포그래피까지 확장하려 하며, 글꼴 크기·행간·문자 간격 등도 더 유연하게 관리할 가능성을 제시한다. 실무에서는 먼저 색상과 간격처럼 반복 사용이 많은 값을 변수화한 뒤, 라이트·다크 모드나 모바일·데스크톱 모드를 구성하는 것이 좋다. 이후 효과, 투명도, 그리드, 컴포넌트 상태로 범위를 넓히면 디자인 시스템의 일관성과 반응형 설계 효율을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템반응형 디자인+2

figma·2023년 8월 30일·3분 읽기큐레이션 요약

스포티파이의 디자인

Spotify는 45개 플랫폼과 2,000종 이상의 기기에서 일관된 브랜드 경험을 제공하기 위해 디자인 시스템 Encore를 플랫폼별 체계에서 크로스플랫폼 체계로 확장했다. 초기에는 모바일과 웹 시스템이 분리되어 유연성을 얻었지만, 시간이 지나며 컴포넌트의 불일치와 중복이 커졌다. 이에 공통 기반과 재사용 가능한 중간 계층을 마련하고, 컴포넌트를 처음부터 여러 플랫폼이 함께 설계하는 방식으로 전환했다. ## 일관된 경험이 필요해진 배경 - Spotify는 TV, 자동차, 모바일, 컴퓨터 등 다양한 환경에서 오디오 콘텐츠를 제공하게 됐다. - 2019년 기준 45개 플랫폼, 2000종 이상의 기기, 200개 브랜드에 걸쳐 서비스를 제공해야 했다. - 목표는 모든 플랫폼을 단순히 지원하는 것이 아니라, 어떤 기기에서도 사용자가 “Spotify답다”고 느끼는 일관된 경험을 만드는 것이었다. - 디자인 시스템의 컴포넌트가 플랫폼 간 경험을 통합하는 핵심 수단으로 강조됐다. ## Encore의 초기 구조와 한계 - Encore는 2019년 두 개의 하위 시스템으로 출발했다. - **Encore Consumer Mobile**: 모바일 중심 경험을 위한 유연한 UI 컴포넌트 카탈로그 - **Encore Web**: 다양한 웹 제품을 위한 시스템 - 색상과 타이포그래피 같은 기본 디자인 결정에는 디자인 토큰을 사용했다. - 그러나 각 하위 시스템이 독립적으로 발전하면서 버튼의 크기, 타이포그래피, 상태 표현 등에서 차이가 생겼다. - 제품팀의 요구가 커지면서 컴포넌트가 지나치게 유연해졌고, 플랫폼 간 공통성이 약해졌다. ## 공통 기반과 재사용 계층의 도입 - 2022년 Spotify는 유연성에 치우친 구조를 재조정할 필요가 있다고 판단했다. - Encore Mobile을 위한 재사용 가능한 컴포넌트 제작 전담 팀을 구성했다. - 이 새로운 계층은 공통 기반과 Consumer Mobile 사이에 위치했다. - 이를 통해: - Consumer Mobile이 모든 컴포넌트를 직접 제공해야 하는 부담을 줄이고 - Web과 Mobile 사이의 플랫폼 대응성을 높이며 - 제품별로 중복 구현되는 컴포넌트를 줄일 수 있었다. - Web 팀과 협력해 크로스플랫폼 컴포넌트를 나중에 맞추는 대신, 처음부터 함께 개발하기 시작했다. ## 크로스플랫폼 컴포넌트 설계 방식 - 기존처럼 사용자 조사, 디자인, 개발로 이어지는 과정 자체는 유지했다. - 가장 큰 변화는 디자인 단계에서 특정 플랫폼 하나만을 대상으로 하지 않는 것이었다. - iOS, Android, Web 팀이 함께 각 플랫폼의 요구사항과 특성을 조사하고, 공통 경험을 조율했다. - 플랫폼별 고유성을 없애는 것이 아니라, 공통된 구조와 시각적 언어를 유지하면서 각 환경에 맞게 적용하는 것이 목표였다. - 웹, 모바일, TV는 입력 방식과 화면 크기 등 사용 맥락이 다르므로, 동일한 컴포넌트를 그대로 복제하기보다 플랫폼의 장점을 보존해야 했다. - 이를 위해 각 플랫폼 전문가가 협업하는 구조가 중요했다. 웹과 모바일 양쪽 모두에 정통한 디자이너는 드물기 때문에, 여러 분야의 전문성을 한 과정 안에서 결합해야 했다. Spotify의 사례는 디자인 시스템을 플랫폼별 컴포넌트 모음으로 관리하기보다, 공통 기반·재사용 계층·플랫폼별 특화를 연결하는 구조로 설계해야 한다는 점을 보여준다. 실무에서는 플랫폼 팀을 초기 설계 단계부터 참여시키고, 공통 토큰과 컴포넌트의 범위를 명확히 정하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)

디자인 토큰디자인 시스템AndroidiOS+3

figma·2023년 7월 26일·3분 읽기큐레이션 요약

디자인 시스템의 미래

디자인 시스템의 미래는 단순히 색상·간격 같은 값을 표준화하는 데서 나아가, 그 값의 의미와 사용 목적을 중심으로 설계하는 시맨틱 방식에 있다. 디자인 토큰과 Figma 변수는 디자인 결정을 여러 플랫폼과 코드에 일관되게 전달하고, 테마 변경과 동적 프로토타이핑까지 가능하게 한다. 따라서 변수는 디자인 시스템을 기록하는 도구를 넘어 디자인과 개발을 연결하는 핵심 기반으로 발전하고 있다. ## 디자인 시스템의 복잡성과 토큰의 필요성 - 시간이 지나면 제품 안에 동일한 목적의 색상·간격·타이포그래피 값이 중복되면서 디자인 시스템이 복잡해진다. - Google Maps는 제품에 700개가 넘는 색상이 사용되고 있음을 발견한 뒤, 이를 25개의 색조로 정리했다. - 축소된 색상 체계가 다시 무질서하게 늘어나지 않도록 디자인 토큰을 사용해 색상 팔레트를 문서화하고 배포했다. - 토큰은 색상, 숫자, 문자열, 테두리 반경, 크기, 글꼴 등 반복되는 디자인 결정을 표현하는 데이터다. - 특정 컴포넌트나 구현 방식에서 디자인 속성을 분리하므로 플랫폼에 종속되지 않고 여러 제품과 환경에서 재사용할 수 있다. - 예를 들어 모든 “나무” 요소의 색상을 변경해야 한다면, 개별 요소를 수정하지 않고 하나의 토큰만 바꿔 전체에 반영할 수 있다. ## 디자인 토큰에서 시맨틱 시스템으로 - 토큰은 디자인 결정을 코드나 특정 컴포넌트가 아닌 독립적인 값으로 관리해 일관성과 유지보수성을 높인다. - Salesforce는 2014년부터 여러 플랫폼과 소프트웨어에 동일한 디자인 원칙을 적용하기 위해 토큰을 활용한 사례로 자주 언급된다. - 토큰의 진정한 가치는 값 자체보다 값이 제품 안에서 어떤 역할을 하는지 표현하는 데 있다. - 예를 들어 단순히 `blue-500`처럼 색상 자체를 지정하기보다, `button-background-primary`처럼 사용 목적과 의미를 나타내면 테마나 브랜드가 바뀌어도 구조를 유지하기 쉽다. - 이런 시맨틱 접근은 디자인 시스템을 시각적 스타일 모음이 아니라 제품의 의도와 규칙을 표현하는 체계로 확장한다. ## Figma 변수의 역할 - Figma 변수는 디자인 속성과 프로토타이핑 동작에 재사용 가능한 값을 저장한다. - 색상, 숫자, 문자열 등 다양한 값을 한 곳에서 관리하고 여러 디자인 요소에 적용할 수 있다. - 기존 토큰의 사용 사례를 충족하면서도 값이 실제로 “변할 수 있다”는 점을 강조한다. - 변수는 디자인 시스템의 값을 중앙에서 관리해 반복 작업을 줄이고, 변경 사항을 여러 화면에 일관되게 적용한다. - 단순한 디자인 결정의 기록을 넘어 다음과 같은 기능을 지원한다. - 라이트·다크 모드와 같은 디자인 테마 전환 - 조건에 따른 프로토타이핑 로직 - 여러 플랫폼에 공유할 수 있는 재사용 가능한 값 관리 - 디자인과 코드 사이의 연결 강화 ## 디자인과 개발을 연결하는 기반 - Config 2023에서 Figma는 Dev Mode, 변수, 고급 프로토타이핑 기능 등을 공개하며 디자인에서 구현으로 이어지는 흐름을 강화했다. - 변수는 디자인 시스템이 디자인 파일 안에만 머무르지 않고 코드와 동일한 개념과 값을 공유하도록 돕는다. - 이후 공개된 Code Connect는 개발자가 실제 코드 컴포넌트와 디자인 컴포넌트를 연결하는 방향을 더욱 강화한다. - typography 및 gradient 변수, Library Analytics API 같은 기능은 디자인 시스템의 적용 범위를 넓히고 조직 전체의 사용 현황과 도입을 관리할 수 있게 한다. - 결과적으로 디자인 시스템은 디자이너만 관리하는 라이브러리가 아니라 디자인·개발·제품팀이 함께 사용하는 공통 언어가 된다. ## 실용적인 적용 방향 - 색상이나 간격 값을 무작정 늘리기보다 먼저 제품에서 각 값이 수행하는 역할을 정의한다. - 원시 값과 의미 기반 값을 구분해 관리한다. 예를 들어 `blue-500`과 `text-color-error`를 별도 계층으로 둘 수 있다. - 테마 변경 가능성을 고려해 컴포넌트에 구체적인 색상값을 직접 넣지 않는다. - 디자인 토큰을 코드와 공유할 수 있는 형식으로 관리하고, Figma 변수와 실제 구현 값의 동기화 방식을 마련한다. - 디자인 시스템의 성공 여부를 라이브러리의 크기보다 재사용성, 일관성, 코드와의 연결성, 조직 내 adoption으로 평가하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

디자인 토큰Figma디자인 시스템프로토타이핑+2