figma·2024년 2월 26일·3분 읽기큐레이션 요약

니콜 뵈쳐의 피그

니콜 부에처는 전직 UX·제품 디자이너로서 Figma를 활용해 퀼트를 설계하고, 디지털 디자인의 반복·측정·최적화 방식을 수공예에 적용한다. 그녀는 천을 자르기 전에 퀼트의 약 80%를 Figma에서 완성하며, 색상 조합과 패턴을 빠르게 실험하고 필요한 원단 수량과 재단 순서까지 계획한다. Figma는 창의적인 퀼트 작업을 체계화하면서도, 재료와 시간을 절약하게 해주는 설계 도구가 된다. ## 손으로 만드는 취미와 디지털 설계의 결합 - 니콜은 2021년 팬데믹으로 업무 방식이 바뀌면서 손을 사용하는 새로운 공예를 찾기 시작했다. - Artsy에서 2년 반 동안 제품 디자이너로 일한 경험이 있으며, 이전에도 간단한 봉제 작업은 했지만 퀼트 제작은 미뤄두고 있었다. - 온라인 튜토리얼과 초보자용 패턴을 따라 하며 독학했고, 실력이 늘면서 더 큰 퀼트를 만들게 됐다. - 직접 패턴을 설계할 단계가 되자 익숙한 도구인 Figma를 사용하기 시작했다. ## UX 경험을 바탕으로 한 계획적 제작 - 니콜은 천을 자르기 전에 퀼트 디자인의 약 80%를 Figma에서 완성한다. - UX 디자인과 엔지니어링용 에셋 준비 경험 때문에 즉흥적으로 만들기보다 먼저 구조와 치수를 계획하는 편이다. - 퀼트 제작은 각 조각을 1/4인치 단위로 측정해야 하므로, 정확한 크기 조정이 가능한 Figma가 적합하다. - 스케치나 종이 조각을 직접 옮기는 방식보다 도형의 비율과 배치를 빠르게 수정할 수 있다. ## 색상 라이브러리와 패턴 실험 - 영감은 퀼트 관련 서적과 Instagram에서 얻으며, 전통적인 퀼트 블록을 새로운 패턴으로 변형하는 방식으로 작업을 시작한다. - 이미 가지고 있는 원단을 우선 활용하기 위해 원단 제조사의 색상 견본을 Figma에 모아 색상 라이브러리를 구축했다. - 디자인 파일에서 특정 영역을 선택해 색상이나 패턴을 한꺼번에 바꿀 수 있다. - `Random Colors Fill` 같은 Figma 플러그인을 활용하면 다양한 색상 조합을 빠르게 시험할 수 있다. - 제품 디자인처럼 하나의 퀼트에 대해 수십 가지 버전을 만든 뒤 최종안을 선택한다. ## Figma에서 퀼트 구조 설계하기 - Grid Quilt처럼 격자 구조의 디자인을 Figma에서 먼저 구성한다. - 각 행을 개별적으로 수정하는 대신 Auto Layout을 사용해 여러 행의 배치를 동시에 조정할 수 있다. - 완성된 전체 디자인을 재단과 봉제에 필요한 작은 단위 조각으로 분해한다. - 조각을 어떤 순서로 연결할지까지 시각적으로 확인해 제작 과정을 단순화한다. ## 치수 계산과 원단 낭비 줄이기 - 최종 디자인을 복제한 뒤 사각형과 직사각형 등 원자 단위의 조각으로 나눈다. - `Count Things` 플러그인으로 필요한 조각의 개수를 계산한다. - 예: 청록색 직사각형 189개, 황갈색 정사각형 378개 등 - Figma의 픽셀 크기를 실제 인치 단위와 대응시켜 재단에 필요한 치수를 산출한다. - 봉제선 여유분을 고려해 각 조각의 양쪽에 1/4인치를 추가한다. - 필요한 원단의 총 길이를 계산하고, 조각을 최대한 효율적으로 배치해 불필요한 자투리 원단을 줄인다. - 어떤 조각을 먼저 봉제할지 다시 조정해 전체 작업 단계를 최소화한다. ## 디지털 도구가 공예에 주는 의미 - Figma는 단순한 화면 디자인 도구가 아니라 실제 재료를 다루는 제작 과정의 계획 도구로 활용된다. - 반복적인 시안 제작, 정확한 치수 계산, 색상 관리, 재단 최적화를 하나의 파일 안에서 처리할 수 있다. - 디지털 설계의 효율성이 수작업의 섬세함을 대체하는 것이 아니라, 수작업에 더 많은 시간과 집중력을 투입하도록 돕는다. - 니콜의 사례는 특정 산업을 위해 만들어진 도구도 사용자의 창의적인 방식에 따라 전혀 다른 제작 분야로 확장될 수 있음을 보여준다. 실용적으로는 퀼트처럼 규격과 반복이 중요한 작업을 시작할 때 Figma에서 색상 견본, 실제 치수, 조각 수량, 조립 순서를 먼저 관리하면 시행착오와 재료 낭비를 크게 줄일 수 있다.

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

Figma사용자 경험프로덕트 디자인auto-layout+2

figma·2024년 2월 26일·3분 읽기큐레이션 요약

기능 비하인드:

Figma는 프로토타입을 실제 기기에서 사용하는 경험에 가깝게 만들기 위해 모바일·태블릿·워치용 **인라인 디바이스 프레임**을 에디터 안에 도입했다. 사용자는 프레젠테이션 화면으로 이동하지 않고도 디자인 옆에서 기기 프레임을 배치·이동·크기 조절하며 프로토타입을 확인할 수 있다. 이 기능은 다양한 기기 형태를 반영하면서도 자연스러운 상호작용과 협업 중심의 디자인 프로세스를 유지하는 것을 목표로 개발됐다. ## 프로토타이핑을 현실에 가깝게 만드는 이유 - 실제 기기를 손에 들고 화면과 플로우를 확인하면 제품이 실제로 어떻게 작동하는지 더 잘 이해할 수 있다. - 프로토타입은 개발 전에 사용성 문제, 설계의 빈틈, 개선 기회를 발견하게 해준다. - Figma는 2023년 Config에서 실시간으로 프로토타입을 확인하는 **인라인 프리뷰**를 선보였고, 이후 기기 프레임까지 에디터 내부로 확장했다. - 프레젠테이션 뷰로 이동하지 않아도 디자인 작업과 실제 기기 맥락 확인을 동시에 할 수 있게 된 것이 핵심이다. ## 협업을 기반으로 한 기능 설계 - Figma는 기존 프레젠테이션 뷰에서 제공하던 다양한 기기 프리셋이 인기가 높다는 점에 주목했다. - 이를 에디터 안으로 가져와 디자인 옆에서 휴대폰, 태블릿, 워치 프레임을 사용할 수 있도록 했다. - 제품 디자이너, 엔지니어, 제품 관리자, 마케팅 담당자와 사용자 커뮤니티의 의견을 함께 반영했다. - 개발 과정에서 세운 핵심 원칙은 다음과 같다. - 디자인 작업 흐름에 자연스럽게 통합할 것 - 다양한 실제 기기를 현실적으로 표현할 것 - 기기의 상호작용 영역을 직관적으로 설계할 것 - 목표는 단순한 정적 이미지가 아니라, 사용자가 잡고 이동하고 크기를 조절할 수 있는 반응형 기기를 에디터 안에 구현하는 것이었다. ## 다양한 기기 형태의 표현 - 인라인 프리뷰 공간의 제약 때문에 초기 대상은 개인용 컴퓨터보다 상대적으로 작은 모바일, 태블릿, 워치로 한정했다. - 기기마다 화면 비율과 외형이 다르므로 하나의 고정된 프레임으로는 다양한 사용 환경을 표현하기 어렵다. - 스마트폰의 카메라와 센서를 수용하기 위해 화면 일부가 파인 **노치(notch)** 같은 요소도 고려해야 했다. - 화면뿐 아니라 기기 외곽, 모서리, 센서 영역 등 실제 사용 경험을 구성하는 시각적 요소를 함께 재현해야 했다. ## 자연스러운 크기 조절과 상호작용 - 인라인 디바이스 프레임은 디자인 요소처럼 에디터 안에서 이동하고 크기를 조절할 수 있어야 했다. - 특히 워치처럼 외형이 작고 복잡한 기기는 어느 영역을 드래그하거나 조작할 수 있게 할지 결정하기 어려웠다. - 프레임의 상호작용 가능한 영역, 즉 **히트 타깃**을 명확하고 직관적으로 설계하는 것이 중요한 과제였다. - 기기마다 형태가 다르더라도 사용자가 별도의 학습 없이 동일한 방식으로 조작할 수 있도록 상호작용 규칙을 정리해야 했다. ## 프로토타이핑 기능 전반의 개선 - 인라인 디바이스 프레임과 함께 여러 프로토타이핑 개선 사항도 제공됐다. - 연결선을 복사·붙여넣기해 인터랙션을 빠르게 복제할 수 있다. - 플로우를 빠르게 삭제하는 기능이 추가됐다. - 로컬 변수가 포함된 요소를 새 파일로 쉽게 가져올 수 있는 고급 기능도 제공됐다. - 주요 사용 사례에서 로딩 스피너가 나타나는 시간이 22% 줄어 성능도 개선됐다. 실무에서는 모바일·태블릿·워치 화면을 설계할 때 인라인 디바이스 프레임을 활용해 디자인과 실제 사용 맥락을 동시에 검토하는 것이 유용하다. 특히 기기별 화면 비율, 노치, 워치의 작은 터치 영역처럼 실제 환경에서 발생하는 문제를 개발 전에 확인하는 데 적합하다.

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

Figma프로토타이핑반응형 디자인user-interface-design+2

figma·2024년 2월 25일·3분 읽기큐레이션 요약

AI가 어떻게 디자인과 개발을 통합

AI는 디자인과 개발을 পৃথ개의 영역으로 두기보다 하나의 긴밀한 창작·제작 과정으로 통합할 가능성이 크다. David Hoang은 AI가 정해진 화면을 설계하는 방식을 넘어, 사용자와 맥락에 따라 변화하는 동적·멀티모달 인터페이스를 만들 것이라고 전망한다. Replit은 범용 인공지능(AGI)보다 개발자의 자율성과 생산성을 높이는 ‘인공 개발자 지능(ADI)’에 집중하며, 아이디어를 코드로 구현하고 실제 출시까지 이어지도록 돕는 것을 목표로 한다. ## AI가 바꾸는 인터페이스와 디자인 - 모바일 혁명 당시 기존 전문가들이 새로운 환경에서 다시 초보자가 되었듯, AI도 디자인과 상호작용의 기준을 재설정하고 있다. - 디자이너가 사용자가 보게 될 모든 인터페이스를 미리 고정하는 방식에서 벗어나, 상황에 따라 형태와 표현이 바뀌는 **동적 인터페이스**로 이동한다. - AI, 멀티모달 기술, 다양한 폼팩터, 공간 컴퓨팅(예: Apple Vision Pro)은 서로 독립적인 흐름이 아니라 하나로 수렴하는 변화로 설명된다. - 디자이너는 화면의 모든 요소를 직접 통제하기보다, 시스템이 변화할 수 있는 여지를 설계해야 한다. ## 디자인과 개발의 통합 - AI는 엔지니어에게는 설계와 코드 작성을, 디자이너에게는 기술 구현과 프로토타이핑을 보조할 수 있다. - 그 결과 디자인과 엔지니어링은 점점 더 긴밀하게 결합된 하나의 분야가 될 가능성이 있다. - AI 도구는 특정 직군을 대체하기보다 각자가 자신의 전문성을 확장하고 다른 영역의 작업까지 수행하도록 돕는 **증강 기술**로 제시된다. - 협업과 AI는 Replit이 개발자 생산성을 바라보는 핵심 축이다. ## Replit의 ‘인공 개발자 지능(ADI)’ - Replit은 인간 수준의 범용 지능인 AGI보다, 소프트웨어 개발에 특화된 **Artificial Developer Intelligence(ADI)** 구축에 초점을 맞춘다. - ADI의 목표는 사용자의 자율성을 높이고 더 적은 장벽으로 소프트웨어를 만들 수 있도록 지원하는 것이다. - 장기적으로는 복잡한 소프트웨어 아키텍처를 생성하고, Replit에 배포된 고급 개발 도구를 조율하는 에이전트가 등장할 수 있다. - 단순한 코드 생성뿐 아니라 팀의 작업 방식과 협업 맥락을 이해하는 조직 지능으로 확장될 수 있다. ## ‘코드 학습’에서 ‘제품 출시’까지 - ADI는 코드 자동완성, 코드 생성, 개발 과정 안내 등 다양한 형태로 활용될 수 있다. - Replit은 사용자가 코딩을 배우는 데서 멈추지 않고, 실제 제품을 만들고 출시하며 사업으로 발전시키는 과정을 가속하는 것을 지향한다. - Hoang은 Replit을 사용자가 필요로 하는 ‘기술 공동창업자’처럼 바라본다. - AI를 활용하면 비기술 직군의 기획자도 프롬프트와 제품 이해를 바탕으로, 기존 엔지니어 팀에 못지않은 수준의 결과물을 만들 수 있다. - 따라서 앞으로는 코딩 능력뿐 아니라 문제를 정의하고 AI에 정확한 지시를 내리는 능력도 중요한 역량이 된다. AI 시대의 창작 도구는 완성된 화면이나 코드 조각을 제공하는 수준을 넘어, 사용자의 의도와 팀의 맥락을 이해하고 실행 가능한 결과물까지 함께 만들어야 한다. 디자이너와 개발자는 모든 것을 직접 통제하려 하기보다 AI와 협업하는 방식, 명확한 문제 정의, 효과적인 프롬프트 작성 능력을 함께 발전시키는 것이 바람직하다.

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

AI프롬프트 엔지니어링code-generationmobile-apps+4

figma·2024년 2월 13일·3분 읽기큐레이션 요약

원활한 핸드오프를

핸드오프는 디자인이 끝나는 한순간의 전달이 아니라, 작업 중인 디자인과 맥락·커뮤니케이션이 지속적으로 오가는 과정이다. 원활한 협업을 위해서는 개발자가 필요한 정보를 명확히 확인할 수 있도록 주석을 정리하고, 디자인·개발 간 공통 언어를 만들며, 파일 구조를 체계적으로 정리해야 한다. 특히 “Ready for dev”가 실제 구현 가능한 상태를 의미하도록 팀의 기준과 작업 방식을 맞추는 것이 중요하다. ## 주석과 콜아웃을 간결하고 명확하게 정리하기 - 주석은 디자인 결정의 의도와 개발자가 놓치기 쉬운 세부 사항을 전달하는 수단이다. - 모든 간격이나 색상을 반복해서 설명하기보다, 이미 변수나 스타일로 정의된 정보는 생략하고 다음과 같은 내용을 우선적으로 표시한다. - 새로 사용하는 컴포넌트 - 프로토타입만으로는 명확하지 않은 인터랙션 - 플랫폼별로 다르게 보여야 하는 요소 - 특정 레이어의 속성, 크기, 동작 방식 - 개발자와 먼저 어떤 정보가 유용한지 합의하면 불필요한 주석을 줄일 수 있다. - Figma의 annotations와 Dev Mode를 활용하면 스펙, 측정값, 설명을 최종 디자인에 직접 고정할 수 있다. - 주석은 디자이너와 개발자 간 대화를 대체하는 것이 아니라, 대화가 필요한 지점을 명확하게 해 커뮤니케이션을 개선한다. ## 디자인과 개발의 공통 언어 만들기 - 디자인과 개발은 서로 다른 분야이므로 같은 용어가 다른 의미로 해석될 수 있다. - 예를 들어 디자이너가 “toggle”이라고 했을 때 개발자가 “switch”를 떠올릴 수 있다. - 프로젝트 초기에 컴포넌트와 속성의 명칭을 합의하면 이후 구현 논의에서 불필요한 혼선을 줄일 수 있다. - 색상, 폰트, 간격처럼 기초적인 디자인 요소는 변수와 스타일로 관리해 디자인과 코드가 동일한 기준을 사용하도록 한다. - 개발팀에 이미 네이밍 규칙이 있다면 디자인 시스템에도 이를 반영하는 것이 좋다. - 예를 들어 `bg-primary-active`, `body text`처럼 공유된 명칭을 사용하면 특정 색상의 헥스 코드나 폰트 세부 정보를 매번 설명하지 않아도 된다. - 디자인 시스템의 색상 휠과 같은 도구를 활용하면 색조와 명도를 일관되게 선택하고 적용할 수 있다. ## 파일과 캔버스를 라벨로 정리하기 - Figma의 무한 캔버스는 아이디어를 자유롭게 펼치기 좋지만, 개발자가 처음 파일을 열었을 때 필요한 화면을 찾기 어렵게 만들 수 있다. - 브레인스토밍과 반복 작업 단계에서는 파일이 다소 복잡해도 괜찮지만, 개발에 넘길 시점에는 구조를 정리해야 한다. - 관련 디자인을 섹션으로 묶어 캔버스 내 탐색 범위를 좁힌다. - 구현이 준비된 섹션이나 프레임에는 “Ready for dev” 상태를 표시해 개발자가 우선 확인할 대상을 알 수 있게 한다. - 팀 차원에서 동일한 파일 템플릿을 사용하면 매번 구조를 새로 파악해야 하는 부담과 컨텍스트 전환을 줄일 수 있다. 실무에서는 주석을 많이 다는 것보다 필요한 정보만 남기고, 변수·스타일·공통 명칭을 디자인 시스템에 정착시키는 것이 효과적이다. 또한 개발 전달 전에는 파일을 정리하고 구현 범위를 명확히 표시해 “Ready for dev”가 팀 내에서 실제로 신뢰할 수 있는 상태가 되도록 관리하는 것이 좋다.

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

Figma디자인 시스템디자인 토큰dev-mode+3

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

슈퍼볼 광고의 해부

Duolingo는 슈퍼볼 광고의 높은 비용과 경쟁을 피하기 위해 5초짜리 광고와 앱 푸시 알림을 결합해 강렬한 화제성을 노렸다. 엉뚱한 마스코트 ‘듀오’와 “Do your Duolingo”라는 메시지로 시청자에게 WTF 순간을 제공하고, 브랜드의 소셜 중심 전략과 학습 리마인더 기능을 동시에 보여준 사례다. 이를 위해 마케팅·엔지니어링·디자인 스튜디오가 여러 차례 협업하며 아이디어를 발전시켰다. ## 5초 광고에 담은 대담한 콘셉트 - 광고에서 듀오는 흰색 프레임 안에 앉아 있다가 뒤돌아 엉덩이를 부풀린다. - 부풀어 오른 엉덩이에서 또 다른 듀오가 튀어나오고, 방귀 소리와 함께 “Do your Duolingo”라는 메시지가 등장한다. - 광고가 방영되는 동시에 Duolingo 사용자의 휴대폰에는 학습을 재촉하는 푸시 알림이 전달됐다. - 귀엽고 건전한 이미지와 인터넷에서 “unhinged”라고 불리는 기괴하고 과감한 이미지를 동시에 가진 듀오의 캐릭터성이 핵심 장치였다. - 목표는 제품 설명보다 강한 반응과 입소문을 만들어내는 “WTF moment”를 만드는 것이었다. ## 슈퍼볼을 선택한 이유 - 슈퍼볼은 미국에서 가장 많은 시청자가 모이는 생방송 이벤트 중 하나이므로, 광고 자체뿐 아니라 소셜미디어와 언론을 통한 추가 노출을 기대할 수 있었다. - Duolingo는 브랜드가 문화적 대화에 참여하고 바이럴 효과를 얻을 기회로 슈퍼볼을 바라봤다. - Eurovision 방송 중 쉬는 시간에 사용자가 학습을 수행한 사례가 있었고, 이전 슈퍼볼에서 보낸 푸시 알림도 높은 참여율을 기록했다. - 이 데이터에서 “대형 방송 이벤트의 쉬는 시간에 학습을 상기시키면 효과적”이라는 인사이트를 얻었다. - 과거 슈퍼볼에서 ‘Super Bowl’을 ‘Superb Owl’로 비튼 푸시 알림 캠페인도 아이디어 발전에 영향을 줬다. ## 비용 제약을 기회로 바꾼 5초 광고 - 2023년 슈퍼볼 30초 광고의 평균 비용은 약 700만 달러에 달했다. - Duolingo는 긴 광고를 구매하는 대신 5초짜리 슬롯을 선택해 예산 부담을 줄였다. - 짧은 광고를 TV에서 완결된 캠페인으로 만들기보다, 소셜미디어에서 사람들이 공유하고 이야기할 소재로 설계했다. - Reddit의 짧은 슈퍼볼 광고처럼 방송 노출보다 온라인 확산과 수천만 회의 소셜 노출을 목표로 삼았다. - 제한된 시간은 오히려 하나의 강력한 이미지와 짧은 문구에 집중하게 만드는 창작 조건이 됐다. ## FigJam을 활용한 전사적 브레인스토밍 - 광고 슬롯을 확보한 뒤 9월부터 세 차례의 부서 간 브레인스토밍이 진행됐다. - 첫 세션에서는 “5초 안에 슈퍼볼 대화를 어떻게 해킹하고 장악할 것인가?”라는 질문을 중심으로 아이디어를 발산했다. - 참여자들은 네 개의 소그룹으로 나뉘어 FigJam에서 스티커 메모 방식으로 아이디어를 작성했다. - 아이디어는 다음 기준으로 평가됐다. - 강한 반응을 일으키고 소셜미디어 화제를 만들 것 - Duolingo 브랜드와 어울리고 적절한 톤을 유지할 것 - 광고 이후에도 추가 콘텐츠로 확장할 수 있을 것 - Duolingo의 제품과 기능을 전달할 것 - 각 그룹이 우수 아이디어 5개를 선정한 뒤, 전체 팀이 FigJam의 스티커 투표 기능으로 선호도를 비교했다. - 이후 마케팅·엔지니어링·브랜드 스튜디오 팀이 다시 모여 아이디어를 여러 접근 방식에 따라 분류하고 최종 콘셉트를 좁혀갔다. ## 실용적인 시사점 - 짧은 광고라도 명확한 목표, 강한 브랜드 캐릭터, 실시간 제품 기능을 결합하면 큰 파급력을 만들 수 있다. - 예산이나 광고 시간의 제약을 단순한 한계로 보지 않고, 더 선명하고 공유하기 쉬운 아이디어를 만드는 조건으로 활용할 수 있다. - 방송 광고와 푸시 알림처럼 서로 다른 채널을 동시에 연결하면 짧은 노출을 실제 사용자 행동으로 확장할 수 있다. - 강한 아이디어를 실행하려면 마케팅뿐 아니라 제품·엔지니어링·디자인 팀의 긴밀한 협업이 필요하다.

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

figjammobile-appbrainstormingpush-notifications+2

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

디자인 시스템이란 무엇

디자인 시스템은 제품의 시각적 요소와 상호작용 방식을 일관되게 유지하도록 돕는 공통 언어이자 설계·개발을 위한 체계다. 색상, 아이콘, 버튼, 문구 같은 요소를 표준화하고 재사용함으로써 제작 시간을 줄이고 사용자 경험과 브랜드 정체성을 보호한다. 단순한 스타일 가이드가 아니라 원칙, 컴포넌트, 패턴, 기술 문서와 프로세스를 포괄하는 지속적으로 발전하는 기반이다. ## 디자인 시스템이란 무엇인가 - 제품과 서비스의 디자인·개발을 안내하는 **재사용 가능한 구성 요소와 표준의 집합**이다. - 복잡한 디지털 제품을 만들 때 팀이 공유할 수 있는 통일된 언어와 구조를 제공한다. - 요소를 매번 새로 설계하지 않아도 되므로 대규모 제품 개발에서 시간과 노력을 줄인다. - 디자인 시스템이 없으면 화면마다 스타일과 동작이 달라지는 **일관성 위기**가 발생할 수 있다. - 사용자가 인터페이스를 혼란스럽게 느낄 수 있다. - 브랜드 정체성이 약화될 수 있다. - 반복적인 디자인 작업과 구현 비용이 늘어난다. ## 디자인 시스템의 계층 구조 ### 1. 디자인 시스템 - 제품 생태계 전체를 아우르는 최상위 개념이다. - 다음과 같은 자원을 포함할 수 있다. - 기술 사양 - 디자인 토큰 - 컴포넌트 및 패턴 문서 - 모범 사례 - UX 설계 원칙 - 제품 개발 프로세스 - 고정된 규칙집이 아니라 제품과 조직의 변화에 따라 계속 발전하는 기반이다. ### 2. 컴포넌트 및 패턴 라이브러리 - 제품에서 반복적으로 사용하는 시각 요소와 상호작용 방식을 모아 둔 라이브러리다. - 컴포넌트의 예: - 버튼 - 입력 필드 - 기타 UI 요소 - 패턴의 예: - 내비게이션 흐름 - 데이터 표시 방식 - 레이아웃과 템플릿 - 반복되는 사용자 상호작용 - 코드 스니펫, 기술 사양, 사용 지침을 함께 제공해 디자인 의도를 실제 구현으로 연결한다. - 디자이너와 개발자가 동일한 기준을 참고하는 협업 지점 역할을 한다. - **컴포넌트 라이브러리**가 개별 UI 요소에 집중한다면, **패턴 라이브러리**는 더 넓은 문제 해결 방식과 사용자 흐름을 다룬다. ## 디자인 시스템과 스타일 가이드의 차이 - 스타일 가이드는 주로 다음과 같은 시각적 요소를 정의한다. - 색상 - 글꼴과 타이포그래피 - 이미지와 시각적 표현 - 디자인 시스템은 스타일 가이드보다 범위가 넓다. - 코딩 표준 - 사용성 원칙 - 상호작용 패턴 - 기술 문서 - 제품 개발 프로세스까지 포함할 수 있다. - 따라서 스타일 가이드는 디자인 시스템을 구성하는 일부로 볼 수 있다. ## 3. 기초 요소 - 제품의 전반적인 시각 언어와 목소리·말투를 정의한다. - 대표적인 구성 요소는 다음과 같다. - 색상 - 타이포그래피 - 아이콘 - 로고 - 일러스트레이션 - 접근성 가이드라인 - 브랜드 가이드라인 - 단순히 화면을 예쁘게 만드는 것을 넘어, 제품이 어떤 인상을 주고 어떤 방식으로 소통할지를 결정한다. ## 디자인 시스템과 UX - 디자인 시스템이 디자이너의 창의성을 제한하고 모든 화면을 똑같이 만든다는 것은 흔한 오해다. - 실제로는 반복적인 문제를 해결해 디자이너가 더 중요한 사용자 경험과 제품 문제에 집중하도록 돕는다. - 공통 요소와 기준을 재사용하면 일관성을 확보하면서도 제품 목적에 맞는 새로운 경험을 설계할 수 있다. - 색상, 아이콘, 버튼의 형태뿐 아니라 명확한 언어와 접근성까지 관리하므로 UX 전반에 영향을 준다. 디자인 시스템을 도입할 때는 단순히 UI 컴포넌트 목록을 만드는 데 그치지 말고, 디자인 원칙·접근성·코드·문서·협업 프로세스까지 함께 정의하는 것이 좋다. 또한 처음부터 모든 요소를 완성하려 하기보다 반복적으로 사용되는 핵심 요소부터 구축하고, 제품과 팀의 변화에 맞춰 지속적으로 관리해야 한다.

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

디자인 시스템사용자 경험접근성디자인 토큰+2

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

Figma와 Jira로 디

제품 개발의 속도와 품질을 높이려면 디자이너와 개발자가 같은 맥락을 공유하며 협업할 수 있는 도구·프로세스·의식이 필요하다. 특히 하이파이 인터랙티브 프로토타입과 Figma-Jira 연동은 디자인 의도를 코드로 옮기는 과정의 오해와 단절을 줄이고, 대면·비동기 협업 모두에서 팀의 ‘플로우’를 유지하도록 돕는다. 규모가 커지고 하이브리드 근무가 일반화될수록 지속적인 정렬과 명확한 정보 공유가 중요해진다. ## 제품 개발에서 ‘플로우’가 중요한 이유 - 플로우는 구성원이 특정 활동에 깊이 몰입해 효율적으로 작업하는 상태다. - 제품 속도는 올바른 기능을 빠르게 출시하는 능력이지만, 조직이 커질수록 유지하기 어렵다. - 속도는 저절로 생기지 않으며, 다음과 같은 기반이 필요하다. - 협업 도구 - 작업 프로세스 - 팀의 정기적인 커뮤니케이션과 의식 - 폴 그레이엄의 ‘메이커의 일정과 매니저의 일정’처럼 디자이너와 개발자는 짧은 단위의 잦은 회의보다 방해받지 않는 긴 작업 시간이 필요하다. - 하이브리드 환경에서는 알림, 일정, 변화하는 요구사항 때문에 개인과 팀 모두 플로우를 잃기 쉬우므로 협업 기반을 먼저 정비해야 한다. ## 고해상도 프로토타입으로 디자인과 개발의 언어 통일 - 회사가 커질수록 팀과 업무가 사일로로 분리되고, 원격·하이브리드 근무로 구성원 간 맥락 공유가 어려워진다. - 같은 용어도 디자이너와 개발자가 서로 다르게 이해할 수 있지만, 실제로 작동하는 프로토타입을 보면 의도를 더 정확히 공유할 수 있다. - One.com은 덴마크의 디자인 팀과 인도의 개발 팀이 정기적으로 요구사항, 장애물, 잠재적 문제를 논의한다. - 새로운 텍스트 기능을 논의할 때 Figma의 하이파이 프로토타입을 사용해 개발자들이 인터랙션 상태를 직접 확인했다. - 정적·로우파이 프로토타입이 전체적인 디자인 방향을 보여준다면, 인터랙티브 하이파이 프로토타입은 다음과 같은 구현 세부사항을 전달한다. - 사용자 플로우가 어떻게 진행되는지 - 창이나 모달이 언제 나타나는지 - 드롭다운이 어떻게 동작하는지 - 최종 제품에서 각 상태가 어떻게 연결되는지 - 여러 페이지를 복잡하게 연결해야 했던 기존 방식과 달리, 하나의 Figma 파일 안에서 전체 경험을 확인하고 검토할 수 있다는 점이 장점이다. ## 회의 이후에도 유지되는 비동기 협업 맥락 - 프로토타입은 회의 중 합의만 돕는 것이 아니라, 회의에 참석하지 못한 구성원에게도 결정의 맥락을 보존한다. - 원격·비동기 환경에서는 회의에서 무엇을 확인하고 결정했는지가 이후 작업의 효율을 좌우한다. - Condé Nast의 제품 개발 팀은 매일 스탠드업을 진행해 다음을 공유한다. - 현재 진행 상황 - 우선순위 - 예상되는 장애물 - 팀이 확인해야 할 질문 - 이러한 정기적인 정렬은 팀이 서로 다른 방향으로 작업하는 것을 방지하고, 문제를 조기에 드러내도록 한다. ## Figma와 Jira를 통한 디자인-개발 연결 - 디자인이 코드로 전환되는 과정에서는 디자인 파일, 개발 작업, 요구사항이 서로 다른 위치에 흩어지기 쉽다. - Figma for Jira는 Jira 작업 항목에 디자인 맥락을 연결해 개발자가 구현 시 필요한 정보를 더 쉽게 확인하도록 지원한다. - 글은 업데이트된 Figma for Jira 앱을 소개하면서, 제품 개발팀이 디자인과 개발 워크플로를 더 가깝게 연결하는 방법을 설명한다. - 핵심 목적은 단순히 디자인 링크를 첨부하는 것이 아니라, 개발자가 디자인의 배경과 동작 방식을 함께 이해하도록 하는 데 있다. ## 실천을 위한 시사점 - 기능 구현 전에 정적 화면보다 실제 인터랙션을 포함한 프로토타입으로 논의한다. - 디자인 리뷰에는 개발자를 참여시켜 상태 변화와 예외 흐름까지 함께 확인한다. - 회의에서 결정한 내용은 프로토타입과 작업 티켓에 남겨 비동기 작업에서도 맥락이 유지되게 한다. - Figma와 Jira를 연결해 디자인 의도, 요구사항, 개발 진행 상황을 하나의 흐름으로 관리한다.

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

Figma프로토타이핑product-developmentjira+2

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

원활한 피그마 마이

Figma 마이그레이션은 단순히 디자인 도구를 교체하는 일이 아니라, 협업 방식과 조직 문화를 바꾸는 변화 관리 과정이다. 성공하려면 계획 수립부터 커뮤니케이션, 라이브러리 재구축, 교육과 온보딩까지 여러 단계를 체계적으로 준비해야 한다. 특히 부서 간 대표로 구성된 옹호 팀과 조직 전체의 공감대가 핵심이다. ## 도구 교체가 아닌 변화 관리 - Figma 도입의 주요 목적은 협업 강화, 작업의 투명성 향상, 프로세스 간소화다. - 마이그레이션은 디자이너만의 과제가 아니라 개발자, 제품 관리자, 이해관계자 등 모든 구성원이 참여해야 한다. - 기존 업무 방식과 조직 문화를 새로운 협업 방식에 맞게 조정해야 한다. - 계획, 커뮤니케이션, 재구축, 온보딩, 문화적 규범 정착을 단계적으로 추진해야 한다. ## 부서 간 Figma 옹호 팀 구성 - 개발, 제품 관리, 디자인 시스템, 주요 이해관계자 등 다양한 부서의 구성원을 핵심 팀으로 참여시킨다. - 옹호 팀의 주요 역할은 다음과 같다. - 조직의 요구사항을 수집하고 균형 잡힌 피드백 제공 - 전체 조직에 적합한 Figma 워크스페이스 구성 - 마이그레이션 관련 공지와 커뮤니케이션 관리 - 기존 라이브러리와 컴포넌트 이전 감독 - Figma 사용 경험이 많거나 변화에 적극적인 사람을 중심으로 구성하는 것이 효과적이다. - Wells Fargo는 숙련자와 열성 사용자를 “Figma Jedis”로 조직했고, JPMorgan Chase는 디자인 시스템에 관심 있는 인재를 리더십과 여러 부서에서 추천받았다. - Uber는 기존 디자인 시스템 워크숍에 Figma 기초 교육과 데모를 결합해 점진적으로 도입했다. ## 부서별 지지와 리더십의 동의 확보 - 디자인 팀뿐 아니라 개발자, 제품 관리자, 경영진과 이해관계자의 동의를 초기부터 확보해야 한다. - 도입 제안서에는 기존 도구와 Figma의 장단점, 예상 효과, 비용과 운영상의 변화를 명확히 정리한다. - Dropbox는 다음과 같은 방식으로 조직의 참여를 이끌었다. - 워크숍 개최 - 모범 사례 공유 - 라이브러리와 컴포넌트의 조기 공개 - 팀별 실습과 교육 제공 - 구성원이 실제 결과를 미리 경험하도록 하면 도구 교체에 대한 저항을 줄일 수 있다. - Figma Migration Toolkit과 같은 자료를 활용해 다른 디자인 도구에서 이전할 때 필요한 지침을 표준화할 수 있다. ## 다른 조직의 경험 활용 - 비슷한 규모와 복잡성을 가진 조직의 마이그레이션 사례를 조사하면 시행착오를 줄일 수 있다. - 이미 Figma를 도입한 팀에 직접 문의해 다음 정보를 얻을 수 있다. - 교육 프로그램 구성 - 단계별 도입 플레이북 - 파일과 프로젝트를 정리하는 커버 페이지 방식 - 피해야 할 운영 방식 - 대규모 배포 시 발생한 문제와 해결책 - Wells Fargo의 사례처럼 외부 조직의 실전 경험을 참고하면 대규모 롤아웃 계획을 구체화하는 데 도움이 된다. - Workday, Uber, Dropbox 등의 사례와 마이그레이션 관련 라이브스트림도 참고 자료로 활용할 수 있다. ## 현실적인 마이그레이션 일정 수립 - 조직의 업무 일정과 기존 디자인 도구의 계약·사용 종료 시점을 함께 고려해 타임라인을 작성한다. - 한 번에 전체 조직을 전환하기보다 준비 상황과 팀별 업무 우선순위에 따라 단계적으로 진행하는 것이 안전하다. - 일정에는 교육, 라이브러리 이전, 파일 정리, 파일럿 운영, 피드백 수집, 전체 배포를 포함해야 한다. - 기존 프로젝트와 신규 프로젝트의 전환 기준을 사전에 정하면 팀 혼란을 줄일 수 있다. Figma 마이그레이션은 도구를 설치하는 프로젝트가 아니라 조직의 협업 체계를 재설계하는 프로젝트로 접근해야 한다. 먼저 부서 간 옹호 팀을 만들고, 리더십과 실무자의 지지를 확보한 뒤, 외부 사례와 단계별 일정을 바탕으로 파일럿부터 시작하는 방식을 추천한다.

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

Figma디자인 시스템design-collaborationdesign-tools+2

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

Dev Mode에 대해 알아

Figma는 디자이너와 개발자가 하나의 파일과 협업 공간에서 더 효율적으로 제품을 만들 수 있도록 Dev Mode를 개발했고, 2024년 1월 베타를 종료했습니다. Dev Mode는 개발자에게 필요한 정보와 도구를 별도 워크스페이스로 제공하면서도 디자인 맥락과 협업은 유지하는 것이 핵심입니다. Figma는 사용자 피드백을 바탕으로 주석, 변경점 비교 등 핸드오프와 구현을 지원하는 기능을 강화했습니다. ## 개발자 중심의 작업 공간이 필요한 이유 - 개발자는 Figma 주간 활성 사용자의 약 3분의 1을 차지했습니다. - 하지만 기존 Figma는 디자인 작업에 최적화되어 있어 개발자의 워크플로, 도구 체계, 선호 사항을 충분히 지원하지 못했습니다. - Figma는 프런트엔드 개발자, 디자인 시스템 엔지니어, 콘텐츠 레이아웃 및 에셋을 다루는 개발자 등 다양한 역할을 고려해 개발자 전용 경험을 만들고자 했습니다. - 핵심 방향은 개발자가 디자인 모드의 모든 상호작용을 학습하지 않아도 되도록, 개발자에게 필요한 방식으로 Figma를 맞추는 것이었습니다. ## Visly 인수와 개발자 직관 확보 - Figma는 2021년 React UI 컴포넌트 개발 도구를 만들던 Visly 팀을 인수했습니다. - 8명의 디자이너와 엔지니어로 구성된 Visly 팀은 개발자 도구에 대한 실무 경험과 연구 결과를 보유하고 있었습니다. - Figma는 개발자와 대화하는 것만으로는 부족하며, 실제 개발 환경에 몰입해 얻는 ‘개발자 직관’이 필요하다고 판단했습니다. - Visly 팀은 개발자가 Figma를 사용하는 실제 방식과 다양한 개발 환경에 대한 관점을 제공했습니다. ## 디자인과 개발을 연결하는 통합 모드 - Dev Mode의 형태를 결정하는 과정에서 디자인 파일과 개발 파일을 완전히 분리할지, 하나로 통합할지 오랜 기간 검토했습니다. - 최종적으로 Dev Mode를 Figma 안의 별도 공간으로 구현했습니다. - 개발자는 개발에 최적화된 인터페이스를 사용하면서도 디자인 파일, 변경사항, 디자이너의 의도 같은 중요한 맥락을 그대로 확인할 수 있습니다. - 별도 도구나 파일로 전환하지 않고 디자인 공간과 개발 공간을 오갈 수 있다는 점이 핵심입니다. ## 오픈 베타와 사용자 피드백 - Dev Mode는 Config 2023에서 오픈 베타로 공개되었습니다. - 베타 기간 동안 고객 요청을 적극적으로 수집했고, 처음 두 달 동안 가장 많이 요청된 업데이트와 수정 사항 200개 이상을 배포했습니다. - 사용자 피드백은 Dev Mode의 기능 우선순위와 제품 결정에 직접 반영되었습니다. - 이후 Dev Mode는 베타를 종료하고 정식 제품 단계로 이동했습니다. ## 디자인 의도를 명확히 전달하는 주석 - 기존에는 디자이너가 개발자에게 필요한 치수와 설명을 수동으로 만들고 디자인을 별도로 정리해야 했습니다. - Dev Mode의 주석 기능은 디자인에 직접 연결된 설명, 사양, 측정값을 제공합니다. - 디자인이 변경되면 주석도 실시간으로 업데이트되어 최신 상태를 유지할 수 있습니다. - 캔버스를 복잡하게 만들지 않으면서 중요한 세부사항을 강조할 수 있습니다. - 플러그인을 이용해 주석을 자동화하거나 사용자 지정할 수 있습니다. - 클릭하고 드래그하는 방식으로 요소 간 거리를 측정할 수 있습니다. ## 개발 준비 상태와 변경점 비교 - 디자이너는 섹션을 “개발 준비 완료(ready for development)”로 표시하고 별도의 페이지나 파일 없이 개발자에게 전달할 수 있습니다. - 변경점 비교(diff) 기능을 사용하면 서로 다른 버전의 프레임을 비교할 수 있습니다. - 이를 통해 디자인 변경 사항을 확인하고, 개발자가 최신 디자인을 기준으로 작업하도록 지원합니다. - 목적은 디자인 핸드오프 과정에서 누락되는 설명이나 변경사항을 줄이고 구현 정확도를 높이는 것입니다. Dev Mode를 효과적으로 활용하려면 디자인과 개발을 별도 도구로 분리하기보다, 디자인 파일 안에서 주석·측정값·준비 상태·변경 이력을 일관되게 관리하는 것이 좋습니다. 특히 개발 전달 전에 “개발 준비 완료” 상태와 변경점을 명확히 표시하면 커뮤니케이션 비용을 줄일 수 있습니다.

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

Figma디자인 시스템Reactdesign-to-code+3

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

개발 모드 어노테

Figma의 Dev Mode 주석 기능은 디자이너와 개발자 사이에 흩어진 요구사항과 설계 의도를 하나의 공간에 모으기 위해 만들어졌다. 기존 주석은 작성에 시간이 많이 들고 디자인 변경에 따라 쉽게 낡으며 캔버스를 복잡하게 만든다는 문제가 있었다. Figma는 주석을 실제 디자인 속성·측정값·변수·컴포넌트와 연결하고, 캔버스 바깥에서 자동으로 배치해 최신 상태와 가독성을 함께 확보하려 했다. ## 디자이너와 개발자의 서로 다른 요구 - 디자이너는 시각적 결과만으로 표현하기 어려운 정보를 전달해야 한다. - 접근성 속성 - 인터랙션의 세부 동작 - 특정 디자인 결정을 내린 의도 - 개발자에게 디자인 파일은 정보가 지나치게 많아 실제 구현해야 할 부분을 찾기 어려울 수 있다. - 디자인 공유는 전체 파일을 전달하는 것과 다르며, 개발자가 집중해야 할 영역과 요구사항을 선별해 주는 과정이 필요하다. - Figma는 이러한 문제를 해결하기 위해 Dev Mode 안에 개발자용 사양을 큐레이션하는 전용 공간을 마련했다. - 디자이너도 Dev Mode에서 주석을 작성함으로써 개발자가 실제로 보게 될 화면과 맥락을 확인할 수 있고, 작업이 끝난 뒤 Dev Mode 링크를 공유할 수 있다. ## 기존 수동 주석의 한계 - 디자이너는 텍스트, 화살표, 치수선, 콜아웃 등을 직접 배치해야 하므로 주석 작성에 많은 시간이 든다. - 디자인이 변경되면 기존 주석이 수정되지 않아 실제 디자인과 설명 사이에 불일치가 생긴다. - 디자인 파일에 주석을 추가하려면 프레임을 옮기거나 주변 공간을 확보해야 한다. - 주석이 많아질수록 캔버스가 복잡해지고, 개발자가 필요한 정보를 찾기 어려워진다. - 작업이 완전히 확정된 뒤 “개발 준비 완료” 상태를 표시하는 방식에는 적합하지만, 지속적으로 변경되는 제품 개발 과정에는 한계가 있다. ## 디자인 속성과 연결되는 동적 주석 - Figma는 주석을 단순한 텍스트가 아니라 디자인의 실제 속성에 연결하는 방식을 고민했다. - 디자인 변경 시 연결된 주석과 치수선도 함께 갱신되도록 하면 디자이너가 정보를 반복해서 입력할 필요가 줄어든다. - 개발자는 디자이너가 계속 수정 중인 상황에서도 최신 디자인에 기반한 사양을 확인할 수 있다. - 디자인 시스템의 변수와 컴포넌트를 주석에서 직접 참조하면, 일반 텍스트보다 오류 가능성이 낮아진다. - 주석의 정보가 실제 디자인 요소 및 코드베이스와 가까워질수록 설계 사양과 구현 결과의 정합성이 높아진다. ## 캔버스를 어지럽히지 않는 위치 지정 - 기존 방식에서는 주석을 표시할 공간을 만들기 위해 프레임을 계속 재배치해야 했다. - Figma는 주석을 캔버스에 직접 차지시키지 않으면서도 개발자에게 충분히 잘 보이게 하는 방식을 탐색했다. - 최종 방향 중 하나는 주석을 자동으로 배치하고 표시하는 것이었다. - 자동 배치는 디자이너의 수동 정리 작업을 줄이고 개발자에게 더 깔끔한 화면을 제공할 수 있다. - 다만 확대·축소, 이동, 크기 조절, 최소화, 선택, 마우스 오버 등 다양한 상호작용을 고려해야 하므로 여러 프로토타입과 반복적인 조정이 필요했다. - 엔지니어링 팀은 주석 표시 로직을 조정해 다양한 화면 상태에서도 주석이 적절히 보이도록 하는 데 집중했다. ## 실용적인 시사점 Dev Mode의 주석은 디자인이 끝난 뒤 설명을 덧붙이는 문서화 도구라기보다, 변경 중인 디자인과 구현 요구사항을 지속적으로 연결하는 협업 기능에 가깝다. 주석을 작성할 때는 단순한 설명보다 접근성, 상태 변화, 인터랙션, 디자인 토큰처럼 실제 구현에 필요한 정보를 디자인 요소와 연결해 기록하는 것이 효과적이다.

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

Figma디자인 시스템접근성dev-mode+2

figma·2024년 1월 29일·2분 읽기큐레이션 요약

피터 양: 고객이 사랑

고객이 사랑하는 제품은 타고난 감각이 아니라 지속적으로 갈고닦은 제품 감각과 깊은 공감에서 출발한다. 고객 문제를 정확히 진단한 뒤 큰 방향과 전략을 세우고, 단기 일정이나 지표보다 장기적인 제품 품질을 우선할 때 의미 있는 결과를 만들 수 있다. 이를 위해 제품 관리자는 실행에만 매몰되지 않고 필요하면 방향을 바꾸거나 프로젝트를 중단할 수 있어야 한다. ### 제품 감각은 타고나는 것이 아니라 길러진다 - 제품 감각은 사용자가 의도한 효과를 얻도록 제품을 설계하고 개선하는 능력이다. - 단순한 직관이나 한 번 습득하면 유지되는 고정된 능력이 아니다. - 시장과 고객의 요구는 계속 변하므로 제품 감각도 지속해서 개선해야 한다. - 고객에 대한 공감, 창의성, 제품 제작 역량을 꾸준히 쌓는 태도가 중요하다. ### 공감으로 고객 문제를 진단하라 - 해결책이나 비전을 서둘러 정하기 전에 고객과 비즈니스가 실제로 겪는 문제를 명확히 파악해야 한다. - 고객을 팀원처럼 대하고, 직접 인터뷰하거나 제품을 고객의 입장에서 사용해 보면 공감 능력을 키울 수 있다. - 제품 관리자의 핵심 역량은 고객이 무엇을 필요로 하는지 깊이 이해하는 것이다. - 문제 진단이 부정확하면 이후의 전략과 기능 개발도 잘못된 방향으로 흘러갈 수 있다. ### 일상적인 실행보다 먼저 큰 방향을 세워라 - 문제를 파악한 직후 세부 실행에 뛰어들기보다 팀의 미션, 비전, 전략을 먼저 정해야 한다. - 팀과 함께 브레인스토밍하고, 여러 가능성 중 고객 문제를 가장 효과적으로 해결할 아이디어를 우선순위화한다. - 복잡한 해결책보다 고객에게 실질적인 가치를 주는 단순한 해결 과정을 설계하는 것이 좋다. - 고객에 대해 더 많이 알게 되면 우선순위와 트레이드오프를 다시 조정해야 한다. ### 품질을 위해 멈추고 방향을 바꿀 줄 알아야 한다 - 좋은 제품을 만들려면 출시 일정이나 단기 목표 지표를 놓치는 어려운 결정을 감수해야 할 때가 있다. - 고객 의견을 통해 꼭 필요한 기능을 발견했다면, 일정이 늦어지더라도 이를 포함하는 것이 장기적으로 더 나은 선택일 수 있다. - 제품의 완성도는 세부 사항에 대한 집착, 트레이드오프 판단, 버그 제거, 기대 이상의 개선에서 나온다. - 반대로 제품이 사용자에게 사랑받더라도 회사의 핵심 사업 목표에 기여하지 못한다면 프로젝트를 중단해야 할 수 있다. - Reddit의 Reddit Talk 사례처럼 사용자 만족도와 사업적 지속 가능성은 별개의 문제이므로, 제품 관리자는 제품 자체를 넘어 회사 전체의 방향을 고려해야 한다. ### 실용적인 적용 문제를 해결하기 전에 고객의 실제 사용 경험을 직접 확인하고, 팀과 함께 비전과 우선순위를 명확히 정하는 것이 좋다. 이후에는 일정과 지표를 절대적인 기준으로 삼기보다 고객 가치와 사업 목표를 함께 평가하며, 필요하면 출시 연기·방향 전환·프로젝트 중단까지 선택해야 한다.

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

user-researchproduct-managementbrainstormingproduct-strategy+3

figma·2024년 1월 25일·2분 읽기큐레이션 요약

디자인 시스템 도입을 가로

디자인 시스템은 대기업만을 위한 복잡한 도구가 아니라, 팀 규모와 관계없이 효율성·일관성·협업을 높이는 실용적인 체계다. 최신 유행이나 Material Design을 그대로 따르기보다 조직의 목표, 브랜드, 사용자에 맞춰 설계해야 한다. 또한 처음부터 모든 것을 직접 만들 필요 없이 공개된 리소스를 활용해 현실적인 범위에서 시작할 수 있다. ## 디자인 시스템은 대기업만을 위한 것이 아니다 - 규모가 작은 팀도 디자인 시스템을 통해 반복 작업을 줄이고 결과물의 일관성을 높일 수 있다. - 디자인 시스템의 형태는 조직마다 다를 수 있지만, 핵심 목적은 공통적이다. - 업무 효율 향상 - 제품 경험의 일관성 확보 - 디자이너와 개발자 간 협업 촉진 - 사례로 소개된 Mixpanel은 디자인 시스템을 개편해 비용을 절감하고, 일관성을 개선하며, 전사적으로 데이터 분석 접근성을 높였다. ## 최신 디자인 기법을 모두 적용해야 한다는 오해 - 디자인 트렌드는 계속 변하며, 모든 조직에 통하는 유일한 정답은 없다. - 다른 팀의 사례와 업계 동향은 참고할 수 있지만 그대로 복제할 필요는 없다. - “완벽하고 최신인 시스템”을 만드는 데 집중하면 실제 해결하려던 문제와 목표를 놓칠 수 있다. - 디자인 시스템은 유행을 보여주는 전시물이 아니라 다음을 지원해야 한다. - 조직의 구체적인 목표 - 실제 사용자 요구 - 팀의 업무 방식 - 지속 가능한 운영 ## Material Design이 모든 조직에 맞는 것은 아니다 - Google의 Material Design은 널리 알려진 표준이지만, 모든 제품에 그대로 적용할 수 있는 만능 해법은 아니다. - 조직의 디자인 시스템은 다음 요소를 반영해야 한다. - 브랜드의 고유한 정체성 - 제품 사용자의 needs - 조직의 비즈니스 목표 - 현재 조직이 처한 상황과 우선순위 - 업계 표준을 참고하되, 조직에 가장 적합한 방식과 균형을 찾아야 한다. - 글에서는 Uber Base, Google Material 3, Spotify Backstage, Pipedrive, Microsoft Teams, Salesforce Lightning 등의 디자인 시스템과 UI 키트를 비교 사례로 제시한다. ## 디자인 시스템을 처음부터 직접 만들어야 한다는 오해 - 글은 디자인 시스템을 반드시 처음부터 자체 제작해야 한다는 생각에 의문을 제기한다. - 공개된 오픈소스 디자인 시스템과 UI 리소스를 활용하면 초기 구축 비용과 시간을 줄일 수 있다. - 이미 검증된 리소스를 기반으로 시작한 뒤, 조직의 브랜드와 제품 요구에 맞게 수정하는 방식이 현실적이다. - 제공된 본문은 이 신화에 대한 설명 중간에서 끝나므로, 이후 네 번째부터 여섯 번째 신화의 전체 내용은 확인할 수 없다. 작게 시작하되 팀의 반복 문제와 실제 사용자 요구를 우선 해결하는 것이 좋다. 기존 오픈소스와 업계 사례는 출발점으로 활용하고, 최종 디자인 시스템은 조직의 브랜드·제품·업무 방식에 맞게 점진적으로 발전시키는 것이 바람직하다.

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

디자인 시스템오픈 소스design-thinkingcomponent-library+3

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

개발 모드의 향후 계획

Figma는 Dev Mode 무료 베타 종료를 앞두고 주석, 변경 사항 비교 개선, 플러그인, Jira·VS Code 연동 기능을 공개했다. 이를 통해 디자이너와 개발자 간 핸드오프에 필요한 맥락을 강화하고, 조직별 기술 스택과 디자인 시스템에 맞춘 개발 워크플로를 지원한다. Dev Mode는 2024년 1월 31일부터 무료 베타를 종료하고 유료 좌석이 필요해진다. ## 디자인과 연결되는 주석 기능 - 디자이너가 디자인 레이어에 설명, 속성, 사양, 측정값을 직접 추가할 수 있다. - 클릭과 드래그만으로 치수와 간격을 표시해 개발자에게 구체적인 구현 정보를 전달한다. - 주석이 특정 레이어에 연결되므로 디자인이 변경되면 속성이나 측정값도 함께 업데이트된다. - 확대·축소 수준에 따라 주석이 자동으로 표시되거나 숨겨져 캔버스를 복잡하게 만들지 않는다. - 플러그인 API를 이용하면 여러 레이어에 주석을 일괄 생성하고 관리할 수 있다. ## 시각적·코드 기반 변경 사항 비교 - Compare Changes 기능이 개편되어 디자인 변경 사항을 시각적 차이와 코드 차이로 모두 확인할 수 있다. - 주석 기능과 결합해 어떤 디자인 요소가 바뀌었고 구현에 어떤 영향을 주는지 파악하기 쉬워졌다. - Figma for Jira 앱을 사용하면 Jira 이슈에 디자인 맥락을 삽입할 수 있다. - 디자인이 변경될 때 Jira에서 알림을 받아 핸드오프 과정에서 업데이트를 놓치지 않도록 지원한다. ## 조직별 코드 생성과 플러그인 - 조직마다 다른 개발 환경에 맞춰 HTML, React, Tailwind, Bootstrap 등 다양한 형식의 코드를 생성할 수 있다. - 디자인 시스템 컴포넌트와 실제 코드베이스의 컴포넌트 연결 여부를 확인하는 플러그인을 만들 수 있다. - 플러그인에 내부 API 안내, 디자인 시스템 문서 링크, 사용 가능한 컴포넌트 정보 등을 포함할 수 있다. - Enterprise 관리자는 특정 플러그인을 조직 전체에 고정하고 Dev Mode에서 기본 실행되도록 설정할 수 있다. - Razorpay는 자체 Dev Mode 플러그인인 RazorSharp를 구축해 디자인에 대응하는 코드를 자동 생성했다. ## Figma for VS Code 개선 - VS Code 안에서 Figma 디자인을 탐색하고 검사할 수 있도록 확장 기능의 탐색성과 검색성이 개선됐다. - 여러 페이지와 무한 캔버스를 직접 이동하는 대신 프레임을 그리드 형태로 선택할 수 있다. - Focus View를 통해 개별 프레임을 집중해서 확인할 수 있다. - VS Code를 떠나지 않고 Figma 플러그인을 실행할 수 있어, 사내 도구나 코드 생성 플러그인을 개발 환경에서 바로 사용할 수 있다. ## Dev Mode 유료 전환 - Dev Mode는 2024년 1월 31일 무료 베타에서 정식 서비스로 전환된다. - 이후 사용하려면 플랜과 좌석 유형에 따라 유료 Dev Mode 좌석이 필요하다. - 무료 베타 기간 동안 사용자 피드백을 반영해 200개 이상의 기능과 수정 사항이 추가됐다. 조직은 디자인 시스템과 실제 코드베이스의 연결이 중요하다면 주석과 플러그인을 우선 도입하고, 개발자가 VS Code 중심으로 작업한다면 Figma for VS Code와 사내 플러그인 연동을 검토하는 것이 효과적이다. 유료 전환 전 팀별 좌석과 플러그인 운영 정책도 함께 정하는 것이 좋다.

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

Figma디자인 시스템dev-modeplugins+4

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

점진적 프레임 로

Figma는 프로토타입 전체를 메모리에 올리던 기존 방식을 버리고, 현재 화면과 곧 이동할 수 있는 화면만 단계적으로 불러오는 ‘증분 프레임 로딩’을 도입했습니다. 이를 통해 대형 프로토타입의 초기 로딩 시간을 줄이고, 특히 메모리가 제한된 모바일 환경에서 발생하던 앱 종료와 충돌을 완화했습니다. 핵심은 필요한 문서 트리 일부만 실시간으로 구독하고, 사용자의 탐색에 따라 구독 범위를 확장하는 것입니다. ## 전체 프로토타입 로딩의 한계 - 초기 프로토타이핑 기능은 프로토타입이 포함된 문서 전체를 메모리에 로드한 뒤 첫 화면을 표시했습니다. - Figma 문서가 커지면서 페이지, 디자인 시스템, 컴포넌트 변형 수가 급증했고 프로토타입도 함께 대형화되었습니다. - iPhone을 비롯한 모바일 기기는 데스크톱보다 메모리 여유가 적습니다. - 운영체제가 애플리케이션의 메모리 사용량 증가를 허용하지 않고 프로세스를 종료하면서 모바일 프로토타입 충돌이 잦아졌습니다. - 전체 데이터를 다운로드하고 메모리에 보관하는 방식은 로딩 시간과 메모리 사용량을 동시에 악화시켰습니다. ## 증분 프레임 로딩 전략 - 증분 로딩은 파일 전체가 아니라 새로 필요하거나 변경된 데이터 일부만 로드하는 방식입니다. - Figma는 이 개념을 프로토타입 화면 단위에 적용해 ‘증분 프레임 로딩’이라고 명명했습니다. - 현재 화면을 표시하는 데 필요한 데이터만 내려받고 메모리에 유지합니다. - 사용자가 처음 보는 화면과 해당 화면에서 프로토타입 인터랙션으로 바로 이동할 수 있는 인접 화면을 우선 로드합니다. - 사용자가 다음 화면으로 이동하면 새 화면과 그 화면에서 접근 가능한 인접 화면을 추가로 로드합니다. - 이미 본 화면은 사용자가 뒤로 이동할 수 있으므로 메모리에 계속 유지합니다. ## Time to Interactive 최적화 - 목표는 페이지 전체가 완전히 로드되는 시간이 아니라, 사용자가 유용한 화면을 보고 빠르게 클릭·탐색할 수 있게 되는 시간인 TTI(Time to Interactive)를 줄이는 것입니다. - 첫 화면과 즉시 이동 가능한 화면만 준비하면 사용자는 전체 프로토타입이 로드되기 전에 상호작용을 시작할 수 있습니다. - 이후 화면은 사용자의 탐색 흐름에 맞춰 지연 로딩되므로 초기 표시를 위해 기다려야 하는 데이터 양이 줄어듭니다. ## 실시간 공동 편집과 부분 동기화 - Figma 파일은 다른 사용자가 편집할 때 변경 사항이 활성 사용자에게 실시간으로 동기화되어야 합니다. - 기존 시스템은 파일 전체를 서버의 실시간 데이터 저장소와 연결해 업데이트를 전달했습니다. - 부분 로딩을 지원하기 위해 Figma는 파일의 특정 부분만 조회할 수 있는 기능을 추가했습니다. - 클라이언트는 문서 트리에서 구독할 하위 트리를 `query` 메시지로 요청합니다. - 서버는 해당 하위 트리의 현재 상태를 `reply` 메시지로 전달하고 요청이 처리되었음을 확인합니다. - 이후 구독 범위 안에서 변경이 발생하면 서버는 `changes` 메시지를 통해 업데이트를 전송합니다. ## 문서 트리 구독 프로토콜 - 특정 노드 `a`를 구독하면 해당 노드뿐 아니라 조상 노드와 모든 자손 노드도 구독 대상으로 취급됩니다. - 클라이언트가 `a`를 요청하면 서버는 `a`의 현재 콘텐츠와 함께 요청 완료 응답을 보냅니다. - 구독한 노드의 속성이 변경되면 변경 사항이 클라이언트로 전달됩니다. - 다른 노드 `y`가 `a` 아래로 이동하면 서버는 `a`의 구독 범위에 새로 들어온 `y`의 존재를 전달합니다. - 반대로 `c`가 `x` 아래로 이동하고 클라이언트가 `x`의 자손을 구독하지 않는다면, 클라이언트에는 `c`가 구독 범위에서 제거되었다는 변경 사항이 전달됩니다. - 따라서 클라이언트는 파일 전체가 아니라 현재 관심 영역에 해당하는 문서 트리만 유지하면서도 실시간 상태를 일관되게 관리할 수 있습니다. ## 실용적인 결론 대규모 문서나 프로토타입을 다루는 애플리케이션에서는 전체 데이터 선로드보다 사용자 행동을 기준으로 한 부분 로딩이 효과적입니다. 특히 초기 상호작용에 필요한 최소 데이터만 먼저 제공하고, 탐색 경로에 따라 인접 데이터를 미리 가져오며, 실시간 동기화 역시 구독 단위로 제한하는 설계가 로딩 성능과 메모리 안정성을 함께 개선할 수 있습니다.

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

multiplayer-collaborationmemory-optimizationincremental-loadingreal-time-sync+2

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

요점 정리: 제

Figma의 **“Issue no.3: The handoff”**는 2023년의 주요 제품 출시와 업무·기술 관련 인사이트를 돌아보고 2024년으로 이어지는 “인계”를 주제로 한 연말 큐레이션이다. 디자인 협업에서의 핸드오프를 단순한 전달이 아니라 아이디어를 계속 주고받으며 발전시키는 과정으로 바라보며, AI 제품 개발, 협업, 기술과의 관계, 생산성 도구 등을 여러 글과 프로젝트로 소개한다. ## 아이디어를 이어가는 ‘핸드오프’ - Figma는 미국 풋볼의 공 전달에서 유래한 “handoff”를 디자인 협업의 개념으로 확장한다. - 디자인 작업에서 핸드오프는 디자이너가 개발자에게 결과물을 넘기는 일회성 단계가 아니라, 아이디어가 팀 사이를 오가며 완성되는 지속적인 상호작용이다. - 2023년에 있었던 주요 출시, 업무 방식의 변화, 팀 협업에 대한 배움을 정리해 2024년으로 이어가려는 목적을 담고 있다. - 글 전체는 하나의 주제를 깊게 분석하기보다, Figma가 선정한 관련 콘텐츠와 프로젝트를 묶어 보여주는 연말 회고 형식이다. ## 2023년 Figma의 주요 출시 - 2023년에 출시한 제품과 기능 가운데 영향이 컸던 10가지를 선정해 소개한다. - 작은 세부 개선부터 제품의 방향을 바꾼 대규모 출시까지 포함하며, 각 항목이 사용자 경험과 업무 방식에 어떤 차이를 만들었는지 설명한다. - 여기서 MVP는 “Minimum Viable Product”가 아니라 “Most Valuable Players”라는 의미로 사용된다. - 제품을 평가할 때 기능의 규모뿐 아니라 실제 업무에 준 영향과 세부 완성도도 중요하다는 관점을 보여준다. ## 기술과 다시 관계 맺기 - 기술에 대한 개인의 경험과 감정을 돌아보는 36개의 질문을 제시한다. - 첫 사용자 이름, 기술을 통해 사람을 만난 경험, 미래에 기대하는 혁신 등을 질문하며 기술을 단순한 도구가 아닌 사회적·개인적 관계의 대상으로 바라본다. - 디지털 과잉과 불확실성이 커지는 상황에서 기술의 장점과 의미를 재발견하려는 내용이다. - 여러 제품 제작자들의 답변을 통해 기술이 사람들을 연결하고 새로운 가능성을 제공하는 방식을 살펴본다. ## AI 제품은 사람의 도움이 필요하다 - 2024년에도 AI가 중요한 기술 흐름이 되겠지만, AI의 능력만으로 좋은 제품이 만들어지는 것은 아니라고 강조한다. - Duolingo, LinkedIn, Asana 등의 제품 리더들이 AI 기능을 실제 사용자 가치로 연결하는 방법을 공유한다. - 제품 관리자는 과장된 AI 열풍을 좇기보다 다음 요소를 판단해야 한다. - 사용자가 실제로 필요로 하는 문제인지 - AI의 결과를 사용자가 신뢰할 수 있는지 - 제품 안에서 AI가 어떤 역할을 맡아야 하는지 - 기능을 안정적으로 시장에 출시하고 개선할 수 있는지 - 핵심은 AI 자체를 도입하는 것이 아니라, 사용자에게 의미 있고 신뢰할 수 있는 경험을 제공하는 것이다. ## Figma Creator Micro와 키보드 문화 - Figma와 모듈형 키보드 제조사 Work Louder가 협업해 12개 키와 2개의 로터리 인코더를 갖춘 커스텀 키보드를 제작했다. - 키 조합을 활용하면 최대 48개의 단축키를 설정할 수 있어 Figma 작업 효율을 높일 수 있다. - 프로젝트 제작 과정과 함께 기계식 키보드가 생산성 도구이자 촉각적 즐거움을 주는 제품이라는 점을 조명한다. - 온라인에서 대부분의 업무가 이루어지는 환경에서도 물리적 인터페이스가 집중력과 작업 감각을 보완할 수 있다고 설명한다. ## 협업과 업무 방식에 대한 다른 시선 - Figma는 앞서 발행한 여러 콘텐츠를 통해 현대적인 업무 방식을 다양한 각도에서 다룬다. - 새로운 업무 용어를 통해 원격·디지털 업무 환경에서 생겨난 규범과 문제를 살펴본다. - 전문성을 유지하면서도 상황에 따라 방향을 바꾸는 “프로페셔널 피벗”의 태도를 소개한다. - 회의를 단순한 정보 전달 시간이 아니라 진행자와 참가자가 함께 만들어가는 협업 세션으로 바라본다. - 글 후반부의 “Rabbit hole” 등 추가 콘텐츠는 일, 회의, 창작, 기술 문화를 일러스트와 이야기 형식으로 확장한다. ## 실용적인 시사점 업무 인계는 산출물을 넘기는 마지막 단계가 아니라, 다음 사람이 맥락을 이해하고 다시 발전시킬 수 있도록 지속적으로 대화하는 과정으로 설계하는 것이 좋다. 또한 AI나 새로운 도구를 도입할 때는 유행보다 사용자 문제, 신뢰성, 실제 업무 개선 효과를 먼저 검증해야 한다.

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

FigmaAI프로덕트 디자인collaboration+1