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

회고를 위한 Figma

애자일·스크럼 팀의 회고를 Figma에서 진행하면 화이트보드와 포스트잇의 한계를 줄이고, 모든 구성원이 동시에 의견을 작성하고 확인할 수 있다. Figma의 실시간 협업, 댓글, 컴포넌트 기능은 원격 참여를 돕고 팀이 새로운 도구에 자연스럽게 익숙해지도록 한다. 글은 회고용 템플릿을 만들고 공유하는 방법부터 프레임·스티키 노트·브랜드 요소를 활용해 맞춤화하는 방법까지 단계별로 설명한다. ## Figma를 회고에 사용하는 이유 - 기존 화이트보드 회고에는 다음과 같은 문제가 있다. - 사람들 앞에 나가 직접 글을 쓰는 것이 부담스러울 수 있다. - 손글씨를 읽기 어렵다. - 여러 사람이 동시에 보드 앞에 서기 어렵다. - Figma는 멀티플레이어 방식으로 여러 명이 같은 파일에 동시에 접속할 수 있다. - 참가자별 커서가 표시되어 서로의 작업을 실시간으로 확인할 수 있다. - 댓글과 협업 기능을 활용하면 회의실에 직접 참석하지 못한 원격 구성원도 참여하기 쉽다. - 회고를 통해 팀에 Figma를 소개하고 도입 가능성을 시험해볼 수 있다. ## 파일 공유와 권한 설정 - 회고용 Figma 파일을 새로 만들거나 제공된 템플릿을 복제한다. - 우측 상단의 파란색 **Share** 버튼으로 파일을 공유한다. - 구성원을 이메일로 초대하거나 공유 링크를 생성할 수 있다. - 링크로 참여하는 사람도 의견을 작성할 수 있도록 편집 권한을 설정해야 한다. ## 회고 카테고리를 프레임으로 구성 - 화이트보드의 구역처럼 Figma 캔버스를 프레임으로 나눈다. - 기본 회고 템플릿은 세 가지 프레임으로 구성된다. - 계속할 일: 잘 작동했으므로 유지할 것 - 중단할 일: 비효율적이거나 개선이 필요한 것 - 시작할 일: 새롭게 시도할 것 - 프레임 내부의 제목과 배경 등에 **Constraints**를 설정한다. - 프레임 크기를 늘리거나 줄여도 내부 요소가 자동으로 조정되므로 참가자들이 작성할 공간을 쉽게 확장할 수 있다. ## 스티키 노트 컴포넌트로 의견 작성 - 참가자들이 각 카테고리에 빠르게 의견을 추가할 수 있도록 스티키 노트 컴포넌트를 제공한다. - 컴포넌트를 선택한 뒤 `Command + D`를 누르거나, `Option/Alt`를 누른 채 드래그해 복제한다. - 컴포넌트 인스턴스에는 오버라이드가 가능하다. - 텍스트 변경 - 색상 변경 - 효과 조정 - 원본 컴포넌트를 훼손하지 않고 각자의 메모를 개성 있게 꾸밀 수 있다. - 원격 참가자도 동일한 화면을 보며 다른 사람의 작업을 따라갈 수 있다. - 다른 사람의 아바타를 클릭해 해당 사용자의 화면을 관찰하는 기능도 활용할 수 있다. ## 팀에 맞게 템플릿 맞춤화 ### 회사 로고와 브랜드 색상 추가 - 회고 파일에 회사 로고 컴포넌트를 추가한다. - 회고 결과를 이미지나 PDF로 내보낼 때 조직의 정체성을 반영할 수 있다. - Figma의 **Styles** 패널에서 회사 브랜드 색상을 지정한다. ### 동의 표시용 컴포넌트 만들기 - 팀원들이 특정 의견에 동의하거나 추가 논의를 원할 때 `+1` 표시를 사용할 수 있다. - `+1` 아이콘이나 배지를 별도 컴포넌트로 만들어 재사용한다. - 각 인스턴스의 크기와 색상을 조정할 수 있도록 구성하면 다양한 의견 표시 방식에 대응할 수 있다. ### 회고별 커버 페이지 구성 - Figma 파일의 첫 페이지를 회고용 커버 페이지로 활용한다. - 회고마다 새 파일을 만든다면 프로젝트, 스프린트, 계절 등 다양한 테마를 적용할 수 있다. - 회고 결과물을 보관하거나 공유할 때 파일을 쉽게 식별하는 데 도움이 된다. 실제로 적용할 때는 회고 전에 편집 권한과 프레임 구조를 미리 설정하고, 참가자들이 사용할 스티키 노트와 동의 표시 컴포넌트를 준비하는 것이 좋다. 이후 회고가 끝나면 프레임을 내보내 결과와 실행 항목을 기록해두면 협업 기록으로도 활용할 수 있다.

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

collaborationFigma디자인 시스템agile+1

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

피그마, 세쿼이아

Figma는 Sequoia Capital이 주도한 4,000만 달러 규모의 Series C 투자를 유치했으며, 이를 통해 협업형 디자인 플랫폼으로서의 성장을 가속하려 한다. 회사는 조직·엔터프라이즈 기능, 성능과 디자인 시스템 지원, 플랫폼 확장성, 글로벌 커뮤니티에 집중할 계획이다. 궁극적으로 Figma는 디자인을 누구나 쉽게 표현하고 함께 작업할 수 있는 개방적이고 커뮤니티 중심의 공간으로 만들고자 한다. ## 투자 유치와 투자자 구성 - Series C 규모는 4,000만 달러다. - Sequoia Capital이 투자를 주도했다. - Coatue, Founders Fund, LinkedIn CEO 제프 와이너, Instagram 공동창업자 마이크 크리거, EA CEO 앤드루 윌슨, Facebook 파트너십 부사장 댄 로즈가 참여했다. - 기존 투자자인 Index, Greylock, KPCB도 함께 투자했다. - Figma는 단순한 자금보다 지속 가능한 기업과 커뮤니티를 구축한 경험이 있는 투자자를 확보하는 데 의미를 뒀다. ## 협업형 디자인 도구로의 확장 - 생산성 도구 전반이 공유와 협업을 중심으로 변화하고 있으며, 디자인 도구도 같은 방향으로 발전한다고 설명한다. - Square, Uber, Twitter, GitHub 등 주요 기업의 디자인 팀이 Figma를 전면적으로 도입하고 있다. - 투자금은 기업용 **Organization 제품**을 발전시키는 데 활용된다. - 동시에 개인 디자이너와 소규모 팀의 사용 경험도 개선할 예정이다. - 이는 Figma를 개인용 디자인 도구에서 대규모 조직의 표준 협업 플랫폼으로 확장하려는 전략이다. ## 성능과 디자인 시스템 - Figma는 네이티브 경쟁 제품보다 빠르다는 평가를 받고 있지만, 로딩과 렌더링 성능을 더 개선할 여지가 있다고 본다. - 가입자가 100만 명을 넘은 만큼, 사용자 규모가 커져도 안정적이고 높은 품질의 경험을 제공하는 것이 중요하다. - 특히 디자인 시스템을 만들고 관리하기에 가장 좋은 환경을 구축하는 데 집중한다. - 디자인 시스템은 여러 팀이 일관된 UI 요소와 규칙을 공유하도록 돕는 핵심 기업 기능으로 제시된다. ## 플랫폼과 확장성 - 디자인 프로세스가 진정으로 개방적이려면 다양한 사용 사례에 맞게 Figma를 확장할 수 있어야 한다. - 회사는 플랫폼 기능과 확장 기능을 개발하고 있다. - 다만 확장 기능의 안정성과 보안을 확보하는 것이 우선이므로 구체적인 출시 일정은 제시하지 않았다. - 향후 플러그인이나 외부 도구 연동을 통해 Figma의 활용 범위가 넓어질 가능성을 보여준다. ## 글로벌 커뮤니티 구축 - Figma의 주간 활성 사용자 중 80%가 미국 외 지역에서 활동한다. - 라고스부터 토론토까지 26개 도시에서 사용자 그룹이 운영되고 있다. - 회사는 서로 다른 지역의 사용자를 더 효과적으로 연결하고, 지역 커뮤니티가 성장하도록 지원할 계획이다. - Sequoia가 커뮤니티 중심 비즈니스 구축 경험을 갖췄다는 점도 투자 유치의 중요한 이유로 언급된다. - Figma는 커뮤니티를 제품 성장의 부수적 요소가 아니라 미래 전략의 기반으로 본다. Figma는 이번 투자를 바탕으로 기업용 협업 기능과 제품 품질을 강화하는 동시에, 확장 가능한 플랫폼과 글로벌 사용자 커뮤니티를 구축하려 한다. 기업이나 팀에서 디자인 협업 도구를 선택할 때는 실시간 공동 작업뿐 아니라 조직 관리, 디자인 시스템, 확장성, 커뮤니티 생태계까지 함께 고려할 필요가 있다.

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

collaborationFigma디자인 시스템design-tools+2

figma·2019년 1월 16일·3분 읽기큐레이션 요약

피그마의 엔지니어

Figma는 엔지니어링 팀이 커져도 협업 방식과 핵심 문화를 유지하기 위해 팀의 가치를 명문화했다. 이 가치는 이상적인 목표가 아니라 팀이 이미 실천한다고 판단한 행동 기준이며, 각 가치에는 다른 선택을 포기하는 트레이드오프가 포함된다. 특히 조기 소통과 팀 구성원 간의 성장을 통해 개인의 성과보다 지속 가능한 협업을 중시한다. ## 엔지니어링 가치를 만든 이유 - 팀이 확장될수록 기존의 협업 방식과 문화를 유지하기 어려워진다. - 자신과 비슷한 사람만 채용하는 ‘단일문화(monoculture)’를 피하면서도 중요한 업무 방식을 보존해야 했다. - 모든 구성원이 행동, 우선순위, 프로세스, 팀 전통, 회사의 경쟁력과 미래에 대해 논의한 뒤 네 가지 가치를 정리했다. - 가치는 “좋은 코드를 작성하자”처럼 누구나 반대하기 어려운 추상적 문구가 아니라, 실제 의사결정에 사용할 수 있는 구체적인 기준이어야 한다. - 각 가치에는 포기하는 것이 있다. 즉, 가치가 무엇을 우선하는지뿐 아니라 무엇을 감수하는지도 분명히 해야 한다. ## 일찍, 자주 소통하기 - 코드 리뷰 시점까지 기다리지 말고 설계 문서, 제품 사양, 아키텍처 초안 등을 작업 초기에 공유한다. - 문제를 혼자 해결한 뒤 결과를 발표하기보다, 여러 사람이 함께 방향을 검토하도록 한다. - 초기 공유를 통해 잘못된 가정을 빠르게 발견하고, 큰 비용을 들이기 전에 방향을 수정할 수 있다. - 미완성 작업을 공유하는 문화를 만들면 도움을 요청하기 쉬워지고, 공유하는 사람과 동료 모두에게 자연스러운 학습 기회가 생긴다. - 소통 방식이 반드시 정해진 절차일 필요는 없다. 어떤 경우에는 코드 자체가 가장 효과적인 의사소통 수단이며, 단순한 버그 수정에는 여러 사전 논의가 필요하지 않다. - 조기 공유는 다른 사람의 의견을 실제로 받아들일 때만 효과가 있다. 의견 충돌이 생겨도 일찍 공유하면 방향 전환 비용을 줄일 수 있다. - 모든 의견을 폭넓게 듣는 대신 의사결정이 느려지고, 논의와 조율에 많은 시간이 걸릴 수 있다는 트레이드오프가 있다. ## 팀을 성장시키기 - 자신의 성공만이 아니라 주변 동료의 성공과 행복을 함께 우선한다. - 팀을 돕는다는 것은 회사의 성과를 위해 자신을 희생하는 것이 아니라, 지속 가능한 방식으로 동료 엔지니어를 성장시키는 것을 뜻한다. - 기술 발표, 온보딩 멘토링, 새로운 기술 학습 장려 등 지속적인 학습과 성장을 지원한다. - 피드백은 사람을 공격하지 않고 아이디어와 작업에 초점을 맞춰야 한다. - 모욕적이거나 상대를 깎아내리는 말은 효과적인 피드백이 아니며, 다양한 의견을 안전하게 제시할 수 있는 포용적 문화를 만들어야 한다. - 구성원 간의 긍정적이고 존중하는 관계를 통해 서로를 더 나은 엔지니어로 만든다. - 이 가치의 핵심은 경쟁에서 개인이 앞서는 것이 아니라, 함께 일하는 사람들이 더 나아지도록 돕는 ‘팀 중심’의 성공이다. 팀의 가치는 벽에 걸어두는 선언문보다 실제 설계 공유, 피드백, 멘토링, 의사결정에서 반복적으로 적용되는 기준이어야 한다. 조직에 도입할 때는 추상적인 구호보다 구체적인 행동과 감수할 트레이드오프까지 함께 정의하는 것이 좋다.

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

collaboration코드 리뷰software-engineeringsoftware-architecture+2

figma·2018년 3월 18일·3분 읽기큐레이션 요약

이제 Figma 버전 히스토리에 이름을

Figma는 웹 기반 자동 저장의 장점을 살려 버전 기록을 직접 이름 붙이고 주석을 추가할 수 있는 기능을 출시했다. 이를 통해 디자인 마일스톤을 쉽게 찾고 복원·복제할 수 있으며, 협업자는 각 변경 사항을 버전별로 검토할 수 있다. 결과적으로 별도 파일을 내보내거나 대면 회의를 할 필요가 줄어들고, 디자인 검토와 협업 속도가 향상된다. ## 웹 기반 자동 저장의 한계 보완 - Figma 파일은 웹에서 지속적으로 자동 저장되므로 별도의 동기화가 필요 없다. - 하지만 자동 저장 버전이 많아지면 중요한 변경 시점을 찾기 어려워지는 문제가 있었다. - 기존 데스크톱 디자인 도구에서는 버전 검토와 변경 문서화를 위해 파일을 별도로 내보내거나 우회적인 작업을 해야 했다. - 새 버전 기록 기능은 자동 저장 흐름 위에 사용자가 직접 중요한 버전을 표시하고 설명하도록 한다. ## 버전에 이름과 주석 추가 - 사용자는 특정 디자인 단계를 직접 저장하고 이름을 붙일 수 있다. - 각 버전에 메모를 추가해 변경 내용이나 해당 단계의 목적을 기록할 수 있다. - 예를 들어 다음과 같은 시점을 명확히 남길 수 있다. - 첫 번째 디자인 리뷰 전 상태 - 사용자 테스트에 처음 사용한 디자인 - 특정 기능이 완성된 마일스톤 - 중요한 버전은 나중에 복원하거나 새 파일로 복제할 수 있다. - 단축키: - macOS: `⌘ + ⌥ + S` - Windows: `Ctrl + Alt + S` ## 자동 저장 기록 정리 - 사용자가 수동으로 저장한 버전 사이의 자동 저장 기록은 자동으로 묶여 표시된다. - 중요하지 않은 중간 기록이 화면을 가득 채우지 않아 전체 변경 흐름을 빠르게 훑을 수 있다. - 버전 기록은 파일 이름을 클릭한 뒤 **Show Version History**에서 확인할 수 있다. ## 페이지별 버전 관리 - 기존에는 파일 전체 단위로만 버전 기록을 확인할 수 있었다. - 새 기능에서는 특정 페이지를 선택한 뒤 해당 페이지의 버전 기록을 따로 볼 수 있다. - 여러 페이지에서 동시에 작업하는 파일에서도 변경 사항을 구분하기 쉬워진다. - 페이지를 선택하고 파일 이름을 클릭한 뒤 **View Version History**를 선택하면 된다. ## 주석을 활용한 빠른 디자인 리뷰 - 이해관계자는 각 버전에 변경 사항과 검토 의견을 직접 남길 수 있다. - 디자이너는 버전별 변경 내용을 별도의 문서나 회의에서 다시 설명할 필요가 줄어든다. - 협업자는 서로 다른 디자인 단계의 결과를 비동기적으로 검토할 수 있다. - 결과적으로 리뷰 시간을 줄이고 더 빠르게 합의에 도달할 수 있다. ## 실용적인 활용 방법 - 큰 변경을 완료할 때마다 버전에 이름을 붙이고 한두 문장으로 변경 목적을 기록하는 것이 좋다. - 페이지별로 버전을 관리하면 기능·화면 단위의 변경 이력을 추적하기 쉽다. - 리뷰 전, 사용자 테스트 전, 최종 승인 전처럼 팀의 업무 흐름에 맞춰 마일스톤을 정의하면 버전 기록을 효과적으로 활용할 수 있다. - 별도 파일을 반복해서 내보내기보다 Figma의 버전 기록을 협업과 검토의 기준으로 사용하는 것이 권장된다.

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

collaborationFigmaversion-historyautosave+1

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

디자인 시스템을 위한 고급

디자인 시스템을 운영하려면 구성 요소를 쉽게 공유하는 것뿐 아니라, 누가 프로젝트를 보고 수정할 수 있는지도 세밀하게 관리해야 한다. Figma는 이를 위해 유료 팀에 **보기 전용(View-only)**과 **초대 전용(Invite-only)** 프로젝트 권한을 도입했다. 이 기능은 유지 관리자가 디자인 시스템을 보호하면서도 팀 전체의 활용을 지원하도록 해, 실수로 인한 변경을 줄이는 것이 핵심 목적이다. ## 디자인 시스템 운영에서 권한 관리가 필요한 이유 - 디자인 시스템 제작자는 새 구성 요소를 팀 전체에 공개하기 전에 비공개로 테스트할 필요가 있다. - 시스템이 배포된 뒤에는 많은 디자이너가 실수로 핵심 구성 요소를 수정하지 않도록 보호해야 한다. - 기존에는 Figma 팀의 편집자가 모든 프로젝트를 보고 수정할 수 있어, 유지 관리자와 사용자를 구분하기 어려웠다. - Team Library가 파일과 팀 간 구성 요소 공유를 해결했다면, Advanced Project Permissions는 프로젝트의 접근 범위와 수정 권한을 해결한다. ## 새로 추가된 프로젝트 권한 유료 Professional Team의 편집자는 프로젝트 생성 시 다음 세 가지 접근 수준을 선택할 수 있다. - **팀 전체 편집 가능** - 팀의 모든 구성원이 프로젝트를 보고 수정할 수 있다. - **팀 전체 보기 가능** - 팀 구성원은 프로젝트를 열람할 수 있지만 내용을 수정할 수 없다. - 배포된 디자인 시스템을 보호하는 데 적합하다. - **초대 전용** - 지정된 사용자만 프로젝트에 접근할 수 있다. - 개발 중인 디자인 시스템이나 제한된 협업에 활용할 수 있다. 기존 프로젝트도 Share 버튼을 통해 기본 접근 권한을 변경할 수 있다. ## 유지 관리자와 사용자를 분리하는 보호 장치 - 디자인 시스템 유지 관리자는 컴포넌트와 스타일을 만들고 안정성을 관리한다. - 일반 사용자는 시스템의 구성 요소를 참고하거나 활용하되, 원본을 직접 변경하지 않는 것이 바람직하다. - 보기 전용 권한은 사용자의 접근성을 유지하면서도 우발적인 편집을 방지하는 완충 역할을 한다. - 특히 규모가 큰 팀에서 의도하지 않은 수정으로 디자인 시스템이 훼손되는 문제를 줄일 수 있다. ## 권한 강화의 한계와 향후 방향 - 유지 관리자와 사용자의 비율에 따라 일부 구성원은 시스템을 직접 개선할 기회가 줄어들 수 있다. - 보기 전용 권한은 안정성을 높이지만, 개선 제안과 실제 반영 사이에 별도의 의사소통 과정이 필요하다. - Figma는 코드 저장소의 풀 리퀘스트와 유사하게, 디자이너가 변경을 제안하고 유지 관리자가 검토하는 방식을 검토하고 있었다. - 이를 통해 권한 보호와 개방적인 개선 문화를 함께 구현하려는 방향을 제시했다. 디자인 시스템을 운영할 때는 개발 중인 프로젝트에는 **초대 전용**, 공식 배포본에는 **보기 전용**, 공동 편집이 필요한 작업에는 **팀 전체 편집 가능** 권한을 적용하는 방식이 실용적이다. 다만 변경 제안 절차와 검토 책임자까지 함께 정해 두어야 권한 제한이 협업 저하로 이어지지 않는다.

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

collaborationFigma디자인 시스템access-control+2

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

Figma의 팀 라이

Figma의 Team Libraries는 여러 파일과 팀원이 동일한 컴포넌트를 공유하고 동기화하도록 해 디자인 시스템 구축을 돕는 기능이다. 기존처럼 파일마다 심볼을 복사해 수동으로 교체하는 방식의 불일치 문제를 해결하고, 컴포넌트를 게시·삽입·업데이트하는 흐름으로 단일 진실 공급원을 유지한다. 이를 통해 디자인 시스템을 더 빠르고 일관되게 확장할 수 있다. ## 기존 디자인 도구의 한계 - 전통적인 디자인 도구는 사진 편집, 일러스트 제작, 정적인 화면 구성에 초점을 맞췄다. - 실제 애플리케이션의 반응형 동작이나 플랫폼의 제약 조건을 충분히 표현하지 못했다. - 디자인 시스템을 하나의 마스터 파일에서 관리하더라도 컴포넌트를 다른 파일로 복사하면 서로 다른 버전이 된다. - 작은 변경도 여러 문서를 찾아 각 심볼과 오버라이드를 수동으로 수정해야 했다. - Facebook, Google, Airbnb 같은 기업은 이러한 한계를 보완하기 위해 자체 디자인 시스템 도구와 전담 인력을 구축했다. ## Figma가 제시한 기반 - Figma는 시각 디자인과 동적인 사용자 인터페이스 설계를 연결하는 것을 목표로 했다. - 벡터 편집, 시스템 동작에 대응하는 제약 조건, 재사용 가능한 동적 컴포넌트를 제공해 디자인 시스템의 기반을 마련했다. - Team Libraries를 통해 이 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있게 했다. - 웹 기반 구조 덕분에 파일 간 동기화 지연이 거의 없고, 여러 기기와 플랫폼을 위한 레이아웃을 일관된 규칙으로 설계할 수 있다. ## 엔지니어링 원칙을 반영한 디자인 시스템 - React 같은 프레임워크처럼 애플리케이션을 명확히 정의된 작은 단위로 구성하는 방식을 디자인에도 적용했다. - 재사용 가능하고 유지보수하기 쉬운 구조는 제품 개발 주기 전체의 효율을 높인다. - 다만 프로그래밍 개념을 그대로 가져오기보다 디자이너가 쉽게 사용할 수 있도록 인터페이스와 작업 흐름을 단순화했다. ## 게시(Publish): 단일 진실 공급원 만들기 - 파일에서 컴포넌트를 선택하고 Inspector의 **Add to Library**를 눌러 라이브러리에 추가한다. - 여러 컴포넌트를 선택한 뒤 변경 사항을 검토하고 팀 라이브러리에 게시한다. - 라이브러리와 원본 파일을 분리해 디자인 시스템의 변경 권한을 통제할 수 있다. - 원본 파일에 편집 권한이 있는 사람만 소스 컴포넌트를 수정할 수 있다. - 원본 파일을 볼 수 있는 사람은 게시된 컴포넌트를 사용할 수 있지만 규칙 자체를 변경할 수는 없다. - 예를 들어 프로덕션 디자이너는 아이콘을, 브랜드 디자이너는 색상 문서를 관리하고 다른 팀원은 이를 재사용할 수 있다. ## 삽입(Insert): 여러 파일에서 컴포넌트 재사용 - 라이브러리에 게시된 컴포넌트는 원본 파일을 볼 권한이 있는 팀원에게 제공된다. - 각 파일의 툴바에서 컴포넌트 도구를 선택해 공유 컴포넌트를 삽입한다. - 컴포넌트 안에 다른 컴포넌트를 중첩할 수 있다. - 개별 요소로 모듈을 구성한 뒤, 이를 더 복잡한 화면과 사용자 흐름에서 재사용할 수 있다. - 깊게 중첩된 컴포넌트도 원본과 연결되므로 단일 진실 공급원을 예측 가능하게 유지할 수 있다. ## 업데이트(Update): 변경 사항의 동기화 - 브랜드 가이드나 UI 자산을 변경할 때 기존 컴포넌트를 수정하고 다시 게시한다. - 재게시 전 확인 단계를 거치며, 이전 버전과 무엇이 달라졌는지 시각적 diff로 확인할 수 있다. - 원본 파일에서 컴포넌트를 삭제한 뒤 게시하면 팀 라이브러리에서도 해당 컴포넌트가 사라진다. - 따라서 팀에는 현재 유효한 디자인 시스템 요소만 공유된다. - 공유 컴포넌트의 변경이 여러 탐색 작업에 영향을 줄 수 있으므로, 작업 손실을 막기 위한 추가 확인 절차를 둔다. ## 실용적인 결론 Team Libraries는 디자인 시스템을 복사본이 아니라 연결된 컴포넌트 구조로 관리하게 해준다. 팀에서는 원본 파일의 편집 권한을 제한하고, 색상·아이콘·버튼·복합 모듈을 라이브러리로 게시한 뒤 변경 사항을 검토하며 재게시하는 운영 방식을 마련하는 것이 좋다.

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

collaborationFigma디자인 시스템사용자 인터페이스+3

figma·2015년 12월 14일·2분 읽기큐레이션 요약

처음부터 슬랙과 함께 |

Figma는 협업형 인터페이스 디자인 도구의 핵심 협업 경험을 자체 메시징 기능이 아니라 Slack 위에 구축하기로 했다. 디자이너들이 Slack을 일상적으로 사용하고, Slack 사용자가 디자인 과정을 더 개방적으로 공유하는 경향이 있었기 때문이다. 따라서 Figma 팀을 Slack 팀과 연결하고 파일 알림도 Figma가 아닌 Slack으로 전달하는 전략이 통합과 사용자 경험 측면에서 효과적이었다. ## Slack 사용자를 관찰한 배경 - Figma는 제품을 개발하며 디자이너들이 파일 저장, 사양 작성, 제품 의사결정 등을 어떻게 협업하는지 조사했다. - 인터뷰한 디자이너 중 절반 이상이 Slack을 하루 종일 사용한다고 답했다. - Slack 사용 여부는 다른 협업 방식과도 연관되어 있었다. - Slack을 사용하는 디자이너일수록 디자인 과정을 팀에 더 개방적이고 투명하게 공유하는 경향이 있었다. - 이를 통해 Slack이 단순한 채팅 도구가 아니라 디자인 협업의 중심 채널이 될 수 있다고 판단했다. ## 중복 기능을 만들지 않은 이유 - Figma는 디자인에 대한 커뮤니케이션을 지원하는 제품이므로, 자체적으로 메시지·알림 기능을 구현하고 싶은 유혹이 있었다. - 하지만 Slack과 비슷한 기능을 다시 만들면 다음과 같은 문제가 생긴다. - 사용자가 메시지를 확인할 장소를 하나 더 관리해야 한다. - 팀을 Figma와 Slack 양쪽에서 별도로 설정해야 한다. - 이미 익숙한 협업 흐름이 여러 서비스로 분산된다. - Figma는 사용자가 또 다른 메시지함을 확인하도록 만들기보다, 기존에 사용 중인 Slack을 협업 기반으로 활용하기로 했다. ## Figma와 Slack의 긴밀한 통합 - Figma의 협업 모델에서 “Figma 팀”은 “Slack 팀”과 연결된다. - Figma 파일에서 발생하는 알림은 Figma 내부가 아니라 Slack을 통해 전달된다. - 사용자는 Slack에서 디자인 관련 소식을 확인하고 팀원과 논의할 수 있다. - 이는 Slack을 단순한 외부 연동 대상이 아니라 Figma 협업 경험의 기반 플랫폼으로 활용한 결정이다. ## 플랫폼 전략과 사업적 판단 - Figma는 Slack 플랫폼이 공식적으로 출시되기 전부터 Slack을 플랫폼으로 바라보고 통합을 준비했다. - Slack 중심의 협업 구조는 당시로서는 큰 전략적 선택이었지만, 초기 성과를 통해 그 판단이 효과를 내고 있다고 평가했다. - 글은 앞으로 다른 기업들도 자체 기능을 무작정 복제하기보다, 사용자가 이미 익숙한 플랫폼 위에 제품 경험을 구축할 가능성이 커질 것이라고 전망한다. 실용적으로는 새로운 협업 기능을 개발할 때 자체 메시징·알림 시스템을 추가하기 전에, 사용자가 이미 매일 사용하는 도구와 자연스럽게 연결하는 방식을 우선 검토할 필요가 있다.

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

collaborationFigmaslackapi-integration+2