figma2023년 8월 30일

스포티파이의 디자인 (새 탭에서 열림)

Spotify는 45개 플랫폼과 2,000종 이상의 기기에서 일관된 브랜드 경험을 제공하기 위해 디자인 시스템 Encore를 플랫폼별 체계에서 크로스플랫폼 체계로 확장했다. 초기에는 모바일과 웹 시스템이 분리되어 유연성을 얻었지만, 시간이 지나며 컴포넌트의 불일치와 중복이 커졌다. 이에 공통 기반과 재사용 가능한 중간 계층을 마련하고, 컴포넌트를 처음부터 여러 플랫폼이 함께 설계하는 방식으로 전환했다. ## 일관된 경험이 필요해진 배경 - Spotify는 TV, 자동차, 모바일, 컴퓨터 등 다양한 환경에서 오디오 콘텐츠를 제공하게 됐다. - 2019년 기준 45개 플랫폼, 2000종 이상의 기기, 200개 브랜드에 걸쳐 서비스를 제공해야 했다. - 목표는 모든 플랫폼을 단순히 지원하는 것이 아니라, 어떤 기기에서도 사용자가 “Spotify답다”고 느끼는 일관된 경험을 만드는 것이었다. - 디자인 시스템의 컴포넌트가 플랫폼 간 경험을 통합하는 핵심 수단으로 강조됐다. ## Encore의 초기 구조와 한계 - Encore는 2019년 두 개의 하위 시스템으로 출발했다. - **Encore Consumer Mobile**: 모바일 중심 경험을 위한 유연한 UI 컴포넌트 카탈로그 - **Encore Web**: 다양한 웹 제품을 위한 시스템 - 색상과 타이포그래피 같은 기본 디자인 결정에는 디자인 토큰을 사용했다. - 그러나 각 하위 시스템이 독립적으로 발전하면서 버튼의 크기, 타이포그래피, 상태 표현 등에서 차이가 생겼다. - 제품팀의 요구가 커지면서 컴포넌트가 지나치게 유연해졌고, 플랫폼 간 공통성이 약해졌다. ## 공통 기반과 재사용 계층의 도입 - 2022년 Spotify는 유연성에 치우친 구조를 재조정할 필요가 있다고 판단했다. - Encore Mobile을 위한 재사용 가능한 컴포넌트 제작 전담 팀을 구성했다. - 이 새로운 계층은 공통 기반과 Consumer Mobile 사이에 위치했다. - 이를 통해: - Consumer Mobile이 모든 컴포넌트를 직접 제공해야 하는 부담을 줄이고 - Web과 Mobile 사이의 플랫폼 대응성을 높이며 - 제품별로 중복 구현되는 컴포넌트를 줄일 수 있었다. - Web 팀과 협력해 크로스플랫폼 컴포넌트를 나중에 맞추는 대신, 처음부터 함께 개발하기 시작했다. ## 크로스플랫폼 컴포넌트 설계 방식 - 기존처럼 사용자 조사, 디자인, 개발로 이어지는 과정 자체는 유지했다. - 가장 큰 변화는 디자인 단계에서 특정 플랫폼 하나만을 대상으로 하지 않는 것이었다. - iOS, Android, Web 팀이 함께 각 플랫폼의 요구사항과 특성을 조사하고, 공통 경험을 조율했다. - 플랫폼별 고유성을 없애는 것이 아니라, 공통된 구조와 시각적 언어를 유지하면서 각 환경에 맞게 적용하는 것이 목표였다. - 웹, 모바일, TV는 입력 방식과 화면 크기 등 사용 맥락이 다르므로, 동일한 컴포넌트를 그대로 복제하기보다 플랫폼의 장점을 보존해야 했다. - 이를 위해 각 플랫폼 전문가가 협업하는 구조가 중요했다. 웹과 모바일 양쪽 모두에 정통한 디자이너는 드물기 때문에, 여러 분야의 전문성을 한 과정 안에서 결합해야 했다. Spotify의 사례는 디자인 시스템을 플랫폼별 컴포넌트 모음으로 관리하기보다, 공통 기반·재사용 계층·플랫폼별 특화를 연결하는 구조로 설계해야 한다는 점을 보여준다. 실무에서는 플랫폼 팀을 초기 설계 단계부터 참여시키고, 공통 토큰과 컴포넌트의 범위를 명확히 정하는 방식이 효과적이다.

webdesign-systemsandroidios+3

figma2020년 2월 26일

Config: 피그마의 첫 번째 (새 탭에서 열림)

Figma의 첫 사용자 컨퍼런스 Config는 1,000명 이상이 모여 배우고 교류하는 커뮤니티 중심의 행사로 기획됐다. Figma는 정해진 의제를 일방적으로 전달하기보다 참가자들의 제안과 참여를 바탕으로 행사를 구성했으며, 디자인을 공개적으로 공유하고 함께 발전시키는 “오픈 디자인”을 핵심 주제로 다뤘다. 기술은 사람을 고립시키는 도구가 아니라 공동체와 더 깊이 연결하는 수단으로 활용해야 한다는 메시지도 강조됐다. ## 커뮤니티가 직접 만든 컨퍼런스 - Config의 목표는 사용자 커뮤니티를 물리적인 공간으로 구현해 의미 있는 대화를 나누는 것이었다. - 팀 문화, 멘토링, 디자인 윤리 같은 주제를 중심으로 참가자들이 서로 배우고 경험을 공유하도록 했다. - Figma 직원이 사용자들의 목소리를 직접 듣고, 사용자들이 서로 만날 수 있는 기회를 마련했다. - 워크숍, 라이트닝 토크, 라운드테이블의 상당수가 참가자들의 제안으로 구성됐다. - 단순히 발표를 듣는 행사가 아니라, 참가자들이 직접 기여하는 공동 토론의 장을 지향했다. - 현장 참석자뿐 아니라 온라인 참가자도 세션 녹화 영상을 통해 행사에 참여할 수 있도록 했다. ## 오픈 디자인과 협업 - 컨퍼런스의 중심 주제는 디자인 분야에서의 “오픈하게 만들기(open design)”였다. - 엔지니어링의 오픈소스 문화처럼 디자인 결과물을 공유하고, 다른 사람이 이를 수정·재사용·확장하는 방식을 강조했다. - Devon Zuegel은 오픈소스의 원리가 디지털 제품을 넘어 도시 계획과 물리적 인프라에도 적용될 수 있다고 설명했다. - Jason Kunesh는 시카고 디자인팀의 자원이 부족한 상황에서 학생들이 팀의 확장된 구성원으로 참여해 디자인 시스템을 구축한 사례를 소개했다. - Miguel Solorio는 Microsoft가 커뮤니티를 디자인 과정에 참여시켜 제품 개발에 사용자 의견을 반영한 경험을 공유했다. - 이를 통해 디자인은 소수의 전문가가 완성하는 결과물이 아니라, 더 넓은 공동체가 함께 만드는 과정이라는 관점을 제시했다. ## 기술과 공동체의 관계 - Craig Mod는 스마트폰과 같은 기술이 사람을 원하는 장소로 순간 이동시키는 것처럼 작동해, 주변 사람들과의 관계를 단절시킬 수도 있다고 지적했다. - 기술을 현실에서 도피하는 수단으로 사용하기보다, 주변 사람들과 더 깊이 연결하는 방식으로 활용해야 한다고 강조했다. - 커뮤니티는 단순히 온라인에서 모인 사용자의 집합이 아니라, 서로 돌보고 참여하며 공동의 가치를 만들어가는 관계망으로 확장됐다. ## 기존 질서에 도전하는 태도 - May-Li Khoe는 자신이 중요하게 생각하는 공동체를 지원하면서도 기존의 규범과 현상 유지를 즐겁게 뒤집는 방법을 공유했다. - 참가자들에게 각자의 커뮤니티를 위해 어떤 변화를 만들 수 있을지 고민하도록 독려했다. - 이는 디자인 실무를 넘어 조직문화, 사회적 책임, 공동체 참여에까지 디자인의 역할을 확장하는 메시지였다. ## 실용적인 시사점 Config의 사례는 사용자 행사를 성공시키려면 일방적인 제품 발표보다 참가자들이 직접 의제와 콘텐츠를 만들 수 있는 구조가 중요하다는 점을 보여준다. 또한 디자인 조직은 결과물을 폐쇄적으로 관리하기보다 지식과 작업물을 공유하고, 사용자·학생·지역사회 등 다양한 사람을 설계 과정에 참여시키는 방식을 고려할 수 있다.

webfigmadesign-systemsopen-source+2

figma2019년 2월 13일

피그마, 세쿼이아 (새 탭에서 열림)

Figma는 Sequoia Capital이 주도한 4,000만 달러 규모의 Series C 투자를 유치했으며, 이를 통해 협업형 디자인 플랫폼으로서의 성장을 가속하려 한다. 회사는 조직·엔터프라이즈 기능, 성능과 디자인 시스템 지원, 플랫폼 확장성, 글로벌 커뮤니티에 집중할 계획이다. 궁극적으로 Figma는 디자인을 누구나 쉽게 표현하고 함께 작업할 수 있는 개방적이고 커뮤니티 중심의 공간으로 만들고자 한다. ## 투자 유치와 투자자 구성 - Series C 규모는 4,000만 달러다. - Sequoia Capital이 투자를 주도했다. - Coatue, Founders Fund, LinkedIn CEO 제프 와이너, Instagram 공동창업자 마이크 크리거, EA CEO 앤드루 윌슨, Facebook 파트너십 부사장 댄 로즈가 참여했다. - 기존 투자자인 Index, Greylock, KPCB도 함께 투자했다. - Figma는 단순한 자금보다 지속 가능한 기업과 커뮤니티를 구축한 경험이 있는 투자자를 확보하는 데 의미를 뒀다. ## 협업형 디자인 도구로의 확장 - 생산성 도구 전반이 공유와 협업을 중심으로 변화하고 있으며, 디자인 도구도 같은 방향으로 발전한다고 설명한다. - Square, Uber, Twitter, GitHub 등 주요 기업의 디자인 팀이 Figma를 전면적으로 도입하고 있다. - 투자금은 기업용 **Organization 제품**을 발전시키는 데 활용된다. - 동시에 개인 디자이너와 소규모 팀의 사용 경험도 개선할 예정이다. - 이는 Figma를 개인용 디자인 도구에서 대규모 조직의 표준 협업 플랫폼으로 확장하려는 전략이다. ## 성능과 디자인 시스템 - Figma는 네이티브 경쟁 제품보다 빠르다는 평가를 받고 있지만, 로딩과 렌더링 성능을 더 개선할 여지가 있다고 본다. - 가입자가 100만 명을 넘은 만큼, 사용자 규모가 커져도 안정적이고 높은 품질의 경험을 제공하는 것이 중요하다. - 특히 디자인 시스템을 만들고 관리하기에 가장 좋은 환경을 구축하는 데 집중한다. - 디자인 시스템은 여러 팀이 일관된 UI 요소와 규칙을 공유하도록 돕는 핵심 기업 기능으로 제시된다. ## 플랫폼과 확장성 - 디자인 프로세스가 진정으로 개방적이려면 다양한 사용 사례에 맞게 Figma를 확장할 수 있어야 한다. - 회사는 플랫폼 기능과 확장 기능을 개발하고 있다. - 다만 확장 기능의 안정성과 보안을 확보하는 것이 우선이므로 구체적인 출시 일정은 제시하지 않았다. - 향후 플러그인이나 외부 도구 연동을 통해 Figma의 활용 범위가 넓어질 가능성을 보여준다. ## 글로벌 커뮤니티 구축 - Figma의 주간 활성 사용자 중 80%가 미국 외 지역에서 활동한다. - 라고스부터 토론토까지 26개 도시에서 사용자 그룹이 운영되고 있다. - 회사는 서로 다른 지역의 사용자를 더 효과적으로 연결하고, 지역 커뮤니티가 성장하도록 지원할 계획이다. - Sequoia가 커뮤니티 중심 비즈니스 구축 경험을 갖췄다는 점도 투자 유치의 중요한 이유로 언급된다. - Figma는 커뮤니티를 제품 성장의 부수적 요소가 아니라 미래 전략의 기반으로 본다. Figma는 이번 투자를 바탕으로 기업용 협업 기능과 제품 품질을 강화하는 동시에, 확장 가능한 플랫폼과 글로벌 사용자 커뮤니티를 구축하려 한다. 기업이나 팀에서 디자인 협업 도구를 선택할 때는 실시간 공동 작업뿐 아니라 조직 관리, 디자인 시스템, 확장성, 커뮤니티 생태계까지 함께 고려할 필요가 있다.

webfigmadesign-systemscollaboration+2

figma2018년 10월 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 챌린지는 보상, 사용권, 선정 기준을 명확히 제시해야 한다. - 좋은 기술적 목표라도 창작자의 권리와 보상 구조를 고려하지 않으면 커뮤니티의 신뢰를 잃을 수 있다.

webfigmaapidesign-tools+2

figma2015년 12월 14일

처음부터 슬랙과 함께 | (새 탭에서 열림)

Figma는 협업형 인터페이스 디자인 도구의 핵심 협업 경험을 자체 메시징 기능이 아니라 Slack 위에 구축하기로 했다. 디자이너들이 Slack을 일상적으로 사용하고, Slack 사용자가 디자인 과정을 더 개방적으로 공유하는 경향이 있었기 때문이다. 따라서 Figma 팀을 Slack 팀과 연결하고 파일 알림도 Figma가 아닌 Slack으로 전달하는 전략이 통합과 사용자 경험 측면에서 효과적이었다. ## Slack 사용자를 관찰한 배경 - Figma는 제품을 개발하며 디자이너들이 파일 저장, 사양 작성, 제품 의사결정 등을 어떻게 협업하는지 조사했다. - 인터뷰한 디자이너 중 절반 이상이 Slack을 하루 종일 사용한다고 답했다. - Slack 사용 여부는 다른 협업 방식과도 연관되어 있었다. - Slack을 사용하는 디자이너일수록 디자인 과정을 팀에 더 개방적이고 투명하게 공유하는 경향이 있었다. - 이를 통해 Slack이 단순한 채팅 도구가 아니라 디자인 협업의 중심 채널이 될 수 있다고 판단했다. ## 중복 기능을 만들지 않은 이유 - Figma는 디자인에 대한 커뮤니케이션을 지원하는 제품이므로, 자체적으로 메시지·알림 기능을 구현하고 싶은 유혹이 있었다. - 하지만 Slack과 비슷한 기능을 다시 만들면 다음과 같은 문제가 생긴다. - 사용자가 메시지를 확인할 장소를 하나 더 관리해야 한다. - 팀을 Figma와 Slack 양쪽에서 별도로 설정해야 한다. - 이미 익숙한 협업 흐름이 여러 서비스로 분산된다. - Figma는 사용자가 또 다른 메시지함을 확인하도록 만들기보다, 기존에 사용 중인 Slack을 협업 기반으로 활용하기로 했다. ## Figma와 Slack의 긴밀한 통합 - Figma의 협업 모델에서 “Figma 팀”은 “Slack 팀”과 연결된다. - Figma 파일에서 발생하는 알림은 Figma 내부가 아니라 Slack을 통해 전달된다. - 사용자는 Slack에서 디자인 관련 소식을 확인하고 팀원과 논의할 수 있다. - 이는 Slack을 단순한 외부 연동 대상이 아니라 Figma 협업 경험의 기반 플랫폼으로 활용한 결정이다. ## 플랫폼 전략과 사업적 판단 - Figma는 Slack 플랫폼이 공식적으로 출시되기 전부터 Slack을 플랫폼으로 바라보고 통합을 준비했다. - Slack 중심의 협업 구조는 당시로서는 큰 전략적 선택이었지만, 초기 성과를 통해 그 판단이 효과를 내고 있다고 평가했다. - 글은 앞으로 다른 기업들도 자체 기능을 무작정 복제하기보다, 사용자가 이미 익숙한 플랫폼 위에 제품 경험을 구축할 가능성이 커질 것이라고 전망한다. 실용적으로는 새로운 협업 기능을 개발할 때 자체 메시징·알림 시스템을 추가하기 전에, 사용자가 이미 매일 사용하는 도구와 자연스럽게 연결하는 방식을 우선 검토할 필요가 있다.

webfigmaslackcollaboration+2