techlist.io
KREN

디자인 시스템

252 개의 포스트

figma3분 읽기큐레이션 요약

업무 자동화, 데이터 활용,

Figma는 2019년 8월, 누구나 플러그인을 사용하고 직접 만들 수 있는 공개 플러그인 플랫폼을 출시했다. 플러그인은 반복 작업 자동화, 실제 데이터·이미지 활용, 접근성 검사 등 Figma의 기능을 확장하며 디자이너가 필요한 도구를 직접 만들 수 있게 한다. Figma는 웹 개발과 유사한 프로그래밍 경험을 제공하면서도 플러그인의 보안성·안정성·성능을 확보하는 것을 목표로 했다. ## 플러그인 플랫폼을 만든 배경 - 기존 디자인 플러그인에는 두 가지 문제가 있었다. - 공식적으로 충분히 지원되지 않는 API를 사용하는 경우가 많아 안정성과 보안이 떨어졌다. - 디자이너가 직접 코딩하지 못하면 필요한 플러그인을 다른 사람이 만들어주길 기다려야 했다. - Figma는 플러그인을 단순한 부가 기능이 아니라 디자이너의 작업 흐름을 강화하는 “파워업”으로 정의했다. - 내부 목표는 “기본적인 HTML과 JavaScript로 웹 페이지를 만들 수 있다면 Figma 플러그인도 만들 수 있어야 한다”는 것이었다. - 웹 기반 디자인 도구를 위한 플러그인 아키텍처를 새롭게 설계했으며, 이를 통해 더 많은 개발자가 창의적인 플러그인을 만들 수 있도록 했다. ## 누구나 사용하고 만들 수 있는 생태계 - 베타 공개 6주 만에 40개 이상의 공개 플러그인이 제공됐다. - Figma 제품 안에서 플러그인을 검색하고 한 번의 클릭으로 설치할 수 있다. - 디자인 파일에서 마우스 오른쪽 버튼을 클릭해 사용 가능한 플러그인을 실행할 수 있다. - Figma Organization 요금제에서는 다음 기능도 제공된다. - 회사 내부용 비공개 플러그인 제작 및 배포 - 관리자가 승인된 플러그인 목록을 큐레이션 - 관리자가 조직 구성원을 대신해 플러그인 설치 ## 반복 작업을 자동화하는 유틸리티 플러그인 - **Similayer** - 비슷한 속성을 가진 레이어를 한꺼번에 선택한다. - 여러 레이어를 일괄 수정해야 하는 반복 작업을 줄여준다. - **Super Tidy** - 프레임 이름을 정리하고 레이어 목록의 순서를 재배치한다. - 디자인 파일의 구조와 탐색성을 개선한다. - 이런 플러그인은 픽셀 단위의 수작업을 줄이고, 디자이너가 더 중요한 설계 작업에 집중하도록 돕는다. ## 실제 콘텐츠와 시각 자료를 가져오는 플러그인 - **Unsplash** - Unsplash의 이미지를 Figma 파일에 직접 삽입할 수 있다. - 이미지 검색과 배치 과정을 간소화해 디자인 작업에 실제 시각 자료를 빠르게 반영한다. - **Content Reel** - 텍스트, 아바타, 아이콘 등 디자인에 필요한 콘텐츠를 검색하고 배치한다. - 더미 데이터 대신 맥락에 맞는 콘텐츠를 사용해 현실적인 시안을 만들 수 있다. - 이러한 플러그인은 디자인 시스템이나 화면 설계 단계에서 콘텐츠를 수동으로 준비하는 부담을 줄인다. ## 접근성 문제를 발견하는 플러그인 - **Contrast Checker** - 색상, 시각 요소, 타이포그래피의 대비 수준을 검사한다. - 읽기 어렵거나 가독성이 낮은 디자인을 식별하는 데 도움을 준다. - **Color Blind** - 8가지 색각 이상 유형을 기준으로 디자인이 어떻게 보이는지 확인한다. - 디자이너가 다양한 사용자의 시각적 경험을 이해하고 접근성을 개선하도록 돕는다. - 플러그인은 디자이너가 육안으로 놓치기 쉬운 접근성 문제를 작업 과정에서 조기에 발견하게 한다. ## 플러그인이 확장하는 디자인 작업 방식 - 플러그인은 Figma에 없는 기능을 외부 도구로 보완하는 수준을 넘어, 팀과 개인의 고유한 작업 방식에 맞는 도구를 만들게 한다. - 디자이너는 엔지니어링 리소스를 기다리거나 다른 사람이 만든 도구에 의존하지 않고, 필요한 기능을 직접 구현할 수 있다. - Figma는 공개 플러그인과 조직 전용 플러그인을 함께 지원해 개인 창작자와 기업 팀 모두를 플랫폼에 참여시켰다. 플러그인은 반복 업무 자동화, 실제 콘텐츠 활용, 접근성 검증처럼 디자인 프로세스의 구체적인 문제를 해결하는 수단이다. Figma를 사용하는 팀이라면 자주 반복되는 작업과 품질 검사를 먼저 찾아보고, 적합한 공개 플러그인을 도입하거나 조직 전용 플러그인으로 직접 자동화하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
디자인 시스템접근성JavaScriptHTML+3
figma3분 읽기큐레이션 요약

플러그인 비하인드

Yitong Zhang은 Coinbase에서 디자이너가 단순히 PRD를 실행하는 역할을 넘어 제품 전략과 문제 정의에 참여해야 한다고 강조한다. 그는 Figma API를 활용해 두 객체를 선으로 연결하는 자동 플로우 플러그인을 개발하며, 디자인 도구와 커뮤니티의 확장 가능성을 보여준다. 앞으로 디자이너는 픽셀 단위 작업보다 시스템 구축, 전략 수립, 브랜드 경쟁력 강화에 더 집중하게 될 것이라고 전망한다. ### 창업 경험에서 출발한 디자인 - Yitong은 처음부터 디자이너였던 것이 아니라, 스타트업 창업자로서 여러 역할을 수행하며 기술 업계에 들어왔다. - 창업이 실패한 뒤 생계를 위해 디자이너가 되었고, 디자인이 유용한 것을 상상하고 실제로 만들어내는 창업의 즐거운 부분과 닮았다고 설명한다. - 과거 좋아하는 애니메이션의 팬아트를 만들며 디자인 도구를 익힌 경험도 디자이너로 전환하는 데 도움이 되었다. ### Figma API로 만드는 자동 플로우 플러그인 - 개발 중인 플러그인은 **Auto Flow**로, Figma 안의 두 객체를 선으로 연결해 플로우 다이어그램을 빠르게 만들 수 있도록 한다. - 사용자가 객체를 직접 배치하고 연결선을 조정하는 반복 작업을 줄이는 것이 목적이다. - Yitong은 Figma API가 강력하고 사용하기 좋으며, Figma가 디자인의 미래라고 생각하기 때문에 Figma 커뮤니티를 위한 도구를 만든다고 말한다. ### Coinbase에서 디자인의 역할 확장 - Yitong이 가장 자랑스럽게 생각하는 성과는 Coinbase에서 디자인 프로세스를 발전시킨 일이다. - 디자인팀이 제품 요구사항(PRD)을 전달받아 실행하는 조직에서 벗어나, 제품 전략을 함께 만드는 동등한 파트너가 되었다. - 이는 디자인을 시각적 결과물 제작이 아니라 문제와 방향을 정의하는 활동으로 확장한 변화다. ### 문제 정의 단계에 참여하는 디자이너 - 좋은 제품은 잘못된 문제 정의에서 나올 수 없으므로, 디자이너가 해결책을 만드는 단계보다 먼저 문제를 정의하는 과정에 참여해야 한다. - 초기 단계부터 참여하면 제품의 영향력과 윤리적 결과까지 고려할 수 있다. - 디자이너가 제품 개발 후반의 실행자에 머물지 않고, 어떤 문제를 해결할지 결정하는 역할을 맡아야 한다는 주장이다. ### 디자인 직무의 미래 - 제품 디자이너의 업무는 세밀한 픽셀 조정에서 시스템 구축과 전략 정의 중심으로 이동할 것으로 전망한다. - 기술 기업이 브랜드를 강력한 경쟁 우위로 인식하면서 브랜드 디자인은 더욱 중요해지고, 제품 디자인과는 별도의 전문 영역으로 발전할 수 있다. - 디자이너에게는 화면 제작 능력뿐 아니라 시스템적 사고와 비즈니스 전략 이해가 요구될 가능성이 커진다. ### 다른 분야에서 얻는 영감 - Yitong은 자신의 분야와 최대한 거리가 먼 영역에서 영감을 얻으려 한다. - 시스템 수준의 디자인 작업을 하면서 건축을 탐구하는 것이 특히 유익했다고 말한다. - 익숙한 디자인 사례만 참고하기보다 건축처럼 구조, 관계, 시스템을 다루는 분야에서 새로운 관점을 얻는 방식이다. 디자이너는 화면을 예쁘게 만드는 역할에만 머무르지 말고, 제품의 문제 정의와 전략 수립 단계부터 참여하는 것이 좋다. 또한 Figma 플러그인처럼 반복 작업을 자동화하는 도구를 직접 만들고, 건축 등 다른 분야의 시스템적 사고를 배우면 디자인의 영향력을 넓힐 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma프로덕트 디자인plugins+1
figma3분 읽기큐레이션 요약

회고를 위한 Figma

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figmacollaborationagile+1
figma3분 읽기큐레이션 요약

DesignSystems.com의 새로운

DesignSystems.com은 디자인 시스템을 만들고 운영하는 디자이너·개발자·관리자를 위한 지식 공유 플랫폼으로 자리 잡고 있다. 이 글은 2019년 6월에 공개된 주요 콘텐츠 네 가지를 소개하며, 아이콘 설계부터 접근성 높은 React 컴포넌트, 에이전시 협업, 화이트라벨링까지 디자인 시스템의 실무 범위를 보여준다. 핵심은 재사용성과 일관성을 유지하면서도 다양한 사용자와 제품 요구에 유연하게 대응하는 것이다. ## 아이콘 시스템 설계와 구현 - 아이콘 제작의 기본 원칙부터 개발자 전달까지 다루는 종합 가이드를 소개한다. - 주요 내용은 다음과 같다. - 아이콘의 스트로크와 필(fill) 설계 - Boolean 연산을 활용한 아이콘 제작 - 아이콘을 체계적으로 구성하고 관리하는 방법 - 개발자 핸드오프를 위한 파일 및 자산 준비 - 아이콘은 단순한 그래픽 요소가 아니라 디자인 시스템의 일관성과 사용성을 좌우하는 핵심 자산으로 설명된다. ## 에이전시 관점의 디자인 시스템 구축 - Instrument는 Nike, Google, Airbnb 등과 협업하며 일회성 결과물이 아닌 확장 가능한 디자인 시스템을 구축한다. - 재사용 가능한 기능성 컴포넌트를 여러 애플리케이션과 규모에 걸쳐 활용하는 것을 중시한다. - 디자인 시스템의 성공을 위해서는 다음 과정이 중요하다. - 클라이언트와 시스템의 목표 및 범위에 대한 공통 이해 형성 - 높은 수준의 협업을 통한 요구사항 조율 - 특정 프로젝트를 넘어 장기적으로 활용 가능한 구성요소 설계 - 디자인 시스템은 산출물 하나가 아니라 브랜드, 제품, 기술을 연결하는 협업 프로세스로 제시된다. ## 접근성을 공유하는 React 컨테이너 - Zendesk의 오픈소스 디자인 시스템 Garden은 접근성 및 키보드 조작을 공통 패턴으로 관리하기 위해 “컨테이너” 패턴을 사용한다. - 컨테이너는 화면 UI를 직접 렌더링하지 않고 다음 기능을 담당한다. - 키보드 및 마우스 상호작용 처리 - React 컴포넌트 간 접근성 로직 공유 - RTL(오른쪽에서 왼쪽으로 읽는 언어) 레이아웃 지원 - 새 라이브러리인 `react-containers`는 스타일이 포함된 전체 패키지를 설치하지 않아도 비시각적 로직만 사용할 수 있도록 별도 저장소로 분리됐다. - 기존 패턴보다 더 작고 효율적으로 다시 작성됐으며, WAI-ARIA Authoring Practices 1.1에 더욱 가깝게 구현됐다. ## 사용자에게 권한을 제공하는 화이트라벨링 - Dawn Labs는 제3자가 디자인 시스템을 직접 커스터마이즈할 수 있으면서도 제품 전체의 일관성을 유지해야 하는 문제를 다뤘다. - 사용한 기술은 다음과 같다. - `styled-components` - `styled-system` - GraphQL 백엔드 - CSS 변수와 전역 CSS 주입 - 기본 디자인 토큰과 구조는 통제하면서도, 최종 사용자가 클라이언트의 개입 없이 원하는 스타일을 수정할 수 있도록 “스타일링 탈출구”를 제공했다. - 화이트라벨 시스템은 일관된 기본 경험과 사용자별 커스터마이징 사이의 균형이 중요하다. ## 커뮤니티 중심의 지식 공유 - DesignSystems.com은 디자인 시스템 제작자, 디자이너, 개발자, 관리자가 경험과 실무 지식을 공유하는 것을 목표로 한다. - 다양한 분야의 기고를 통해 디자인 시스템을 시각 디자인에만 한정하지 않고 다음 영역까지 확장한다. - 접근성 - 컴포넌트 아키텍처 - 협업과 운영 - 사용자 커스터마이징 - 플랫폼의 성장은 운영팀뿐 아니라 커뮤니티 구성원의 사례와 기여에 기반한다. 디자인 시스템을 구축할 때는 재사용 가능한 컴포넌트와 명확한 시각 규칙뿐 아니라 접근성, 협업 프로세스, 확장 가능한 커스터마이징 구조까지 함께 설계하는 것이 좋다. 특히 공통 로직은 별도 모듈로 분리하고, CSS 변수나 디자인 토큰을 활용하면 일관성과 유연성을 동시에 확보할 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템React접근성GraphQL+4
figma2분 읽기큐레이션 요약

Figma의 새로운 기능 요

Figma는 2019년 봄, 디자인 시스템 확장에 초점을 맞춰 Components를 개선하고 플러그인 API 공개 베타를 시작했다. 여러 컴포넌트를 한 번에 생성하거나 인스턴스와 마스터 간 이동·동기화를 쉽게 만드는 기능으로 반복 작업을 줄였으며, 플러그인을 통해 커뮤니티가 Figma 기능을 확장할 수 있는 기반을 마련했다. 또한 Smart Selection 등 일상적인 기능 개선과 버그 수정도 함께 진행했다. ## 디자인 시스템 확장을 위한 컴포넌트 개선 - 여러 객체를 선택한 뒤 한 번의 클릭으로 각각의 Component로 변환할 수 있다. - 인스턴스를 우클릭하면 Context Menu에서 관련 Component를 바로 확인할 수 있다. - 다른 인스턴스로 빠르게 교체할 때 유용하다. - **Return to Instance** 기능을 사용하면 현재 인스턴스의 Master Component로 이동해 참고하거나 수정한 뒤, 작업 중이던 인스턴스로 돌아올 수 있다. - 로컬 컴포넌트에서는 인스턴스에 적용한 변경 사항과 오버라이드를 Master Component에 반영할 수 있다. - 기존 컴포넌트를 실제 사용 사례에 맞게 조정하고 업데이트할 때 효율적이다. - 이러한 기능들은 재사용 가능한 UI 요소를 관리하고, 팀 단위 디자인 시스템을 확장하는 작업을 단순화한다. ## Figma 플러그인 API 공개 베타 - Figma는 오랫동안 준비한 플러그인 API의 공개 베타를 출시했다. - 플러그인을 통해 사용자가 Figma 내부 기능을 직접 확장하고 반복적인 디자인 작업을 자동화할 수 있게 됐다. - 초기 제작 사례로 다음과 같은 플러그인이 소개됐다. - 텍스트 요소를 방사형으로 반복 배치하는 생성형 디자인 플러그인 - 선택한 이미지에서 주요 색상 팔레트를 추출하는 플러그인 - 공개 직후부터 커뮤니티와 고객들이 다양한 실험적 도구를 만들며 생태계의 가능성을 보여줬다. ## 지속적인 사용성 개선과 품질 향상 - Components와 Smart Selection처럼 매일 사용하는 기능을 빠르게 개선했다. - 사용자가 요청해 온 기능을 추가하는 동시에, 반복 작업에 드는 시간을 줄이는 데 초점을 맞췄다. - 별도의 품질 개선 기간을 운영해 다수의 버그를 수정했다. - 이번 업데이트는 대규모 신기능뿐 아니라 기존 기능의 안정성과 작업 흐름 개선도 중요하게 다뤘다. ## 실용적인 활용 방향 - 반복되는 UI 요소는 Component로 만들고, 여러 객체를 한 번에 변환해 초기 구축 시간을 줄이는 것이 좋다. - 인스턴스에서 발견한 개선 사항은 로컬 컴포넌트의 Master에 반영해 디자인 시스템을 최신 상태로 유지할 수 있다. - 이미지 색상 추출이나 생성형 배치처럼 반복적이거나 계산이 필요한 작업은 플러그인으로 자동화할 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figmafigma-pluginscomponents+2
figma3분 읽기큐레이션 요약

Figma 워크플로우

Figma는 디자인 작업의 맥락과 팀별 상황에 따라 해답이 달라지는 문제를 사용자 간 대화로 해결할 수 있다고 보고, 온라인 포럼을 새롭게 개편했다. 개편의 핵심은 주제별 채널 구조, 명확한 커뮤니티 가이드라인, AMA와 라이브스트림 같은 참여형 콘텐츠다. 버그 신고와 기능 요청은 포럼 대신 지원 플랫폼으로 일원화해 더 신속하고 체계적으로 처리하도록 했다. ## 사용자 간 지식 공유를 강화하는 포럼 - 디자인 시스템, 개발자 핸드오프, 툴체인 구성처럼 정답이 하나로 정해지지 않은 문제는 일반적인 지원 문서만으로 해결하기 어렵다. - 사용자는 다른 디자이너의 실제 경험과 상황을 참고해 자신의 워크플로를 개선할 수 있다. - 포럼에서는 한 질문에 다양한 관점이 모이고, 그 논의가 질문자뿐 아니라 커뮤니티 전체에 유용한 지식으로 축적된다. - Figma는 오프라인 모임이나 트위터에서 자연스럽게 이뤄지던 교류를 온라인 포럼에서 더 쉽게 이어가려 했다. ## 실무 주제 중심의 새 채널 구조 - 기존 채널 일부를 보관하거나 이름을 변경하고, 실무 영역별로 대화를 집중할 수 있도록 새 채널을 추가했다. - **Design Systems** - 디자인 시스템의 모범 사례를 논의한다. - 팀별 Figma 라이브러리 구성 방식과 운영 경험을 공유한다. - 관련 자료와 리소스를 교환한다. - **Prototyping** - 프로토타이핑 기법과 활용 사례를 다룬다. - **API and Extensions** - Figma API와 확장 기능에 관한 질문과 정보를 공유한다. - **Workflow and Process** - 디자인 업무 프로세스와 협업 방식에 대해 논의한다. - **Open Design** - 진행 중인 작업물을 공개하고 피드백을 받을 수 있다. - 프로젝트에 참여할 다른 디자이너를 찾는 용도로도 활용할 수 있다. - 브라우저 기반 협업 도구라는 Figma의 특성을 커뮤니티 활동에 연결한 채널이다. - **Start Here** - 새 채널 구조, 커뮤니티 이용 가이드라인, 행동 강령 등 포럼 이용에 필요한 정보를 제공한다. ## 버그 신고와 기능 요청의 지원 플랫폼 이관 - 버그 신고와 기능 요청은 포럼에서 제거하고 Figma의 공식 지원 플랫폼으로 접수 경로를 통합했다. - 지원 채널을 이용하면 담당 팀이 사용자와 1:1로 문제를 진단할 수 있다. - 공개 포럼에서 공유하기 어려운 파일이나 계정 정보도 지원 과정에서 전달할 수 있다. - 지원팀은 접수된 버그와 요청을 적절한 담당자에게 전달하고 우선순위를 관리한다. - 지원팀은 제품팀 및 엔지니어링팀과 매주 논의하며, 사용자 피드백이 제품 개선 과정에 반영되도록 했다. ## 커뮤니티 참여형 콘텐츠 - 포럼을 단순한 질문·답변 공간이 아니라 지속적인 커뮤니티 활동의 장으로 확장하려 했다. - AMA(Ask Me Anything)를 통해 Figma 관계자나 전문가에게 직접 질문할 수 있다. - 라이브스트림 등 실시간 콘텐츠를 통해 사용자와의 소통을 강화한다. - 공식 안내와 사용자 간 자율적인 경험 공유를 함께 제공하는 구조를 지향한다. 실제로 이용할 때는 워크플로·디자인 시스템·프로토타이핑 관련 질문은 주제별 포럼에서 다른 사용자의 경험을 참고하고, 계정 정보나 파일이 필요한 버그 신고 및 기능 요청은 공식 지원 플랫폼을 이용하는 것이 가장 효율적이다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma프로토타이핑API+1
figma3분 읽기큐레이션 요약

깃허브, 협업 문화를

GitHub는 원격 협업 환경에서 디자인 시스템을 효율적으로 운영하기 위해 Figma를 도입했다. Figma와 API를 활용해 아이콘·UI 컴포넌트 제작 과정을 자동화하고, 디자이너와 개발자가 같은 파일에서 실시간으로 협업할 수 있게 했다. 그 결과 디자인 시스템은 GitHub의 일하는 방식에 핵심 요소로 자리 잡았고, 반복 작업과 협업 장벽을 줄이는 기반이 되었다. ## 디자인 시스템 전담 조직의 성장 - 2015년 당시 GitHub에는 디자인 시스템을 전담하는 직원이 없었다. - 디자이너들이 동일한 요소를 반복해서 만들고, 문서가 부족하며, 패턴이 오래된 문제가 있었다. - 이를 해결하기 위해 디자인 시스템과 문서화된 워크플로를 구축하는 풀뿌리 활동을 시작했다. - 활동 시작 6개월 만에 전담 팀이 만들어졌으며, 이후 7명 규모로 성장했다. - 전체 제품 디자인 팀 25명 중 7명이 재사용 가능하고 교체 가능한 컴포넌트를 관리하게 되었다. - 디자인 시스템은 GitHub의 디자인·개발 프로세스를 효율적이고 반복 가능하며 확장 가능하게 만드는 핵심 기반이 되었다. ## 기존 디자인 워크플로의 문제점 - 전담 팀을 구성해도 디자인 시스템을 만들고 유지하는 과정 자체가 비효율적이었다. - SVG 아이콘 라이브러리인 **Octicons**를 수정하려면 특정 소프트웨어 설치와 관련 도구에 대한 지식이 필요했다. - 이런 복잡한 설정은 기여자가 아이콘을 수정하거나 업데이트하는 일을 어렵고 혼란스럽게 만들었다. - 결과적으로 디자인 시스템에 참여하려는 사람들의 진입 장벽이 높아졌다. ## Figma와 API를 통한 기여 과정 자동화 - GitHub는 Octicons를 Figma로 이전하는 실험을 시작했다. - Figma는 별도의 소프트웨어를 다운로드하거나 설치하지 않아도 브라우저에서 작업할 수 있었다. - Figma API를 함께 사용해 아이콘 업데이트 과정을 자동화할 수 있었다. - 디자이너와 개발자는 운영체제나 도구에 관계없이 복잡한 설정 없이 디자인 시스템에 기여할 수 있게 되었다. - Octicons에서 얻은 효과를 바탕으로 UI 컴포넌트도 Figma로 이전했다. - 이후 GitHub의 디자인과 개발에 필요한 대부분의 요소를 Figma에서 이용할 수 있게 되었다. ## 원격 팀을 위한 ‘DesignHub’ - GitHub는 원래 도구에 구애받지 않는 팀이었지만, Figma 사용은 빠르게 확산되었다. - 웹 기반 협업 기능 덕분에 서로 다른 장소에서 일하는 팀원들이 같은 파일에 동시에 참여할 수 있었다. - Figma는 물리적으로 함께 모여 화이트보드 앞에서 작업하는 경험을 대체했다. - 디자이너들은 실제로 한 공간에 있는 팀처럼 아이디어를 공유하고 발전시킬 수 있었다. - 여러 디자이너가 Figma 파일에서 즉석으로 아이디어를 결합하는 ‘디자인 잼’을 진행하며 창의적인 탐색을 활성화했다. ## 프로토타이핑과 스토리텔링의 통합 - GitHub의 디자이너들은 Figma를 디자인 과정뿐 아니라 스토리텔링 전반에 활용했다. - 디자인은 사용자 경험의 이야기를 전달하는 과정이며, 프로토타입은 그 이야기를 실제 흐름으로 보여주는 수단으로 여겨졌다. - Figma에서는 다른 도구로 전환하지 않고 요소를 빠르게 배치하고 이동해 화면 흐름을 제안할 수 있었다. - 프로토타이핑의 진입 장벽이 낮아지면서 아이디어를 빠르게 표현하고 검증할 수 있었다. ## 협업 중심 문화와 도구의 결합 - GitHub는 기능과 도구가 모두 협업을 촉진해야 한다는 문화를 갖고 있다. - Figma는 디자이너와 엔지니어가 함께 작업하도록 설계된 도구라는 점에서 GitHub의 문화와 잘 맞았다. - 디자인 시스템을 단순한 결과물이나 라이브러리가 아니라 여러 직군이 함께 개선하는 협업 공간으로 발전시켰다. - 웹 기반 편집, 실시간 공동 작업, API 자동화를 조합해 원격 협업의 물리적 한계를 줄였다. GitHub 사례는 디자인 시스템의 효과를 높이려면 컴포넌트를 만드는 것뿐 아니라 누구나 쉽게 기여할 수 있는 워크플로를 함께 설계해야 한다는 점을 보여준다. 특히 웹 기반 협업 도구와 API 자동화를 결합하면 원격 팀에서도 디자인·개발 간 피드백과 반복 작업을 크게 줄일 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma프로토타이핑github+3
figma2분 읽기큐레이션 요약

DesignSystems.com을

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figmacomponent-librarydesign-ops+1
figma4분 읽기큐레이션 요약

Figma UI 개편:

Figma는 기능 구조를 크게 바꾸기보다 타이포그래피, 레이아웃, 색상, 아이콘 등 UI 표면을 다듬는 방식으로 시각적 리프레시를 진행했다. 기존 UI가 제품 성장에 따라 일관성을 잃고 한계에 부딪혔기 때문에, 전사적 브레인스토밍과 이슈 통합, 정성·정량 조사를 거쳐 변경 범위를 결정했다. 핵심은 모든 사용자를 만족시키려 하기보다 문제를 체계적으로 수집하고, 중요한 개선점에 집중하는 것이었다. ## 리디자인이 필요해진 배경 - Figma의 UI는 제품과 기능이 성장하면서 점점 일관성을 잃었다. - 기존 컴포넌트로 새로운 기능을 표현하기 어려워질 때마다 팀이 임시 컴포넌트와 맞춤형 해결책을 만들었다. - 그 결과 다음과 같은 문제가 누적됐다. - 서로 다른 형태의 테이블, 버튼, 입력 컨트롤 - UI 곳곳에 흩어진 여러 색조의 회색·빨강·파랑 - 기능마다 다른 알림과 대화상자 처리 방식 - 가독성, 여백, 아이콘 체계의 불일치 - 마지막으로 UI 전체를 검토했을 때는 아직 Multiplayer나 Components 같은 핵심 기능이 없었다. - 즉, 기존 UI의 기반이 현재의 Figma를 충분히 반영하지 못하게 된 것이 리프레시의 주요 배경이었다. ## 표면적 변화에 집중한 전략 - 목표는 사용자가 큰 혼란 없이 새 UI를 받아들이도록 만드는 것이었다. - 정보 구조나 제품의 기본 동작을 재설계하기보다는 다음과 같은 시각적 요소를 중심으로 개선했다. - 타이포그래피 - 레이아웃 - 색상 - 아이콘 - 컴포넌트의 시각적 일관성 - 출시 전 수개월 동안 정성적·정량적 조사를 진행했다. - 세부 변경 사항마다 여러 팀이 깊이 논의해 최종 결과에 동의하도록 했다. - 특히 디자이너는 시각적 변화에 민감하므로, 리디자인이 모든 사람에게 동일하게 환영받을 수 없다는 점도 고려했다. ## 1단계: 제한 없이 문제 수집하기 - 전체 디자인 팀이 참여하는 2시간 브레인스토밍 세션을 열었다. - 팀원들은 실제로 Figma를 사용하면서 제품의 구석구석을 살펴봤다. - 발견한 내용을 다음 방식으로 기록했다. - UI의 문제점과 불편한 점 - 마음에 드는 부분 - 관련 스크린샷 - 특정 문제가 미치는 영향에 대한 메모 - 모든 결과물을 Figma 파일에 모아 공동으로 검토했다. - 팀원들이 강하게 반응한 문제, 즉 모두가 “이건 심각하다”고 느낀 항목을 별도로 표시했다. - 이 반응은 어떤 문제가 사용자 경험에 큰 영향을 줄 가능성이 있는지 판단하는 초기 신호로 활용됐다. - 브레인스토밍 직후 결론을 내리지 않고 며칠간 거리를 둔 것도 중요했다. 시간이 지나면서 문제의 우선순위와 구성원들의 의견이 자연스럽게 바뀌었기 때문이다. ## 2단계: 문제를 통합하고 범주화하기 - 후속 회의에서 각 문제를 다시 검토하며 처음의 판단을 재평가했다. - 일부 문제는 생각보다 중요하지 않다고 판단했고, 다른 문제는 해결 필요성을 더 강하게 주장할 수 있도록 논거를 보완했다. - 긴 문제 목록을 팀원들에게 나누어 전달하고, 각자가 이를 포스트잇 형태의 짧은 항목으로 재작성했다. - 이 과정에서는 개별적인 증상을 그대로 옮기기보다 공통된 근본 문제로 추상화했다. - 예: “특정 화면의 알림 모양이 다르다” - 통합된 표현: “제품 전체의 알림 처리 시스템이 필요하다” - 비슷한 포스트잇을 함께 묶어 반복적으로 나타나는 주제를 확인했다. - 그 결과 다음과 같은 범주가 도출됐다. - 아이콘, 타이포그래피, 가독성, 색상 - 대화상자, 툴바, 말투 - 에디터와 파일 브라우저 - 모드, 팀 페이지, 속성 사이드바 - 컴포넌트, 레이어, 히스토리 - 공유, 퍼블리싱, 내보내기 - 포스트잇의 반복은 단순한 중복이 아니라 중요한 문제가 여러 방식으로 나타나고 있다는 신호가 되었다. - 다만 범주를 다시 “시각적 문제에서 기초 구조적 문제까지”라는 축으로 정렬하려 한 것은 지나치게 복잡한 접근이었다. ## 범주화 과정에서 얻은 교훈 - 문제를 조직화할 때 지나치게 추상적인 기준을 만들면 오히려 판단이 어려워진다. - “제품의 개성”처럼 거의 모든 문제를 포함할 수 있는 범주는 유용하지 않다. - 반대로 특정 대화상자 하나처럼 지나치게 좁은 범주도 전체적인 개선 방향을 잡는 데 적합하지 않다. - 가장 좋은 범주는 서로 비슷한 문제를 묶으면서도, 실제 개선 작업으로 이어질 수 있을 만큼 구체적이어야 한다. - 완벽한 분류 체계를 만드는 것보다 중요한 문제의 신호를 잡음에서 분리하는 것이 우선이다. ## 실무에 적용할 때의 추천 - 리디자인을 시작할 때 바로 해결책을 만들기보다, 먼저 팀 전체가 제품을 직접 사용하며 문제를 폭넓게 수집한다. - 각 문제를 개별 사례가 아닌 반복되는 시스템적 문제로 재정의한다. - 브레인스토밍 직후 결론을 확정하지 말고 일정한 숙고 시간을 둔다. - 범주화는 단순하고 이해하기 쉽게 유지하며, 지나치게 추상적이거나 복잡한 분류 축은 피하는 것이 좋다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma사용자 경험사용자 인터페이스+2
figma3분 읽기큐레이션 요약

#FigmaTip 모

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figmacomponent-librariesregular-expressions+1
figma3분 읽기큐레이션 요약

디자인 시스템 전파의

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figma접근성CSS+4
figma3분 읽기큐레이션 요약

Dribbble이 원격 팀

Dribbble은 완전 원격으로 일하는 디자인팀의 협업 문제를 Figma로 해결했다. 여러 도구와 파일을 오가던 방식을 하나의 온라인 파일과 실시간 공동 편집으로 통합해, 최신 디자인을 공유하고 피드백을 주고받는 과정을 단순화했다. 그 결과 디자인 페어 작업과 리뷰가 빨라졌고, 아이디어를 며칠이 아니라 수십 분 안에 구체화할 수 있었다. ## 여러 시간대에 걸친 원격 협업의 어려움 - Dribbble은 전 직원이 100% 원격으로 근무하며, 디자인팀은 제품 디자이너와 개발자 7명으로 구성되어 있다. - 원격 근무는 유연성과 인재 확보 측면에서 장점이 있지만, 사무실에서 자연스럽게 대화하는 방식의 협업은 어려웠다. - 팀은 화상회의와 여러 협업 도구를 함께 사용했지만, 작업 방식이 매끄럽게 연결되지 않았다. - 다른 디자이너의 작업 현황을 파악하기 어려웠고, 파일 관리와 다양한 피드백 흐름을 정리하는 데 시간이 소요됐다. ## Figma를 통한 단일 작업 공간 - Figma에서는 여러 사람이 동시에 하나의 파일에 접속해 회의실이나 화이트보드에서 함께 작업하는 경험을 재현할 수 있었다. - 온라인 기반이므로 최신 파일을 찾기 위해 동료에게 묻거나 여러 애플리케이션을 전환할 필요가 줄었다. - 디자인 파일, 버전 관리, 댓글, 리뷰를 한곳에서 처리해 팀의 ‘단일 진실 공급원(single source of truth)’을 마련했다. - 기존 디자인 파일 형식을 가져올 수 있어 새로운 도구로의 전환 부담도 낮췄다. - Dribbble은 기존 사용자 인터페이스를 Figma에서 다시 제작해 팀원들이 익숙한 구성 요소로 학습하도록 했다. ## 디자인 페어와 실시간 공동 작업 - Dribbble은 두 명의 디자이너가 함께 문제나 프로젝트를 해결하는 디자인 페어 방식을 활용한다. - 하나의 파일에서 동시에 작업하면서 도구 간 전환과 파일 주고받기에 드는 마찰을 제거했다. - 최신 변경 사항을 모든 팀원이 즉시 확인할 수 있어 커뮤니케이션 비용과 중복 작업이 감소했다. - 여러 사람이 스타일 가이드를 참고하거나 같은 디자인을 반복 수정해야 하는 대규모 작업에서도 일관성을 유지하기 쉬웠다. ## 더 빠른 디자인 리뷰와 피드백 - Figma의 멀티플레이어 기능을 활용해 모든 디자이너가 같은 파일에서 디자인 리뷰를 진행했다. - 팀원들은 프레임을 복제해 아이디어를 발전시키고, 댓글을 남기며, 실시간으로 수정 사항을 반영했다. - 피드백 루프가 짧아져 디자인 문제를 며칠이 아니라 몇 분 만에 해결할 수 있었다. - 한 사례에서는 화상회의 중 5명이 하나의 Figma 파일에 참여해 아이디어를 브레인스토밍하고 서로의 안을 비평했으며, 약 20분 만에 합의된 디자인을 완성했다. ## Figma와 Dribbble의 연동 - Dribbble은 Figma API를 활용해 작업물을 Figma에서 Dribbble로 직접 공유하는 통합 기능을 만들었다. - 사용자는 Figma에서 레이어를 선택한 뒤 `Integrations` ▸ `Dribbble`을 통해 Dribbble 업로드 화면으로 이동할 수 있다. - 이를 통해 디자인 제작과 게시 사이의 절차도 하나의 작업 흐름으로 연결했다. ## 실용적인 시사점 - 원격 디자인팀에는 화상회의만으로는 부족하며, 실시간 공동 편집과 최신 파일을 보장하는 중앙 작업 공간이 필요하다. - 도구를 통합하면 파일 관리와 커뮤니케이션에 쓰는 시간을 줄이고 디자인 자체에 집중할 수 있다. - 기존 자산을 가져오고 익숙한 UI를 재현하는 방식은 협업 도구 도입 시 팀의 학습 부담을 줄이는 효과적인 방법이다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figmareal-time-collaborationremote-collaboration+3
figma3분 읽기큐레이션 요약

피그마 드래프트

Figma Drafts는 완성된 결과물을 공유하기 전, 아이디어를 자유롭게 실험하는 개인 작업 공간이다. 글쓴이는 공개 협업 환경에서 파일의 완성도나 정리 상태를 평가받을까 하는 두려움을 Drafts로 완화했고, 이를 디지털 노트처럼 활용했다. 핵심 원칙은 먼저 만들고 나중에 정리하며, 발전시킬 아이디어만 프로젝트로 옮기는 것이다. ## 공개 협업에서 생기는 부담 - 다른 사람이 작업 중인 파일을 볼 수 있으면 다음과 같은 걱정이 생길 수 있다. - 8px 그리드를 지키지 않았다는 평가 - 레이어 이름을 정리하지 않았다는 지적 - 아이콘을 만드는 과정이나 파일 구조가 미숙해 보일 가능성 - 이 부담 때문에 실제 문제 해결이나 다양한 시도보다 파일을 “보여줄 만한 상태”로 꾸미는 데 시간을 쓰게 된다. - 글쓴이는 이러한 두려움이 공개적이고 협력적인 디자인 환경에서 더 커졌다고 설명한다. ## Drafts의 역할과 장점 - Drafts는 팀이나 프로젝트와 마찬가지로 파일을 보관하는 조직 단위지만, 개인 폴더라는 점이 다르다. - 팀이나 프로젝트의 권한 및 공유 설정에 종속되지 않는다. - Drafts 전체를 다른 사람에게 공개할 수는 없고, 필요한 경우 개별 파일만 선택적으로 공유할 수 있다. - 완성품이 아니라는 의미가 이름에 내포되어 있어, 실험과 미완성 작업을 심리적으로 허용한다. - 디자이너의 블록을 극복하고 색상, 타이포그래피, 화면 흐름 등을 정하기 전에 우선 아이디어를 시각화하는 공간으로 활용할 수 있다. - 글쓴이는 Drafts를 낙서, 스케치, 미완성 목록이 섞여 있는 개인 노트의 디지털 버전으로 사용한다. ## “먼저 만들고, 나중에 정리하기” - Drafts에서는 iOS 앱 아이디어나 Figma 기능을 활용한 실험처럼 빠르게 떠오른 생각을 즉시 기록한다. - 파일 이름이 없거나, 기본 회색 도형만 있거나, 구조가 엉성해도 문제로 보지 않는다. - 중요한 원칙은 **Create first, organize second**이다. - 먼저 다양한 해결책을 시도한다. - 아이디어가 발전한 뒤 파일명, 레이어, 구성 등을 정리한다. - 초기 단계에서 정리와 완성도를 지나치게 신경 쓰면 탐색의 폭이 줄어들 수 있으므로, Drafts에서는 혼란스러운 상태를 작업 과정의 일부로 받아들인다. ## Drafts를 프로젝트로 옮기는 방법 - 아이디어가 더 발전해 팀과 공유하거나 체계적으로 관리해야 할 시점이 되면 Drafts 파일을 프로젝트로 이동한다. - 파일 브라우저에서 파일을 선택한 뒤 원하는 프로젝트로 드래그 앤 드롭하면 된다. - 파일 내부에서 파일명 왼쪽의 “Drafts” 메뉴를 클릭하고 이동할 프로젝트를 선택할 수도 있다. - 예를 들어 와이어프레임을 고해상도 화면으로 발전시키려는 경우, 전체 파일을 프로젝트로 옮기는 방식이 적절하다. ## 원본 보존과 반복 작업 - 아이디어를 여러 페이지나 파일에서 계속 발전시킬 예정이라면, 먼저 Drafts 파일을 복제한다. - 복제본은 Drafts에 남겨 초기 아이디어의 스냅샷으로 보존한다. - 복제한 파일을 프로젝트로 옮겨 팀 작업이나 정리 작업을 진행한다. - Drafts에는 정리되지 않은 원본을 유지하고, 프로젝트 파일에서는 실제 작업에 필요한 요소를 다듬는 방식이다. ## 파일 관리와 검색 - Drafts가 많아지면 파일 브라우저의 필터 기능을 활용할 수 있다. - 파일명, 생성일, 마지막 수정일 등을 기준으로 파일을 찾고 정렬할 수 있다. - 다만 정리 자체를 너무 일찍 시작하기보다, 아이디어가 충분히 발전한 뒤 필요한 파일만 프로젝트로 옮기는 흐름이 권장된다. 개인 작업에서는 Drafts를 “공개 전 검수 공간”이 아니라 자유롭게 실패하고 탐색하는 디지털 스케치북으로 사용하는 것이 좋다. 완성도와 정리는 아이디어가 검증된 뒤에 진행하고, 팀 공유가 필요해졌을 때 파일을 복제하거나 프로젝트로 이동하면 창의성과 협업을 모두 확보할 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma프로토타이핑collaborative-design+2
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 컴포넌트 모음이 아니라, 디자인·개발·리서치·콘텐츠가 함께 일하는 협업 기반으로 구축해야 한다는 점을 보여준다. 먼저 제품 간 불일치를 시각화하고, 명확한 원칙을 정한 뒤, 작은 패턴부터 라이브러리화해 점진적으로 확장하는 접근이 실용적이다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma사용자 경험프로토타이핑+2
figma3분 읽기큐레이션 요약

피그마, 세쿼이아

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는 이번 투자를 바탕으로 기업용 협업 기능과 제품 품질을 강화하는 동시에, 확장 가능한 플랫폼과 글로벌 사용자 커뮤니티를 구축하려 한다. 기업이나 팀에서 디자인 협업 도구를 선택할 때는 실시간 공동 작업뿐 아니라 조직 관리, 디자인 시스템, 확장성, 커뮤니티 생태계까지 함께 고려할 필요가 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figmacollaborationdesign-tools+2