프로토타이핑

139 개의 포스트

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 자동화를 결합하면 원격 팀에서도 디자인·개발 간 피드백과 반복 작업을 크게 줄일 수 있다.

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

피그마 드래프트

Figma Drafts는 완성된 결과물을 공유하기 전, 아이디어를 자유롭게 실험하는 개인 작업 공간이다. 글쓴이는 공개 협업 환경에서 파일의 완성도나 정리 상태를 평가받을까 하는 두려움을 Drafts로 완화했고, 이를 디지털 노트처럼 활용했다. 핵심 원칙은 먼저 만들고 나중에 정리하며, 발전시킬 아이디어만 프로젝트로 옮기는 것이다. ## 공개 협업에서 생기는 부담 - 다른 사람이 작업 중인 파일을 볼 수 있으면 다음과 같은 걱정이 생길 수 있다. - 8px 그리드를 지키지 않았다는 평가 - 레이어 이름을 정리하지 않았다는 지적 - 아이콘을 만드는 과정이나 파일 구조가 미숙해 보일 가능성 - 이 부담 때문에 실제 문제 해결이나 다양한 시도보다 파일을 “보여줄 만한 상태”로 꾸미는 데 시간을 쓰게 된다. - 글쓴이는 이러한 두려움이 공개적이고 협력적인 디자인 환경에서 더 커졌다고 설명한다. ## Drafts의 역할과 장점 - Drafts는 팀이나 프로젝트와 마찬가지로 파일을 보관하는 조직 단위지만, 개인 폴더라는 점이 다르다. - 팀이나 프로젝트의 권한 및 공유 설정에 종속되지 않는다. - Drafts 전체를 다른 사람에게 공개할 수는 없고, 필요한 경우 개별 파일만 선택적으로 공유할 수 있다. - 완성품이 아니라는 의미가 이름에 내포되어 있어, 실험과 미완성 작업을 심리적으로 허용한다. - 디자이너의 블록을 극복하고 색상, 타이포그래피, 화면 흐름 등을 정하기 전에 우선 아이디어를 시각화하는 공간으로 활용할 수 있다. - 글쓴이는 Drafts를 낙서, 스케치, 미완성 목록이 섞여 있는 개인 노트의 디지털 버전으로 사용한다. ## “먼저 만들고, 나중에 정리하기” - Drafts에서는 iOS 앱 아이디어나 Figma 기능을 활용한 실험처럼 빠르게 떠오른 생각을 즉시 기록한다. - 파일 이름이 없거나, 기본 회색 도형만 있거나, 구조가 엉성해도 문제로 보지 않는다. - 중요한 원칙은 **Create first, organize second**이다. - 먼저 다양한 해결책을 시도한다. - 아이디어가 발전한 뒤 파일명, 레이어, 구성 등을 정리한다. - 초기 단계에서 정리와 완성도를 지나치게 신경 쓰면 탐색의 폭이 줄어들 수 있으므로, Drafts에서는 혼란스러운 상태를 작업 과정의 일부로 받아들인다. ## Drafts를 프로젝트로 옮기는 방법 - 아이디어가 더 발전해 팀과 공유하거나 체계적으로 관리해야 할 시점이 되면 Drafts 파일을 프로젝트로 이동한다. - 파일 브라우저에서 파일을 선택한 뒤 원하는 프로젝트로 드래그 앤 드롭하면 된다. - 파일 내부에서 파일명 왼쪽의 “Drafts” 메뉴를 클릭하고 이동할 프로젝트를 선택할 수도 있다. - 예를 들어 와이어프레임을 고해상도 화면으로 발전시키려는 경우, 전체 파일을 프로젝트로 옮기는 방식이 적절하다. ## 원본 보존과 반복 작업 - 아이디어를 여러 페이지나 파일에서 계속 발전시킬 예정이라면, 먼저 Drafts 파일을 복제한다. - 복제본은 Drafts에 남겨 초기 아이디어의 스냅샷으로 보존한다. - 복제한 파일을 프로젝트로 옮겨 팀 작업이나 정리 작업을 진행한다. - Drafts에는 정리되지 않은 원본을 유지하고, 프로젝트 파일에서는 실제 작업에 필요한 요소를 다듬는 방식이다. ## 파일 관리와 검색 - Drafts가 많아지면 파일 브라우저의 필터 기능을 활용할 수 있다. - 파일명, 생성일, 마지막 수정일 등을 기준으로 파일을 찾고 정렬할 수 있다. - 다만 정리 자체를 너무 일찍 시작하기보다, 아이디어가 충분히 발전한 뒤 필요한 파일만 프로젝트로 옮기는 흐름이 권장된다. 개인 작업에서는 Drafts를 “공개 전 검수 공간”이 아니라 자유롭게 실패하고 탐색하는 디지털 스케치북으로 사용하는 것이 좋다. 완성도와 정리는 아이디어가 검증된 뒤에 진행하고, 팀 공유가 필요해졌을 때 파일을 복제하거나 프로젝트로 이동하면 창의성과 협업을 모두 확보할 수 있다.

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

Bulb, 디자인 시스템 Solar

Bulb는 여러 제품의 디자인·코드베이스·패턴이 서로 달랐던 문제를 해결하기 위해 Figma로 디자인 시스템 ‘Solar’를 구축했다. Figma의 브라우저 기반 협업과 팀 라이브러리를 활용해 디자이너뿐 아니라 개발자, 연구자, 콘텐츠 작성자, 이해관계자까지 디자인 과정에 참여하도록 만들었다. 핵심 전략은 제품 전반을 조사한 뒤 디자인 원칙을 세우고, 작고 단순한 컴포넌트와 패턴부터 점진적으로 표준화하는 것이었다. ## Bulb의 성장과 디자인 조직의 과제 - 영국의 친환경 에너지 기업 Bulb는 18개월 동안 2,000% 성장했다. - 디자인팀은 13명 규모로, 여러 제품 그룹에서 엔지니어·PM·리서처·콘텐츠 작성자와 협업했다. - 기존 5~6개 제품은 서로 다른 에이전시가 제작해 다음 문제가 있었다. - 제품마다 다른 코드베이스 사용 - 버튼, 체크박스, 드롭다운 등 디자인 패턴의 불일치 - 시각적 브랜드는 통일되어도 실제 사용 경험은 일관되지 않음 - 새롭게 구성된 디자인팀은 디자인 시스템과 이를 지원할 도구를 처음부터 설계할 수 있었다. ## Figma를 통한 개방적인 협업 - Bulb의 조직 문화는 사업 부문 간 협업과 투명성을 중시했으며, 디자인 도구도 이러한 문화를 지원해야 했다. - 프로젝트별 ‘팟(pod)’에 디자이너, 리서처, 콘텐츠 작성자, 개발자가 함께 참여했다. - Figma에서는 디자이너의 별도 허가 없이도 다른 직군이 파일을 열어 다음 작업을 수행할 수 있었다. - 디자인에 의견과 제안 남기기 - 최신 작업 내용 확인 - 아이디어 스케치와 브레인스토밍 - 프로토타입 제작 및 검토 - 개발자와 디자이너가 설계 과정 전반에서 함께 논의하며 가이드라인과 품질 기준을 확인할 수 있었다. - 비디자이너에게도 복잡하거나 위협적인 도구가 아니어서 사용자 리서처가 디자이너와 직접 아이디어를 발전시키기 쉬웠다. ## Solar 디자인 시스템의 구축 과정 - 목표는 여러 제품에서 일관된 디자인을 보장하는 ‘단일 진실 공급원(single source of truth)’을 만드는 것이었다. - Figma 팀 라이브러리를 활용하면 마스터 컴포넌트를 수정했을 때 이를 사용하는 여러 디자인에 변경 사항이 동기화됐다. - 모든 파일을 브라우저에서 접근할 수 있어 빠르게 움직이는 팀에 적합했다. - 구축 초기에는 Bulb의 각 제품 페이지를 스크린샷으로 수집해 Figma에 시각적 사이트맵을 만들었다. - 이 사이트맵을 통해 제품별 차이와 불일치를 한눈에 파악했다. - 여러 직군이 참여해 디자인 원칙을 정의하고, 이를 기준으로 컴포넌트와 디자인 패턴을 정리했다. - 버튼·체크박스·드롭다운처럼 여러 버전이 존재하던 요소를 검토해 더 단순하고 견고한 패턴을 선택했다. - 정리한 패턴은 8개 제품에 단계적으로 적용됐다. ## 작고 단순하게 유지하는 원칙 - 디자인 시스템은 처음부터 모든 상황을 포괄하려 하기보다 작은 범위에서 시작해야 한다. - Solar는 다음과 같이 복잡도를 의도적으로 낮췄다. - 제한된 색상 팔레트 - 적은 수의 디자인 패턴 - 관리하기 쉬운 단순한 구조 - 시스템이 복잡해질수록 유지보수와 운영이 어려워지므로, 필요한 요소만 포함하고 지속적으로 단순화하는 것이 중요하다. - 디자인 시스템을 여러 직군이 함께 만들면 실제 구현과 사용 맥락을 반영한 표준을 정립할 수 있다. Bulb의 사례는 디자인 시스템을 단순한 UI 컴포넌트 모음이 아니라, 디자인·개발·리서치·콘텐츠가 함께 일하는 협업 기반으로 구축해야 한다는 점을 보여준다. 먼저 제품 간 불일치를 시각화하고, 명확한 원칙을 정한 뒤, 작은 패턴부터 라이브러리화해 점진적으로 확장하는 접근이 실용적이다.

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

Figma Organization을 소개

Figma Organization은 웹 기반 디자인 협업을 대기업 규모로 확장하기 위해 출시된 Figma의 첫 엔터프라이즈급 요금제다. 무제한 팀, 세밀한 권한 관리, 통합 결제와 감사 보고서, 공유 폰트 및 조직 전체 디자인 시스템을 제공해 여러 부서와 제품이 하나의 작업 환경에서 협업하도록 돕는다. 글은 Uber, Volvo, Square 등의 사례를 통해 중앙화와 자율성을 동시에 확보할 수 있다고 설명한다. ## 엔터프라이즈 시장으로의 확장 - Figma는 디자인이 데스크톱과 로컬 파일이 아니라 웹에서 이루어져야 한다는 비전을 바탕으로 성장했다. - 초기에는 새로운 기술을 빠르게 받아들이는 스타트업이 주요 고객이었지만, 5년 후에는 다양한 규모와 산업의 기업이 웹 기반 디자인 프로세스를 채택했다. - Figma Organization은 기업 리더에게 필요한 기능과 디자이너를 위한 협업 기능을 함께 제공한다. - 통합 결제 - 감사 보고서 - 강화된 보안 및 관리 기능 - 공유 폰트 - 무제한 팀 - 조직 전체에서 사용하는 디자인 시스템 ## 무제한 팀과 중앙화된 작업 공간 - 사용자가 만들거나 참여할 수 있는 팀 수에 제한이 없어 조직 내 다양한 제품과 부서가 독립적으로 운영될 수 있다. - 모든 팀의 프로토타입, 디자인 파일, 코드 내보내기, 에셋을 한곳에서 탐색할 수 있다. - 웹 기반이므로 파일과 작업 결과가 항상 최신 상태로 유지된다. - Volvo Cars처럼 여러 브랜드와 사무실, 팀을 관리해야 하는 오래된 대기업은 파일과 디자인 프로세스를 중앙화할 수 있다. - Uber는 과거 파일이 하드 드라이브, 클라우드 저장소, 외부 플러그인 등 여러 장소에 흩어져 있었다. - Figma 도입 후 각 제품 조직이 자율적으로 운영되면서도 전체 조직의 작업과 에셋을 확인할 수 있게 됐다. - 베타 이후 Uber는 전사적으로 Figma를 도입했고, 제품 디자인 작업의 약 90%를 Figma에서 수행하게 됐다. ## 세분화된 팀 공개 범위와 권한 관리 Figma Organization은 기존 프로젝트·파일 단위 권한에 더해 팀 단위의 공개 범위를 설정할 수 있도록 했다. - **Open** - 누구나 팀에 가입할 수 있다. - **Closed** - 누구나 팀을 볼 수 있지만, 가입하거나 프로젝트를 편집하려면 접근 요청이 필요하다. - **Secret** - 초대받은 사람만 팀의 존재를 확인할 수 있다. 이 구조를 사용하면 조직은 공개 협업이 필요한 팀과 제한적인 접근이 필요한 팀을 구분하면서도, 각 제품 조직의 자율성을 유지할 수 있다. ## 조직 전체 디자인 시스템 - 여러 팀이 공통 Component와 Style 라이브러리를 공유할 수 있다. - 디자인 시스템을 별도의 도구가 아니라 실제 디자인 작업이 이루어지는 Figma 안에서 관리할 수 있다. - Square는 100명 이상의 디자이너와 25개 이상의 제품을 Figma로 이전하고, iOS·Android·웹을 위한 6개의 디자인 시스템을 관리했다. - 한 제품의 디자인 시스템을 다른 제품 팀이 탐색해 유사한 문제를 해결하는 방식을 참고할 수 있다. - 예를 들어 Square for Restaurants 팀이 Point of Sale 제품의 고객 프로필 양식을 참고할 수 있다. - 구조는 재사용하되 제품별 브랜드와 맥락에 맞게 조정할 수 있다. - 모든 팀이 동일한 컴포넌트와 동일한 버전을 바라보므로 디자인 시스템의 단일 진실 공급원(single source of truth)을 확보할 수 있다. ## 변경 사항의 자동 전파 - 디자이너는 마스터 디자인 시스템 파일에서 컴포넌트와 스타일을 추가하거나 수정할 수 있다. - 변경 사항을 반영하기 위해 별도의 수동 배포 절차를 거치지 않고, 간단한 작업만으로 사용하는 팀에 업데이트를 알릴 수 있다. - 웹에서 자산이 연결되어 있기 때문에 여러 파일에 흩어진 디자인 요소를 최신 상태로 유지하기 쉽다. - 이를 통해 조직 전체의 일관성을 유지하면서 디자인 시스템 변경 속도도 높일 수 있다. ## 실용적인 시사점 대규모 조직에서는 팀별 자율성을 없애기보다, 중앙화된 파일 구조와 공유 디자인 시스템을 제공하는 방식이 효과적이다. 팀 공개 범위와 권한을 제품·조직의 보안 요구에 맞게 설정하고, 공통 컴포넌트와 스타일을 단일 라이브러리로 관리하면 협업 효율성과 제품 일관성을 함께 높일 수 있다.

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

코인베이스에서 개방

Coinbase는 암호화폐의 복잡성을 낮추고 개방형 금융 시스템을 만들기 위해, 누구나 참여할 수 있는 개방형 디자인 문화를 구축했다. Figma를 도입하면서 디자인·제품·엔지니어링·경영진이 하나의 공간에서 협업하고 실시간으로 피드백을 주고받을 수 있게 되었으며, 그 결과 의사소통과 제품 출시 속도가 개선되었다. 글은 적절한 협업 도구가 디자인을 폐쇄적인 작업이 아닌 조직 전체의 공동 창작 과정으로 바꿀 수 있다고 강조한다. ## 암호화폐를 대중화하는 디자인 - Coinbase는 2,000만 명 이상의 사용자가 디지털 통화를 쉽게 사고팔고 관리하도록 지원한다. - Coinbase Consumer와 Wallet은 블록체인의 복잡한 개념을 추상화해 암호화폐를 일반 사용자에게 전달한다. - 디자인 팀은 다음 네 가지 원칙을 바탕으로 제품을 만든다. - 안내한다(guide) - 역량을 부여한다(empower) - 인간적으로 만든다(humanize) - 단순화한다(simplify) - 기술적 아이디어를 대중이 이해하고 사용할 수 있도록 교육, 안내, 실제 사용 사례를 디자인에 포함하는 것이 중요하다고 본다. ## 개방형 금융 시스템과 개방형 디자인 - Coinbase의 금융 비전처럼 디자인 과정도 개방적이고 투명해야 한다고 주장한다. - 디자인은 디자이너만의 전유물이 아니라 제품 관리자, 엔지니어, 경영진 등 다양한 직군이 참여하는 협업 과정이다. - 기존에는 디자인, 프로토타이핑, 개발 handoff에 서로 다른 도구를 사용했다. - 도구 간 전환으로 인해 다음 문제가 발생했다. - 작업 맥락을 계속 바꿔야 함 - 파일 버전 관리가 어려움 - 피드백과 산출물이 여러 플랫폼에 분산됨 - 디자인 팀의 작업이 다른 구성원에게 보이지 않음 ## Figma 도입으로 사라진 협업 장벽 - 브라우저 기반인 Figma는 별도 설치나 복잡한 배포 없이 링크 하나로 팀에 도입할 수 있었다. - 모든 파일을 온라인에 중앙 저장하고 여러 사람이 같은 공간에서 동시에 작업할 수 있었다. - 디자이너들은 작업을 공개한 상태에서 피드백을 받고 즉시 반복 개선할 수 있게 되었다. - 디자인, 프로토타입, 의견 수렴, 개발 전달 과정이 하나의 환경에 통합되었다. - 다양한 직군이 동일한 파일과 맥락을 보면서 제품에 의견을 남길 수 있어 정보 손실과 커뮤니케이션 비용이 줄었다. ## 하나의 공간에서 이루어지는 공동 작업 - 디자이너, PM, 엔지니어, 리더십이 최신 디자인 파일을 확인하고 의견을 제시할 수 있었다. - 디자인이 더 이상 “블랙박스” 안에서 진행되지 않아 진행 상황과 의사결정이 투명해졌다. - 의견이 Figma 안에 기록되고 추적되면서 이해관계자 간 커뮤니케이션 주기가 짧아졌다. - 모든 구성원이 같은 장소에서 같은 언어로 대화하게 되어 불필요한 관료적 절차가 줄었다. - 공식적인 제품 작업뿐 아니라 굿즈, 포스터 같은 즉흥적인 요청에도 디자인 팀이 함께 파일을 만들고 빠르게 협업했다. ## 더 빠르고 포용적인 디자인 문화 - Figma 도입 후 팀은 더 빠르고 유연하게 움직이며 조직 전체의 정렬 상태도 좋아졌다. - 디자인 팀은 제품을 함께 만들고 더 신속하게 출시할 수 있게 되었다. - 도구의 변화는 단순한 생산성 향상을 넘어, 구성원이 자유롭게 참여하는 조직 문화 형성에 영향을 주었다. - Coinbase는 앞으로도 포용적이고 다양한 문화를 유지하면서 디자이너가 복잡한 도구가 아닌 적절한 환경의 지원을 받아 역량을 발휘하도록 해야 한다고 본다. 실무적으로는 디자인 도구를 직군별로 분리하기보다, 파일·피드백·의사결정·개발 전달을 한곳에 모으는 협업 환경을 구축하는 것이 효과적이다. 특히 참여자를 디자이너로 제한하지 않고 관련된 모든 구성원이 초기 단계부터 의견을 남기게 하면 제품 완성도와 출시 속도를 함께 높일 수 있다.

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

오버레이를 소개합니다 |

Figma는 정적인 화면을 연결하는 기존 프로토타이핑의 한계를 보완하기 위해 Overlays 기능을 출시했다. 이를 통해 모달, 사이드바, 팝오버, 드롭다운처럼 기존 콘텐츠 위에 표시되는 요소를 유연하게 표현하고, 여러 오버레이를 겹쳐 상호작용할 수 있다. 결과적으로 반복적이고 번거로운 프로토타입 제작 과정을 단순화하고 실제 인터페이스에 가까운 사용자 흐름을 구현할 수 있게 됐다. ## 오버레이의 기본 동작 - 두 프레임을 연결한 뒤 속성 패널에서 목적지 프레임을 오버레이로 설정할 수 있다. - 오버레이의 표시 위치와 등장 방식을 설정할 수 있다. - 디바이스 기준 상대 위치를 지원해 모달이나 액션 시트를 자연스럽게 배치할 수 있다. - 툴팁이나 드롭다운처럼 특정 객체를 기준으로 표시해야 하는 요소는 오버레이 위치를 수동으로 조정할 수 있다. ## 여러 오버레이의 중첩 - 하나의 화면 위에 여러 오버레이를 연속해서 표시할 수 있다. - 다단계 구매 과정, 확인 대화상자 등 복잡한 상호작용 흐름을 표현하는 데 적합하다. - 여러 오버레이를 설정하는 방식도 단일 오버레이와 동일해 추가 학습 부담이 적다. ## 오버레이 내부 상호작용 - 오버레이 위의 요소에도 상호작용을 연결할 수 있다. - 프레임을 교체하는 ‘Swap’ 동작을 사용하면 전체 화면을 전환하지 않고 오버레이 내부 상태만 바꿀 수 있다. - 이를 활용해 버튼 호버, 선택 상태, 단계별 콘텐츠 변화 같은 인터랙션을 구현할 수 있다. - Swap은 오버레이를 자동으로 닫지 않으므로, 오버레이를 유지한 채 내용을 갱신하는 흐름에 유용하다. ## 연결 방식과 단축키 - 오버레이 연결을 드래그하는 동안 캔버스에서 바로 Back 또는 Close를 선택할 수 있다. - 레이어 패널에서 별도로 옵션을 찾지 않아도 되므로 연결 작업이 간결해졌다. - 목적지 프레임 위에서 Option 키를 누르면 Swap 연결을 빠르게 선택할 수 있다. - Swap 링크를 활용한 Back 동작은 Swap 연결을 건너뛰고, 마지막으로 Navigate를 사용했던 프레임으로 돌아가도록 구성할 수 있다. ## 기존 프로토타이핑 기능과의 결합 - Overlays는 기존의 인터랙션, 화면 전환, 전환 효과, 디바이스 프레임, 고정 객체, 고급 스크롤 기능과 함께 사용할 수 있다. - 단순히 화면 간 이동만 보여주는 것이 아니라 실제 제품의 메뉴, 팝업, 확인창, 상태 변화까지 하나의 프로토타입에서 재현할 수 있다. - 사용자 테스트나 이해관계자 검토에서 실제 사용 흐름에 가까운 경험을 제공한다. 실무에서는 모달·드롭다운·툴팁처럼 화면 위에 나타나는 요소를 별도 페이지로 복제하기보다 Overlays로 구성하는 것이 효율적이다. 오버레이 내부 상태 변화에는 Swap을 사용하고, 사용자가 흐름을 되돌아가야 할 때는 의도에 맞게 Back 또는 Close를 구분해 설정하는 것이 좋다.

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

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의 강점은 단순한 디자인 도구가 아니라 모든 직군이 같은 맥락에서 협업하는 공통 작업 공간을 제공한다는 데 있다.

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

Figma에서 페이지를

Figma의 Pages는 하나의 파일 안에서 작업을 목적별로 나누어 정리하는 유연한 구조다. 글은 플랫폼, 기능, 디자인 단계, 원자적 디자인 방법론에 따라 Pages를 구성하는 네 가지 방식을 소개하며, 팀 규모와 프로젝트 특성에 맞는 체계를 선택하라고 제안한다. 적절히 나누면 협업, 프로토타이핑, 검색, 개발자 전달이 쉬워진다. ## Pages를 활용한 파일 구조화 - Figma 파일의 왼쪽 탭에 여러 Pages를 만들어 디자인을 분류할 수 있다. - 조직 방식에는 정답이 없으며 회사, 팀, 개인의 작업 방식에 따라 달라진다. - 디자인 파일을 무작정 한 곳에 쌓기보다 작업 목적에 맞게 구분하면 정리보다 디자인 자체에 집중할 수 있다. ## 플랫폼 또는 화면 크기별 구성 - Android, iOS, 데스크톱처럼 여러 플랫폼을 지원하는 제품에 적합하다. - 플랫폼별로 Page를 나누면 각 환경의 프레임 프리셋과 제약 조건을 적용하기 쉽다. - 각 Page에 독립적인 프로토타입을 구성할 수 있어 플랫폼별 사용자 테스트가 간편하다. - 반응형 디자인을 플랫폼별로 비교하고 관리하기에도 유리하다. ## 앱 기능별 구성 - 여러 디자이너가 다양한 기능을 동시에 개발하는 대규모 앱에 적합하다. - 프로필, 홈 화면 등 제품의 주요 기능을 각각 별도의 Page로 분리한다. - 담당 디자이너는 특정 기능에 집중하면서도 다른 Page를 참고해 전체 제품과의 일관성을 유지할 수 있다. - 기능별로 별도의 프로토타입을 만들어 특정 사용자 흐름만 독립적으로 테스트할 수 있다. ## 디자인 프로세스 단계별 구성 - 아이디어부터 최종 결과물까지 작업 진행 상태를 명확히 보여줄 수 있다. - 예를 들어 다음과 같이 Page를 구성할 수 있다. - 썸네일 → 와이어프레임 → 디자인 → 아카이브 - 문서·리서치 → 작업 중인 시안 → 리뷰 준비 - 사이트맵 → 와이어프레임 → 목업 → QA → 마케팅용 스크린샷 - `Done` Page에 완료된 디자인을 모으면 개발자는 실제로 구현해야 할 결과물을 쉽게 확인할 수 있다. - 초기 아이디어와 브레인스토밍을 별도 Page에 두면 완성도 높은 화면이 작업 중인 시안에 묻히지 않는다. - 팀이 복잡한 체계를 원하지 않는다면 단순히 “진행 중”과 “완료” 정도로 나누는 방식도 가능하다. ## Atomic Design 방법론에 따른 구성 - 디자인 시스템을 원자적 디자인 방식으로 운영할 때 적합하다. - 구성 요소의 계층에 따라 Page를 분리한다. - Atoms: 타이포그래피, 아이콘 등 기본 요소 - Molecules: 버튼 등 조합된 컴포넌트 - Organisms: 전체 페이지처럼 복잡한 구성 - Team Library에서 Page 이름을 기준으로 컴포넌트를 찾기 쉬워진다. - 레이어 이름에 컴포넌트 유형을 반복해서 넣지 않아도 된다. - 예: `button-selected`, `button-hovered` 대신 `selected`, `hovered`처럼 상태만 이름에 표시 - 결과적으로 레이어 패널이 단순해지고 컴포넌트 검색과 관리가 쉬워진다. 프로젝트의 핵심 기준을 먼저 정한 뒤 Pages를 구성하는 것이 좋다. 여러 플랫폼을 지원하면 플랫폼별로, 협업 규모가 크면 기능별로, 개발 전달이 중요하면 프로세스 단계별로 나누고, 디자인 시스템 중심이라면 Atomic Design 구조를 적용하면 된다.

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

디자이너들이 피

Uber는 다양한 국가와 사용자층을 고려한 현지화된 경험 설계를 통해 교통 서비스를 확장했다. 특히 현금 결제가 필요한 신흥 시장을 공략하는 과정에서, Figma의 실시간 협업과 중앙 집중식 파일 관리가 디자인·리서치·엔지니어링 간 소통을 크게 개선했다. 결과적으로 팀은 최신 디자인을 공유하고 빠르게 피드백을 반영하며, 지역과 조직 규모에 관계없이 더 빠르게 제품을 발전시킬 수 있었다. ## 전 세계 사용자를 위한 디자인 - Uber는 65개국에서 7,500만 명의 승객이 연간 40억 회 이용하는 글로벌 물류 플랫폼으로 성장했다. - 국가별 사용자 경험을 설계할 때 다음 요소를 고려한다. - 언어 - 문해력 - 사용하는 기기 - 문화 - 지역적 특성 - 승객·운전자 등 사용자의 역할 - 제품팀은 설계 전에 현지 시장과 사용자에 대한 심층 조사를 수행한다. - 디자이너가 여러 국가에서 운전자와 직접 탑승하며 실제 환경에서 새로운 사용자 경험을 테스트하기도 한다. ## 신흥 시장의 현금 결제 설계 - 은행 계좌나 신용카드를 사용하기 어려운 사용자를 위해 Uber는 일부 시장에 현금 결제를 도입했다. - 현금 결제 기능은 제품 관리자, 디자이너, 운영 담당자, 데이터 과학자, 엔지니어가 함께 개발했다. - 기존 디자인 도구에서는 다음과 같은 비효율이 발생했다. - 디자인·프로토타이핑·공유·피드백 수집에 여러 도구를 사용 - 파일을 반복적으로 가져오고 내보내야 함 - 진행 상황을 별도 커뮤니케이션 채널에서 공유 - 한 번에 한 사람만 파일을 수정할 수 있음 - 현지 운전자와 프로토타입을 테스트하면서 실시간으로 수정하려 했지만, 협업 편집이 불가능해 즉각적인 반복 작업이 어려웠다. ## Figma를 통한 실시간 협업 - 디자이너 Femke van Schoonhoven은 다른 Uber 팀이 사용하던 웹 기반 협업 도구 Figma를 도입했다. - 기존 디자인 파일을 Figma로 드래그 앤 드롭해 쉽게 이전할 수 있었다. - 현지 언어와 실제 사용 맥락을 반영한 디자인을 만들면서 팀원들과 동시에 작업할 수 있었다. - 팀원들이 지역과 시간대에 관계없이 같은 디자인 파일에서 실시간으로 협업했다. - 파일 구조와 정리 방식도 직관적이어서 필요한 자료를 쉽게 찾을 수 있었다. - Figma는 여러 디자인 파일과 버전을 한곳에서 관리하는 중앙 저장소 역할을 했다. ## 단일 디자인 소스와 커뮤니케이션 효율화 - 이전에는 최신 디자인 버전을 알리기 위해 이해관계자에게 이메일을 반복해서 보내야 했다. - Figma에서는 팀원들이 폴더에서 언제든 최신 디자인을 확인할 수 있었다. - 디자인 파일 안에서 직접 댓글을 남길 수 있어 별도 이메일이나 메신저로 맥락을 설명할 필요가 줄었다. - van Schoonhoven은 커뮤니케이션 오버헤드가 최소 75% 감소했다고 설명했다. - 엔지니어를 디자인 파일에 초대해 최신 변경 사항과 맥락이 포함된 댓글을 함께 확인하도록 했다. - 엔지니어가 초기 단계부터 디자인 과정에 참여하면서 핸드오프가 더 빠르고 간단해졌다. ## 분산된 팀을 하나로 연결 - 여러 지역에 흩어진 팀원들이 동일한 파일과 목표를 공유할 수 있었다. - 과거에는 업무가 팀별로 분리되어 있었지만, Figma 도입 후 공동 작업 기반이 마련됐다. - 웹 기반 도구이므로 이해관계자가 파일을 쉽게 공유하고 상위 승인도 빠르게 받을 수 있었다. - 결과적으로 디자인 검토와 의사결정 속도가 빨라졌고, 팀 전체의 작업 효율이 향상됐다. Figma의 사례는 글로벌 제품에서 현지화 자체만큼이나 협업 방식이 중요하다는 점을 보여준다. 여러 국가의 사용자와 분산된 팀을 상대한다면, 최신 디자인을 한곳에서 관리하고 디자인·개발·피드백을 실시간으로 연결하는 협업 환경을 구축하는 것이 효과적이다.

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

새로운 Principle 연동 기능

Figma가 프로토타이핑 도구 Principle과 연동되어, Figma에서 만든 정적 디자인에 고급 애니메이션과 인터랙션을 추가할 수 있게 되었다. 사용자는 코딩 없이 스크롤, 스와이프, 버튼 상태 변화, 스프링·이징·선형 전환 등을 구현해 실제 모바일 앱과 유사한 프로토타입을 만들 수 있다. 또한 Figma에서 디자인을 수정하면 Principle이 변경 사항을 감지해 기존 애니메이션을 유지한 채 동기화한다. ## Figma와 Principle의 통합 - Principle에서 Figma를 가져오기 소스로 인증하면 Figma 디자인을 Principle로 불러올 수 있다. - Figma의 화면과 객체를 기반으로 Principle에서 인터랙션과 모션을 설정한다. - 정적인 UI 시안을 실제 앱처럼 동작하는 프로토타입으로 발전시킬 수 있다. - 이 통합은 Figma의 웹 기반 API를 활용해 구축되었다. ## 구현할 수 있는 인터랙션과 애니메이션 - 페이지에 스크롤 동작 추가 - 이미지 카드 사이의 스와이프 전환 구현 - 사용자의 상호작용에 따른 버튼 상태 변화 설정 - 객체 간 전환 애니메이션 적용 - 스프링(spring) - ease in - ease out - 선형(linear) 전환 - 별도의 코딩 없이 모바일 앱에 가까운 동작과 화면 전환 표현 ## 코딩 없이 사용하는 시각적 프로토타이핑 - Principle은 인터페이스 디자이너에게 익숙한 시각적 UI를 제공한다. - 디자인과 엔지니어링 작업을 오가는 대신, 디자이너가 시각적·창의적 사고에 집중할 수 있도록 설계되었다. - 초보자도 비교적 쉽게 사용할 수 있으며, 복잡한 프로토타입을 만들면서도 코드를 배울 필요가 없다. - 단순한 사용성과 강력한 애니메이션 기능의 균형이 Principle의 장점으로 소개된다. ## Figma 수정 사항의 동기화 - 이미 Principle로 가져온 디자인을 Figma에서 수정해도 두 도구 사이의 동기화가 가능하다. - Principle은 Figma의 변경 사항을 자동으로 인식하고 기존 작업에 병합한다. - 예를 들어 Figma에서 버튼 크기를 변경하면 Principle에서도 버튼 크기가 자동으로 조정된다. - 이때 Principle에서 설정한 기존 애니메이션은 유지된다. - 따라서 디자인 수정 때마다 프로토타입의 인터랙션을 처음부터 다시 설정할 필요가 없다. ## 개발자를 위한 Figma API 활용 - Principle 제작자는 Figma의 API 문서와 도구를 활용해 연동 기능을 개발했다. - Figma의 API Explorer에서는 특정 Figma 파일 ID를 입력해 API 호출 결과를 확인할 수 있다. - 개발자는 API의 기본 구성 요소와 파일 데이터 구조를 직접 테스트하며 연동 방식을 이해할 수 있다. - 이는 디자인 도구를 외부 서비스와 연결하려는 개발자에게 실용적인 검증 환경을 제공한다. ## 활용과 의의 - Figma는 화면 설계에, Principle은 모션과 인터랙션 구현에 특화된 역할을 맡는다. - 두 도구를 함께 사용하면 디자인 단계에서 사용자 경험을 더 현실적으로 검증할 수 있다. - 디자이너는 개발에 넘기기 전에 전환 효과와 인터랙션의 완성도를 확인할 수 있다. - 통합 기능은 Figma 사용자들의 지속적인 요청에 대한 대응으로 제공되었다. 실무에서는 Figma에서 레이아웃과 시각 디자인을 관리하고, Principle에서 핵심 사용자 흐름과 애니메이션을 빠르게 검증하는 방식이 효과적이다. 특히 디자인 변경 후에도 애니메이션이 유지되므로, 반복적인 프로토타입 수정 작업을 줄일 수 있다.

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

구글의 AR 디자인 가이드

Google의 AR 디자인 가이드라인은 Apple보다 범위가 넓고 실용적이지만, 두 가이드 모두 단순한 단일 장면과 객체 배치에 지나치게 집중한다. 따라서 복잡한 상호작용, 다중 장면, 애니메이션, 협업 환경 등 실제 3D UX 설계에 필요한 문제를 충분히 다루지 못한다. 결국 AR 디자인의 발전은 공식 문서보다 디자이너와 업계가 직접 새로운 관행과 도구를 만들어가는 과정에 달려 있다. ## 모바일 AR의 대중화와 새로운 설계 과제 - Google의 ARCore와 Apple의 ARKit 등장으로 3D UX가 VR 헤드셋 중심에서 모바일로 이동했다. - 모바일 개발자라면 수억 명의 Android·iOS 사용자에게 AR 경험을 제공할 수 있게 되었다. - 그러나 기존 2D 앱 디자인과 달리 3D에서는 공간, 깊이, 물리, 장면 전환 등을 고려해야 한다. - 게임·영화·건축 등 서로 다른 분야에서 가져온 도구와 복잡한 작업 흐름 때문에 디자이너가 쉽게 접근하기 어려웠다. ## Apple과 Google 가이드라인의 범위 - Apple은 Human Interface Guidelines의 AR 항목에서 비교적 제한적인 내용을 제공한다. - Apple의 설명은 주로 ARKit의 평면 인식과 그 위에 객체를 배치하는 기본 사용 사례에 집중한다. - Google의 AR Design Guidelines는 AR Stickers와 Just a Line 같은 실제 제품 경험을 바탕으로 더 폭넓은 주제를 다룬다. - Google은 다음과 같은 객체 배치 방식을 제시한다. - 탭해서 배치 - 드래그해서 배치 - 자유 배치 - 객체 배치의 현실감을 높이기 위해 물리 효과를 활용하는 방법도 간략히 설명한다. - 이후 UI 컴포넌트와 온보딩을 포함한 “경험 설계” 관련 내용도 추가되며 지속적으로 확장되고 있다. ## 복잡한 AR 상호작용을 다루지 못하는 문제 두 가이드라인은 단순한 객체 배치나 스티커형 기능을 넘어서는 설계를 거의 다루지 않는다. - 객체 선택 및 선택 상태 관리 - 다른 객체에 가려진 객체 선택 - 조건에 따른 동작 변화 - 사용자의 행동에 따른 분기형 장면 흐름과 스토리보드 - 텔레포테이션을 통한 장면 이동 - 포털과 공간 간 연결 - 물리적 제스처 기반 상호작용 - 시간 또는 사용자 행동에 의해 실행되는 애니메이션 - 여러 장면 사이의 상태 변화와 개인화 - 원격 사용자와 함께 AR 프로토타입을 확인하고 피드백하는 실시간 협업 특히 다중 장면 사용 사례가 빠져 있어, 복잡한 전환과 조건부 동작을 설계하기 어렵다. 이는 더 깊고 몰입감 있는 AR 경험을 만들려는 디자이너의 요구와 맞지 않는다. ## 객체 배치 방식에 대한 한계 - Google은 사용자가 손을 뻗어 닿을 수 있는 거리 안에 객체를 배치하는 것이 최적이라는 전제를 둔다. - 그러나 실제로는 객체를 던지거나, 멀리 있는 대상을 가리키거나, 잡아당기는 방식도 가능하다. - 따라서 특정 거리나 방식만을 최적의 규칙으로 고정하기보다, 다양한 상호작용을 실험할 여지가 필요하다. - Apple이 평면 감지 기반 배치만 설명하는 것과 비교하면 Google의 접근은 훨씬 구체적이지만, 여전히 복잡한 공간 상호작용까지는 확장되지 않았다. ## 업계가 직접 만드는 3D UX 관행 - 공식 가이드라인은 빠르게 변화하는 AR 기술과 수많은 창의적 실험을 모두 따라가기 어렵다. - 디자이너들은 기존 도구를 조합해 새로운 프로토타이핑 및 제작 프로세스를 구축하고 있다. - Unity의 Bushra Mahmood처럼 개인이 독자적인 AR 디자인 가이드라인을 만들기도 한다. - Marino Software 같은 팀은 기존 도구를 혼합해 작동하는 AR 앱과 새로운 작업 방식을 실험하고 있다. - 이러한 풀뿌리 활동은 3D UX의 실제 모범 사례를 형성하는 데 중요한 역할을 한다. ## 실용적인 결론 현재 AR 프로젝트를 시작한다면 Google의 가이드라인을 기본 출발점으로 활용하되, 이를 완성된 설계 규칙으로 받아들여서는 안 된다. 다중 장면, 상태 변화, 애니메이션, 제스처, 협업 같은 요구사항을 별도로 정의하고, 실제 기기에서 반복적으로 프로토타이핑하며 프로젝트에 맞는 3D UX 원칙을 직접 구축하는 것이 바람직하다.

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

월풀을 담당하는 에이전

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 요소를 디자인 시스템과 공유 라이브러리로 관리하면 협업 속도와 결과물의 일관성을 함께 높일 수 있다.

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

피그마 기능 하이라이트

Figma의 컴포넌트 오버라이드는 디자인 시스템의 일관성을 유지하면서도 각 인스턴스를 상황에 맞게 수정할 수 있게 해준다. 인스턴스를 분리하지 않고 색상, 텍스트, 스타일 등을 변경할 수 있으며, 원본 컴포넌트가 업데이트되면 수정되지 않은 속성은 계속 상속된다. 따라서 반복되는 UI를 효율적으로 관리하면서도 다양한 상태와 콘텐츠를 표현할 수 있다. ## 디자인 시스템에서 유연성과 일관성의 균형 - 리스트, 아바타, 상태 표시줄처럼 여러 곳에서 반복되는 기본 컴포넌트는 일관된 디자인을 유지해야 한다. - 동시에 리스트의 텍스트, 상태 표시줄의 색상처럼 사용 맥락에 따라 달라지는 부분도 필요하다. - 모든 변형을 처음부터 새로 만들면 작업량이 늘고 디자인 시스템과의 연결도 끊어진다. - 오버라이드는 원본 컴포넌트의 구조는 유지하면서 인스턴스별 차이만 적용하는 방식이다. ## 컴포넌트 오버라이드의 작동 방식 - 인스턴스를 원본 컴포넌트에서 분리하지 않고 속성을 재정의할 수 있다. - 원본 컴포넌트를 수정하면 각 인스턴스는 오버라이드되지 않은 변경 사항을 계속 상속한다. - 인스턴스별로 변경 가능한 속성에는 다음이 포함된다. - 색상과 채우기 - 텍스트와 텍스트 정렬 - 글꼴 및 스타일 - 선의 추가, 삭제, 수정 - 불투명도와 블렌드 모드 - 그림자와 블러 같은 효과 - 요소의 표시·숨김 상태 ## 실제 활용 사례 - **정보 목록 만들기** - 하나의 셀 컴포넌트를 만든 뒤 각 인스턴스의 텍스트를 오버라이드한다. - 할 일 목록이나 대시보드 테이블처럼 서로 다른 데이터를 일관된 형태로 표현할 수 있다. - **버튼 상태 표현하기** - 하나의 버튼 컴포넌트를 기반으로 기본, 호버, 클릭, 비활성 상태를 만든다. - 배경색, 텍스트 불투명도, 그림자 등을 상태별로 변경할 수 있다. - **주소록 아바타 구성하기** - 원형 컴포넌트의 채우기를 각 인물의 사진으로 교체한다. - 아바타의 공통 형태는 유지하면서 이미지 콘텐츠만 다르게 적용할 수 있다. ## 오버라이드를 활용한 케일리도스코프 - 하나의 일러스트를 프레임에 그리고 컴포넌트로 변환한다. - 인스턴스를 복제해 오른쪽에 배치한 뒤 수평 반전한다. - 다시 복제해 아래쪽에 배치하고 수직 반전한다. - 남은 공간에 인스턴스를 하나 더 배치해 2×2 형태를 만든다. - 왼쪽 위의 원본 컴포넌트 안에서 그림을 수정하면 연결된 인스턴스들이 함께 바뀌며 대칭 패턴이 만들어진다. 컴포넌트 오버라이드는 공통 구조와 스타일은 원본에 맡기고, 콘텐츠와 상태처럼 달라져야 하는 부분만 인스턴스에서 수정하는 데 적합하다. 반복 UI를 컴포넌트로 만든 뒤 필요한 속성만 오버라이드하면, 유지보수성과 디자인의 다양성을 함께 확보할 수 있다.

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

프로토타이핑 위크의

Figma는 프로토타입이 실제 제품처럼 반응하도록 다양한 사용자 입력 기반의 **Interactions** 기능을 공개했다. 클릭·호버·누르기뿐 아니라 마우스 진입/이탈과 누름·해제, 일정 시간 후 전환까지 지원해 사용자 테스트의 현실성을 높인다. 또한 Prototyping Week 동안 가로형 디바이스 프레임, 외부 URL 연결, 뒤로 가기 전환도 함께 출시했다. ## 사용자 입력에 반응하는 Interactions - Figma에서 지원하는 상호작용은 다음과 같다. - **On Click**: 클릭 시 화면이나 상태 전환 - **While Hovering**: 마우스를 올리고 있는 동안 상태 변경 - **While Pressing**: 누르고 있는 동안 눌림 상태 표시 - **Mouse Enter / Mouse Leave**: 마우스가 영역에 들어오거나 나갈 때 동작 - **Mouse Down / Mouse Up**: 마우스 버튼을 누르는 순간과 놓는 순간의 동작 - **After Delay**: 지정한 시간이 지나면 자동 전환 - 디바이스 프레임을 선택한 경우 일부 상호작용은 모바일 환경에 맞춰 **On Tap, Touch Down, Touch Up**으로 표시된다. ## 버튼 상태와 메뉴 동작 구현 - **On Click**, **While Hovering**, **While Pressing**은 버튼이나 목록 항목의 상태를 표현하는 데 유용하다. - 예를 들어 메뉴 항목에 마우스를 올리면 배경색을 바꾸어 실제 웹 UI의 호버 상태를 재현할 수 있다. - **Mouse Enter**와 **Mouse Leave**를 사용하면 드롭다운 메뉴처럼 더 세밀한 동작을 구현할 수 있다. - Mouse Enter로 메뉴를 열면 사용자가 다른 상호작용을 수행할 때까지 메뉴가 열린 상태를 유지하도록 만들 수 있다. - 이러한 기능은 단순한 화면 연결을 넘어, 실제 제품의 입력 피드백과 상태 변화를 프로토타입에 반영한다. ## After Delay를 활용한 자동 전환 - **After Delay**는 특정 시간이 지나면 자동으로 다음 화면으로 이동시킨다. - 알림 표시, 자동 리디렉션, 일정 시간이 지난 뒤 나타나는 화면 등을 표현할 수 있다. - 이 전환은 특정 하위 레이어가 아니라 프레임 전체와 연결되므로, 한 화면에서 다른 화면으로만 설정할 수 있다. ## Prototyping Week의 추가 출시 기능 ### 가로형 디바이스 프레임 - 기존 발표용 디바이스 프레임 기능을 가로 방향 화면에도 적용할 수 있게 했다. - 모바일 가로 화면이나 태블릿처럼 sideways로 보는 디자인을 실제 기기 형태에 가깝게 보여준다. ### Clickable URLs - 프로토타입 프레임에서 외부 웹사이트나 다른 Figma 파일로 연결되는 링크를 만들 수 있다. - 예를 들어 발표 자료 마지막 화면에서 개인 웹사이트나 포트폴리오로 바로 이동시킬 수 있다. ### Back Transitions - 사용자가 이전 화면으로 돌아갈 수 있는 뒤로 가기 전환을 제공한다. - 하나의 화면이 여러 경로에서 접근되더라도 화면을 복제하거나 경로별 전환을 따로 만들 필요가 없다. - 현재 프레임으로 이동할 때 애니메이션 전환을 사용했다면, 뒤로 갈 때 해당 애니메이션이 역방향으로 재생된다. ## 향후 방향 - Figma 팀은 추가 프로토타이핑 기능을 개발 중이며, 당시 커뮤니티에서는 특히 **오버레이(Overlays)** 기능에 대한 요구가 많았다. - Figma는 사용자 의견과 리서치를 바탕으로 프로토타이핑 기능의 우선순위와 형태를 발전시키고자 했다. 실무에서는 기본 화면 이동만 연결하기보다 호버·눌림·드롭다운·자동 전환을 함께 구성하는 것이 좋다. 이를 통해 실제 사용 흐름에 가까운 프로토타입을 만들고, 개발 전에 인터랙션과 사용자 경험을 더 정확하게 검증할 수 있다.

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

투명하고 개방적인 디자인이

Citrusbyte는 완성된 시안만 공개하는 대신, 작업 중인 디자인 파일을 클라이언트와 실시간으로 공유하는 ‘투명한 오픈 디자인’을 실천한다. Figma의 클라우드·실시간 협업 기능 덕분에 피드백 과정이 빨라지고 불필요한 파일 전달과 커뮤니케이션이 줄어들었다. 그 결과 프로젝트 이해도와 고객 참여가 높아졌으며, 디자이너의 작업 시간과 리뷰 주기도 크게 단축됐다. ## 전통적인 비공개 디자인 프로세스의 한계 - 디자이너는 완성도가 충분히 높아질 때까지 작업물을 외부에 공개하지 않는 경우가 많다. - 기존에는 Sketch나 Photoshop 파일을 내보내 이메일로 보내거나, Dropbox·Google Drive에 동기화해야 했다. - 클라이언트가 프로젝트의 진행 상황을 지속적으로 확인하기 어렵고, 최신 파일이 무엇인지 혼란이 생겼다. - PNG·PDF 이미지로 피드백을 주고받으면 클라이언트가 어느 부분을 지칭하는지 명확하지 않아 불필요한 대화가 반복됐다. - InVision 같은 프로토타이핑 도구를 사용할 때도 디자인을 평면 파일로 저장한 뒤 새 버전을 다시 업로드해야 했다. ## 클라이언트에게 작업 과정을 공개하는 이유 - Citrusbyte는 초기 단계부터 클라이언트가 프로젝트의 발전 과정을 볼 수 있어야 한다고 판단했다. - Figma에서는 하나의 링크로 항상 최신 디자인 파일에 접근할 수 있다. - 여러 사람이 같은 파일에 동시에 들어와 실시간으로 변경 사항을 확인할 수 있다. - 클라이언트는 완성된 결과물만 받는 것이 아니라, 디자인이 만들어지는 과정 자체에 참여한다. - 작업 상황을 직접 볼 수 있어 프로젝트가 ‘블랙박스’처럼 느껴지지 않고 심리적 안정감이 커진다. - 프로젝트에 직접 참여한 클라이언트는 현재 진행 상황과 의사결정의 맥락을 더 잘 이해하므로 결과물에 대한 공감대와 참여도가 높아진다. ## 미완성 작업을 공개할 때의 위험과 대응 - 작업 중인 파일은 구조가 복잡하거나 시각적으로 정리되지 않아 클라이언트가 결과물을 오해할 수 있다. - 디자이너 입장에서는 미완성 결과물을 보여주는 것이 부담스럽고, 창작 과정이 평가받는 것처럼 느껴질 수 있다. - Citrusbyte는 이를 커뮤니케이션과 기대치 관리로 해결한다. - Pablo Franco는 “자전거를 원하더라도 작업 중인 나를 보면 체인을 조립하고 있는 모습을 보게 된다”는 비유를 사용해, 현재 보이는 화면이 최종 결과물이 아님을 설명한다. - 공개의 목적이 완성품 평가가 아니라 진행 상황 공유와 협업이라는 점을 사전에 합의한다. ## 실시간 피드백으로 빨라지는 협업 - 클라이언트는 디자인 파일에서 직접 변경 사항을 확인하고, 필요한 경우 일부 요소를 스스로 실험할 수 있다. - 예를 들어 헤드라인 문구를 바꿔 어떤 표현이 더 적절한지 직접 비교할 수 있다. - 간단한 문구 수정 때문에 긴 이메일 대화를 주고받는 일이 줄어든다. - 디자이너는 반복적인 수정 요청을 처리하는 대신 핵심적인 디자인 작업에 집중할 수 있다. - 디자인과 프로토타입이 같은 최신 파일에 연결되어 있어 변경 후 별도의 재업로드가 필요 없다. ## Figma 기능이 제거한 불필요한 작업 - Figma의 웹 기반 환경은 파일 버전 관리와 공유 과정을 단순화한다. - 정기적인 클라이언트 리뷰에서는 발표자가 자신의 아바타를 클릭한 사용자가 화면을 따라오도록 하는 ‘관찰 모드’를 활용할 수 있다. - 발표자는 별도의 프레젠테이션용 파일이나 복잡한 플로우 연결 화면을 준비하지 않고, 실제 디자인 파일을 이동하며 설명하면 된다. - 이러한 작은 기능들이 파일 내보내기, 업로드, 발표용 화면 구성 같은 반복 작업을 없앴다. - Citrusbyte의 디자이너 Sam Small은 이전 방식과 비교해 Figma 사용으로 작업 시간이 약 30~50% 절약된다고 평가했다. ## 생산성과 고객 만족도 향상 - 작업 과정이 투명해지면서 클라이언트가 프로젝트에 더 많이 참여하고 결과물에 대한 이해도도 높아졌다. - 피드백 전달 위치가 명확해져 커뮤니케이션 왕복 횟수가 감소했다. - 리뷰 준비에 들던 시간이 줄어들어 공격적인 일정의 프로젝트도 수행하기 쉬워졌다. - Citrusbyte는 절약된 시간만큼 더 많은 프로젝트를 맡을 수 있었다. - 고객사 SundaySky는 Figma를 사용한 프로젝트에서 리뷰 주기가 절반으로 줄어든 점을 긍정적으로 평가했다. - Citrusbyte는 스타트업 중심의 고객 기반에서 Apple, Sony, Intel, AT&T 등 Fortune 1000 기업으로 사업을 확장했으며, 투명한 협업 방식이 이러한 성장과도 연결된다고 설명한다. ## 실용적인 적용 방법 - 프로젝트 시작 전에 클라이언트에게 작업 중인 화면이 미완성 상태일 수 있음을 명확히 알린다. - 하나의 최신 Figma 파일을 프로젝트의 기준점으로 삼고, 이메일 첨부 파일이나 중복된 버전 생성을 줄인다. - 클라이언트가 직접 확인하고 의견을 남길 수 있도록 적절한 접근 권한을 제공한다. - 정기 리뷰에서는 관찰 모드와 실시간 화면 공유를 활용해 별도 발표 자료 제작을 최소화한다. - 투명성은 단순히 파일을 공개하는 것이 아니라, 진행 과정·피드백 방식·기대 결과를 함께 합의하는 협업 문화로 운영해야 한다.

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