Figma/디자인 시스템

246 개의 포스트

figma2분 읽기큐레이션 요약

Config 2021

Config 2021의 핵심 메시지는 제품 개발에서 실패, 지연, 갈등 같은 “엉킨 순간”을 피하기보다 성장의 재료로 받아들여야 한다는 것이다. 프로젝트가 중단되거나 팀 내 마찰이 생겨도 이를 개인적 실패로 해석하지 말고, 기록·대화·성찰을 통해 다음 작업과 더 나은 협업으로 전환해야 한다. ## 실패와 좌절을 새로운 관점에서 바라보기 Shopify의 Shanique Shields는 1년 반 동안 진행한 기능이 롤백된 경험을 소개한다. 처음에는 자신의 실패라고 느꼈지만, 프로젝트에서 잠시 거리를 둔 뒤 이를 학습의 기회로 재해석할 수 있었다. - **실패를 개인적인 평가로 받아들이지 않기** - 피드백이나 기능 변경은 작업자의 능력보다 이해관계자와 고객의 관점 차이에서 비롯될 수 있다. - **과정을 문서화하기** - 출시되지 않은 작업이라도 디자인 의도, 의사결정 과정, Figma 댓글과 메모를 보존한다. - 기록은 다음 프로젝트에서 개선점을 찾게 하고, 다른 디자이너가 참고할 수 있는 작업 아카이브가 된다. - **프로젝트에서 얻을 것을 의식하기** - 새로운 기술, 사업 영역에 대한 이해, 다른 직군과의 협업 경험 등 프로젝트를 통해 얻는 성장을 명확히 파악한다. - **다음 작업을 새로운 출발점으로 삼기** - 실패감에 머무르기보다 다음 업무의 공동 목표를 세우고 팀의 동기를 다시 끌어올린다. ## 솔직한 대화와 주의 깊은 경청 Headspace의 Frank Bach는 팀의 갈등을 방치하지 말고 투명한 대화로 해결해야 한다고 강조한다. 강한 팀 문화와 프로세스가 있어도 의사소통이 끊기면 문제가 쌓일 수 있기 때문이다. - 갈등 상황에서 자신의 입장을 최대한 투명하게 설명한다. - 상대방의 말을 실제로 이해하려는 태도로 듣는다. - 어려운 대화라도 객관적이고 솔직하게 시작해야 한다. - 마찰을 무시하면 문제가 해결되지 않고 더 커지므로, 용기를 내어 직접 다룬다. - 일이 잘 풀렸을 때는 동료, 팀, 디자이너로서의 기회에 감사하는 태도도 중요하다. ## 지속 가능한 팀 문화를 만드는 태도 Config 2021에서는 팀 문화 전환과 확장 가능한 프로세스도 다뤘지만, 실제 업무에서는 예상치 못한 장애와 인간적인 갈등이 언제든 발생한다는 점을 전제로 한다. - 완벽하게 정리된 프로세스만으로 모든 문제를 예방할 수는 없다. - 실패와 충돌을 숨기기보다 학습 가능한 경험으로 공개적으로 다룬다. - 개인의 감정적 회복과 팀 차원의 목표 재정렬을 함께 진행한다. - 기록과 솔직한 대화를 통해 어려운 경험을 조직의 지식으로 전환한다. 실무에서는 프로젝트가 중단되거나 갈등이 생겼을 때 즉시 자책하거나 회피하기보다, 잠시 거리를 두고 과정을 기록한 뒤 당사자들과 사실 중심으로 대화하는 것이 좋다. 그렇게 하면 실패한 결과도 개인과 팀의 성장 자산으로 남길 수 있다.

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

댄틀리 데이비스와의 Q

Dantley Davis는 디자인을 형식과 기능을 통한 문제 해결로 보고, 의도적인 창작과 데이터 기반 판단을 강조한다. 그는 좋은 팀이 되려면 호기심, 피드백, 상호 신뢰, 낮은 자아가 필요하며, 디자인 리더는 다양한 분야를 이해하고 포용적인 팀을 만들어야 한다고 말한다. 개인적으로는 창의성을 유지할 시간과 부수 프로젝트가 중요하며, 역경을 영향력으로 전환하는 태도를 보여준다. ## 디자인 철학과 창작 과정 - 창작 과정의 핵심은 **“의도적(intentional)”**인 접근이다. - 좋은 디자인은 사용자가 필요성을 인식하지 못했던 문제를 해결해, 해결된 뒤에는 없이는 살 수 없게 만드는 디자인이다. - 디자인은 **형식과 기능을 통한 문제 해결**이다. - 가장 큰 디자인의 두려움은 작업물이 사람들에게 아무런 반응도 일으키지 못하는 것이다. - 자기 자신만을 기준으로 디자인하는 것을 가장 큰 문제점으로 꼽았다. - 업무 외에 개인 시간을 갖고 사이드 프로젝트를 진행할 때 가장 창의적이고 최고의 상태가 된다고 설명했다. ## 데이터와 인접 분야의 중요성 - 디자인 업계에서 ‘사상적 리더(thought leader)’라는 지위는 과대평가되어 있다고 본다. - 반대로 데이터를 활용해 디자인 결정을 뒷받침하는 일은 과소평가되어 있다고 말한다. - 젊은 디자이너에게는 비즈니스, 엔지니어링, 금융 등 인접 분야를 공부하라고 조언한다. - 다양한 분야에 대한 이해는 디자이너를 더 균형 잡힌 사고를 하는 사람으로 만든다. - 최근 출시한 제품이나 기능이 사용자에게 실질적인 가치를 주지 못했다면, 오래 유지하기보다 빠르게 제거하는 판단도 필요하다고 지적했다. ## 신뢰와 피드백을 기반으로 한 팀 - 좋은 협업자는 호기심이 많고 자아가 강하지 않은 사람이다. - 팀이 진정한 팀처럼 느껴지려면 다음 조건이 필요하다. - 서로를 신뢰하고, 팀과 개인을 개선하기 위해 적극적으로 피드백을 요청한다. - 구성원들이 자신의 작업이나 관점으로 서로에게 영감을 준다. - 개인의 자아나 지위가 협업을 방해하지 않는다. - Davis가 경력에서 가장 자랑스럽게 생각하는 성과는 **기술 업계에서 가장 다양한 팀을 만든 것**이다. - 디자인 리더십은 개인의 결과물뿐 아니라 팀의 구성과 문화까지 책임지는 역할로 확장된다. ## 디자인의 사회적·문화적 영향 - Davis는 Design Twitter 커뮤니티에서 멘토 역할을 하려 한다. - 기술 업계에서 디자이너이자 리더로 일하며 얻은 경험을 다른 디자이너들과 공유하려고 한다. - Roblox를 훌륭하지만 주목받지 못한 디자인 사례로 꼽았다. - 아이들이 게임을 즐기는 데 그치지 않고, 서로 소통하고 직접 무언가를 만들 수 있다. - 단순 소비에 집중하는 많은 앱과 달리 참여와 창작을 가능하게 한다. - Afrotech의 가상 콘퍼런스도 인상적인 사례로 언급했다. - 사용자가 아바타를 만들고 가상 세계를 이동할 수 있었다. - 온라인 행사에 물리적 현장감과 존재감을 더했다. ## 개인적 취향과 관심 분야 - 선호하는 UI 글꼴은 Montserrat이며, 좋아하는 서체는 Akzidenz-Grotesk다. - 색상 표기 방식으로는 Hex를 선호하고, 대표 색상으로 `#000000`을 제시했다. - 1990년대 웹의 시각적 스타일을 다시 가져오고 싶다고 답했다. - Porsche의 자동차와 브랜드 생태계를 디자인하고 싶어 한다. - 실제 주행 경험부터 모바일 앱까지 연결된 전체 경험을 포함한다. - 오랫동안 자동차 인터페이스를 디자인하고 싶어 했으며, 이동 경험과 디지털 제품의 결합에 관심을 보였다. - Figma 기능 중에서는 다른 사람의 작업을 관찰할 수 있는 **Observation Mode**를 가장 좋아한다고 밝혔다. ## 디자인 리더에게 필요한 태도 - 디자인 리더는 작업 결과뿐 아니라 팀의 다양성, 문화, 협업 방식을 함께 설계해야 한다. - 업계의 명성이나 ‘리더’라는 호칭보다 실제 문제 해결과 사용자에게 미치는 영향이 중요하다. - 자신이 만든 결과물에 애착을 갖더라도, 사용자에게 의미 있는 혜택을 주지 못한다면 제거할 수 있어야 한다. - 자신의 전문 영역에만 머물지 않고 비즈니스와 기술 등 주변 분야를 이해해야 더 큰 영향력을 발휘할 수 있다. 실무적으로는 디자인 과정에 데이터를 적극 활용하고, 팀 내 피드백을 일상화하며, 사용자의 실제 가치가 낮은 기능은 과감히 개선하거나 제거하는 것이 Davis의 조언을 적용하는 방법이다.

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

In the file: Config

Config 2021의 Coda와 Stripe 사례는 디자인팀이 불확실성과 단기 요구를 다루면서도 장기적인 제품 방향과 확장성을 확보하는 방법을 보여준다. Coda는 사용자 데이터가 없는 0→1 단계에서 경쟁사 분석과 팀의 직관으로 관점을 세웠고, Stripe는 장기적 관점·튼튼한 기반·엄격한 품질 기준을 통해 복잡한 결제 경험을 단순화했다. 두 사례 모두 명확한 비전과 이를 공유하는 프로세스가 팀 정렬과 좋은 제품 결정의 핵심이라고 강조한다. ## 0→1 제품에서 맥락 만들기 - Coda의 Helena Jaramillo는 기존 제품을 개선하는 대신, 새로운 퍼블리싱 플랫폼을 처음부터 구축하는 과제를 맡았다. - 초기 제품에는 기존 사용자의 행동 데이터나 인터뷰할 사용자 자체가 없었기 때문에 일반적인 리서치 인사이트를 활용하기 어려웠다. - 이를 보완하기 위해 경쟁 제품과 인접 분야의 서비스를 조사했다. - 조사 결과를 Figma 파일에 스크린샷과 주석으로 정리해 다음을 공유했다. - 어떤 접근 방식이 효과적인지 - 어떤 방식은 Coda에 적합하지 않은지 - 경쟁 제품에서 참고할 만한 패턴은 무엇인지 - 데이터가 부족한 초기 단계에서는 외부 사례를 체계적으로 분석해 팀이 논의할 수 있는 공통 맥락을 만드는 것이 중요하다. ## 강한 제품 관점과 비전 수립 - Coda는 사람들이 왜 Coda에서 콘텐츠를 발행해야 하는지, Coda만의 차별점이 무엇인지부터 질문했다. - 퍼블리싱 경험이 다음 중 무엇에 가까워야 하는지 검토했다. - 블로그 글을 발행하는 경험 - 노코드 앱을 만드는 경험 - 웹사이트를 제작하는 경험 - Helena 자신의 퍼블리셔 경험과 팀 토론을 바탕으로 두 가지 우선순위를 도출했다. - 발행 과정을 쉽게 만들 것 - 발행자가 자신의 결과물을 자랑스럽게 느끼게 할 것 - 이 관점은 구체적인 제품 결정으로 이어졌다. - 인터랙티브 문서를 쉽게 발행할 수 있는 흐름 - 사진, 부제목, 작성자 정보를 추가할 수 있는 기능 - 사용자 인사이트가 부족하더라도 팀이 함께 명확한 관점을 세우면 일관된 제품 방향을 결정할 수 있다. ## 복잡한 아이디어를 이야기로 전달하기 - Helena는 기능 목록만 설명하는 대신 제품이 만들고자 하는 경험을 하나의 이야기로 전달했다. - 이를 위해 Figma에 “tl;dr 페이지”를 만들고 다음을 포함했다. - 핵심 사용자 흐름 - 소수의 대표 목업 - 팀이 만들려는 경험의 전체적인 서사 - 이 페이지는 세부 기능을 모두 설명하기보다, 협업자가 짧은 시간 안에 제품의 방향을 이해하도록 돕는 역할을 했다. - 크로스펑셔널 팀을 설득할 때는 상세한 사양보다 문제, 사용자 경험, 제품의 의도를 한눈에 보여주는 자료가 효과적이다. ## 단기 요구와 장기 확장성의 균형 - Stripe 디자인팀은 기업과 최종 사용자가 겪는 복잡한 프로세스를 최대한 단순하고 쉽게 만드는 것을 목표로 한다. - 이를 위해 당장의 요구를 해결하는 동시에 장기적으로 확장 가능한 시스템과 프로세스를 구축한다. - Connie Yang은 이를 “도시 계획가의 사고방식”에 비유했다. - 개별 건물이나 차량만 설계하지 않는다. - 도로의 폭과 교통 흐름을 고려한다. - 시스템 간 연결 관계를 설계한다. - 화재나 재난 같은 미래의 예외 상황에도 대비한다. - 팀은 현재의 속도를 유지하면서도 “2030년까지 작동할 구조인가”를 질문한다. ## 튼튼한 기반과 확장 가능한 시스템 - 장기적 관점은 인프라와 디자인 시스템에 대한 투자로 구체화된다. - Stripe가 말하는 견고한 기반에는 다음이 포함된다. - 빠르고 접근성 높은 제품과 플랫폼 구축 - 임시방편보다 확장 가능한 시스템 개발 - 반복적으로 활용할 수 있는 공통 규칙과 구조 마련 - Stripe 디자인 시스템의 색상 테이블에는 색상 대비와 접근성 평가 정보가 내장되어 있다. - 디자이너가 매번 접근성을 별도로 확인하지 않아도 되며, 시스템 자체가 더 나은 결정을 유도한다. - 이런 기반은 팀의 생산성을 높이는 동시에 최종 사용자의 경험과 접근성도 개선한다. ## 엄격한 품질 기준과 사용자 신뢰 - Stripe에서는 “디테일이 중요하다”는 원칙을 중시한다. - Stripe는 결제 승인과 대금 지급처럼 신뢰가 핵심인 업무를 다루므로, 작은 UI 요소도 사용자 경험과 신뢰에 영향을 준다. - 때로는 구현이 더 어렵거나 시간이 오래 걸리더라도, 최종적으로 더 안전하고 명확한 경험을 제공하는 방식을 선택한다. - 단기적으로 빠른 해결책을 택하기보다 품질, 정확성, 접근성을 높이는 선택이 장기적인 제품 신뢰로 이어진다. ## 실무에 적용할 때의 시사점 - 데이터가 부족한 초기 제품이라면 경쟁사와 인접 분야를 조사해 팀의 공통 맥락을 만든다. - 팀의 직관을 막연한 의견으로 두지 말고, 명확한 제품 원칙과 우선순위로 정리한다. - 세부 기능보다 사용자 흐름과 제품의 핵심 이야기를 먼저 공유한다. - 단기 요구를 해결할 때도 디자인 시스템, 접근성, 성능처럼 미래에 반복될 기반을 함께 설계한다. - 빠른 실행과 장기적 품질 사이에서 균형을 잡되, 사용자 신뢰가 중요한 영역에서는 품질 기준을 낮추지 않는 것이 좋다.

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

브랜칭 기능 소개: 자유롭게

Figma는 공유 파일을 보호하면서도 디자이너가 자유롭게 실험할 수 있도록 브랜칭 기능을 베타로 도입했다. 브랜치를 만들면 원본 파일과 분리된 공간에서 작업하고, 검토가 끝난 변경 사항만 메인 파일에 병합할 수 있다. 이를 통해 대규모 디자인 시스템의 일관성과 협업 속도를 함께 확보하려는 것이 핵심이다. ## 분산된 디자인 시스템이 만든 문제 - 여러 팀이 디자인 시스템을 사용하면서도 시스템이 여러 파일과 플랫폼에 분산되어 있었다. - 컴포넌트를 재사용해 생산성은 높아졌지만, 위치가 분산되어 도구 사이를 오가야 했고 구현 결과도 일관되지 않았다. - 넷플릭스의 Hawkins처럼 100명 이상의 디자이너가 참여하는 시스템에서는 최신 변경 사항이 실제 승인된 버전이라는 보장이 어려웠다. - 따라서 디자인 시스템을 중앙화하되, 승인되지 않은 변경이 공유 파일에 즉시 반영되지 않도록 하는 장치가 필요했다. ## 브랜치로 실험 공간과 원본 보호 - 디자이너는 기존 파일에서 브랜치를 생성해 새로운 아이디어와 반복 작업을 독립적으로 진행할 수 있다. - 브랜치의 변경 사항은 메인 파일에 자동 저장되지 않으므로, 실수나 미승인 변경으로 공유 파일이 오염되는 것을 방지한다. - 작업이 완료되면 편집자가 변경 내용을 검토한 뒤 메인 파일에 병합할 수 있다. - 결과적으로 공유 파일은 승인된 디자인 시스템의 기준점으로 유지되고, 브랜치는 자유로운 탐색 공간이 된다. ## 단순성과 일관성을 우선한 설계 - Figma는 일반적인 Git 방식처럼 별도의 커밋 작업을 요구하지 않기로 했다. - 브랜치 안의 작업은 Figma 파일과 마찬가지로 자동 저장된다. - 브랜치 안에서 다시 브랜치를 만드는 복잡한 구조도 배제했다. - 브랜치도 Figma의 멀티플레이어 협업 기능을 그대로 지원하므로 여러 사람이 동시에 작업할 수 있다. - 브랜칭을 별도의 복잡한 도구가 아니라 기존 파일 협업 경험에 자연스럽게 통합하는 것이 목표였다. ## 버전 관리의 확장 - Figma는 향후 리뷰 기능을 추가하면서 브랜칭과 멀티플레이어 작업을 아우르는 통합적인 버전 관리 방식을 모색하고 있다. - 사용자가 기능별로 서로 다른 버전 관리 개념을 익히지 않고, 하나의 일관된 방식으로 작업하도록 만드는 것이 방향이다. - 브랜칭은 조직 전체의 디자인 시스템을 중앙화하고 관리하는 기반 기능으로 제시됐다. ## 제공 범위 - 당시 브랜칭은 베타 기능으로 Figma Organization 요금제에서 제공됐다. - 사용자는 접근 신청을 해야 했으며, Figma가 순차적으로 사용자를 추가하는 방식이었다. - Professional 요금제 사용자는 Organization 요금제에 대해 영업팀에 문의하도록 안내됐다. 브랜칭은 대규모 팀에서 디자인 시스템을 운영할 때 특히 유용하다. 메인 파일에는 승인된 결과만 유지하고, 새로운 컴포넌트나 레이아웃은 브랜치에서 충분히 실험한 뒤 리뷰와 병합을 거치는 방식이 안정적인 협업 흐름을 만든다.

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

Config 2021에서

Figma는 디자인이 개인 작업이 아니라 다양한 사람들이 함께 아이디어를 만들고 발전시키는 협업 과정이라고 강조했다. Config 2021에서 이를 지원하기 위해 브레인스토밍 도구 FigJam, 브랜칭, 모바일 앱, 오디오 협업, 대규모 동시 접속, Figma Community 공개 기능을 발표했다. 결론적으로 Figma는 디자인 전 과정에 더 많은 사람이 참여할 수 있는 협업 플랫폼으로 확장되고 있다. ## 협업 중심 디자인으로의 전환 - 초기에는 디자인을 개인의 작업으로 보는 인식이 강했지만, Figma의 등장과 원격 협업 확산으로 팀 단위 작업이 일반화됐다. - 디자이너뿐 아니라 개발자, 기획자, 이해관계자 등 다양한 참여자가 디자인 과정에 기여할 수 있도록 기능을 확장했다. - 목표는 아이디어 구상부터 반복 작업, 검토와 공유까지 모든 단계에서 함께 작업하는 환경을 제공하는 것이다. ## FigJam: 아이디어 발상과 브레인스토밍 - FigJam은 기존 Figma의 인터페이스 디자인 기능이 아닌, 팀 브레인스토밍과 화이트보드 작업에 특화된 별도 공간이다. - 사용자 여정 다이어그램, 아이디어 정리, 워크숍 등 다양한 초기 기획 작업을 지원한다. - 이모티콘, 채팅 등 기능을 제공해 물리적인 회의실에서 느낄 수 있는 즉흥성과 상호작용을 디지털 공간에 구현하려 했다. - 2021년 4월 오픈 베타로 출시됐으며, 2022년부터 무료 및 유료 요금제($8, $15/편집자/월)가 적용될 예정이었다. ## 브랜칭을 통한 안전한 디자인 변경 - 파일을 브랜치로 복제해 기존 작업에 영향을 주지 않는 별도 공간에서 아이디어와 디자인 변형을 실험할 수 있다. - 브랜치에서도 멀티플레이어 협업이 가능하며, 작업이 끝나면 몇 번의 클릭으로 메인 브랜치에 병합할 수 있다. - 디자인 시스템에 여러 팀원이 기여하거나, 대규모 조직에서 변경 사항을 검토하는 데 유용하다. - 베타 기능으로 Organization 요금제에서 제공됐다. ## 모바일 앱과 디자인 공유 - iOS와 Android용 새 모바일 앱을 통해 파일과 프로토타입을 어디서든 확인할 수 있도록 했다. - 실제 기기에서 앱 디자인이 어떻게 보이고 작동하는지 확인하는 용도뿐 아니라, 이해관계자에게 작업물을 공유하는 용도도 강조됐다. - 미러링 재생 경험을 안정화하고, 모바일에서 디자인과 프로토타입에 더 쉽게 접근하도록 개선했다. ## 편집기 내 오디오 협업 - Figma 파일이나 FigJam 보드에서 별도 화상회의 도구 없이 즉시 음성 통화를 시작할 수 있다. - 실시간 디자인 리뷰, 피드백, 그룹 브레인스토밍 등에 활용할 수 있다. - Professional 및 Organization 요금제 사용자에게 제공될 예정인 기능으로 소개됐다. ## 대규모 동시 접속 지원 - 초기에는 최대 500명이 동시에 접속할 수 있도록 제한을 확대했다. - 편집자 100명 - 뷰어 400명 - 이후 Figma와 FigJam 모두에서 최대 1,000명까지 지원할 계획을 밝혔다. - 편집자 200명 - 뷰어 800명 - 대규모 디자인 발표, 워크숍, 수업 같은 상황을 지원하고 새로운 협업 방식을 가능하게 하는 것이 목적이다. ## Figma Community 공개와 공유 - 모든 사용자가 Figma Community에 파일을 게시할 수 있도록 개방했다. - 다른 사용자가 만든 파일과 FigJam 템플릿을 활용할 수 있으며, 자신의 작업물·템플릿·노하우도 공개할 수 있다. - 개인의 디자인 결과물을 공유하는 것을 넘어, 커뮤니티 기반의 학습과 재사용을 촉진하려는 방향이다. Figma의 발표는 디자인 도구를 단순한 제작 소프트웨어가 아니라 아이디어 발상, 협업, 검토, 공유를 아우르는 공동 작업 공간으로 확장하려는 전략을 보여준다. 팀 규모와 참여자 유형에 맞춰 FigJam, 브랜칭, 모바일 앱, 오디오 기능을 조합하면 원격·대규모 디자인 협업을 보다 효율적으로 운영할 수 있다.

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

렙솔(Repsol) (새 탭에서 열림)

스페인 최대 에너지 기업인 렙솔(Repsol)은 2050년 탄소 중립 달성을 목표로, 난해한 에너지 개념을 소비자가 친숙하게 느낄 수 있도록 디자인 중심의 디지털 전환을 추진하고 있습니다. 이를 위해 렙솔은 디자인 에이전시 및 피그마(Figma)와 협력하여 전사 통합 디자인 시스템인 '옥시젠(Oxygen)'을 구축하고 분산되어 있던 사용자 경험을 하나로 통합했습니다. 결과적으로 디자인은 단순한 시각적 개선을 넘어 제품 구현에 필요한 리소스를 30% 절감하고, 기업의 비즈니스 가치를 측정 가능한 수치로 증명하는 핵심 전략으로 자리 잡았습니다. **에너지 경험의 재정의와 시각화** * **인간 중심의 에너지:** 에너지를 '필요악'이 아닌 사용자가 주도적으로 관리할 수 있는 대상으로 변화시키기 위해 디자인을 활용합니다. * **실시간 가시성 제공:** 단순히 요금 고지서를 발행하는 것에 그치지 않고, 현재 날씨에 맞춰 실시간으로 가동되는 태양광 패널이나 풍력 발전기의 정보를 앱 내에서 시각적으로 보여줌으로써 에너지 사용에 대한 실감을 높였습니다. * **행동 변화 유도:** 전기차 공유 서비스 앱을 통해 주행 중 에너지 소비량을 보여주고 효율성에 따른 등급을 부여하여, 사용자가 더 효율적으로 에너지를 소비하도록 독려합니다. **Oxygen 디자인 시스템을 통한 통합** * **일관된 상호작용 언어:** 과거 10개의 제품이 각기 다른 방식으로 사용자와 소통하던 문제를 해결하기 위해, 모든 디지털 제품에 적용되는 공통의 패턴, 컴포넌트, 가이드를 구축했습니다. * **커뮤니케이션 허브로서의 피그마:** 피그마를 중심 도구로 채택하여 실무 디자이너부터 경영진까지 실시간으로 의견을 공유하고 아이디어를 반복 수정할 수 있는 환경을 조성했습니다. * **워크플로우 최적화:** 기존에 사용하던 Sketch, Invision, PowerPoint 등의 도구를 피그마 하나로 대체하여 15개 이상의 프로젝트를 동시에 일관성 있게 관리할 수 있게 되었습니다. **디자인 성과 측정과 효율성 증대** * **전용 플러그인 활용:** 피그메트릭스(Figmetrics)와 MSVM 플러그인을 개발하여 컴포넌트 활용도와 팀 간 정렬 상태를 추적하고 디자인의 투자 대비 효율(ROI)을 데이터로 입증했습니다. * **운영 효율성 개선:** 새로운 디자인 시스템 도입 이후 제품 구현에 드는 작업량을 기존 대비 30% 절감하는 성과를 거두었습니다. * **단일 진실 공급원(Single Source of Truth):** 디자인, 제품 관리, 비즈니스, 기술 팀이 동일한 기준 아래 협업함으로써 의사결정 프로세스를 단순화했습니다. 에너지 산업과 같이 복잡하고 보이지 않는 가치를 다루는 기업일수록 디자인 시스템은 단순한 도구를 넘어 비즈니스의 효율성과 사용자 신뢰를 구축하는 강력한 기반이 됩니다. 렙솔의 사례처럼 디자인 시스템을 통해 확보한 여유 자원을 기업의 본질적인 미션인 탄소 중립과 혁신에 재투자하는 선순환 구조를 구축할 것을 권장합니다.

figma3분 읽기큐레이션 요약

Tailwind UI 공식 피그

Tailwind Labs는 Tailwind UI의 코드 컴포넌트를 디자이너와 개발자가 함께 사용할 수 있는 공식 Figma 키트로 재구성했다. 약 1,400개의 컴포넌트와 10,000개의 요소를 제작하면서, 최종 코드 구조를 디자인 파일의 기준으로 삼고 레이어 이름·구조·변형을 체계화했다. 핵심 결론은 디자인 시스템을 실제 제품처럼 배포하려면 시각적 완성도뿐 아니라 일관된 구조와 사용성까지 세밀하게 설계해야 한다는 것이다. ## Tailwind UI Figma 키트 제작 배경 - Tailwind UI는 Tailwind CSS 기반의 반응형 HTML 컴포넌트 모음이다. - 고객들의 Figma 파일 요청이 지속적으로 늘어나 공식 Figma 키트를 제작하게 됐다. - 400개가 넘는 코드 컴포넌트를 바탕으로 1,400개 이상의 Figma 컴포넌트와 10,000개의 개별 요소를 구축했다. - 일반적인 작업용 디자인 파일과 달리, 상용 디자인 키트는 파일 자체가 최종 제품이므로 모든 세부 요소가 사용자 경험에 영향을 준다. ## 디자인 파일을 코드의 구조에 맞추기 - 최종 HTML 코드가 디자인 파일이 따라야 할 픽셀 단위 기준이 되도록 했다. - Figma의 오토 레이아웃, 레이아웃 그리드, 레이아웃 제약 조건을 활용해 HTML 마크업과 유사한 레이어 구조를 만들었다. - 디자인과 코드가 비슷한 구조를 가지면 디자이너와 개발자가 레이아웃 가능성을 공통으로 이해할 수 있다. - 반복되는 반응형 패딩이나 중앙 정렬된 최대 너비 컨테이너 같은 패턴을 디자인 파일에서 발견하고, 이를 개발자가 재사용 가능한 컨테이너 구조로 구현할 수 있었다. ## 일관된 레이어 이름 - 모든 레이어에 일관된 명명 규칙을 적용했다. - 예를 들어 버튼의 텍스트 레이어를 항상 `Text`로 지정하면, 버튼 크기나 변형을 바꿔도 사용자가 입력한 텍스트가 그대로 유지된다. - 복잡한 컴포넌트에서도 아이콘, 제목, 본문, 링크 등의 사용자 지정 내용이 다른 인스턴스나 변형으로 교체할 때 보존된다. - 일관된 레이어 이름은 단순한 정리 규칙이 아니라 Figma의 오버라이드 동작을 안정적으로 만드는 기반이다. ## 변형으로 컴포넌트 수 줄이기 - 여러 개의 유사한 컴포넌트를 개별적으로 관리하는 대신, 하나의 컴포넌트에 다양한 변형을 정의했다. - 예를 들어 80개의 배지 컴포넌트를 따로 만드는 대신 `type`, `size`, `theme`, 보조 요소 등의 속성을 가진 하나의 Badge 컴포넌트를 구성했다. - 코드 컴포넌트에서 사용하는 속성과 Figma의 변형 속성에 동일한 이름과 개념을 사용해 디자인과 개발 사이의 대응 관계를 명확히 했다. - 여러 컴포넌트에서 반복적으로 사용할 수 있는 변형 이름은 다음과 같다. - `type` - `size` - `theme` - `position` - `breakpoint` - `state` - 변형 패널 자체가 컴포넌트의 가능한 상태와 옵션을 설명하는 문서 역할을 한다. - 최종 키트에는 평균 7개의 변형을 가진 1,430개 컴포넌트가 포함됐다. - 변형을 사용하지 않았다면 컴포넌트 수가 10,000개를 넘었겠지만, 변형 덕분에 실제 코드 컴포넌트 수인 약 400개에 가까운 수준으로 관리할 수 있었다. ## 실용적인 결론 상용 Figma 키트를 만들 때는 화면을 예쁘게 복제하는 것보다 코드와 디자인의 구조를 일치시키는 일이 중요하다. 레이어 이름과 변형 속성을 처음부터 표준화하고, 반복되는 레이아웃 규칙을 컴포넌트 구조에 반영하면 사용자는 더 쉽게 커스터마이즈할 수 있고 디자인·개발 간 협업도 효율적으로 유지할 수 있다.

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

드롭박스의 일하는 방식 리

코로나19로 Dropbox는 사무실 중심 문화를 버리고 ‘virtual-first’ 업무 모델로 전환하면서, 온라인에서 협업과 창의성을 재현하는 방식을 다시 설계했다. 디자인팀은 Figma를 단순한 디자인 도구가 아니라 브레인스토밍, 리뷰, 핸드오프, 부서 간 커뮤니케이션이 이루어지는 업무의 중심 공간으로 활용했다. 또한 Figma 사용법을 전사적으로 교육해 디자인 외 조직까지 시각적 협업에 참여하도록 만들었다. ## 사무실 중심 문화에서 virtual-first로 - Dropbox는 12개 글로벌 오피스에 Maker Room과 협업 공간을 운영하며 대면 창의성을 업무 문화의 핵심으로 삼고 있었다. - 디자인팀은 포스트잇, 마커, 장난감 등을 활용해 디자인 스프린트와 즉석 브레인스토밍을 진행했다. - 원격근무에서는 우연히 만나 아이디어를 주고받거나 같은 공간에서 자연스럽게 몰입하는 일이 어려워졌다. - 따라서 기존의 물리적 협업 방식을 온라인 환경에 맞게 의도적으로 재설계해야 했다. ## Figma를 활용한 원격 협업 - Dropbox 디자인팀은 2018년 Sketch에서 Figma로 전환한 덕분에 브레인스토밍, 와이어프레임, 프로토타이핑, 댓글 작성 등 원격 협업의 기반을 이미 갖추고 있었다. - 대면 디자인 리뷰 대신 Figma의 **관찰 모드(Observation mode)** 를 사용해 발표자의 화면을 실시간으로 따라갔다. - 디자이너들은 책상 옆에서 함께 작업하는 대신 Figma 링크를 공유하고 같은 파일에 들어가 아이디어를 빠르게 수정했다. - 엔지니어와 PM도 Figma 기반 디자인 스프린트에 참여하면서 부서 간 협업이 쉬워졌다. - 디자인 파일 자체가 결과물뿐 아니라 논의와 의사결정이 기록되는 커뮤니케이션 공간이 되었다. ## 비동기 핸드오프로 커뮤니케이션 단순화 - Design System 팀과 Brand Studio 팀은 아이콘 전달 과정을 Figma 템플릿으로 표준화했다. - 브랜드 디자이너가 아이콘 작업을 완료하면 해당 페이지에 체크 표시를 남긴다. - 디자인 시스템 팀은 매주 월요일 파일을 확인해 새 아이콘을 마스터 라이브러리에 반영하고 게시한다. - 별도의 반복적인 메시지나 진행 상황 확인 없이 파일 상태만으로 업무 진행 여부를 알 수 있게 되었다. - 이 방식은 다른 협업 라이브러리에도 적용할 수 있는 효율적인 비동기 프로세스로 평가됐다. ## Figma를 전사 협업 도구로 확장 - 디자인팀은 다른 부서가 Figma를 사용할 수 있도록 댓글, 내보내기, 화면 보기 및 따라가기 기능을 중심으로 워크숍을 진행했다. - 워크숍에는 마케팅, 리서치, 데이터 사이언스 등 200명 이상의 구성원이 참여했다. - 교육의 목적은 원격 환경에서도 실제 사무실의 화이트보드처럼 함께 보고, 말하고, 아이디어를 발전시키게 하는 것이었다. - 디자인 외 조직도 Figma에서 다음과 같이 활용하기 시작했다. - QA: 디자인 플로우를 복제해 테스트 계획과 테스트 케이스 작성 - 디자인 리서치: 설문 데이터와 정성적 인사이트를 나란히 배치해 발표 - 여러 조직: 프레젠테이션 공동 제작 - 그 결과 Figma는 Dropbox 전체 구성원이 시각적으로 소통하고 공동 작업하는 공용 공간으로 자리 잡았다. ## 실용적인 시사점 원격 협업을 정착시키려면 기존 대면 업무를 화상회의로 단순히 옮기는 데 그치지 말고, 협업 산출물·상태·의사결정을 하나의 공유 공간에 남기는 방식으로 프로세스를 재설계해야 한다. 특히 명확한 템플릿, 상태 표시, 비동기 핸드오프 규칙을 마련하고 비디자이너까지 도구 교육에 참여시키는 것이 효과적이다.

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

기능 비하인드: 새로운

Figma의 새 Auto Layout은 수동으로 요소 크기와 간격을 조정하던 작업을 자동화하면서도, CSS Flexbox의 강력함을 그대로 복잡하게 노출하지 않는 방향으로 설계됐다. 핵심 원칙은 “Flexbox의 신중한 부분집합”으로, 코드와 디자인의 정렬을 돕되 누구나 쉽게 이해하고 사용할 수 있게 만드는 것이었다. 새 버전은 사용자 피드백을 바탕으로 유연성과 기능을 확장한 결과다. ## 수동 리사이징 문제에서 출발한 Auto Layout - Auto Layout 출시 전에는 버튼의 텍스트가 길어지면 다음 작업을 직접 해야 했다. - 버튼 크기 조정 - 주변 버튼 위치 이동 - 대화상자 컨테이너 크기 조정 - 패딩과 간격 재조정 - 이런 수작업은 단순히 번거로운 것을 넘어 반응형 디자인 시스템 구축의 장애물이 됐다. - Figma 초기 설계에도 프레임 내부 객체를 자동으로 배치하는 아이디어가 있었지만, 제품 출시 당시에는 구현되지 않았다. - 2018년 Maker Week에서 제품 디렉터 Sho가 초기 아이디어를 다시 프로토타입으로 발전시켰고, 이후 전담 팀이 Auto Layout을 실제 기능으로 구현하기 시작했다. ## Flexbox를 참고하되 단순하게 설계 - 팀은 웹 기술인 CSS Flexbox의 강력함과 범용성에서 영감을 얻었다. - 디자인과 코드 사이의 개념적 일치를 높이려면 Flexbox와 유사한 모델이 유리했다. - 그러나 사용자가 브라우저와 CSS를 깊이 이해해야 한다면 Figma의 접근성이 떨어질 수 있었다. - 이에 따라 “Auto Layout은 Flexbox의 신중한 부분집합이어야 한다”는 설계 원칙을 세웠다. - 이 원칙은 기능을 추가하면서도 설정 항목과 동작 규칙을 불필요하게 복잡하게 만들지 않도록 팀의 의사결정을 이끌었다. ## 첫 번째 Auto Layout의 핵심 개념 - 프레임에 Auto Layout을 적용하면 내부 요소를 수직 또는 수평으로 배치할 수 있다. - 요소 사이의 수직·수평 간격을 지정할 수 있다. - Auto Layout 프레임은 기본적으로 주축 방향에서 내부 컴포넌트 크기에 맞춰 늘어나거나 줄어든다. - 반대축 방향도 고정 너비 또는 내부 콘텐츠에 맞추는 방식으로 설정할 수 있다. - 프레임 내부의 각 컴포넌트는 컨테이너 기준으로 개별 정렬할 수 있다. - 수직 레이아웃에서는 좌·중앙·우 정렬 - 수평 레이아웃에서는 상·중앙·하 정렬 ## HTML 프로토타입과 초기 검증 - Auto Layout 디자이너 Marcin은 처음부터 HTML로 프로토타입을 제작했다. - 실제 웹 환경과 유사한 프로토타입을 통해 기능의 사용감과 동작을 조기에 확인할 수 있었다. - 이 과정에서 다음과 같은 세부 동작을 구체화했다. - 프레임 핸들의 시각적 장식 - 객체를 드래그할 때의 동작 - Auto Layout 프레임의 외곽선 표시 - 초기 프로토타입은 기능 목록을 정하는 데 그치지 않고, 편집기에서 사용자가 기능을 어떻게 인식하고 조작할지 검증하는 역할을 했다. ## 기능 확장과 사용성 사이의 균형 - 초기 Auto Layout은 접근성과 직관성을 우선해 설계됐다. - 이후 사용자 피드백을 반영하면서 더 강력하고 유연한 레이아웃 기능을 추가했다. - 다만 유연성을 높일수록 설정과 예외 상황이 늘어나 사용성이 떨어질 수 있으므로, 기능의 범위를 의도적으로 제한했다. - 새 버전은 단순한 UI 변경이 아니라, 초기의 단순한 모델을 유지하면서 더 다양한 반응형 레이아웃 요구를 수용하려는 설계 개선이다. Auto Layout을 설계할 때는 Flexbox처럼 검증된 레이아웃 모델을 참고하되, 사용자가 모든 내부 규칙을 학습하지 않아도 되도록 핵심 개념만 제공하는 것이 중요하다. 또한 실제 편집 환경을 반영한 프로토타입과 사용자 피드백을 통해 기능의 유연성과 조작의 직관성을 함께 검증해야 한다.

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

Variants로 디자인과 코드의

Figma의 Variants는 하나의 컴포넌트에 존재하는 여러 변형을 하나의 컴포넌트 세트로 묶어 디자인 시스템과 코드의 구조를 가깝게 연결한다. 디자이너는 관련 변형을 쉽게 탐색·관리하고, 개발자는 상태·스타일·크기 같은 속성을 코드의 컴포넌트처럼 이해할 수 있다. Figma는 사용자 관찰과 6주간 4차례의 사용성 테스트를 통해 기능 구조와 UI, 명칭을 다듬었다. ## 디자인과 코드의 사고방식 맞추기 - 개발은 재사용성과 확장성을 중시하고, 디자인은 자유로운 반복과 탐색을 중시한다. - 기존 Figma 컴포넌트는 관련 변형을 찾거나 전환하기 어려웠고, 인스턴스 교체 메뉴가 지나치게 복잡해지는 문제가 있었다. - 디자인 시스템이 커지면서 팀들은 `default/primary/large/icon` 같은 슬래시 기반 이름 규칙을 사용해 상태와 속성을 표현했다. - Variants는 이를 `state="hover"`, `style="secondary"`처럼 **속성명:값** 구조로 발전시킨다. - 상태뿐 아니라 `type`, `color`, `size` 등 여러 차원의 속성을 지원해 코드의 컴포넌트 모델과 더 유사하게 구성할 수 있다. ## 변형을 한곳에 모으는 컴포넌트 세트 - Figma는 디자인 시스템 관리자가 변형들을 그리드에 배치하고 나란히 비교한다는 점을 관찰했다. - 이에 따라 하나의 컴포넌트에 속한 여러 Variants를 캔버스에 side-by-side로 배치할 수 있도록 설계했다. - 이 방식은 다음 작업에 유용하다. - 변형 간 시각적 비교 - 디자인 반복 작업 - 라이브러리 유지보수 - 전체 디자인 시스템 구조 파악 - 기존 컴포넌트 변형들을 모두 선택한 뒤 **Combine Variants**를 클릭하면 하나의 컴포넌트 세트로 쉽게 전환할 수 있다. ## 사용성 테스트로 다듬은 UI - Figma는 작동하는 프로토타입을 제작하고 6주 동안 네 차례 사용성 테스트를 진행했다. - 초기 UI는 모든 속성값을 pill 형태로 표시했다. - 하지만 pill은 일반적으로 여러 태그를 동시에 표시하는 요소로 인식되기 때문에, 사용자는 특정 변형의 속성을 조정하는 UI로 이해하기 어려워했다. - 최종적으로는 다음과 같이 변경했다. - 특정 Variant를 선택했을 때는 각 속성을 간단한 입력 필드와 드롭다운으로 표시 - 전체 컴포넌트 세트의 속성과 값을 한눈에 볼 때는 pill UI 유지 - 기본 속성명도 `State`, `Style`처럼 미리 정해진 용어보다 `Property 1`, `Property 2`를 사용했다. - 사용자가 이를 `Type`, `Size` 등 자신의 디자인 시스템에 맞는 이름으로 직접 커스터마이즈하도록 한 것이다. ## 기능 이름을 ‘States’에서 ‘Variants’로 변경 - 초기에는 주요 사용 사례가 버튼의 hover, active, disabled 같은 인터랙션 상태였기 때문에 기능명을 **States**로 정했다. - 그러나 사용자들은 이 이름이 기능을 상태 관리에만 한정하는 것처럼 보인다고 지적했다. - Variants는 상태뿐 아니라 색상, 크기, 유형 등 다양한 속성 조합을 표현할 수 있다. - Fidelity Investments의 피드백을 계기로 기능의 전체 범위를 더 잘 드러내는 **Variants**라는 이름을 채택했다. - 이후 사용성 테스트에서도 Variants가 기능의 목적과 확장성을 더 직관적으로 전달하는 것으로 검증됐다. ## 디자인-개발 협업을 위한 확장 - Variants는 컴포넌트의 구조를 코드와 유사하게 만들어 디자이너와 개발자가 같은 개념으로 대화하도록 돕는다. - Auto Layout 업데이트와 Inspect 패널 개선도 함께 제공되어 디자인을 구현으로 전달하는 과정이 간결해진다. - 단순한 상태 관리부터 여러 속성을 조합한 복잡한 디자인 시스템까지 동일한 방식으로 관리할 수 있다. 실무에서는 버튼, 입력창, 카드처럼 상태·크기·스타일 변형이 많은 컴포넌트부터 Variants로 통합하는 것이 효과적이다. 속성명은 팀의 코드 규칙과 일치시키고, 변형을 체계적인 속성-값 조합으로 정의하면 디자인 시스템 유지보수와 개발 협업을 모두 개선할 수 있다.

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

킴벌리클라크가 사랑

Kimberly-Clark은 변화하는 소비자 선호와 경쟁 심화에 대응하기 위해 디지털 경험과 디자인 업무 방식을 혁신했다. Figma를 단일 협업 플랫폼으로 도입하면서 디자이너, 마케팅, 브랜드, 개발자 간 협업이 빨라졌고, 실제로 한 웹사이트의 가입률을 71% 높였다. 이 사례는 디자인 도구 통합과 실시간 협업이 제품 출시 속도와 사용자 경험을 동시에 개선할 수 있음을 보여준다. ## 디지털 중심 성장 전략 - Kleenex, Scott, Huggies 등을 보유한 Kimberly-Clark은 전 세계 175개국에서 사업을 운영한다. - 400개 이상의 소비자 대상 웹사이트와 다양한 디지털 제품을 관리하고 있다. - 소비자 취향 변화, 경쟁 심화, 생산비 증가로 성장세가 둔화되자 2022년 창립 150주년을 목표로 성장 가속화 전략을 추진했다. - 가격 책정, 제조, 유통, 진열, 영업, 인사 등 거의 모든 업무 과정에 디지털 요소가 포함되어 있었다. - 코로나19 이후에는 수요 변화에 맞춰 생산량과 재고를 재배분했으며, 해당 분기 매출은 46억 1천만 달러를 기록했다. ## 기존 디자인 프로세스의 비효율 - 디자이너들이 독점적인 Mac 기반 애플리케이션에서 혼자 수주일 동안 작업했다. - 완성한 파일을 별도의 클라우드 프로토타이핑 도구에 업로드한 뒤 이해관계자의 피드백을 기다려야 했다. - 수정이 발생하면 같은 과정을 반복해야 했다. - 개발 단계에서는 Mac을 사용하지 않는 개발자에게 디자인 파일을 전달하는 과정에서 추가적인 문제가 생겼다. - 여러 브랜드와 국가에 맞춰 디자인을 현지화해야 했기 때문에, 이러한 단절이 제품 출시 속도를 더욱 늦췄다. ## Figma를 통한 실시간 협업 - Figma를 도입해 디자인, 프로토타이핑, 피드백 과정을 하나의 웹 기반 플랫폼으로 통합했다. - 파일을 로컬에 저장할 필요가 없고, 초대받은 사람이 쉽게 파일을 열어 보고 편집할 수 있었다. - Figma를 모든 팀이 참조하는 단일 정보원으로 활용하면서 파일 버전 관리와 전달 과정이 단순해졌다. - 피드백 회의가 일방적인 검토 자리가 아니라 브랜드·마케팅·디자인·기타 이해관계자가 함께 작업하는 실시간 협업 세션으로 바뀌었다. - 참여자들이 디자인 변경 사항을 즉시 확인하고 제작 과정에 직접 참여할 수 있게 되었다. ## 데이터로 검증한 디자인 개선 - 팀은 디자인 효율성뿐 아니라 실제 사용자 경험의 개선 여부도 측정했다. - 주요 지표로 이탈률, 재방문자, 사이트 체류 시간, 쿠폰·뉴스레터·보상 프로그램 가입률 등을 추적했다. - 한 웹사이트의 가입 양식에는 마케팅 목적으로 13개의 입력 필드가 포함되어 있었다. - 브랜드, 마케팅, 디자인 팀이 Figma에서 함께 논의해 입력 필드를 5개로 줄였다. - 양식 변경 후 가입률이 71% 증가했다. - 회의에서 장시간 논쟁하기보다 문제를 함께 시각화하고 즉시 수정한 것이 성과 향상에 기여했다. ## 다음 단계: 디자인 시스템과 개발 연계 - Kimberly-Clark은 Figma에서 Storybook과 코드 저장소까지 연결되는 새로운 디자인 시스템을 계획했다. - 이를 통해 디자인 요소와 개발 구현 사이의 일관성을 높이고, 여러 브랜드와 지역에 적용 가능한 재사용 체계를 구축하려 했다. - 디자인을 단순한 산출물 제작 과정이 아니라 비즈니스 성과와 제품 출시 속도를 높이는 핵심 업무로 자리매김하려는 방향이다. 실무적으로는 디자인 도구를 많이 사용하는 것보다, 하나의 공유 환경에서 관련 팀이 함께 문제를 해결하고 결과를 사용자 지표로 검증하는 것이 중요하다. 특히 입력 단계 축소처럼 작은 디자인 변경도 데이터로 효과를 확인하면 빠른 개선과 조직 내 합의를 동시에 이끌어낼 수 있다.

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

팀으로 배우고 실패하기 |

Config Europe의 발표들은 더 나은 제품을 만드는 일과 더 나은 팀원이 되는 일이 서로 연결되어 있음을 보여준다. 핵심은 디자인·개발·기획 등 다양한 구성원을 과정에 참여시키고, 실패를 숨기기보다 함께 학습하고 개선하는 문화다. Figma의 Variants 사례처럼 반복적인 테스트와 피드백은 제품의 접근성과 완성도를 높인다. ## 팀의 경계를 넓히는 디자인 시스템 - UAL의 Declan Talbert는 디자인 시스템을 단순한 패턴 라이브러리나 디자이너 전용 도구가 아니라 **서비스**로 바라봐야 한다고 설명한다. - 디자인 시스템에는 UI 컴포넌트뿐 아니라 접근성, 데이터, 프로젝트 관리 등 다양한 요소가 포함될 수 있다. - 디자이너, 개발자, 제품 관리자 등 여러 직군이 기여하고 사용할 수 있어야 시스템이 더 포용적으로 작동한다. - 다양한 전문성과 관점을 가진 사람을 디자인 프로세스에 참여시키면 인간 중심적인 제품과 서비스로 이어진다. - 개방적인 프로세스는 도구의 공유를 넘어, 기존 디자인 조직 밖의 사람들도 의사결정과 제작 과정에 참여하도록 만드는 것을 의미한다. ## 실패를 함께 받아들이기 - Figma의 제품 관리자 Kelsey Whelan과 제품 디자이너 Nikolas Klein은 다양한 관점이 더 나은 제품을 만든다고 강조한다. - 이 과정에서는 서로 앞에서 아이디어가 실패하는 상황도 발생하지만, 실패를 공동의 학습 기회로 바라보는 태도가 중요하다. - Variants 초기 버전은 기능적으로 강력했지만 사용자에게 충분히 직관적이지 않았다. - 팀은 몇 주 동안 짧게 사용성 테스트를 진행하려 했지만, 실제로는 6주 동안 네 차례의 테스트가 필요했다. - 이를 통해 팀은 제품이 예상보다 훨씬 사용자에게서 멀리 떨어져 있다는 사실을 발견했다. ## 원격 환경에서 확장한 사용성 테스트 - Figma는 원격 근무 환경을 활용해 제품에 직접 관여한 사람뿐 아니라 회사 전체 구성원을 테스트에 참여시켰다. - 디자이너 애드보케이트, 제품 교육 담당자, 엔지니어링 매니저 등 다양한 직군이 Zoom을 통해 사용성 테스트에 참여했다. - 테스트 과정에서 버그도 발견했으며, 전용 Slack 채널에서 문제와 수정 방안을 즉시 논의했다. - 아이디어가 작동하지 않는 모습을 공개적으로 확인하는 일은 어렵지만, 피드백을 반영해 사용성이 개선되는 과정은 더 큰 보람으로 이어졌다. - 다양한 참여자는 사용자 경험을 개선하는 동시에 팀 내부의 개방성과 협업도 강화했다. ## 실패를 ‘앞으로 나아가는 과정’으로 만들기 - 실패는 비난의 근거가 아니라 개선과 반복을 위한 정보로 활용되어야 한다. - 여러 사람이 초기 결과물을 함께 검토하면 문제를 더 일찍 발견하고, 특정 직군의 편견이나 사각지대를 줄일 수 있다. - 중요한 것은 실패하지 않는 것이 아니라, 실패를 공유하고 피드백을 반영해 다음 단계로 발전하는 것이다. - 이러한 문화가 자리 잡으면 팀원들은 실험과 의견 제시에 더 적극적으로 참여할 수 있다. 제품 개발에서는 디자인 시스템과 테스트 과정을 특정 팀의 전유물로 두기보다 다양한 직군에 개방하는 것이 좋다. 초기 결과가 미흡하더라도 이를 숨기지 말고, 반복적인 사용성 테스트와 명확한 피드백 채널을 통해 팀 전체가 함께 개선하는 구조를 마련해야 한다.

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

Figma의 에이전시 파

Figma는 디자인 시스템의 구축·이전·확장을 지원하기 위해 전문 디자인·디지털 에이전시들과 파트너십을 맺었다. 디자인 시스템은 단순한 UI 패턴 모음이 아니라 디자인과 코드가 공유하는 언어이자 조직의 단일 진실 공급원이며, 에이전시 파트너는 이를 실제 업무 프로세스와 브랜드 전략에 연결한다. 이를 통해 조직은 협업의 일관성, 효율성, 개발·디자인 간 소통을 강화할 수 있다. ## 디자인 시스템의 역할 - 디자인 시스템은 패턴 라이브러리나 스티커 시트에 그치지 않고, 디자인과 코드 양쪽을 아우르는 **공유 언어**다. - 자유로운 디자인 탐색과 코드의 구조·엄격성을 동시에 지원한다. - 팀 전체의 작업 속도와 효율성을 높이고, 일관된 결과물을 만들도록 돕는다. - 조직 내에서 디자인과 브랜드 관련 의사결정의 **단일 진실 공급원(single source of truth)** 역할을 한다. - 다만 기존 도구에서 시스템을 이전하거나, 구조를 설계하고, 규모에 맞게 운영하는 일은 복잡할 수 있다. ## Figma 에이전시 파트너가 제공하는 지원 파트너들은 다양한 규모와 산업의 조직을 대상으로 디자인 시스템의 도입부터 운영 확장까지 지원한다. ### 디자인 시스템 구축 및 이전 - 기존 디자인 도구 스택을 Figma로 이전할 수 있도록 지원한다. - 이미 Figma를 사용하는 팀에도 브랜드와 조직 특성에 맞는 파일·컴포넌트·라이브러리 구조를 제안한다. - 디자인 시스템을 처음 구축하거나 기존 시스템을 재정비할 때 실무적인 모범 사례를 제공한다. - 조직의 규모와 팀 구성에 맞춰 시스템의 기반을 설계한다. ### 프로세스와 워크플로 개선 - 디자인 시스템은 구축 이후의 유지·관리 방식도 중요하므로 운영 원칙과 프로세스를 수립한다. - 팀이 시스템을 어떻게 사용하고 업데이트할지에 대한 가이드라인을 제시한다. - 디자인과 개발 사이의 협업 프레임워크를 마련한다. - 도구나 팀 간 커뮤니케이션에서 발생하는 불일치와 비효율을 줄인다. - 디자인이 조직의 전략적 파트너로 기능할 수 있도록 업무 흐름을 개선한다. ### 브랜드 정의와 확장 - 디자인 시스템을 브랜드의 시각적·경험적 표현과 연결한다. - 컴포넌트 구조나 구현 방식뿐 아니라 브랜드를 제품과 서비스에 반영하는 전략도 지원한다. - 여러 브랜드나 제품군으로 확장할 때 일관성을 유지하도록 돕는다. - 디자인 시스템을 통해 조직 구성원이 브랜드를 동일한 방향으로 해석하고 실행하도록 한다. ## 파트너십이 강조하는 협업 방식 - Figma의 실시간 협업 환경을 활용해 에이전시와 고객이 같은 작업 공간에서 공동 제작할 수 있다. - BASIC®은 Figma가 고객과의 공동 창작을 빠르고 쉽게 만들며, 협업·효율성·조직화의 잠재력을 높였다고 평가했다. - Idean은 여러 도구와 팀 사이의 커뮤니케이션 단절이 불일치와 비효율을 만든다고 설명하며, Figma가 고객과 에이전시를 같은 화면에 연결한다고 강조했다. - 결과적으로 투명성, 협업 속도, 의사결정의 집중도가 높아진다. ## Figma의 초기 에이전시 파트너 Figma는 당시 세계적인 디자인·디지털 에이전시 8곳과 파트너십을 발표했다. - BASIC® - frog - HUGE - Idean - One North - R/GA - The(stylized agency logo in the article) - Work & Co BASIC®의 사례로는 Herman Miller와 함께 여러 브랜드에 걸쳐 확장 가능한 디자인 시스템을 구축한 프로젝트가 소개된다. 이들 파트너는 브랜딩, 디지털 제품, 전자상거래, 서비스 디자인 등 다양한 분야의 경험을 바탕으로 Figma 활용을 지원한다. 실무적으로는 디자인 시스템을 단순히 만들어 두는 것보다 구조, 운영 원칙, 디자인·개발 협업 방식, 브랜드 확장 전략을 함께 설계하는 것이 중요하다. 다만 글은 2020년 자료이므로, 현재 이용 가능한 파트너와 서비스 범위는 최신 Figma Service Partners 페이지에서 확인해야 한다.

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

연결의 순간 만들기 | Figma

디자인은 기능과 완성도만 높이는 일이 아니라, 사람과 조직을 연결하고 의미 있는 경험을 만드는 일이다. Config Europe의 사례들은 사용자 여정을 전체적으로 바라보고, 개인의 성품과 진정성을 브랜드에 반영하며, 기술을 통해 소속감과 인간적 연결을 강화해야 한다고 말한다. 결국 전문성을 갈고닦는 동시에 인간다움을 함께 발전시키는 것이 중요하다. ## 조직 전체를 바꾸는 사용자 경험 - 핀란드 우편 기업 Posti Group은 디지털 청구서와 편지의 확산에 대응해 단순히 새 앱을 만드는 데 그치지 않고, 수백 년 된 조직의 고객 경험 전체를 현대화하려 했다. - 이를 위해 디자인을 중심에 두고 다음 네 가지 원칙을 세웠다. - **성장(Grow):** 변화하는 사용자의 요구에 맞춰 발전한다. - **감동(Delight):** 실망스러운 경험을 긍정적인 경험으로 전환한다. - **감소(Reduce):** 안정적이고 신뢰할 수 있는 서비스를 제공한다. - **경청(Listen):** 고객이 자신의 필요를 직접 표현할 수 있게 한다. - 특정 산출물이나 디지털 접점 하나가 아니라, 고객이 서비스를 이용하는 전체 여정을 통합적으로 바라보는 접근이다. - 우편 서비스는 효율적인 기능을 제공하지만, 실제로는 사랑의 편지, 세금 고지서, 신생아의 사회보장 카드처럼 사람들의 중요한 감정과 사건을 전달한다. - 따라서 디자인은 서비스의 기능뿐 아니라 그 서비스가 사람들의 삶에서 어떤 의미를 만들어내는지도 고려해야 한다. ## 기술보다 중요한 디자이너의 성품 - ConvertKit의 Charli Marie Prangley는 디자이너의 평판이 뛰어난 랜딩 페이지나 아름다운 로고를 만드는 능력만으로 결정되지 않는다고 설명한다. - 개인의 브랜드는 다음 두 요소로 구성된다. - 디자이너로서의 **기술과 전문성** - 어떤 사람인지 보여주는 **성품과 태도** - 고객을 확보하거나 좋은 직장을 얻고 커뮤니티에서 신뢰를 쌓으려면, 사람들이 자신을 어떤 사람으로 기억하길 원하는지 먼저 생각해야 한다. - 창의적이고 친절하며 재미있는 사람인지 등 자신의 가치와 성격을 정의하면, 온라인 활동과 작업물이 실제 자신을 제대로 반영하는지 점검할 수 있다. - 다른 사람을 모방하기보다 자신의 관점과 개성을 진정성 있게 드러내는 것이 중요하다. 진솔한 관점을 가치 있게 여기는 사람은 반드시 존재한다. ## 기능과 감정을 함께 설계하기 - Ueno의 Halli Thorleifsson은 웹사이트나 앱을 단순한 기능적 산출물로 보지 말고, 의미 있는 목적을 가진 작업으로 바라봐야 한다고 강조한다. - 중요한 것은 도구나 디자인 시스템 자체가 아니라, 그것을 사용해 무엇을 만들고 왜 만드는가이다. - 좋은 도구는 팀의 협업을 돕는 데서 끝나지 않고, 사람 사이의 연결과 공동체 의식을 가능하게 해야 한다. - 원격 근무가 확산된 상황에서는 기술이 사람들을 고립시키는 것이 아니라 서로 연결하고 소속감을 느끼게 하는 방향으로 사용되어야 한다. - 디자인의 결과물에는 기능뿐 아니라 감정, 의미, 인간적인 경험이 함께 담겨야 한다. ## Config Europe가 보여준 연결의 가치 - Figma의 첫 가상 사용자 콘퍼런스인 Config Europe에는 150개국에서 약 1만 명이 참여했다. - 참가자들은 온라인 네트워킹, 채팅, Friends of Figma 그룹 등을 통해 발표 내용을 배우는 것뿐 아니라 서로 관계를 형성했다. - 글은 콘퍼런스의 가장 중요한 성과가 새로운 디자인 지식보다 커뮤니티 안에서 만들어진 연결일 수 있다고 말한다. - Halli의 결론은 다음과 같다. - 자신의 전문 기술을 끊임없이 연마할 것 - 동시에 인간다움과 타인과의 관계를 발전시킬 것 일과 제품을 설계할 때 기능적 목표만 세우지 말고, 그것이 사용자와 팀, 커뮤니티에 어떤 감정과 연결을 만들어내는지 함께 정의하는 것이 좋다. 전문성은 신뢰를 만들지만, 진정성과 인간적인 태도는 사람들이 오래 기억하는 관계를 만든다.

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

피그마 내부 이야기: 신입

Josh Shi는 대학 졸업 후 Figma에 입사한 경험을 바탕으로, 취업을 “좋은 회사의 조건을 체크하는 일”이 아니라 자신과 일의 관계를 탐구하는 과정으로 바라보자고 말한다. 특히 일과 삶을 서로 상쇄되는 두 영역으로 보지 말고, 함께 삶을 구성하며 서로 영향을 주는 요소로 이해해야 한다고 강조한다. 신입 엔지니어에게는 회사의 명성보다 자신의 관심사·성장 방식·가치관이 실제 업무 환경과 맞는지를 질문하라고 조언한다. ## 정답이 아닌 질문으로 취업을 바라보기 - 저자는 대학 졸업 당시 Figma를 선택한 이유를 완벽하게 설명할 수 없었다고 고백한다. - 면접에서 만난 사람들이 친절하고 사려 깊으며, 자신을 한 사람으로 이해하려는 태도를 보였던 점이 인상적이었다. - “흥미로운 문제”, “똑똑한 동료”, “좋은 문화” 같은 일반적인 평가 기준만으로는 개인에게 의미 있는 직장을 판단하기 어렵다. - 회사 선택에서 중요한 것은 정해진 체크리스트보다 다음과 같은 자기 성찰이다. - 어떤 종류의 일에 관심이 있는가? - 회사가 그 관심사를 발전시킬 기회를 제공하는가? - 관심사가 바뀌었을 때 업무나 역할도 변화할 수 있는가? - 어떤 기술과 전문성을 쌓을 수 있는가? - 일이 직장 밖의 다른 관심사와 삶의 방향에도 어떤 영향을 주는가? ## ‘일과 삶의 균형’이라는 단순한 프레임의 한계 - 일과 삶을 시소의 양쪽처럼 보는 전통적인 “work-life balance” 개념은 지나치게 단순하다. - 일과 비업무 시간은 서로 독립된 영역이 아니라, 합쳐져 한 사람의 삶을 구성한다. - 업무 만족도는 개인 생활의 만족도에 영향을 주고, 반대로 삶의 상태도 업무 경험에 영향을 준다. - 단순히 근무 시간을 줄이거나 일정한 시간 비율을 맞춘다고 해서 올바른 균형이 만들어지는 것은 아니다. - 사람마다 일에 자신의 정체성을 얼마나 연결할지는 다르며, 어느 한 방식이 정답은 아니다. - 저자는 일과 삶을 어떻게 배치해야 자신이 원하는 방식으로 살 수 있는지 질문해야 한다고 말한다. - 다만 모든 사람이 업무 환경을 자유롭게 선택할 수 있는 것은 아니다. 생계와 고용 안정성이 우선인 상황에서는 일을 커리어의 일부로 바라볼 여유가 제한될 수 있다. ## 신입으로서 얻은 기술적·실무적 성장 - Figma에서 새로운 기술 경험을 쌓았다. - 풀스택 개발을 경험했다. - 웹 환경에서 C++를 사용하는 업무를 접했다. - 단순히 코드를 작성하는 것을 넘어 기능을 실제로 소유하고 제품 개발 과정에 참여했다. - 다음과 같은 제품 개발 역량을 배웠다. - 기능과 제품의 범위를 현실적으로 정하기 - 모호한 목표를 구체화하기 - 아이디어를 처음부터 출시까지 발전시키기 - 제품을 신중하게 설계하고 구현하기 - 신입 개발자에게 기술 스택보다 중요한 성장 요소는 기능의 전체 생명주기를 경험하고 결과에 책임지는 것이라고 볼 수 있다. ## 멘토와 조직 환경의 영향 - 저자의 성장에는 주변 동료들의 지원과 지도가 결정적인 역할을 했다. - 동료들은 의도적으로 멘토 역할을 하지 않았더라도, 도전할 기회와 업무 소유권을 제공하며 성장을 도왔다. - 면접 당시 함께 식사했던 동료들 중 상당수가 계속 Figma에 남아 있었고, 저자는 그들의 경험과 관대함으로부터 지속적으로 도움을 받았다. - 신입이 회사를 평가할 때는 공식적인 복지나 문화 설명뿐 아니라 다음 요소도 살펴볼 필요가 있다. - 질문하고 도움을 요청하기 쉬운가 - 신입에게 실제 책임과 소유권을 주는가 - 동료들이 지식을 공유하는가 - 새로운 역할이나 기술을 시도할 수 있는가 ## 회사와 역할은 계속 변한다 - 저자가 입사한 뒤 Figma는 회사와 제품 모두 크게 성장했다. - 입사 당시와 현재의 조직 환경은 달라졌으며, 회사는 하이브리드 모델로 전환하기 시작했다. - 따라서 취업 선택은 고정된 조건을 고르는 일이 아니라, 변화하는 회사 안에서 자신의 관심과 역할이 어떻게 발전할 수 있는지를 판단하는 일이다. - 좋은 직장은 처음부터 모든 조건이 완벽한 곳이라기보다, 개인의 성장과 변화에 맞춰 역할을 확장하거나 조정할 수 있는 환경일 수 있다. 취업을 준비하는 신입 개발자는 회사의 유명세나 기술 목록만 비교하기보다, 자신이 배우고 싶은 방식과 일의 의미를 먼저 정리하는 것이 좋다. 면접에서는 업무 내용뿐 아니라 멘토링, 기능 소유권, 역할 변화 가능성, 조직의 성장 방향을 구체적으로 질문하는 것이 실용적이다.

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