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

FigJam에 도입된 오픈 플랫폼의

FigJam은 Figma의 개방형 플랫폼을 확장해 플러그인과 위젯을 누구나 만들 수 있도록 지원한다. 플러그인은 반복 작업과 데이터 처리를 자동화하고, 위젯은 투표·설문·게임처럼 여러 사용자가 동시에 상호작용하는 협업 경험을 제공한다. 두 API 모두 JavaScript·HTML 또는 React 지식을 바탕으로 쉽게 시작할 수 있도록 설계되었다. ## Figma 플러그인에서 FigJam으로 확장 - Figma는 약 2년 전부터 플러그인을 통해 외부 데이터 연동, 워크플로 자동화, 디자인 프로세스 개선을 지원했다. - 핵심 원칙은 “웹사이트를 만들 수 있다면 플러그인도 만들 수 있어야 한다”는 것이다. - 따라서 기본적인 JavaScript와 HTML 지식만으로도 플러그인 개발을 시작할 수 있도록 API의 진입장벽을 낮췄다. - FigJam에도 같은 개방형 플랫폼 원칙을 적용하되, 협업 중심의 사용 사례를 추가로 고려했다. ## 플러그인과 위젯의 역할 차이 - **플러그인** - 개인 또는 팀의 작업 흐름을 자동화한다. - CSV 데이터를 스티키 노트 격자로 변환하거나, 스티키 노트에 태그를 붙이는 작업 등을 처리할 수 있다. - 보드의 객체를 정리·분석하거나 외부 콘텐츠를 가져오는 데 적합하다. - **위젯** - FigJam 보드에 직접 배치해 여러 사용자가 함께 조작하는 인터랙티브 객체다. - 투표, 설문, 게임 등 협업형 기능을 구현할 수 있다. - 사용자가 보드에 드래그 앤 드롭해 사용할 수 있다. ## React 기반의 선언형 위젯 API - 위젯 API는 플러그인 API와 달리 선언적·함수형 방식으로 설계되었다. - `<Frame />`, `<Rectangle />`, `<Text />`, `<SVG />` 같은 컴포넌트로 위젯의 화면 구조를 정의한다. - 클릭 이벤트와 같은 사용자 상호작용에 임의의 코드를 연결할 수 있다. - FigJam의 기본 객체처럼 인라인 속성 메뉴도 제공할 수 있다. - React 컴포넌트와 유사한 구조를 사용하며, 컴포넌트 속성은 CSS의 레이아웃·스타일 속성과 비슷하다. - 예시 카운터 위젯은 다음 방식으로 동작한다. - `useSyncedState('count', 0)`으로 여러 사용자에게 동기화되는 상태를 만든다. - 사용자가 숫자를 클릭하면 `setCount(count + 1)`을 호출해 값을 증가시킨다. - `Frame`으로 자동 레이아웃과 패딩을 지정하고, `Text`로 현재 값을 표시한다. - `widget.register(SimpleCounter)`로 위젯을 등록한다. ## FigJam 플러그인의 주요 활용 분야 ### 보드 정리와 인사이트 도출 - 보드의 객체를 체계적으로 정리하고 분석할 수 있다. - 스티키 노트를 색상별로 정렬하거나 카테고리용 태그를 추가할 수 있다. - 스티키 노트의 내용을 분석해 워드 클라우드처럼 주제를 시각화할 수 있다. - 투표 수를 자동으로 집계하는 스탬프 카운터 플러그인도 활용 사례로 제시된다. - 텍스트를 입력하면 여러 개의 스티키 노트를 자동 생성하는 플러그인도 소개된다. ### 반복 작업 자동화 - 맞춤법 검사, 찾기 및 바꾸기 같은 수작업을 줄일 수 있다. - 동일한 스타일의 스티키 노트 100개를 한 번에 만드는 등 반복적인 작업을 자동화할 수 있다. - 사용자는 여러 단계를 직접 수행하는 대신 몇 번의 클릭만으로 작업을 완료할 수 있다. - Figma에서 사용되던 맞춤법 검사 플러그인을 FigJam으로 확장하는 사례가 언급된다. ### 콘텐츠 라이브러리 연동 - 외부 서비스나 라이브러리의 콘텐츠를 FigJam 보드로 가져올 수 있다. - 아이콘, 이모지, 회사 로고 등을 빠르게 삽입하는 플러그인을 만들 수 있다. - Icons8, Material Design, Iconify, Brandfetch 등 기존 Figma 콘텐츠 플러그인의 FigJam 확장이 사례로 제시된다. - 이를 통해 FigJam 사용자는 별도의 검색·복사 과정 없이 보드 안에서 필요한 시각 자료를 활용할 수 있다. ### 사용자 맞춤 설정 - 사용자가 원하는 색상, 폰트, 텍스트 스타일 등을 선택할 수 있는 기능도 플러그인 활용 분야로 제시된다. - FigJam은 기본적으로 폰트와 색상 체계를 단순하게 유지하지만, 사용자 요구에 따른 커스터마이징 수요가 존재한다. ## 실용적인 시사점 FigJam에서 자동화가 필요하면 플러그인을, 여러 사람이 동시에 조작하는 기능이 필요하면 위젯을 선택하는 것이 적합하다. 특히 React에 익숙한 개발자는 FigJam 레이어와 CSS와 유사한 컴포넌트 구조를 활용해 비교적 빠르게 인터랙티브 협업 도구를 만들 수 있다.

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

HTMLfigjamReactJavaScript+4

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

Tailwind UI 공식 피그

Tailwind Labs는 Tailwind UI의 코드 컴포넌트를 디자이너와 개발자가 함께 사용할 수 있는 공식 Figma 키트로 재구성했다. 약 1,400개의 컴포넌트와 10,000개의 요소를 제작하면서, 최종 코드 구조를 디자인 파일의 기준으로 삼고 레이어 이름·구조·변형을 체계화했다. 핵심 결론은 디자인 시스템을 실제 제품처럼 배포하려면 시각적 완성도뿐 아니라 일관된 구조와 사용성까지 세밀하게 설계해야 한다는 것이다. ## Tailwind UI Figma 키트 제작 배경 - Tailwind UI는 Tailwind CSS 기반의 반응형 HTML 컴포넌트 모음이다. - 고객들의 Figma 파일 요청이 지속적으로 늘어나 공식 Figma 키트를 제작하게 됐다. - 400개가 넘는 코드 컴포넌트를 바탕으로 1,400개 이상의 Figma 컴포넌트와 10,000개의 개별 요소를 구축했다. - 일반적인 작업용 디자인 파일과 달리, 상용 디자인 키트는 파일 자체가 최종 제품이므로 모든 세부 요소가 사용자 경험에 영향을 준다. ## 디자인 파일을 코드의 구조에 맞추기 - 최종 HTML 코드가 디자인 파일이 따라야 할 픽셀 단위 기준이 되도록 했다. - Figma의 오토 레이아웃, 레이아웃 그리드, 레이아웃 제약 조건을 활용해 HTML 마크업과 유사한 레이어 구조를 만들었다. - 디자인과 코드가 비슷한 구조를 가지면 디자이너와 개발자가 레이아웃 가능성을 공통으로 이해할 수 있다. - 반복되는 반응형 패딩이나 중앙 정렬된 최대 너비 컨테이너 같은 패턴을 디자인 파일에서 발견하고, 이를 개발자가 재사용 가능한 컨테이너 구조로 구현할 수 있었다. ## 일관된 레이어 이름 - 모든 레이어에 일관된 명명 규칙을 적용했다. - 예를 들어 버튼의 텍스트 레이어를 항상 `Text`로 지정하면, 버튼 크기나 변형을 바꿔도 사용자가 입력한 텍스트가 그대로 유지된다. - 복잡한 컴포넌트에서도 아이콘, 제목, 본문, 링크 등의 사용자 지정 내용이 다른 인스턴스나 변형으로 교체할 때 보존된다. - 일관된 레이어 이름은 단순한 정리 규칙이 아니라 Figma의 오버라이드 동작을 안정적으로 만드는 기반이다. ## 변형으로 컴포넌트 수 줄이기 - 여러 개의 유사한 컴포넌트를 개별적으로 관리하는 대신, 하나의 컴포넌트에 다양한 변형을 정의했다. - 예를 들어 80개의 배지 컴포넌트를 따로 만드는 대신 `type`, `size`, `theme`, 보조 요소 등의 속성을 가진 하나의 Badge 컴포넌트를 구성했다. - 코드 컴포넌트에서 사용하는 속성과 Figma의 변형 속성에 동일한 이름과 개념을 사용해 디자인과 개발 사이의 대응 관계를 명확히 했다. - 여러 컴포넌트에서 반복적으로 사용할 수 있는 변형 이름은 다음과 같다. - `type` - `size` - `theme` - `position` - `breakpoint` - `state` - 변형 패널 자체가 컴포넌트의 가능한 상태와 옵션을 설명하는 문서 역할을 한다. - 최종 키트에는 평균 7개의 변형을 가진 1,430개 컴포넌트가 포함됐다. - 변형을 사용하지 않았다면 컴포넌트 수가 10,000개를 넘었겠지만, 변형 덕분에 실제 코드 컴포넌트 수인 약 400개에 가까운 수준으로 관리할 수 있었다. ## 실용적인 결론 상용 Figma 키트를 만들 때는 화면을 예쁘게 복제하는 것보다 코드와 디자인의 구조를 일치시키는 일이 중요하다. 레이어 이름과 변형 속성을 처음부터 표준화하고, 반복되는 레이아웃 규칙을 컴포넌트 구조에 반영하면 사용자는 더 쉽게 커스터마이즈할 수 있고 디자인·개발 간 협업도 효율적으로 유지할 수 있다.

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

HTMLFigma디자인 시스템CSS+3

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

기능 비하인드: 새로운

Figma의 새 Auto Layout은 수동으로 요소 크기와 간격을 조정하던 작업을 자동화하면서도, CSS Flexbox의 강력함을 그대로 복잡하게 노출하지 않는 방향으로 설계됐다. 핵심 원칙은 “Flexbox의 신중한 부분집합”으로, 코드와 디자인의 정렬을 돕되 누구나 쉽게 이해하고 사용할 수 있게 만드는 것이었다. 새 버전은 사용자 피드백을 바탕으로 유연성과 기능을 확장한 결과다. ## 수동 리사이징 문제에서 출발한 Auto Layout - Auto Layout 출시 전에는 버튼의 텍스트가 길어지면 다음 작업을 직접 해야 했다. - 버튼 크기 조정 - 주변 버튼 위치 이동 - 대화상자 컨테이너 크기 조정 - 패딩과 간격 재조정 - 이런 수작업은 단순히 번거로운 것을 넘어 반응형 디자인 시스템 구축의 장애물이 됐다. - Figma 초기 설계에도 프레임 내부 객체를 자동으로 배치하는 아이디어가 있었지만, 제품 출시 당시에는 구현되지 않았다. - 2018년 Maker Week에서 제품 디렉터 Sho가 초기 아이디어를 다시 프로토타입으로 발전시켰고, 이후 전담 팀이 Auto Layout을 실제 기능으로 구현하기 시작했다. ## Flexbox를 참고하되 단순하게 설계 - 팀은 웹 기술인 CSS Flexbox의 강력함과 범용성에서 영감을 얻었다. - 디자인과 코드 사이의 개념적 일치를 높이려면 Flexbox와 유사한 모델이 유리했다. - 그러나 사용자가 브라우저와 CSS를 깊이 이해해야 한다면 Figma의 접근성이 떨어질 수 있었다. - 이에 따라 “Auto Layout은 Flexbox의 신중한 부분집합이어야 한다”는 설계 원칙을 세웠다. - 이 원칙은 기능을 추가하면서도 설정 항목과 동작 규칙을 불필요하게 복잡하게 만들지 않도록 팀의 의사결정을 이끌었다. ## 첫 번째 Auto Layout의 핵심 개념 - 프레임에 Auto Layout을 적용하면 내부 요소를 수직 또는 수평으로 배치할 수 있다. - 요소 사이의 수직·수평 간격을 지정할 수 있다. - Auto Layout 프레임은 기본적으로 주축 방향에서 내부 컴포넌트 크기에 맞춰 늘어나거나 줄어든다. - 반대축 방향도 고정 너비 또는 내부 콘텐츠에 맞추는 방식으로 설정할 수 있다. - 프레임 내부의 각 컴포넌트는 컨테이너 기준으로 개별 정렬할 수 있다. - 수직 레이아웃에서는 좌·중앙·우 정렬 - 수평 레이아웃에서는 상·중앙·하 정렬 ## HTML 프로토타입과 초기 검증 - Auto Layout 디자이너 Marcin은 처음부터 HTML로 프로토타입을 제작했다. - 실제 웹 환경과 유사한 프로토타입을 통해 기능의 사용감과 동작을 조기에 확인할 수 있었다. - 이 과정에서 다음과 같은 세부 동작을 구체화했다. - 프레임 핸들의 시각적 장식 - 객체를 드래그할 때의 동작 - Auto Layout 프레임의 외곽선 표시 - 초기 프로토타입은 기능 목록을 정하는 데 그치지 않고, 편집기에서 사용자가 기능을 어떻게 인식하고 조작할지 검증하는 역할을 했다. ## 기능 확장과 사용성 사이의 균형 - 초기 Auto Layout은 접근성과 직관성을 우선해 설계됐다. - 이후 사용자 피드백을 반영하면서 더 강력하고 유연한 레이아웃 기능을 추가했다. - 다만 유연성을 높일수록 설정과 예외 상황이 늘어나 사용성이 떨어질 수 있으므로, 기능의 범위를 의도적으로 제한했다. - 새 버전은 단순한 UI 변경이 아니라, 초기의 단순한 모델을 유지하면서 더 다양한 반응형 레이아웃 요구를 수용하려는 설계 개선이다. Auto Layout을 설계할 때는 Flexbox처럼 검증된 레이아웃 모델을 참고하되, 사용자가 모든 내부 규칙을 학습하지 않아도 되도록 핵심 개념만 제공하는 것이 중요하다. 또한 실제 편집 환경을 반영한 프로토타입과 사용자 피드백을 통해 기능의 유연성과 조작의 직관성을 함께 검증해야 한다.

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

HTMLFigma디자인 시스템CSS+3

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

오토 레이아웃

Figma의 Auto Layout은 자유로운 디자인 탐색과 HTML/CSS·SwiftUI 같은 개발 환경의 구조적 레이아웃 장점을 결합한 기능이다. 텍스트나 콘텐츠가 바뀌면 버튼과 주변 요소의 크기·위치가 자동으로 조정되어 반복적인 수작업을 줄인다. 또한 프레임 중첩을 통해 콘텐츠에 반응하는 복잡한 인터페이스와 재사용 가능한 컴포넌트를 만들 수 있다. ## 디자인과 개발 환경의 간극 - Figma의 기존 자유 배치 방식은 창의적인 탐색에는 유리하지만 반복 작업이 많았다. - 버튼 문구를 수정하려면 텍스트 편집, 버튼 크기 조정, 인접 버튼 이동을 각각 수행해야 했다. - HTML/CSS나 SwiftUI는 객체 간 구조와 관계를 표현하므로 콘텐츠 변경에 강하지만, 자유로운 시각적 실험에는 불편하다. - Auto Layout은 CSS 박스 모델, 특히 flexbox의 핵심 개념을 Figma에 도입해 두 환경의 장점을 결합했다. - 프레임의 속성으로 제공되므로 컴포넌트뿐 아니라 일반 프레임에도 적용할 수 있다. ## 콘텐츠에 따라 자동으로 변하는 레이아웃 - Auto Layout을 적용하면 내부 요소가 가로 또는 세로 방향으로 순서대로 배치된다. - 컨테이너의 크기는 내부 요소들의 전체 크기에 맞춰 자동으로 결정된다. - 프레임 자체에 패딩, 채우기, 선, 모서리 반경을 설정할 수 있어 버튼 제작에 별도 레이어가 필요하지 않다. - “Buy”를 “Add to basket”으로 변경하면 버튼이 텍스트 길이에 맞춰 자동으로 늘어난다. - 인접한 버튼이나 요소도 레이아웃 흐름에 맞춰 함께 이동한다. - 요소 간 간격은 개별 요소가 아니라 컨테이너 수준에서 설정된다. 특정 요소 사이만 다르게 조정하려면 추가 작업이 필요하다. ## 리스트와 메뉴의 자동 재정렬 - 반복되는 UI 요소를 배치하는 리스트와 메뉴 제작에 특히 유용하다. - 요소를 드래그해 순서를 바꾸면 나머지 요소가 자동으로 재배치된다. - 항목을 하나씩 올바른 위치로 옮기던 반복적인 클릭 작업을 줄일 수 있다. - 기존 컴포넌트 라이브러리와 디자인 시스템에도 적용할 수 있으며, `Shift + A` 또는 옵션 메뉴에서 활성화할 수 있다. ## 중첩 프레임으로 복잡한 인터페이스 구성 - 여러 Auto Layout 프레임을 HTML의 중첩된 `div`처럼 조합할 수 있다. - 버튼, 카드, 리스트, 화면 전체를 계층적으로 구성하면서 각 영역이 콘텐츠 변화에 반응하도록 만들 수 있다. - 콘텐츠를 수정하거나 요소를 다른 Auto Layout 프레임 안팎으로 이동하기 쉽다. - 의도하지 않은 배치를 막기 위해 큰 이미지를 버튼 안에 넣는 등의 작업에는 안전장치가 작동한다. - 실제로 원하는 작업이라면 macOS에서는 `Command`, Windows에서는 `Ctrl` 키를 눌러 안전장치를 무시할 수 있다. - 콘텐츠 변형마다 별도 컴포넌트를 만들기보다, 다양한 콘텐츠를 수용하는 범용 컴포넌트를 제작할 수 있다. ## 향후 발전 방향 - Figma는 Auto Layout을 첫 출시로 보고, 향후 더 많은 기능을 추가할 계획이라고 밝혔다. - 사용자는 플레이그라운드 파일, 동영상, 공식 문서를 통해 기능을 학습할 수 있다. - 기능 사용 후 피드백과 개선 요청을 공유하도록 독려했다. 실무에서는 텍스트 길이가 달라지는 버튼, 반복 목록, 카드와 메뉴처럼 콘텐츠 변화가 잦은 UI부터 Auto Layout을 적용하는 것이 효과적이다. 이후 프레임을 중첩해 디자인 시스템 전반을 반응형이고 재사용 가능한 구조로 확장할 수 있다.

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

HTMLFigma디자인 시스템반응형 디자인+3

figma·2019년 9월 5일·4분 읽기큐레이션 요약

5명의 플러그인 개발자가

Figma의 첫 Plugin Show & Tell은 커뮤니티 개발자들이 제작 중인 플러그인을 직접 시연하고, 새로운 기능과 개발 방향을 공유하는 라이브 행사였다. 디자인 시스템 검사, 맞춤법 검사, 아이콘 관리, 문서 연결, 음성 제어 등 플러그인이 Figma의 작업 자동화와 확장성을 크게 넓힐 수 있음을 보여준다. 글은 행사를 소개하는 데 그치지 않고, 더 많은 개발자가 Figma Plugin API에 참여하도록 관련 자료와 커뮤니티를 안내한다. ## Plugin Show & Tell의 목적 - Figma 플러그인 커뮤니티의 창의적인 작업을 소개하기 위해 처음 개최된 라이브 스트리밍 행사다. - 개발자들이 플러그인을 홍보하고, 사용자가 새로운 API와 활용 방법을 탐색하도록 돕는 것이 목적이다. - 완성된 플러그인뿐 아니라 개발 중인 기능과 향후 로드맵도 공유했다. - 녹화 영상에서는 5명의 개발자가 디자인 시스템 검사부터 Figma 음성 제어까지 다양한 사례를 시연했다. ## 디자인 시스템과 품질 관리 자동화 - Toybox의 Jono Kolnik은 개발 중인 **Roller**를 소개했다. - Roller는 디자인을 디자인 시스템과 비교해 오류와 불일치를 찾고 수정하도록 돕는다. - 반복적인 수동 검수 대신 플러그인이 디자인 규칙을 검사함으로써 일관성을 유지할 수 있다. - 디자인 시스템이 커질수록 색상, 간격, 컴포넌트 사용 규칙을 자동으로 점검하는 도구의 가치가 커진다. ## 맞춤법 검사와 외부 서비스 연동 - Tekeste Kidanu는 Figma 안에서 사용하는 **Spell Check** 플러그인을 시연했다. - 프로젝트의 텍스트를 검사해 디자인 문서의 오탈자를 줄이는 데 활용할 수 있다. - 자신의 서비스인 **Cleanmock**을 Figma 내부에서 사용할 수 있도록 연동한 사례도 소개했다. - 플러그인은 Figma 캔버스뿐 아니라 브라우저 API와 외부 서비스까지 연결하는 확장 지점이 될 수 있다. ## 대규모 아이콘 세트 관리 - Vjacheslav Trushkin은 **Iconify** 플러그인과 향후 계획을 공유했다. - Iconify를 사용하면 수백 개의 아이콘 세트를 Figma와 실제 제품 개발 과정에서 함께 활용할 수 있다. - 디자인 단계에서 선택한 아이콘을 production 환경까지 일관되게 연결하는 워크플로를 지향한다. - 방대한 아이콘 라이브러리를 검색하고 관리하는 문제를 플러그인으로 단순화한다. ## 검색·문서화·레이아웃 작업 개선 - Jackie Chui는 여러 생산성 플러그인의 개선 사항을 소개했다. - **Find & Replace**는 Figma 문서 안의 내용을 빠르게 검색하고 바꾸는 기능을 제공한다. - **Link to Documentation**은 컴포넌트에 관련 문서 링크를 추가해 디자인과 가이드 문서를 연결한다. - **Paste to Fill**은 붙여넣은 이미지를 이미지 채우기로 적용한다. - 프레임 안 오브젝트의 여백과 크기를 관리하는 플러그인은 사용자 지정 프리셋을 지원할 예정이었다. - 이러한 도구들은 반복적인 레이아웃 조정과 문서 탐색 작업을 줄이는 데 초점을 둔다. ## 타이포그래피 규칙과 음성 인터페이스 - Andrew Goodwin은 타이포그래피 규칙을 선택하고 적용하는 플러그인을 선보였다. - 사용자가 정해진 글꼴, 크기, 행간 등의 규칙을 적용해 텍스트 스타일을 일관되게 관리할 수 있다. - Figma를 음성 명령으로 조작하는 음성 UI도 시연했다. - Figma Plugin API의 기능 대부분을 음성 명령으로 매핑하는 작업이 거의 완료 단계라고 설명했다. - 이는 플러그인이 시각적 UI를 넘어 새로운 입력 방식과 접근성 기능까지 제공할 수 있음을 보여준다. ## 플러그인 개발을 위한 생태계 - Figma는 플러그인 개발을 시작할 수 있도록 다음 자료를 제공했다. - 플러그인의 기본 구조와 개발 환경 설정을 설명하는 Getting Started 문서 - 캔버스와 상호작용하는 공식 Plugin API 문서 - Figma UI와 유사한 HTML·JavaScript·CSS 기반의 Figma Plugin DS - 오픈소스 플러그인 코드 목록 - TypeScript, React/JSX, 번들링, 매니페스트 생성을 지원하는 FigPlug - 개발자들이 질문과 작업물을 공유하는 Figma Plugins Slack 커뮤니티 - 조직 내부에서만 사용하는 비공개 플러그인도 팀별 워크플로 자동화에 활용할 수 있다고 안내한다. ## 실용적인 결론 Figma 플러그인은 단순한 편의 기능을 넘어 디자인 시스템 검증, 콘텐츠 품질 관리, 외부 데이터 연동, 접근성 개선, 개발 프로세스 연결까지 확장할 수 있다. 반복 작업이나 팀 고유의 규칙이 있다면 Plugin API와 오픈소스 사례를 참고해 사내 전용 플러그인부터 작게 만들어보는 것이 현실적인 접근이다.

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

HTMLReactTypeScriptJavaScript+4

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

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

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를 사용하는 팀이라면 자주 반복되는 작업과 품질 검사를 먼저 찾아보고, 적합한 공개 플러그인을 도입하거나 조직 전용 플러그인으로 직접 자동화하는 것이 효과적이다.

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

HTML디자인 시스템접근성JavaScript+3

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

Figma에 플러그인이 도입

Figma는 디자인 작업을 확장할 수 있는 플러그인 베타를 출시하며, 개발자들의 참여를 요청했다. 플러그인은 반복 작업 자동화, 외부 데이터 활용 등으로 디자인 워크플로를 개선할 수 있으며, 장기적으로는 커뮤니티가 만든 플러그인을 누구나 사용할 수 있도록 하는 것이 목표다. Figma는 안정성·보안·성능을 보장하기 위해 내부 API가 아닌 서드파티 전용 API를 설계했다고 강조한다. ## Figma 플랫폼에서 플러그인으로 확장 - Figma는 1년 전 HTTP 기반 Figma API를 공개해 외부 도구와의 연동을 지원했다. - 고객들은 API를 활용해 다음과 같은 워크플로를 구축했다. - Slack 명령으로 Figma 아이콘을 문서에 내보내기 - 디자인 파일 변경 사항을 개발 환경에 자동 반영하기 - SVG 아이콘 라이브러리를 효율적으로 업데이트·배포하기 - 플러그인은 기존 API 연동을 넘어 Figma 내부의 디자인 작업 과정을 직접 확장하는 다음 단계로 소개됐다. ## 플러그인으로 가능한 작업 - 반복적인 디자인 작업을 자동화할 수 있다. - 실제 데이터를 Figma 파일에 가져와 디자인에 활용할 수 있다. - 팀 구성원과 직접 만든 플러그인을 공유할 수 있다. - 웹사이트 제작 경험이 있는 개발자라면 비교적 쉽게 플러그인을 만들고 유지할 수 있도록 설계됐다. ## 안정성과 보안을 고려한 API 설계 - 플러그인이 Figma 업데이트 때마다 작동을 멈추는 문제를 방지하려 했다. - 내부 API를 그대로 공개하면 플랫폼 변경에 따라 API가 자주 바뀌고, 서드파티 개발자는 매번 코드를 수정해야 한다. - Figma는 플러그인 개발자를 위해 별도의 공식 API를 설계하고, 플러그인이 의존하는 API를 지속적으로 지원·관리하겠다고 밝혔다. - 플러그인이 Figma의 성능이나 사용자 경험을 저해하지 않도록 하는 것도 중요한 원칙으로 제시됐다. ## 플러그인 생태계의 설계 원칙 - 모든 디자이너가 쉽고 직관적으로 사용할 수 있어야 한다. - 웹사이트를 만들 수 있는 사람이라면 플러그인을 개발할 수 있어야 한다. - 인기 있는 프로그래밍 언어로 플러그인을 작성할 수 있어야 한다. - 플러그인이 Figma의 성능과 사용성을 해치지 않아야 한다. - 플러그인이 사용하는 모든 API를 Figma가 공식적으로 지원해야 한다. ## 베타 참여 대상과 운영 방식 - 기본적인 HTML과 JavaScript 지식이 있고 플러그인 아이디어가 있는 사람을 대상으로 했다. - 초기에는 참여 인원이 제한되며, 어떤 플러그인을 만들려는지에 따라 우선순위를 정했다. - 다양한 아이디어를 가진 베타 사용자가 API를 실제로 시험하고 개선 방향을 제시하도록 하는 것이 목적이었다. - 당시에는 개발자 중심의 베타였지만, 이후 코딩하지 않는 사용자도 커뮤니티 플러그인을 사용하게 될 것이라고 예고했다. 플러그인은 Figma를 단순한 디자인 도구가 아니라 개발자와 커뮤니티가 기능을 확장하는 플랫폼으로 전환하는 핵심 수단이다. 플러그인을 도입하려는 팀은 반복 업무 자동화나 실제 데이터 연동처럼 효과가 분명한 작업부터 시작하고, 공식 API의 안정성과 성능 영향을 함께 고려하는 것이 좋다.

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

HTMLJavaScript웹 개발figma-plugins+2

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

디자인 시스템 전파의

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

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

HTMLFigma디자인 시스템접근성+4

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

마이크로소프트 디자이너

Microsoft 디자이너 Jackie Chui는 사내 아이콘 4,000개를 한곳에서 검색·분류·복사할 수 있는 브라우저 기반 라이브러리를 3주 만에 만들었다. 디자이너용 태그와 엔지니어용 클래스명, 아이콘을 붙여 넣어 메타데이터를 찾는 역검색 기능을 제공해 도구 간 단절을 해결했다. 이 사례는 기존 제품을 그대로 사용하는 대신 실제 사용자의 요구를 조사하고, 익숙한 기술과 단계적인 학습으로 맞춤형 도구를 만들 수 있음을 보여준다. ## 문제 발견과 기존 도구의 한계 - Jackie는 Microsoft 디자이너들의 작업 과정을 관찰하고 아이콘 관리에서 겪는 불편을 조사했다. - 기존 제품 중에서는 IconJar가 아이콘 정리와 복사·붙여넣기를 지원했지만 Microsoft의 요구에는 부족했다. - 여러 사용자가 아이콘 태그를 추가하고 공유할 수 없었다. - 브라우저 기반이 아니어서 아이콘을 클라우드에서 공동으로 사용할 수 없었다. - Mac 전용이라 Windows 중심 조직에 적합하지 않았다. - 이에 따라 특정 운영체제나 디자인 도구에 종속되지 않는 자체 도구를 만들기로 했다. ## 브라우저 기반 아이콘 라이브러리 설계 - 초기 UI는 Sketch로 설계하고 IconJar에서 아이디어를 얻되, Microsoft Fabric 디자인 언어에 맞게 스타일을 조정했다. - 브라우저에서 작동하도록 만들어 사용자가 선호하는 디자인 도구와 관계없이 접근할 수 있게 했다. - 아이콘마다 다음 정보를 연결했다. - 디자이너가 찾기 쉬운 태그와 분류명 - 엔지니어가 코드에서 사용하는 클래스명 - 실제 복사·붙여넣기에 필요한 유니코드 아이콘 문자 - 아이콘을 검색해 바로 복사할 수 있게 해, 디자이너가 자주 쓰는 아이콘 문자를 별도 파일에 보관하던 방식을 없앴다. - 아이콘을 라이브러리에 붙여 넣으면 관련 메타데이터를 역으로 찾을 수 있는 기능도 제공했다. ## 익숙한 기술로 빠르게 개발 - Jackie는 포트폴리오 제작을 통해 익힌 HTML, CSS, JavaScript 경험을 기반으로 개발을 시작했다. - 프런트엔드와 백엔드 데이터베이스를 함께 구축하기 쉬운 JavaScript 프레임워크 Meteor.js를 선택했다. - Meteor 튜토리얼의 할 일 목록 데이터베이스 예제를 아이콘 데이터베이스로 확장했다. - 새로운 기술을 완전히 습득한 뒤 시작하기보다, 해결해야 할 실제 문제를 중심으로 필요한 내용을 학습하며 개발했다. - 기획과 디자인 경험에 엔지니어링 지식을 결합해 짧은 기간 안에 작동하는 제품을 완성했다. ## 아이콘 데이터 수집과 변환 - 아이콘은 일반적으로 폰트 파일에 저장되며, 키보드로 직접 입력할 수 없는 전용 유니코드 문자를 복사해 사용한다. - Jackie는 회사의 아이콘 폰트 파일을 다운로드하고 각 아이콘의 실제 유니코드 문자를 추출했다. - Microsoft 문서에서 엔지니어가 사용하는 아이콘 이름과 클래스명 목록을 확보했다. - 아이콘 이름 목록을 Excel로 정리한 뒤 JSON으로 변환해 애플리케이션 데이터로 사용했다. - 이렇게 아이콘 문자, 표시 이름, 클래스명, 태그를 하나의 검색 가능한 시스템으로 통합했다. ## 배포와 사용자 피드백 - 약 3주간의 개인 작업 끝에 첫 버전을 완성하고 Microsoft Azure에 호스팅했다. - 처음에는 팀에 간단한 이메일과 링크만 공유했지만, 사용자들의 입소문을 통해 디자인 스튜디오 전체로 확산됐다. - 동료들은 버그를 제보하고 새 기능을 제안하며 제품 개선에 참여했다. - 도구는 빠르게 여러 디자이너의 일상적인 작업 흐름에 포함됐다. - 이후 V2에서는 버그 수정과 기능 보강을 진행하고 다른 Microsoft 팀으로 확장할 계획이었다. ## Figma 컴포넌트로의 확장 - 향후 4,000개 이상의 아이콘을 한 번에 Figma 컴포넌트로 변환하는 기능을 계획했다. - 사용자는 별도 라이브러리를 거치지 않고 Figma 안에서 아이콘을 검색하고 정리할 수 있게 된다. - 장기적으로는 아이콘 폰트 파일을 업로드하면 누구나 Figma 컴포넌트로 변환할 수 있는 도구로 발전시키려 했다. - 기존 도구를 대체하는 다음 버전을 만드는 것이 목표라는 점에서, 제품은 사용자의 작업 흐름에 맞춰 계속 진화한다. 실용적으로는 먼저 사용자의 반복적인 불편을 관찰하고, 기존 도구의 부족한 점을 명확히 정의하는 것이 중요하다. 이후 모든 기능을 완성하려 하기보다 검색·분류·복사처럼 핵심 작업만 지원하는 최소 버전을 빠르게 배포하고, 실제 사용자 피드백을 바탕으로 확장하는 접근이 효과적이다.

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

HTMLFigmaReactJavaScript+4

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

디자인 면접에서 포트폴

신입 디자이너의 포트폴리오 면접 발표는 작품의 완성도만큼이나 전달 방식이 중요하다. 발표자는 자신이 어떤 디자이너인지 명확히 소개하고, 가장 애정을 가진 프로젝트를 중심으로 문제·역할·해결 과정·성과를 간결하게 설명해야 한다. 또한 면접 회사의 브랜드를 무리하게 차용하기보다 자신의 역량과 디자인 사고를 정확히 보여주는 데 집중해야 한다. ## 발표의 시작은 천천히, 정체성은 분명하게 - 발표 초반에는 이름과 전문 분야를 먼저 소개한다. - 모든 디자인 분야를 잘한다고 포장하기보다 자신이 강점을 가진 영역을 명확히 말한다. - 타이포그래피 - UX/UI 디자인 - 커뮤니케이션 디자인 - 모션 그래픽 - 프런트엔드 개발 - 경험해 본 분야와 전문 분야를 구분해 설명하면 자신의 역량 범위를 더 신뢰감 있게 전달할 수 있다. - 경력이 많은 디자이너라면 여러 분야에 걸친 폭넓은 전문성을 강조해도 좋지만, 신입이라면 핵심 강점과 열정을 선명하게 보여주는 편이 효과적이다. ## 가장 오래 한 프로젝트보다 가장 좋아하는 프로젝트를 먼저 보여주기 - 신입 지원자는 규모가 크고 작업 시간이 긴 프로젝트를 먼저 제시하려는 경향이 있다. - 그러나 발표 초반에는 자신이 가장 즐겁게 작업했고 애정을 가진 프로젝트를 선택하는 것이 좋다. - 열정이 담긴 프로젝트는 발표자의 디자인 감각과 개성을 더 자연스럽게 드러낸다. - 작은 프로젝트라도 본인의 관점과 성향을 잘 보여준다면 복잡하고 장황한 프로젝트보다 인상적일 수 있다. ## 프로젝트는 “무엇을, 누가, 왜, 현재 어떻게 되었는가”로 설명하기 면접관에게 프로젝트의 모든 세부 과정을 전달하려 하기보다, 핵심 흐름만 남겨 이해하기 쉽게 구성해야 한다. - 간단한 프로젝트 소개 - 해결해야 했던 문제 - 프로젝트 목표 - 실제 실행 과정 - 최종 디자인 - 결과와 성공을 판단한 기준 ### 무엇을 만든 프로젝트인가 - 발표 자료에 긴 아티스트 스테이트먼트가 있더라도 면접관이 모두 읽는다고 기대하지 않는다. - 배경지식이 없는 사람도 이해할 수 있도록 프로젝트의 성격과 목적을 간단히 설명한다. ### 누가 어떤 역할을 맡았는가 - 팀 프로젝트에서는 자신의 기여 범위를 반드시 분명히 한다. - 담당한 업무와 의사결정에 참여한 부분을 설명해야 면접관이 실제 역량을 정확히 판단할 수 있다. - 역할을 밝히지 않으면 팀의 성과를 자신의 성과처럼 말하는 것으로 오해받거나, 반대로 본인의 기여가 제대로 드러나지 않을 수 있다. ### 왜 필요한 프로젝트였는가 - 대부분의 디자인 과제는 특정한 문제를 해결하기 위해 진행된다. - 사용자의 문제, 비즈니스 요구, 커뮤니케이션상의 제약 등 프로젝트가 시작된 이유를 구체적으로 제시한다. - 면접관이 디자인 과제의 맥락과 난점을 공감할 수 있도록 상황을 생생하게 설명한다. ### 현재 어떤 결과를 만들었는가 - 디자인이 실제로 어떻게 사용되었는지 설명한다. - 가입자 증가, 전환율, 사용량 등 측정 가능한 성과가 있다면 수치로 제시한다. - 결과물이 실제 채택되지 않았더라도, 채택되었다면 어떤 효과가 있었을지와 향후 가능성을 설명할 수 있다. - 기업은 마감 시점의 결과물뿐 아니라 디자인이 실제 환경에서 어떻게 살아갈 수 있는지도 보고 싶어 한다. ## 면접 회사의 브랜드를 과도하게 활용하지 않기 - 지원 회사의 브랜드를 발표 자료나 작품에 무리하게 적용하는 것은 신중해야 한다. - 회사의 브랜드 사용 지침을 정확히 모르면 의도치 않게 브랜드를 잘못 표현할 수 있다. - 면접관 중에는 해당 브랜드의 디자인 시스템과 컴포넌트를 직접 만든 디자이너가 있을 수 있다. - 회사를 만족시키려는 의도가 오히려 브랜드를 피상적으로 모방하거나 잘못 이해한 결과로 보일 수 있다. - 회사에 맞춘 준비보다 자신의 디자인 역량, 문제 해결 과정, 협업 기여도를 명확히 전달하는 데 집중하는 것이 안전하다. 발표를 준비할 때는 프로젝트 수를 늘리기보다 자신을 가장 잘 보여주는 작업을 선정하고, 각 프로젝트를 짧고 일관된 구조로 연습하는 것이 좋다. 특히 “내 역할은 무엇이었는가”, “어떤 문제를 해결했는가”, “그 결과 무엇이 달라졌는가”를 명확히 답할 수 있어야 한다.

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

HTMLFigmaCSStypography+3

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

피그마 컴포넌트

Figma의 컴포넌트는 소프트웨어 개발의 composition, inheritance, override 개념을 디자인에 적용해 복잡한 UI를 일관되고 효율적으로 설계하도록 돕는다. 원본 컴포넌트를 수정하면 모든 인스턴스에 변경 사항이 반영되지만, 각 인스턴스는 필요한 속성을 독립적으로 재정의할 수 있다. 이를 통해 반복 작업을 줄이면서도 디자인 시스템의 일관성과 창의적인 변형을 동시에 확보할 수 있다. ## 디자인에 컴포넌트를 적용하는 이유 - 복잡한 화면을 더 작은 재사용 단위로 나누어 이해하고 구성할 수 있다. - 주소록의 연락처 행처럼 반복되는 UI를 한 번만 설계한 뒤 여러 곳에서 재사용할 수 있다. - 동일한 컴포넌트를 사용하면 글자 크기, 간격, 아이콘, 그래픽 등의 시각적 일관성을 유지하기 쉽다. - 컴포넌트는 단순한 복사본이 아니라 동일한 원본을 참조하는 인스턴스이므로, 원본 변경 사항이 관련 디자인에 자동으로 반영된다. ## Figma가 지향한 컴포넌트 설계 - 초보자도 쉽게 배울 수 있어야 한다. - 고급 사용자에게 충분히 강력해야 한다. - 디자인 과정 전반에서 유연하게 활용할 수 있어야 한다. - 체계적으로 디자인하더라도 창의적인 작업을 방해하거나 불필요한 작업 절차를 늘리지 않아야 한다. - 디자인 시스템 구축이 속도와 일관성을 높이는 수단이 되어야 하며, 새로운 문제를 해결하는 데 제약이 되어서는 안 된다. ## 컴포넌트와 인스턴스의 동작 방식 - 선택한 프레임이나 객체에 “Create Component”를 적용하면 컴포넌트가 생성된다. - 컴포넌트를 복제하거나 Alt 키로 드래그하거나 복사·붙여넣기하면 일반 복사본이 아니라 인스턴스가 만들어진다. - 인스턴스는 캔버스에서 위치를 독립적으로 가질 수 있지만, 기본적으로 원본 컴포넌트의 구조와 속성을 공유한다. - 원본 컴포넌트의 변경 사항은 모든 인스턴스에 즉시 반영된다. - 인스턴스 내부의 일부 속성은 관리와 유지보수를 위해 제한될 수 있으며, 특히 내부 객체의 위치와 크기 같은 속성이 대표적이다. ## 스타일 및 속성 오버라이드 - 인스턴스에서 변경한 값은 원본을 대체하는 것이 아니라 해당 인스턴스에만 적용되는 오버라이드로 취급된다. - 예를 들어 특정 인스턴스의 채우기 색상을 진회색으로 바꾸거나, 다른 인스턴스의 선 색상과 두께를 빨간색·6px로 설정할 수 있다. - 원본 컴포넌트를 수정해도 인스턴스에서 직접 재정의한 속성은 유지된다. - 재정의하지 않은 속성은 원본 컴포넌트의 최신 상태를 계속 반영한다. - 인스턴스 내부의 하위 레이어와 그 속성도 오버라이드할 수 있어 다양한 변형을 만들 수 있다. - 변경 사항을 제거하려면 “Reset Instance”를 사용해 원본 컴포넌트의 상태로 되돌릴 수 있다. ## 중첩 컴포넌트로 복잡한 UI 구성 - 컴포넌트 안에 다른 컴포넌트의 인스턴스를 포함할 수 있다. - 여러 인스턴스를 조합해 더 복잡한 동작과 UI 구조를 만들 수 있다. - 기존 인스턴스를 포함한 객체를 다시 컴포넌트로 만들 수도 있다. - 작은 단위의 컴포넌트를 계층적으로 조합하면 대규모 디자인 시스템을 관리하기 쉬워진다. ## 제약 조건과의 결합 - 컴포넌트는 Figma의 다른 기능과 함께 사용할 때 더 큰 표현력을 갖는다. - 제약 조건을 적용하면 화면 크기나 객체 위치가 바뀔 때 내부 요소가 어떻게 반응할지 정의할 수 있다. - 따라서 단순히 같은 UI를 복제하는 것을 넘어, 다양한 크기와 상황에 대응하는 반응형 디자인을 구성할 수 있다. 실무에서는 반복되는 UI를 먼저 컴포넌트로 만들고, 인스턴스별 차이는 오버라이드로 최소한만 적용하는 방식이 적합하다. 공통 구조와 스타일은 원본에서 관리하고, 개별 화면의 예외적인 요구만 인스턴스에서 변경하면 유지보수성과 디자인 일관성을 함께 확보할 수 있다.

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

HTMLFigma디자인 시스템React+4

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

Figma와 Framer 통합 기능 소개

Figma는 2016년 Framer와의 통합을 발표하며, 정적 UI 디자인과 코드 기반 프로토타이핑 사이의 작업 흐름을 단순화했다. 이제 사용자는 Figma의 디자인 자산을 레이어별로 내보내고 다시 업로드하지 않고도 Framer로 한 번에 가져올 수 있다. 이를 통해 디자인 아이디어를 빠르게 코드로 구현하고, 실제 상호작용을 테스트하며, 더 나은 제품을 빠르게 출시할 수 있다는 것이 글의 결론이다. ## 정적 목업만으로는 부족한 이유 - 모바일과 다양한 디바이스 환경에서는 단순한 화면 이미지나 정적 목업만으로 사용자 경험을 충분히 표현하기 어렵다. - 디자이너에게는 다음 세 가지 능력이 필요하다. - 실제 사용될 맥락에 맞춰 디자인하기 - 사용자의 입력에 따라 화면이 어떻게 변하는지 보여주기 - 모션 그래픽과 전환 효과를 통해 상호작용의 즐거움을 표현하기 - 과거에는 After Effects 같은 영상 편집 도구를 사용하거나 HTML, JavaScript, CSS로 프로토타입을 직접 작성해야 했다. - 이러한 방식은 FTP 업로드, 모바일 기기에서 3G로 접속하기, 브라우저 호환성 문제 해결 등 창의적인 작업과 무관한 부담이 컸다. ## Figma와 Framer의 역할 - Figma는 UI를 빠르게 설계하고 반복해서 수정하는 데 강점을 가진다. - Framer는 코드를 기반으로 복잡하고 개방적인 상호작용을 구현하는 프로토타이핑 도구다. - 특히 복잡한 단일 페이지 인터랙션을 표현하는 데 적합하며, 디자이너가 코드 수준의 프로토타입을 만들 수 있도록 돕는다. - 두 도구를 함께 사용하면 Figma에서 만든 UI 아이디어를 Framer에서 빠르게 구현하고 실제 동작을 검증할 수 있다. ## 한 번의 클릭으로 디자인 자산 가져오기 - 통합 이전에는 Figma의 레이어를 하나씩 내보낸 뒤 Framer에 다시 업로드해야 했다. - 새 통합 기능을 사용하면 Framer 작업 중 Figma 자산을 한 번에 가져올 수 있다. - 반복적인 파일 변환과 업로드 과정이 줄어들어 디자인에서 프로토타이핑으로 넘어가는 시간이 단축된다. - 결과적으로 아이디어를 코드로 옮기고 테스트하는 과정이 더 빠르고 효율적으로 바뀐다. ## 디자인과 코드의 연결 - Framer 사용자 Jonathan Simcoe는 Framer의 코드 기반 구조가 표현력이 높고 제한이 적다고 설명했다. - Figma는 팀이 UI를 빠르게 설계하고 반복하는 데 도움을 주며, Framer는 이를 실제 상호작용이 포함된 프로토타입으로 발전시키는 역할을 한다. - 통합의 목표는 디자이너가 아이디어를 더 빨리 구현하고, 테스트와 개선을 반복해 더 나은 제품을 출시하도록 지원하는 것이다. - 이는 디자인 도구와 개발·프로토타이핑 도구를 분리하기보다 하나의 연속된 작업 흐름으로 연결하려는 시도다. ## 출시 당시 상황 - 해당 기능은 2016년 8월 발표됐으며, 당시 Figma는 아직 비공개 릴리스 단계였다. - Figma는 사용자 요청을 바탕으로 여러 프로토타이핑 도구와의 연동을 검토했고, 그중 Framer에 대한 요구가 가장 컸다고 밝혔다. - 사용자는 Figma에서 시각적 설계를 진행한 뒤 Framer에서 코드 기반 상호작용을 구현하는 방식으로 두 도구를 조합할 수 있었다. 실무에서는 Figma를 화면 설계와 반복 작업에 활용하고, 복잡한 인터랙션이나 실제 동작 검증이 필요할 때 Framer로 가져가는 방식이 효과적이다. 특히 레이어를 수동으로 내보내는 과정이 줄어들기 때문에 프로토타입을 자주 수정하고 테스트하는 팀일수록 통합의 이점을 크게 얻을 수 있다.

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

HTMLFigma프로토타이핑JavaScript+4

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

스크린 디자인을 위한 그리드

스위스 타이포그래피에서 발전한 그리드 시스템은 화면 디자인에서도 여전히 일관성과 질서를 만드는 핵심 원리다. 고정된 인쇄물과 달리 화면은 기기 크기와 밀도가 달라지므로, 디지털 디자인에는 유연한 그리드와 이를 제어할 도구가 필요하다. Figma는 제약 조건, 레이아웃 그리드, 중첩 프레임을 결합해 다양한 화면 크기에서도 구조가 유지되는 디자인을 제안한다. ## 고정된 페이지에서 유동적인 화면으로 - 1950년대 스위스 디자이너들은 정보를 체계적으로 배치하기 위해 그리드 디자인을 발전시켰다. - Joseph Müller-Brockmann, Karl Gerstner 등의 작업은 합리적인 구조와 시각적 아름다움을 함께 보여주었다. - 인쇄 디자인은 페이지 크기, 글자 크기, 행간, 여백을 정밀하게 통제할 수 있다는 전제를 가진다. - 반면 화면 디자인은 브라우저와 기기마다 크기와 화면 밀도가 달라 동일한 고정 레이아웃을 그대로 적용하기 어렵다. - 따라서 문제는 그리드 철학 자체가 아니라, 유동적인 캔버스를 다룰 수 있는 디지털 도구가 부족했다는 데 있다. ## 기존 화면 디자인 도구의 한계 - 초기 디지털 디자인에서는 기술적 제약 때문에 인쇄 디자인의 많은 원칙이 버려졌다. - 오늘날에는 타이포그래피와 레이아웃 제어 기능이 발전했지만, 도구는 여전히 고정된 아트보드 중심인 경우가 많다. - 디자이너는 여러 화면 크기의 아트보드를 반복해서 복사·수정하거나, 개발 단계에서 반응형 동작을 추측해야 했다. - iPad처럼 화면의 가장자리와 페이지 개념을 제공하는 기기가 등장했지만, 기기 종류가 늘면서 디지털 페이지는 어떤 크기와 형태도 가질 수 있게 되었다. - 중요한 과제는 유연성을 확보하면서도 정밀한 정렬과 통제를 유지하는 것이다. ## 제약 조건: 크기 변화에 대응하는 규칙 - 제약 조건은 프레임의 크기가 바뀔 때 내부 객체가 어떻게 반응할지 지정한다. - 객체를 프레임의 왼쪽이나 오른쪽에 고정하거나, 중앙에 배치하거나, 남은 공간을 채우도록 늘릴 수 있다. - 이를 통해 단순히 요소를 특정 좌표에 고정하는 대신, 화면 크기 변화에 따른 동작을 설계할 수 있다. - 제약 조건만으로도 가장자리 고정, 중앙 정렬, 영역 확장과 같은 기본적인 반응형 레이아웃을 구현할 수 있다. ## 레이아웃 그리드: 정밀한 반응형 정렬 - 복잡한 디자인에서는 단순한 좌우 고정이나 중앙 정렬만으로 충분하지 않기 때문에 그리드가 필요하다. - Figma의 그리드는 제약 조건이 작동하는 기준을 세밀하게 정의한다. - 예를 들어 어떤 박스가 두 개의 그리드 열을 차지하도록 설정하면, 화면이 커지거나 작아질 때 박스도 그 열의 경계에 맞춰 함께 늘어나거나 줄어든다. - 열 그리드는 웹페이지의 텍스트 흐름뿐 아니라 아이콘, 툴바, 버튼 등 다양한 요소를 정렬하는 데 사용할 수 있다. - 그리드는 열과 행, 여백, 모듈 등의 구조를 통해 디자인 전체에 일관된 시각적 리듬을 부여한다. ## 중첩 프레임: 복잡한 구조를 구성하는 방법 - 하나의 화면 안에서도 영역마다 다른 레이아웃 규칙이 필요할 수 있다. - 프레임 안에 또 다른 프레임을 배치하면 각 영역에 독립적인 그리드와 제약 조건을 적용할 수 있다. - 예를 들어 전체 화면은 큰 2열 그리드를 사용하고, 툴바나 카드 내부에는 별도의 그리드를 적용할 수 있다. - 이러한 구조는 HTML의 중첩된 `<div>`와 유사하며, 실제 개발 구조로 옮기기에도 적합하다. - Figma가 ‘아트보드’ 대신 ‘프레임’이라는 용어를 사용하는 이유도 단순한 캔버스를 넘어 계층적 레이아웃 시스템을 제공하기 때문이다. ## 현대적인 디자인 도구의 방향 - 정적인 화면을 그리는 것만으로는 다양한 디바이스 환경을 충분히 다룰 수 없다. - 디자인 도구는 과거의 인쇄 디자인 원칙을 버리기보다, 이를 유동적인 화면 환경에 맞게 재해석해야 한다. - 제약 조건, 그리드, 중첩 프레임은 각각 독립적으로도 사용할 수 있지만 함께 사용할 때 복잡한 반응형 디자인 시스템을 구축할 수 있다. - 좋은 도구는 결과물뿐 아니라 화면 크기 변화에 따른 디자인의 동작과 규칙까지 표현할 수 있어야 한다. 실무에서는 먼저 전체 화면의 그리드를 정의한 뒤, 주요 요소에 제약 조건을 설정하고, 카드·툴바·콘텐츠 영역을 중첩 프레임으로 분리하는 방식이 효과적이다. 이렇게 하면 여러 화면 크기별 시안을 일일이 복제하지 않고도 일관성과 반응성을 함께 관리할 수 있다.

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

HTMLFigma디자인 시스템반응형 디자인+3