component-library

21 개의 포스트

figma3분 읽기큐레이션 요약

Figma로 하는 고객

고객 여정 지도는 고객이 특정 과정을 거치며 경험하는 단계와 감정, 고충을 시각적으로 보여 주어 팀의 공통 이해를 돕는 도구다. 글은 Figma를 활용하면 여정 지도 제작부터 인터뷰 기록, 협업, 버전 관리, 고객 피드백 수집까지 하나의 공간에서 수행할 수 있다고 설명한다. 다만 프로세스가 비선형적이거나 분기·의존성이 많다면 고객 여정 지도보다 사용자 흐름도가 더 적합할 수 있다. ## 고객 여정 지도가 필요한 이유 - 자동차 구매, 웹사이트 상품 구매, 의료 서비스 이용처럼 고객이 여러 단계를 거치는 과정을 시각적으로 표현한다. - 각 단계에서 고객이 무엇을 하고, 어떤 감정을 느끼며, 어떤 불편이나 고충을 겪는지 함께 기록할 수 있다. - 서로 다른 관점을 가진 팀원도 동일한 지도를 보며 조사 결과를 빠르게 이해할 수 있다. - 고객 경험을 개선할 수 있는 문제 지점과 기회를 공동으로 발견하는 데 유용하다. - 프로세스가 단순하고 순차적일 때 특히 효과적이다. - 반대로 분기나 의존성이 많은 비선형 프로세스에는 전통적인 2차원 사용자 흐름도가 더 적합하다. ## 여정 지도 컴포넌트 라이브러리 구축 - 팀 전용 컴포넌트와 스타일 라이브러리를 만들면 지도마다 일관된 시각 언어를 유지할 수 있다. - 반복적으로 사용하는 단계, 감정 표현, 아이콘, 라벨 등을 재사용해 새 지도를 빠르게 제작할 수 있다. - 디자인 변경이 필요할 때 개별 요소를 수정하는 대신 컴포넌트를 업데이트하면 전체 지도에 일괄 반영할 수 있다. - Figma의 샘플 파일이나 고객 여정 지도 템플릿을 출발점으로 활용할 수 있다. ## Tidy Up으로 단계 정리 - Figma의 **Tidy Up** 기능을 사용하면 여정 단계 사이의 간격을 쉽게 조정할 수 있다. - 중간에 새로운 단계를 삽입하거나 기존 단계를 재배치할 때 전체 레이아웃을 크게 다시 작업하지 않아도 된다. - 단계가 많아질수록 수동 정렬에 드는 시간을 줄이고 구조적인 배치를 유지할 수 있다. ## 실시간 협업과 인터뷰 기록 - 여러 디자이너가 동시에 같은 여정 지도를 편집할 수 있다. - 인터뷰 노트를 Figma에 직접 기록하면 조사 자료와 디자인 결과물이 여러 도구로 분산되지 않는다. - 리서치 담당자와 디자이너가 동일한 파일에서 내용을 확인하고 즉시 보완할 수 있다. - 인터뷰 정보와 지도 요소가 한곳에 모이므로 조사 결과를 시각적 산출물에 연결하기 쉽다. ## 버전 기록으로 변화 추적 - 고객 리뷰 전에 Figma 버전 기록에 수동으로 타임스탬프를 남겨 특정 시점의 결과물을 보존한다. - 프로젝트가 진행되며 고객에 대한 이해가 어떻게 바뀌었는지 이전 버전과 비교할 수 있다. - 클라이언트에게 여정 지도가 조사 결과에 따라 어떻게 발전했는지 보여 주는 자료로도 활용할 수 있다. ## 댓글을 활용한 지속적인 피드백 - 완성본이 아닌 초기 여정 지도를 실제 고객에게 공유해 조사 결과가 고객 경험과 일치하는지 검증한다. - 고객이 빠진 단계나 새롭게 탐색해야 할 경험을 댓글로 지적할 수 있다. - 댓글을 특정 지도 요소에 직접 배치하면 나중에 어느 단계에 대한 의견인지 명확하게 확인할 수 있다. - 비동기 검토에서는 고객이 파일에 댓글을 남기고, 팀이 댓글 스레드에서 추가 질문을 할 수 있다. - 회의나 화상 통화 중에는 디자이너가 참석자들의 의견을 해당 위치에 바로 기록할 수 있다. - 필요하면 파일을 복제해 고객, 클라이언트 등 피드백 출처별로 분리한다. - 새 검토자가 이전 댓글에 영향을 받지 않도록 하여 편향되지 않은 의견을 얻을 수 있다. - 고객과 클라이언트의 피드백을 비교해 두 집단의 인식 차이도 파악할 수 있다. ## 실용적인 적용 방향 Figma로 고객 여정 지도를 만들 때는 먼저 재사용 가능한 컴포넌트와 스타일을 정하고, 인터뷰 노트와 지도를 같은 파일에서 관리하는 것이 좋다. 이후 버전을 저장하며 고객과 클라이언트에게 단계별 댓글 피드백을 받아 지도를 반복 개선하면, 단순한 시각 자료를 넘어 지속적으로 검증되는 리서치 문서로 활용할 수 있다.

원문 읽기(새 탭에서 열림)
figma2분 읽기큐레이션 요약

DesignSystems.com을

Figma는 디자인 시스템 구축과 운영에 관한 실용적인 지식 허브인 DesignSystems.com을 새롭게 개편해 다시 선보였다. 개편의 핵심은 바로 적용할 수 있는 콘텐츠를 제공하고, 초보자부터 숙련자까지 다양한 수준과 규모의 팀을 아우르며, 여러 관점을 소개하는 것이다. 사이트는 커뮤니티의 피드백을 반영해 지속적으로 콘텐츠를 업데이트하고 기여를 받을 예정이다. ## DesignSystems.com 재출시 배경 - Figma는 2018년 5월 DesignSystems.com을 처음 공개한 뒤 커뮤니티에 아이디어와 의견을 요청했다. - 디자이너, 개발자, 콘텐츠 전략가, 디자인 운영 담당자 등 다양한 직군과 대규모 브랜드부터 1인 팀까지 폭넓은 피드백을 수집했다. - 이러한 의견을 바탕으로 사이트의 목적과 콘텐츠 방향을 재정비했다. ## 실행 가능한 콘텐츠 제공 - 디자인 시스템을 만드는 사람과 운영하는 사람이 실제 업무에 적용할 수 있는 글과 자료를 제공한다. - 단순한 개념 소개보다 명확한 시사점과 실천 방법을 포함하는 것을 목표로 한다. - 샘플 코드, 디자인 파일, 가이드, 커뮤니티 사례 등을 통해 이론과 실무를 연결한다. ## 다양한 수준과 팀 규모 지원 - 디자인 시스템을 처음 시작하는 사람을 위한 입문 가이드를 제공한다. - 이미 성숙한 디자인 시스템을 운영하는 실무자를 위해 선도적인 기업의 사례와 경험도 소개한다. - Lyft, Asana, Harry’s 등 디자인 시스템 팀의 글을 통해 조직 규모와 성숙도에 따른 다양한 접근법을 보여준다. - 대기업뿐 아니라 소규모 팀이나 개인 단위의 실무자도 참고할 수 있도록 콘텐츠 범위를 넓힌다. ## 여러 관점과 사례 수집 - 디자인 시스템 문제에는 하나의 정답만 존재하지 않는다는 관점을 강조한다. - 같은 문제를 서로 다른 조직과 직군이 어떻게 해결했는지 비교할 수 있도록 다양한 목소리를 담는다. - 커뮤니티 구성원 간 경험과 지식을 공유하는 장으로 사이트를 발전시키려 한다. ## 지속적인 커뮤니티 참여 - 이번 재출시는 완성된 결과물이 아니라 지속적인 운영의 시작으로 소개된다. - 새로운 글과 자료를 정기적으로 추가할 예정이다. - 독자에게 사이트 콘텐츠에 대한 피드백과 기고 아이디어 제출을 요청한다. - 관심 있는 사람은 업데이트를 구독하거나 직접 콘텐츠 제작에 참여할 수 있다. 디자인 시스템을 도입하려는 팀은 입문 가이드로 기본 방향을 잡고, 성숙한 기업의 사례를 참고하되 자신의 조직 규모와 업무 방식에 맞게 적용하는 것이 좋다. 특히 여러 사례를 비교해 단일한 정답보다 팀에 적합한 원칙과 운영 방식을 찾는 접근이 권장된다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

디자인 시스템 전파의

디자인 시스템의 확산은 UI 키트나 컴포넌트 라이브러리를 만드는 기술적 작업만으로 이루어지지 않으며, 사람과의 협업을 통해 조직 문화로 정착되어야 한다. 특히 페어링은 다른 디자이너·엔지니어와 함께 작업하며 시스템의 문제를 발견하고, 비판을 협력으로 전환하며, 시스템의 가치를 자연스럽게 전파하는 가장 효과적인 방법이다. 디자인 시스템 팀은 “규칙을 지키라”고 요구하기보다 사용자의 일을 더 빠르고 높은 품질로 만들어 주는 파트너가 되어야 한다. ## 디자인 시스템은 기술 프로젝트가 아니라 문화 프로젝트 - UI 키트나 컴포넌트 라이브러리를 혼자 구축하는 것만으로는 조직의 불일치를 해결할 수 없다. - 디자인 시스템은 디자이너, 엔지니어, 제품 관리자, 고객 사이의 관계와 조직 문화를 반영한다. - “파란색을 쓰지 마라”, “이 컴포넌트를 왜 새로 만들었나”처럼 잘못을 지적하는 방식은 디자인 시스템 팀과 다른 팀을 대립 구도로 만들 수 있다. - Gusto는 다음과 같은 소통 장치를 마련했다. - 피드백과 질문을 위한 Slack 채널 - 디자인 시스템 팀의 오피스 아워 - 신규 구성원을 위한 UI 소개 키트 - 그러나 가장 효과적으로 시스템을 전파한 방법은 직접 함께 작업하는 페어링이었다. ## 페어링은 디자인 시스템의 사용자 조사다 - 다른 디자이너와 나란히 작업하면 실제 사용 과정에서 다음을 관찰할 수 있다. - 어떤 컴포넌트와 패턴이 혼란스러운가 - 문서나 Figma 파일에서 어떤 정보가 부족한가 - 기존 시스템에서 이상하거나 잘 작동하지 않는 부분은 무엇인가 - 팀이 사용자의 필요를 추측하는 대신, 실제 사용 데이터를 바탕으로 컴포넌트와 문서를 개선할 수 있다. - 페어링 중에는 다음과 같은 질문에 답할 수 있다. - 디자이너와 엔지니어가 컴포넌트 라이브러리의 존재를 알고 있는가 - HTML·CSS의 최신 모범 사례를 이해하고 있는가 - 특정 컴포넌트를 사용하는 것이 조직 전체에 왜 유리한지 설명하고 있는가 - 개인 작업에서 유용한 레이아웃을 공식 패턴으로 발전시킬 수 있는가 - 오피스 아워는 사용자가 언제 도움을 받아야 하는지 판단하지 못해 참여율이 낮을 수 있지만, 페어링은 실제 작업 흐름 안에서 문제를 발견한다. ## 비판을 협업으로 전환하는 페어링 - 디자인 시스템 팀과의 협업은 추가적인 디자인 리뷰가 아니라, 작업 속도를 높이고 향후 버그를 줄이는 과정처럼 느껴져야 한다. - 초기 디자인 시스템은 복잡하고 문서화가 부족한 경우가 많다. - 사용할 수 있는 색상이 제한되어 있다는 사실 - 이미 동일한 용도의 컴포넌트가 존재한다는 사실 - 특정 구현 방식이 접근성 기준을 위반한다는 사실 - 이런 규칙을 한꺼번에 강요하면 통제적으로 보일 수 있고, 엔지니어는 문서를 무시하며 디자이너는 기존 시스템과 어울리지 않는 UI를 만들 수 있다. - 페어링은 디자인 시스템 팀이 머릿속에만 보관하던 코드베이스의 제약과 조직의 지식을 직접 전달하게 한다. - 동시에 디자인 시스템 팀도 제품 디자이너가 실제로 어떤 일을 해야 하는지 이해하게 된다. - 결과적으로 디자인 시스템 팀은 현장의 요구를 파악하고, 제품 팀은 프런트엔드 컴포넌트와 패턴을 배우면서 양쪽 모두 더 빠르게 작업할 수 있다. ## 시스템의 지지자를 만드는 방법 - 페어링을 경험한 디자이너와 엔지니어는 디자인 시스템을 단순한 규칙 모음이 아니라 자신의 작업을 개선하는 도구로 이해하게 된다. - 직접 협업을 통해 얻은 지식은 각 팀으로 돌아가 자연스럽게 공유될 수 있다. - 디자인 시스템의 채택을 높이려면 규칙 준수를 감시하기보다, 시스템이 창의성을 제한하는 것이 아니라 작업에 “추진력을 더해준다”는 경험을 제공해야 한다. - 이런 경험이 축적되면 디자인 시스템 팀 외에도 시스템을 설명하고 추천하는 내부 전도자(evangelist)가 늘어난다. 실무적으로는 정기적인 페어링 세션을 실제 디자인·개발 과제와 연결하고, 세션에서 발견한 혼란과 요구를 컴포넌트·문서 개선으로 바로 반영하는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Bulb, 디자인 시스템 Solar

Bulb는 여러 제품의 디자인·코드베이스·패턴이 서로 달랐던 문제를 해결하기 위해 Figma로 디자인 시스템 ‘Solar’를 구축했다. Figma의 브라우저 기반 협업과 팀 라이브러리를 활용해 디자이너뿐 아니라 개발자, 연구자, 콘텐츠 작성자, 이해관계자까지 디자인 과정에 참여하도록 만들었다. 핵심 전략은 제품 전반을 조사한 뒤 디자인 원칙을 세우고, 작고 단순한 컴포넌트와 패턴부터 점진적으로 표준화하는 것이었다. ## Bulb의 성장과 디자인 조직의 과제 - 영국의 친환경 에너지 기업 Bulb는 18개월 동안 2,000% 성장했다. - 디자인팀은 13명 규모로, 여러 제품 그룹에서 엔지니어·PM·리서처·콘텐츠 작성자와 협업했다. - 기존 5~6개 제품은 서로 다른 에이전시가 제작해 다음 문제가 있었다. - 제품마다 다른 코드베이스 사용 - 버튼, 체크박스, 드롭다운 등 디자인 패턴의 불일치 - 시각적 브랜드는 통일되어도 실제 사용 경험은 일관되지 않음 - 새롭게 구성된 디자인팀은 디자인 시스템과 이를 지원할 도구를 처음부터 설계할 수 있었다. ## Figma를 통한 개방적인 협업 - Bulb의 조직 문화는 사업 부문 간 협업과 투명성을 중시했으며, 디자인 도구도 이러한 문화를 지원해야 했다. - 프로젝트별 ‘팟(pod)’에 디자이너, 리서처, 콘텐츠 작성자, 개발자가 함께 참여했다. - Figma에서는 디자이너의 별도 허가 없이도 다른 직군이 파일을 열어 다음 작업을 수행할 수 있었다. - 디자인에 의견과 제안 남기기 - 최신 작업 내용 확인 - 아이디어 스케치와 브레인스토밍 - 프로토타입 제작 및 검토 - 개발자와 디자이너가 설계 과정 전반에서 함께 논의하며 가이드라인과 품질 기준을 확인할 수 있었다. - 비디자이너에게도 복잡하거나 위협적인 도구가 아니어서 사용자 리서처가 디자이너와 직접 아이디어를 발전시키기 쉬웠다. ## Solar 디자인 시스템의 구축 과정 - 목표는 여러 제품에서 일관된 디자인을 보장하는 ‘단일 진실 공급원(single source of truth)’을 만드는 것이었다. - Figma 팀 라이브러리를 활용하면 마스터 컴포넌트를 수정했을 때 이를 사용하는 여러 디자인에 변경 사항이 동기화됐다. - 모든 파일을 브라우저에서 접근할 수 있어 빠르게 움직이는 팀에 적합했다. - 구축 초기에는 Bulb의 각 제품 페이지를 스크린샷으로 수집해 Figma에 시각적 사이트맵을 만들었다. - 이 사이트맵을 통해 제품별 차이와 불일치를 한눈에 파악했다. - 여러 직군이 참여해 디자인 원칙을 정의하고, 이를 기준으로 컴포넌트와 디자인 패턴을 정리했다. - 버튼·체크박스·드롭다운처럼 여러 버전이 존재하던 요소를 검토해 더 단순하고 견고한 패턴을 선택했다. - 정리한 패턴은 8개 제품에 단계적으로 적용됐다. ## 작고 단순하게 유지하는 원칙 - 디자인 시스템은 처음부터 모든 상황을 포괄하려 하기보다 작은 범위에서 시작해야 한다. - Solar는 다음과 같이 복잡도를 의도적으로 낮췄다. - 제한된 색상 팔레트 - 적은 수의 디자인 패턴 - 관리하기 쉬운 단순한 구조 - 시스템이 복잡해질수록 유지보수와 운영이 어려워지므로, 필요한 요소만 포함하고 지속적으로 단순화하는 것이 중요하다. - 디자인 시스템을 여러 직군이 함께 만들면 실제 구현과 사용 맥락을 반영한 표준을 정립할 수 있다. Bulb의 사례는 디자인 시스템을 단순한 UI 컴포넌트 모음이 아니라, 디자인·개발·리서치·콘텐츠가 함께 일하는 협업 기반으로 구축해야 한다는 점을 보여준다. 먼저 제품 간 불일치를 시각화하고, 명확한 원칙을 정한 뒤, 작은 패턴부터 라이브러리화해 점진적으로 확장하는 접근이 실용적이다.

원문 읽기(새 탭에서 열림)
figma4분 읽기큐레이션 요약

Figma에서 디자인 시스템을 구축

Figma의 디자인 시스템은 팀의 규모나 목적에 따라 다양한 방식으로 구축할 수 있으며, 공통 컴포넌트와 라이브러리를 활용하면 디자인 일관성과 협업 효율을 높일 수 있다. 이 글은 Figma가 제공하는 기능과 실제 사용자 사례를 통해 디자인 시스템을 어디서 시작하고 어떻게 확장할지 보여준다. 핵심은 작은 단위에서 출발해 컴포넌트, 중첩 구조, 팀 라이브러리 등을 점진적으로 발전시키는 것이다. ## Figma가 디자인 시스템을 지원하는 방식 - Figma는 디자인 시스템을 구축하는 사용자를 지원하기 위해 **Constraints**, **Team Library**, **Components** 같은 기능을 발전시키고 있다. - 디자인 시스템은 단순한 UI 키트가 아니라 팀 내 디자이너, 개발자, 제품 관리자 간의 공통 언어로 활용될 수 있다. - Microsoft처럼 매우 복잡한 중첩 컴포넌트와 제약 조건을 활용하는 사례도 있으며, Figma는 사용자가 제품의 한계를 확장하는 다양한 방식을 공유하고자 했다. - 글에 소개된 사례들은 Figma가 비용을 지급하거나 후원한 콘텐츠가 아니라, 실제 사용자들이 작성한 경험 공유다. ## 작은 구성 요소부터 시작하기 — Gusto - Gusto는 급여·인사 관리 서비스를 제공하는 기업으로, 디자인 시스템을 처음 시작할 때의 막막함을 단순한 구성 요소로 해결했다. - 처음부터 완성된 시스템을 만들기보다, 재사용 가능한 기본 요소를 정의하는 방식으로 출발했다. - 디자인 시스템 구축의 첫 단계에서는 다음과 같은 작업이 유용하다. - 반복적으로 사용되는 UI 요소 찾기 - 기본 컴포넌트와 패턴 정리 - 프로젝트와 자산을 체계적으로 분류 - 팀이 실제로 자주 사용하는 요소부터 우선순위화 ## 마케팅·커뮤니케이션 자산 관리 — Square - Square의 마케팅 팀은 제품 UI뿐 아니라 커뮤니케이션 디자인을 위한 내부 디자인 시스템을 구축했다. - 시스템에는 다음과 같은 자산이 포함된다. - 색상 팔레트 - 로고 세트 - 마케팅 및 브랜드 관련 그래픽 자산 - 디자인 시스템을 제품 화면에만 한정하지 않고, 마케팅과 브랜드 업무에도 적용하면 여러 팀이 동일한 시각적 기준을 사용할 수 있다. - Figma 안에서 자산을 공유하면 최신 버전을 쉽게 찾고, 중복 제작이나 오래된 로고 사용을 줄일 수 있다. ## 비디자이너의 참여를 돕기 — Virta Health - Virta Health는 당뇨병 치료 서비스를 제공하는 기업으로, 디자인 시스템을 통해 디자이너가 아닌 구성원도 디자인 작업에 참여할 수 있도록 했다. - 구축 과정은 다음 단계로 진행됐다. - 기존 컴포넌트와 화면을 감사 - 반복되는 패턴과 문제점 파악 - 재사용 가능한 컴포넌트 제작 - 컴포넌트를 활용한 최종 목업 구성 - 비디자이너는 컴포넌트를 드래그 앤 드롭해 아이디어를 시각화할 수 있다. - 그 결과 엔지니어와 제품 관리자가 디자인 개념을 더 쉽게 이해하고, 아이디어를 논의하는 방식도 개선됐다. - 디자인 시스템은 제작 속도뿐 아니라 직군 간 커뮤니케이션을 개선하는 도구로도 기능한다. ## 중첩 컴포넌트로 유연성 높이기 — OpenText - OpenText는 중첩 컴포넌트를 사용해 더 강력하고 유연한 디자인 시스템을 구축했다. - 하나의 컴포넌트 안에 다른 컴포넌트를 조합하면 복잡한 UI 패턴도 일관되게 관리할 수 있다. - 대표적인 활용 예시는 다음과 같다. - 버튼 내부에 아이콘 컴포넌트 배치 - 버튼의 기본·호버·비활성 상태 구성 - 여러 요소를 조합한 복합 UI 패턴 제작 - 하위 컴포넌트를 수정하면 이를 사용하는 상위 컴포넌트에도 변경 사항을 반영할 수 있어 유지보수가 쉬워진다. - 다만 중첩 구조가 지나치게 복잡해지면 관리가 어려워질 수 있으므로, 컴포넌트의 책임과 조합 규칙을 명확히 해야 한다. ## 원자적 디자인 구조 적용하기 — SetProduct.com - SetProduct.com은 **Atomic Design** 원칙을 디자인 시스템의 기반으로 사용했다. - 디자인 요소를 작은 단위에서 큰 단위로 확장한다. - 원자: 텍스트, 아이콘, 색상 등 - 분자: 버튼처럼 여러 원자가 결합된 요소 - 유기체: 카드나 복합 UI 블록 - 템플릿·페이지: 여러 블록이 조합된 화면과 전체 레이아웃 - 이 접근 방식은 디자인 요소 간의 관계를 체계적으로 정리하고, 재사용성을 높이는 데 도움이 된다. - 작은 단위의 변경이 더 큰 화면에 일관되게 적용되므로, 대규모 UI를 관리하기에 적합하다. ## 실무 적용을 위한 접근법 - 처음부터 모든 화면과 컴포넌트를 표준화하려 하지 말고, 반복 사용 빈도가 높은 요소부터 시작한다. - 컴포넌트와 스타일을 팀 라이브러리로 공유해 모든 구성원이 동일한 자산을 사용하도록 한다. - 중첩 컴포넌트와 제약 조건은 반응형 화면과 복잡한 상태를 표현할 때 활용한다. - 디자인 시스템을 디자이너만의 도구로 만들지 말고 개발자와 제품 관리자도 쉽게 사용할 수 있게 구성한다. - 시스템을 한 번 완성하는 프로젝트로 보기보다, 실제 사용 데이터를 바탕으로 계속 개선하는 공용 기반으로 운영하는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

팀 라이브러리 1

Figma의 Team Library 1.0은 팀이 컴포넌트를 공유·사용·관리하며 일관된 디자인 시스템을 구축하도록 돕는 기능이다. 중앙화된 온라인 환경을 기반으로 컴포넌트와 변경 사항을 실시간으로 공유하고, 각 팀원이 업데이트를 적용할지 선택할 수 있게 했다. 베타 버전의 사용성 문제를 개선해 탐색, 문서화, 분류 기능을 강화한 것이 핵심이다. ## 중앙화된 디자인 시스템과 단일 진실 공급원 - 버튼, 아이콘, 다이얼로그 같은 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있다. - Figma의 온라인·중앙화 구조 덕분에 별도의 내보내기, 동기화, 파일 공유가 필요 없다. - 공유 컴포넌트를 게시하거나 수정하면 팀 라이브러리에 즉시 반영된다. - 다른 파일에서 컴포넌트가 변경되면 알림을 받고, 자신의 인스턴스에 변경 사항을 적용할지 결정할 수 있다. - 이를 통해 팀별로 분산된 도구나 클라우드 동기화 작업 없이 일관된 디자인을 유지할 수 있다. ## 라이브러리 탐색 UI 개선 - 베타에서는 컴포넌트를 찾을 때마다 캔버스를 가리는 팝업을 열어야 했다. - 1.0에서는 왼쪽 사이드바에 Team Library 전용 탭을 제공한다. - 작업 화면을 벗어나지 않고 팀 컴포넌트를 탐색할 수 있다. - 원하는 컴포넌트를 사이드바에서 디자인 캔버스로 드래그해 인스턴스를 생성한다. - 왼쪽 사이드바 탭은 `Alt+1` 단축키로 빠르게 전환할 수 있다. - 별도의 로컬 컴포넌트 탭도 제공해, 라이브러리에 게시될 컴포넌트를 미리 확인하고 관리할 수 있다. ## 컴포넌트에 연결된 문서화 - 베타 버전에서는 컴포넌트의 사용 목적이나 동작 방식에 대한 설명을 저장할 공간이 없었다. - 그 결과 관련 정보가 Slack이나 Google Docs에 흩어졌다. - 1.0에서는 오른쪽 속성 패널에서 선택한 컴포넌트에 설명을 추가할 수 있다. - 팀원은 Team Library에서 컴포넌트를 탐색하면서 해당 문서를 함께 확인할 수 있다. - 문서가 컴포넌트 자체에 연결되므로 사용 시점에 필요한 지침을 바로 확인할 수 있다. ## 그룹과 프레임을 활용한 컴포넌트 분류 - 베타에서는 파일 단위로만 컴포넌트를 분류할 수 있어 라이브러리가 쉽게 복잡해졌다. - 1.0에서는 파일뿐 아니라 그룹과 프레임 기준으로도 컴포넌트를 정리할 수 있다. - 예를 들어 버튼 컴포넌트를 “Buttons”라는 그룹에 모으면 Components 탭과 Team Library 탭에서 함께 표시된다. - 그룹과 프레임을 활용하면 규모가 큰 라이브러리에서도 원하는 컴포넌트를 쉽게 찾을 수 있다. - 공유 컴포넌트를 담은 프레임의 배경색을 변경해 라이브러리에서 표시되는 배경을 설정할 수도 있다. ## 베타 피드백을 반영한 제품 발전 - Figma는 2017년 2월 Team Library 베타를 출시한 뒤 수백 명의 사용자와 실제 활용 방식을 논의했다. - 초기 기능은 사용자의 요구를 파악하기 위한 최소한의 형태였지만, 실제 디자인 시스템을 운영하는 팀에는 부족했다. - 사용자 피드백을 바탕으로 탐색 UI, 문서화, 분류 기능을 확장해 1.0 버전을 완성했다. - 목표는 단순한 컴포넌트 저장소가 아니라 팀이 함께 유지·발전시키는 “살아 있는” 디자인 시스템을 만드는 것이었다. 팀에서 디자인 시스템을 운영한다면 컴포넌트를 파일별로 분산시키기보다 Team Library를 단일 관리 지점으로 활용하는 것이 효과적이다. 특히 컴포넌트 설명과 그룹 구조를 함께 정리하면 재사용성과 팀 간 커뮤니케이션을 동시에 높일 수 있다.

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