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

Figma AI를 소개

Figma는 디자이너의 창작 정체를 해소하고 반복 작업을 줄이기 위해 Figma AI를 출시했다. 주요 기능은 이미지·영역·텍스트 기반의 Visual Search와 의미를 이해하는 AI Asset Search이며, 디자인 탐색과 재사용을 더 쉽게 만드는 것이 목표다. 베타 기간에는 무료로 제공되지만, 향후 사용량 제한과 정식 출시 후 가격 정책이 적용될 수 있다. ## Figma AI의 목표와 제공 방식 - AI를 단순한 유행이 아니라 실제 사용자 문제를 해결하는 도구로 활용한다. - 영감 탐색, 여러 디자인 방향의 실험, 반복적이고 번거로운 작업 자동화를 지원한다. - 디자인 프로세스의 어느 단계에서든 사용자가 작업을 계속 진행하도록 돕는 것을 목표로 한다. - Figma AI와 UI3는 2024년 당시 제한적 베타로 제공되며, 사용자는 Figma 화면 하단의 `?` 메뉴에서 대기자 명단에 등록할 수 있다. - 베타 기간에는 모든 사용자에게 무료로 제공되지만, 운영 비용과 사용 패턴에 따라 사용량 제한이 도입될 수 있다. - 정식 출시 시 가격 정책을 별도로 안내할 예정이다. ## 이미지와 디자인을 찾는 Visual Search - 사용자가 이미지를 업로드하거나, 캔버스의 특정 영역을 선택하거나, 텍스트 검색어를 입력하면 시각적으로 유사한 디자인을 찾아준다. - 사용자가 접근 권한을 가진 팀 내 모든 파일에서 관련 디자인을 검색한다. - 검색 결과에서 적절한 프레임을 현재 작업 중인 파일에 바로 삽입할 수 있다. - 기존 제작물이나 제품 스크린샷을 출발점으로 삼는 디자이너가 필요한 디자인을 빠르게 재사용할 수 있다. - 향후에는 Figma Community 파일까지 검색 범위를 확대할 계획이다. - 커뮤니티 리소스 검색 결과에는 원작자 표기를 제공하고, 원본 파일이나 제작자의 다른 작업으로 이동할 수 있도록 할 예정이다. ## 의미를 이해하는 AI Asset Search - Assets 패널의 기존 검색 기능을 AI 기반으로 개선했다. - 단순히 컴포넌트 이름에 검색어가 포함되는지 확인하는 대신, 검색어의 의미와 디자인 요소가 사용되는 맥락을 분석한다. - 예를 들어 `primary button`을 검색하면 실제 컴포넌트 이름이 `btn_large`처럼 되어 있어도 관련 버튼을 찾아준다. - 디자인 시스템의 명명 규칙이 일관되지 않거나 조직 규모가 커서 컴포넌트를 찾기 어려운 상황에서 유용하다. - 키워드를 정확히 기억하지 않아도 자연어에 가까운 방식으로 적절한 컴포넌트와 에셋을 탐색할 수 있게 한다. ## 디자이너의 작업 흐름을 돕는 방향 - Figma AI는 처음부터 새로 만드는 작업뿐 아니라 기존 디자인을 찾고 발전시키는 과정도 지원한다. - Visual Search는 시각적 유사성을 기반으로 영감과 재사용 가능한 결과물을 제공한다. - Asset Search는 디자인 시스템 내부의 컴포넌트를 더 직관적으로 찾도록 돕는다. - 결과적으로 탐색에 소요되는 시간을 줄이고, 디자이너가 실제 문제 해결과 창의적 의사결정에 더 집중하도록 하는 것이 제품의 방향이다. 실무에서는 팀의 디자인 시스템에 일관된 이름을 적용하는 것이 여전히 중요하지만, Figma AI의 검색 기능을 활용하면 기존 자산의 명칭이 제각각인 조직에서도 컴포넌트 탐색과 재사용 효율을 높일 수 있다.

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

디자인 시스템AI사용자 경험생성형 AI+2

figma·2024년 5월 21일·3분 읽기큐레이션 요약

Code Connect의 잠재력 활용

디자인과 개발의 간극을 줄이려면 두 팀이 공유할 수 있는 언어와 단일한 작업 흐름이 필요하다. Figma의 Code Connect는 디자인 시스템의 컴포넌트 구현 정보와 문서를 Dev Mode에서 직접 제공해 개발자가 맥락을 바꾸지 않고 올바른 코드를 사용할 수 있도록 돕는다. 패널 참가자들은 작은 컴포넌트부터 시작해 점진적으로 도입하고, 디자이너와 개발자의 전문성을 서로 존중해야 한다고 강조한다. ## 디자인과 개발이 함께 쓰는 언어 만들기 - 디자이너와 개발자는 컴포넌트 이름, 속성, 구현 방식에 대해 서로 다른 용어와 기대를 가질 수 있다. - 이 차이는 다음과 같은 문제로 이어진다. - 일관되지 않은 네이밍 - 디자인과 코드의 속성 불일치 - 팀 간 요구사항과 구현 결과의 불일치 - 디자인 시스템은 공통 컴포넌트, 패턴, 용어를 정의해 두 분야를 연결하는 “제3의 언어” 역할을 한다. - 단순히 규칙을 문서화하는 것뿐 아니라, 구성원이 쉽게 찾고 실제로 적용할 수 있게 만드는 것도 중요하다. ## 단일한 기준과 개발자 워크플로 연결 - Bumble의 Raul Menezes는 디자인과 코드에서 서로 다른 기준 문서가 사용되는 것이 일관성 저하의 주요 원인이라고 설명한다. - 같은 UI 패턴을 반복해서 직접 구현하면 다음 문제가 발생한다. - 중복 코드 증가 - 커스텀 구현 확산 - 유지보수 어려움 - 디자인 시스템과 실제 제품 간의 불일치 - 디자이너는 디자인 시스템 문서를 참고하지만, 개발자는 별도의 코드 저장소나 문서를 기준으로 삼는 경우가 많다. - Code Connect는 디자인 시스템의 코드 예시와 구현 정보를 Dev Mode 안에서 제공해 개발자가 기존 코드 편집 및 개발 흐름에서 바로 참고하도록 설계됐다. ## 도입 장벽을 낮추고 작은 규모로 시작하기 - 디자인 시스템을 구축했다고 해서 자동으로 팀 전체가 사용하는 것은 아니다. 개발자가 기존 작업 방식을 크게 바꿔야 한다면 adoption이 느려질 수 있다. - 기존에는 개발자가 디자인 구현 방식을 확인하기 위해 별도의 디자인 시스템 웹사이트로 이동해야 했다. - Code Connect를 사용하면 Dev Mode에서 특정 디자인이 코드로 구현되어 있는지, 어떤 방식으로 구현하는지 확인할 수 있어 컨텍스트 전환을 줄인다. - 처음부터 모든 컴포넌트를 연결하기보다 영향도가 높고 구조가 단순한 컴포넌트부터 시작하는 것이 권장된다. - 예: 토글 같은 작은 컴포넌트 - 디자인 속성과 코드 속성을 어떻게 매핑하는지 먼저 검증 - 팀이 도구의 효과와 운영 방식을 익힌 뒤 범위 확대 - Code Connect는 완성된 최종 해법이라기보다 더 큰 디자인-코드 통합을 위한 첫 단계로 제시된다. ## 서로의 전문성 존중하기 - 디자인과 개발의 간극을 줄인다는 것은 한쪽의 방식을 다른 쪽에 강요하는 것이 아니다. - 디자이너는 사용자 경험, 시각적 일관성, 패턴 설계에 강점을 가진다. - 개발자는 컴포넌트 구조, 재사용성, 기술적 제약, 유지보수성에 전문성이 있다. - 효과적인 디자인 시스템 운영을 위해서는 두 팀이 각자의 전문성을 인정하고, 공통 언어와 도구를 통해 협업해야 한다. - Code Connect는 디자인 시스템의 의도와 실제 코드 구현을 연결해 양쪽의 지식을 공유하는 매개 역할을 한다. ## 실용적인 적용 방법 - 디자인 시스템에서 자주 사용되고 영향도가 큰 컴포넌트를 우선 선정한다. - 디자인의 컴포넌트 속성과 코드의 props·API가 어떻게 대응하는지 정의한다. - Dev Mode에서 개발자가 별도 문서 검색 없이 구현 예시를 확인할 수 있도록 연결한다. - 초기 도입 후 다음을 점검한다. - 개발자가 실제로 재사용 컴포넌트를 선택하는지 - 중복·커스텀 구현이 줄었는지 - 디자인과 코드의 명명 및 속성이 일치하는지 - 검증된 운영 방식을 바탕으로 점차 복잡한 컴포넌트와 더 넓은 제품 영역으로 확대하는 것이 바람직하다.

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

디자인 시스템Figmadesign-to-codedev-mode+2

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

The Long and Short of

Figma의 뉴스레터 「Find your framework」는 디자인 시스템 구축과 확산에 도움이 되는 Framework 행사 발표와 관련 콘텐츠를 소개한다. 핵심 메시지는 디자인 시스템이 단순한 UI 산출물이 아니라, 조직 전체가 사용해야 가치를 발휘하는 제품이라는 점이다. 이를 위해 기능 개발뿐 아니라 내부 마케팅, 교육, 데이터 기반 adoption 전략이 필요하다. ## Framework 행사에서 발표한 기능 - Figma의 가상 디자인 시스템 행사인 **Framework**에서 제품 개발자와 디자인 시스템 담당자를 위한 기능을 공개했다. - 주요 발표 내용: - **Code Connect**: 디자인 시스템의 컴포넌트와 실제 코드 구현을 연결해 디자이너와 개발자 간 협업을 지원한다. - **Typography variables**: 글꼴, 크기, 행간 등 타이포그래피 속성을 변수로 관리할 수 있다. - **Gradient variables**: 그라디언트 관련 값을 변수화해 일관된 스타일 관리와 변경을 돕는다. - **Library Analytics API**: 조직 내 라이브러리 사용 현황을 분석해 디자인 시스템 adoption을 높이는 데 활용할 수 있다. - 행사에서 진행된 라운드테이블과 전문가 Q&A를 통해 디자인 시스템 운영 사례와 실무 관점도 공유했다. ## 디자인 시스템을 제품처럼 운영하기 - 디자인 시스템을 조직의 필수 도구로 만들려면 단순히 좋은 컴포넌트를 만드는 것만으로는 부족하다. - 제품처럼 다음 요소를 관리해야 한다. - 사용자의 요구와 문제 파악 - 명확한 가치 제안 - 지속적인 개선과 업데이트 - 사용 현황과 피드백 수집 - 사용자에게 변화와 이점을 알리는 커뮤니케이션 - 디자인 시스템의 성공은 완성도보다 **얼마나 많은 팀이 실제 업무에서 사용하는가**에 달려 있다. ## 내부 마케팅과 사용 확산 - 디자인 시스템은 일관성, 효율성, 확장성을 약속하지만, 실제 효과는 조직 전체의 사용이 전제되어야 나타난다. - 담당자는 “사용하라”고 지시하기보다 각 팀이 얻는 구체적인 이점을 설득해야 한다. - 디자인·개발 작업 시간 단축 - 중복 작업 감소 - 제품 간 시각적 일관성 향상 - 변경 사항을 여러 화면과 플랫폼에 빠르게 반영 - 내부 구성원을 대상으로 명확한 adoption 전략을 세우고, 교육·문서화·사례 공유를 통해 지속적인 참여를 유도해야 한다. ## 디자인 시스템 입문 - 아직 디자인 시스템을 시작하지 않은 팀을 위해 기본 개념과 구축 방법을 소개하는 입문 시리즈를 제공한다. - 디자인 시스템은 재사용 가능한 컴포넌트, 스타일, 규칙, 가이드라인을 모아 제품 제작 방식을 표준화하는 체계다. - 이를 활용하면: - 반복적인 디자인 결정을 줄일 수 있다. - 팀 간 협업 방식이 통일된다. - 제품이 성장해도 일관된 경험을 유지하기 쉽다. - 디자인과 개발 사이의 구현 차이를 줄일 수 있다. ## 성장과 확장을 지원한 Carvana 사례 - 온라인 중고차 거래 기업 **Carvana**는 급격한 고객 수요 증가와 사업 확장에 대응하기 위해 디자인 시스템을 활용했다. - 디자인 시스템과 변수를 사용해 제품 전반의 디자인 세부 사항을 일관되게 유지했다. - 특히 변수는 색상이나 기타 디자인 속성을 중앙에서 관리하고 변경할 수 있게 해, 여러 화면과 제품 영역에 일관된 수정 사항을 적용하는 데 도움을 줬다. - 이는 디자인 시스템이 시각적 통일성뿐 아니라 빠른 성장과 운영 효율성을 뒷받침하는 기반이 될 수 있음을 보여준다. 디자인 시스템을 도입할 때는 컴포넌트 제작에만 집중하기보다, 실제 사용자를 위한 제품으로 정의하는 것이 좋다. 명확한 사용 가치와 교육·홍보 전략을 마련하고, 사용 데이터를 분석하며 지속적으로 개선해야 조직 전체에서 정착시킬 수 있다.

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

디자인 시스템Figma디자인 토큰API+2

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

Framework 2024

Figma는 디자인 시스템 구축보다 더 어려운 과제인 조직 전체의 도입과 활용을 지원하기 위해 Framework 2024에서 세 가지 기능을 공개했다. Code Connect는 디자인과 실제 코드 사이의 간극을 줄이고, 타이포그래피·그라디언트 변수는 디자인 토큰의 범위를 확장하며, Library Analytics API는 디자인 시스템 사용 현황을 측정하도록 돕는다. 결론적으로 Figma는 디자인 시스템을 만드는 도구를 넘어, 개발자 adoption과 조직 내 확산까지 지원하는 방향으로 발전하고 있다. ### 디자인 시스템의 핵심 과제: 조직 전체의 도입 - 디자인 시스템은 일관성, 효율성, 확장성을 제공하지만 실제 효과는 팀 전체가 이를 사용할 때 발생한다. - 시스템이 강력하고 정교해질수록 복잡성도 커지며, 디자이너와 개발자의 적극적인 참여를 이끌어내는 일이 어려워진다. - Figma는 변수, 테마와 상태 관리, 고급 프로토타이핑, Dev Mode 등을 통해 디자인과 코드의 연결을 강화해 왔다. - 이번 발표의 중심 목표는 디자인 시스템을 “구축”하는 데서 나아가 조직 전반에서 “채택”되도록 만드는 것이다. ### Code Connect: 디자인과 코드의 연결 - Code Connect는 Dev Mode에서 디자인 시스템 컴포넌트에 대응하는 실제 코드 스니펫을 제공한다. - 개발자는 별도의 문서나 저장소를 검색하지 않고 Figma에서 필요한 코드를 확인하고 복사할 수 있다. - 이를 통해: - 구현 시간을 줄일 수 있다. - 디자인과 코드의 불일치를 완화할 수 있다. - 개발자가 디자인 시스템 컴포넌트를 사용하는 진입 장벽을 낮출 수 있다. - 임의로 유사한 컴포넌트를 새로 만드는 일을 줄일 수 있다. - Organization 및 Enterprise 요금제에서 베타로 제공되며, React·iOS·Storybook을 지원한다. - 향후 더 많은 프레임워크와 플랫폼으로 지원 범위가 확대될 예정이다. - Bumble, GitHub, HP 등의 팀은 디자인 시스템과 실제 프로덕션 코드 사이를 연결하는 문제와 Code Connect의 활용 가능성을 논의했다. ### 타이포그래피 변수: 디자인 토큰의 확장 - 기존 변수 기능만으로는 디자인 시스템의 중요한 영역인 타이포그래피를 충분히 표현하기 어려웠다. - 타이포그래피 변수를 사용하면 글꼴 크기, 행간, 글꼴 스타일 등 타이포그래피 속성을 변수와 토큰 체계 안에서 관리할 수 있다. - 주요 활용 방식: - 폰트 스케일을 한 번 정의하고 전체 시스템에 일관되게 적용 - 플랫폼별 타이포그래피 설정 조정 - 반응형 또는 테마별 텍스트 스타일 관리 - WCAG 기준을 고려한 접근성 높은 스케일 구성 - 디자인 시스템의 색상과 간격뿐 아니라 텍스트 표현까지 체계적으로 관리할 수 있게 된다. ### 그라디언트 변수: 더 풍부한 시각 스타일 관리 - 그라디언트도 변수로 정의하고 재사용할 수 있도록 지원한다. - 여러 화면과 컴포넌트에서 동일한 그라디언트 스타일을 일관되게 적용할 수 있다. - 브랜드 테마나 모드별로 그라디언트를 교체하기 쉬워진다. - 변수 기반 관리로 디자인 시스템이 단순한 색상 팔레트를 넘어 더 표현력 있는 시각 언어를 다룰 수 있다. ### Library Analytics API: 디자인 시스템 사용 현황 측정 - Library Analytics API는 조직 내 디자인 시스템 라이브러리와 컴포넌트의 사용 데이터를 분석할 수 있도록 제공된다. - 디자인 시스템 관리자는 다음과 같은 질문에 답할 수 있다. - 어떤 라이브러리와 컴포넌트가 실제로 사용되는가? - 어느 팀이나 프로젝트가 디자인 시스템을 적극적으로 채택하는가? - 사용되지 않거나 개선이 필요한 컴포넌트는 무엇인가? - 정량적인 사용 데이터를 바탕으로 문서화, 교육, 컴포넌트 개선, 도입 전략을 세울 수 있다. - 디자인 시스템의 성공을 단순히 “만들었는가”가 아니라 “얼마나 사용되는가”로 평가할 수 있게 한다. ### 실용적인 결론 디자인 시스템 팀은 컴포넌트와 토큰을 만드는 데 그치지 말고, 개발자가 실제 코드로 쉽게 사용할 수 있는 경로와 사용 현황을 측정할 방법까지 함께 마련해야 한다. Code Connect로 개발자 경험을 개선하고, 타이포그래피·그라디언트 변수로 토큰 범위를 확장하며, Analytics API로 채택률을 추적하는 접근이 효과적이다.

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

디자인 시스템FigmaReact디자인 토큰+3

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

디자인 시스템을 위한 올바

Code Connect는 Figma의 Dev Mode에서 자동 생성된 CSS 대신 조직의 실제 디자인 시스템 코드를 보여줘 디자인 시스템 도입률을 높이는 도구다. 개발자는 목업과 연결된 컴포넌트의 올바른 코드와 사용 지침을 바로 확인할 수 있어 구현 속도와 일관성이 향상된다. 결과적으로 잘못된 컴포넌트 사용과 중복된 일회성 컴포넌트의 생성·유지보수를 줄이는 것이 목표다. ## 디자인 시스템 도입이 어려운 이유 - 디자인 시스템을 구축해도 개발자가 시스템의 모든 컴포넌트와 패턴을 알지 못하는 경우가 많다. - 일부 컴포넌트를 사용하더라도 의도된 가이드라인과 다르게 적용할 수 있다. - 디자인 시스템의 성공은 단순히 사용 여부가 아니라, 올바르고 일관되게 사용하는지에 달려 있다. - 디자인과 코드는 서로 다른 도구와 제약을 가진 별개의 작업 영역으로 발전해 왔기 때문에 연결 지점이 부족했다. ## 디자인과 코드의 연결 - 디자인은 무엇을 만들지 탐색하고 결정하는 데 초점을 두며, 코드는 이를 구조적이고 유지보수 가능한 형태로 구현하는 데 초점을 둔다. - Figma는 두 영역이 원활하게 오갈 수 있어야 한다고 보고, Code Connect를 그 연결을 강화하는 기능으로 소개한다. - 기존의 Auto Layout, Variables, Component Props, Dev Mode 등의 기능과 함께 디자인 시스템을 코드에 더 가깝게 통합하려는 흐름에 속한다. - 디자인 시스템 팀이 작성한 실제 구현 방식과 문서를 디자인 목업의 맥락 안에서 제공한다. ## Code Connect의 핵심 기능 - Dev Mode에 표시되는 코드 스니펫을 조직의 실제 디자인 시스템 코드로 사용자 지정할 수 있다. - 자동 생성 CSS가 아니라 프로젝트에서 사용하는 컴포넌트, 속성, 패턴에 맞는 코드를 개발자에게 보여준다. - 개발자가 목업에서 특정 요소를 선택하면 관련 코드와 사용법을 별도의 문서 검색 없이 확인할 수 있도록 한다. - 올바른 구현 예시와 디자인 시스템 사용 원칙을 함께 제공해 오용을 줄인다. - 디자인 시스템의 재사용을 촉진해 중복 컴포넌트와 일회성 구현의 생성을 줄인다. ## 개발자 워크플로에 맞춘 설치 방식 - Code Connect는 개발자가 익숙한 패키지 및 명령줄 기반 방식으로 설치·설정할 수 있다. - JavaScript와 TypeScript 프로젝트에서는 **npm**을 사용한다. - SwiftUI 프로젝트에서는 **Swift Package Manager**를 지원한다. - 설치 패키지와 설정 방법은 GitHub 저장소에서 제공된다. - 향후 더 많은 플랫폼을 지원해 기존 개발 환경에 자연스럽게 통합하는 것을 목표로 한다. ## 기대 효과 - 개발자가 디자인 시스템 컴포넌트를 더 쉽게 발견하고 사용할 수 있다. - 디자인에서 코드로 전환하는 과정이 빨라지고 구현 효율이 높아진다. - 실제 코드와 디자인 간의 차이를 줄여 제품 전반의 UI 일관성을 높인다. - 디자인 시스템 팀의 문서화와 모범 사례를 개발 작업의 적절한 시점에 전달할 수 있다. - 결과적으로 조직 전체의 디자인 시스템 채택률과 유지보수성을 개선한다. Code Connect를 도입할 때는 자주 사용하는 컴포넌트부터 실제 프로덕션 코드와 연결하고, 각 컴포넌트의 올바른 사용 예시와 속성 매핑을 함께 관리하는 것이 효과적이다. Primitives나 자동 생성 코드보다 조직의 표준 컴포넌트가 우선 노출되도록 구성해야 도입 효과를 극대화할 수 있다.

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

디자인 시스템FigmaTypeScriptJavaScript+4

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

알래스카 항공, 변

Alaska Airlines는 Figma의 디자인 시스템과 Variables를 활용해 웹·모바일·디지털 사이니지·키오스크 전반의 경험을 일관되게 관리하고 있다. 45명 규모의 디자인 팀은 이를 통해 디자이너당 주당 평균 11시간을 절약했으며, 개발팀과의 협업과 접근성·구현 정확성도 개선했다. 특히 Auro 디자인 시스템의 재사용 컴포넌트는 긴급한 서비스 개편을 한 스프린트 안에 완료하도록 도왔다. ## 기존 도구와 단일 기준 부재의 문제 - Sketch와 InVision을 사용하던 시기의 디자인 시스템은 여러 도구가 뒤섞인 “프랑켄슈타인” 같은 상태였다. - 재사용 위젯이 직관적이지 않았고, 프로토타이핑과 실시간 협업 기능도 부족했다. - 디자인과 개발을 연결하는 단일 진실 공급원(Single Source of Truth)이 없어 다음 문제가 발생했다. - 컴포넌트와 패턴의 간격·색상 등이 몇 픽셀씩 어긋남 - 플랫폼별로 변경 사항을 수동 복사·붙여넣기 - 버튼, 체크박스, 모달, 색상, 날짜 선택기 등의 불일치 - 접근성 기준을 놓칠 가능성 증가 - 최신 파일이나 올바른 버전을 찾기 어려움 - 결과적으로 개발자는 실제 웹사이트와 맞지 않는 디자인을 전달받는 경우가 많았다. ## Auro 디자인 시스템과 Figma 도입 - Alaska Airlines는 Figma를 도입하며 디자이너와 엔지니어 모두를 위한 디자인 시스템 문서를 구축했다. - Auro는 웹 컴포넌트와 대응되는 디자인 컴포넌트를 제공해 설계와 구현 사이의 차이를 줄였다. - 컴포넌트, 색상, 패턴 등을 공통으로 참조할 수 있어 여러 인터페이스에서 일관된 사용자 경험을 유지할 수 있게 됐다. - 디자인 시스템 운영 과정에서 Auto Layout, 브랜치 및 병합 기능 등의 사용법도 문서화해 팀 내 채택률을 높였다. - 교육을 강화한 결과 디자이너의 Figma 활용도가 높아졌고, 디자이너와 엔지니어 간 충돌도 줄었다. ## 재사용 컴포넌트로 긴급 대응 속도 향상 - 심각한 폭풍으로 항공편 지연이 급증했을 때, 기존에 충분히 활용되지 않던 항공편 상태 페이지를 빠르게 개편했다. - 디자인·개발 타이거 팀은 개편에 필요한 컴포넌트의 90%를 Figma의 Auro 디자인 시스템에서 재사용했다. - Figma가 없었다면 최소 4~5개 스프린트가 필요했을 작업을 단 한 스프린트에 완료했다. - 개편 후 항공편 상태 페이지의 평균 체류 시간은 다음과 같이 증가했다. - 기존: 36초 - 변경 후: 5분 10초 - 증가율: 761% - 새 페이지에는 항공편 추적 정보와 항공기 세부 정보 등 고객에게 필요한 정보가 추가됐다. ## 디자인과 개발 간 신뢰 강화 - Figma는 처음에는 디자이너 간 협업 도구로 도입됐지만, 점차 엔지니어가 Auro의 설계 원칙을 이해하는 수단으로도 활용됐다. - 엔지니어가 실제로 사용하는 웹 컴포넌트와 유사한 디자인 컴포넌트를 참조할 수 있어 구현 가능성을 더 쉽게 판단하게 됐다. - 디자인이 구현 결과와 가까워지면서 팀 간 신뢰가 높아졌다. - 디자인 시스템 문서와 기능 교육은 디자이너가 Figma의 기능을 제대로 활용하도록 돕고, 협업 과정의 불필요한 충돌을 줄였다. ## Variables를 통한 다중 환경 대응 - Figma Variables를 활용해 23,000명 이상의 직원과 다양한 조직·파트너의 요구에 맞춰 디자인을 조정할 수 있게 됐다. - 다음과 같은 조건을 체계적으로 관리할 수 있다. - 다양한 화면 크기 - 라이트 모드와 다크 모드 - 팀별 테마 - 외부 파트너를 위한 테마 - 여러 환경에 맞는 디자인을 개별적으로 수정하는 대신, 변수 기반으로 체계화해 반복 작업을 줄였다. - 그 결과 Alaska의 디자이너들은 평균적으로 주당 11시간의 작업 시간을 절약했다. Alaska Airlines 사례는 디자인 시스템을 단순한 컴포넌트 모음이 아니라 디자인·개발·문서·교육을 연결하는 운영 체계로 구축해야 효과가 커진다는 점을 보여준다. 여러 플랫폼과 테마를 동시에 지원해야 하는 조직이라면 공통 컴포넌트와 Variables를 함께 도입하고, 이를 뒷받침할 문서화와 팀 교육까지 병행하는 것이 실용적이다.

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

디자인 시스템Figma사용자 경험디자인 토큰+4

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

카바나가 일관성과 확장성을

Carvana는 Figma의 디자인 시스템과 변수를 활용해 빠른 성장 속에서도 제품 경험의 일관성과 확장성을 유지했다. 분산된 디자인 도구를 Figma로 통합해 단일 기준을 만들고, 변수와 테마 기능으로 디자인·개발 협업과 브랜드 확장을 효율화했다. 그 결과 반복 작업과 수정이 줄고, 새로운 사업 영역에도 기존 디자인 언어를 빠르게 적용할 수 있었다. ## 성장에 대응하는 단일 기준 마련 - Carvana는 2019년 성장세가 가속화되면서 확장 가능한 디자인 플랫폼이 필요해졌다. - 기존 디자인 시스템은 PDF 기반 UI 키트, Principle, Sketch 등 여러 도구에 흩어져 있었다. - 컴포넌트를 복사해 사용하는 방식 때문에 동일한 요소가 조금씩 변형됐고, 디자인과 개발팀이 참조할 중앙 기준이 없었다. - Figma로 디자인 시스템을 이전하면서 디자인·개발팀이 함께 참조할 수 있는 연결된 단일 소스 오브 트루스를 구축했다. - 코로나19 시기 차량 판매가 급증했을 때도 통합된 시스템 덕분에 기존 도구에서 발생하던 협업 마찰을 줄이고 수요에 대응할 수 있었다. - 약 40명의 디자인 시스템 팀이 1만 명 규모의 회사 전반에 디자인 품질을 확산시키는 역할을 담당했다. ## 변수로 디자인 일관성과 효율성 강화 - 제품 생태계가 커지면서 색상, 간격, 타이포그래피, 모서리 반경이 화면과 컴포넌트마다 달라지는 문제가 발생했다. - Figma 변수는 색상이나 수치처럼 재사용 가능한 값을 정의하고 여러 디자인 속성에 적용할 수 있게 했다. - 특히 숫자 변수를 활용해 spacing과 corner radius를 일관된 값으로 관리했다. - 변수의 값을 중앙에서 정의하면 디자이너가 픽셀 수준의 정확성을 유지하면서도 반복적인 수정 작업을 줄일 수 있다. - 초기에는 변수 설정과 학습에 비용이 들었지만, 결과적으로 디자인 완성도가 높아지고 리뷰 과정에서 되돌아오는 수정 사항이 감소했다. - 변수 기반 시스템은 장기적으로 디자이너의 반복 작업과 리비전을 줄여 효율을 높인다. ## 테마 기능으로 인수 사업 통합 - Carvana가 자동차 경매 기업 ADESA를 인수한 뒤에도 변수는 새로운 브랜드 테마를 빠르게 도입하는 데 활용됐다. - 컴포넌트의 구조와 기능은 유지하면서 변수 값만 바꾸어 ADESA 전용 색상과 스타일을 적용할 수 있었다. - 기존 방식이라면 새 스타일에 맞춰 컴포넌트 라이브러리를 다시 구축하는 데 최소 한 달이 걸렸을 작업을, 변수 기반 테마로 1주일 이내에 처리했다. - ADESA용 디자인 시안을 평소보다 약 3배 빠르게 제작할 수 있었다. - 브랜드 변경을 개별 컴포넌트의 재작업이 아니라 테마 전환으로 처리함으로써 여러 화면 너비와 제품 영역에 일관되게 적용할 수 있었다. ## 디자인과 개발 간 연결 강화 - Figma 기반 디자인 시스템은 디자이너와 개발자가 동일한 컴포넌트와 변수 기준을 참조하도록 돕는다. - 중앙화된 라이브러리와 변수는 디자인 변경 사항을 일관되게 관리하고 핸드오프 과정의 마찰을 줄이는 기반이 된다. - 글에서는 변수와 Figma REST API를 활용한 개발 연계 및 변수 마이그레이션 사례도 소개한다. Carvana 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

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

디자인 시스템Figma사용자 경험디자인 토큰+4

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

디자인 시스템의 미래는

디자인 시스템은 좋은 컴포넌트와 문서를 만드는 것만으로 성공하지 않으며, 조직 구성원이 실제로 사용하도록 만드는 채택 전략이 필요하다. 따라서 디자인 시스템 팀은 자신들의 시스템을 하나의 제품처럼 보고, 사용자 이해·메시지 설계·조직 내 홍보·성과 측정을 마케팅 방식으로 수행해야 한다. 이를 통해 디자인 시스템을 선택 사항이 아닌 조직의 필수 기반으로 자리매김할 수 있다. ## 디자인 시스템도 제품처럼 시장 적합성을 찾아야 한다 - 디자인 시스템의 효과인 일관성, 효율성, 확장성은 구성원들이 널리 사용할 때 비로소 실현된다. - 단순히 Slack 메시지를 보내거나 교육 세션을 여는 것만으로는 채택을 이끌어내기 어렵다. - 디자인 시스템 팀은 내부 사용자를 대상으로 제품-시장 적합성(product-market fit)을 지속적으로 탐색해야 한다. - 디자이너, 개발자, 의사결정자 등 다양한 사용자의 다음 요소를 파악해야 한다. - 현재 업무 방식과 프로세스 - 반복되는 병목과 불편 - 새로운 도구에 대한 우려 - 시스템이 일상 업무에 제공할 수 있는 가치 - 아직 명확히 표현하지 못한 욕구와 불만 - 개별 실무자부터 리더십까지 Product Design and Engineering 조직 전반을 인터뷰하면 역할별 관점을 전략에 반영할 수 있다. - 인터뷰는 디자인 시스템 자체를 설명하는 것보다 현재의 업무 목표와 문제점을 먼저 묻는 방식으로 시작하는 것이 효과적이다. ## 대상별로 다른 메시지를 설계해야 한다 - 디자이너, 개발자, 프로젝트 관리자, 의사결정자는 같은 시스템을 사용하더라도 관심사와 판단 기준이 다르다. - 따라서 모두에게 동일한 홍보 문구를 전달하기보다 대상별로 설득 논리를 조정해야 한다. - **디자이너에게는** - 브랜드 일관성을 유지하면서도 창의성을 발휘할 수 있다는 점을 강조한다. - **개발자에게는** - 컴포넌트 재사용과 표준화 - 디자인과 코드 사이의 원활한 협업 - 반복 작업 감소와 효율 향상을 설명한다. - **의사결정자에게는** - 출시 속도 향상 - 기술 부채 감소 - 투자 대비 효과(ROI)를 중심으로 제안한다. - 유연성 부족, 기술적 한계, 도입 비용과 같은 반대 의견도 피하지 말고 구체적으로 다뤄야 한다. - 사용자의 회의적인 이유를 이해하고 이에 답하는 메시지를 제시하면 저항을 설득과 참여로 전환할 수 있다. ## 채택을 높이는 기능과 도구 - 글에서는 조직 전체의 채택을 지원하는 사례로 다음과 같은 기능을 언급한다. - 개발자를 위한 Code Connect - 타이포그래피 및 그라디언트 변수 - 디자인 시스템 사용 현황을 파악하는 Library Analytics API - 이런 기능은 디자인과 코드의 연결을 강화하고, 시스템이 실제로 어떻게 사용되는지 확인하게 해준다. - 특히 사용 데이터를 확보하면 어떤 팀이 시스템을 사용하고 있는지, 어느 부분에서 채택이 막히는지 파악해 후속 전략을 세울 수 있다. ## 조직 내부의 마케팅으로 접근하기 - 디자인 시스템 팀의 역할은 시스템을 구축하는 데서 끝나지 않고, 조직 안에서 그 가치를 지속적으로 알리고 확산시키는 데까지 확장되어야 한다. - 시스템을 성공시키려면 다음과 같은 제품 출시 전략이 필요하다. - 대상 사용자와 문제 정의 - 대상별 가치 제안 작성 - 도입 장벽과 반론에 대한 대응 - 내부 홍보와 지지자 확보 - 사용량과 성과 측정 - 이런 마케팅 관점은 디자인 시스템을 “있으면 좋은 도구”가 아니라 디지털 제품을 설계하고 개발하는 방식의 핵심 기반으로 바꾸는 데 목적이 있다. 실무적으로는 먼저 디자이너·개발자·리더를 인터뷰해 각자의 문제를 정리하고, 대상별 가치 제안과 도입 장벽을 문서화하는 것이 좋다. 이후 사용량과 반복 사용률 같은 데이터를 추적하면서 메시지와 지원 방식을 계속 개선해야 한다.

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

디자인 시스템Figma프로덕트 디자인user-research+3

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

컴포넌트 스프린트의

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

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

디자인 시스템Figmafigjamslack+3

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

디자인 시스템 구축 방법

디자인 시스템은 제품 전반의 일관성을 높이고, 재사용 가능한 컴포넌트와 공통 언어를 통해 디자인·개발 업무를 효율화하는 기반이다. 성공적인 시스템은 정해진 정답을 따르기보다 조직의 목표와 문제에 맞춰 설계하고, 제품과 팀의 변화에 따라 지속적으로 발전해야 한다. 이를 위해 목표 설정, 기존 자산 조사, 협업자 확보, 적절한 구축 방식 선택이 선행되어야 한다. ## 디자인 시스템의 목표와 범위 정의 - 컴포넌트를 만들기 전에 디자인 시스템을 도입하려는 이유를 명확히 해야 한다. - 다음 질문에 답하면서 목표를 구체화한다. - 왜 디자인 시스템이 필요한가? - 어떤 문제를 해결할 것인가? - 문제가 해결되었는지 어떻게 측정할 것인가? - 플랫폼 간 UI 불일치, 반복적인 수동 수정, 디자인·개발팀 간 협업 문제 등이 주요 도입 계기가 될 수 있다. - 디자인 시스템은 소규모 팀의 단순한 컴포넌트 모음부터 대기업의 종합적인 표준 체계까지 다양한 규모로 구성할 수 있다. - 중요한 것은 조직의 현재 상황에 맞게 시작하고, 필요에 따라 확장 가능한 구조를 만드는 것이다. ## 기존 디자인과 코드 자산 조사 - 여러 플랫폼과 디바이스에서 제품 UI를 수집한다. - 일반 화면뿐 아니라 다음과 같은 변형도 함께 확인한다. - 호버·포커스·비활성·오류 등 인터랙션 상태 - 반응형 레이아웃 - 플랫폼별 또는 제품별 대체 버전 - 스크린샷을 모으면 반복되는 시각적 패턴과 일관된 요소를 파악하기 쉽다. - 디자인 파일만 조사해서는 안 되며, 코드베이스도 함께 점검해야 한다. - 개발자가 이미 구현한 다음 자산을 확인하면 기존 엔지니어링 작업을 재활용할 수 있다. - 반복적으로 사용되는 UI 요소 - 공통 CSS 변수 - 공유 컴포넌트 - 표준화된 구현 패턴 - 디자인과 코드 양쪽을 조사해야 서로 다른 시스템이 병렬로 만들어지는 문제를 줄일 수 있다. ## 패턴 분류와 문제점 평가 - 수집한 화면과 컴포넌트를 유형별로 분류해 현재 제품의 디자인 언어를 파악한다. - 같은 문제를 여러 방식으로 해결하고 있는지 확인한다. - 다음과 같은 문제는 디자인 시스템으로 개선할 후보가 된다. - 비슷한 UI가 제품마다 다르게 보이는 경우 - 중복 컴포넌트나 불필요한 변형이 많은 경우 - 디자인팀과 개발팀이 동일한 문제를 각자 다르게 해결하는 경우 - 사용자 경험이 화면이나 플랫폼에 따라 단절되는 경우 - 이 과정은 무엇을 새로 만들지뿐 아니라 무엇을 통합·정리·폐기할지도 결정하는 단계다. ## 조직 내 챔피언 확보 - 디자인 시스템은 한 직군만의 프로젝트가 아니라 디자인, 개발, 제품 관리가 함께 참여하는 팀 작업이다. - 일관된 제품 경험에 관심이 있는 사람을 조직 내 협력자로 확보해야 한다. - 개발자는 실제 코드 구현과 유지보수를 담당하므로 초기부터 참여시키는 것이 중요하다. - 개발자는 컴포넌트의 기술적 실현 가능성, API 설계, 유지보수 비용에 대한 현실적인 의견을 제공할 수 있다. - 성공적인 디자인 시스템이 반드시 대규모 전담 조직에서 시작되는 것은 아니며, 한 명의 담당자에서 출발할 수도 있다. ## 구축 방식 선택 - 디자인 시스템을 구축하는 방법은 크게 두 가지다. - 조직의 요구에 맞춰 처음부터 직접 구축하기 - 기존 프레임워크를 도입한 뒤 제품 상황에 맞게 조정하기 - 선택할 때는 현재 보유한 디자인·코드 자산, 팀 규모, 기술 역량, 유지보수 가능성을 함께 고려해야 한다. - 기존 시스템을 그대로 복사하기보다 조직의 목표와 제품 특성에 맞는 수준으로 조정하는 것이 중요하다. ## 이후의 구축 단계 - 글은 전체 과정을 다음 세 단계로 제시한다. - 기반 마련: 목표 정의, 기존 자산 조사, 문제 평가, 협력자 확보 - 디자인 기반 정의: 색상, 타이포그래피, 간격 등 공통 시각 규칙 수립 - Figma에서 구축: 디자인 자산과 재사용 가능한 컴포넌트를 체계적으로 구성 - 구축 후에도 시스템은 고정된 결과물이 아니라 제품과 팀의 변화에 맞춰 계속 관리하고 발전시켜야 한다. 실무에서는 모든 것을 한 번에 만들기보다 가장 반복적으로 사용되고 영향이 큰 패턴부터 시작하는 것이 좋다. 디자인과 코드를 함께 조사하고 개발자를 초기 단계부터 참여시키면 실제 제품에 적용되고 유지되는 디자인 시스템을 만들 가능성이 높아진다.

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

디자인 시스템Figma사용자 경험사용자 인터페이스+3

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

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가 제시한 방향은 디자인 시스템을 엄격한 규칙만으로 운영하기보다, 구조화된 관리와 자유로운 창작을 함께 지원하는 것이다. 조직에서는 디자인 토큰과 컴포넌트 표준화뿐 아니라 코드 연결, 사용량 분석, 디자이너·엔지니어 간 협업 체계까지 함께 구축하는 것이 실용적이다.

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

디자인 시스템Figma접근성design-to-code+3

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

원활한 핸드오프를

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

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

디자인 시스템Figma디자인 토큰dev-mode+3

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

디자인 시스템이란 무엇

디자인 시스템은 제품의 시각적 요소와 상호작용 방식을 일관되게 유지하도록 돕는 공통 언어이자 설계·개발을 위한 체계다. 색상, 아이콘, 버튼, 문구 같은 요소를 표준화하고 재사용함으로써 제작 시간을 줄이고 사용자 경험과 브랜드 정체성을 보호한다. 단순한 스타일 가이드가 아니라 원칙, 컴포넌트, 패턴, 기술 문서와 프로세스를 포괄하는 지속적으로 발전하는 기반이다. ## 디자인 시스템이란 무엇인가 - 제품과 서비스의 디자인·개발을 안내하는 **재사용 가능한 구성 요소와 표준의 집합**이다. - 복잡한 디지털 제품을 만들 때 팀이 공유할 수 있는 통일된 언어와 구조를 제공한다. - 요소를 매번 새로 설계하지 않아도 되므로 대규모 제품 개발에서 시간과 노력을 줄인다. - 디자인 시스템이 없으면 화면마다 스타일과 동작이 달라지는 **일관성 위기**가 발생할 수 있다. - 사용자가 인터페이스를 혼란스럽게 느낄 수 있다. - 브랜드 정체성이 약화될 수 있다. - 반복적인 디자인 작업과 구현 비용이 늘어난다. ## 디자인 시스템의 계층 구조 ### 1. 디자인 시스템 - 제품 생태계 전체를 아우르는 최상위 개념이다. - 다음과 같은 자원을 포함할 수 있다. - 기술 사양 - 디자인 토큰 - 컴포넌트 및 패턴 문서 - 모범 사례 - UX 설계 원칙 - 제품 개발 프로세스 - 고정된 규칙집이 아니라 제품과 조직의 변화에 따라 계속 발전하는 기반이다. ### 2. 컴포넌트 및 패턴 라이브러리 - 제품에서 반복적으로 사용하는 시각 요소와 상호작용 방식을 모아 둔 라이브러리다. - 컴포넌트의 예: - 버튼 - 입력 필드 - 기타 UI 요소 - 패턴의 예: - 내비게이션 흐름 - 데이터 표시 방식 - 레이아웃과 템플릿 - 반복되는 사용자 상호작용 - 코드 스니펫, 기술 사양, 사용 지침을 함께 제공해 디자인 의도를 실제 구현으로 연결한다. - 디자이너와 개발자가 동일한 기준을 참고하는 협업 지점 역할을 한다. - **컴포넌트 라이브러리**가 개별 UI 요소에 집중한다면, **패턴 라이브러리**는 더 넓은 문제 해결 방식과 사용자 흐름을 다룬다. ## 디자인 시스템과 스타일 가이드의 차이 - 스타일 가이드는 주로 다음과 같은 시각적 요소를 정의한다. - 색상 - 글꼴과 타이포그래피 - 이미지와 시각적 표현 - 디자인 시스템은 스타일 가이드보다 범위가 넓다. - 코딩 표준 - 사용성 원칙 - 상호작용 패턴 - 기술 문서 - 제품 개발 프로세스까지 포함할 수 있다. - 따라서 스타일 가이드는 디자인 시스템을 구성하는 일부로 볼 수 있다. ## 3. 기초 요소 - 제품의 전반적인 시각 언어와 목소리·말투를 정의한다. - 대표적인 구성 요소는 다음과 같다. - 색상 - 타이포그래피 - 아이콘 - 로고 - 일러스트레이션 - 접근성 가이드라인 - 브랜드 가이드라인 - 단순히 화면을 예쁘게 만드는 것을 넘어, 제품이 어떤 인상을 주고 어떤 방식으로 소통할지를 결정한다. ## 디자인 시스템과 UX - 디자인 시스템이 디자이너의 창의성을 제한하고 모든 화면을 똑같이 만든다는 것은 흔한 오해다. - 실제로는 반복적인 문제를 해결해 디자이너가 더 중요한 사용자 경험과 제품 문제에 집중하도록 돕는다. - 공통 요소와 기준을 재사용하면 일관성을 확보하면서도 제품 목적에 맞는 새로운 경험을 설계할 수 있다. - 색상, 아이콘, 버튼의 형태뿐 아니라 명확한 언어와 접근성까지 관리하므로 UX 전반에 영향을 준다. 디자인 시스템을 도입할 때는 단순히 UI 컴포넌트 목록을 만드는 데 그치지 말고, 디자인 원칙·접근성·코드·문서·협업 프로세스까지 함께 정의하는 것이 좋다. 또한 처음부터 모든 요소를 완성하려 하기보다 반복적으로 사용되는 핵심 요소부터 구축하고, 제품과 팀의 변화에 맞춰 지속적으로 관리해야 한다.

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

디자인 시스템사용자 경험접근성디자인 토큰+2

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

원활한 피그마 마이

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 마이그레이션은 도구를 설치하는 프로젝트가 아니라 조직의 협업 체계를 재설계하는 프로젝트로 접근해야 한다. 먼저 부서 간 옹호 팀을 만들고, 리더십과 실무자의 지지를 확보한 뒤, 외부 사례와 단계별 일정을 바탕으로 파일럿부터 시작하는 방식을 추천한다.

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

디자인 시스템Figmadesign-collaborationdesign-tools+2

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

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를 효과적으로 활용하려면 디자인과 개발을 별도 도구로 분리하기보다, 디자인 파일 안에서 주석·측정값·준비 상태·변경 이력을 일관되게 관리하는 것이 좋습니다. 특히 개발 전달 전에 “개발 준비 완료” 상태와 변경점을 명확히 표시하면 커뮤니케이션 비용을 줄일 수 있습니다.

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

디자인 시스템FigmaReactdesign-to-code+3