Figma

532 개의 포스트

figma3분 읽기큐레이션 요약

니콜 뵈쳐의 피그

니콜 부에처는 전직 UX·제품 디자이너로서 Figma를 활용해 퀼트를 설계하고, 디지털 디자인의 반복·측정·최적화 방식을 수공예에 적용한다. 그녀는 천을 자르기 전에 퀼트의 약 80%를 Figma에서 완성하며, 색상 조합과 패턴을 빠르게 실험하고 필요한 원단 수량과 재단 순서까지 계획한다. Figma는 창의적인 퀼트 작업을 체계화하면서도, 재료와 시간을 절약하게 해주는 설계 도구가 된다. ## 손으로 만드는 취미와 디지털 설계의 결합 - 니콜은 2021년 팬데믹으로 업무 방식이 바뀌면서 손을 사용하는 새로운 공예를 찾기 시작했다. - Artsy에서 2년 반 동안 제품 디자이너로 일한 경험이 있으며, 이전에도 간단한 봉제 작업은 했지만 퀼트 제작은 미뤄두고 있었다. - 온라인 튜토리얼과 초보자용 패턴을 따라 하며 독학했고, 실력이 늘면서 더 큰 퀼트를 만들게 됐다. - 직접 패턴을 설계할 단계가 되자 익숙한 도구인 Figma를 사용하기 시작했다. ## UX 경험을 바탕으로 한 계획적 제작 - 니콜은 천을 자르기 전에 퀼트 디자인의 약 80%를 Figma에서 완성한다. - UX 디자인과 엔지니어링용 에셋 준비 경험 때문에 즉흥적으로 만들기보다 먼저 구조와 치수를 계획하는 편이다. - 퀼트 제작은 각 조각을 1/4인치 단위로 측정해야 하므로, 정확한 크기 조정이 가능한 Figma가 적합하다. - 스케치나 종이 조각을 직접 옮기는 방식보다 도형의 비율과 배치를 빠르게 수정할 수 있다. ## 색상 라이브러리와 패턴 실험 - 영감은 퀼트 관련 서적과 Instagram에서 얻으며, 전통적인 퀼트 블록을 새로운 패턴으로 변형하는 방식으로 작업을 시작한다. - 이미 가지고 있는 원단을 우선 활용하기 위해 원단 제조사의 색상 견본을 Figma에 모아 색상 라이브러리를 구축했다. - 디자인 파일에서 특정 영역을 선택해 색상이나 패턴을 한꺼번에 바꿀 수 있다. - `Random Colors Fill` 같은 Figma 플러그인을 활용하면 다양한 색상 조합을 빠르게 시험할 수 있다. - 제품 디자인처럼 하나의 퀼트에 대해 수십 가지 버전을 만든 뒤 최종안을 선택한다. ## Figma에서 퀼트 구조 설계하기 - Grid Quilt처럼 격자 구조의 디자인을 Figma에서 먼저 구성한다. - 각 행을 개별적으로 수정하는 대신 Auto Layout을 사용해 여러 행의 배치를 동시에 조정할 수 있다. - 완성된 전체 디자인을 재단과 봉제에 필요한 작은 단위 조각으로 분해한다. - 조각을 어떤 순서로 연결할지까지 시각적으로 확인해 제작 과정을 단순화한다. ## 치수 계산과 원단 낭비 줄이기 - 최종 디자인을 복제한 뒤 사각형과 직사각형 등 원자 단위의 조각으로 나눈다. - `Count Things` 플러그인으로 필요한 조각의 개수를 계산한다. - 예: 청록색 직사각형 189개, 황갈색 정사각형 378개 등 - Figma의 픽셀 크기를 실제 인치 단위와 대응시켜 재단에 필요한 치수를 산출한다. - 봉제선 여유분을 고려해 각 조각의 양쪽에 1/4인치를 추가한다. - 필요한 원단의 총 길이를 계산하고, 조각을 최대한 효율적으로 배치해 불필요한 자투리 원단을 줄인다. - 어떤 조각을 먼저 봉제할지 다시 조정해 전체 작업 단계를 최소화한다. ## 디지털 도구가 공예에 주는 의미 - Figma는 단순한 화면 디자인 도구가 아니라 실제 재료를 다루는 제작 과정의 계획 도구로 활용된다. - 반복적인 시안 제작, 정확한 치수 계산, 색상 관리, 재단 최적화를 하나의 파일 안에서 처리할 수 있다. - 디지털 설계의 효율성이 수작업의 섬세함을 대체하는 것이 아니라, 수작업에 더 많은 시간과 집중력을 투입하도록 돕는다. - 니콜의 사례는 특정 산업을 위해 만들어진 도구도 사용자의 창의적인 방식에 따라 전혀 다른 제작 분야로 확장될 수 있음을 보여준다. 실용적으로는 퀼트처럼 규격과 반복이 중요한 작업을 시작할 때 Figma에서 색상 견본, 실제 치수, 조각 수량, 조립 순서를 먼저 관리하면 시행착오와 재료 낭비를 크게 줄일 수 있다.

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

기능 비하인드:

Figma는 프로토타입을 실제 기기에서 사용하는 경험에 가깝게 만들기 위해 모바일·태블릿·워치용 **인라인 디바이스 프레임**을 에디터 안에 도입했다. 사용자는 프레젠테이션 화면으로 이동하지 않고도 디자인 옆에서 기기 프레임을 배치·이동·크기 조절하며 프로토타입을 확인할 수 있다. 이 기능은 다양한 기기 형태를 반영하면서도 자연스러운 상호작용과 협업 중심의 디자인 프로세스를 유지하는 것을 목표로 개발됐다. ## 프로토타이핑을 현실에 가깝게 만드는 이유 - 실제 기기를 손에 들고 화면과 플로우를 확인하면 제품이 실제로 어떻게 작동하는지 더 잘 이해할 수 있다. - 프로토타입은 개발 전에 사용성 문제, 설계의 빈틈, 개선 기회를 발견하게 해준다. - Figma는 2023년 Config에서 실시간으로 프로토타입을 확인하는 **인라인 프리뷰**를 선보였고, 이후 기기 프레임까지 에디터 내부로 확장했다. - 프레젠테이션 뷰로 이동하지 않아도 디자인 작업과 실제 기기 맥락 확인을 동시에 할 수 있게 된 것이 핵심이다. ## 협업을 기반으로 한 기능 설계 - Figma는 기존 프레젠테이션 뷰에서 제공하던 다양한 기기 프리셋이 인기가 높다는 점에 주목했다. - 이를 에디터 안으로 가져와 디자인 옆에서 휴대폰, 태블릿, 워치 프레임을 사용할 수 있도록 했다. - 제품 디자이너, 엔지니어, 제품 관리자, 마케팅 담당자와 사용자 커뮤니티의 의견을 함께 반영했다. - 개발 과정에서 세운 핵심 원칙은 다음과 같다. - 디자인 작업 흐름에 자연스럽게 통합할 것 - 다양한 실제 기기를 현실적으로 표현할 것 - 기기의 상호작용 영역을 직관적으로 설계할 것 - 목표는 단순한 정적 이미지가 아니라, 사용자가 잡고 이동하고 크기를 조절할 수 있는 반응형 기기를 에디터 안에 구현하는 것이었다. ## 다양한 기기 형태의 표현 - 인라인 프리뷰 공간의 제약 때문에 초기 대상은 개인용 컴퓨터보다 상대적으로 작은 모바일, 태블릿, 워치로 한정했다. - 기기마다 화면 비율과 외형이 다르므로 하나의 고정된 프레임으로는 다양한 사용 환경을 표현하기 어렵다. - 스마트폰의 카메라와 센서를 수용하기 위해 화면 일부가 파인 **노치(notch)** 같은 요소도 고려해야 했다. - 화면뿐 아니라 기기 외곽, 모서리, 센서 영역 등 실제 사용 경험을 구성하는 시각적 요소를 함께 재현해야 했다. ## 자연스러운 크기 조절과 상호작용 - 인라인 디바이스 프레임은 디자인 요소처럼 에디터 안에서 이동하고 크기를 조절할 수 있어야 했다. - 특히 워치처럼 외형이 작고 복잡한 기기는 어느 영역을 드래그하거나 조작할 수 있게 할지 결정하기 어려웠다. - 프레임의 상호작용 가능한 영역, 즉 **히트 타깃**을 명확하고 직관적으로 설계하는 것이 중요한 과제였다. - 기기마다 형태가 다르더라도 사용자가 별도의 학습 없이 동일한 방식으로 조작할 수 있도록 상호작용 규칙을 정리해야 했다. ## 프로토타이핑 기능 전반의 개선 - 인라인 디바이스 프레임과 함께 여러 프로토타이핑 개선 사항도 제공됐다. - 연결선을 복사·붙여넣기해 인터랙션을 빠르게 복제할 수 있다. - 플로우를 빠르게 삭제하는 기능이 추가됐다. - 로컬 변수가 포함된 요소를 새 파일로 쉽게 가져올 수 있는 고급 기능도 제공됐다. - 주요 사용 사례에서 로딩 스피너가 나타나는 시간이 22% 줄어 성능도 개선됐다. 실무에서는 모바일·태블릿·워치 화면을 설계할 때 인라인 디바이스 프레임을 활용해 디자인과 실제 사용 맥락을 동시에 검토하는 것이 유용하다. 특히 기기별 화면 비율, 노치, 워치의 작은 터치 영역처럼 실제 환경에서 발생하는 문제를 개발 전에 확인하는 데 적합하다.

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

원활한 핸드오프를

핸드오프는 디자인이 끝나는 한순간의 전달이 아니라, 작업 중인 디자인과 맥락·커뮤니케이션이 지속적으로 오가는 과정이다. 원활한 협업을 위해서는 개발자가 필요한 정보를 명확히 확인할 수 있도록 주석을 정리하고, 디자인·개발 간 공통 언어를 만들며, 파일 구조를 체계적으로 정리해야 한다. 특히 “Ready for dev”가 실제 구현 가능한 상태를 의미하도록 팀의 기준과 작업 방식을 맞추는 것이 중요하다. ## 주석과 콜아웃을 간결하고 명확하게 정리하기 - 주석은 디자인 결정의 의도와 개발자가 놓치기 쉬운 세부 사항을 전달하는 수단이다. - 모든 간격이나 색상을 반복해서 설명하기보다, 이미 변수나 스타일로 정의된 정보는 생략하고 다음과 같은 내용을 우선적으로 표시한다. - 새로 사용하는 컴포넌트 - 프로토타입만으로는 명확하지 않은 인터랙션 - 플랫폼별로 다르게 보여야 하는 요소 - 특정 레이어의 속성, 크기, 동작 방식 - 개발자와 먼저 어떤 정보가 유용한지 합의하면 불필요한 주석을 줄일 수 있다. - Figma의 annotations와 Dev Mode를 활용하면 스펙, 측정값, 설명을 최종 디자인에 직접 고정할 수 있다. - 주석은 디자이너와 개발자 간 대화를 대체하는 것이 아니라, 대화가 필요한 지점을 명확하게 해 커뮤니케이션을 개선한다. ## 디자인과 개발의 공통 언어 만들기 - 디자인과 개발은 서로 다른 분야이므로 같은 용어가 다른 의미로 해석될 수 있다. - 예를 들어 디자이너가 “toggle”이라고 했을 때 개발자가 “switch”를 떠올릴 수 있다. - 프로젝트 초기에 컴포넌트와 속성의 명칭을 합의하면 이후 구현 논의에서 불필요한 혼선을 줄일 수 있다. - 색상, 폰트, 간격처럼 기초적인 디자인 요소는 변수와 스타일로 관리해 디자인과 코드가 동일한 기준을 사용하도록 한다. - 개발팀에 이미 네이밍 규칙이 있다면 디자인 시스템에도 이를 반영하는 것이 좋다. - 예를 들어 `bg-primary-active`, `body text`처럼 공유된 명칭을 사용하면 특정 색상의 헥스 코드나 폰트 세부 정보를 매번 설명하지 않아도 된다. - 디자인 시스템의 색상 휠과 같은 도구를 활용하면 색조와 명도를 일관되게 선택하고 적용할 수 있다. ## 파일과 캔버스를 라벨로 정리하기 - Figma의 무한 캔버스는 아이디어를 자유롭게 펼치기 좋지만, 개발자가 처음 파일을 열었을 때 필요한 화면을 찾기 어렵게 만들 수 있다. - 브레인스토밍과 반복 작업 단계에서는 파일이 다소 복잡해도 괜찮지만, 개발에 넘길 시점에는 구조를 정리해야 한다. - 관련 디자인을 섹션으로 묶어 캔버스 내 탐색 범위를 좁힌다. - 구현이 준비된 섹션이나 프레임에는 “Ready for dev” 상태를 표시해 개발자가 우선 확인할 대상을 알 수 있게 한다. - 팀 차원에서 동일한 파일 템플릿을 사용하면 매번 구조를 새로 파악해야 하는 부담과 컨텍스트 전환을 줄일 수 있다. 실무에서는 주석을 많이 다는 것보다 필요한 정보만 남기고, 변수·스타일·공통 명칭을 디자인 시스템에 정착시키는 것이 효과적이다. 또한 개발 전달 전에는 파일을 정리하고 구현 범위를 명확히 표시해 “Ready for dev”가 팀 내에서 실제로 신뢰할 수 있는 상태가 되도록 관리하는 것이 좋다.

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

Figma와 Jira로 디

제품 개발의 속도와 품질을 높이려면 디자이너와 개발자가 같은 맥락을 공유하며 협업할 수 있는 도구·프로세스·의식이 필요하다. 특히 하이파이 인터랙티브 프로토타입과 Figma-Jira 연동은 디자인 의도를 코드로 옮기는 과정의 오해와 단절을 줄이고, 대면·비동기 협업 모두에서 팀의 ‘플로우’를 유지하도록 돕는다. 규모가 커지고 하이브리드 근무가 일반화될수록 지속적인 정렬과 명확한 정보 공유가 중요해진다. ## 제품 개발에서 ‘플로우’가 중요한 이유 - 플로우는 구성원이 특정 활동에 깊이 몰입해 효율적으로 작업하는 상태다. - 제품 속도는 올바른 기능을 빠르게 출시하는 능력이지만, 조직이 커질수록 유지하기 어렵다. - 속도는 저절로 생기지 않으며, 다음과 같은 기반이 필요하다. - 협업 도구 - 작업 프로세스 - 팀의 정기적인 커뮤니케이션과 의식 - 폴 그레이엄의 ‘메이커의 일정과 매니저의 일정’처럼 디자이너와 개발자는 짧은 단위의 잦은 회의보다 방해받지 않는 긴 작업 시간이 필요하다. - 하이브리드 환경에서는 알림, 일정, 변화하는 요구사항 때문에 개인과 팀 모두 플로우를 잃기 쉬우므로 협업 기반을 먼저 정비해야 한다. ## 고해상도 프로토타입으로 디자인과 개발의 언어 통일 - 회사가 커질수록 팀과 업무가 사일로로 분리되고, 원격·하이브리드 근무로 구성원 간 맥락 공유가 어려워진다. - 같은 용어도 디자이너와 개발자가 서로 다르게 이해할 수 있지만, 실제로 작동하는 프로토타입을 보면 의도를 더 정확히 공유할 수 있다. - One.com은 덴마크의 디자인 팀과 인도의 개발 팀이 정기적으로 요구사항, 장애물, 잠재적 문제를 논의한다. - 새로운 텍스트 기능을 논의할 때 Figma의 하이파이 프로토타입을 사용해 개발자들이 인터랙션 상태를 직접 확인했다. - 정적·로우파이 프로토타입이 전체적인 디자인 방향을 보여준다면, 인터랙티브 하이파이 프로토타입은 다음과 같은 구현 세부사항을 전달한다. - 사용자 플로우가 어떻게 진행되는지 - 창이나 모달이 언제 나타나는지 - 드롭다운이 어떻게 동작하는지 - 최종 제품에서 각 상태가 어떻게 연결되는지 - 여러 페이지를 복잡하게 연결해야 했던 기존 방식과 달리, 하나의 Figma 파일 안에서 전체 경험을 확인하고 검토할 수 있다는 점이 장점이다. ## 회의 이후에도 유지되는 비동기 협업 맥락 - 프로토타입은 회의 중 합의만 돕는 것이 아니라, 회의에 참석하지 못한 구성원에게도 결정의 맥락을 보존한다. - 원격·비동기 환경에서는 회의에서 무엇을 확인하고 결정했는지가 이후 작업의 효율을 좌우한다. - Condé Nast의 제품 개발 팀은 매일 스탠드업을 진행해 다음을 공유한다. - 현재 진행 상황 - 우선순위 - 예상되는 장애물 - 팀이 확인해야 할 질문 - 이러한 정기적인 정렬은 팀이 서로 다른 방향으로 작업하는 것을 방지하고, 문제를 조기에 드러내도록 한다. ## Figma와 Jira를 통한 디자인-개발 연결 - 디자인이 코드로 전환되는 과정에서는 디자인 파일, 개발 작업, 요구사항이 서로 다른 위치에 흩어지기 쉽다. - Figma for Jira는 Jira 작업 항목에 디자인 맥락을 연결해 개발자가 구현 시 필요한 정보를 더 쉽게 확인하도록 지원한다. - 글은 업데이트된 Figma for Jira 앱을 소개하면서, 제품 개발팀이 디자인과 개발 워크플로를 더 가깝게 연결하는 방법을 설명한다. - 핵심 목적은 단순히 디자인 링크를 첨부하는 것이 아니라, 개발자가 디자인의 배경과 동작 방식을 함께 이해하도록 하는 데 있다. ## 실천을 위한 시사점 - 기능 구현 전에 정적 화면보다 실제 인터랙션을 포함한 프로토타입으로 논의한다. - 디자인 리뷰에는 개발자를 참여시켜 상태 변화와 예외 흐름까지 함께 확인한다. - 회의에서 결정한 내용은 프로토타입과 작업 티켓에 남겨 비동기 작업에서도 맥락이 유지되게 한다. - Figma와 Jira를 연결해 디자인 의도, 요구사항, 개발 진행 상황을 하나의 흐름으로 관리한다.

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

원활한 피그마 마이

Figma 마이그레이션은 단순히 디자인 도구를 교체하는 일이 아니라, 협업 방식과 조직 문화를 바꾸는 변화 관리 과정이다. 성공하려면 계획 수립부터 커뮤니케이션, 라이브러리 재구축, 교육과 온보딩까지 여러 단계를 체계적으로 준비해야 한다. 특히 부서 간 대표로 구성된 옹호 팀과 조직 전체의 공감대가 핵심이다. ## 도구 교체가 아닌 변화 관리 - Figma 도입의 주요 목적은 협업 강화, 작업의 투명성 향상, 프로세스 간소화다. - 마이그레이션은 디자이너만의 과제가 아니라 개발자, 제품 관리자, 이해관계자 등 모든 구성원이 참여해야 한다. - 기존 업무 방식과 조직 문화를 새로운 협업 방식에 맞게 조정해야 한다. - 계획, 커뮤니케이션, 재구축, 온보딩, 문화적 규범 정착을 단계적으로 추진해야 한다. ## 부서 간 Figma 옹호 팀 구성 - 개발, 제품 관리, 디자인 시스템, 주요 이해관계자 등 다양한 부서의 구성원을 핵심 팀으로 참여시킨다. - 옹호 팀의 주요 역할은 다음과 같다. - 조직의 요구사항을 수집하고 균형 잡힌 피드백 제공 - 전체 조직에 적합한 Figma 워크스페이스 구성 - 마이그레이션 관련 공지와 커뮤니케이션 관리 - 기존 라이브러리와 컴포넌트 이전 감독 - Figma 사용 경험이 많거나 변화에 적극적인 사람을 중심으로 구성하는 것이 효과적이다. - Wells Fargo는 숙련자와 열성 사용자를 “Figma Jedis”로 조직했고, JPMorgan Chase는 디자인 시스템에 관심 있는 인재를 리더십과 여러 부서에서 추천받았다. - Uber는 기존 디자인 시스템 워크숍에 Figma 기초 교육과 데모를 결합해 점진적으로 도입했다. ## 부서별 지지와 리더십의 동의 확보 - 디자인 팀뿐 아니라 개발자, 제품 관리자, 경영진과 이해관계자의 동의를 초기부터 확보해야 한다. - 도입 제안서에는 기존 도구와 Figma의 장단점, 예상 효과, 비용과 운영상의 변화를 명확히 정리한다. - Dropbox는 다음과 같은 방식으로 조직의 참여를 이끌었다. - 워크숍 개최 - 모범 사례 공유 - 라이브러리와 컴포넌트의 조기 공개 - 팀별 실습과 교육 제공 - 구성원이 실제 결과를 미리 경험하도록 하면 도구 교체에 대한 저항을 줄일 수 있다. - Figma Migration Toolkit과 같은 자료를 활용해 다른 디자인 도구에서 이전할 때 필요한 지침을 표준화할 수 있다. ## 다른 조직의 경험 활용 - 비슷한 규모와 복잡성을 가진 조직의 마이그레이션 사례를 조사하면 시행착오를 줄일 수 있다. - 이미 Figma를 도입한 팀에 직접 문의해 다음 정보를 얻을 수 있다. - 교육 프로그램 구성 - 단계별 도입 플레이북 - 파일과 프로젝트를 정리하는 커버 페이지 방식 - 피해야 할 운영 방식 - 대규모 배포 시 발생한 문제와 해결책 - Wells Fargo의 사례처럼 외부 조직의 실전 경험을 참고하면 대규모 롤아웃 계획을 구체화하는 데 도움이 된다. - Workday, Uber, Dropbox 등의 사례와 마이그레이션 관련 라이브스트림도 참고 자료로 활용할 수 있다. ## 현실적인 마이그레이션 일정 수립 - 조직의 업무 일정과 기존 디자인 도구의 계약·사용 종료 시점을 함께 고려해 타임라인을 작성한다. - 한 번에 전체 조직을 전환하기보다 준비 상황과 팀별 업무 우선순위에 따라 단계적으로 진행하는 것이 안전하다. - 일정에는 교육, 라이브러리 이전, 파일 정리, 파일럿 운영, 피드백 수집, 전체 배포를 포함해야 한다. - 기존 프로젝트와 신규 프로젝트의 전환 기준을 사전에 정하면 팀 혼란을 줄일 수 있다. Figma 마이그레이션은 도구를 설치하는 프로젝트가 아니라 조직의 협업 체계를 재설계하는 프로젝트로 접근해야 한다. 먼저 부서 간 옹호 팀을 만들고, 리더십과 실무자의 지지를 확보한 뒤, 외부 사례와 단계별 일정을 바탕으로 파일럿부터 시작하는 방식을 추천한다.

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

Dev Mode에 대해 알아

Figma는 디자이너와 개발자가 하나의 파일과 협업 공간에서 더 효율적으로 제품을 만들 수 있도록 Dev Mode를 개발했고, 2024년 1월 베타를 종료했습니다. Dev Mode는 개발자에게 필요한 정보와 도구를 별도 워크스페이스로 제공하면서도 디자인 맥락과 협업은 유지하는 것이 핵심입니다. Figma는 사용자 피드백을 바탕으로 주석, 변경점 비교 등 핸드오프와 구현을 지원하는 기능을 강화했습니다. ## 개발자 중심의 작업 공간이 필요한 이유 - 개발자는 Figma 주간 활성 사용자의 약 3분의 1을 차지했습니다. - 하지만 기존 Figma는 디자인 작업에 최적화되어 있어 개발자의 워크플로, 도구 체계, 선호 사항을 충분히 지원하지 못했습니다. - Figma는 프런트엔드 개발자, 디자인 시스템 엔지니어, 콘텐츠 레이아웃 및 에셋을 다루는 개발자 등 다양한 역할을 고려해 개발자 전용 경험을 만들고자 했습니다. - 핵심 방향은 개발자가 디자인 모드의 모든 상호작용을 학습하지 않아도 되도록, 개발자에게 필요한 방식으로 Figma를 맞추는 것이었습니다. ## Visly 인수와 개발자 직관 확보 - Figma는 2021년 React UI 컴포넌트 개발 도구를 만들던 Visly 팀을 인수했습니다. - 8명의 디자이너와 엔지니어로 구성된 Visly 팀은 개발자 도구에 대한 실무 경험과 연구 결과를 보유하고 있었습니다. - Figma는 개발자와 대화하는 것만으로는 부족하며, 실제 개발 환경에 몰입해 얻는 ‘개발자 직관’이 필요하다고 판단했습니다. - Visly 팀은 개발자가 Figma를 사용하는 실제 방식과 다양한 개발 환경에 대한 관점을 제공했습니다. ## 디자인과 개발을 연결하는 통합 모드 - Dev Mode의 형태를 결정하는 과정에서 디자인 파일과 개발 파일을 완전히 분리할지, 하나로 통합할지 오랜 기간 검토했습니다. - 최종적으로 Dev Mode를 Figma 안의 별도 공간으로 구현했습니다. - 개발자는 개발에 최적화된 인터페이스를 사용하면서도 디자인 파일, 변경사항, 디자이너의 의도 같은 중요한 맥락을 그대로 확인할 수 있습니다. - 별도 도구나 파일로 전환하지 않고 디자인 공간과 개발 공간을 오갈 수 있다는 점이 핵심입니다. ## 오픈 베타와 사용자 피드백 - Dev Mode는 Config 2023에서 오픈 베타로 공개되었습니다. - 베타 기간 동안 고객 요청을 적극적으로 수집했고, 처음 두 달 동안 가장 많이 요청된 업데이트와 수정 사항 200개 이상을 배포했습니다. - 사용자 피드백은 Dev Mode의 기능 우선순위와 제품 결정에 직접 반영되었습니다. - 이후 Dev Mode는 베타를 종료하고 정식 제품 단계로 이동했습니다. ## 디자인 의도를 명확히 전달하는 주석 - 기존에는 디자이너가 개발자에게 필요한 치수와 설명을 수동으로 만들고 디자인을 별도로 정리해야 했습니다. - Dev Mode의 주석 기능은 디자인에 직접 연결된 설명, 사양, 측정값을 제공합니다. - 디자인이 변경되면 주석도 실시간으로 업데이트되어 최신 상태를 유지할 수 있습니다. - 캔버스를 복잡하게 만들지 않으면서 중요한 세부사항을 강조할 수 있습니다. - 플러그인을 이용해 주석을 자동화하거나 사용자 지정할 수 있습니다. - 클릭하고 드래그하는 방식으로 요소 간 거리를 측정할 수 있습니다. ## 개발 준비 상태와 변경점 비교 - 디자이너는 섹션을 “개발 준비 완료(ready for development)”로 표시하고 별도의 페이지나 파일 없이 개발자에게 전달할 수 있습니다. - 변경점 비교(diff) 기능을 사용하면 서로 다른 버전의 프레임을 비교할 수 있습니다. - 이를 통해 디자인 변경 사항을 확인하고, 개발자가 최신 디자인을 기준으로 작업하도록 지원합니다. - 목적은 디자인 핸드오프 과정에서 누락되는 설명이나 변경사항을 줄이고 구현 정확도를 높이는 것입니다. Dev Mode를 효과적으로 활용하려면 디자인과 개발을 별도 도구로 분리하기보다, 디자인 파일 안에서 주석·측정값·준비 상태·변경 이력을 일관되게 관리하는 것이 좋습니다. 특히 개발 전달 전에 “개발 준비 완료” 상태와 변경점을 명확히 표시하면 커뮤니케이션 비용을 줄일 수 있습니다.

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

개발 모드 어노테

Figma의 Dev Mode 주석 기능은 디자이너와 개발자 사이에 흩어진 요구사항과 설계 의도를 하나의 공간에 모으기 위해 만들어졌다. 기존 주석은 작성에 시간이 많이 들고 디자인 변경에 따라 쉽게 낡으며 캔버스를 복잡하게 만든다는 문제가 있었다. Figma는 주석을 실제 디자인 속성·측정값·변수·컴포넌트와 연결하고, 캔버스 바깥에서 자동으로 배치해 최신 상태와 가독성을 함께 확보하려 했다. ## 디자이너와 개발자의 서로 다른 요구 - 디자이너는 시각적 결과만으로 표현하기 어려운 정보를 전달해야 한다. - 접근성 속성 - 인터랙션의 세부 동작 - 특정 디자인 결정을 내린 의도 - 개발자에게 디자인 파일은 정보가 지나치게 많아 실제 구현해야 할 부분을 찾기 어려울 수 있다. - 디자인 공유는 전체 파일을 전달하는 것과 다르며, 개발자가 집중해야 할 영역과 요구사항을 선별해 주는 과정이 필요하다. - Figma는 이러한 문제를 해결하기 위해 Dev Mode 안에 개발자용 사양을 큐레이션하는 전용 공간을 마련했다. - 디자이너도 Dev Mode에서 주석을 작성함으로써 개발자가 실제로 보게 될 화면과 맥락을 확인할 수 있고, 작업이 끝난 뒤 Dev Mode 링크를 공유할 수 있다. ## 기존 수동 주석의 한계 - 디자이너는 텍스트, 화살표, 치수선, 콜아웃 등을 직접 배치해야 하므로 주석 작성에 많은 시간이 든다. - 디자인이 변경되면 기존 주석이 수정되지 않아 실제 디자인과 설명 사이에 불일치가 생긴다. - 디자인 파일에 주석을 추가하려면 프레임을 옮기거나 주변 공간을 확보해야 한다. - 주석이 많아질수록 캔버스가 복잡해지고, 개발자가 필요한 정보를 찾기 어려워진다. - 작업이 완전히 확정된 뒤 “개발 준비 완료” 상태를 표시하는 방식에는 적합하지만, 지속적으로 변경되는 제품 개발 과정에는 한계가 있다. ## 디자인 속성과 연결되는 동적 주석 - Figma는 주석을 단순한 텍스트가 아니라 디자인의 실제 속성에 연결하는 방식을 고민했다. - 디자인 변경 시 연결된 주석과 치수선도 함께 갱신되도록 하면 디자이너가 정보를 반복해서 입력할 필요가 줄어든다. - 개발자는 디자이너가 계속 수정 중인 상황에서도 최신 디자인에 기반한 사양을 확인할 수 있다. - 디자인 시스템의 변수와 컴포넌트를 주석에서 직접 참조하면, 일반 텍스트보다 오류 가능성이 낮아진다. - 주석의 정보가 실제 디자인 요소 및 코드베이스와 가까워질수록 설계 사양과 구현 결과의 정합성이 높아진다. ## 캔버스를 어지럽히지 않는 위치 지정 - 기존 방식에서는 주석을 표시할 공간을 만들기 위해 프레임을 계속 재배치해야 했다. - Figma는 주석을 캔버스에 직접 차지시키지 않으면서도 개발자에게 충분히 잘 보이게 하는 방식을 탐색했다. - 최종 방향 중 하나는 주석을 자동으로 배치하고 표시하는 것이었다. - 자동 배치는 디자이너의 수동 정리 작업을 줄이고 개발자에게 더 깔끔한 화면을 제공할 수 있다. - 다만 확대·축소, 이동, 크기 조절, 최소화, 선택, 마우스 오버 등 다양한 상호작용을 고려해야 하므로 여러 프로토타입과 반복적인 조정이 필요했다. - 엔지니어링 팀은 주석 표시 로직을 조정해 다양한 화면 상태에서도 주석이 적절히 보이도록 하는 데 집중했다. ## 실용적인 시사점 Dev Mode의 주석은 디자인이 끝난 뒤 설명을 덧붙이는 문서화 도구라기보다, 변경 중인 디자인과 구현 요구사항을 지속적으로 연결하는 협업 기능에 가깝다. 주석을 작성할 때는 단순한 설명보다 접근성, 상태 변화, 인터랙션, 디자인 토큰처럼 실제 구현에 필요한 정보를 디자인 요소와 연결해 기록하는 것이 효과적이다.

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

개발 모드의 향후 계획

Figma는 Dev Mode 무료 베타 종료를 앞두고 주석, 변경 사항 비교 개선, 플러그인, Jira·VS Code 연동 기능을 공개했다. 이를 통해 디자이너와 개발자 간 핸드오프에 필요한 맥락을 강화하고, 조직별 기술 스택과 디자인 시스템에 맞춘 개발 워크플로를 지원한다. Dev Mode는 2024년 1월 31일부터 무료 베타를 종료하고 유료 좌석이 필요해진다. ## 디자인과 연결되는 주석 기능 - 디자이너가 디자인 레이어에 설명, 속성, 사양, 측정값을 직접 추가할 수 있다. - 클릭과 드래그만으로 치수와 간격을 표시해 개발자에게 구체적인 구현 정보를 전달한다. - 주석이 특정 레이어에 연결되므로 디자인이 변경되면 속성이나 측정값도 함께 업데이트된다. - 확대·축소 수준에 따라 주석이 자동으로 표시되거나 숨겨져 캔버스를 복잡하게 만들지 않는다. - 플러그인 API를 이용하면 여러 레이어에 주석을 일괄 생성하고 관리할 수 있다. ## 시각적·코드 기반 변경 사항 비교 - Compare Changes 기능이 개편되어 디자인 변경 사항을 시각적 차이와 코드 차이로 모두 확인할 수 있다. - 주석 기능과 결합해 어떤 디자인 요소가 바뀌었고 구현에 어떤 영향을 주는지 파악하기 쉬워졌다. - Figma for Jira 앱을 사용하면 Jira 이슈에 디자인 맥락을 삽입할 수 있다. - 디자인이 변경될 때 Jira에서 알림을 받아 핸드오프 과정에서 업데이트를 놓치지 않도록 지원한다. ## 조직별 코드 생성과 플러그인 - 조직마다 다른 개발 환경에 맞춰 HTML, React, Tailwind, Bootstrap 등 다양한 형식의 코드를 생성할 수 있다. - 디자인 시스템 컴포넌트와 실제 코드베이스의 컴포넌트 연결 여부를 확인하는 플러그인을 만들 수 있다. - 플러그인에 내부 API 안내, 디자인 시스템 문서 링크, 사용 가능한 컴포넌트 정보 등을 포함할 수 있다. - Enterprise 관리자는 특정 플러그인을 조직 전체에 고정하고 Dev Mode에서 기본 실행되도록 설정할 수 있다. - Razorpay는 자체 Dev Mode 플러그인인 RazorSharp를 구축해 디자인에 대응하는 코드를 자동 생성했다. ## Figma for VS Code 개선 - VS Code 안에서 Figma 디자인을 탐색하고 검사할 수 있도록 확장 기능의 탐색성과 검색성이 개선됐다. - 여러 페이지와 무한 캔버스를 직접 이동하는 대신 프레임을 그리드 형태로 선택할 수 있다. - Focus View를 통해 개별 프레임을 집중해서 확인할 수 있다. - VS Code를 떠나지 않고 Figma 플러그인을 실행할 수 있어, 사내 도구나 코드 생성 플러그인을 개발 환경에서 바로 사용할 수 있다. ## Dev Mode 유료 전환 - Dev Mode는 2024년 1월 31일 무료 베타에서 정식 서비스로 전환된다. - 이후 사용하려면 플랜과 좌석 유형에 따라 유료 Dev Mode 좌석이 필요하다. - 무료 베타 기간 동안 사용자 피드백을 반영해 200개 이상의 기능과 수정 사항이 추가됐다. 조직은 디자인 시스템과 실제 코드베이스의 연결이 중요하다면 주석과 플러그인을 우선 도입하고, 개발자가 VS Code 중심으로 작업한다면 Figma for VS Code와 사내 플러그인 연동을 검토하는 것이 효과적이다. 유료 전환 전 팀별 좌석과 플러그인 운영 정책도 함께 정하는 것이 좋다.

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

요점 정리: 제

Figma의 **“Issue no.3: The handoff”**는 2023년의 주요 제품 출시와 업무·기술 관련 인사이트를 돌아보고 2024년으로 이어지는 “인계”를 주제로 한 연말 큐레이션이다. 디자인 협업에서의 핸드오프를 단순한 전달이 아니라 아이디어를 계속 주고받으며 발전시키는 과정으로 바라보며, AI 제품 개발, 협업, 기술과의 관계, 생산성 도구 등을 여러 글과 프로젝트로 소개한다. ## 아이디어를 이어가는 ‘핸드오프’ - Figma는 미국 풋볼의 공 전달에서 유래한 “handoff”를 디자인 협업의 개념으로 확장한다. - 디자인 작업에서 핸드오프는 디자이너가 개발자에게 결과물을 넘기는 일회성 단계가 아니라, 아이디어가 팀 사이를 오가며 완성되는 지속적인 상호작용이다. - 2023년에 있었던 주요 출시, 업무 방식의 변화, 팀 협업에 대한 배움을 정리해 2024년으로 이어가려는 목적을 담고 있다. - 글 전체는 하나의 주제를 깊게 분석하기보다, Figma가 선정한 관련 콘텐츠와 프로젝트를 묶어 보여주는 연말 회고 형식이다. ## 2023년 Figma의 주요 출시 - 2023년에 출시한 제품과 기능 가운데 영향이 컸던 10가지를 선정해 소개한다. - 작은 세부 개선부터 제품의 방향을 바꾼 대규모 출시까지 포함하며, 각 항목이 사용자 경험과 업무 방식에 어떤 차이를 만들었는지 설명한다. - 여기서 MVP는 “Minimum Viable Product”가 아니라 “Most Valuable Players”라는 의미로 사용된다. - 제품을 평가할 때 기능의 규모뿐 아니라 실제 업무에 준 영향과 세부 완성도도 중요하다는 관점을 보여준다. ## 기술과 다시 관계 맺기 - 기술에 대한 개인의 경험과 감정을 돌아보는 36개의 질문을 제시한다. - 첫 사용자 이름, 기술을 통해 사람을 만난 경험, 미래에 기대하는 혁신 등을 질문하며 기술을 단순한 도구가 아닌 사회적·개인적 관계의 대상으로 바라본다. - 디지털 과잉과 불확실성이 커지는 상황에서 기술의 장점과 의미를 재발견하려는 내용이다. - 여러 제품 제작자들의 답변을 통해 기술이 사람들을 연결하고 새로운 가능성을 제공하는 방식을 살펴본다. ## AI 제품은 사람의 도움이 필요하다 - 2024년에도 AI가 중요한 기술 흐름이 되겠지만, AI의 능력만으로 좋은 제품이 만들어지는 것은 아니라고 강조한다. - Duolingo, LinkedIn, Asana 등의 제품 리더들이 AI 기능을 실제 사용자 가치로 연결하는 방법을 공유한다. - 제품 관리자는 과장된 AI 열풍을 좇기보다 다음 요소를 판단해야 한다. - 사용자가 실제로 필요로 하는 문제인지 - AI의 결과를 사용자가 신뢰할 수 있는지 - 제품 안에서 AI가 어떤 역할을 맡아야 하는지 - 기능을 안정적으로 시장에 출시하고 개선할 수 있는지 - 핵심은 AI 자체를 도입하는 것이 아니라, 사용자에게 의미 있고 신뢰할 수 있는 경험을 제공하는 것이다. ## Figma Creator Micro와 키보드 문화 - Figma와 모듈형 키보드 제조사 Work Louder가 협업해 12개 키와 2개의 로터리 인코더를 갖춘 커스텀 키보드를 제작했다. - 키 조합을 활용하면 최대 48개의 단축키를 설정할 수 있어 Figma 작업 효율을 높일 수 있다. - 프로젝트 제작 과정과 함께 기계식 키보드가 생산성 도구이자 촉각적 즐거움을 주는 제품이라는 점을 조명한다. - 온라인에서 대부분의 업무가 이루어지는 환경에서도 물리적 인터페이스가 집중력과 작업 감각을 보완할 수 있다고 설명한다. ## 협업과 업무 방식에 대한 다른 시선 - Figma는 앞서 발행한 여러 콘텐츠를 통해 현대적인 업무 방식을 다양한 각도에서 다룬다. - 새로운 업무 용어를 통해 원격·디지털 업무 환경에서 생겨난 규범과 문제를 살펴본다. - 전문성을 유지하면서도 상황에 따라 방향을 바꾸는 “프로페셔널 피벗”의 태도를 소개한다. - 회의를 단순한 정보 전달 시간이 아니라 진행자와 참가자가 함께 만들어가는 협업 세션으로 바라본다. - 글 후반부의 “Rabbit hole” 등 추가 콘텐츠는 일, 회의, 창작, 기술 문화를 일러스트와 이야기 형식으로 확장한다. ## 실용적인 시사점 업무 인계는 산출물을 넘기는 마지막 단계가 아니라, 다음 사람이 맥락을 이해하고 다시 발전시킬 수 있도록 지속적으로 대화하는 과정으로 설계하는 것이 좋다. 또한 AI나 새로운 도구를 도입할 때는 유행보다 사용자 문제, 신뢰성, 실제 업무 개선 효과를 먼저 검증해야 한다.

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

Razorpay가 개발자 워크플 (새 탭에서 열림)

인도 최대의 금융 서비스 기업인 Razorpay는 1,000만 개 이상의 비즈니스를 지원하기 위해 디자인 시스템 'Blade'를 구축하여 일관된 사용자 경험과 개발 효율성을 동시에 확보했습니다. 웹과 모바일을 아우르는 단일 API 구조를 통해 플랫폼 간 전환 비용을 최소화하고, 전용 플러그인과 Figma Dev Mode를 적극 활용해 디자이너와 개발자 간의 협업 마찰을 획기적으로 줄였습니다. 결과적으로 Blade는 단순한 가이드를 넘어 제품의 신뢰성을 높이고 시장 출시 속도를 앞당기는 핵심 동력으로 자리 잡았습니다. **크로스 플랫폼을 위한 단일 라이브러리 체계** * 웹, iOS, Android 등 다양한 플랫폼에서 동일한 API와 속성을 공유하는 단일 디자인 시스템을 운영하여 개발자가 플랫폼을 옮겨가더라도 기존 지식을 그대로 활용할 수 있게 했습니다. * 하드코딩으로 인해 발생할 수 있는 텍스트 필드의 에러 처리나 버튼 상태값 누락 등의 세부적인 오류를 방지하고, 모든 컴포넌트에 접근성(Accessibility)을 기본적으로 내장했습니다. * 디자이너와 개발자가 동일한 언어를 사용함으로써 커뮤니케이션 비용을 줄이고, 디자인에서 보는 결과물이 코드와 일치하도록 보장합니다. **지표 기반의 도입 전략과 조직 내 확산** * 새로운 기능을 개발할 때는 디자인의 70%, 기존 화면을 수정할 때는 50% 이상 Blade 컴포넌트를 사용하도록 KPI를 설정하여 디자인과 개발 팀이 공동의 목표를 추구하게 합니다. * 'Blade Coverage' 플러그인을 통해 디자이너가 시스템에서 얼마나 벗어나고 있는지 실시간으로 확인하게 함으로써, 핸드오프 단계 이전에 피드백을 주고받을 수 있는 환경을 조성했습니다. * 리더십의 지지를 바탕으로 전담 슬랙 채널 운영, 오피스 아워, 시연 영상 공유 등을 통해 내부 고객(직원)들의 채택률을 높이고 연간 NPS(순추천지수) 설문을 통해 만족도를 관리합니다. **RazorSharp와 Dev Mode를 통한 코드 자동화** * 개발자가 일일이 속성을 검사하던 비효율을 제거하기 위해 디자인을 코드로 자동 변환해주는 자체 플러그인 'RazorSharp'를 개발했습니다. * Figma의 Dev Mode를 도입하면서 기존 편집 권한이 필요했던 플러그인 제약을 극복했고, 개발자가 편집 권한 없이도 코드를 복사하고 Storybook 링크를 통해 바로 컴포넌트 환경으로 이동할 수 있게 했습니다. * VS Code 플러그인을 연동하여 개발 환경 내부에서 직접 디자인 사양을 확인하며 코드를 작성하는 워크플로우를 구축했습니다. **Variables를 활용한 토큰 관리 및 성능 최적화** * 기존의 복잡한 토큰 명명 규칙(surface/text/subtle)을 개발자 친화적인 구조(surface.text.subtle)로 변환하고, 간격(spacing) 토큰을 변수화하여 개발 편의성을 높였습니다. * 여러 테마와 라이트/다크 모드를 개별적으로 만들던 방식에서 변수(Variables) 기반 시스템으로 전환하여 메모리 소모를 대폭 줄이고 디자인 작업 속도를 개선했습니다. * 이를 통해 하나의 테마 안에서 다양한 모드를 유연하게 구현할 수 있게 되어 시스템의 복잡성을 낮추고 관리 효율을 극대화했습니다. **디자인 시스템 운영을 위한 실용적 제언** 디자인 시스템의 성공은 단순히 컴포넌트를 만드는 것에 그치지 않고, 개발자가 실제 작업 환경에서 얼마나 편리하게 코드를 추출하고 적용할 수 있느냐에 달려 있습니다. Razorpay처럼 자체 플러그인을 개발하거나 Dev Mode를 적극 활용하여 '디자인 검사'에 들어가는 시간을 줄이고, 정량적인 사용량 지표(Coverage)를 통해 팀의 성과를 객관화하는 접근 방식이 권장됩니다. 또한, 시스템의 복잡도가 커질수록 Variables 기능을 활용해 성능 저하를 방지하고 개발 생산성을 높이는 전략이 필수적입니다.

figma2분 읽기큐레이션 요약

피그마와 어도비,

Figma와 Adobe는 15개월간의 규제 심사 끝에 인수합병을 중단하기로 공동 결정했다. 양사는 제품과 사업, 시장의 차이를 규제 당국에 설명했지만 승인 가능성이 없다고 판단했다. Figma는 독립 기업으로 남아 AI와 협업 기능을 강화하고, 향후 Adobe와는 사용자에게 도움이 되는 방식으로 협력할 계획이다. ## 인수합병 중단과 규제 승인 불확실성 - Figma와 Adobe는 15개월 동안 전 세계 규제 당국의 심사를 받았다. - 양사는 두 기업의 사업·제품·시장 사이에 차이가 있다는 점을 수천 시간에 걸쳐 설명했다. - 그러나 제안된 인수의 규제 승인을 받을 현실적인 경로가 없다고 판단해 거래를 종료했다. - 인수합병은 양사의 사용자 커뮤니티에 더 큰 가치를 제공하려는 목적에서 시작됐지만, 최종적으로 실현되지 못했다. ## 독립 기업으로서의 Figma - Figma는 Adobe에 인수되지 않고 독립적인 기업으로 계속 운영된다. - 인수 심사 기간의 불확실성 속에서도 제품 개발과 조직 확장을 지속했다. - 향후 Adobe와 경쟁만 하는 것이 아니라 사용자에게 도움이 되는 협력 기회를 모색할 예정이다. - 영국과 아시아에 새로운 거점을 열고, 500명 이상의 직원을 추가했다. ## 지난 15개월간의 제품 발전 - **FigJam AI 기능**을 출시해 시각적 협업과 아이디어 구상에 AI를 활용할 수 있도록 했다. - **Dev Mode**를 도입해 개발자가 디자인 파일에서 필요한 정보와 도구에 더 쉽게 접근하도록 개선했다. - **Variables**와 **Advanced Prototyping**을 추가해 디자인 시스템과 프로토타이핑 기능을 확장했다. - AI 스타트업 **Diagram**을 인수해 디자인 과정에서 AI가 담당할 수 있는 영역을 넓혔다. - Config 2023 행사를 통해 디자인과 개발이 하나의 흐름으로 연결되는 제품 방향을 제시했다. ## Figma의 장기 비전 - 창업 당시의 목표는 “상상과 현실 사이의 간극을 없애는 것”이었다. - 디지털 경제의 확대와 AI 기술의 발전으로 이 목표가 더욱 중요하고 실현 가능해졌다고 설명한다. - Figma는 누구나 하나의 멀티플레이어 캔버스에서 아이디어 구상부터 디자인, 개발, 제품 출시까지 진행할 수 있도록 만드는 데 집중할 예정이다. - 디자인 도구를 넘어 디지털 제품 제작 전 과정을 지원하는 플랫폼으로 발전하려는 방향이다. 이번 결정은 대형 인수합병보다 Figma의 독립성과 제품 혁신을 유지하는 결과로 이어졌다. 사용자 입장에서는 Figma가 AI, 개발자 도구, 협업 기능을 중심으로 계속 확장되는지 지켜보는 것이 중요하다.

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

요점: 제2호 |

Figma의 뉴스레터 「Rework your work」는 기존 업무 방식을 재검토하고 더 나은 제품과 협업을 만드는 방법을 소개한다. 핵심은 거대한 기능보다 반복되는 작은 개선을 중시하고, AI·프로토타이핑·커뮤니티 도구를 활용해 제품 개발의 장벽을 낮추는 것이다. 디자이너에게는 자신의 가치를 증명하려 하기보다 결과물로 말하고, 새로운 방식으로 실험하라는 메시지를 전한다. ### 작은 개선이 만드는 큰 변화 - 사용자가 자주 수행하는 작은 행동을 개선하는 것이 거의 사용되지 않는 화려한 기능을 추가하는 것보다 더 큰 긍정적 영향을 줄 수 있다. - Figma는 품질 향상과 버그 수정, 사용자의 시간을 절약하는 변경을 제품 개발의 기본적인 습관으로 본다. - 좋은 제품 경험은 거대한 혁신보다 세부적인 배려와 사용자의 필요를 미리 파악하는 데서 만들어진다. ### FigJam과 생성형 AI의 결합 - Figma는 FigJam에 생성형 AI를 도입해 시각적 협업의 접근성을 높였다. - AI 기능은 다음과 같은 작업을 지원한다. - 맞춤형 템플릿 생성 - 다이어그램 작성 - 협업 문서 및 보드 내용 요약 - 스티키 노트 자동 분류 - 이를 통해 제품 팀이 계획을 세우고, 의견을 동기화하며, 브레인스토밍하는 과정을 더 쉽게 만들 수 있다. - 목표는 제품의 진입 장벽을 낮추는 동시에 사용자가 만들 수 있는 결과의 범위를 넓히는 것이다. ### 프로토타이핑을 조직의 문화로 만들기 - 프로토타이핑은 디자인 결과물을 보여주기 위한 마지막 단계가 아니라 제품 개발 전반에 필요한 과정이다. - 아이디어를 구체적인 형태로 만들어 동료들이 직접 탐색하고 반응하며 수정할 수 있게 한다. - 디자이너의 주도권을 강화하고, 팀 전체가 더 이른 시점에 유용한 통찰을 얻도록 돕는다. - 개발 전에 가설을 검증할 수 있어 업무 흐름을 간소화하고 효율성을 높인다. ### Creator Fund와 커뮤니티 창작자 - Figma의 Creator Fund는 커뮤니티를 위해 무료 위젯, 플러그인, 파일을 만드는 창작자를 지원하는 보조금 프로그램이다. - 소개된 프로젝트에는 다음과 같은 도구가 포함된다. - 몰입형 환경 제작 키트 - 디자인을 코드로 변환하는 플러그인 - 텍스트 애니메이션 도구 - 이러한 리소스는 Figma Community 구성원들이 별도의 복잡한 도구 없이 창작할 수 있도록 돕는다. - 첫 번째 지원 cohort의 프로젝트들은 거의 백만 명의 사용자가 Figma에서 창작하는 데 활용되었다. ### 디자이너의 태도와 업계 전망 - 디자이너는 자신의 가치를 끊임없이 증명하려 하기보다 작업 자체가 역량을 보여주도록 해야 한다. - Figma의 디자이너 보고서에 따르면 디자이너의 69%가 취업 전망이 개선되었다고 느꼈다. - 이는 디자인 직무의 가능성이 여전히 상승세에 있다는 신호로 제시된다. - 글은 디자이너들에게 기존 방식에 머무르지 말고, 실험과 결과물을 통해 새로운 업무 방식을 만들어가라고 권한다. 작은 사용성 개선을 꾸준히 실행하고, 프로토타입으로 아이디어를 조기에 검증하며, AI와 커뮤니티 도구를 적절히 활용하는 것이 실용적인 접근이다. 기술 도입 자체보다 팀의 협업과 창작 과정을 실제로 개선하는지를 기준으로 선택하는 것이 중요하다.

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

프로토타이핑 문화를 조성

프로토타이핑은 더 이상 개발 직전의 선택적 작업이 아니라, 제품 개발 전반에 통합해야 할 핵심 활동이다. 인터랙티브한 프로토타입은 정적 디자인에서 놓치기 쉬운 내비게이션과 사용자 경험 문제를 조기에 발견하고, 개발 전에 아이디어의 가치를 검증하게 한다. 조직 전체가 프로토타이핑을 일상적인 업무 방식으로 받아들이면 실험과 의사결정이 빨라지고 더 나은 제품을 만들 수 있다. ## 프로토타이핑의 역할과 가치 - 프로토타입은 제품의 형태와 동작을 미리 보여주는 모형 또는 데모다. - 인터랙션과 경험을 충분히 높은 완성도로 재현해, 실제 개발에 들어가기 전에 아이디어를 평가할 수 있다. - 정적 화면만으로는 발견하기 어려운 내비게이션 문제, 사용성 장애, 사용자 테스트상의 문제를 조기에 드러낸다. - 개발 전에 문제를 수정하므로 엔지니어링 시간과 불필요한 개발 사이클을 줄인다. - 디자인을 단순한 시각 결과물이 아니라 실제 제품 경험으로 전환한다. ## 빠른 실험과 아이디어 검증 - 여러 아이디어를 개발 리소스를 추가로 투입하지 않고 빠르게 만들고 검증할 수 있다. - 초기에는 다양한 방향으로 폭넓게 탐색한 뒤, 가능성이 높은 해법으로 좁혀 갈 수 있다. - 이러한 과정은 더 창의적이고 기존 방식에서 벗어난 사용자 경험을 만드는 데 도움이 된다. - 프로토타입은 아이디어를 상위 의사결정자에게 구체적으로 보여주는 증거가 되어, 프로젝트 승인과 설득을 앞당긴다. - 디자이너는 인터랙티브한 결과물로 자신의 의도를 효과적으로 전달하고 제품 및 비즈니스 의사결정에 영향력을 행사할 수 있다. ## 프로토타이핑 문화의 확산 - 프로토타이핑 문화는 과거 디자인 시스템이 발전한 과정과 비슷하게 확산되고 있다. - 도구 접근성이 높아지고 교육 프로그램이 생기면서 더 많은 팀이 프로토타이핑을 업무에 활용할 수 있게 됐다. - Lyft는 정적 디자인을 넘어 동영상, GIF, 인터랙티브 프로토타입을 활용하고, 사용자 피드백을 제품 리뷰에 빠르게 반영하는 사례로 소개된다. - 프로토타이핑을 중시하는 조직은 혁신과 디자인을 중요하게 여긴다는 신호를 제공하며, 우수한 디자인 인재를 끌어들이는 데도 도움이 된다. ## 조직 차원의 정착 조건 - 프로토타이핑을 익히고 실천할 수 있도록 시간과 리소스를 공식적으로 배정해야 한다. - 이를 최종 단계의 선택 사항이 아니라 디자인 프로세스에 자연스럽게 포함된 필수 단계로 바꿔야 한다. - 실무자는 프로토타이핑 역량을 발전시키고, 리더십은 효율성과 의사결정 개선에 미치는 가치를 인정해야 한다. - 리더는 팀이 프로토타이핑을 프로세스에 포함하도록 명시적으로 요구하고, 실제로 작업할 시간과 환경을 제공해야 한다. - 관심 있는 직원들을 위한 전문 프로그램을 운영하고, 습득한 지식을 교육·개발 체계와 주요 리뷰 과정에 확장할 수 있다. - 실무자와 리더 중 한쪽만 동의하면 문화로 정착하기 어렵기 때문에 조직 전반의 공감대가 필요하다. ## 제품 개발 프로세스의 변화 - 프로토타이핑을 앞단에 배치하면 제품 개발은 기존의 선형적인 순서에서 더 반복적이고 탐색적인 과정으로 바뀐다. - 잠재적 장애물을 빠르게 발견하고 여러 대안을 평가할 수 있어, 이미 알려진 문제를 피하면서 해결책에 집중할 수 있다. - 프로토타이핑 문화는 디자이너의 역할뿐 아니라 제품·엔지니어링·리더십 간 협업 방식과 의사결정 구조 전체를 변화시킨다. - 결과적으로 개발 착수 후 수정하는 비용보다, 개발 전 실험하고 학습하는 비용을 우선하게 된다. 실무적으로는 모든 기능에 높은 완성도의 프로토타입을 만들기보다, 위험이 큰 인터랙션과 사용자 경험부터 짧게 실험하는 것이 효과적이다. 이를 정기 리뷰와 교육 과정에 포함하고 리더가 시간을 보장해야 프로토타이핑이 일회성 산출물이 아니라 조직의 기본 업무 방식으로 자리 잡을 수 있다.

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

슬랙래시부터 토글

2023년의 디지털·하이브리드 업무 환경은 새로운 행동과 감정을 만들어냈고, 이를 표현할 새로운 업무 용어도 낳았다. 이 글은 Slack, Zoom, 협업 도구, 멀티태스킹과 관련된 현상을 유머러스한 신조어로 정리하며, 변화한 업무 문화를 이해하고 적응하는 언어를 제시한다. 결국 바쁜 업무 환경을 완전히 없애기보다, 그 안의 불합리함과 재미를 인식하고 더 현명하게 일하자는 메시지다. ### 업무 완성도와 반복 개선 - **Fidelity Fluency** - 프로젝트에 필요한 완성도 수준을 판단하는 능력이다. - 초기 아이디어 스케치에 과도한 시간을 쓰지 않고, 실제 영향력에 맞춰 디테일을 조절한다. - 불필요한 픽셀 단위 수정과 낭비를 줄이는 실무적 감각을 의미한다. - **WIP Waltz** - 진행 중인 작업을 끊임없이 수정하고 반복하는 과정을 춤에 비유한 표현이다. - 매 단계마다 새로운 관점과 개선 사항이 생기지만, 동시에 또 다른 수정 라운드가 시작된다. ### 원격 협업에서 발생하는 순간들 - **Icebroken** - 온라인 회의의 아이스브레이킹에서 지나치게 개인적인 이야기를 꺼내 어색해지는 상황이다. - 친밀감을 만들려던 시도가 오히려 ‘TMI’로 이어지는 순간을 풍자한다. - **Screenshare Scramble** - 화면 공유 직전이나 도중에 민감하거나 부끄러운 브라우저 탭을 급히 숨기는 행동이다. - Zoom 화면에 무엇이 나타날지 모르는 긴장감과 허둥거림을 표현한다. - **Zoombie** - Zoom 회의에 접속해 있지만 실제로는 거의 참여하지 않는 사람을 뜻한다. - 카메라 앞에는 존재하지만 정신적으로는 여러 회의와 화면 공유에 지친 상태다. - **Zoom Zen** - 명확한 안건, 원활한 음소거·해제, 시간 내 종료가 모두 이루어진 이상적인 화상회의 상태다. - 드물지만 회의가 효율적이고 만족스럽게 끝났을 때의 평온함을 의미한다. ### 메시지와 알림의 과부하 - **Keyboard Cardio** - 이메일과 Slack 메시지를 빠르게 입력하고 처리하는 일을 격렬한 유산소 운동처럼 표현한 말이다. - 실제 운동 효과보다는 메시지 작성이 유발하는 긴장과 스트레스를 농담처럼 강조한다. - **Slack-lash** - Slack 알림과 메시지가 한꺼번에 쏟아져 놀라고 압도되는 순간이다. - 디지털 메시지의 폭발적인 유입을 갑작스러운 반동이나 ‘채찍질’에 비유한다. - **Workplace Whack-a-Mole** - 업무, 알림, 이메일이 끊임없이 나타나 이를 계속 처리해야 하는 상황이다. - 하나를 끝내면 곧바로 다른 일이 튀어나오는 업무 환경의 피로와 혼란을 묘사한다. ### 멀티태스킹과 디지털 산만함 - **Toggle Tax** - 여러 업무 사이를 전환할 때 발생하는 인지적 비용이다. - 작업을 바꿀 때마다 집중력을 다시 끌어올려야 하므로, 멀티태스킹이 생산성을 떨어뜨릴 수 있음을 암시한다. - **Tab Tsunami** - 브라우저 탭이 지나치게 많이 열려 화면과 집중력을 모두 압도하는 상태다. - 수많은 정보와 작업을 동시에 붙잡으려는 디지털 업무 습관을 거대한 파도에 비유한다. ### 디자인 시스템과 협업 문화 - **Style Guide Safari** - 스타일 가이드 안에서 색상, 서체, 컴포넌트 등을 탐색하는 과정을 정글 탐험처럼 표현한 말이다. - 디자인 시스템이 풍부하고 복잡할수록 원하는 규칙을 찾아다니는 경험이 모험처럼 느껴질 수 있다. - **Sudden Heavy Stamping** - 협업 중 자신의 아이디어에 갑자기 여러 개의 +1, 하트, 스탬프가 몰리는 순간이다. - 실시간 협업 도구에서 사회적 인정과 즉각적인 피드백을 받는 기쁨을 뜻한다. - **UI Lock Ness Monster** - 다음 업데이트에 포함될 것이라는 소문만 무성하고 실제로는 계속 등장하지 않는 UI 기능이다. - 오랫동안 기대되지만 실현되지 않는 기능을 전설 속 괴물에 빗댄 표현이다. ### 글이 제시하는 업무 문화의 풍경 - 이 용어들은 새로운 기술 자체보다, 기술을 사용하는 과정에서 생긴 감정과 습관을 포착한다. - Zoom 피로, Slack 알림, 화면 공유 불안, 멀티태스킹 비용처럼 디지털 업무의 문제를 유머로 표현한다. - 동시에 비동기 업무, 팬데믹 이후의 업무 전환, 몰입 중심의 업무 방식 등 변화한 일하는 방식을 반영한다. - 이러한 표현은 업무의 혼란을 개인의 실패로만 보지 않고, 많은 사람이 공유하는 문화적 경험으로 바라보게 한다. 업무 효율을 높이려면 `Toggle Tax`를 줄이도록 작업 전환을 최소화하고, `Zoom Zen`을 위해 회의 안건과 종료 시간을 명확히 정하는 것이 좋다. 또한 `Fidelity Fluency`처럼 업무 목적에 맞는 완성도만 추구하면 불필요한 수정과 디지털 과부하를 줄일 수 있다.

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

Figma x Work Louder의 새로운

Figma는 Work Louder와 협업해 창작 작업에 최적화된 맞춤형 기계식 키보드를 선보였다. 일반 키보드가 타이핑 중심이라면, 이 제품은 Figma 캔버스 탐색과 단축키 사용을 더 직관적이고 촉각적으로 만드는 보조 입력 장치에 가깝다. 12개 키와 2개의 로터리 인코더로 최대 48개 단축키를 제공해, 반복적인 디자인 작업을 빠르고 즐겁게 수행하도록 돕는 것이 핵심이다. ## 기계식 키보드가 주는 개인화와 촉각성 - 일반 노트북 키보드는 표준화와 일관성에 초점이 맞춰져 있다. - 기계식 키보드는 다음 요소를 사용자가 직접 조정할 수 있다. - 키캡과 색상 - 키 배열 - 조명 - 스위치의 촉감과 소리 - 이러한 개인화는 단순한 효율성뿐 아니라 작업 도구에 대한 애착과 즐거움을 높인다. - Figma 디자인 디렉터 Marcin Wichary는 키보드를 생산성 도구이면서도 개인의 취향과 작업 방식을 반영하는 물건으로 바라본다. ## 기존 키보드와 창작 작업의 불일치 - 표준 QWERTY 키보드는 원래 타자기와 사무용 문서 작성의 영향을 강하게 받았다. - 오늘날의 창작 소프트웨어는 수많은 단축키를 요구하지만, 기존 키보드는 이를 효율적으로 사용하도록 설계되지 않았다. - 복잡한 단축키 조합은 손가락을 무리하게 뻗게 만들고, 사용자가 명령을 기억하고 조작하는 데 부담을 준다. - Figma는 보편적인 키보드의 기능을 대체하려는 것이 아니라, 창작자가 자주 사용하는 조작에 개성과 촉각적 피드백을 더하려 했다. ## Figma와 Work Louder의 협업 - Figma는 모듈형 키보드를 제작하는 몬트리올 기반 회사 Work Louder와 협업했다. - 목표는 고가 하드웨어를 필수품으로 만들어 접근성을 제한하는 것이 아니라, 기계식 키보드를 선호하는 사용자에게 더 즐거운 작업 경험을 제공하는 것이다. - 제품은 Work Louder의 Creator Micro 키보드를 기반으로 Figma 작업에 맞게 맞춤 제작됐다. - Figma는 브라우저 기반 협업이라는 기존 방향을 유지하면서, 선택적인 생산성 도구를 추가했다. ## 타이핑보다 캔버스 탐색에 초점을 둔 설계 - Figma 사용자는 문자를 입력하기보다 마우스로 캔버스를 탐색하고 파일을 조작하는 시간이 많다. - 따라서 이 장치는 전통적인 키보드보다 대체 트랙패드에 가까운 역할을 한다. - 주요 구성은 다음과 같다. - 12개의 물리 키 - 2개의 로터리 인코더 - 총 48개의 단축키 조합 - Figma에는 150개가 넘는 단축키가 있으므로, 사용자는 자신의 작업 흐름에 맞는 명령을 선택해 배치할 수 있다. - 모든 키가 격자 형태로 배치되어 있어 단축키 위치를 머릿속으로 쉽게 매핑할 수 있다. ## 촉각 피드백과 근육 기억 - 물리 키와 다이얼은 명령이 입력됐다는 피드백을 손끝으로 전달한다. - 사용자는 화면이나 키보드를 내려다보지 않고도 조작 여부를 확인할 수 있다. - 반복 사용하면 특정 키와 명령의 위치가 근육 기억으로 자리 잡아 작업 속도가 빨라진다. - 단축키를 장시간 암기해야 하는 부담을 줄이고, 학습 과정을 더 재미있게 만드는 것이 제품의 중요한 의도다. - Figma는 창작 도구의 세부적인 사용 경험과 즐거움 자체도 좋은 디자인의 일부라고 강조한다. 반복적으로 사용하는 Figma 단축키가 많고 마우스 중심의 캔버스 조작을 더 빠르게 하고 싶다면, 이와 같은 보조 키패드가 유용할 수 있다. 다만 모든 단축키를 한 번에 익히기보다 자주 쓰는 명령 몇 개만 배치해 근육 기억을 만드는 방식이 현실적이다.

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