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 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

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

sketchFigma디자인 시스템사용자 경험+4

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

News UK가 멀티

News UK는 서로 다른 역사와 요구사항을 가진 여러 브랜드를 하나의 디자인 시스템으로 통합했다. 기존에는 Sketch, Abstract, Zeplin, InVision을 조합하면서 라이브러리 유지보수와 브랜드별 변형 관리가 복잡해졌지만, Figma로 전환해 도구와 라이브러리를 중앙화했다. 또한 교육, 문서화, 디자이너 옹호자 제도를 통해 조직의 참여를 이끌어내면서 확장 가능한 시스템을 구축했다. ## 여러 브랜드를 하나로 통합해야 했던 배경 - News UK는 인쇄 매체뿐 아니라 온라인, 라디오, TV까지 사업을 확장했다. - The Times, The Sun 등 각 브랜드는 독립적인 디자인 조직, 제품 팀, 도구를 사용하고 있었다. - 브랜드마다 고유한 역사와 시각적 요구사항이 있어 단순히 동일한 디자인을 강제할 수 없었다. - 여러 브랜드와 제품에서 디자인·개발을 확장하려면 공통 요소를 재사용하면서도 브랜드별 차이를 유지할 수 있는 시스템이 필요했다. ## 기존 도구 조합의 문제점 - Sketch, Abstract, Zeplin, InVision을 함께 사용했지만 결과적으로 작업 흐름이 분절됐다. - 디자인 시스템 팀이 라이브러리 업데이트와 유지보수에 며칠에서 몇 주씩 소요됐다. - 브랜드별 변형을 지원하기 위해 수천 개의 텍스트 스타일과 컴포넌트 스타일이 생겼다. - 기존 테마 기능은 제품과 브랜드 요구가 늘어날수록 지나치게 복잡하고 경직됐다. - The Times의 라디오 사업처럼 새로운 유형의 제품이 시스템을 사용하기 시작하면서, 디자인 시스템 팀이 각 팀을 직접 지원해야 하는 부담이 커졌다. - 사용하기 어려운 시스템은 팀의 채택을 이끌어내지 못했기 때문에, 도구와 운영 방식 모두를 재검토해야 했다. ## Figma로 도구와 라이브러리 통합 - News UK는 Sketch와 여러 보조 도구를 Figma로 전환했다. - 전환의 목표는 다음과 같았다. - 여러 도구를 하나로 통합 - 라이브러리 관리의 중앙화 - 디자이너의 실제 사용과 기여 촉진 - Figma 도입 후 디자이너들은 디자인 시스템을 업무를 방해하는 제약이 아니라 효율을 높이는 기반으로 인식하기 시작했다. - 전체 마이그레이션은 약 몇 주 만에 진행됐다. ## 채택을 유도한 교육과 참여 방식 - 새로운 시스템을 배포하고 “사용하라”고 지시하는 것만으로는 충분하지 않다고 판단했다. - 디자인 시스템 팀이 각 디자이너의 Figma 작업 공간을 직접 설정하고 온보딩했다. - 다음과 같은 주제의 맞춤형 워크숍과 문서를 제공했다. - Sketch 파일 마이그레이션 - 파일 구조화와 관리 - 컴포넌트 사용법 - 댓글 작성과 디자인 검사 - Jira 등 외부 도구와의 연동 - 디자이너들과 함께 컴포넌트 사양과 재사용 가능한 디자인 패턴을 만들고 조직 전체에 공유했다. - 특정 상황에서 어떤 컴포넌트를 선택해야 하는지 안내하는 Figma 기반 도구와 프로토타입도 제작했다. ## 디자이너 옹호자 제도 - 각 제품 영역에서 디자인 시스템을 홍보할 디자이너 옹호자(designer advocate)를 모집했다. - 옹호자는 다음 역할을 맡았다. - 팀 내 디자인 시스템 사용 촉진 - 우수 사례와 사용법 공유 - 디자인 시스템 팀과 현업 팀 사이의 주요 연락 창구 - 시스템 변경 사항을 제품 팀에 전달 - 중앙 조직이 모든 팀을 직접 지원하는 대신, 각 조직 안에서 시스템이 확산되도록 만든 방식이다. ## 브랜드별 테마를 지원하는 시스템 - 동일한 컴포넌트에 서로 다른 브랜드 테마를 적용할 수 있도록 구성했다. - News UK는 자체 Themer 플러그인을 개발해 여러 브랜드에 적용할 컴포넌트를 쉽게 실험하고 구축했다. - 이를 통해 공통 컴포넌트의 구조와 동작은 재사용하면서도 색상, 스타일 등 브랜드별 표현을 유지할 수 있었다. - 디자인 시스템이 모든 브랜드에 억지로 동일하게 적용되는 대신, 각 브랜드에 맞게 제작된 것처럼 느껴지도록 했다. ## 확장 이후의 효과 - 디자이너들이 더 이른 시점에 협업하고 피드백을 주고받을 수 있게 됐다. - 팀 간 고립과 기존 솔루션의 중복 제작이 줄었다. - 모든 제품·디자인 팀에 시스템을 배포한 뒤 내부 NPS가 첫 분기에 23포인트 상승했다. - 제품 팀이 시스템에 실제로 참여하고, 업무 효율 향상과 재사용의 이점을 체감하기 시작했다. - 디자인 시스템은 완성된 결과물이 아니라 지속적으로 개선되는 확장 기반으로 자리 잡았다. ## 실용적인 결론 다중 브랜드 디자인 시스템의 성공은 컴포넌트와 도구만으로 결정되지 않는다. 브랜드별 차이를 수용할 수 있는 테마 구조, 중앙화된 라이브러리, 체계적인 온보딩, 현업 디자이너의 참여와 옹호자 네트워크를 함께 구축해야 한다. 특히 시스템을 일방적으로 배포하기보다 사용자가 이해하고 기여할 수 있도록 만드는 운영 체계가 중요하다.

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

sketchFigma디자인 시스템jira+4

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

BT가 통신 산업을 계속

174년 역사의 통신 기업 BT는 빠르게 변화하는 기술과 높아진 사용자 기대에 대응하기 위해 제품 개발 방식을 전환했다. 제품·엔지니어링·디자인 인력을 소규모 제품 스쿼드로 재편하고 Figma를 도입하면서 협업과 의사결정의 속도, 투명성을 높였다. 그 결과 도구 비용을 50% 절감하고, 원격근무 상황에서도 혁신을 지속할 수 있었다. ## 제품 스쿼드 모델로의 전환 - BT는 제품, 엔지니어링, 디자인 조직을 제품 스쿼드 중심으로 재구성했다. - 각 스쿼드는 특정 제품의 기획부터 출시까지 전 과정을 책임지는 소규모·유연한 팀으로 운영됐다. - 디자이너는 더 이상 디자이너끼리만 일하지 않고, 제품 담당자, 엔지니어, 콘텐츠 디자이너와 함께 협업했다. - 그러나 기존에는 문서, Sketch, InVision, Jira 등 여러 도구를 병행해야 했다. - 파일 이동과 여러 피드백 채널 관리에 시간이 소요되어 실제 디자인 작업과 팀 간 소통이 비효율적이었다. ## Figma 도입과 협업 방식 개선 - 180명 이상의 디자이너가 있는 만큼, BT는 먼저 한 제품 스쿼드에서 2개월간 Figma를 시험 운영했다. - 몇 주 만에 실시간 협업, 디자인 핸드오프, 파일 관리가 쉬워졌다는 긍정적인 피드백을 얻었다. - 디자인, 프로토타이핑, 발표를 하나의 도구에서 처리하면서 Sketch와 InVision 사이에서 파일을 옮길 필요가 줄었다. - 제품 담당자와 엔지니어도 진행 중인 디자인을 직접 확인하고 초기 단계부터 의견을 제시할 수 있게 됐다. - Figma 파일 링크만 공유하면 임원과 외부 이해관계자도 기기와 장소에 관계없이 디자인을 보고 댓글을 남길 수 있었다. - 파일럿 이후 BT는 모든 제품 스쿼드에 Figma를 확대 적용했다. ## 협업을 넘어선 효과 - **비용 50% 절감:** Sketch와 InVision을 Figma로 대체하고 디자인 도구를 통합했다. - **디자인의 의사결정 참여 확대:** 이해관계자가 디자인 과정에 더 잘 접근하게 되면서 디자인이 사업 의사결정과 투자 논의의 핵심 요소가 됐다. - **디자인 일관성 강화:** 브랜드, 제품, 여러 사업부를 아우르는 중앙화된 디자인 시스템 구축의 기반을 마련했다. - **업무 연속성 확보:** 코로나19로 재택근무가 시행된 뒤에도 구성원들이 Figma에서 함께 아이디어를 공유하고 문제를 해결할 수 있었다. - **발표 방식 변화:** 완성된 프레젠테이션을 만드는 대신 CEO와 라이브 디자인 파일을 함께 보며 ‘경험 walkthrough’를 진행했다. - **투명성과 효율 향상:** 팀 전체가 동일한 작업물을 실시간으로 확인해 공동의 이해를 빠르게 형성하고, 제품과 기능을 더 자신 있게 출시할 수 있었다. ## 실용적인 시사점 협업 도구 도입만으로 변화가 완성되는 것은 아니며, 먼저 조직을 제품 중심의 소규모 팀으로 재편하고 팀 간 공동 책임 구조를 만들어야 한다. 이후 파일럿 운영으로 효과를 검증한 뒤 도구를 확산하면 구성원의 수용성을 높이면서 비용 절감, 의사결정 가속화, 원격 협업 강화까지 함께 달성할 수 있다.

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

sketchFigma디자인 시스템프로토타이핑+3

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

페어 디자인하는 방법

디자인 페어링은 두 명의 디자이너가 같은 문제를 동시에 해결하는 협업 방식이다. 즉각적인 피드백과 다양한 아이디어를 통해 디자인 품질을 높이고, 오류·엣지 케이스를 조기에 발견하며, 결과적으로 작업 시간과 커뮤니케이션 비용을 줄일 수 있다. 글은 역할과 진행 방식을 명확히 정하고 짧은 실험부터 시작하면 상사에게도 투자 가치를 설득할 수 있다고 주장한다. ## 디자인 페어링의 정의 - 두 사람이 같은 디자인 문제를 같은 시간에 함께 해결한다. - 회원가입 플로우에서 한 명은 계정 생성, 다른 한 명은 온보딩을 맡는 방식은 ‘분업’이지 페어링이 아니다. - 페어링에서는 하나의 문제를 함께 탐색하고, 아이디어를 만들고, 의사결정을 내린다. ## 다양한 페어링 방식 - **Generator–Synthesizer 방식** - 한 사람이 많은 아이디어를 생성하고, 다른 사람이 이를 UX 흐름이나 구조로 정리한다. - **Lead–Support 방식** - 숙련된 디자이너가 주도하고 다른 디자이너가 지원하며, 주니어 디자이너의 성장을 돕는다. - **스크린 공유 방식** - 페어 프로그래밍처럼 한 화면을 보며 실시간으로 작업하고 의견을 교환한다. ## 드라이버와 내비게이터 역할 - **드라이버** - Figma 파일, 키보드, 마우스를 조작하며 실제 디자인을 만든다. - 버튼 위치나 보조 문구 추가 같은 판단의 근거를 소리 내어 설명한다. - **내비게이터** - 직접 조작하지 않고 작업을 관찰하며 질문을 던진다. - 기존 제품 패턴, 사용자 혼란, 접근성, 엣지 케이스 등을 즉시 검토한다. - 결과물을 비판하기보다 향후 디자인 리뷰나 출시 후 발견될 문제를 미리 제기한다. - 일정 시간이 지나면 두 사람이 역할을 교대해 서로 다른 관점에서 작업한다. ## 효과적인 진행 방법 - 해결할 문제와 목표를 시작 전에 합의한다. - 짧은 스케치나 레퍼런스 탐색으로 문제 인식을 맞춘다. - 페어링 시간을 10분, 하루, 일주일 등 상황에 맞게 정한다. - 대화와 사고가 많아 피로할 수 있으므로 중간에 휴식한다. - 즉시 거절하기보다 아이디어를 발전시키는 즉흥극의 원칙을 따른다. - 누군가 지켜보는 상황이 어색할 수 있으므로 실수를 자연스럽게 받아들이는 분위기를 만든다. - 종료 후 짧은 회고를 진행해 잘된 점과 개선할 점을 확인한다. ## 상사를 설득할 수 있는 투자 가치 - 작업 중 즉각적인 피드백을 받아 나중에 별도 리뷰할 필요가 줄어든다. - Slack이나 이메일 같은 방해 요소가 줄어든다. - 지식과 맥락이 실시간으로 공유되어 팀 전체의 역량이 빠르게 확산된다. - 문서 작성과 별도 컨텍스트 공유 회의가 감소한다. - 두 사람이 함께 아이디어를 생성하므로 더 많은 가능성을 탐색할 수 있다. - 오류, 버그, 엣지 케이스를 조기에 발견한다. - 디자인 파일의 구조와 정리가 더 일관된다. - 의사결정에 대한 자신감과 팀 사기가 높아진다. 처음부터 장기간 도입하기보다 명확한 문제를 정해 짧은 세션으로 시험해 보는 것이 좋다. 작업 속도뿐 아니라 재작업, 회의, 문서화, 출시 후 수정 비용까지 함께 비교하면 디자인 페어링의 효과를 더 설득력 있게 평가할 수 있다.

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

sketchFigma사용자 경험design-critique+2

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

딜리버루, 피그마

Deliveroo는 빠른 성장으로 디자인 조직이 커지면서 도구와 파일이 분산되고, 디자이너·콘텐츠·엔지니어 간 협업이 느려지는 문제를 겪었다. Figma의 실시간 공동 편집과 한 문서 내 협업을 도입한 뒤, 팀은 디자인 과정과 의사결정을 투명하게 공유하고 피드백을 더 빠르게 주고받을 수 있게 됐다. 결과적으로 Figma는 Deliveroo의 디자인 문화를 개방적이고 협력적인 방식으로 전환하는 기반이 되었다. ## 빠른 성장으로 생긴 디자인 사일로 - Deliveroo는 2013년 설립 이후 13개 시장, 500개 이상의 도시와 지역으로 확장했다. - 소비자, 배달원, 레스토랑을 위한 제품을 만들기 위해 콘텐츠·리서치·디자인 분야에서 40명 이상의 인력이 협업했다. - 조직이 커지면서 제품 그룹별 사일로가 생겼고, Sketch, Dropbox, Zeplin, Abstract 등 여러 도구가 분산 사용됐다. - 서로 다른 앱 버전의 파일을 동기화하기 어려워 이메일로 파일을 주고받는 일이 잦았다. - 콘텐츠 디자이너와 제품 디자이너가 같은 파일을 동시에 다루지 못해, 한 사람이 오전에 파일을 사용하고 다른 사람이 오후에 이어받는 방식으로 작업했다. - 스크린샷, Slack 메시지, 이메일 등을 통해 변경 사항을 재확인해야 했고 불필요한 커뮤니케이션이 반복됐다. ## 하나의 파일에서 시작된 협업 - Deliveroo 팀은 Figma의 실시간 공동 편집 기능을 통해 여러 사람이 하나의 문서에서 작업할 수 있다는 점에 주목했다. - 초기에는 도구 변경에 대한 우려가 있었지만, 파일을 따로 관리하고 동기화해야 하는 부담이 줄어들면서 빠르게 도입에 동의했다. - 콘텐츠 디자이너와 제품 디자이너가 같은 파일에서 작업하면서 디자인과 콘텐츠 아이디어를 동시에 발전시킬 수 있었다. - 파일 버전을 관리하거나 별도 문서로 콘텐츠를 공유하는 작업이 줄어들었다. - 파일 관리에 들던 시간을 줄이고 실제 제품 아이디어와 문제 해결에 더 집중할 수 있게 됐다. ## 디자인 과정을 공개하는 문화 - Figma를 통해 디자인 결과물뿐 아니라 작업 과정과 사고방식까지 팀 전체가 확인할 수 있게 됐다. - 제품 디자이너, 리서처, 엔지니어, 프로덕트 매니저가 같은 문서에서 콘텐츠 디자인 과정을 볼 수 있었다. - 디자인에 익숙하지 않은 조직 구성원도 작업물을 쉽게 확인하고 의견을 제시할 수 있었다. - 엔지니어가 디자인의 의도를 이해한 상태에서 예외 상황(edge case)을 제안하고 함께 정의할 수 있게 됐다. - 디자인이 특정 담당자만 이해하는 비공개 작업이 아니라, 여러 직군이 참여하는 공개적인 과정으로 바뀌었다. ## 온보딩과 지식 공유의 간소화 - 새로 합류한 디자이너는 여러 도구를 따로 익히는 대신 Figma를 중심으로 팀의 작업 방식을 빠르게 파악할 수 있었다. - 기존 파일과 프로젝트를 직접 둘러보며 팀의 디자인 기준과 진행 방식을 스스로 학습할 수 있었다. - 콘텐츠 디자이너처럼 다양한 이해관계자와 협업해야 하는 구성원에게 특히 도구 학습 부담이 줄었다. - 업무 결과물뿐 아니라 과거의 논의와 디자인 맥락도 한곳에서 확인할 수 있어 팀 지식 공유가 쉬워졌다. ## 한 문서에 모인 피드백 - 댓글과 의견을 디자인 파일 안에 직접 남길 수 있어 프로젝트 관련 논의가 여러 채널로 흩어지지 않았다. - 담당자가 별도로 작업 내용을 설명하지 않아도 문서와 댓글만으로 프로젝트의 진행 상황을 파악할 수 있었다. - 파일을 보면서 질문하고 답변할 수 있어 피드백 전달과 응답 속도가 빨라졌다. - 의견과 결정 사항이 디자인과 함께 남기 때문에, 팀원들이 작업의 맥락을 더 쉽게 이해할 수 있었다. ## 실용적인 결론 빠르게 성장하는 디자인 조직이라면 도구의 개수보다 모든 구성원이 같은 작업 공간과 최신 파일을 공유하는지가 중요하다. 실시간 공동 편집, 문서 내 댓글, 직군 간 접근 권한을 활용하면 파일 동기화와 반복적인 확인 작업을 줄이고 디자인·콘텐츠·개발 간 협업을 더 투명하고 효율적으로 만들 수 있다.

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

sketchFigma디자인 시스템프로덕트 디자인+4

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

Zoom, Figma로 디자인 워크

Zoom은 Sketch, InVision·Framer, Zeplin으로 분리된 디자인 workflow를 Figma로 통합해 반복 작업과 협업 마찰을 줄였다. 실시간 공동 편집, 디자인 문서 내 댓글, 공유 라이브러리를 통해 디자이너뿐 아니라 엔지니어·PM·데이터 과학자까지 같은 맥락에서 참여할 수 있게 되었고, 피드백의 양과 품질도 크게 향상됐다. Figma는 Zoom의 단일 기준 문서이자 디자인 시스템 구축의 기반으로 자리 잡았다. ## 분산된 디자인 도구가 만든 비효율 - Zoom의 디자인팀은 여러 국가와 시간대에 걸쳐 원격으로 협업했다. - 디자이너 1명이 엔지니어 약 10명을 지원하는 구조였기 때문에, 디자인 의도를 일일이 설명하기 어려웠다. - Sketch에서 디자인하고, InVision이나 Framer에서 프로토타입을 만들고, Zeplin으로 개발자에게 전달하는 방식이었다. - 디자인 수정 때마다 여러 도구 간 파일을 동기화해야 했다. - 한 프로젝트에서 수정본을 10~20회씩 각 도구에 반영하고, 버전과 이해관계자별 리뷰를 따로 관리해야 했다. - 이 과정은 창의적인 작업보다 파일 관리와 수동 반복 작업에 시간을 쓰게 만들었다. ## Figma를 통해 발견한 전환점 - 디자이너 Steven Crosby는 Figma의 빠른 렌더링과 높은 프레임 속도에 주목했다. - 여러 사람이 하나의 디자인 파일에서 동시에 작업할 수 있는 실시간 협업 기능이 핵심적인 장점으로 평가됐다. - 댓글 기능을 통해 디자인 문서 안에서 직접 피드백을 남길 수 있었다. - 정적인 스크린샷을 공유하는 방식과 달리, 전체 화면 흐름과 해당 요소가 사용되는 맥락을 유지한 채 의견을 주고받을 수 있었다. - 별도의 다운로드, 파일 동기화, 정적 파일 공유 없이 링크만으로 협업할 수 있었다. ## 디자이너와 다른 직군의 협업 강화 - Figma는 디자이너뿐 아니라 프로젝트 매니저, 제품 매니저, 엔지니어까지 동일한 문서에 참여하게 했다. - 디자인 의사소통이 구두 설명이나 이미지 첨부 중심에서 문서 내 직접 피드백 중심으로 바뀌었다. - Zoom은 이전보다 피드백의 양과 품질이 크게 향상됐다고 평가했다. - 실시간으로 같은 화면을 보며 작업하므로, 원격 근무자와 다른 시간대의 팀원도 협업하기 쉬워졌다. ## 단일 기준이 된 디자인 시스템 - Figma를 팀의 단일 기준 문서로 사용하면서 디자인 시스템의 기반을 마련했다. - Team Libraries를 통해 여러 프로젝트에서 공통 컴포넌트를 공유할 수 있었다. - 아이콘 세트와 다양한 UI 컴포넌트를 마스터 파일에 모아 지속적으로 업데이트했다. - 라이브 업데이트를 통해 모든 디자이너가 최신 컴포넌트를 사용할 수 있었다. - Constraints 기능을 활용해 화면 크기가 바뀌어도 요소가 특정 방향에 고정되도록 만들고, 일관된 디자인 패턴을 구축했다. - 컴포넌트 중심의 작업 방식은 디자인 재사용성과 유지보수성을 높였다. ## 비디자이너도 참여한 브레인스토밍 - Zoom은 데이터 과학팀과 투자회사 소속 디자인 파트너를 제품 메시지 브레인스토밍에 초대했다. - 참가자들은 Figma를 처음 사용했지만 별도의 긴 교육 없이 바로 디자인 파일에 참여했다. - 각자 화면의 영역을 맡아 문구와 요소를 직접 배치하고, 다른 사람의 아이디어를 참고하거나 변형했다. - 실시간으로 서로의 커서를 확인하며 아이디어를 발전시킬 수 있었다. - Figma의 낮은 학습 곡선 덕분에 디자인 작업이 특정 직군만의 활동이 아니라 공동 창작 과정으로 확장됐다. ## 실용적인 결론 여러 도구와 파일 형식으로 나뉜 디자인 프로세스는 반복적인 동기화와 맥락 손실을 만든다. 팀 규모가 작거나 원격 협업이 많다면, 디자인·프로토타이핑·피드백·개발 전달을 하나의 공유 문서와 컴포넌트 라이브러리로 통합하는 방식이 효율적이다. Figma의 강점은 단순한 디자인 도구가 아니라 모든 직군이 같은 맥락에서 협업하는 공통 작업 공간을 제공한다는 데 있다.

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

sketchFigma디자인 시스템프로토타이핑+3

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

API 챌린지 과정에서의

Figma는 Sketch 내보내기 API 챌린지가 디자이너에게 무보수 작업을 요구하는 ‘스펙 워크’로 받아들여질 수 있음을 인정하고 사과했다. 개방적인 디자인 생태계를 만들고자 했던 취지는 타당했지만, 창작 노동의 가치를 충분히 고려하지 못한 것이 문제였다. Figma는 챌린지를 중단하고 대안을 검토했으며, 2018년 11월에는 해당 챌린지를 어떤 형태로도 진행하지 않기로 결정했다. ## API 챌린지의 목적 - Figma는 **Figma 파일을 Sketch 형식으로 내보내는 기능**을 만들기 위한 API 챌린지를 시작했다. - 목표는 다음과 같았다. - Figma를 중심으로 한 개방적인 디자인 도구 생태계 조성 - Figma 데이터를 외부로 가져갈 수 있는 다양한 방법 지원 - 관련 기능이나 도구 개발에 필요한 자금 지원 - 회사는 기술 생태계를 확장하려는 의도에서 이 프로그램을 기획했다. ## ‘스펙 워크’로 비친 문제 - 디자이너 커뮤니티는 챌린지가 실제 결과물을 요구하면서도 참가자가 보상을 받지 못할 수 있다는 점을 지적했다. - 이러한 구조는 기업이 업무에 활용할 수 있는 창작물을 여러 참가자에게 무상으로 제작하게 하는 **스펙 워크(spec work)**로 해석될 수 있었다. - Figma는 창작자가 정당한 대가를 받아야 한다고 믿어왔지만, 개방형 생태계에 대한 열정 때문에 이 원칙을 이번 기획에 충분히 적용하지 못했다고 인정했다. - 특히 숙련된 창작 노동자가 착취되어 온 업계의 역사와 커뮤니티의 우려를 간과한 점이 핵심적인 실수였다. ## Figma의 대응과 사과 - Figma는 커뮤니티의 비판을 접한 뒤 해당 챌린지를 즉시 중단했다. - 기존 방식으로는 진행하지 않고, 참가자에게 무보수 작업을 요구하지 않는 새로운 구조를 검토하겠다고 밝혔다. - 당시에는 1~2주 안에 챌린지를 재설계해 다시 시작할 가능성을 언급했다. - 커뮤니티의 건설적인 피드백에 감사를 표하고, 디자인 생태계를 더 개방적이고 공정하게 만들겠다고 약속했다. ## 최종 결정 - 2018년 11월 19일 업데이트에서 Figma는 커뮤니티의 우려를 고려해 **이 챌린지를 어떤 형태로도 당분간 진행하지 않기로 결정**했다. - 따라서 단순히 운영 방식을 수정하는 수준을 넘어, 해당 프로젝트 자체를 보류하는 결론에 도달했다. ## 실용적인 시사점 - 오픈 생태계나 커뮤니티 프로그램을 설계할 때도 참여자의 노동이 기업 가치로 전환되는지 먼저 검토해야 한다. - 결과물을 요구하는 공모전이나 API 챌린지는 보상, 사용권, 선정 기준을 명확히 제시해야 한다. - 좋은 기술적 목표라도 창작자의 권리와 보상 구조를 고려하지 않으면 커뮤니티의 신뢰를 잃을 수 있다.

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

sketchFigmaAPIdesign-tools+2

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

소개합니다: 피그

Figma는 디자인 생태계의 개방성을 강화하기 위해 Figma 파일을 Sketch로 변환하는 API 챌린지를 발표했다. 총 1만 5천 달러의 상금과 오픈소스 제출을 통해 개발자와 디자이너의 참여를 유도하려는 목적이었다. 다만 커뮤니티의 우려가 제기되면서 챌린지는 일시 중단되었고, 2018년 11월에는 당분간 진행하지 않기로 결정되었다. ## 개방형 디자인 플랫폼을 위한 API 챌린지 - Figma는 경쟁 제품인 Sketch로 파일을 내보내는 도구를 만들도록 참가자들을 초대했다. - 이는 특정 도구에 사용자를 묶어두기보다, 다양한 디자인 도구와 작업 방식을 연결하려는 Figma의 개방형 플랫폼 전략을 보여준다. - Figma는 이미 Sketch 파일 가져오기를 지원하고 있었으며, Sketch 내보내기는 그 생태계를 확장하는 자연스러운 다음 단계로 소개됐다. - 기존 API를 활용해 커뮤니티가 만든 스타일 가이드 생성기, Alexa 연동 등 다양한 프로젝트에서 영감을 받아 챌린지를 기획했다. ## 구현 대상: Figma에서 Sketch로의 변환 - 참가자는 Figma 객체로 구성된 두 개의 파일을 Sketch로 변환하는 exporter를 개발해야 했다. - 첫 번째 파일에는 기본 수준의 객체가 포함되어 비교적 명확한 변환 결과를 기대할 수 있었다. - 두 번째 파일에는 다음과 같은 복잡한 요소가 포함됐다. - 텍스트 및 타입 - 컴포넌트 - 스타일 - 프로토타입 - Figma와 Sketch의 기능이 항상 1:1로 대응하지 않기 때문에, 복잡한 파일은 단순한 변환 정확도뿐 아니라 창의적인 매핑 방식도 평가 대상이었다. ## 평가 기준과 제출 조건 - 심사는 객관적 기준과 주관적 기준을 함께 적용했다. - 평가 요소에는 다음이 포함됐다. - 두 파일의 디자인 요소를 얼마나 정확하게 전달하는지 - exporter의 사용 편의성 - Figma와 Sketch 간 차이를 해결하는 접근 방식의 창의성 - 코드 품질과 GitHub 문서화 수준 - 전체 점수의 5%는 코드 품질과 GitHub README 문서에 배정됐다. - 제출물은 GitHub 저장소 링크와 함께 제출해야 했으며, README와 MIT 라이선스를 포함해야 했다. ## 상금과 참가 방식 - 1등 상금은 1만 달러, 2등 상금은 5천 달러로 총상금은 1만 5천 달러였다. - 최대 3명까지 팀을 구성할 수 있었다. - 대부분의 국가에서 만 21세 이상이면 참가할 수 있었지만, 일부 국가에는 예외가 적용됐다. - 챌린지 기간은 2018년 10월 2일부터 11월 16일 오후 11시 59분(PST)까지로 예정됐다. ## 심사위원 구성 - 심사위원은 디자인 경험과 커뮤니티용 플러그인·도구 제작 경험을 함께 갖춘 인물들로 구성됐다. - GitHub의 디자인 시스템 엔지니어 Emily Plumme는 디자인과 개발을 연결하는 API 및 컴포넌트 시스템 경험을 보유했다. - Google의 인터랙션 디자이너 Raph D’Amico는 행동과학과 시스템 설계 관점에서 사용자 경험을 평가할 수 있는 배경을 갖췄다. - 접근성 도구 Stark와 Lyra를 만든 Cat Noone은 디자인 접근성과 윤리적 제품 설계에 전문성이 있었다. - Sketch Runner를 만든 디자이너 Roy van Rooijen은 디자인 도구와 플러그인 생태계에 대한 경험을 제공했다. ## 커뮤니티 반응과 챌린지 중단 - 발표 이후 커뮤니티에서 챌린지의 운영 방식과 관련한 우려가 제기됐다. - Figma는 이러한 의견을 반영해 챌린지를 일시 중단하고, 몇 주 뒤 재개하는 방안을 검토한다고 밝혔다. - 이후 2018년 11월 19일 업데이트에서 어떤 형태의 챌린지도 당분간 진행하지 않기로 결정했다. - 따라서 글에서 제시된 상금, 일정, 제출 조건은 최초 계획이며 실제로는 예정대로 진행되지 않았다. Figma의 시도는 경쟁 제품과의 호환성을 지원하는 것이 장기적으로 플랫폼의 신뢰와 확장성을 높일 수 있음을 보여준다. 다만 외부 커뮤니티를 대상으로 한 API 경연은 상품 범위, 평가 기준, 참가자 권리와 운영 방식에 대한 충분한 사전 검토와 소통이 중요하다는 교훈도 남겼다.

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

sketch디자인 시스템오픈 소스React+4

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

월풀을 담당하는 에이전

Aisle Rocket Studios(ARS)는 여러 사무실과 원격 인력으로 구성된 환경에서 분산된 디자인 파일과 협업 단절 문제를 Figma로 해결했다. Whirlpool 계정 팀은 Figma를 단일 작업 공간이자 협업의 기준점으로 삼아 기획·카피·디자인·개발·고객 검토를 브라우저 안에서 진행했고, 결과적으로 더 빠르고 창의적인 프로세스를 구축했다. 이 방식은 이후 ARS 전체의 표준 협업 방식으로 확산됐다. ## 분산된 팀의 파일 관리 문제 - ARS는 Whirlpool, Maytag, Sears 등 25개 이상의 브랜드를 담당하며 4개 사무실과 원격 인력으로 운영됐다. - Whirlpool 프로젝트에 긴급 투입된 크리에이티브 디렉터 Matt Carson은 Sketch, Photoshop 등 서로 다른 형식의 파일을 전달받았다. - 파일이 여러 도구와 장소에 흩어져 있어 중앙화된 작업 방식이나 일관된 프로세스가 없었다. - ARS는 디자이너와 개발자를 분리된 역할이 아니라, 서로 다른 기술을 가진 하나의 크리에이티브 팀으로 보려 했다. ## Figma를 단일 협업 공간으로 도입 - Whirlpool 계정 팀은 Figma를 새로운 ‘단일 정보 출처(source of truth)’로 정하고 기존 작업 도구와 워크플로를 빠르게 통합했다. - 실시간 멀티플레이어 기능을 이용해 서로 다른 시간대와 지역의 구성원이 같은 파일에서 동시에 작업했다. - 팀 내부 회의, 아이디어 구상, 피드백 수집, 프로토타입 공유까지 하나의 파일 안에서 진행했다. - 고객도 별도 로그인이나 개발 작업 없이 작동이 시뮬레이션된 디지털 콘셉트를 확인하고 공유할 수 있었다. - 에이전시와 고객이 실시간으로 수정 사항을 확인하면서 검토와 승인 과정이 짧아졌다. ## 협업이 창의성을 높이는 방식 - 작가, 디자이너, 개발자가 서로 다른 프로그램과 공간에서 작업하지 않고 동일한 환경에서 의견을 주고받게 됐다. - 아이디어를 함께 브레인스토밍하고 즉시 수정할 수 있어 반복 작업의 속도와 창의성이 향상됐다. - Figma는 단순한 디자인 제작 도구가 아니라 기획부터 검토까지 연결하는 협업 플랫폼으로 활용됐다. - ARS는 크리에이티브 프로세스의 80%를 브라우저에서 수행한다는 원칙을 실현할 수 있었다. ## 카피라이터와 개발자를 포함한 포용적 디자인 - 카피라이터는 완성된 디자인에 문구를 나중에 삽입하는 대신, 초기 디자인 단계부터 직접 카피를 수정하고 논의했다. - 카피가 디자인의 부수적인 요소가 아니라 독립적인 디자인 요소로 다뤄졌다. - 개발자는 정적인 디자인 파일을 전달받은 뒤 뒤늦게 문제를 발견하는 대신, 초기 단계부터 파일을 열람할 수 있었다. - 개발 가능성을 초기에 검토할 수 있어 디자인과 코드 사이의 반복적인 수정과 커뮤니케이션이 줄었다. - 역할별 참여 장벽이 낮아지면서 디자인 프로세스가 더 민주적이고 포괄적으로 바뀌었다. ## 소규모 팀에서 전사 표준으로 확산 - Whirlpool 팀은 도구를 통합하고 복잡한 업무 흐름과 파일을 중앙화하면서 더 빠르고 효율적으로 일했다. - 고객 측에서도 협업으로 시간과 비용을 절감하면서 창의성을 유지할 수 있었다. - 성과를 본 다른 ARS 구성원들이 이 방식을 도입하기 시작했고, Figma는 조직 전체의 표준으로 자리 잡았다. - ARS는 개방적인 협업 디자인을 기본 방식으로 삼고 전 디자인팀의 Figma 전환을 추진했다. ## 디자인 시스템으로의 확장 - Whirlpool 팀은 디지털 브랜드 전반의 일관성을 높이기 위해 디자인 시스템 구축을 다음 과제로 삼았다. - 원자적 디자인(Atomic Design) 원칙에 따라 기본 구성 요소를 Figma에서 규격화할 계획이다. - 완성된 요소는 팀 라이브러리에 저장해 브랜드 디자인의 단일 기준으로 활용하려 했다. - 이를 통해 프로젝트마다 디자인 요소를 새로 만들지 않고 재사용성과 일관성을 높일 수 있다. 분산된 팀이라면 파일 형식과 도구를 먼저 통합하고, 기획자·카피라이터·디자이너·개발자가 초기 단계부터 같은 작업 공간에서 협업하도록 구성하는 것이 효과적이다. 이후 반복적으로 사용하는 UI 요소를 디자인 시스템과 공유 라이브러리로 관리하면 협업 속도와 결과물의 일관성을 함께 높일 수 있다.

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

sketchFigma디자인 시스템프로토타이핑+3

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

피그마 기능 하이라이트

Figma의 Sketch Import 기능은 Sketch 사용자가 기존 작업물을 잃지 않고 Figma로 전환하도록 돕는 기능이다. Sketch 파일의 페이지, 크기 조정 제약, 벡터, 심볼 등을 높은 정확도로 보존하며, 여러 운영체제와 협업 환경을 연결한다. 글은 이 기능이 단순한 마이그레이션 도구를 넘어 Sketch와 Figma를 오가며 협업할 수 있게 하는 핵심 기능이라고 강조한다. ## Sketch Import이 필요한 이유 - **Figma로의 초기 전환 지원** - Sketch에서 Figma로 옮기는 사용자가 기존 디자인을 처음부터 다시 만들 필요가 없다. - 과거 Photoshop에서 Sketch로 전환할 때와 같은 큰 작업 부담을 줄여준다. - 기존 파일을 안정적으로 가져올 수 있어 새로운 도구를 시험하기 쉽다. - **운영체제가 다른 팀의 협업** - Sketch는 Mac 전용이지만 Figma는 다양한 운영체제에서 사용할 수 있다. - Windows나 Linux를 사용하는 개발자도 Sketch 파일을 Figma로 가져와 디자인 사양을 확인할 수 있다. - 서로 다른 디자인 도구를 사용하는 팀원들이 동일한 작업물을 기준으로 협업할 수 있다. - **Sketch와 Figma를 병행하는 작업 방식** - 디자이너가 Sketch에서 작업한 뒤 Figma로 파일을 옮겨 디자인 리뷰나 원격 협업을 진행할 수 있다. - Figma의 댓글 기능을 활용해 팀원 및 외부 이해관계자와 의견을 주고받을 수 있다. - 한 가지 도구만 강제하지 않고 작업 목적에 따라 도구를 선택할 수 있다. ## 높은 변환 정확도 - Sketch Import은 Sketch 파일의 구조와 시각적 요소를 최대한 보존하도록 설계되었다. - 다음과 같은 요소를 가져올 수 있다. - 페이지 구조 - 크기 조정 제약 조건 - 벡터 데이터 - Sketch의 심볼 - Sketch의 심볼은 Figma에서 **컴포넌트**로 변환된다. - 따라서 디자인 시스템을 구축하거나 유지하는 조직도 기존 컴포넌트 구조를 활용할 수 있다. - 글에서는 실제 사용자가 Angle 파일을 가져온 사례를 통해 벡터와 컴포넌트가 거의 완벽하게 유지된다고 소개한다. - 변환 과정에서 문제가 발생하면 Figma 앱 내부의 지원 위젯을 통해 문의할 수 있다. ## Sketch 파일을 가져오는 방법 - Figma 파일 공간에 Sketch 파일을 **드래그 앤 드롭**한다. - Figma 툴바의 가져오기 기능을 사용한다. - 단축키를 사용한다. - macOS: `Command + Shift + K` - Windows: `Control + Shift + K` - 가져오기가 완료되면 가져온 이미지와 디자인 요소가 포함된 새로운 Figma 파일이 자동으로 생성된다. ## 커뮤니티 중심의 기능 소개 - Figma는 새 기능 출시 소식이나 릴리스 노트가 쉽게 묻힐 수 있다는 점을 언급하며, 이미 출시된 유용한 기능을 다시 소개한다. - Sketch Import은 2015년 6월에 출시됐지만 이후에도 사용자들이 계속 새롭게 발견하는 기능으로 소개된다. - 다음에 어떤 기능을 다룰지는 Figma 커뮤니티의 의견을 바탕으로 결정하려 했다. Sketch Import은 기존 Sketch 자산을 Figma로 옮겨야 하는 개인과 팀에게 유용한 마이그레이션 수단이다. 특히 디자인 시스템, 운영체제가 다른 협업 환경, 원격 리뷰가 필요한 프로젝트라면 파일을 가져온 뒤 페이지와 컴포넌트가 제대로 변환되는지 확인하고 적극적으로 활용하는 것이 좋다.

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

sketchFigma디자인 시스템사용자 경험+2

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

런던 예술 대학교의 디자인 시스템

UAL은 6개 단과대학의 독립적인 정체성 때문에 디지털 경험이 일관되지 않았지만, 웹사이트 개편 과정에서 협업 도구를 Figma로 전환하며 자연스럽게 디자인 시스템을 구축했다. 실시간 공동 편집과 중앙화된 라이브러리는 디자인·개발·외부 에이전시 간의 소통을 개선했고, 결과적으로 웹사이트를 더 빠르고 일관되게 제작할 수 있게 했다. 디자인 시스템은 단순한 컴포넌트 모음이 아니라 여러 채널과 대학 조직을 연결하는 공통 언어로 발전했다. ## 조직 구조가 만든 디자인 일관성 문제 - UAL은 2004년 공식 연합체가 되었으며, 현재 6개 대학으로 구성되어 있다. - 각 대학은 오랜 역사와 고유한 브랜드 정체성을 가지고 있어, 웹사이트마다 서로 다른 스타일을 적용하려는 경향이 있었다. - 그 결과 UAL의 디지털 경험은 채널과 대학별로 분리되고 일관성이 부족했다. - 2017년부터 UX 팀은 디지털 트랜스포메이션 프로그램의 일환으로 사용자 중심의 핵심 디지털 경험을 재설계했다. ## Sketch 협업의 한계와 Figma 전환 - 기존 Sketch 기반 작업에서는 여러 사람이 같은 파일에서 원활하게 협업하기 어려웠다. - 14개 캠퍼스에 흩어진 내부 구성원과 외부 에이전시가 함께 일하면서 다음 문제가 발생했다. - 파일 버전 관리 혼란 - 파일 동기화에 소요되는 시간 - 반복적인 커뮤니케이션과 확인 절차 - 디자인 팀과 개발 팀 사이의 단절 - Figma는 브라우저만 있으면 어디서든 접근할 수 있고, 실시간 공동 편집을 지원했다. - Sketch 파일을 간단히 가져올 수 있어 웹사이트 프로젝트 중간에도 도구를 전환할 수 있었다. - 모든 이해관계자가 하나의 중앙 파일을 기준으로 작업하면서 투명성이 높아지고, 디자인과 개발 간 협업이 개선되었다. ## 웹사이트 개편에서 디자인 시스템으로 확장 - 팀은 웹사이트를 처음부터 구축해야 했기 때문에, 반복 작업을 줄이기 위해 디자인 시스템을 우선적으로 만들기로 했다. - Figma의 컴포넌트와 협업 기능 덕분에 디자인 시스템 구축이 별도의 대형 프로젝트가 아니라 웹사이트 제작 과정에서 자연스럽게 진행되었다. - 디자인 시스템은 웹사이트용 컴포넌트뿐 아니라 여러 채널에 동일한 스타일과 기능을 적용하기 위한 기반으로 정의되었다. - 목표는 대학별로 달랐던 컴포넌트를 조화시키고 제작 프로세스를 표준화하는 것이었다. ## 워크숍을 통한 요구사항과 불일치 파악 - UX 팀은 학생과 비즈니스 파트너를 대상으로 워크숍을 진행했다. - 워크숍의 목적은 다음과 같았다. - 디자인 시스템에 필요한 핵심 기능 파악 - 사용 중인 모든 UI 컴포넌트 목록화 - 대학과 채널별 디자인 차이 및 불일치 발견 - 기존 스타일 가이드를 실제 디지털 자산과 재사용 가능한 컴포넌트로 변환했다. ## 유연한 브랜드 시스템 구축 - UAL의 복잡한 브랜드 구조 때문에 디자인 시스템은 하나의 고정된 스타일만 강제할 수 없었다. - 서로 다른 색상, 타이포그래피, 브랜드 개성을 수용할 수 있도록 유연하게 설계했다. - Figma 팀 라이브러리를 활용해 모든 구성원이 기기나 위치에 관계없이 최신 브랜드 가이드와 자산을 사용할 수 있게 했다. - Figma Styles를 사용하면 색상, 텍스트, 효과 스타일을 분리해 관리할 수 있어 브랜드 변형을 더 유연하게 적용할 수 있었다. - 결과적으로 디자인 시스템은 정적인 문서가 아니라 지속적으로 업데이트되는 ‘살아 있는’ 브랜드 가이드가 되었다. ## 컴포넌트 기반의 빠른 개발 - 디자인 시스템의 컴포넌트를 조합해 기본 페이지를 템플릿으로 만들었다. - 개발 팀은 이 템플릿을 활용해 새로운 페이지를 빠르게 생성할 수 있었다. - Figma에서 디자인과 컴포넌트 구조를 함께 확인할 수 있어, 개발자는 디자인이 코드로 어떻게 구현될지 즉시 파악할 수 있었다. - 디자이너와 개발자가 동일한 시스템을 기준으로 작업하면서 구현 속도와 협업 효율이 높아졌다. ## 실용적인 시사점 - 디자인 시스템은 처음부터 별도의 거대한 프로젝트로 계획하지 않아도, 반복되는 문제를 해결하는 과정에서 자연스럽게 시작할 수 있다. - 여러 조직이나 브랜드가 공존하는 환경에서는 일관성만 강제하기보다 공통 기반과 개별 표현의 유연성을 함께 설계해야 한다. - 최신 컴포넌트와 스타일을 중앙 라이브러리로 관리하고 디자인·개발·이해관계자가 함께 사용하면, 제작 속도와 결과물의 일관성을 동시에 높일 수 있다.

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

sketchFigma디자인 시스템사용자 경험+2

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

#FigmaTip 라운드업

Figma의 10번째 팁 모음은 디자이너 Charli Marie의 리뷰에서 소개된, 작업 속도와 파일 정리 효율을 높이는 기능들을 정리한 글이다. 핵심은 레이어 단축키, 빈 그룹 자동 삭제, 속성별 복사, 이미지 fill 설정, 벡터 네트워크 등을 활용하면 Sketch나 Illustrator를 열지 않고도 더 빠르고 깔끔하게 작업할 수 있다는 것이다. ## 레이어 순서 조정 단축키 - `Command + [` 및 `Command + ]`로 선택한 레이어를 앞뒤로 이동할 수 있다. - 레이어 패널에서 직접 드래그하지 않아도 되므로 디자인 중 요소의 순서를 빠르게 바꿀 수 있다. - 메뉴에 단축키가 표시되어 있어 잊어버렸을 때 확인하기 쉽다. - Photoshop과 유사한 방식이라 기존 사용자도 쉽게 익힐 수 있다. ## 빈 그룹 자동 삭제 - 그룹 안의 모든 요소를 삭제하면 해당 그룹도 자동으로 사라진다. - 내용이 없는 그룹을 수동으로 찾아 삭제할 필요가 없다. - 요소를 다른 곳으로 옮긴 뒤 빈 그룹이 남아 파일이 지저분해지는 문제를 줄여준다. - 결과적으로 레이어 패널을 더 깔끔하게 유지할 수 있다. ## 개별 속성만 복사하기 - 한 도형의 속성을 다른 도형에 복사할 때 전체 속성 또는 일부 속성만 선택할 수 있다. - 복사 가능한 예시는 다음과 같다. - Fill - Font - Stroke - 기존 디자인에서 잘 설정된 특정 속성만 다른 요소에 적용할 수 있다. - 전체 스타일을 덮어쓰지 않고 필요한 부분만 재사용할 수 있어 반복 작업이 빨라진다. ## 마스크 대신 이미지 Fill 활용 - Figma에 이미지를 삽입하면 이미지가 독립적인 이미지 객체가 아니라, 이미지가 Fill로 적용된 사각형 형태로 생성된다. - Fill 설정에서 이미지를 조정할 수 있다. - Crop - Tile - 이미지 표시 방식과 위치 - 이미지 크롭을 위해 여러 마스크를 만들 필요가 줄어든다. - 처음에는 기존 그래픽 도구와 달라 혼란스러울 수 있지만, 이미지 배치와 편집을 단순화하는 방식이다. ## 벡터 네트워크로 복잡한 도형 만들기 - Figma의 벡터 네트워크에서는 하나의 점이 두 개 이상의 선과 연결될 수 있다. - 일반적인 벡터 편집 도구의 경로 구조보다 자유로운 형태의 도형을 만들 수 있다. - 복잡한 벡터를 제작할 때 Illustrator로 파일을 옮겨야 하는 상황을 줄여준다. - 기존 벡터 편집 방식과 달라 적응이 필요하지만, 익숙해지면 Figma 안에서 대부분의 작업을 처리할 수 있다. ## 실용적인 활용 Figma 작업 속도를 높이려면 레이어 이동 단축키를 우선 익히고, 반복되는 스타일은 필요한 속성만 복사하는 것이 좋다. 이미지 작업에서는 마스크를 무조건 사용하는 대신 Fill 설정을 확인하고, 복잡한 아이콘이나 도형은 벡터 네트워크를 활용하면 파일 구조를 단순하게 유지하면서 효율적으로 제작할 수 있다.

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

sketchFigma사용자 경험vector-graphics+2

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

Kiwi.com이 Figma에서 프로젝트

Kiwi.com은 여러 도구를 조합한 Sketch 중심 workflow에서 발생하는 동기화 문제를 해결하기 위해 모바일 디자인 시스템을 Figma로 옮기기 시작했다. 소규모 디자인팀과 약 20명의 협업자가 함께 작업하는 환경에서는 디자인, 프로토타입, 개발 전달, 버전 관리가 하나의 협업 공간에서 연결되는 것이 중요하다고 판단했다. 이 글은 Figma 도입 배경과 디자인 라이브러리·컴포넌트·프로젝트 구조를 정리하는 방식을 소개한다. ## Kiwi.com의 디자인 환경과 과제 - 모바일 디자인팀은 디자이너 2명으로 구성되어 있지만, 약 20명이 다양한 방식으로 디자인에 참여한다. - 디자인 시안에 댓글을 남기는 사람 - 카피를 수정하는 사람 - 여러 플랫폼을 아우르는 기능을 설계하는 사람 - 기존 프런트엔드 디자인과 디자인 시스템인 **Orbit**는 Sketch를 기반으로 운영되고 있었다. - 그러나 Orbit의 모바일 버전은 시각적으로 차이가 커서, 별도의 모바일 디자인 시스템을 Figma에서 시험하게 되었다. ## Sketch 기반 도구 조합의 동기화 문제 - 기존 workflow에서는 목적별로 여러 도구를 사용했다. - **Sketch**: 디자인 제작 - **Zeplin**: 개발자 핸드오프 - **Abstract**: 버전 관리 - **Marvel**: 정적 프로토타입 제작 - **Dropbox Paper**: 디자인 이미지 공유 - 도구가 분리되어 있어 최신 상태가 서로 달라질 수 있었다. - 프로토타입이 최신 테스트 버전을 반영하지 못함 - 작업자가 Abstract에 커밋하는 것을 잊음 - 승인된 최종 시안이 Zeplin에 업데이트되지 않음 - 문서에 첨부된 PNG가 몇 주 전 버전으로 남아 있음 - 각 도구는 독립적으로 작동하기 때문에, 팀이 수동으로 상태를 맞추지 않으면 디자인 산출물이 쉽게 불일치한다. ## Figma를 선택한 이유 - Figma 도입의 핵심 기대 효과는 디자인 파일, 협업, 프로토타입, 버전 이력을 한 환경에서 연결하는 것이었다. - 여러 도구 사이에서 최신 파일을 확인하고 전달하는 관리 비용을 줄일 수 있다. - 다수의 참여자가 디자인 과정에 관여하는 Kiwi.com의 환경에서는 중앙화된 협업 방식이 특히 유용하다. - 저자는 초기에는 브라우저 기반 도구인 Figma의 가치에 회의적이었지만, 실제 팀의 협업 문제를 경험하면서 Figma 도입의 필요성을 재평가하게 되었다. ## 글에서 다루는 디자인 시스템 운영 범위 - 글은 단순한 Figma 사용 후기가 아니라 다음 운영 주제를 함께 다룬다. - 모바일 디자인 시스템을 Figma로 구축한 이유 - Figma 업데이트 이후 달라진 작업 방식 - 디자인 라이브러리 컴포넌트의 설계 원칙 - 컴포넌트와 프로젝트 파일의 구조화 - 버전 이력 관리와 파일 정리 - 특히 여러 사람이 컴포넌트를 재사용하는 환경에서 일관성을 유지하고, 최신 디자인 자산을 쉽게 찾도록 구성하는 방법에 초점을 둔다. 여러 협업자가 디자인에 참여하고 도구별 최신 상태를 수동으로 맞추고 있다면, Figma처럼 디자인·프로토타입·협업을 한 공간에 통합하는 방식을 검토할 만하다. 다만 도구를 바꾸는 것만으로 문제가 해결되지는 않으므로, 컴포넌트 명명 규칙과 파일 구조, 버전 관리 원칙을 함께 정립하는 것이 중요하다.

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

sketchFigma디자인 시스템프로토타이핑+2

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

한 디자이너가 더 윤리

Cat Noone은 접근성을 제품 개발의 마지막 점검이 아니라 초기 설계 원칙으로 삼아야 한다고 주장한다. 그녀는 의료 정보 공유 앱 Iris Health, 색각 이상 접근성 도구 Stark, 자폐 아동용 의사소통 앱 Lyra를 통해 소외되기 쉬운 사용자도 제품의 기본 사용자로 고려해야 한다는 점을 보여준다. 접근성을 높이는 일은 디자인을 제한하는 것이 아니라 더 많은 사람에게 제품을 열어 주는 방법이다. ## 접근성을 처음부터 고려해야 하는 이유 - 장애가 있는 사용자 중 상당수가 온라인 서비스를 이용하므로, 접근성을 무시하면 잠재 사용자층의 약 10%를 놓칠 수 있다. - 접근성을 “UI를 나쁘게 만드는 제약”으로 보는 인식을 비판한다. - 제품 기획 단계부터 신체적·인지적·감각적 특성이 다른 사용자들을 조사하고, 각 집단에 맞게 UI와 기능을 조정해야 한다. - “전형적인 사용자”라는 가정 자체가 기술 업계의 사각지대를 만들 수 있다. ## Iris Health: 위급 상황에서 의료 정보를 전달하는 서비스 - 해외 체류 중 사고가 발생하면 가족이나 의료진이 사용자의 알레르기, 복용 약, 혈액형, 당뇨 여부 등을 알기 어렵다는 문제에서 출발했다. - 사용자가 병원에 있는 것으로 감지되면 안부를 확인하고, 10분 안에 응답이 없을 경우 등록된 비상 연락처에 문자 메시지를 보낸다. - iPhone 잠금 화면에 의료 카드가 표시되어 의료진이 이름, 약물, 알레르기, 장기 기증 여부 등의 정보를 빠르게 확인할 수 있다. - 만성질환자뿐 아니라 해외 거주자, 응급 상황에서 의사 표현이 어려운 사람에게도 유용하도록 설계됐다. - **교훈:** 사용자의 상황을 여러 각도에서 상상하고, 다양한 사용자 집단이 실제로 서비스를 어떻게 사용할지 충분히 검토해야 한다. ## Stark: 색각 이상과 대비를 확인하는 디자인 도구 - 의료 앱을 만들면서 접근성을 지원하는 디자인 도구가 부족하다는 문제를 발견해 개발했다. - Sketch에서 레이어를 선택해 다양한 색각 이상 유형을 시뮬레이션할 수 있다. - 텍스트와 배경색의 대비 비율을 확인해 색상 조합이 읽기 어려운지 판단할 수 있다. - Twitter, ESPN, Palantir, Dropbox, Microsoft 등의 팀에서도 사용됐다. - 접근성 검사를 별도 업무로 미루지 말고 디자인 워크플로에 기본 기능처럼 포함해야 한다. - Stark 외에도 Contrast, W3C 접근성 체크리스트 등을 활용해 표준 준수 여부와 개선점을 점검할 수 있다. - 시각과 촉각을 함께 고려한 Braille Neue 같은 서체도 접근성을 확장하는 사례로 소개된다. ## Lyra: 자폐 아동을 위한 기호-음성 의사소통 앱 - 대학 시절 다양한 특수 필요를 가진 아동들과 일한 경험을 바탕으로 시작됐다. - 비언어적 자폐 아동이 기호를 선택해 음성으로 의사를 표현할 수 있도록 돕는다. - 1985년부터 사용된 라미네이트 카드와 벨크로 방식의 의사소통 도구를 디지털 환경에 맞게 현대화하려는 프로젝트다. - 기존 방식은 아동이 디지털 세계에 참여하는 데 한계가 있으므로, 더 편리하고 자연스러운 의사소통 수단을 제공하려 한다. - 개발팀은 당시 베타 버전 출시를 준비하고 있었다. - **교훈:** 접근성 디자인을 제대로 만들려면 관련 사용자와 문제 영역을 스스로 학습해야 하며, Microsoft의 Inclusive Design 가이드 같은 자료부터 참고할 수 있다. 제품을 만들 때 접근성을 출시 직전의 검수 항목으로 두기보다, 사용자 조사·정보 구조·시각 디자인·개발 도구에 기본값으로 포함하는 것이 좋다. 특히 실제 장애 사용자와 함께 테스트하고, 색상 대비·키보드 사용·의사소통 방식 등 구체적인 사용 조건을 반복적으로 검증해야 한다.

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

sketch사용자 인터페이스접근성inclusive-design+3

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

Sketch 사용자의 Figma 전환기 | 피

Figma는 Sketch의 기능을 대체하는 수준을 넘어, 실시간 협업과 웹 기반 작업 환경을 통해 디자인 프로세스 자체를 더 빠르고 단순하게 만든다는 것이 글의 핵심 주장이다. 자동 저장·공유, 프로토타이핑, 개발자 핸드오프, 버전 관리 등을 하나의 도구에 통합해 팀 간 동기화 비용을 줄인다. 특히 여러 지역에 분산된 제품 팀이라면 Sketch 중심의 기존 워크플로보다 Figma가 더 효율적이라는 결론이다. ## 웹 기반 실시간 협업 도구 - Figma는 브라우저에서 작동하는 디자인 도구이며, Sketch와 유사한 인터페이스와 기능을 제공한다. - 오프라인 작업을 위한 네이티브 앱도 지원한다. - 실시간으로 여러 명이 하나의 파일에서 작업할 수 있고, 서로의 커서와 변경 사항을 즉시 확인할 수 있다. - 파일이 클라우드의 공유 공간에 자동 저장되므로 별도의 저장·파일 정리 과정이 줄어든다. - 하나의 URL이 최신 디자인의 기준점이 되어 PNG 업로드, 파일 동기화, 링크 관리가 필요하지 않다. ## Sketch 생태계를 대체하는 통합 기능 글에서는 Figma가 Sketch뿐 아니라 Abstract, InVision, Craft, LiveShare, Freehand, Zeplin, Dropbox의 역할까지 상당 부분 통합한다고 설명한다. - **프로토타이핑**: 화면을 연결해 클릭 가능한 프로토타입을 만들 수 있다. - **댓글 기능**: 링크를 가진 사용자가 디자인의 특정 위치에 댓글을 남길 수 있으며, 사용자를 태그하거나 댓글을 해결 상태로 표시할 수 있다. Slack 연동도 가능하다. - **개발자 핸드오프**: 개발자가 URL을 통해 치수와 스타일을 확인하고 아이콘·이미지를 다운로드할 수 있다. - **버전 관리**: 모든 협업자의 변경 이력이 저장되며, 과거 버전으로 되돌리거나 해당 시점에서 새 작업을 시작할 수 있다. - **멀티플레이어 협업**: 여러 사람이 동시에 디자인을 수정하고 의견을 교환할 수 있다. - **화면 공유와 팔로우**: 특정 사용자의 아바타를 선택해 그 사람이 보고 있는 화면과 커서 움직임을 따라갈 수 있다. - **컴포넌트와 제약 조건**: Sketch의 심볼과 리사이징 기능에 해당하지만 더 유연하고 직관적으로 사용할 수 있다. - **팀 라이브러리**: 여러 프로젝트에서 컴포넌트 컬렉션을 공유하고 업데이트할 수 있다. - Dropbox Paper 문서에 Figma 프로젝트를 삽입할 수도 있다. ## 동기화 비용을 없애 더 빠르게 반복하기 - 디자인 리뷰 중에 수정하고, 수정 결과에 대한 피드백을 즉시 받을 수 있다. - 기존에는 디자인 파일 수정 후 InVision에 화면을 다시 업로드하거나, 프로토타입 순서를 재정렬하거나, 공유 링크를 다시 전달해야 했다. - Figma에서는 모든 참여자가 같은 파일을 보므로 이런 업로드·동기화·공유 과정이 사라진다. - 시간대가 다른 팀원이 작업물을 커밋하거나 업로드할 때까지 기다릴 필요가 없다. - 플러그인 업데이트로 기존 워크플로가 깨지는 문제도 줄어든다. - 결과적으로 디자인 반복 주기가 며칠 단위에서 몇 분 단위로 단축될 수 있다. ## 더 개방적이고 원활한 디자인 프로세스 - 디자인 파일 자체가 리뷰와 토론이 이루어지는 공동 작업 공간이 된다. - 디자이너뿐 아니라 개발자, 기획자 등 링크를 받은 팀원이 같은 화면에서 디자인을 확인하고 의견을 남길 수 있다. - 별도의 파일 전달이나 발표용 이미지 제작 없이 최신 상태의 디자인을 공유할 수 있다. - 실시간 협업과 댓글 기능은 원격·분산 팀이 디자인 논의에 참여하기 쉽게 만든다. ## 실용적인 결론 Sketch의 기존 기능과 플러그인에 크게 의존하는 팀이라도, Figma는 프로토타이핑부터 핸드오프·버전 관리·협업까지 하나의 환경에서 제공한다. 특히 여러 지역에 흩어진 팀이나 디자인 리뷰와 개발자 커뮤니케이션이 잦은 조직이라면, Figma 도입으로 파일 동기화와 반복적인 공유 작업을 우선 줄여볼 만하다.

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

sketchFigma디자인 시스템프로토타이핑+3