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와 유사한 컴포넌트 구조를 활용해 비교적 빠르게 인터랙티브 협업 도구를 만들 수 있다.

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

CSSfigjamReactJavaScript+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 키트를 만들 때는 화면을 예쁘게 복제하는 것보다 코드와 디자인의 구조를 일치시키는 일이 중요하다. 레이어 이름과 변형 속성을 처음부터 표준화하고, 반복되는 레이아웃 규칙을 컴포넌트 구조에 반영하면 사용자는 더 쉽게 커스터마이즈할 수 있고 디자인·개발 간 협업도 효율적으로 유지할 수 있다.

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

CSSFigma디자인 시스템HTML+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처럼 검증된 레이아웃 모델을 참고하되, 사용자가 모든 내부 규칙을 학습하지 않아도 되도록 핵심 개념만 제공하는 것이 중요하다. 또한 실제 편집 환경을 반영한 프로토타입과 사용자 피드백을 통해 기능의 유연성과 조작의 직관성을 함께 검증해야 한다.

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

CSSFigma디자인 시스템HTML+3

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

코드와 디자인 사이의 긴

Figma는 디자인의 자유로운 탐색과 코드의 구조적·재사용 가능한 접근 사이의 긴장을 없애기보다 생산적인 협업 방식으로 받아들여야 한다고 주장한다. 이를 위해 디자인 시스템을 코드의 컴포넌트 구조와 가깝게 만들고, 디자이너와 개발자가 같은 시스템을 더 효율적으로 이해하고 활용할 수 있도록 Variants, Interactive Components, 개선된 Auto Layout, Inspect Tab 등을 발표했다. 궁극적으로 Figma는 디자인과 코드를 분리된 작업이 아니라 제품을 함께 만드는 연결된 과정으로 발전시키려 한다. ## 디자인과 코드 사이의 긴장 - 디자이너는 무엇을 만들지 결정하며 자유로운 시각적 탐색과 빠른 반복을 중시한다. - 개발자는 정해진 구조 안에서 실제 제품을 구현하며 재사용성, 일관성, 규칙을 중시한다. - 개발자에게 컴포넌트를 “깨는” 행위가 디자이너에게는 창의적인 실험일 수 있고, 개발자의 구조가 디자이너에게는 제약처럼 느껴질 수 있다. - Figma는 코드의 엄격성과 재사용성을 디자인에 적용하되, 디자인의 빠른 반복과 자유로운 탐색은 유지해야 한다고 본다. ## Variants로 코드와 디자인 컴포넌트 연결 - 프런트엔드의 하나의 컴포넌트는 상태와 맥락에 따라 여러 형태로 표현된다. - 예: 버튼의 기본형·보조형 - 작은 크기·큰 크기 - iOS·Android별 스타일 - 기존 Figma에서는 이런 변형을 각각 별도의 컴포넌트로 관리해야 해 코드 구조와 디자인 구조가 달라졌다. - **Variants**는 같은 컴포넌트의 여러 변형을 하나의 논리적 컴포넌트로 그룹화한다. - 이를 통해 에셋 패널을 단순화하고, 디자인 컴포넌트를 코드의 컴포넌트 모델에 더 가깝게 표현할 수 있다. - 발표 당시 2020년 11월 출시 예정으로 소개됐다. ## Interactive Components로 프로토타이핑 간소화 - Variants를 사용하면 버튼이나 입력 필드의 여러 상태를 하나로 묶을 수 있다. - 기존에는 상태 간 전환을 표현하려면 여러 프레임과 오버레이를 수동으로 연결해야 했다. - **Interactive Components**는 Variants 사이에 프로토타이핑 상호작용을 직접 설정할 수 있게 한다. - 컴포넌트 인스턴스를 프로토타이핑 모드에서 즉시 동작하는 요소처럼 사용할 수 있어, 반복적인 프레임 연결 작업을 줄인다. - 당시 2021년 1월 출시 예정으로 발표됐다. ## 코드처럼 설계하는 Auto Layout - Auto Layout은 텍스트가 바뀌어도 버튼이나 프레임 크기가 자동으로 조정되도록 해 반응형 UI 제작을 돕는다. - Figma는 Auto Layout을 웹의 CSS 박스 모델과 Flexbox에 더 가깝게 발전시키려 했다. - 개선 사항에는 다음이 포함된다. - 더 단순해진 사용자 인터페이스 - 가로·세로 양축에서 요소를 늘리는 기능 - 방향별로 독립적인 패딩 설정 - 내비게이션 아이콘처럼 자주 쓰이는 UI 패턴에 맞춘 간격 설정 - 디자이너가 수동으로 위치와 크기를 조정하는 대신, 코드의 레이아웃 규칙에 가까운 방식으로 디자인할 수 있게 하는 것이 목표다. ## 대규모 디자인 시스템을 위한 컴포넌트 탐색 - 수천 개의 컴포넌트를 사용하는 대규모 라이브러리에서는 정확한 이름을 기억하거나 긴 목록을 직접 찾아야 하는 불편이 있었다. - **Instance Swap Menu**가 개선되어 다음 기능을 제공한다. - 컴포넌트 썸네일 - 검색 - 키보드 단축키 - Variants와 함께 사용하면 여러 컴포넌트를 일일이 찾는 부담을 줄이고, 대규모 디자인 시스템에서도 적절한 인스턴스를 빠르게 교체할 수 있다. - 이 기능은 글 작성 당시 바로 사용할 수 있는 기능으로 소개됐다. ## Inspect Tab으로 개발자 전달 정보 강화 - 기존 Code 패널을 대체하는 **Inspect Tab**은 개발자가 구현에 필요한 정보를 더 쉽게 확인하도록 설계됐다. - 선택한 레이어의 이름을 상단에 표시해 디자이너와 개발자가 어떤 요소를 구현하는지 명확히 확인할 수 있다. - 다음과 같은 디자인 속성을 구분해 보여준다. - Variants - 색상 - 그림자 - 콘텐츠 - 타이포그래피 - 테두리 - 개별 값을 클릭해 클립보드로 복사할 수 있으며, 여러 `key:value` 값으로 구성된 코드 조각도 한 번에 복사할 수 있다. - 디자인 명세를 별도로 정리하거나 개발자가 값을 수동으로 옮기는 과정을 줄여 구현 전환을 효율화한다. Figma의 방향은 디자인을 코드처럼 획일화하는 것이 아니라, 코드의 구조성과 재사용성을 디자인 시스템에 도입하면서도 디자이너의 창의적 탐색을 보존하는 것이다. 실무에서는 Variants로 상태와 스타일을 체계화하고, Auto Layout으로 레이아웃 규칙을 정의하며, Inspect Tab을 통해 개발자에게 구현 정보를 명확히 전달하는 방식이 효과적이다.

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

CSSFigma디자인 시스템프로토타이핑+4

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

기능 비하인드:

Figma의 그림자 `spread` 기능은 겉보기와 달리 단순히 도형을 확대하는 문제를 넘어선다. 사각형에서는 기하 도형을 키우는 방식이 작동하지만, 구멍이나 복잡한 윤곽을 가진 도형에서는 “모든 방향으로 일정 거리만큼 확장”해야 하므로 별도의 알고리즘과 렌더링 설계가 필요하다. 이 글은 CSS `box-shadow`와 호환되는 기능을 만들기 위해 알고리즘, W3C 명세, 기존 렌더러의 제약, 제품 우선순위를 검토한 과정을 설명한다. ## 그림자 `spread`가 필요한 이유 - Figma는 2020년 7월 23일부터 사각형, 타원, 프레임 배경, 컴포넌트 배경에 그림자 확산 거리를 조절하는 기능을 제공했다. - CSS의 `box-shadow`와 마찬가지로 `spread` 값은 그림자를 모든 방향으로 확장하거나 수축하는 거리다. - 사용자는 오랫동안 이 기능을 요청했지만, 기본적인 CSS 기능처럼 보이는 요구사항이 실제로는 그래픽스 엔진 수준의 문제였다. ## 기존 그림자 렌더링 방식 - 일반적인 드롭 섀도는 다음 순서로 만든다. - 원본 객체의 기하 구조를 복사한다. - 단일 색상으로 채운다. - 블러 효과를 적용한다. - 원본 노드 아래에 렌더링한다. - 이 방식은 단순한 도형의 그림자를 만드는 데는 충분하다. - 특히 사각형은 그림자 기하 구조를 확대하는 것만으로도 어느 정도 `spread` 효과를 낼 수 있다. ## 단순한 확대가 실패하는 복잡한 도형 - 복잡한 도형이나 Figma 로고처럼 내부에 구멍이 있는 도형은 전체 기하 구조를 스케일링하면 올바른 결과가 나오지 않는다. - 스케일링은 도형의 중심과 전체 비율을 기준으로 크기를 바꾸지만, `spread`는 원래 윤곽선에서 모든 방향으로 일정한 픽셀 거리만큼 확장해야 한다. - 따라서 원하는 결과는 단순히 외곽 크기가 커지는 것이 아니라 다음과 같은 형태다. - 볼록하거나 오목한 윤곽을 각각 일정 거리만큼 이동한다. - 내부 구멍도 동일한 규칙에 따라 확장 또는 축소한다. - 각 경계와 꼭짓점에서 일정한 거리 관계를 유지한다. ## 알고리즘과 렌더러의 제약 - 그림자 확산을 구현하는 알고리즘적 방법은 여러 가지가 있지만, 기존 Figma 렌더링 시스템에 자연스럽게 끼워 넣기 어려웠다. - 스트로크를 이용해 그림자를 흉내 내는 비알고리즘적 접근도 검토했지만 적합하지 않았다. - Figma의 스트로크는 특정 꼭짓점 각도를 그림자 확산에 필요한 방식과 다르게 처리한다. - 프로토타입 렌더러에는 스트로크 생성 코드 자체가 없었다. - Figma는 서로 다른 두 렌더링 코드베이스를 사용하고 있었기 때문에, 복잡한 기하 생성 로직을 양쪽에 모두 추가하는 방식은 유지보수 비용이 컸다. - 결국 문제는 “그림자를 크게 만드는 것”이 아니라, 기존 렌더링 구조를 크게 훼손하지 않으면서 임의의 2D 도형을 일정 거리만큼 확장하는 방법을 찾는 일이었다. ## 기능 개발 과정에서의 판단 - 작성자는 Maker Week에서 며칠 만에 끝낼 수 있는 간단한 기능이라고 생각했지만, 실제로는 몇 주가 걸리는 프로젝트가 되었다. - 개발 과정에서 처음 시도한 접근이 잘못되었음을 확인하고, 도형 확장 알고리즘과 W3C 명세를 다시 검토했다. - 이 사례는 사용자에게 단순해 보이는 기능도 다음 요소를 함께 고려해야 한다는 점을 보여준다. - 시각적으로 정확한 결과 - CSS와의 동작 호환성 - 기존 렌더링 엔진과의 통합 가능성 - 구현 복잡도와 장기적인 유지보수 비용 복잡한 도형의 그림자 `spread`를 구현할 때는 단순 확대나 스트로크 재활용만으로 해결하려 하지 말고, “윤곽선에서 모든 방향으로 일정 거리”라는 의미를 먼저 명확히 정의해야 한다. 이후 정확도, 렌더링 성능, 기존 코드베이스와의 통합 비용을 비교해 가장 현실적인 구현 방식을 선택하는 것이 중요하다.

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

CSScomputational-geometrycomputer-graphicsbox-shadow+2

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와 오픈소스 사례를 참고해 사내 전용 플러그인부터 작게 만들어보는 것이 현실적인 접근이다.

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

CSSReactTypeScriptJavaScript+4

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

Figma의 줄 높이

Figma는 텍스트의 줄 높이를 글자 위아래에 균등하게 배분하고, 보다 현대적인 기준으로 측정하도록 변경했다. 이는 기존 파일에 자동 적용되지 않는 선택적 변경이며, 사용자가 원하는 시점에 업데이트할 수 있다. 이 글은 금속 활자부터 컴퓨터 글꼴, CSS까지 줄 높이와 수직 정렬이 발전해 온 과정을 설명하며 Figma의 변경 배경을 밝힌다. ## 금속 활자 시대의 줄 높이 - 초기 활자에서 폰트 크기는 글자 자체가 아니라 글자를 담는 납 블록의 높이를 의미했다. - 같은 16pt 폰트라도 실제 글자 크기, 기준선 위치, 위아래 여백은 서체마다 달랐다. - 조판공은 줄 사이에 얇은 납 조각을 끼워 행간을 추가했다. - 이 납 조각을 뜻하는 *leading*에서 오늘날의 줄 높이 개념이 유래했다. - 예를 들어 16pt 활자에 4pt 행간을 추가하면 전체 줄 높이는 20pt가 된다. - 당시에는 행간을 추가할 수만 있었고, 활자에 내장된 공간을 제거할 수는 없었다. ## 디지털 폰트가 가져온 자유와 혼란 - 컴퓨터에서는 폰트가 고정된 납 블록이 아니라 다양한 수치와 메트릭을 담은 파일로 바뀌었다. - Windows, Macintosh, OS/2 등 플랫폼마다 폰트 형식과 렌더링 방식이 달랐고, 버그와 호환성 문제도 발생했다. - 화면에서는 글자가 고정된 상자에 묶이지 않으므로 행간을 자유롭게 추가하거나 제거할 수 있게 됐다. - 폰트의 기본 줄 높이는 글자 크기와 무관하게 임의의 값으로 설정될 수 있었다. - 같은 글자 크기와 같은 줄 높이를 사용해도 폰트 내부의 ascent, descent, 기준선 위치가 달라 시각적 결과가 달라졌다. ## CSS와 폰트 메트릭의 복잡성 - 웹에서는 줄 높이를 단순히 글자 크기로만 결정하지 않고, 기준선과 인라인 박스를 기준으로 계산한다. - CSS의 줄 높이는 일반적으로 한 줄의 기준선에서 다음 줄 기준선까지의 거리로 이해할 수 있다. - 추가 공간인 “half-leading”을 글자 위와 아래에 나누어 배치하는 방식이 사용된다. - 그러나 폰트 파일에 들어 있는 여러 메트릭 값이 서로 다른 목적을 가져 브라우저와 운영체제마다 결과가 달라질 수 있었다. - 특히 OS/2 테이블의 ascent, descent, line gap 값은 폰트의 시각적 경계와 실제 줄 상자 크기를 일치시키지 못하는 경우가 있었다. ## Figma의 줄 높이 변경 - Figma는 추가 줄 높이를 글자 위와 아래에 분배하는 방식으로 변경했다. - 줄 높이를 글자 크기나 특정 플랫폼의 관행에만 의존하지 않고, 보다 현대적인 타이포그래피 및 웹 기준에 가깝게 측정한다. - 이를 통해 텍스트가 프레임 안에서 수직으로 배치되는 방식을 더 예측 가능하게 만들려 했다. - 변경 사항은 기존 파일에 강제로 적용되지 않는다. - 사용자는 기존 텍스트를 그대로 유지하거나, 필요할 때 새 줄 높이 동작으로 업데이트할 수 있다. ## 하나의 완벽한 기준을 만들기 어려운 이유 - Figma는 인쇄물 디자인, 웹 디자인, 제품 UI 등 서로 다른 목적에 사용된다. - 역사적인 조판 관습과 현대적인 CSS 동작이 항상 일치하지 않는다. - 폰트마다 내부 메트릭이 다르고, 같은 폰트도 플랫폼과 렌더링 엔진에 따라 다르게 보일 수 있다. - 따라서 Figma는 모든 상황에 하나의 절대적인 정답을 적용하기보다, 새로운 동작을 선택 사항으로 제공하는 방식을 택했다. 기존 디자인의 시각적 일관성이 중요하다면 파일을 즉시 변경하지 말고, 새 줄 높이 동작이 필요한 웹·제품 UI 작업부터 선택적으로 적용하는 것이 적절하다.

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

CSSFigmatypographyweb-design+2

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

디자인 시스템 전파의

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

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

CSSFigma디자인 시스템접근성+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 컴포넌트로 변환할 수 있는 도구로 발전시키려 했다. - 기존 도구를 대체하는 다음 버전을 만드는 것이 목표라는 점에서, 제품은 사용자의 작업 흐름에 맞춰 계속 진화한다. 실용적으로는 먼저 사용자의 반복적인 불편을 관찰하고, 기존 도구의 부족한 점을 명확히 정의하는 것이 중요하다. 이후 모든 기능을 완성하려 하기보다 검색·분류·복사처럼 핵심 작업만 지원하는 최소 버전을 빠르게 배포하고, 실제 사용자 피드백을 바탕으로 확장하는 접근이 효과적이다.

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

CSSFigmaReactJavaScript+4

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

소개: Figma to React | 피

Figma는 API를 활용해 Figma 디자인을 React 컴포넌트와 코드로 변환하는 도구를 만들었다. 핵심 목표는 디자인을 Figma에서 계속 관리하면서도, 개발자가 작성한 기능 코드를 보존하고 여러 디자인에 재사용할 수 있도록 분리하는 것이다. 이를 통해 디자인 변경 사항을 웹사이트에 동기화하고, 기존 기능을 새로운 디자인에 쉽게 연결하려 했다. ## Figma 디자인을 React 코드로 변환 - Figma API 출시 이후 Figma 문서를 React 컴포넌트로 자동 변환하려는 시도가 꾸준히 있었다. - Pagedraw는 Figma 연동을 지원하는 제품을 만들었고, Figma 역시 자체적인 변환기를 개발해 공개했다. - 구현 코드는 GitHub에 오픈 소스로 공개되어 누구나 동작 방식을 확인하고 실험할 수 있다. - API를 직접 사용해 보고 싶은 개발자를 위해 Figma Developers 페이지도 제공한다. ## 디자인 코드와 기능 코드의 분리 - 생성되는 컴포넌트의 시각적 디자인은 가능한 한 Figma에서 관리하도록 설계했다. - Figma에서 디자인을 수정한 뒤 버튼 한 번으로 웹사이트의 디자인 변경 사항을 동기화하는 것이 목표다. - 동기화 과정에서 개발자가 작성한 이벤트 처리, 데이터 로직 등 기능 코드를 덮어쓰지 않아야 한다. - 따라서 Figma가 생성하는 디자인 코드와 애플리케이션의 기능 코드를 서로 독립적인 영역에 두는 구조가 필요하다. ## 기능 코드의 재사용 - 새로운 디자인을 만들 때마다 기능을 처음부터 다시 구현하지 않도록 하는 것도 주요 목표다. - 예를 들어 기존에 구현한 정렬 가능한 리스트의 기능을 새로운 리스트 디자인에 연결할 수 있어야 한다. - 기능 코드를 디자인과 분리하면 React 컴포넌트를 재사용하듯, 동일한 기능을 여러 시각적 디자인에 적용할 수 있다. - 이는 디자인 변경과 기능 개발이 서로의 작업을 방해하지 않도록 만드는 기반이 된다. ## Figma에서 CSS로 변환하기 - React 변환의 첫 번째 기술적 과제는 Figma 디자인과 동일하게 보이는 React 컴포넌트를 생성하는 것이다. - 단순히 HTML 구조만 생성하는 것이 아니라, 레이아웃과 스타일을 CSS로 재현해야 변환의 실질적인 가치가 생긴다. - 글에서는 정렬 가능한 리스트 예시를 사용해 디자인을 코드로 옮기는 과정을 설명하려 한다. - 동일한 시각적 결과를 구현하는 방법은 여러 가지가 있으므로, 어떤 CSS 구조와 속성을 선택할지가 중요한 설계 문제가 된다. 실무에서는 Figma를 디자인의 원천으로 활용하되, 변환된 코드를 그대로 최종 코드로 취급하기보다 시각적 구조와 기능 로직을 분리하는 초기 코드 생성 도구로 사용하는 것이 적절하다.

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

CSSReactJavaScriptdesign-to-code+2

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

디자인 면접에서 포트폴

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

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

CSSFigmaHTMLtypography+3

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

웹 디자이너 없는 웹

Xfive는 전담 디자이너가 없는 웹 개발 회사였지만, Figma를 활용해 낡고 복잡해진 홈페이지를 직접 redesign했다. 브라우저 기반 협업과 실시간 댓글 기능으로 마케팅·영업·개발 등 여러 이해관계자의 피드백을 한곳에서 관리했으며, 개발자는 별도 도구 없이 디자인 사양과 코드를 확인할 수 있었다. 이 경험을 통해 Figma가 디자인 제작부터 검토, 프로토타이핑, 개발자 인계까지 연결하는 효과적인 협업 플랫폼임을 확인했다. ## 리디자인이 필요했던 배경 - Xfive는 2006년 설립된 웹 개발 회사로, 크라쿠프·멜버른·샌프란시스코에 사무실을 두고 있다. - 일반적으로 고객이 제공한 디자인을 구현하는 방식이어서 사내에 디자이너를 두지 않았다. - 리브랜딩과 신규 웹사이트 출시 이후 회사는 성장했지만, 홈페이지와 일부 주요 영역은 그대로 남아 있었다. - Customers와 Work 섹션이 outdated 상태였고, 다음과 같은 구조적 문제가 있었다. - 혼란스러운 전역 내비게이션 - 서로 경쟁하는 지나치게 많은 CTA - 탐색과 유지보수가 어려운 다수의 랜딩 페이지 ## 디자이너가 아닌 직원의 Figma 활용 - 콘텐츠 제작자인 Lubos Kmetko가 Figma를 시험적으로 사용한 뒤 홈페이지 리디자인을 맡았다. - 전문 디자이너는 아니었지만 Figma를 이용하면 직접 시안을 만들 수 있다고 판단했다. - 홈페이지, Customers 영역, Work 섹션을 새로 설계하면서 내비게이션과 CTA, 랜딩 페이지 구조를 단순화했다. - 중요한 조건은 다양한 부서가 디자인을 검토하고 의견을 제출할 수 있어야 한다는 점이었다. ## 브라우저 기반 프로토타이핑과 협업 - Lubos는 완성한 각 페이지의 목업을 링크로 공유했다. - 마케팅, 영업, 제작, 편집, 개발팀은 물론 COO까지 브라우저에서 디자인을 열고 댓글을 남길 수 있었다. - Figma의 Comments 기능을 통해 다음 작업을 한 공간에서 처리했다. - 디자인에 대한 의견 교환 - 사용자 인터랙션 설명 - 피드백을 반영한 실시간 수정 - 변경 내역과 최신 버전 동기화 - 별도의 파일 다운로드나 프로그램 설치 없이 참여할 수 있어 비디자이너도 구체적인 피드백을 제공하기 쉬웠다. - 모든 피드백이 디자인 파일과 함께 보존되어, 이메일이나 분산된 문서보다 검토 과정의 추적성이 높아졌다. ## 디자이너-개발자 인계 간소화 - 시안이 승인된 뒤에도 이메일이나 Box로 파일을 주고받지 않고 Figma 링크를 사용했다. - 개발자는 브라우저에서 디자인 파일을 열어 별도 도구 없이 사양을 확인했다. - Code Mode를 통해 다음 정보를 확인하거나 내보낼 수 있었다. - 요소의 크기 - 색상 - 패딩 등 간격 - CSS - iOS 및 Android 코드 - 이를 통해 버전 관리 문제와 구현 과정의 추측을 줄이고, 더 빠르고 정확하게 개발할 수 있었다. - Figma는 Photoshop의 디자인 기능과 Google Docs의 협업 방식을 결합하면서도 상대적으로 가볍고 단순한 도구로 평가됐다. ## 클라이언트 프로젝트로의 확장 - Xfive는 이번 리디자인을 Figma를 실제 고객 프로젝트에 적용하기 위한 시험대로 삼았다. - 향후에는 기능성 프로토타입을 팀원과 고객에게 공유하고 실시간으로 협업할 수 있다고 보았다. - PDF나 JPEG를 이메일에 첨부해 디자인 아이디어를 전달하던 기존 방식에서 벗어나: - 프로토타입 공유 - 구현 세부사항 논의 - 개발자 인계 를 하나의 플랫폼에서 처리하려 했다. 전담 디자이너가 없는 조직이라도 브라우저 기반 도구와 명확한 협업 프로세스를 갖추면 웹 리디자인을 진행할 수 있다. 특히 Figma는 디자인 검토부터 개발 사양 확인까지 연결하므로, 여러 부서와 외부 고객이 함께 참여하는 프로젝트에 유용한 선택지다.

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

CSSFigma사용자 경험프로토타이핑+4

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

팀을 Figma로 전환하도록 설득

Figma 도입은 단순히 디자인 도구를 바꾸는 일이 아니라, 디자인을 조직 내 협업과 의사결정의 중심으로 끌어오는 문화적 변화다. Buffer의 James Morris는 전사 탐색 기간을 마련하고, 실제 화이트보딩과 엔지니어 협업을 통해 구성원들이 Figma의 가치를 직접 경험하게 했다. 클라우드 기반의 공유성, 플랫폼 독립성, 실시간 협업, 개발자용 디자인 데이터 제공이 전환의 핵심 동력이었다. ## 디자인 도구가 협업을 가로막은 문제 - Buffer는 투명성을 중시하는 조직이었지만, 기존 디자인 도구는 디자인팀을 다른 부서와 분리했다. - 디자인 파일이 Dropbox의 깊은 하위 폴더에 묻혀 필요한 자료를 찾기 어려웠다. - 파일을 열려면 특정 데스크톱 소프트웨어나 최신 버전, 유료 라이선스가 필요했다. - 개발자와 PM은 실수로 원본을 덮어쓸까 봐 파일을 열기조차 꺼렸다. - Linux를 사용하는 엔지니어는 디자인 파일을 보기 위해 Mac을 구매해야 할 수도 있었다. ## Figma가 제공한 협업 방식 - 클라우드에서 실행되므로 파일을 URL 하나로 공유할 수 있다. - 무료 보기 전용 계정을 통해 누구나 디자인을 확인하고 댓글을 남길 수 있다. - 디자이너와 개발자, PM이 동일한 파일을 보며 소통할 수 있다. - 디자인 파일이 특정 운영체제나 데스크톱 애플리케이션에 종속되지 않는다. - 하나의 공유 URL이 디자인의 기준점이 되어, 이미지로 내보내거나 Dropbox 경로를 설명할 필요가 줄어든다. ## 1단계: 전사적인 탐색 기간 마련 - James는 처음부터 Figma 도입을 강요하지 않고, 회사 전체에 ‘탐색 기간’을 제안했다. - 각 팀이 여러 디자인·협업 도구를 직접 사용해 보고 자신들의 요구에 맞는 도구를 평가하도록 했다. - 이 과정에서 Buffer의 업무 흐름과 협업 문제에 대한 구성원들의 피드백을 수집했다. - Figma의 장점을 일방적으로 주장하기보다, 실제 사용을 통해 기능이 증명되도록 했다. ## 2단계: 설명보다 직접 경험하게 하기 ### PM과의 원격 화이트보딩 - 원격 근무 환경에 맞춰 PM과 Figma에서 실시간 가상 화이트보딩을 진행했다. - 문서에 글을 쓰는 대신 도형을 사용해 기능 아이디어와 협업 방식을 함께 구상했다. - 별도의 공식 기획서가 완성될 때까지 기다리지 않고, 디자이너와 PM이 즉시 아이디어를 시각화할 수 있었다. - Figma의 직관성과 실시간 협업 기능을 자연스럽게 체험하게 한 사례다. ### 엔지니어 설득 - 개발자들에게 장황하게 설명하는 대신 파일 URL을 전달하고 필요한 정보를 직접 찾아보게 했다. - 무료 보기 전용 기능으로 CSS, iOS용 Swift, Android용 XML 관련 디자인 데이터를 확인할 수 있었다. - 개발자는 별도의 애플리케이션을 설치하거나 라이선스를 구매하지 않고 디자인을 열 수 있었다. - URL이 동일하게 유지되는 ‘단일 진실의 원천(source of truth)’이 되어 디자인 전달과 위치 확인이 쉬워졌다. - Figma가 WebAssembly를 활용해 브라우저 성능을 개선했다는 점도 엔지니어들의 기술적 관심을 끌었다. ### 디자이너의 우려 다루기 - 디자이너는 공개적이고 투명한 디자인 작업 방식에 부담을 느낄 수 있다. - 웹 애플리케이션이 데스크톱 도구만큼 빠르게 작동할지 의심할 수도 있다. - 따라서 디자이너에게는 기능 설명보다 실제 성능과 작업 흐름을 직접 보여 주는 접근이 필요하다. - 글에서 제시된 전략의 핵심은 각 직군이 중요하게 여기는 가치에 맞춰 Figma를 소개하는 것이다. 조직의 도구 전환을 성공시키려면 “새 도구가 더 좋다”고 주장하기보다, 구성원들이 자신의 업무에서 문제 해결 효과를 직접 확인하게 해야 한다. 특히 원격·다직군 협업 환경에서는 공유 가능한 단일 작업 공간과 운영체제에 구애받지 않는 접근성이 도입의 강력한 근거가 된다.

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

CSSFigmaAndroidwebassembly+3

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

더 많은 시간, 더 많은

Unfold는 Figma를 도입해 디자인 파일 버전 충돌, 피드백 분산, 개발자 핸드오프 문제를 크게 줄였다. 클라우드 기반 협업과 브라우저 접근성 덕분에 커뮤니케이션에 쓰는 시간이 약 30% 감소했고, 더 빠르게 프로젝트를 진행하며 더 많은 고객을 맡을 수 있게 됐다. 이 글은 에이전시 업무를 하나의 협업 플랫폼으로 통합하는 것이 시간과 비용 절감으로 이어진다는 점을 보여준다. ## 여러 버전과 협업 문제의 해소 - Unfold는 디자이너, 개발자, 마케터, 프로젝트 매니저, 고객 등 다양한 관계자가 참여하는 프로젝트를 진행했다. - 서로 다른 컴퓨터와 운영체제, 각기 다른 디자인 도구를 사용하면서 파일 덮어쓰기와 버전 충돌이 자주 발생했다. - 문제를 해결하기 위해 여러 플러그인을 조합했지만, 단순한 작업에도 복잡한 도구 체계가 필요했다. - Figma는 클라우드에서 작동하므로 모든 사람이 같은 최신 파일에 접근할 수 있고, URL 하나만 공유하면 협업이 가능했다. - Unfold는 버전 관리와 피드백 과정이 단순해지면서 커뮤니케이션에 소요되는 시간이 최소 30% 줄었다고 평가했다. ## 하나의 공간으로 통합된 디자인 프로세스 - Figma는 디자인, 프로토타이핑, 피드백, 개발자 전달을 한 플랫폼 안에서 처리한다. - 기존 Sketch 파일은 Figma의 Sketch importer로 가져올 수 있어 기존 프로젝트를 이전하기 쉬웠다. - 새로운 프로젝트에서는 Figma의 multiplayer 기능을 활용해 팀과 고객이 하나의 문서에서 동시에 아이디어를 스케치했다. - 여러 사람이 실시간으로 참여할 수 있어 초기 브레인스토밍 속도가 빨라졌다. - 무드 보드에는 색상 팔레트, 글꼴 후보, 시각적 레퍼런스를 함께 배치할 수 있었다. - 웹에서 이미지를 문서로 바로 드래그 앤 드롭할 수 있어 파일을 저장하고 다시 업로드하는 과정이 사라졌다. ## 문맥을 유지하는 피드백 - 디자인 파일은 항상 같은 URL에서 최신 상태로 공유됐다. - 디자이너가 파일을 내보내거나 고객에게 새 버전을 업로드할 필요가 없었다. - 고객은 Figma의 댓글 기능으로 원하는 시점에 피드백을 남길 수 있었다. - 댓글이 관련 디자인 프레임에 고정되므로 Slack이나 이메일에 흩어진 피드백보다 맥락을 파악하기 쉬웠다. - 고객 입장에서도 “모든 작업이 한곳에 있다”는 점이 Figma 도입을 설득하는 간단한 장점이 됐다. ## 개발자 핸드오프의 간소화 - 기존에는 Mac을 사용하지 않는 고객의 개발자에게 별도 도구나 구독을 요구해야 했다. - 디자인 파일을 PSD로 변환하기 위해 Illustrator를 거치면서 레이어가 손상되는 문제도 발생했다. - Figma에서는 운영체제와 관계없이 브라우저로 디자인을 확인할 수 있다. - 개발자는 코드 모드에서 에셋과 CSS, Android, iOS 관련 정보를 확인하거나 내보낼 수 있다. - 클라우드의 최신 디자인과 개발자에게 제공되는 정보가 자동으로 연결되어 별도의 동기화가 필요 없다. - 개발자는 보기 전용 권한만으로도 필요한 정보를 확인할 수 있어 고객의 추가 비용 부담도 줄었다. ## 더 많은 프로젝트를 맡을 수 있게 된 효과 - Figma 도입 후 Unfold는 전체 프로세스의 마찰과 반복 작업이 줄어 프로젝트를 더 빨리 완료할 수 있었다. - 작업 흐름이 자연스러워져 팀원들이 도구 자체보다 디자인과 문제 해결에 집중할 수 있었다. - 시간 절약뿐 아니라 협업 경험이 편해진 점도 생산성 향상의 중요한 요인으로 작용했다. - 결과적으로 같은 인력으로 더 많은 업무를 수용할 수 있다는 자신감을 얻었다. 에이전시처럼 내부 팀과 외부 고객, 개발자가 동시에 참여하는 환경에서는 파일 형식보다 **접근성, 단일 최신본, 문맥 기반 피드백, 개발자용 정보 제공**이 중요하다. 따라서 협업 도구를 선택할 때는 개별 기능보다 전체 업무 흐름을 얼마나 하나로 연결하고 반복 커뮤니케이션을 줄이는지 평가하는 것이 좋다.

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

CSSFigma프로토타이핑Android+4

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

피그마 2.0:

Figma 2.0은 디자이너 간 협업을 넘어 마케팅, 경영진, 개발자까지 포함한 전체 팀의 협업을 목표로 한다. 이를 위해 디자인 파일과 발표용 프로토타입을 연결하는 프로토타이핑 기능과, 개발자가 디자인 정보를 직접 확인하는 개발자 핸드오프 기능을 추가했다. 핵심은 내보내기·동기화·버전 관리 같은 중간 단계를 줄이고 하나의 클라우드 문서를 모든 팀원이 함께 사용하는 것이다. ## 디자이너 협업에서 전체 팀 협업으로 - Figma 1.0은 클라우드 기반 디자인 환경을 구축하는 데 초점을 맞췄다. - 저장, 내보내기, 동기화, 이메일 공유가 거의 필요 없다. - 여러 사용자가 동시에 편집하는 멀티플레이어 기능을 제공한다. - 팀 단위 컴포넌트 라이브러리로 디자인 요소를 공유할 수 있다. - Figma 2.0에서는 협업 범위를 디자이너 밖으로 확장했다. - 마케팅 부서, 경영진, 엔지니어 등 다양한 이해관계자가 같은 디자인 자료를 활용할 수 있다. - 제품 개발 전반에서 하나의 진실 공급원(single source of truth)을 유지하는 것이 목표다. ## 클라우드 기반 프로토타이핑 - 디자이너가 디자인을 별도 도구로 내보내지 않고 같은 장소에서 발표와 테스트까지 진행할 수 있다. - 주요 활용 목적은 다음과 같다. - 디자인 리뷰와 피드백 - 경영진 대상 프레젠테이션 - 사용자 인터랙션 테스트 - Figma는 고급 모션 그래픽보다 슬라이드쇼와 핫스팟 기능을 우선적으로 제공했다. - 프로토타입은 정적인 결과물이 아니라 원본 디자인과 연결된 “살아 있는 문서”로 동작한다. - 원본 프레임을 수정하거나 화면을 추가하면 발표 화면에도 실시간 반영된다. - 별도의 내보내기나 동기화가 필요 없다. - 프레임을 노드로 연결해 화면 이동을 구성하고, 개별 객체를 핫스팟으로 설정할 수 있다. - 컴포넌트에 핫스팟을 지정하면 해당 컴포넌트의 모든 인스턴스에 내비게이션 동작이 적용된다. - 프레임 순서를 정해 간단한 프레젠테이션으로 사용할 수도 있다. - 발표자는 휴대폰으로 프레젠테이션을 탐색할 수 있다. - 아트보드 순서를 맞추기 위한 복잡한 파일명이나 버전 관리가 줄어든다. - 다만 모든 프로토타이핑 시나리오를 지원하는 것은 아니며, Framer 같은 전문 도구와의 연동도 계속 추진할 계획이다. ## 개발자 핸드오프 - 디자이너는 개발자에게 파일을 보기 전용(view-only)으로 공유할 수 있다. - 개발자는 편집 권한 없이도 오른쪽 속성 패널의 ‘Code’ 모드에서 디자인 정보를 확인할 수 있다. - 객체를 선택하면 다른 객체와의 간격을 빨간색 측정선(redline)으로 확인할 수 있다. - 다음 플랫폼에 필요한 정보를 추출할 수 있다. - CSS - iOS - Android - 정보는 두 가지 방식으로 제공된다. - **테이블 보기:** 속성을 항목별로 나누어 빠르게 확인 - **생성된 코드 보기:** 구현에 활용할 수 있는 마크업 및 코드 제공 - 개발자가 편집자 좌석을 구매하지 않아도 되므로 팀의 비용 부담을 줄일 수 있다. - 디자인 파일 자체를 기준으로 치수와 스타일 정보를 확인하므로, 별도의 스펙 문서나 수동 전달 과정이 줄어든다. ## 하나의 문서로 줄어드는 추상화 계층 - 기존에는 디자인 파일, 프로토타이핑 도구, 발표 자료, 개발자용 스펙 문서가 분리될 수 있었다. - Figma 2.0은 디자인과 발표, 디자인과 구현 사이의 변환 단계를 줄인다. - 원본 디자인이 수정되면 연결된 프로토타입과 공유 정보에도 즉시 반영된다. - 팀 구성원마다 별도의 파일이나 도구를 관리하는 대신, 클라우드 문서를 중심으로 협업할 수 있다. ## 확장되는 도구 생태계 - Figma는 모든 팀의 워크플로를 하나의 제품으로 대체하려 하기보다 다양한 도구와 함께 작동하는 생태계를 지향한다. - 전문 프로토타이핑 도구 및 다른 협업 도구와의 통합과 파트너십을 다음 단계로 제시했다. - 궁극적인 목표는 더 나은 소프트웨어를 함께 만들 수 있도록 팀 전체의 협업 장벽을 낮추는 것이다. 실무적으로는 디자인 파일을 단순한 작업물이 아니라 발표·검토·개발의 기준 문서로 운영하는 방식이 Figma 2.0의 가장 큰 장점이다. 팀은 프로토타입과 개발자 핸드오프를 같은 파일에서 관리하고, 개발자에게는 필요한 최소 권한인 보기 전용 접근을 제공하는 것이 효과적이다.

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

CSSFigma프로토타이핑Android+3