figma2024년 4월 9일

컴포넌트 스프린트의 (새 탭에서 열림)

워싱턴 포스트는 디자인과 개발이 분리된 채 진행되던 컴포넌트 제작의 문제를 해결하기 위해 약 10일간의 ‘컴포넌트 스프린트’를 도입했다. 디자이너와 개발자가 처음부터 한 쌍으로 참여하고, 관련 팀의 의견을 단계별로 반영해 기술적 제약과 실제 사용 맥락을 함께 고려한다. 이 방식은 디자인 시스템 컴포넌트를 더 빠르고 일관되게 제작하면서도, 팀 전체의 공동 소유 의식을 높이는 것이 핵심이다. ## 디자인 주도·개발 주도 방식의 한계 - 초기 WPDS(The Washington Post Design System)는 컴포넌트 성격에 따라 제작 주체가 달랐다. - `select`, `radio`, `checkbox`처럼 시각적 설계가 중심인 요소는 디자인 주도로 제작했다. - `carousel`, `input search`처럼 기술적 복잡성이 큰 요소는 개발 주도로 제작했다. - 한쪽 팀이 주도하면 다른 팀의 전문 지식이 늦게 반영되어 일정 지연과 타협이 발생했다. - 개발자는 디자인 단계에서 기술적 한계를 뒤늦게 지적하거나, 구현보다 세부적인 시각 요소에 집중하도록 압박받을 수 있었다. - 디자이너는 자신의 사용 사례가 충분히 고려되지 않거나, 이미 존재하는 컴포넌트를 알지 못해 별도 솔루션을 만들기도 했다. - 그 결과 디자인 시스템에는 잦은 오버라이드와 즉석에서 판단해야 하는 기능·변형 요청이 누적됐다. ## 컴포넌트 스프린트의 운영 원칙 - 모든 컴포넌트마다 스프린트를 시작하며, 일반적으로 약 10일 동안 진행한다. - 디자이너와 개발자가 처음부터 끝까지 프로세스를 이끄는 담당자로 짝을 이룬다. - 핵심 담당자 외에도 관련 팀의 의견을 수집해 폐쇄적인 순차 작업을 개방적이고 협력적인 과정으로 바꾼다. - 프로세스는 대체로 다음 단계로 구성된다. - 킥오프 - 콘셉트 정의 - 디자인과 구현 - 개선 및 다듬기 - 문서화 - 모든 참여자가 초기에 요구사항과 기술적 제약을 공유하므로, 후반부의 재작업과 오해를 줄일 수 있다. ## 킥오프: 영향도와 노력으로 우선순위 정하기 - 매주 30분 회의에서 Jira의 후보 컴포넌트 티켓을 검토한다. - 각 아이디어를 예상 영향도와 필요한 노력의 관점에서 비교해 우선순위를 정한다. - 아이디어 보드는 단순한 목록이 아니라 다음 정보를 축적하는 협업 공간으로 활용한다. - 이해관계자의 비동기 피드백 - Slack에서 논의된 관련 정보 - 비슷한 아이디어의 묶음 - 사업 목표와의 연관성 - 시각화된 영향도-노력 매트릭스에서는 원의 크기로 투표 수나 인기도를 표현하고, 색상으로 연관된 사업 목표를 구분한다. - 우선순위가 결정되면 디자인 시스템 팀에서 디자이너와 개발자를 각각 배정한다. - 두 담당자를 초기 단계부터 정함으로써 프로세스 전반의 지속적인 커뮤니케이션을 보장한다. ## 콘셉트 정의: 범위와 목표 합의하기 - 스프린트 시작 시 전체 팀과 함께 약 2시간의 회의를 진행한다. - FigJam에서 다음 내용을 공동으로 정리한다. - 컴포넌트의 목표 - 필수 요구사항 - 작업 범위 - 기술적 요구사항 - 검토가 필요한 가정과 쟁점 - 회의 마지막 15분은 결과 검토에 사용한다. - 기술 담당자와 비기술 담당자가 같은 공간에서 의견을 남기므로, 서로 다른 관점의 기대치를 조기에 맞출 수 있다. - 이 단계에서는 구체적인 디자인 세부사항보다 문제의 범위, 사용 목적, 구현 조건을 먼저 합의한다. - FigJam을 활용하면 특정 직군이 논의를 독점하지 않고, 참여자 모두가 요구사항을 명확히 할 수 있다. ## 실용적인 적용 방향 컴포넌트 제작을 한 팀에 일괄 위임하기보다, 디자이너와 개발자를 초기부터 공동 책임자로 배치하는 것이 효과적이다. 또한 영향도·노력 기반 우선순위 보드와 공개적인 요구사항 문서를 운영하면 불필요한 컴포넌트 중복과 후반 재작업을 줄일 수 있다.

design-development-collaborationfigmadesign-systemsfigjam+3

figma2024년 4월 2일

Framework by Figma에 여러분을 초대합니다 (새 탭에서 열림)

Figma는 디자인 시스템을 단순한 스타일 가이드가 아니라 제품 설계와 개발을 지탱하는 기반으로 보고, 이를 주제로 한 글로벌 행사 ‘Framework by Figma’를 2024년 4월 16일 개최한다고 소개했다. 행사는 새로운 기능, 운영 모범 사례, 디자인-코드 연결, 디자이너와 엔지니어 간 협업을 다룬다. 이후 행사에서는 Code Connect, 타이포그래피·그라디언트 변수, Library Analytics API 등이 공개됐다. ## 디자인 시스템의 확장과 복잡성 - 디자인 시스템은 초기의 단순한 스타일 가이드에서 제품 개발 전반의 기반으로 발전했다. - 실제 도입과 운영 과정에서는 도구 선택, 자동화, 접근성, 조직 내 채택률 관리 등 다양한 문제가 발생한다. - Figma는 현재와 미래의 복잡한 요구를 지원하는 기능과 운영 전략을 행사에서 공유하려 했다. - 시스템을 미리 구조화한 경우뿐 아니라 자유롭게 작업하는 상황도 지원해야 한다는 철학을 강조했다. ## Framework 행사에서 다룬 내용 - 새로운 디자인 시스템 기능을 심층적으로 소개한다. - 디자인 시스템을 효과적으로 구축하고 유지하는 모범 사례를 공유한다. - Verizon 등 업계 기업의 디자인 시스템 구축 및 운영 경험을 소개한다. - Figma 제품팀이 향후 개발 방향을 설명한다. - Bumble, GitHub, Hewlett Packard가 참여하는 디자인-코드 연계 라운드테이블을 진행한다. - 참가자들의 실무 질문에 답하는 전문가 Q&A를 마련한다. ## 디자이너와 엔지니어의 연결 - 성공적인 디자인 시스템에는 디자인과 개발 조직의 긴밀한 협업이 필요하다고 설명한다. - 세션은 디자인 원칙부터 기술적 구현까지 두 직군의 공통 관심사를 다룬다. - 디자인 시스템을 코드와 더 가깝게 연결하는 새로운 기능도 소개 대상에 포함됐다. - 이는 디자인 산출물이 실제 제품 코드로 이어지는 과정의 간극을 줄이려는 방향이다. ## 행사에서 공개된 기능 - **Code Connect**: 디자인 시스템 구성 요소와 개발자가 사용하는 코드 컴포넌트를 연결한다. - **타이포그래피 변수와 그라디언트 변수**: 디자인 토큰의 표현 범위를 확장하고 일관된 스타일 관리를 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황과 디자인 시스템 채택 정도를 분석할 수 있도록 지원한다. - 이러한 기능은 디자인 시스템의 구축뿐 아니라 개발 연계와 조직 전체의 활용도 측정까지 지원하는 데 초점을 둔다. ## 글로벌 디자인 시스템 커뮤니티 - 본 행사는 온라인으로 진행되며 전 세계 디자인 시스템 실무자를 대상으로 했다. - 아시아 지역 온라인 행사는 4월 18일, 도쿄 행사는 4월 23일에 별도로 진행될 예정이었다. - 런던 등 여러 도시에서는 현지 밋업도 계획됐다. - 온라인 스트림을 통해 지역과 관계없이 주요 발표와 세션에 참여할 수 있도록 했다. Figma가 제시한 방향은 디자인 시스템을 엄격한 규칙만으로 운영하기보다, 구조화된 관리와 자유로운 창작을 함께 지원하는 것이다. 조직에서는 디자인 토큰과 컴포넌트 표준화뿐 아니라 코드 연결, 사용량 분석, 디자이너·엔지니어 간 협업 체계까지 함께 구축하는 것이 실용적이다.

design-development-collaborationfigmadesign-systemsaccessibility+3

figma2024년 1월 30일

개발 모드 어노테 (새 탭에서 열림)

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

design-development-collaborationfigmadesign-systemsaccessibility+2