Figma

532 개의 포스트

figma3분 읽기큐레이션 요약

플러그인 비하인드

Yitong Zhang은 Coinbase에서 디자이너가 단순히 PRD를 실행하는 역할을 넘어 제품 전략과 문제 정의에 참여해야 한다고 강조한다. 그는 Figma API를 활용해 두 객체를 선으로 연결하는 자동 플로우 플러그인을 개발하며, 디자인 도구와 커뮤니티의 확장 가능성을 보여준다. 앞으로 디자이너는 픽셀 단위 작업보다 시스템 구축, 전략 수립, 브랜드 경쟁력 강화에 더 집중하게 될 것이라고 전망한다. ### 창업 경험에서 출발한 디자인 - Yitong은 처음부터 디자이너였던 것이 아니라, 스타트업 창업자로서 여러 역할을 수행하며 기술 업계에 들어왔다. - 창업이 실패한 뒤 생계를 위해 디자이너가 되었고, 디자인이 유용한 것을 상상하고 실제로 만들어내는 창업의 즐거운 부분과 닮았다고 설명한다. - 과거 좋아하는 애니메이션의 팬아트를 만들며 디자인 도구를 익힌 경험도 디자이너로 전환하는 데 도움이 되었다. ### Figma API로 만드는 자동 플로우 플러그인 - 개발 중인 플러그인은 **Auto Flow**로, Figma 안의 두 객체를 선으로 연결해 플로우 다이어그램을 빠르게 만들 수 있도록 한다. - 사용자가 객체를 직접 배치하고 연결선을 조정하는 반복 작업을 줄이는 것이 목적이다. - Yitong은 Figma API가 강력하고 사용하기 좋으며, Figma가 디자인의 미래라고 생각하기 때문에 Figma 커뮤니티를 위한 도구를 만든다고 말한다. ### Coinbase에서 디자인의 역할 확장 - Yitong이 가장 자랑스럽게 생각하는 성과는 Coinbase에서 디자인 프로세스를 발전시킨 일이다. - 디자인팀이 제품 요구사항(PRD)을 전달받아 실행하는 조직에서 벗어나, 제품 전략을 함께 만드는 동등한 파트너가 되었다. - 이는 디자인을 시각적 결과물 제작이 아니라 문제와 방향을 정의하는 활동으로 확장한 변화다. ### 문제 정의 단계에 참여하는 디자이너 - 좋은 제품은 잘못된 문제 정의에서 나올 수 없으므로, 디자이너가 해결책을 만드는 단계보다 먼저 문제를 정의하는 과정에 참여해야 한다. - 초기 단계부터 참여하면 제품의 영향력과 윤리적 결과까지 고려할 수 있다. - 디자이너가 제품 개발 후반의 실행자에 머물지 않고, 어떤 문제를 해결할지 결정하는 역할을 맡아야 한다는 주장이다. ### 디자인 직무의 미래 - 제품 디자이너의 업무는 세밀한 픽셀 조정에서 시스템 구축과 전략 정의 중심으로 이동할 것으로 전망한다. - 기술 기업이 브랜드를 강력한 경쟁 우위로 인식하면서 브랜드 디자인은 더욱 중요해지고, 제품 디자인과는 별도의 전문 영역으로 발전할 수 있다. - 디자이너에게는 화면 제작 능력뿐 아니라 시스템적 사고와 비즈니스 전략 이해가 요구될 가능성이 커진다. ### 다른 분야에서 얻는 영감 - Yitong은 자신의 분야와 최대한 거리가 먼 영역에서 영감을 얻으려 한다. - 시스템 수준의 디자인 작업을 하면서 건축을 탐구하는 것이 특히 유익했다고 말한다. - 익숙한 디자인 사례만 참고하기보다 건축처럼 구조, 관계, 시스템을 다루는 분야에서 새로운 관점을 얻는 방식이다. 디자이너는 화면을 예쁘게 만드는 역할에만 머무르지 말고, 제품의 문제 정의와 전략 수립 단계부터 참여하는 것이 좋다. 또한 Figma 플러그인처럼 반복 작업을 자동화하는 도구를 직접 만들고, 건축 등 다른 분야의 시스템적 사고를 배우면 디자인의 영향력을 넓힐 수 있다.

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

플러그인 비하인드

티파니 첸은 Microsoft의 접근성과 포용성 팀에서 일하며, Figma 플러그인으로 접근성 주석 작성 과정을 자동화하고 있다. 그녀는 플러그인이 디자이너가 필요한 기능을 직접 만들 수 있게 해 주며, 접근성 향상과 디자인 진입 장벽 완화에 기여한다고 본다. 또한 다양한 전공과 배경을 가진 사람들이 디자인에 참여할수록 더 풍부하고 포용적인 결과를 만들 수 있다고 강조한다. ## 접근성 주석 작업을 자동화하는 플러그인 - 티파니가 개발 중인 플러그인은 **접근성 중심의 주석(annotation) 도구**다. - 디자인에 접근성 관련 정보를 표시하는 수작업을 자동화해 반복적인 작업을 줄이는 것을 목표로 한다. - Microsoft의 내부·외부 접근성 강화 노력과 맞닿아 있으며, 포용적인 제품 경험에 대한 인식을 높이려는 목적이 있다. - 이 프로젝트는 티파니가 처음 만든 Figma 디자인 플러그인이기도 하다. ## Figma 플러그인을 선택한 이유 - 새로운 플러그인 시스템과 Figma API가 사용하기 쉬워 설정이나 디버깅보다 실제 제작에 더 많은 시간을 쓸 수 있었다. - 기존 디자인 도구가 모든 디자이너의 요구를 충족할 수는 없지만, 플러그인을 통해 필요한 기능을 직접 만들 수 있다. - 다른 개발자가 기능을 추가해 주기를 기다리는 대신, 자신과 커뮤니티에 필요한 도구를 직접 제안하고 구현할 수 있다. - Figma 커뮤니티가 친절하고 협력적이라는 점도 개발 동기가 됐다. ## 다양한 배경이 디자인에 주는 가치 - 티파니는 심리학, 인류학, 국제관계, 컴퓨터과학 등 비전통적인 배경을 가진 사람들이 디자인에 진입하는 것을 돕고 싶어 한다. - 다양한 경험과 지식은 디자인 커뮤니티에 새로운 관점과 문제 해결 방식을 제공한다. - 컴퓨터과학 배경 덕분에 디자인을 평가하고 구현할 때 **기술적 실현 가능성**과 **새로운 시도** 사이에서 균형을 잡는 편이라고 설명한다. - 디자인이 특정 전공자만의 영역이 되지 않도록 진입 장벽을 낮추는 것이 중요하다고 본다. ## 기술과 창작을 결합한 작업 - 가장 자랑스러운 프로젝트로 사람들에게 “어릴 때 어떤 거짓말을 들었나요?” 같은 질문을 던지고, 그 답변을 이야기와 일러스트로 발전시킨 작업을 꼽았다. - 참여자들의 경험을 시각화해 아트 디렉션 웹사이트로 제작했다. - 레이어링과 패럴랙스 효과를 활용해 이야기를 입체적으로 표현했다. - 이 프로젝트를 통해 기술적 역량과 창의적 작업을 결합하는 데 흥미를 느끼게 됐다. ## 사회적 영향을 고려하는 기업관 - 티파니는 B Corporation의 원칙에 관심을 보였다. - B Corp 인증 기업은 의사결정 시 노동자, 고객, 공급업체, 환경에 미치는 영향을 함께 고려한다. - Ben & Jerry’s, Kickstarter, Patagonia 등이 대표적인 B Corp 사례로 언급된다. - 이는 제품과 기업 활동이 수익뿐 아니라 사회와 환경에 미치는 영향까지 책임져야 한다는 관점과 연결된다. ## 더 포용적인 디자인 생태계 - 디자인 업계에는 모든 사람을 포괄하는 제품과 경험에 대한 인식이 더 필요하다. - 동시에 디자이너가 되려는 사람들의 진입 장벽도 낮아져야 한다. - 온라인에 공개된 학습 자료가 늘면서 이러한 장벽은 점차 낮아지고 있다. - 단순하면서도 강력한 도구인 Figma와 플러그인 생태계가 이 변화를 더욱 빠르게 만들 수 있다고 기대한다. 접근성을 별도의 사후 작업으로 다루기보다 디자인 과정에 자연스럽게 통합하려면, 반복적인 접근성 검토를 자동화하는 도구를 적극 활용하는 것이 좋다. 또한 디자인 팀은 다양한 전공과 배경의 구성원이 참여할 수 있도록 학습 자료와 제작 도구를 개방하는 방향을 고려할 필요가 있다.

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

플러그인 뒷이야기:

Figma 플러그인은 디자이너가 반복적이고 번거로운 작업을 자동화해 더 의미 있는 디자인 작업에 집중하도록 돕는다. Cloudflare의 UX Engineer Sam Mason de Caires는 번역, 데이터 교체, 테마 생성, 그래프, 색각 이상 대응 등 다양한 플러그인을 만들며 디자인과 개발의 결합 가능성을 보여준다. 그는 앞으로 디자인 도구가 데이터를 바탕으로 여러 디자인 변형을 생성하고, 디자이너가 그중 최선의 결과를 선택하는 방향으로 발전할 것이라고 전망한다. ## 플러그인 생태계의 출발 - Figma는 2019년 플러그인 베타를 시작했고, 첫 고객들이 다양한 도구를 제작했다. - 플러그인의 활용 사례로 데이터 시각화, 콘텐츠 가져오기, 접근성 도구 등이 소개된다. - Figma는 플러그인 제작자들의 동기와 작업물을 소개하는 5부작 인터뷰 시리즈를 진행했다. - Sam Mason de Caires는 Figma 커뮤니티를 위한 초기 플러그인 제작자 중 한 명이다. ## 디자인과 개발의 결합 - Sam은 무언가를 처음부터 만들어 사람들이 실제로 사용하는 모습을 보는 데 매력을 느껴 개발자가 되었다. - 동시에 디자인에도 관심이 있었으며, 디자인과 개발 사이에 큰 교차점이 있다고 보았다. - Cloudflare에서는 개발 역량을 활용해 디자인 프로젝트에 실질적으로 기여하고 있다. - 플러그인 API는 디자인 도구 내부의 코드와 데이터에 접근할 수 있게 해, 개발자가 디자이너를 위한 생산성 도구를 만들 수 있도록 한다. ## 제작 중인 Figma 플러그인 - 번역 플러그인: 디자인 콘텐츠를 여러 언어로 변환하는 작업을 지원한다. - 데이터 교체 플러그인: 화면에 들어간 데이터를 빠르게 다른 값으로 바꿀 수 있다. - 테마 UI 생성기: 테마에 맞는 사용자 인터페이스 요소를 자동으로 생성한다. - 그래프 플러그인: 데이터를 시각적인 그래프로 표현한다. - 색상 참고 플러그인: 색각 이상 사용자가 색상을 어떻게 인식하는지 확인해 접근성을 개선한다. - 이 도구들은 디자이너가 수작업으로 반복하던 작업을 줄이고, 더 빠르고 자신 있게 디자인하도록 돕는 것을 목표로 한다. ## 자동화가 디자이너에게 주는 가치 - 반복 작업을 자동화하면 디자이너가 실제 문제 해결과 시각적 의사결정에 더 많은 시간을 사용할 수 있다. - 플러그인은 단순한 편의 기능을 넘어 디자인 프로세스 자체를 확장하는 수단이 된다. - 개발자는 디자인 도구의 내부 구조와 API를 활용해 디자이너가 직접 만들기 어려운 기능을 제공할 수 있다. - Sam은 개발자의 기술이 커뮤니티에 직접 도움이 되지 않을 것이라고 생각했지만, 플러그인을 만들면서 디자인 생산성과 신뢰도를 높일 수 있음을 깨달았다. ## 생성형 디자인의 미래 - Sam은 향후 5년 동안 생성형 디자인이 크게 발전할 것으로 예상한다. - 디자이너가 가능한 모든 상태를 하나씩 만드는 대신, 원하는 결과를 설명하는 데이터와 조건을 입력하면 도구가 여러 변형을 자동으로 생성한다. - 디자이너의 역할은 모든 결과를 직접 제작하는 것에서 벗어나, 생성된 결과 중 적절한 요소를 선택하고 다듬는 방향으로 이동할 수 있다. - 이는 디자인 도구가 정적인 편집기를 넘어 데이터 기반의 결과 생성 시스템으로 발전할 가능성을 의미한다. ## 커뮤니티에 대한 장기적 기여 - Sam은 디자이너가 더 빠르고 정확하게 작업할 수 있도록 돕는 도구와 프로세스를 계속 만들고 싶다고 밝혔다. - 그는 디자인 커뮤니티의 발전에 개발자도 중요한 방식으로 기여할 수 있다고 본다. - 특히 자동화, 접근성, 콘텐츠 관리처럼 여러 프로젝트에서 반복되는 문제를 플러그인으로 해결할 수 있다. - Sam의 플러그인은 2019년 8월 1일부터 Figma 커뮤니티에 공개될 예정이었다. 플러그인을 활용하면 반복 작업을 줄이고 디자인 품질과 접근성을 함께 높일 수 있다. 디자이너와 개발자는 Figma API를 활용해 팀의 업무 방식에 맞는 자동화 도구를 직접 만들고, 생성된 여러 결과를 사람이 검토·선택하는 협업 방식을 실험해볼 만하다.

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

회고를 위한 Figma

애자일·스크럼 팀의 회고를 Figma에서 진행하면 화이트보드와 포스트잇의 한계를 줄이고, 모든 구성원이 동시에 의견을 작성하고 확인할 수 있다. Figma의 실시간 협업, 댓글, 컴포넌트 기능은 원격 참여를 돕고 팀이 새로운 도구에 자연스럽게 익숙해지도록 한다. 글은 회고용 템플릿을 만들고 공유하는 방법부터 프레임·스티키 노트·브랜드 요소를 활용해 맞춤화하는 방법까지 단계별로 설명한다. ## Figma를 회고에 사용하는 이유 - 기존 화이트보드 회고에는 다음과 같은 문제가 있다. - 사람들 앞에 나가 직접 글을 쓰는 것이 부담스러울 수 있다. - 손글씨를 읽기 어렵다. - 여러 사람이 동시에 보드 앞에 서기 어렵다. - Figma는 멀티플레이어 방식으로 여러 명이 같은 파일에 동시에 접속할 수 있다. - 참가자별 커서가 표시되어 서로의 작업을 실시간으로 확인할 수 있다. - 댓글과 협업 기능을 활용하면 회의실에 직접 참석하지 못한 원격 구성원도 참여하기 쉽다. - 회고를 통해 팀에 Figma를 소개하고 도입 가능성을 시험해볼 수 있다. ## 파일 공유와 권한 설정 - 회고용 Figma 파일을 새로 만들거나 제공된 템플릿을 복제한다. - 우측 상단의 파란색 **Share** 버튼으로 파일을 공유한다. - 구성원을 이메일로 초대하거나 공유 링크를 생성할 수 있다. - 링크로 참여하는 사람도 의견을 작성할 수 있도록 편집 권한을 설정해야 한다. ## 회고 카테고리를 프레임으로 구성 - 화이트보드의 구역처럼 Figma 캔버스를 프레임으로 나눈다. - 기본 회고 템플릿은 세 가지 프레임으로 구성된다. - 계속할 일: 잘 작동했으므로 유지할 것 - 중단할 일: 비효율적이거나 개선이 필요한 것 - 시작할 일: 새롭게 시도할 것 - 프레임 내부의 제목과 배경 등에 **Constraints**를 설정한다. - 프레임 크기를 늘리거나 줄여도 내부 요소가 자동으로 조정되므로 참가자들이 작성할 공간을 쉽게 확장할 수 있다. ## 스티키 노트 컴포넌트로 의견 작성 - 참가자들이 각 카테고리에 빠르게 의견을 추가할 수 있도록 스티키 노트 컴포넌트를 제공한다. - 컴포넌트를 선택한 뒤 `Command + D`를 누르거나, `Option/Alt`를 누른 채 드래그해 복제한다. - 컴포넌트 인스턴스에는 오버라이드가 가능하다. - 텍스트 변경 - 색상 변경 - 효과 조정 - 원본 컴포넌트를 훼손하지 않고 각자의 메모를 개성 있게 꾸밀 수 있다. - 원격 참가자도 동일한 화면을 보며 다른 사람의 작업을 따라갈 수 있다. - 다른 사람의 아바타를 클릭해 해당 사용자의 화면을 관찰하는 기능도 활용할 수 있다. ## 팀에 맞게 템플릿 맞춤화 ### 회사 로고와 브랜드 색상 추가 - 회고 파일에 회사 로고 컴포넌트를 추가한다. - 회고 결과를 이미지나 PDF로 내보낼 때 조직의 정체성을 반영할 수 있다. - Figma의 **Styles** 패널에서 회사 브랜드 색상을 지정한다. ### 동의 표시용 컴포넌트 만들기 - 팀원들이 특정 의견에 동의하거나 추가 논의를 원할 때 `+1` 표시를 사용할 수 있다. - `+1` 아이콘이나 배지를 별도 컴포넌트로 만들어 재사용한다. - 각 인스턴스의 크기와 색상을 조정할 수 있도록 구성하면 다양한 의견 표시 방식에 대응할 수 있다. ### 회고별 커버 페이지 구성 - Figma 파일의 첫 페이지를 회고용 커버 페이지로 활용한다. - 회고마다 새 파일을 만든다면 프로젝트, 스프린트, 계절 등 다양한 테마를 적용할 수 있다. - 회고 결과물을 보관하거나 공유할 때 파일을 쉽게 식별하는 데 도움이 된다. 실제로 적용할 때는 회고 전에 편집 권한과 프레임 구조를 미리 설정하고, 참가자들이 사용할 스티키 노트와 동의 표시 컴포넌트를 준비하는 것이 좋다. 이후 회고가 끝나면 프레임을 내보내 결과와 실행 항목을 기록해두면 협업 기록으로도 활용할 수 있다.

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

Figma 채용 담당자가 전하는

제품 디자인 포트폴리오는 자신의 경력을 모두 보여주는 자료가 아니라, 지원하는 역할에 맞는 역량을 짧은 시간 안에 전달하는 도구다. 채용 담당자나 디자인 리더는 포트폴리오를 몇 분 또는 몇 초 만에 훑을 수 있으므로, 대상 독자의 관점에서 정보를 선별하고 구조화해야 한다. 랜딩 페이지에서는 프로젝트를 일관되게 배치하고 실제 작업까지 한 번의 클릭으로 도달하게 하며, 프로젝트는 목표 직무와 산업에 맞춰 선택하는 것이 핵심이다. ## 채용 담당자의 관점에서 목표 설정 - 포트폴리오를 주로 검토하는 사람은 디자인 매니저, 크리에이티브 디렉터, 디자인 총괄, 디자인 부문 VP 등이다. - 이들은 회의와 인터뷰 사이에 제한된 시간으로 포트폴리오를 검토한다. - 짧은 시간 안에 다음 정보를 파악하려 한다. - 어떤 유형의 디자인을 하는지 - 어떤 역량과 관심사를 가졌는지 - 지원 직무에 적합한 경험이 있는지 - 디자인 문제를 어떻게 해결하는지 - 전반적인 디자인 능력이 어떤지 - 따라서 모든 경력을 빠짐없이 보여주기보다, 지원하는 역할과 가장 관련 있는 정보를 우선적으로 노출해야 한다. ## 랜딩 페이지: 프로젝트를 쉽게 파악하게 만들기 - 프로젝트 썸네일은 일관된 시스템으로 구성해야 한다. - 회사 로고를 보여준다면 로고 크기를 동일하게 맞춘다. - 작업 화면을 보여준다면 배경색, 그림자, 이미지 스타일 등을 통일한다. - 각 프로젝트에는 회사명, 담당 역할, 작업 매체 등 핵심 정보를 일정한 형식으로 표시한다. - 동일한 크기와 정돈된 디자인의 썸네일은 채용 담당자가 포트폴리오 전체를 더 쉽게 훑도록 돕는다. - 썸네일마다 차이를 주고 싶다면 우연히 어긋난 결과가 아니라, 특정 프로젝트의 중요도 등을 반영한 의도적인 레이아웃이어야 한다. ## 작업까지의 클릭 수 줄이기 - 방문자가 ‘소개 페이지 → 작업 메뉴 → 프로젝트 선택’처럼 여러 단계를 거치지 않도록 한다. - 랜딩 페이지에서 프로젝트 개요를 바로 볼 수 있게 구성하고, 실제 작업까지 한 번의 클릭으로 접근하게 만드는 것이 좋다. - 채용 담당자가 정보를 찾아 헤매도록 만들지 말고, 첫 화면에서 작업의 범위와 성격을 즉시 이해할 수 있어야 한다. ## 지원 목표에 맞는 프로젝트 선택 - 프로젝트는 자신의 전체 경력보다 희망하는 직무와 커리어 방향을 기준으로 선별한다. - 모바일, 웹, VR 중 원하는 분야의 경험을 강조한다. - 이커머스에서 핀테크나 헬스케어로 전환하고 싶다면 관련성이 높은 작업을 앞세운다. - 모든 프로젝트를 한 포트폴리오에 담아 경력의 폭을 보여주려는 방식은 오히려 핵심 메시지를 흐릴 수 있다. - 오래된 유명 브랜드 작업은 브랜드 이름만으로 포함하지 않는다. - 현재의 자신을 잘 보여주지 못하는 작업은 이력서에서 경력의 폭을 설명하는 데 활용한다. - 다만 널리 알려진 대표 작업처럼 현재도 의미가 큰 결과물은 예외적으로 강조할 수 있다. - 희망 분야의 실무 경험이 부족하다면 사이드 프로젝트로 해당 분야의 결과물을 만든다. - 예를 들어 모바일 중심 경력으로 웹 디자인 직무를 원한다면 웹을 우선한 프로젝트를 추가한다. - 인쇄 디자인에서 UX/UI로, 비주얼 디자인에서 UX 리서치로 이동하는 경우에도 같은 전략을 적용할 수 있다. - 가장 뛰어난 작업이 지원 분야의 산업이나 매체와 다르더라도, 단순히 그 이유만으로 포트폴리오 전체를 구성해서는 안 된다. 지원 목표를 보여줄 수 있는 관련 작업을 새로 만들거나 기존 작업을 적절히 재구성하는 것이 바람직하다. ## 실용적인 적용 방법 지원 직무를 먼저 한 문장으로 정한 뒤, 랜딩 페이지에는 그 직무와 가장 관련 있는 프로젝트를 일관된 썸네일 형식으로 배치하는 것이 좋다. 각 프로젝트에는 자신의 역할과 작업 매체를 명확히 적고, 방문자가 한 번의 클릭으로 핵심 결과물에 도달하도록 구성하면 채용 담당자의 제한된 검토 시간을 효과적으로 활용할 수 있다.

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

GIF로 피그마 프로토타

Figma는 2019년부터 프로토타입에서 애니메이션 GIF를 재생할 수 있도록 지원했다. 파일에 GIF를 추가한 뒤 **Present**를 누르면 움직임이 재생되며, 모션 디자인·영상·미세한 인터랙션을 실제 제품처럼 표현할 수 있다. 편집 화면에서는 GIF가 정지 이미지로 보이지만, 원하는 프레임을 커버 이미지로 지정해 여러 GIF를 쉽게 구분할 수 있다. ## 프로토타입에서 GIF 사용하기 - Figma 파일에 GIF를 이미지처럼 추가한다. - **Present** 모드에서 GIF가 자동으로 애니메이션을 재생한다. - GIF는 편집 화면에서는 정지 이미지로 표시되고, 프로토타입에서만 움직인다. - GIF 제작 도구로 ScreenFlow, LICEcap, Principle, After Effects 등이 소개됐다. ## 커버 프레임 지정 - GIF 속성 패널의 GIF 모달을 열어 원하는 프레임으로 이동할 수 있다. - 선택한 프레임은 편집 화면에 표시되는 대표 이미지가 된다. - 첫 프레임이 비어 있거나, 비슷한 시작 화면을 가진 GIF가 여러 개일 때 유용하다. ## 모바일 프로토타입 개선 - 모바일 프로토타입에는 OS에 맞춘 관성 스크롤이 적용됐다. - 새로운 터치 커서가 추가되어 실제 모바일 기기와 비슷한 조작감을 제공한다. - GIF 기능과 함께 모바일 인터랙션의 사실성을 높이는 업데이트다. ## GIF를 활용할 수 있는 디자인 사례 - **Uber**: 애니메이션 스플래시 화면을 로딩 상태와 브랜드 인사말로 활용한다. - **Slack**: 로딩 중 제품 팁이나 재미있는 문구를 보여준다. - **Material Design**: 선형·원형 진행 표시기로 작업 상태를 단순하게 전달한다. - **Headspace**: 온보딩 과정에서 일러스트 애니메이션으로 기능과 사용 맥락을 설명한다. - **Hyperlapse**: 동영상 촬영 앱의 사용 시나리오를 온보딩 영상으로 소개한다. - **Mapbox**: 웹사이트 히어로 영역에서 위치 기술을 설명하는 반복 영상을 사용한다. - **Mailchimp**: 일러스트에 미세한 움직임을 더해 화면에 생동감과 질감을 부여한다. ## 실용적인 활용 방향 GIF는 복잡한 동영상 구현 없이도 로딩 상태, 온보딩, 진행 표시, 제품 소개, 일러스트 애니메이션을 프로토타입에 포함하는 간단한 방법이다. 다만 편집 화면에서는 정지 이미지로 보이므로 의미 있는 커버 프레임을 설정하고, 실제 사용 환경을 확인하려면 반드시 **Present** 모드에서 테스트하는 것이 좋다.

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

Figma의 새로운 기능 요

Figma는 2019년 봄, 디자인 시스템 확장에 초점을 맞춰 Components를 개선하고 플러그인 API 공개 베타를 시작했다. 여러 컴포넌트를 한 번에 생성하거나 인스턴스와 마스터 간 이동·동기화를 쉽게 만드는 기능으로 반복 작업을 줄였으며, 플러그인을 통해 커뮤니티가 Figma 기능을 확장할 수 있는 기반을 마련했다. 또한 Smart Selection 등 일상적인 기능 개선과 버그 수정도 함께 진행했다. ## 디자인 시스템 확장을 위한 컴포넌트 개선 - 여러 객체를 선택한 뒤 한 번의 클릭으로 각각의 Component로 변환할 수 있다. - 인스턴스를 우클릭하면 Context Menu에서 관련 Component를 바로 확인할 수 있다. - 다른 인스턴스로 빠르게 교체할 때 유용하다. - **Return to Instance** 기능을 사용하면 현재 인스턴스의 Master Component로 이동해 참고하거나 수정한 뒤, 작업 중이던 인스턴스로 돌아올 수 있다. - 로컬 컴포넌트에서는 인스턴스에 적용한 변경 사항과 오버라이드를 Master Component에 반영할 수 있다. - 기존 컴포넌트를 실제 사용 사례에 맞게 조정하고 업데이트할 때 효율적이다. - 이러한 기능들은 재사용 가능한 UI 요소를 관리하고, 팀 단위 디자인 시스템을 확장하는 작업을 단순화한다. ## Figma 플러그인 API 공개 베타 - Figma는 오랫동안 준비한 플러그인 API의 공개 베타를 출시했다. - 플러그인을 통해 사용자가 Figma 내부 기능을 직접 확장하고 반복적인 디자인 작업을 자동화할 수 있게 됐다. - 초기 제작 사례로 다음과 같은 플러그인이 소개됐다. - 텍스트 요소를 방사형으로 반복 배치하는 생성형 디자인 플러그인 - 선택한 이미지에서 주요 색상 팔레트를 추출하는 플러그인 - 공개 직후부터 커뮤니티와 고객들이 다양한 실험적 도구를 만들며 생태계의 가능성을 보여줬다. ## 지속적인 사용성 개선과 품질 향상 - Components와 Smart Selection처럼 매일 사용하는 기능을 빠르게 개선했다. - 사용자가 요청해 온 기능을 추가하는 동시에, 반복 작업에 드는 시간을 줄이는 데 초점을 맞췄다. - 별도의 품질 개선 기간을 운영해 다수의 버그를 수정했다. - 이번 업데이트는 대규모 신기능뿐 아니라 기존 기능의 안정성과 작업 흐름 개선도 중요하게 다뤘다. ## 실용적인 활용 방향 - 반복되는 UI 요소는 Component로 만들고, 여러 객체를 한 번에 변환해 초기 구축 시간을 줄이는 것이 좋다. - 인스턴스에서 발견한 개선 사항은 로컬 컴포넌트의 Master에 반영해 디자인 시스템을 최신 상태로 유지할 수 있다. - 이미지 색상 추출이나 생성형 배치처럼 반복적이거나 계산이 필요한 작업은 플러그인으로 자동화할 수 있다.

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

피그마에서 프로토타 (새 탭에서 열림)

피그마를 활용한 프로토타이핑은 사용자 테스트와 이해관계자 소통의 핵심이지만, 복잡한 연결 과정이 작업 속도를 늦추기도 합니다. 이 글은 마스터 컴포넌트 활용, 스크롤 관리, 지연 효과 등을 통해 프로토타이핑 워크플로우를 획기적으로 개선하고 효율성을 높이는 다섯 가지 실무 팁을 제시합니다. 이러한 기법들을 숙달하면 더 사실적인 프로토타입을 빠르게 제작하여 협업의 질을 높일 수 있습니다. ### 마스터 컴포넌트를 활용한 자동 연결 * 탭바나 햄버거 메뉴처럼 여러 화면에 반복되는 요소를 마스터 컴포넌트로 먼저 제작합니다. * 마스터 컴포넌트 내부에서 각 메뉴 항목과 대상 프레임을 미리 연결하면, 이후 생성되는 모든 인스턴스에 연결 정보가 자동으로 상속되어 반복적인 링크 작업을 생략할 수 있습니다. * 외부 팀 라이브러리의 컴포넌트를 사용할 때는 해당 인스턴스를 다시 로컬 마스터 컴포넌트로 감싸는 방식으로 연결 정보를 유지하며 관리할 수 있습니다. ### 컴포넌트를 활용한 스크롤 영역 관리 * 상단 바나 하단 바가 고정된 긴 화면을 디자인할 때, 스크롤되는 콘텐츠 자체를 별도의 컴포넌트로 구성합니다. * 콘텐츠 컴포넌트에 'Clip content'를 적용하고 프로토타이핑 설정에서 'Overflow Behavior'를 활성화하면, 다양한 기기 사이즈에서 초기에 노출되는 영역(Viewport)을 직관적으로 확인할 수 있습니다. * 이 방식을 통해 기기별로 잘리는 콘텐츠의 위치를 파악하고, 스크롤 내용을 한 곳에서 효율적으로 수정할 수 있습니다. ### 시간 지연과 오버레이로 현실감 구현 * 사용자 상호작용이 너무 즉각적이면 부자연스러울 수 있으므로 'After delay' 트리거를 사용하여 의도적인 시간 지연을 추가합니다. * 지연 기능을 오버레이(Overlay) 및 오버레이 교체(Swap overlay) 기능과 결합하면, 버튼 클릭 후 로딩 화면이 나타났다가 성공 메시지로 바뀌는 등의 복합적인 연출이 가능합니다. * 이러한 디테일은 프로토타입에 사실성을 더해 사용자가 혼란을 느끼지 않고 자연스럽게 흐름을 따라오게 돕습니다. ### 목차 페이지를 활용한 다중 흐름 관리 * 피그마 프로토타입 URL은 페이지 단위로 생성되지만, 첫 화면을 '목차(Table of Contents)' 프레임으로 구성하여 이를 보완할 수 있습니다. * 목차의 각 항목을 동일 페이지 내의 서로 다른 사용자 흐름(User Flow) 시작점에 연결하면, 하나의 링크만으로도 여러 디자인 시나리오를 공유할 수 있습니다. * 이는 이해관계자에게 여러 옵션을 한꺼번에 제안해야 할 때 특히 유용합니다. ### 관찰 모드를 통한 원격 협업 및 테스트 * 피그마의 '관찰 모드(Observation Mode)'는 디자인 에디터뿐만 아니라 프로토타입 실행 화면에서도 지원됩니다. * 화면 우측 상단의 협업자 아바타를 클릭하면 상대방이 프로토타입의 어느 부분을 클릭하고 어떻게 이동하는지 실시간으로 추적할 수 있습니다. * 이 기능은 원격 사용자 테스트를 수행하여 사용자의 행동 패턴을 관찰하거나, 미팅에서 디자인 결과물을 시연할 때 모든 참여자가 동일한 맥락을 유지하도록 돕습니다. 효율적인 프로토타이핑은 디자인 의도를 정확하게 전달하고 피드백 루프를 단축하는 데 필수적입니다. 위에서 소개한 컴포넌트 중심의 설계와 피그마의 고급 기능을 워크플로우에 녹여낸다면, 단순 반복 작업에 드는 시간을 줄이고 사용자 경험의 본질을 다듬는 데 더 집중할 수 있을 것입니다.

figma3분 읽기큐레이션 요약

Figma 워크플로우

Figma는 디자인 작업의 맥락과 팀별 상황에 따라 해답이 달라지는 문제를 사용자 간 대화로 해결할 수 있다고 보고, 온라인 포럼을 새롭게 개편했다. 개편의 핵심은 주제별 채널 구조, 명확한 커뮤니티 가이드라인, AMA와 라이브스트림 같은 참여형 콘텐츠다. 버그 신고와 기능 요청은 포럼 대신 지원 플랫폼으로 일원화해 더 신속하고 체계적으로 처리하도록 했다. ## 사용자 간 지식 공유를 강화하는 포럼 - 디자인 시스템, 개발자 핸드오프, 툴체인 구성처럼 정답이 하나로 정해지지 않은 문제는 일반적인 지원 문서만으로 해결하기 어렵다. - 사용자는 다른 디자이너의 실제 경험과 상황을 참고해 자신의 워크플로를 개선할 수 있다. - 포럼에서는 한 질문에 다양한 관점이 모이고, 그 논의가 질문자뿐 아니라 커뮤니티 전체에 유용한 지식으로 축적된다. - Figma는 오프라인 모임이나 트위터에서 자연스럽게 이뤄지던 교류를 온라인 포럼에서 더 쉽게 이어가려 했다. ## 실무 주제 중심의 새 채널 구조 - 기존 채널 일부를 보관하거나 이름을 변경하고, 실무 영역별로 대화를 집중할 수 있도록 새 채널을 추가했다. - **Design Systems** - 디자인 시스템의 모범 사례를 논의한다. - 팀별 Figma 라이브러리 구성 방식과 운영 경험을 공유한다. - 관련 자료와 리소스를 교환한다. - **Prototyping** - 프로토타이핑 기법과 활용 사례를 다룬다. - **API and Extensions** - Figma API와 확장 기능에 관한 질문과 정보를 공유한다. - **Workflow and Process** - 디자인 업무 프로세스와 협업 방식에 대해 논의한다. - **Open Design** - 진행 중인 작업물을 공개하고 피드백을 받을 수 있다. - 프로젝트에 참여할 다른 디자이너를 찾는 용도로도 활용할 수 있다. - 브라우저 기반 협업 도구라는 Figma의 특성을 커뮤니티 활동에 연결한 채널이다. - **Start Here** - 새 채널 구조, 커뮤니티 이용 가이드라인, 행동 강령 등 포럼 이용에 필요한 정보를 제공한다. ## 버그 신고와 기능 요청의 지원 플랫폼 이관 - 버그 신고와 기능 요청은 포럼에서 제거하고 Figma의 공식 지원 플랫폼으로 접수 경로를 통합했다. - 지원 채널을 이용하면 담당 팀이 사용자와 1:1로 문제를 진단할 수 있다. - 공개 포럼에서 공유하기 어려운 파일이나 계정 정보도 지원 과정에서 전달할 수 있다. - 지원팀은 접수된 버그와 요청을 적절한 담당자에게 전달하고 우선순위를 관리한다. - 지원팀은 제품팀 및 엔지니어링팀과 매주 논의하며, 사용자 피드백이 제품 개선 과정에 반영되도록 했다. ## 커뮤니티 참여형 콘텐츠 - 포럼을 단순한 질문·답변 공간이 아니라 지속적인 커뮤니티 활동의 장으로 확장하려 했다. - AMA(Ask Me Anything)를 통해 Figma 관계자나 전문가에게 직접 질문할 수 있다. - 라이브스트림 등 실시간 콘텐츠를 통해 사용자와의 소통을 강화한다. - 공식 안내와 사용자 간 자율적인 경험 공유를 함께 제공하는 구조를 지향한다. 실제로 이용할 때는 워크플로·디자인 시스템·프로토타이핑 관련 질문은 주제별 포럼에서 다른 사용자의 경험을 참고하고, 계정 정보나 파일이 필요한 버그 신고 및 기능 요청은 공식 지원 플랫폼을 이용하는 것이 가장 효율적이다.

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

Figma의 줄 높이

Figma는 텍스트의 줄 높이를 글자 위아래에 균등하게 배분하고, 보다 현대적인 기준으로 측정하도록 변경했다. 이는 기존 파일에 자동 적용되지 않는 선택적 변경이며, 사용자가 원하는 시점에 업데이트할 수 있다. 이 글은 금속 활자부터 컴퓨터 글꼴, CSS까지 줄 높이와 수직 정렬이 발전해 온 과정을 설명하며 Figma의 변경 배경을 밝힌다. ## 금속 활자 시대의 줄 높이 - 초기 활자에서 폰트 크기는 글자 자체가 아니라 글자를 담는 납 블록의 높이를 의미했다. - 같은 16pt 폰트라도 실제 글자 크기, 기준선 위치, 위아래 여백은 서체마다 달랐다. - 조판공은 줄 사이에 얇은 납 조각을 끼워 행간을 추가했다. - 이 납 조각을 뜻하는 *leading*에서 오늘날의 줄 높이 개념이 유래했다. - 예를 들어 16pt 활자에 4pt 행간을 추가하면 전체 줄 높이는 20pt가 된다. - 당시에는 행간을 추가할 수만 있었고, 활자에 내장된 공간을 제거할 수는 없었다. ## 디지털 폰트가 가져온 자유와 혼란 - 컴퓨터에서는 폰트가 고정된 납 블록이 아니라 다양한 수치와 메트릭을 담은 파일로 바뀌었다. - Windows, Macintosh, OS/2 등 플랫폼마다 폰트 형식과 렌더링 방식이 달랐고, 버그와 호환성 문제도 발생했다. - 화면에서는 글자가 고정된 상자에 묶이지 않으므로 행간을 자유롭게 추가하거나 제거할 수 있게 됐다. - 폰트의 기본 줄 높이는 글자 크기와 무관하게 임의의 값으로 설정될 수 있었다. - 같은 글자 크기와 같은 줄 높이를 사용해도 폰트 내부의 ascent, descent, 기준선 위치가 달라 시각적 결과가 달라졌다. ## CSS와 폰트 메트릭의 복잡성 - 웹에서는 줄 높이를 단순히 글자 크기로만 결정하지 않고, 기준선과 인라인 박스를 기준으로 계산한다. - CSS의 줄 높이는 일반적으로 한 줄의 기준선에서 다음 줄 기준선까지의 거리로 이해할 수 있다. - 추가 공간인 “half-leading”을 글자 위와 아래에 나누어 배치하는 방식이 사용된다. - 그러나 폰트 파일에 들어 있는 여러 메트릭 값이 서로 다른 목적을 가져 브라우저와 운영체제마다 결과가 달라질 수 있었다. - 특히 OS/2 테이블의 ascent, descent, line gap 값은 폰트의 시각적 경계와 실제 줄 상자 크기를 일치시키지 못하는 경우가 있었다. ## Figma의 줄 높이 변경 - Figma는 추가 줄 높이를 글자 위와 아래에 분배하는 방식으로 변경했다. - 줄 높이를 글자 크기나 특정 플랫폼의 관행에만 의존하지 않고, 보다 현대적인 타이포그래피 및 웹 기준에 가깝게 측정한다. - 이를 통해 텍스트가 프레임 안에서 수직으로 배치되는 방식을 더 예측 가능하게 만들려 했다. - 변경 사항은 기존 파일에 강제로 적용되지 않는다. - 사용자는 기존 텍스트를 그대로 유지하거나, 필요할 때 새 줄 높이 동작으로 업데이트할 수 있다. ## 하나의 완벽한 기준을 만들기 어려운 이유 - Figma는 인쇄물 디자인, 웹 디자인, 제품 UI 등 서로 다른 목적에 사용된다. - 역사적인 조판 관습과 현대적인 CSS 동작이 항상 일치하지 않는다. - 폰트마다 내부 메트릭이 다르고, 같은 폰트도 플랫폼과 렌더링 엔진에 따라 다르게 보일 수 있다. - 따라서 Figma는 모든 상황에 하나의 절대적인 정답을 적용하기보다, 새로운 동작을 선택 사항으로 제공하는 방식을 택했다. 기존 디자인의 시각적 일관성이 중요하다면 파일을 즉시 변경하지 말고, 새 줄 높이 동작이 필요한 웹·제품 UI 작업부터 선택적으로 적용하는 것이 적절하다.

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

깃허브, 협업 문화를

GitHub는 원격 협업 환경에서 디자인 시스템을 효율적으로 운영하기 위해 Figma를 도입했다. Figma와 API를 활용해 아이콘·UI 컴포넌트 제작 과정을 자동화하고, 디자이너와 개발자가 같은 파일에서 실시간으로 협업할 수 있게 했다. 그 결과 디자인 시스템은 GitHub의 일하는 방식에 핵심 요소로 자리 잡았고, 반복 작업과 협업 장벽을 줄이는 기반이 되었다. ## 디자인 시스템 전담 조직의 성장 - 2015년 당시 GitHub에는 디자인 시스템을 전담하는 직원이 없었다. - 디자이너들이 동일한 요소를 반복해서 만들고, 문서가 부족하며, 패턴이 오래된 문제가 있었다. - 이를 해결하기 위해 디자인 시스템과 문서화된 워크플로를 구축하는 풀뿌리 활동을 시작했다. - 활동 시작 6개월 만에 전담 팀이 만들어졌으며, 이후 7명 규모로 성장했다. - 전체 제품 디자인 팀 25명 중 7명이 재사용 가능하고 교체 가능한 컴포넌트를 관리하게 되었다. - 디자인 시스템은 GitHub의 디자인·개발 프로세스를 효율적이고 반복 가능하며 확장 가능하게 만드는 핵심 기반이 되었다. ## 기존 디자인 워크플로의 문제점 - 전담 팀을 구성해도 디자인 시스템을 만들고 유지하는 과정 자체가 비효율적이었다. - SVG 아이콘 라이브러리인 **Octicons**를 수정하려면 특정 소프트웨어 설치와 관련 도구에 대한 지식이 필요했다. - 이런 복잡한 설정은 기여자가 아이콘을 수정하거나 업데이트하는 일을 어렵고 혼란스럽게 만들었다. - 결과적으로 디자인 시스템에 참여하려는 사람들의 진입 장벽이 높아졌다. ## Figma와 API를 통한 기여 과정 자동화 - GitHub는 Octicons를 Figma로 이전하는 실험을 시작했다. - Figma는 별도의 소프트웨어를 다운로드하거나 설치하지 않아도 브라우저에서 작업할 수 있었다. - Figma API를 함께 사용해 아이콘 업데이트 과정을 자동화할 수 있었다. - 디자이너와 개발자는 운영체제나 도구에 관계없이 복잡한 설정 없이 디자인 시스템에 기여할 수 있게 되었다. - Octicons에서 얻은 효과를 바탕으로 UI 컴포넌트도 Figma로 이전했다. - 이후 GitHub의 디자인과 개발에 필요한 대부분의 요소를 Figma에서 이용할 수 있게 되었다. ## 원격 팀을 위한 ‘DesignHub’ - GitHub는 원래 도구에 구애받지 않는 팀이었지만, Figma 사용은 빠르게 확산되었다. - 웹 기반 협업 기능 덕분에 서로 다른 장소에서 일하는 팀원들이 같은 파일에 동시에 참여할 수 있었다. - Figma는 물리적으로 함께 모여 화이트보드 앞에서 작업하는 경험을 대체했다. - 디자이너들은 실제로 한 공간에 있는 팀처럼 아이디어를 공유하고 발전시킬 수 있었다. - 여러 디자이너가 Figma 파일에서 즉석으로 아이디어를 결합하는 ‘디자인 잼’을 진행하며 창의적인 탐색을 활성화했다. ## 프로토타이핑과 스토리텔링의 통합 - GitHub의 디자이너들은 Figma를 디자인 과정뿐 아니라 스토리텔링 전반에 활용했다. - 디자인은 사용자 경험의 이야기를 전달하는 과정이며, 프로토타입은 그 이야기를 실제 흐름으로 보여주는 수단으로 여겨졌다. - Figma에서는 다른 도구로 전환하지 않고 요소를 빠르게 배치하고 이동해 화면 흐름을 제안할 수 있었다. - 프로토타이핑의 진입 장벽이 낮아지면서 아이디어를 빠르게 표현하고 검증할 수 있었다. ## 협업 중심 문화와 도구의 결합 - GitHub는 기능과 도구가 모두 협업을 촉진해야 한다는 문화를 갖고 있다. - Figma는 디자이너와 엔지니어가 함께 작업하도록 설계된 도구라는 점에서 GitHub의 문화와 잘 맞았다. - 디자인 시스템을 단순한 결과물이나 라이브러리가 아니라 여러 직군이 함께 개선하는 협업 공간으로 발전시켰다. - 웹 기반 편집, 실시간 공동 작업, API 자동화를 조합해 원격 협업의 물리적 한계를 줄였다. GitHub 사례는 디자인 시스템의 효과를 높이려면 컴포넌트를 만드는 것뿐 아니라 누구나 쉽게 기여할 수 있는 워크플로를 함께 설계해야 한다는 점을 보여준다. 특히 웹 기반 협업 도구와 API 자동화를 결합하면 원격 팀에서도 디자인·개발 간 피드백과 반복 작업을 크게 줄일 수 있다.

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

DesignSystems.com을

Figma는 디자인 시스템 구축과 운영에 관한 실용적인 지식 허브인 DesignSystems.com을 새롭게 개편해 다시 선보였다. 개편의 핵심은 바로 적용할 수 있는 콘텐츠를 제공하고, 초보자부터 숙련자까지 다양한 수준과 규모의 팀을 아우르며, 여러 관점을 소개하는 것이다. 사이트는 커뮤니티의 피드백을 반영해 지속적으로 콘텐츠를 업데이트하고 기여를 받을 예정이다. ## DesignSystems.com 재출시 배경 - Figma는 2018년 5월 DesignSystems.com을 처음 공개한 뒤 커뮤니티에 아이디어와 의견을 요청했다. - 디자이너, 개발자, 콘텐츠 전략가, 디자인 운영 담당자 등 다양한 직군과 대규모 브랜드부터 1인 팀까지 폭넓은 피드백을 수집했다. - 이러한 의견을 바탕으로 사이트의 목적과 콘텐츠 방향을 재정비했다. ## 실행 가능한 콘텐츠 제공 - 디자인 시스템을 만드는 사람과 운영하는 사람이 실제 업무에 적용할 수 있는 글과 자료를 제공한다. - 단순한 개념 소개보다 명확한 시사점과 실천 방법을 포함하는 것을 목표로 한다. - 샘플 코드, 디자인 파일, 가이드, 커뮤니티 사례 등을 통해 이론과 실무를 연결한다. ## 다양한 수준과 팀 규모 지원 - 디자인 시스템을 처음 시작하는 사람을 위한 입문 가이드를 제공한다. - 이미 성숙한 디자인 시스템을 운영하는 실무자를 위해 선도적인 기업의 사례와 경험도 소개한다. - Lyft, Asana, Harry’s 등 디자인 시스템 팀의 글을 통해 조직 규모와 성숙도에 따른 다양한 접근법을 보여준다. - 대기업뿐 아니라 소규모 팀이나 개인 단위의 실무자도 참고할 수 있도록 콘텐츠 범위를 넓힌다. ## 여러 관점과 사례 수집 - 디자인 시스템 문제에는 하나의 정답만 존재하지 않는다는 관점을 강조한다. - 같은 문제를 서로 다른 조직과 직군이 어떻게 해결했는지 비교할 수 있도록 다양한 목소리를 담는다. - 커뮤니티 구성원 간 경험과 지식을 공유하는 장으로 사이트를 발전시키려 한다. ## 지속적인 커뮤니티 참여 - 이번 재출시는 완성된 결과물이 아니라 지속적인 운영의 시작으로 소개된다. - 새로운 글과 자료를 정기적으로 추가할 예정이다. - 독자에게 사이트 콘텐츠에 대한 피드백과 기고 아이디어 제출을 요청한다. - 관심 있는 사람은 업데이트를 구독하거나 직접 콘텐츠 제작에 참여할 수 있다. 디자인 시스템을 도입하려는 팀은 입문 가이드로 기본 방향을 잡고, 성숙한 기업의 사례를 참고하되 자신의 조직 규모와 업무 방식에 맞게 적용하는 것이 좋다. 특히 여러 사례를 비교해 단일한 정답보다 팀에 적합한 원칙과 운영 방식을 찾는 접근이 권장된다.

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

Figma UI 개편:

Figma는 기능 구조를 크게 바꾸기보다 타이포그래피, 레이아웃, 색상, 아이콘 등 UI 표면을 다듬는 방식으로 시각적 리프레시를 진행했다. 기존 UI가 제품 성장에 따라 일관성을 잃고 한계에 부딪혔기 때문에, 전사적 브레인스토밍과 이슈 통합, 정성·정량 조사를 거쳐 변경 범위를 결정했다. 핵심은 모든 사용자를 만족시키려 하기보다 문제를 체계적으로 수집하고, 중요한 개선점에 집중하는 것이었다. ## 리디자인이 필요해진 배경 - Figma의 UI는 제품과 기능이 성장하면서 점점 일관성을 잃었다. - 기존 컴포넌트로 새로운 기능을 표현하기 어려워질 때마다 팀이 임시 컴포넌트와 맞춤형 해결책을 만들었다. - 그 결과 다음과 같은 문제가 누적됐다. - 서로 다른 형태의 테이블, 버튼, 입력 컨트롤 - UI 곳곳에 흩어진 여러 색조의 회색·빨강·파랑 - 기능마다 다른 알림과 대화상자 처리 방식 - 가독성, 여백, 아이콘 체계의 불일치 - 마지막으로 UI 전체를 검토했을 때는 아직 Multiplayer나 Components 같은 핵심 기능이 없었다. - 즉, 기존 UI의 기반이 현재의 Figma를 충분히 반영하지 못하게 된 것이 리프레시의 주요 배경이었다. ## 표면적 변화에 집중한 전략 - 목표는 사용자가 큰 혼란 없이 새 UI를 받아들이도록 만드는 것이었다. - 정보 구조나 제품의 기본 동작을 재설계하기보다는 다음과 같은 시각적 요소를 중심으로 개선했다. - 타이포그래피 - 레이아웃 - 색상 - 아이콘 - 컴포넌트의 시각적 일관성 - 출시 전 수개월 동안 정성적·정량적 조사를 진행했다. - 세부 변경 사항마다 여러 팀이 깊이 논의해 최종 결과에 동의하도록 했다. - 특히 디자이너는 시각적 변화에 민감하므로, 리디자인이 모든 사람에게 동일하게 환영받을 수 없다는 점도 고려했다. ## 1단계: 제한 없이 문제 수집하기 - 전체 디자인 팀이 참여하는 2시간 브레인스토밍 세션을 열었다. - 팀원들은 실제로 Figma를 사용하면서 제품의 구석구석을 살펴봤다. - 발견한 내용을 다음 방식으로 기록했다. - UI의 문제점과 불편한 점 - 마음에 드는 부분 - 관련 스크린샷 - 특정 문제가 미치는 영향에 대한 메모 - 모든 결과물을 Figma 파일에 모아 공동으로 검토했다. - 팀원들이 강하게 반응한 문제, 즉 모두가 “이건 심각하다”고 느낀 항목을 별도로 표시했다. - 이 반응은 어떤 문제가 사용자 경험에 큰 영향을 줄 가능성이 있는지 판단하는 초기 신호로 활용됐다. - 브레인스토밍 직후 결론을 내리지 않고 며칠간 거리를 둔 것도 중요했다. 시간이 지나면서 문제의 우선순위와 구성원들의 의견이 자연스럽게 바뀌었기 때문이다. ## 2단계: 문제를 통합하고 범주화하기 - 후속 회의에서 각 문제를 다시 검토하며 처음의 판단을 재평가했다. - 일부 문제는 생각보다 중요하지 않다고 판단했고, 다른 문제는 해결 필요성을 더 강하게 주장할 수 있도록 논거를 보완했다. - 긴 문제 목록을 팀원들에게 나누어 전달하고, 각자가 이를 포스트잇 형태의 짧은 항목으로 재작성했다. - 이 과정에서는 개별적인 증상을 그대로 옮기기보다 공통된 근본 문제로 추상화했다. - 예: “특정 화면의 알림 모양이 다르다” - 통합된 표현: “제품 전체의 알림 처리 시스템이 필요하다” - 비슷한 포스트잇을 함께 묶어 반복적으로 나타나는 주제를 확인했다. - 그 결과 다음과 같은 범주가 도출됐다. - 아이콘, 타이포그래피, 가독성, 색상 - 대화상자, 툴바, 말투 - 에디터와 파일 브라우저 - 모드, 팀 페이지, 속성 사이드바 - 컴포넌트, 레이어, 히스토리 - 공유, 퍼블리싱, 내보내기 - 포스트잇의 반복은 단순한 중복이 아니라 중요한 문제가 여러 방식으로 나타나고 있다는 신호가 되었다. - 다만 범주를 다시 “시각적 문제에서 기초 구조적 문제까지”라는 축으로 정렬하려 한 것은 지나치게 복잡한 접근이었다. ## 범주화 과정에서 얻은 교훈 - 문제를 조직화할 때 지나치게 추상적인 기준을 만들면 오히려 판단이 어려워진다. - “제품의 개성”처럼 거의 모든 문제를 포함할 수 있는 범주는 유용하지 않다. - 반대로 특정 대화상자 하나처럼 지나치게 좁은 범주도 전체적인 개선 방향을 잡는 데 적합하지 않다. - 가장 좋은 범주는 서로 비슷한 문제를 묶으면서도, 실제 개선 작업으로 이어질 수 있을 만큼 구체적이어야 한다. - 완벽한 분류 체계를 만드는 것보다 중요한 문제의 신호를 잡음에서 분리하는 것이 우선이다. ## 실무에 적용할 때의 추천 - 리디자인을 시작할 때 바로 해결책을 만들기보다, 먼저 팀 전체가 제품을 직접 사용하며 문제를 폭넓게 수집한다. - 각 문제를 개별 사례가 아닌 반복되는 시스템적 문제로 재정의한다. - 브레인스토밍 직후 결론을 확정하지 말고 일정한 숙고 시간을 둔다. - 범주화는 단순하고 이해하기 쉽게 유지하며, 지나치게 추상적이거나 복잡한 분류 축은 피하는 것이 좋다.

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

#FigmaTip 모

Figma 파일과 디자인 시스템을 효율적으로 정리하려면 레이어, 파일, 컴포넌트, 페이지를 체계적으로 관리해야 한다. 이 글은 봄맞이 정리를 위한 Figma 활용법으로 일괄 이름 변경, 사용자 지정 썸네일, 파일 정렬, 라이브러리 정리, 프레임과 페이지 활용을 소개한다. 이러한 기능을 활용하면 파일을 빠르게 탐색하고 팀 협업 효율도 높일 수 있다. ### 레이어 일괄 이름 변경 - 장기간 진행한 프로젝트에서는 레이어가 복제·수정되며 이름이 뒤섞이기 쉽다. - 여러 레이어를 선택한 뒤 마우스 오른쪽 버튼의 **Rename**을 선택하거나 `Command + R`을 누르면 일괄 변경할 수 있다. - 다음과 같은 방식이 지원된다. - 모든 레이어를 동일한 이름으로 변경 - 숫자 접미사 추가 - 접두사 추가 - 기존 이름의 일부만 변경 - 정규 표현식을 이용한 고급 이름 변경 ### 사용자 지정 썸네일로 파일 구분 - 파일에 사용자 지정 썸네일을 설정하면 파일 브라우저에서 내용을 빠르게 식별할 수 있다. - 설정 방법: - 새 페이지를 만들고 페이지 목록의 가장 위로 이동 - `640x320` 크기의 프레임 하나를 생성 - 프레임 안에 제목, 설명, 이미지 등을 배치 - 프레임 배경색과 캔버스 배경색을 동일하게 설정 - 썸네일에 프로젝트 상태나 버전 정보를 표시하면 파일 탐색과 진행 상황 공유에 유용하다. ### 파일 브라우저 정렬 - 파일 브라우저의 정렬 기능을 사용하면 불필요한 파일을 쉽게 찾을 수 있다. - **File Name**으로 정렬하면 `Untitled`처럼 이름이 정리되지 않은 파일을 확인할 수 있다. - 다음 기준으로도 정렬할 수 있다. - 생성일 - 최종 수정일 ### 팀 라이브러리의 컴포넌트 정리 - 디자인 시스템을 정리할 때는 팀 라이브러리에 등록된 컴포넌트가 실제로 필요한지 검토해야 한다. - 중복되거나 더 이상 사용하지 않는 컴포넌트는 컴포넌트 탭에서 마우스 오른쪽 버튼을 클릭한 뒤 **Remove from Library**를 선택해 제거할 수 있다. - 컴포넌트 이름 앞에 `.` 또는 `_`를 붙이는 방식으로 라이브러리에서 제외할 수도 있다. - 이를 통해 팀원이 불필요한 컴포넌트를 찾느라 시간을 낭비하는 것을 줄일 수 있다. ### 프레임과 페이지로 라이브러리 구성 - 컴포넌트 라이브러리와 디자인 시스템은 프레임과 페이지를 사용해 논리적인 컬렉션으로 나누는 것이 좋다. - 이름에 슬래시(`/`)를 여러 번 사용해 계층 구조를 표현하는 대신, 프레임과 페이지로 분류하면 컴포넌트 이름을 더 단순하게 유지할 수 있다. - 체계적인 분류는 팀원이 필요한 컴포넌트를 쉽게 탐색하고 라이브러리를 이해하는 데 도움이 된다. ### 실용적인 정리 순서 - 먼저 파일 브라우저를 이름과 수정일 기준으로 정렬해 불필요한 파일을 선별한다. - 각 파일의 레이어를 일괄적으로 이름 변경해 검색과 탐색이 쉽게 만든다. - 중요한 파일에는 `640x320` 사용자 지정 썸네일을 추가한다. - 마지막으로 팀 라이브러리에서 중복·미사용 컴포넌트를 제거하고, 남은 컴포넌트를 프레임과 페이지로 분류하는 것이 좋다.

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

디자인 시스템 전파의

디자인 시스템의 확산은 UI 키트나 컴포넌트 라이브러리를 만드는 기술적 작업만으로 이루어지지 않으며, 사람과의 협업을 통해 조직 문화로 정착되어야 한다. 특히 페어링은 다른 디자이너·엔지니어와 함께 작업하며 시스템의 문제를 발견하고, 비판을 협력으로 전환하며, 시스템의 가치를 자연스럽게 전파하는 가장 효과적인 방법이다. 디자인 시스템 팀은 “규칙을 지키라”고 요구하기보다 사용자의 일을 더 빠르고 높은 품질로 만들어 주는 파트너가 되어야 한다. ## 디자인 시스템은 기술 프로젝트가 아니라 문화 프로젝트 - UI 키트나 컴포넌트 라이브러리를 혼자 구축하는 것만으로는 조직의 불일치를 해결할 수 없다. - 디자인 시스템은 디자이너, 엔지니어, 제품 관리자, 고객 사이의 관계와 조직 문화를 반영한다. - “파란색을 쓰지 마라”, “이 컴포넌트를 왜 새로 만들었나”처럼 잘못을 지적하는 방식은 디자인 시스템 팀과 다른 팀을 대립 구도로 만들 수 있다. - Gusto는 다음과 같은 소통 장치를 마련했다. - 피드백과 질문을 위한 Slack 채널 - 디자인 시스템 팀의 오피스 아워 - 신규 구성원을 위한 UI 소개 키트 - 그러나 가장 효과적으로 시스템을 전파한 방법은 직접 함께 작업하는 페어링이었다. ## 페어링은 디자인 시스템의 사용자 조사다 - 다른 디자이너와 나란히 작업하면 실제 사용 과정에서 다음을 관찰할 수 있다. - 어떤 컴포넌트와 패턴이 혼란스러운가 - 문서나 Figma 파일에서 어떤 정보가 부족한가 - 기존 시스템에서 이상하거나 잘 작동하지 않는 부분은 무엇인가 - 팀이 사용자의 필요를 추측하는 대신, 실제 사용 데이터를 바탕으로 컴포넌트와 문서를 개선할 수 있다. - 페어링 중에는 다음과 같은 질문에 답할 수 있다. - 디자이너와 엔지니어가 컴포넌트 라이브러리의 존재를 알고 있는가 - HTML·CSS의 최신 모범 사례를 이해하고 있는가 - 특정 컴포넌트를 사용하는 것이 조직 전체에 왜 유리한지 설명하고 있는가 - 개인 작업에서 유용한 레이아웃을 공식 패턴으로 발전시킬 수 있는가 - 오피스 아워는 사용자가 언제 도움을 받아야 하는지 판단하지 못해 참여율이 낮을 수 있지만, 페어링은 실제 작업 흐름 안에서 문제를 발견한다. ## 비판을 협업으로 전환하는 페어링 - 디자인 시스템 팀과의 협업은 추가적인 디자인 리뷰가 아니라, 작업 속도를 높이고 향후 버그를 줄이는 과정처럼 느껴져야 한다. - 초기 디자인 시스템은 복잡하고 문서화가 부족한 경우가 많다. - 사용할 수 있는 색상이 제한되어 있다는 사실 - 이미 동일한 용도의 컴포넌트가 존재한다는 사실 - 특정 구현 방식이 접근성 기준을 위반한다는 사실 - 이런 규칙을 한꺼번에 강요하면 통제적으로 보일 수 있고, 엔지니어는 문서를 무시하며 디자이너는 기존 시스템과 어울리지 않는 UI를 만들 수 있다. - 페어링은 디자인 시스템 팀이 머릿속에만 보관하던 코드베이스의 제약과 조직의 지식을 직접 전달하게 한다. - 동시에 디자인 시스템 팀도 제품 디자이너가 실제로 어떤 일을 해야 하는지 이해하게 된다. - 결과적으로 디자인 시스템 팀은 현장의 요구를 파악하고, 제품 팀은 프런트엔드 컴포넌트와 패턴을 배우면서 양쪽 모두 더 빠르게 작업할 수 있다. ## 시스템의 지지자를 만드는 방법 - 페어링을 경험한 디자이너와 엔지니어는 디자인 시스템을 단순한 규칙 모음이 아니라 자신의 작업을 개선하는 도구로 이해하게 된다. - 직접 협업을 통해 얻은 지식은 각 팀으로 돌아가 자연스럽게 공유될 수 있다. - 디자인 시스템의 채택을 높이려면 규칙 준수를 감시하기보다, 시스템이 창의성을 제한하는 것이 아니라 작업에 “추진력을 더해준다”는 경험을 제공해야 한다. - 이런 경험이 축적되면 디자인 시스템 팀 외에도 시스템을 설명하고 추천하는 내부 전도자(evangelist)가 늘어난다. 실무적으로는 정기적인 페어링 세션을 실제 디자인·개발 과제와 연결하고, 세션에서 발견한 혼란과 요구를 컴포넌트·문서 개선으로 바로 반영하는 것이 좋다.

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