figma·2020년 10월 7일·3분 읽기큐레이션 요약

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 페이지에서 확인해야 한다.

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

Figma디자인 시스템design-toolsdesign-to-development+1

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

연결의 순간 만들기 | 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의 결론은 다음과 같다. - 자신의 전문 기술을 끊임없이 연마할 것 - 동시에 인간다움과 타인과의 관계를 발전시킬 것 일과 제품을 설계할 때 기능적 목표만 세우지 말고, 그것이 사용자와 팀, 커뮤니티에 어떤 감정과 연결을 만들어내는지 함께 정의하는 것이 좋다. 전문성은 신뢰를 만들지만, 진정성과 인간적인 태도는 사람들이 오래 기억하는 관계를 만든다.

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

Figma디자인 시스템사용자 경험remote-collaboration+1

figma·2020년 9월 29일·3분 읽기큐레이션 요약

개방적이고 포용

프로세스는 팀의 협업 방식뿐 아니라 제품이 얼마나 개방적이고 포용적인지도 결정한다. 좋은 디자인은 핵심 사용자와 이상적인 사용 사례를 넘어 다양한 환경·능력·문화의 사용자를 고려하고, 디자인·개발·현지화 팀이 초기부터 함께 검토하는 구조를 갖춰야 한다. 특히 원격 근무 환경에서는 업무 현황과 가용 시간을 투명하게 공유하는 루틴이 중요하다. ## 이상적인 사용 사례를 넘어선 사용자 이해 - 대표 페르소나와 핵심 사용 사례만을 기준으로 삼으면 실제 사용 환경의 복잡성을 놓치기 쉽다. - 제품을 직접 사용하는 사람뿐 아니라 배달원처럼 제품의 결과물을 전달하거나 운영하는 사람의 상황도 체험해야 한다. - 예를 들어 배달 앱은 다음과 같은 현실적 제약을 고려해야 한다. - 고장 난 엘리베이터 대신 계단을 이용해야 하는 상황 - 외진 지역에서 GPS가 작동하지 않는 상황 - 사용자의 범위를 넓혀 바라보면 접근성 문제도 더 구체적으로 발견할 수 있다. - 문구를 단순화하고, 색상 대비·글자 크기·레이아웃을 개선하는 것부터 시작할 수 있다. - 접근성은 장애뿐 아니라 특정 상황에서 일시적으로 발생하는 제약도 포함한다. - 시끄러운 장소에서 소리를 듣기 어려운 경우 - 휴대폰 화면이 깨진 경우 - 조직 내에서 접근성 개선을 책임질 담당자를 명확히 정해야 지속적인 변화로 이어진다. - 특정 사용자에게 필수적인 기능은 결과적으로 모든 사용자에게도 유용할 수 있다. ## 현지화를 제품 개발의 일부로 만들기 - 현지화는 단순히 문구를 번역하는 작업이 아니라 다음 요소를 함께 고려하는 과정이다. - 언어별 문장 구조와 문법 - 문화적 뉘앙스 - 번역된 문구가 실제 화면에 들어갈 수 있는지 여부 - Deliveroo는 기존에 디자이너가 경험을 설계한 뒤 개발자에게 넘기고, 개발자가 번역 문구마다 화면을 수동으로 확인하는 방식으로 작업했다. - Phrase Figma 플러그인을 도입해 디자이너가 여러 언어의 디자인을 빠르게 만들고 공유할 수 있도록 개선했다. - 이 방식으로 현지화 팀은 개발 전에 다음 문제를 발견할 수 있었다. - 번역이 부정확한 문제 - 번역문이 화면 영역을 초과하는 문제 - 현지화 담당자는 전체 사용자 흐름을 한 번에 확인하고 초기 단계에서 피드백을 제공할 수 있다. - 결과적으로 현지화는 디자인팀과 현지화팀 사이의 일회성 인계가 아니라, 글로벌 사용자 여정을 함께 설계하는 제품 개발 과정으로 바뀌었다. ## 조직 전체의 긴밀한 협업 - 포용적인 제품을 만들려면 디자인팀 내부뿐 아니라 디자인·개발·현지화 등 관련 조직이 일찍부터 협력해야 한다. - 기존의 순차적 핸드오프 방식은 문제를 늦게 발견하게 만들고, 이미 구현된 화면을 다시 만드는 비용을 높인다. - 가벼운 프로토타입을 공유하면 각 팀이 자신의 전문성을 디자인 단계에서 반영할 수 있다. - 협업 과정에서 중요한 것은 단순히 시간을 절약하는 것뿐 아니라, 각 팀이 전체 사용자 경험과 제품 맥락을 이해하는 것이다. ## 원격 환경에서 투명한 팀 프로세스 만들기 - 원격 근무에서는 사무실에서 자연스럽게 얻던 공간적·시각적 정보가 사라지므로 업무 상황을 더 의도적으로 공유해야 한다. - 팀 구성원이 무엇을 하고 있는지, 회의에 얼마나 참여할 수 있는지 파악할 수 있도록 업무 시간을 시각화할 필요가 있다. - Team Capacity Template과 같은 도구를 활용하면 다음 정보를 공유할 수 있다. - 각자의 주간 업무 일정 - 회의 가능 시간 - 업무량의 공백이나 과부하 - 정기적인 회의와 짧은 스탠드업은 업무 진행 상황뿐 아니라 개인적인 안부를 확인하는 역할도 한다. - 사무실의 즉흥적인 대화와 브레인스토밍을 보완하기 위해 자유롭게 참여하고 나갈 수 있는 화상 작업 세션을 운영할 수 있다. - 원격 상황에서는 효율성만을 앞세우기보다 팀이 현재 상황을 견뎌내는 데 필요한 소통과 관계 형성에 충분한 시간을 배정해야 한다. 실무적으로는 프로젝트 초기에 다양한 사용자와 실제 사용 환경을 점검하고, 현지화·접근성 담당자를 디자인 리뷰에 참여시키는 것이 좋다. 또한 원격 팀이라면 업무 가시성과 정기적인 협업 시간을 명시적인 프로세스로 만들어야 포용적인 제품과 건강한 협업 문화를 함께 구축할 수 있다.

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

Figma접근성remote-collaborationuser-experience-design+2

figma·2020년 9월 28일·3분 읽기큐레이션 요약

폰트가 깨질 때

폰트 폴백(font fallback)은 현재 글꼴에 필요한 글리프가 없을 때 다른 글꼴이나 대체 표시를 사용하는 컴퓨터 타이포그래피机制이다. 네모 상자, 깨진 이모지, 플랫폼마다 다르게 보이는 특수문자, 이모지 삽입 후 줄이 내려가는 현상 등은 대부분 이 메커니즘과 관련 있다. 이는 단순한 버그라기보다, 서로 다른 글꼴·문자 집합·운영체제가 텍스트를 처리하는 과정에서 발생하는 필연적인 결과다. ## 일상에서 나타나는 폰트 폴백 - 지원되지 않는 문자는 네모 상자, 물음표, 십자가가 들어간 상자 등으로 표시될 수 있다. - 발신자와 수신자의 환경에 설치된 글꼴이나 지원하는 문자 범위가 다르면 같은 이모지가 분해되거나 전혀 다른 모양으로 보인다. - 트위터 등에서 보이는 ‘특수 폰트’는 실제 글꼴을 바꾼 것이 아니라 유니코드의 다른 문자나 기호를 조합한 경우가 많다. - 이런 문자는 화면에서는 장식적으로 보일 수 있지만, 스크린 리더가 부자연스럽게 읽거나 다른 환경에서 빈 상자로 표시될 수 있다. - 이모지를 추가했을 때 줄 높이나 기준선이 변하는 것도 해당 글리프의 크기와 글꼴 메트릭이 기존 텍스트와 다르기 때문이다. - 카오모지나 결합 문자는 플랫폼·폰트별 지원 차이로 정렬과 모양이 달라질 수 있다. ## 글리프와 글꼴의 문자 범위 - 글리프는 글꼴이 실제로 그려내는 문자 모양을 뜻한다. 문자 자체와 글리프는 구분되지만, 글에서는 이해를 돕기 위해 대략적인 의미의 ‘문자’로 설명한다. - 서유럽권 글꼴도 대문자·소문자·숫자·문장 부호·악센트·기호 등을 포함해 수백 개의 글리프가 필요하다. - 중국어·일본어 글꼴은 수천 개의 한자를 포함해야 하므로 필요한 글리프 수가 훨씬 많다. - 합자(ligature), 숫자 스타일, 대체 글자 모양 같은 OpenType 기능을 지원하려면 기본 문자 외의 글리프도 추가해야 한다. - 라틴 문자만 지원하더라도 서유럽, 중부 유럽, 그리스어, 키릴 문자, 베트남어 등으로 범위를 넓히면 글리프 수가 계속 증가한다. - 모든 문자를 하나의 글꼴에 넣는 것은 현실적으로 어렵기 때문에 글꼴 제작자는 지원 범위를 선택해야 한다. ## `.notdef`: 글꼴이 모르는 문자의 표시 - 글꼴이 요청받은 문자를 포함하지 않을 때 사용하는 마지막 대체 글리프의 이름이 `.notdef`다. - 일반적으로 사각형, 십자가가 있는 상자, 물음표가 들어간 상자 등으로 표시된다. - `.notdef`는 특정 유니코드 문자가 아니라, 해당 글꼴 내부에서 “이 문자를 표현할 수 없다”는 사실을 나타내는 글리프다. - 화면에 네모가 표시되어도 내부의 텍스트 데이터가 네모 문자로 바뀌는 것은 아니다. - 따라서 텍스트를 복사하면 원래 문자가 유지되며, 나중에 해당 문자를 지원하는 글꼴로 바꾸면 제대로 표시될 수 있다. - 표시 모양과 크기는 글꼴 디자이너가 정하므로 글꼴마다 빈 사각형, 십자가, 장식된 상자 등 다양한 형태가 나타난다. ## 금속 활자와 디지털 글꼴의 차이 - 금속 활자 시대에는 글자와 글꼴의 활자가 물리적으로 결합되어 있어, 존재하지 않는 문자를 출력하려는 문제가 상대적으로 적었다. - 디지털 환경에서는 텍스트와 글꼴이 분리되어 있다. - 사용자는 다른 사람이 오래전에 작성한 텍스트나, 작성 당시 존재하지도 않았던 글꼴이 필요한 문자를 열 수 있다. - 이 때문에 글꼴은 자신이 표현할 수 없는 문자를 만났을 때 `.notdef` 같은 대체 수단으로 응답해야 한다. - 폰트 폴백은 이러한 디지털 텍스트 환경에서 서로 다른 문자 집합과 글꼴을 연결하는 핵심 장치다. ## 실용적인 결론 특수문자나 이모지를 사용할 때는 상대방의 운영체제와 글꼴 지원 여부가 다를 수 있음을 고려해야 한다. 장식용 유니코드 문자는 접근성과 호환성이 떨어질 수 있으므로 중요한 정보에는 일반 텍스트를 함께 제공하고, 디자인 작업에서는 여러 글꼴과 환경에서 폴백 결과를 확인하는 것이 좋다.

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

typographyscreen-readersunicodeopentype+3

figma·2020년 9월 23일·3분 읽기큐레이션 요약

제품 팀의 Figma 협업

Figma는 개방형 API와 플러그인을 통해 제품 개발 전 과정의 협업 도구와 연결될 수 있다고 설명합니다. Confluence, GitLab, Avocode, Pendo, Bubble 등의 통합을 활용하면 문서화·개발 협업·디자인 핸드오프·고객 피드백·프로토타입 구현을 하나의 흐름으로 이어갈 수 있습니다. 결과적으로 최신 디자인을 여러 도구에 반복해서 옮기거나 정보를 찾기 위해 도구를 오가는 수고를 줄이고, 디자인에서 출시까지의 속도를 높일 수 있습니다. ## 개방형 디자인 플랫폼의 필요성 - 제품 디자인은 Figma에서 진행하더라도 실제 개발·테스트·출시는 개발자와 제품 관리자용 도구에서 이루어집니다. - Figma의 개방형 API와 통합 기능을 사용하면 팀이 기존 업무 도구 안에서 디자인을 활용할 수 있습니다. - 통합의 주요 목적은 다음과 같습니다. - 제품 문서에 최신 디자인 반영 - 개발 이슈와 디자인을 연결 - 개발자가 디자인 사양과 에셋을 쉽게 확인 - 실제 사용자에게 프로토타입을 테스트 - 코드 작성 없이 디자인을 웹 앱으로 구현 ## Confluence: 최신 디자인을 제품 문서에 삽입 - Figma 파일과 프로토타입을 Confluence 페이지에 라이브 임베드할 수 있습니다. - 제품 사양서와 요구사항 문서 안에서 디자인을 직접 확인할 수 있어 개발자가 별도 링크나 오래된 스크린샷을 찾을 필요가 없습니다. - Figma 파일이 변경되면 문서에 표시되는 디자인도 최신 상태로 유지됩니다. - 기능 기획, 프로젝트 현황 공유, 개발 문서화 등에서 디자인과 관련 설명을 한곳에 모을 수 있습니다. ## GitLab: 이슈와 디자인을 연결하는 개발 협업 - GitLab 플러그인을 사용하면 Figma 디자인을 GitLab 이슈에 직접 업로드할 수 있습니다. - 개발자는 작업 중인 이슈 안에서 관련 디자인을 확인하고 변경 사항을 검토할 수 있습니다. - 디자인을 이슈의 맥락에 맞춰 공유할 수 있어 요청 사항과 구현 결과를 비교하기 쉽습니다. - 스프린트 작업, 신규 요청, 버그 대응 과정에서 디자인 공유에 드는 시간을 줄여줍니다. ## Avocode: 개발자용 디자인 핸드오프 - Avocode 플러그인은 Figma 디자인을 Avocode 프로젝트와 동기화합니다. - 디자이너가 탐색적 시안을 계속 수정하는 동안에도 개발자는 확정된 디자인의 레이어와 상세 정보를 확인할 수 있습니다. - 개발자는 다음 정보를 직접 확인하거나 추출할 수 있습니다. - 디자인 치수 - 색상 코드 - 이미지 및 기타 에셋 - CSS, CSS-in-JS, React Native 등을 포함한 코드 스니펫 - 디자인 도구와 개발 핸드오프 도구를 반복해서 오갈 필요가 없어 디자인을 코드로 전환하는 과정이 단순해집니다. ## Pendo: 실제 사용자 대상 프로토타입 검증 - Pendo 통합은 Figma의 라이브 디자인을 제품 안에 삽입할 수 있게 합니다. - 제품 관리자는 특정 사용자 세그먼트가 실제 제품을 사용하는 맥락에서 새 기능이나 변경안을 보여줄 수 있습니다. - 사용자는 프로토타입을 직접 경험한 뒤 다음 방식으로 의견을 남길 수 있습니다. - 설문 응답 - 자유 형식의 텍스트 피드백 - 사용자 조사 인터뷰 예약 - 개발 전에 고객 반응을 수집하면 중요한 문제를 조기에 발견하고, 실제 요구에 맞지 않는 기능에 투자하는 위험을 줄일 수 있습니다. ## Bubble: Figma 디자인을 코드 없이 웹 앱으로 전환 - Bubble 통합을 사용하면 Figma 디자인을 기반으로 웹 앱을 만들 수 있습니다. - Figma에서 새 디자인을 만들거나 커뮤니티 파일을 활용한 뒤 Bubble로 직접 가져올 수 있습니다. - 가져오기 과정에서: - Figma의 각 프레임은 Bubble 앱의 새로운 페이지가 됩니다. - 벡터 요소는 이미지로 업로드됩니다. - 이를 통해 디자인 단계와 실제 구현 사이의 시간을 단축하고, 코드 작성 없이 초기 웹 앱을 빠르게 구성할 수 있습니다. ## 실용적인 활용 방향 팀은 모든 도구를 동시에 도입하기보다 업무 흐름에 맞는 통합부터 선택하는 것이 좋습니다. 문서 중심 조직은 Confluence, 개발 이슈 중심 조직은 GitLab, 정교한 핸드오프가 필요하면 Avocode, 출시 전 검증이 중요하면 Pendo, 빠른 프로토타입 구현이 목표라면 Bubble을 우선 검토할 수 있습니다. 제공된 글 내용은 Bubble 섹션 중간에서 끝나므로, 원문의 여섯 번째 통합에 대한 내용은 포함되어 있지 않습니다.

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

Figmagitlabdesign-collaborationReact Native+3

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

피그마 내부 이야기: 신입

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

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

디자인 시스템웹 개발product-developmentc+++1

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

디자인에서 신뢰의 다양한 차

디자인 협업에서 신뢰는 단순한 친밀감을 넘어, 팀과 고객이 솔직하게 소통하고 반복적인 작업 과정을 안전하게 공유하게 만드는 기반이다. 신뢰를 구축하려면 구성원을 인간적으로 이해하고, 진행 중인 작업의 상태와 피드백 범위를 명확히 하며, 디자인의 윤리적·사회적 영향까지 공개적으로 논의해야 한다. 이러한 문화는 단기간에 만들어지지 않지만, 의도적인 대화와 명확한 협업 규칙을 통해 강화할 수 있다. ## 인간적인 관계를 통한 신뢰 형성 - 신뢰는 직속 동료뿐 아니라 제품 개발에 참여하는 모든 사람을 이해하는 데서 시작된다. - 짧은 안부 대화나 회의 전후의 캐주얼한 대화, 이메일 대신 간단한 통화 등을 통해 서로의 생각과 업무 방식을 파악할 수 있다. - 디자인 비평에서 피드백이 배려와 지원에서 비롯된다는 확신이 있어야 구성원이 방어적으로 반응하지 않는다. - 팀원들이 서로의 의도와 어려움을 긍정적으로 해석하는 문화를 만들면, 더 솔직하고 직접적인 피드백이 가능해진다. - 공감은 협업자의 관점과 작업 방식을 이해하고 신뢰를 유지하는 중요한 도구다. ## 진행 중인 작업을 안전하게 공유하기 - Figma처럼 실시간으로 작업물이 업데이트되는 환경에서는 고객이 초기 아이디어와 미완성 시안을 그대로 보게 된다. - 이러한 투명성은 프로젝트의 현재 상태를 공유하는 데 유용하지만, 충분히 다듬어지지 않은 작업에 즉각적인 피드백이 들어오는 부담도 만든다. - 협업 파일을 함께 사용할 때는 다음과 같은 운영 규칙을 미리 정해야 한다. - 작업이 탐색 단계인지, 검토 단계인지 상태를 표시한다. - 현재 피드백을 받을 수 있는지 명시한다. - 필요한 피드백의 수준을 구체적으로 설명한다. 예를 들어 세부 디자인이 아닌 방향성에 대한 의견을 요청할 수 있다. - 상태 주석이나 진행 단계 표시를 활용하면 고객과 내부 팀이 작업물을 과도하게 해석하는 일을 줄일 수 있다. - 디자인은 계속 변하므로 문서가 프로젝트의 최신 상태를 반영하도록 지속적으로 관리해야 한다. ## 공개적인 대화와 이견 장려 - 신뢰는 일상적인 업무뿐 아니라 디자인 윤리, 기술의 역할, 제품이 사회에 미치는 영향 같은 큰 주제를 논의할 때도 필요하다. - 직급이나 역할과 관계없이 누구나 문제를 제기할 수 있는 환경을 만들어야 한다. - ‘Designated Dissenter’와 같은 활동은 한 명에게 의도적으로 반대 의견을 내는 역할을 맡겨 팀의 가정과 결정에 질문을 던지게 한다. - 이견을 제도화하면 특정 개인의 성격이나 직급에 의존하지 않고 다양한 관점을 끌어낼 수 있다. - 이러한 논의는 팀원 간 이해를 넓히고, 제품이 가져올 장기적·사회적 결과를 검토하는 데 도움을 준다. ## 신뢰를 만드는 협업 원칙 - 신뢰는 한 번의 워크숍이나 규칙만으로 생기지 않고 반복적인 상호작용을 통해 형성된다. - 팀원과 고객을 업무 역할이 아닌 사람으로 이해하려는 시간을 확보한다. - 파일과 문서에 작업 상태, 피드백 요청 범위, 최신 진행 상황을 명확히 기록한다. - 긍정적 의도를 전제로 하되, 불편한 의견과 반대 의견도 안전하게 제시할 수 있도록 한다. - 실무적인 협업 규칙과 윤리적 논의를 함께 운영해야 지속 가능한 디자인 문화를 만들 수 있다. 실제로는 프로젝트 시작 시 피드백 방식과 작업 상태 표기 규칙을 합의하고, 정기적으로 짧은 관계 형성 대화와 이견 토론을 운영하는 것이 가장 효과적이다.

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

Figma프로덕트 디자인real-time-collaborationdesign-collaboration+1

figma·2020년 9월 16일·4분 읽기큐레이션 요약

코드와 디자인 사이의 긴

Figma는 디자인의 자유로운 탐색과 코드의 구조적·재사용 가능한 접근 사이의 긴장을 없애기보다 생산적인 협업 방식으로 받아들여야 한다고 주장한다. 이를 위해 디자인 시스템을 코드의 컴포넌트 구조와 가깝게 만들고, 디자이너와 개발자가 같은 시스템을 더 효율적으로 이해하고 활용할 수 있도록 Variants, Interactive Components, 개선된 Auto Layout, Inspect Tab 등을 발표했다. 궁극적으로 Figma는 디자인과 코드를 분리된 작업이 아니라 제품을 함께 만드는 연결된 과정으로 발전시키려 한다. ## 디자인과 코드 사이의 긴장 - 디자이너는 무엇을 만들지 결정하며 자유로운 시각적 탐색과 빠른 반복을 중시한다. - 개발자는 정해진 구조 안에서 실제 제품을 구현하며 재사용성, 일관성, 규칙을 중시한다. - 개발자에게 컴포넌트를 “깨는” 행위가 디자이너에게는 창의적인 실험일 수 있고, 개발자의 구조가 디자이너에게는 제약처럼 느껴질 수 있다. - Figma는 코드의 엄격성과 재사용성을 디자인에 적용하되, 디자인의 빠른 반복과 자유로운 탐색은 유지해야 한다고 본다. ## Variants로 코드와 디자인 컴포넌트 연결 - 프런트엔드의 하나의 컴포넌트는 상태와 맥락에 따라 여러 형태로 표현된다. - 예: 버튼의 기본형·보조형 - 작은 크기·큰 크기 - iOS·Android별 스타일 - 기존 Figma에서는 이런 변형을 각각 별도의 컴포넌트로 관리해야 해 코드 구조와 디자인 구조가 달라졌다. - **Variants**는 같은 컴포넌트의 여러 변형을 하나의 논리적 컴포넌트로 그룹화한다. - 이를 통해 에셋 패널을 단순화하고, 디자인 컴포넌트를 코드의 컴포넌트 모델에 더 가깝게 표현할 수 있다. - 발표 당시 2020년 11월 출시 예정으로 소개됐다. ## Interactive Components로 프로토타이핑 간소화 - Variants를 사용하면 버튼이나 입력 필드의 여러 상태를 하나로 묶을 수 있다. - 기존에는 상태 간 전환을 표현하려면 여러 프레임과 오버레이를 수동으로 연결해야 했다. - **Interactive Components**는 Variants 사이에 프로토타이핑 상호작용을 직접 설정할 수 있게 한다. - 컴포넌트 인스턴스를 프로토타이핑 모드에서 즉시 동작하는 요소처럼 사용할 수 있어, 반복적인 프레임 연결 작업을 줄인다. - 당시 2021년 1월 출시 예정으로 발표됐다. ## 코드처럼 설계하는 Auto Layout - Auto Layout은 텍스트가 바뀌어도 버튼이나 프레임 크기가 자동으로 조정되도록 해 반응형 UI 제작을 돕는다. - Figma는 Auto Layout을 웹의 CSS 박스 모델과 Flexbox에 더 가깝게 발전시키려 했다. - 개선 사항에는 다음이 포함된다. - 더 단순해진 사용자 인터페이스 - 가로·세로 양축에서 요소를 늘리는 기능 - 방향별로 독립적인 패딩 설정 - 내비게이션 아이콘처럼 자주 쓰이는 UI 패턴에 맞춘 간격 설정 - 디자이너가 수동으로 위치와 크기를 조정하는 대신, 코드의 레이아웃 규칙에 가까운 방식으로 디자인할 수 있게 하는 것이 목표다. ## 대규모 디자인 시스템을 위한 컴포넌트 탐색 - 수천 개의 컴포넌트를 사용하는 대규모 라이브러리에서는 정확한 이름을 기억하거나 긴 목록을 직접 찾아야 하는 불편이 있었다. - **Instance Swap Menu**가 개선되어 다음 기능을 제공한다. - 컴포넌트 썸네일 - 검색 - 키보드 단축키 - Variants와 함께 사용하면 여러 컴포넌트를 일일이 찾는 부담을 줄이고, 대규모 디자인 시스템에서도 적절한 인스턴스를 빠르게 교체할 수 있다. - 이 기능은 글 작성 당시 바로 사용할 수 있는 기능으로 소개됐다. ## Inspect Tab으로 개발자 전달 정보 강화 - 기존 Code 패널을 대체하는 **Inspect Tab**은 개발자가 구현에 필요한 정보를 더 쉽게 확인하도록 설계됐다. - 선택한 레이어의 이름을 상단에 표시해 디자이너와 개발자가 어떤 요소를 구현하는지 명확히 확인할 수 있다. - 다음과 같은 디자인 속성을 구분해 보여준다. - Variants - 색상 - 그림자 - 콘텐츠 - 타이포그래피 - 테두리 - 개별 값을 클릭해 클립보드로 복사할 수 있으며, 여러 `key:value` 값으로 구성된 코드 조각도 한 번에 복사할 수 있다. - 디자인 명세를 별도로 정리하거나 개발자가 값을 수동으로 옮기는 과정을 줄여 구현 전환을 효율화한다. Figma의 방향은 디자인을 코드처럼 획일화하는 것이 아니라, 코드의 구조성과 재사용성을 디자인 시스템에 도입하면서도 디자이너의 창의적 탐색을 보존하는 것이다. 실무에서는 Variants로 상태와 스타일을 체계화하고, Auto Layout으로 레이아웃 규칙을 정의하며, Inspect Tab을 통해 개발자에게 구현 정보를 명확히 전달하는 방식이 효과적이다.

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

Figma디자인 시스템프로토타이핑CSS+4

figma·2020년 9월 15일·3분 읽기큐레이션 요약

피칭과 발표에 관하여

좋은 프레젠테이션은 화려한 시각 자료보다 청중에게 맞는 이야기와 명확한 메시지에서 출발한다. 발표자는 청중의 관심사와 문제를 이해한 뒤, 공감할 수 있는 문제를 제시하고 해결책과 행동 요청으로 이어지는 구조를 만들어야 한다. 또한 목소리, 몸짓, 감정 표현을 조절하고 발표 환경에 맞게 전달 방식을 다듬어야 한다. ## 스토리텔링이 발표를 설득력 있게 만드는 이유 - 발표의 목적은 정보 나열이 아니라 청중이 이해하고, 행동하고, 생각을 바꾸도록 돕는 것이다. - 글쓴이는 ‘Pet Rocks’ 피치에서 시장 통계와 제품 역사를 설명했지만, 우승팀은 앱과 마케팅 캠페인을 활용해 하나의 이야기를 만들었다. - 스토리텔링은 타고난 재능이 아니라 반복적인 연습으로 발전시킬 수 있는 기술이다. - 수업 발표, 팀 회의, 취업 면접, 투자 피치 등 다양한 상황에서 복잡한 아이디어를 명확하게 전달하는 데 유용하다. - 발표는 크게 다음 세 요소로 구성된다. - **Content**: 무엇을 말할 것인가 - **Delivery**: 어떻게 말할 것인가 - **Visuals**: 아이디어를 시각적으로 어떻게 보여줄 것인가 ## 청중의 신뢰를 얻는 콘텐츠 설계 - 발표를 준비하기 전에 청중을 파악해야 한다. - 다음 질문을 통해 청중의 관점과 기대를 분석한다. - 청중은 무엇을 중요하게 생각하는가? - 어떤 문제, 필요, 목표를 가지고 있는가? - 왜 이 발표를 듣고 있는가? - 발표를 통해 무엇을 얻을 수 있는가? - 어떤 업계 용어와 커뮤니케이션 방식을 사용하는가? - 청중이 “발표자가 우리의 상황을 이해하고 있다”고 느껴야 발표 내용에 신뢰를 갖는다. - 시각 자료와 발표 스타일은 중요하지만, 궁극적으로는 전달하려는 이야기를 뒷받침하는 역할을 해야 한다. ## 문제에서 해결책으로 이어지는 이야기 구조 - 발표의 중심에는 청중과 관련된 이야기가 있어야 한다. - 효과적인 기본 구조는 다음과 같다. 1. 청중과 상황을 조사한다. 2. 청중이 공감할 수 있는 문제를 정의한다. 3. 문제를 해결하는 해결책을 소개한다. 4. 해결책이 어떻게 작동하고 문제를 어떻게 개선하는지 설명한다. 5. 청중에게 구체적인 행동을 요청한다. - 문제 정의에는 다음 문장 구조를 활용할 수 있다. - “**[이해관계자]**는 **[과업]**에 대해 **[감정]**을 느끼며 **[행동]**해야 하지만, **[장애물]**에 직면해 있다.” - 해결책을 설명할 때 문제 정의에서 사용한 표현이나 사례를 다시 활용하면 이야기의 일관성과 기억하기 쉬운 흐름을 만들 수 있다. - 발표의 마지막에는 CTA(Call-To-Action)를 포함한다. - 프로젝트를 추가 검토하도록 승인 요청 - 자금 지원 요청 - 멘토링 요청 - 특정 관점이나 행동의 변화 요청 ## 목소리와 몸짓으로 감정 전달하기 - 같은 슬라이드라도 목소리의 높낮이, 표정, 자세, 움직임에 따라 설득력이 크게 달라진다. - 자신의 발표를 녹음해 들어보면 말투, 억양, 속도에서 개선할 점을 발견할 수 있다. - 발표 전에는 몸을 움직이거나 자세를 바로잡는 등 자신감을 높이는 준비가 도움이 된다. - 발표 중에는 다음과 같은 표현을 활용한다. - 중요한 부분에서 목소리를 높이거나 속도를 조절한다. - 손동작과 자연스러운 이동으로 메시지를 강조한다. - 핵심 내용을 말할 때 몸을 약간 앞으로 기울인다. - 청중과 눈을 맞춘다. - 발표자의 진짜 감정은 청중에게 전달된다. 발표자가 주제에 열정을 보이면 청중도 더 쉽게 몰입한다. - 청중의 눈맞춤과 몸짓을 관찰하며 발표 방식을 조정해야 한다. - 집중력이 떨어져 보이면 이동 범위를 넓힌다. - 목소리를 조금 키운다. - 청중의 여러 사람과 시선을 나눈다. ## 온라인 발표에 맞춘 전달 방식 조정 - 원격 발표에서는 기술적 문제뿐 아니라 평소의 억양과 손동작이 화면을 통해 충분히 전달되지 않을 수 있다. - 온라인 발표를 준비할 때도 자신의 목소리를 녹음해 청중이 듣는 방식과 실제 인상을 점검하는 것이 좋다. - 대면 발표에서 자연스럽던 표현이 가상 환경에서는 약하게 보일 수 있으므로, 목소리와 표정, 화면 안에서의 움직임을 의식적으로 조정해야 한다. 발표를 준비할 때는 먼저 청중과 문제를 정의하고, 문제-해결책-행동 요청의 흐름을 만든 뒤, 녹음과 리허설로 전달 방식을 점검하는 것이 좋다. 멋진 슬라이드보다 청중이 공감할 수 있는 이야기와 분명한 다음 행동이 발표의 성패를 좌우한다.

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

Figmapresentation-designstorytellingdesign-strategy+2

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

피그마의 새로운 EMEA 본

Figma는 EMEA 지역 사용자를 더 잘 지원하기 위해 런던에 지역 본부(HQ)를 열기로 했다. 이 사무실은 단순한 물리적 공간이 아니라, 현지 사용자와 같은 시간대를 공유하고 다양한 인재를 확보하며 지역별 디자인 커뮤니티를 이해하기 위한 거점이다. 코로나19로 대면 업무가 지연된 상황에서도 하이브리드 근무와 온라인 행사로 지역 협력을 이어가겠다는 것이 글의 결론이다. ## 런던 EMEA 본부 설립 배경 - Figma는 미국 외 지역의 사용자가 매우 많은 글로벌 서비스다. - 2020년 기준 주간 활성 사용자의 **81%가 미국 외 지역**에 있었다. - 기존의 미국 중심 시간대 운영만으로는 EMEA 지역 사용자에게 충분한 지원을 제공하기 어려웠다. - 이에 따라 유럽·중동·아프리카 지역을 전담하는 런던 허브 오피스를 설립하기로 했다. ## 사무실 이상의 역할 - 런던 오피스는 단순히 직원이 출근하는 공간이 아니라 지역 사업과 커뮤니티를 연결하는 거점이다. - 주요 목적은 다음과 같다. - EMEA 사용자와 더 많은 시간을 공유해 지원 대응력을 높임 - 현지의 다양한 인재를 채용 - 지역별 업무 문화와 사용자 요구를 직접 이해 - 각국의 디자인 커뮤니티 및 기업 고객과 긴밀히 협력 - Figma는 하이브리드 근무를 추진하고 있어, 원격 근무와 대면 근무를 함께 지원하는 허브 형태를 지향했다. ## 글로벌 사용자와 현지 커뮤니티의 중요성 - 창업자는 Figma 출시 이후 여러 국가의 사용자와 커뮤니티를 직접 만나며 제품에 대한 통찰을 얻었다. - 런던, 파리, 헬싱키, 키이우, 모스크바, 자카르타, 싱가포르 등 다양한 도시의 고객을 방문했다. - Deliveroo, Zalando, Spotify, Booking.com과 같은 기업 고객과 협력하며 EMEA 지역의 성장 가능성을 확인했다. - 사용자와 직접 교류하는 과정은 제품 개선뿐 아니라 지역별 요구와 디자인 생태계를 파악하는 데 중요한 역할을 했다. ## 유럽 지역 팀 확장 - Figma는 2019년 초 암스테르담에 제품 전문가 팀을 채용하며 유럽 내 지원을 강화했다. - 이후 런던 지역 팀을 별도로 구축하기로 결정했다. - 발표 당시 런던 지역에는 **14명의 팀원**이 원격으로 근무하고 있었다. - 향후 런던 팀과 본부를 중심으로 EMEA 사용자 및 기업 고객과의 협력을 확대할 계획이었다. ## 코로나19와 온라인 전환 - 코로나19로 인해 새 사무실을 즉시 대면 업무에 활용하거나 개장 행사를 열 수 없었다. - Figma는 안전하게 대면 근무를 재개할 수 있을 때 공식적으로 오피스를 열 예정이라고 밝혔다. - 그동안에는 온라인 방식으로 지역 커뮤니티와의 연결을 유지하기 위해 첫 가상 사용자 콘퍼런스인 **Config Europe**을 개최하기로 했다. - 이는 물리적 사무실이 준비되지 않은 상황에서도 지식 공유와 커뮤니티 형성을 이어가는 대안이었다. 지역 확장을 추진하는 기업이라면 사무실 개설 자체보다 시간대 지원, 현지 인재 채용, 고객과의 직접 교류, 온라인 커뮤니티 운영을 함께 설계해야 한다. Figma의 사례는 하이브리드 근무 환경에서도 지역별 거점을 활용해 글로벌 사용자 지원을 강화할 수 있음을 보여준다.

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

Figmacollaborationdesign-toolsweb-design+2

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

온라인 쇼핑객을 위해 디자인

Design Within Reach(DWR)는 온라인에서도 오프라인 쇼룸과 유사한 개인화된 구매 경험을 제공하기 위해 웹사이트를 전면 개편했다. DWR과 BASIC®은 Figma를 활용해 하나의 팀처럼 실시간 협업하고, 110시간의 고객 조사와 200명 이상의 사용자 테스트를 통해 제품 탐색과 상담 경험을 개선했다. 그 결과 라이브 채팅 이용자의 구매 가능성이 9배 높아졌으며, 여러 Herman Miller 브랜드로 확장 가능한 디자인 시스템도 구축했다. ### 투명한 에이전시 협업과 실시간 공동 작업 - DWR과 BASIC®은 업무를 분리하기보다 공동 창작을 중심으로 하나의 통합된 팀처럼 운영했다. - 서로 다른 회사와 시간대에서 일하는 디자이너들이 같은 Figma 파일에 동시에 접근해 작업했다. - 파일을 복사하거나 최신 버전을 전달하고 링크를 갱신하는 과정이 사라져 협업 효율이 높아졌다. - 시간대 차이를 활용해 한 팀이 작업을 마치면 다른 팀이 이어받는 방식으로 사실상 하루 14시간의 연속 작업이 가능했다. - CEO와 경영진도 Figma 프로토타입 링크를 통해 진행 상황을 쉽게 확인하고 의사결정에 참여할 수 있었다. ### 오프라인 쇼룸 경험의 온라인 구현 - 웹사이트 개편의 목표는 고객이 온라인에서 가구를 구매할 때 생기는 주요 질문에 답하고, 실제 쇼룸 방문에 가까운 경험을 제공하는 것이었다. - 총 110시간의 고객 조사와 200명 이상의 참가자를 대상으로 한 심층 사용자 테스트를 진행했다. - Figma 프로토타입을 실제 웹사이트처럼 제작해 사용성 테스트, 빠른 반복 수정, 즉각적인 인사이트 수집을 수행했다. - 2020년 7월 새 사이트를 출시했으며, 다양한 화면에 대응하는 반응형 디자인과 영업 담당자와 연결되는 영상·라이브 채팅 기능을 도입했다. - 라이브 채팅을 이용한 방문자는 그렇지 않은 방문자보다 온라인 구매 가능성이 9배 높았다. - 일반적으로 대규모 웹사이트 출시 직후에는 구매가 일시적으로 감소할 수 있지만, DWR은 출시 직후부터 구매 증가를 경험했다. ### 여러 브랜드로 확장되는 디자인 시스템 - DWR 웹사이트 개편을 계기로 Herman Miller 전체 브랜드를 위한 첫 디자인 시스템을 만들었다. - 공통 컴포넌트와 공유된 시각 언어를 기반으로 장기적으로 확장 가능한 구조를 설계했다. - 개발자는 반복 가능한 컴포넌트를 더 빠르게 구현할 수 있게 됐다. - 콘텐츠 작성자는 미리 제작된 컴포넌트를 드래그하고 이미지와 텍스트만 수정해 페이지를 직접 구성할 수 있게 됐다. - Figma의 클라우드 기반 에셋 라이브러리를 통해 내부 팀과 전 세계 외부 파트너가 디자인 자산과 시스템을 쉽게 공유할 수 있다. - DWR의 컴포넌트 라이브러리는 향후 Herman Miller의 다른 전자상거래 사이트에도 적용될 기반이 됐다. ### 실용적인 시사점 온라인 쇼핑 경험을 개선하려면 단순히 시각적으로 아름다운 사이트를 만드는 것보다 고객 조사, 실제 프로토타입 테스트, 실시간 협업을 하나의 흐름으로 연결해야 한다. 또한 반복 가능한 컴포넌트와 공통 디자인 언어를 디자인 시스템으로 정리하면 개발 속도와 콘텐츠 운영 효율을 높이면서 여러 브랜드와 채널로 일관되게 확장할 수 있다.

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

Figma디자인 시스템사용자 경험반응형 디자인+3

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

멀티 브랜드 디자인 시스템 구축

멀티 브랜드 디자인 시스템은 일관성과 효율성을 제공하되, 엄격한 규칙보다 유연성을 중심으로 설계해야 한다. 기본 컴포넌트와 브랜드별 토큰, 코드 연계를 통해 다양한 요구를 수용하고 빠르게 확장할 수 있다. 또한 디자인 시스템은 완성된 산출물이 아니라 실제 사용 데이터를 관찰하며 계속 발전시키는 살아 있는 시스템이어야 한다. ## 유연성을 우선하는 설계 - 디자인 시스템을 지나치게 규정적으로 운영하면 디자이너의 창의성을 제한하고, 결국 시스템 밖에서 작업하게 만들 수 있다. - Harry’s는 복잡도와 유연성이 서로 다른 여러 계층으로 시스템을 구성했다. - 기본 컴포넌트: 단순하고 표준화된 구성 - 스타터 키트: 더 복잡하고 유연한 구성 - 대부분의 프로젝트는 단순한 계층으로 해결하되, 특수한 요구에는 커스텀 구성을 허용한다. - 기본값은 단순하게 유지하면서도 예외를 수용하면 효율성과 창의성을 동시에 확보할 수 있다. ## 토큰을 활용한 멀티 브랜드 확장 - Condé Nast처럼 여러 브랜드를 운영하는 조직에서는 브랜드마다 다른 시각적 특성을 수용해야 한다. - 모듈화된 컴포넌트와 디자인 토큰을 사용하면 동일한 구조를 유지하면서 브랜드별 값을 적용할 수 있다. - 하나의 토큰이 브랜드마다 다른 값을 가질 수 있다. - 예: `prominent text`라는 토큰에 Vogue, The New Yorker, Bon Appétit별 폰트를 각각 지정 - 이런 방식은 컴포넌트를 브랜드별로 별도 제작하지 않고도 시스템을 확장하게 해준다. ## 계속 진화하는 디자인 시스템 - 시스템을 구축한 뒤에도 실제 사용 과정에서 무엇이 잘 작동하고 실패하는지 관찰해야 한다. - Shopify는 디자인 시스템을 “휘어지지만 부러지지 않는” 기반으로 만든다는 방향을 취한다. - 디자인 시스템을 박물관의 전시물처럼 보존하려 하면 변화하는 요구사항을 반영할 수 없다. - 디자이너뿐 아니라 최종 사용자도 관찰해야 한다. - Shopify의 경우 상점 운영자인 머천트가 시스템의 실제 사용자인 만큼, 사용 중 어디서 문제가 발생하는지 확인한다. - 컴포넌트 사용량, 라이브러리 활용 추세 등의 데이터를 분석하면 개선 우선순위를 정할 수 있다. - 시스템이 어떻게 실패하는지 확인하고 이를 바탕으로 다시 설계하는 과정이 중요하다. ## 디자인과 코드의 연결 - 디자인 컴포넌트를 코드로 연결하면 디자인과 개발 간의 전달 비용을 줄이고 구현 속도를 높일 수 있다. - Condé Nast는 JavaScript 기반 사이트에서 JSON으로 토큰을 정의한다. - 커스텀 플러그인을 통해 토큰 값을 JSON으로 가져오거나 내보내 디자인과 코드의 변경 사항을 동기화한다. - 토큰 기반 구조는 새로운 시장이나 브랜드를 빠르게 구축하고 디자이너와 엔지니어 간의 핸드오프를 원활하게 한다. - 멀티 브랜드 환경이 아니더라도 색상이나 타이포그래피에 목적과 값을 연결하는 것부터 시작할 수 있다. - 예: 특정 색상을 직접 `#000000`으로 부르기보다 `text-primary`처럼 용도 중심으로 명명 - 목적과 값을 분리하면 시스템의 복잡도와 불필요한 세분화를 파악하기 쉬워진다. ## 조직에 맞는 시스템 구축 - 모든 조직에 동일하게 적용되는 디자인 시스템은 없다. - 팀 규모, 조직 구조, 브랜드 수, 개발 환경, 업무 우선순위에 맞춰 범위와 복잡도를 결정해야 한다. - 처음부터 거대한 시스템을 만들기보다 현재 반복적으로 사용되는 패턴과 컴포넌트부터 정리하는 것이 현실적이다. - 시스템의 규칙보다 실제 팀이 쉽게 사용하고 변경할 수 있는 프로세스를 만드는 것이 더 중요하다. 실무에서는 기본 컴포넌트와 목적 기반 토큰부터 시작하고, 브랜드별 차이는 토큰 값으로 관리하는 방식을 추천한다. 이후 사용 데이터와 사용자 피드백을 바탕으로 시스템을 지속적으로 수정하되, 예외와 실험을 허용해 시스템 밖으로 이탈할 필요가 없도록 해야 한다.

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

디자인 시스템JavaScript디자인 토큰웹 개발+2

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

Inside Figma: 엔터프라이즈

Figma의 엔터프라이즈 제품은 고객 요청을 그대로 구현하는 데 그치지 않고, 다양한 규모와 역할의 조직이 지속적으로 사용할 수 있는 기반을 만드는 것을 목표로 한다. 이를 위해 Figma는 관리자와 최종 사용자의 업무를 함께 이해하고, 영업·지원·마케팅·디자인·엔지니어링 등 여러 팀과 협력해 Admin Settings를 전면적으로 재설계했다. 결론적으로 엔터프라이즈 기능의 핵심은 개별 기능 추가보다 확장 가능한 구조와 중요한 관리 업무에 최적화된 사용자 경험이다. ## 엔터프라이즈 제품의 역할 - Figma의 엔터프라이즈 팀은 조직 관리자가 다음 업무를 수행할 수 있도록 도구를 개발한다. - 조직 계정 관리 - 디자이너·개발자·협업자의 접근 권한 관리 - 조직 내 사용 현황과 리소스 관리 - 제품 개발 과정에서 잠재 고객과의 영업 통화, 기존 고객 인터뷰, 지원팀 피드백 등을 적극적으로 활용한다. - 고객 요구를 단순히 받아 적는 것이 아니라, 여러 고객과 조직에 공통적으로 적용될 수 있는 문제를 파악하는 데 초점을 둔다. ## 기존 Admin Settings가 가진 한계 - Figma Organization 출시 후 사용자가 크게 늘면서 관리자 업무의 범위가 넓어졌다. - 초기 Admin Settings는 어떤 기능이 관리자에게 가장 중요한지 충분히 알기 전에 설계된 화면이었다. - 고객·지원·영업팀과의 대화를 통해 다음 문제가 드러났다. - 관리자가 조직의 의사결정에 필요한 정보를 충분히 얻기 어려움 - 자신에게 유용한 기능이 무엇인지 알기 어려움 - 필요한 정보를 수동으로 내보내야 함 - 개별 기능 자체보다, 기능을 발견하고 활용하는 전체 관리 화면의 구조가 문제였다. ## 처음부터 다시 설계한 브레인스토밍 - 팀은 기존 화면을 조금 수정하는 대신 관리자 경험을 처음부터 재구성하기로 했다. - 주요 목표는 다음과 같았다. - 구성원 관리 워크플로 개선 - 기존 기능의 노출과 활용도 향상 - 향후 새 기능을 쉽게 추가할 수 있는 구조 마련 - 아이디어를 다음 세 범주로 나누어 논의했다. - 지금 실행할 항목 - 검토할 가치가 있는 항목 - 과감하고 실험적인 항목 - PM, 엔지니어링 매니저, 디자이너, 엔지니어뿐 아니라 리서치·데이터·지원·마케팅·영업팀도 참여했다. - 각 팀의 제안을 사용자 피드백과 연결해 공통 주제를 도출하고, 우선순위가 높은 항목을 정리했다. ## 단순한 UI 개선이 아닌 제품 개편 - 처음에는 기존 Admin Settings에 새로운 화면과 옵션을 추가하는 정도로 생각했다. - 그러나 영업팀과 함께 관리자들의 실제 불편을 분석하면서 문제가 특정 화면이나 기능에 국한되지 않았음을 확인했다. - 기존 설계 위에 기능을 계속 덧붙이면 단기적으로는 개선할 수 있어도, 다음 문제가 반복될 수 있었다. - 핵심 업무 흐름이 복잡해짐 - 기능 간 연결성이 약해짐 - 새로운 기능을 추가하기 어려워짐 - 따라서 문제의 증상만 고치는 대신, 관리자의 주요 워크플로를 중심으로 전체 제품 경험을 재설계하는 방향을 택했다. ## 다양한 규모의 조직을 위한 확장성 - Figma는 특정 규모 이상의 기업만 대상으로 하는 제품이 아니라, 5명 규모의 팀부터 5,000명 규모의 조직까지 지원해야 한다. - 작은 조직에서는 한 사람이 관리자, 디자인 운영 담당자, 실무 디자이너 역할을 동시에 맡을 수 있다. - 대기업에서는 예산 책임자, 디자인 운영팀, 보안팀, 개별 사용자가 서로 다른 목표와 요구를 가진다. - 경영진·예산 담당자: 조직 전체에서 제품이 제공하는 가치를 파악 - 디자인 운영 담당자: 필요한 권한과 리소스 접근을 보장 - 보안팀: 조직 데이터가 안전하게 보호되는지 확인 - 일반 사용자: 일상적인 업무를 효율적으로 수행 - 따라서 엔터프라이즈 도구는 특정 사용자 유형에만 맞추기보다, 조직 내 다양한 역할과 의사결정 구조를 수용할 수 있어야 한다. - 관리자 화면은 일반 사용자에게는 부수적인 기능처럼 보일 수 있지만, 관리자에게는 매일의 운영을 책임지는 핵심 업무 공간이다. ## 실용적인 결론 엔터프라이즈 제품을 설계할 때는 고객의 최신 요청을 개별적으로 처리하기보다, 여러 조직에서 반복되는 문제와 업무 흐름을 찾아야 한다. 특히 조직 규모와 사용자 역할이 다양하다면 단기적인 UI 수정보다 확장 가능한 정보 구조와 관리 워크플로를 먼저 설계하는 것이 장기적으로 더 효과적이다.

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

Figma사용자 경험프로덕트 디자인enterprise-software+2

figma·2020년 8월 18일·3분 읽기큐레이션 요약

60fps의 React: Figma

Figma는 캔버스에서 댓글 핀이 이동할 때 발생하던 불필요한 React 렌더링을 줄여 스크롤 성능을 약 3배 개선했다. 댓글 수와 무관하게 편집기를 60fps에 가깝게 동작시키는 것이 목표였으며, Chrome Performance 도구와 React Profiler로 병목이 JavaScript 실행과 컴포넌트 재렌더링에 있음을 확인했다. 핵심 해결책은 뷰포트 변화에 실제로 영향을 받는 댓글 컴포넌트만 업데이트하고, 댓글 위치 계산과 변환 처리를 최적화하는 것이었다. ## 60fps를 목표로 한 댓글 스크롤 - Figma의 댓글은 캔버스 위 특정 위치에 고정된 “댓글 핀”으로 표시된다. - 사용자가 캔버스를 이동하거나 확대·축소하면 댓글 핀도 뷰포트에 맞춰 계속 위치를 다시 계산해야 한다. - 15fps나 30fps보다 60fps가 훨씬 부드러운 사용자 경험을 제공하므로, 댓글과 스레드가 많아져도 일정한 성능을 유지하는 것이 목표였다. - 댓글 사용량이 증가하면서 대규모 팀과 파일에서 캔버스 반응성이 저하되기 시작했다. ## WebGL 캔버스와 React 댓글 UI의 구조 - Figma 편집기는 WebGL과 WebAssembly를 사용하는 “브라우저 안의 브라우저”에 가까운 구조다. - 일부 사용자 인터페이스는 TypeScript와 React로 구현되어 있지만, 일반적인 정적 React 화면과 달리 댓글은 캔버스의 이동과 확대·축소에 따라 동적으로 움직인다. - 편집기의 뷰포트 정보는 Redux에 저장된다. - 댓글 핀 컴포넌트는 Redux에서 뷰포트 정보를 가져와 캔버스 좌표를 화면에 표시할 위치로 변환한다. - 뷰포트가 변경될 때마다 React 컴포넌트 트리 일부가 업데이트되므로, 업데이트 범위가 성능에 직접적인 영향을 준다. ## 성능 분석에서 발견한 병목 - Chrome Performance 도구에서 대부분의 프레임 시간이 렌더링이나 페인팅이 아니라 JavaScript 실행에 사용되는 것으로 나타났다. - 댓글 30개인 화면에서 프레임당 약 68ms가 JavaScript에 소비되었고, 실제 화면은 약 19fps로 렌더링됐다. - React Profiler에서는 댓글 화면 자체의 렌더링에는 약 1.8ms만 사용되고 있었다. - 대신 뷰포트 변화와 직접 관련 없는 다음 컴포넌트들이 함께 재렌더링됐다. - 왼쪽 패널 - 툴바 - 속성 패널 - 기타 고정 위치 UI - 즉, 댓글 내용 렌더링보다 “변화가 없는 컴포넌트까지 다시 렌더링하는 것”이 더 큰 비효율이었다. ## 불필요한 재렌더링 줄이기 - 뷰포트 업데이트는 댓글 핀의 위치에는 필요하지만, 화면에 고정된 패널이나 툴바에는 필요하지 않다. - 따라서 뷰포트 상태를 사용하는 컴포넌트의 범위를 댓글 영역으로 제한해야 한다. - React 애플리케이션이 커질수록 상위 컴포넌트의 상태 변화가 하위 전체로 전파되면서 불필요한 렌더링이 발생하기 쉽다. - React Profiler로 실제로 다시 렌더링되는 컴포넌트를 확인하면, 직관만으로 찾기 어려운 병목을 구체적으로 식별할 수 있다. - 성능 개선은 댓글 컴포넌트 자체를 빠르게 만드는 것뿐 아니라, 댓글과 무관한 컴포넌트가 업데이트되지 않도록 컴포넌트 구조와 상태 구독 방식을 조정하는 데서 시작됐다. ## 댓글 핀 위치 변환 최적화 - 댓글 핀은 뷰포트가 바뀔 때마다 캔버스 좌표를 화면 좌표로 변환해야 한다. - 이 변환 과정이 매 업데이트마다 React 렌더링과 결합되면 JavaScript 실행 비용이 커질 수 있다. - Figma는 불필요한 컴포넌트 업데이트를 제거한 뒤 댓글 핀의 변환 처리도 최적화해, 캔버스 이동 중 위치 계산과 화면 반영 비용을 줄였다. - 결과적으로 댓글 스크롤 FPS가 기존보다 약 3배 향상됐다. ## 실용적인 결론 - React 성능 문제에서는 먼저 “컴포넌트 하나의 렌더링 속도”보다 “불필요하게 다시 렌더링되는 컴포넌트가 무엇인지”를 확인하는 것이 효과적이다. - Chrome Performance 도구로 프레임별 JavaScript 비용을 확인하고, React Profiler로 재렌더링 범위를 분석하는 조합이 유용하다. - 자주 변하는 상태는 실제로 그 상태가 필요한 컴포넌트 가까이에 두고, 고정 UI가 동적 상태 변화에 구독되지 않도록 설계하는 것이 좋다.

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

ReactTypeScriptwebassemblywebgl+2

figma·2020년 8월 12일·4분 읽기큐레이션 요약

쇼피파이에서 협업을

Shopify는 Figma 파일을 팀 간 협업의 공용 작업 공간으로 활용하기 위해, 프로젝트 상태와 산출물을 일정한 구조로 정리하는 템플릿을 사용한다. 이 템플릿은 GSD(Get Sh*t Done)의 **Think–Explore–Build** 프로세스를 기반으로 하며, 실제로 구현할 결과물을 가장 앞에 배치해 필요한 정보를 빠르게 찾도록 설계됐다. 핵심은 파일마다 예측 가능한 구조와 상태 표시를 적용해 디자인·제품·엔지니어링 팀의 커뮤니케이션 비용을 줄이는 것이다. ## 일관된 파일 구조가 필요한 이유 - Figma는 협업을 쉽게 만들지만, 시간이 지나면서 파일과 산출물이 많아지면 다음과 같은 문제가 생긴다. - 어떤 디자인이 최신인지 파악하기 어렵다. - 특정 레이아웃이 승인됐는지 알기 어렵다. - 실제 구현 대상과 사용자 테스트용 프로토타입을 구분하기 어렵다. - 제품 관리자, 엔지니어, 다른 디자이너가 필요한 정보를 찾기 어렵다. - Shopify는 팀마다 다른 파일 정리 방식을 사용하는 문제를 해결하기 위해 공통 템플릿을 만들었다. - 일정한 형식은 여러 팀이 파일을 탐색할 때 기대할 수 있는 공통 규칙을 제공하고, 프로젝트 초기 설정 시간도 줄여준다. ## GSD 프로세스와 템플릿의 페이지 순서 - Shopify의 GSD 프레임워크는 세 단계로 구성된다. - **Think**: 문제와 배경을 이해한다. - **Explore**: 다양한 해결책을 탐색한다. - **Build**: 선택한 해결책을 구체화하고 출시한다. - 템플릿의 페이지는 이 순서와 반대로 구성된다. - 가장 중요한 구현 준비 상태의 결과물을 파일 앞부분에 둔다. - 사용자가 파일을 열었을 때 최근 작업과 실행 가능한 결과를 먼저 확인할 수 있다. - 새 파일을 만들 때는 표지와 프로젝트 개요를 먼저 작성한 뒤, Think 섹션의 정보를 채우는 방식으로 시작한다. - Explore 단계에서는 필요한 만큼 페이지를 만들고 자유롭게 실험한다. - Build 단계에 들어가면 Explore에서 선택된 페이지나 레이아웃을 Build 섹션으로 이동한다. ## 표지: 프로젝트의 현재 상태를 한눈에 표시 - 새 Figma 파일을 만들 때 표지를 먼저 구성한다. - 표지에는 다음과 같은 정보를 담는다. - 프로젝트명 - 담당 팀 - 프로젝트 상태 - Figma 프로젝트의 그리드 보기에서도 파일을 쉽게 식별할 수 있다. - 프로젝트가 진행될 때마다 상태 표시를 갱신해야 현재 단계가 혼동되지 않는다. ## 프로젝트 개요: 배경과 담당자 연결 - 개요 페이지에는 프로젝트를 이해하는 데 필요한 추가 정보를 제공한다. - 포함할 수 있는 내용은 다음과 같다. - 관련 문서와 리서치 링크 - 프로젝트 브리프 - 피드백을 줄 담당자 - 질문이나 문의를 전달할 연락처 - 필요에 따라 섹션과 항목을 추가하거나 삭제할 수 있다. - Figma 문서에 문서 링크나 Slack 프로필 링크를 붙여 넣으면 관련 앱을 바로 열 수 있어 탐색 과정이 단순해진다. ## Think: 문제 공간과 프로젝트 기반 정리 - Think 섹션은 탐색을 시작하기 전에 문제와 맥락을 정리하는 공간이다. - 다음과 같은 자료를 모을 수 있다. - 사용자 플로우 - 고객 여정 지도 - 잡 스토리(job story) - 디자인 스프린트 결과물 - 과거 디자인이나 영감을 위한 스크린샷 - 관련 외부 문서 링크 - 이 단계의 목적은 해결책을 바로 결정하는 것이 아니라, 탐색에 필요한 정보를 한곳에 모아 프로젝트의 기반을 만드는 것이다. ## Explore: 다양한 아이디어를 실험하고 피드백 수집 - Explore는 여러 해결책을 넓고 깊게 시도하는 작업 공간이다. - 협업과 댓글, 피드백이 가장 활발하게 발생하는 영역으로 활용한다. - 효과적인 정리를 위해 다음 규칙을 적용할 수 있다. - 태블릿·모바일처럼 기기나 화면 형태가 다르면 별도 페이지로 나눈다. - 탐색 결과와 사용자 플로우에 제목을 붙여 내용을 명확히 한다. - 진행 상태를 나타내는 배지를 추가한다. - 새 페이지마다 날짜를 기록해 최신 작업인지 확인할 수 있게 한다. - 사용자 테스트용 프로토타입은 별도 페이지로 관리한다. - 스티키 노트로 메모, 아이디어, 피드백, 후속 작업을 기록한다. - 이 단계에서는 가능한 접근법을 많이 시도한 뒤, 피드백을 바탕으로 구현할 방향을 좁혀 간다. ## Build: 선택된 결과물을 구현 단계로 이동 - Build는 탐색을 마친 뒤 적절한 해결책을 구체화하고 출시 및 피드백으로 연결하는 단계다. - Explore에서 검토한 여러 시안 중 실제로 진행할 페이지나 레이아웃만 Build 섹션으로 이동한다. - 이를 통해 실험 중인 아이디어와 구현 대상으로 확정된 결과물을 명확히 분리할 수 있다. - 파일 앞부분에 Build 관련 결과물이 배치되므로 다른 직군도 현재 구현 대상과 프로젝트 진행 상황을 빠르게 파악할 수 있다. 팀 단위로 Figma를 운영한다면 표지, 개요, Think–Explore–Build 섹션을 기본 템플릿으로 정하고, 날짜·상태 배지·담당자·관련 링크를 의무적으로 기록하는 방식이 실용적이다. 특히 Explore의 자유로운 실험 공간과 Build의 확정 산출물을 분리하면 최신 디자인과 구현 대상을 찾는 데 드는 커뮤니케이션 비용을 크게 줄일 수 있다.

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

Figma디자인 시스템프로토타이핑design-collaboration+2