techlist.io
KREN

디자인 시스템

252 개의 포스트

figma3분 읽기큐레이션 요약

Variants로 디자인과 코드의

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figma사용자 경험auto-layout+2
figma3분 읽기큐레이션 요약

킴벌리클라크가 사랑

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figma사용자 경험프로토타이핑+3
figma3분 읽기큐레이션 요약

팀으로 배우고 실패하기 |

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figma접근성remote-collaboration+3
figma3분 읽기큐레이션 요약

Figma의 에이전시 파

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figmadesign-toolsdesign-to-development+1
figma3분 읽기큐레이션 요약

연결의 순간 만들기 | Figma

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

원문 읽기(새 탭에서 열림)
디자인 시스템Figma사용자 경험remote-collaboration+1
figma3분 읽기큐레이션 요약

피그마 내부 이야기: 신입

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

원문 읽기(새 탭에서 열림)
디자인 시스템웹 개발product-developmentc+++1
figma4분 읽기큐레이션 요약

코드와 디자인 사이의 긴

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
figma3분 읽기큐레이션 요약

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

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
figma3분 읽기큐레이션 요약

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

멀티 브랜드 디자인 시스템은 일관성과 효율성을 제공하되, 엄격한 규칙보다 유연성을 중심으로 설계해야 한다. 기본 컴포넌트와 브랜드별 토큰, 코드 연계를 통해 다양한 요구를 수용하고 빠르게 확장할 수 있다. 또한 디자인 시스템은 완성된 산출물이 아니라 실제 사용 데이터를 관찰하며 계속 발전시키는 살아 있는 시스템이어야 한다. ## 유연성을 우선하는 설계 - 디자인 시스템을 지나치게 규정적으로 운영하면 디자이너의 창의성을 제한하고, 결국 시스템 밖에서 작업하게 만들 수 있다. - 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
figma4분 읽기큐레이션 요약

쇼피파이에서 협업을

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
figma3분 읽기큐레이션 요약

Figma 커뮤니티

Figma Community는 사용자들이 디자인 시스템, 아이콘, 와이어프레임, 일러스트, 프로토타입 등을 공개하고 서로 탐색·재사용·리믹스할 수 있는 공간이다. 2020년 8월부터 전체 Figma 사용자에게 단계적으로 공개되었으며, 검색과 태그 탐색, 프로필 핸들, 좋아요, 파일 복제 기능을 제공한다. 글은 베타 기간 동안 커뮤니티가 만든 다양한 리소스와 그 제작 배경을 소개하며, Figma Community가 협업과 지식 공유의 기반으로 성장할 가능성을 강조한다. ## Figma Community의 공개와 기능 - 수천 명의 제작자가 베타에 참여해 파일과 프로필을 공개했다. - 사용자는 다음과 같은 자료를 검색하고 탐색할 수 있다. - 디자인 시스템 - 아이콘 팩 - 와이어프레임 - 일러스트레이션 - 애니메이션 프로토타입 - 보드게임 등 실험적인 작업물 - 주요 기능은 검색, 태그 탐색, 프로필 핸들 선점, 좋아요, 파일 복제다. - 초기 공개 단계에서는 모든 사용자가 파일과 프로필을 볼 수 있지만, 파일을 직접 게시하려면 여전히 베타 참여가 필요했다. - Microsoft, Google Material Design, Mixpanel 같은 조직과 개인 디자이너들이 실용적인 리소스를 공개했다. ## Material Design Baseline Kit: 디자인 시스템의 출발점 - Google Material Design 팀의 Jessie Z가 제작한 리소스다. - 디자인 시스템을 처음부터 구축하는 부담을 줄이고, 다양한 프로젝트에서 활용할 수 있도록 설계됐다. - 두 부분으로 구성된다. - **Material Theme**: 타이포그래피와 색상 팔레트를 수정하고, 변경 사항이 컴포넌트·상태·예시 레이아웃에 미치는 영향을 빠르게 확인한다. - **Sticker sheet**: 기존 컴포넌트를 조합하고 활용하는 전통적인 UI 리소스 모음이다. - 사용자는 이 키트를 기반으로 Material 가이드라인을 학습하거나, 제품과 브랜드에 맞는 테마를 시각화할 수 있다. ## Open Figures: 재사용 가능한 일러스트 라이브러리 - Bonnie Kate Wolf가 제작한 일러스트레이션 라이브러리다. - 특정 회사의 브랜드 가이드에 얽매이지 않고 독립적인 스타일을 만들 수 있었던 프로젝트다. - 제품 화면, 프레젠테이션, 개인적인 창작 활동 등 다양한 목적에 사용할 수 있도록 구성됐다. - 모듈형 일러스트를 설계하면서 접근성과 포용성을 고려했다. - 휠체어를 사용하는 캐릭터의 의상 교체가 가능하도록, 드레스나 긴 재킷처럼 다른 요소와 충돌하는 형태를 조정했다. - 단순히 보기 좋은 그림을 제공하는 것을 넘어, 다양한 사용자를 표현할 수 있는 디자인 구조를 보여준다. ## Spotify Ways of Working: 팀 협업 방식의 공유 - Spotify의 Barton Smith, Cliona O’Sullivan과 Figma 워킹 그룹이 제작했다. - Figma에서 팀의 업무를 조직하고 협업하는 방식을 외부 커뮤니티에 공개한 자료다. - Spotify는 회사마다 Figma 파일과 프로젝트를 정리하는 표준 방식이 없고, 이를 어려워하는 팀이 많다는 점에서 출발했다. - 이 파일은 특정 도구 사용법보다 실제 조직이 업무를 구조화한 사례를 보여주는 데 목적이 있다. - Spotify 팀 역시 운영 과정에서 얻은 학습을 바탕으로 기존 결정을 계속 수정하고 있다고 설명한다. ## 커뮤니티가 만드는 공유 생태계 - Figma Community는 완성된 결과물뿐 아니라 제작자의 문제의식과 작업 방식을 공유하는 장으로 기능한다. - 대기업의 디자인 시스템부터 개인 창작자의 일러스트, 팀 운영 문서까지 자료의 범위가 넓다. - 공개된 파일을 복제해 자신의 프로젝트에 맞게 수정할 수 있어 학습과 실무 적용이 동시에 가능하다. - Figma는 초기 출시를 완성된 제품이 아니라 앞으로 확장될 기반으로 설명하며, 사용자들이 무엇을 만들고 어떻게 활용하는지에 따라 발전시킬 계획을 밝혔다. 실무에서는 Material Design Baseline Kit처럼 구조화된 시스템을 출발점으로 삼고, Open Figures처럼 재사용 가능한 시각 자산을 활용하며, Spotify 사례처럼 팀의 파일 관리 규칙을 문서화하는 방식으로 Figma Community를 활용할 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma프로토타이핑접근성+2
figma3분 읽기큐레이션 요약

피그마 내부: 원격 인

원격 인턴십은 관계 형성과 업무 맥락 습득에 어려움이 있을 수 있지만, 의도적으로 소통 기회를 만들고 적극적으로 질문하면 충분히 의미 있는 경험이 될 수 있다. Jenning Chen은 Figma에서 스타일 피커 개선 프로젝트를 맡아 검색, 색상 스타일 목록 보기, 텍스트 스타일 지표 표시를 구현했으며, 인턴도 실제 사용자 기능의 기획부터 출시까지 주도할 수 있음을 보여준다. 이 과정에서 협업과 피드백, 대규모 데이터 마이그레이션을 경험하며 제품 이해도와 기술 역량을 함께 넓혔다. ## 원격 환경에서의 따뜻한 온보딩 - 입사 직후 Slack 환영 메시지와 온라인 커피챗을 통해 팀원들과 관계를 형성했다. - 동료들이 만든 Figma 환영 카드와 낙서가 담긴 파일을 받으며 대면 없이도 회사의 개방적 문화를 느꼈다. - 원격 근무에서도 신입 구성원이 소속감을 느끼도록 의도적인 환영 절차가 중요했다. ## 원격 인턴십의 우려와 관계 형성 - Slack이나 이메일에서 메시지를 놓치거나 오해할 가능성, 팀원들과 깊은 관계를 만들기 어려울 가능성을 걱정했다. - 회사 전체 쇼앤텔, 기술 강연, 일대일 미팅 등을 통해 다른 팀의 업무와 구성원들의 관심사를 접했다. - 온라인 요리 수업, 방 탈출, 보물찾기 같은 활동은 업무 외적인 관계 형성에도 도움이 됐다. - 원격 환경에서는 우연한 대화가 줄어드는 대신, 조직이 교류 기회를 의도적으로 설계해야 했다. ## 제품 이해도와 질문하는 문화 - 프로젝트를 시작하기 전 Figma의 기능과 디자인 용어를 충분히 익혀야 했다. - 멘토, 팀원, Slack 채널에 적극적으로 질문하며 제품과 업무 맥락을 파악했다. - 문제가 생겼을 때 동료들이 기꺼이 화상 통화를 열어 함께 해결해 주었고, 이는 원격 환경에서도 빠르게 배울 수 있는 기반이 됐다. ## 스타일 피커의 기존 문제 - 스타일 피커는 페인트, 텍스트, 효과, 레이아웃 그리드 스타일을 찾아 적용하는 기능이다. - 스타일 수가 늘어나면서 기존 인터페이스가 복잡해졌다. - 긴 목록을 수동으로 스크롤해야 했고, 특히 색상 스타일의 이름처럼 중요한 정보가 잘 드러나지 않았다. - 사용자가 원하는 스타일을 빠르게 찾고 비교할 수 있도록 개선 요구가 컸다. ## 스타일 피커 개선 기능 - **검색 기능** - 사용자가 몇 글자만 입력해 원하는 스타일을 빠르게 찾을 수 있게 했다. - **색상 스타일 목록 보기** - 기존 격자 보기에서는 가려지던 스타일 이름을 썸네일 옆에 명확히 표시했다. - 목록 보기와 격자 보기를 전환할 수 있도록 했다. - **텍스트 스타일 지표 표시** - 텍스트 스타일을 선택할 때 중요한 글꼴 크기와 줄 높이를 직접 보여줬다. - 스타일을 적용하기 전에 핵심 속성을 확인할 수 있어 선택 시간을 줄였다. ## 여러 기술 스택을 활용한 구현 - 디자인 시스템 팀의 프로젝트 특성상 에디터부터 백엔드까지 전체 기술 스택을 다뤘다. - 에디터에서는 TypeScript와 C++를, 백엔드에서는 Ruby를 사용했다. - 단일 기능을 구현하면서 프론트엔드, 에디터 내부 로직, 백엔드 데이터 처리까지 폭넓은 경험을 쌓았다. ## 출시 과정의 협업과 기술적 난관 - 완성된 기능을 사내 쇼앤텔에서 발표하고 동료들의 피드백을 받았다. - 출시 전 수백만 개의 기존 텍스트 스타일에 글꼴 크기와 줄 높이 메타데이터를 추가하는 마이그레이션이 필요했다. - 해당 마이그레이션만 실행하는 데 하루가 걸렸으며, 리뷰 피드백 반영과 출시 직전 버그 수정도 진행했다. - 구현 과정의 어려움은 제품 구조와 데이터 흐름을 더 깊이 이해하는 계기가 됐다. ## 실용적인 시사점 원격 인턴십이나 신규 프로젝트에서는 정기적인 일대일 미팅, 공개적인 질문 채널, 업무 외 교류 기회를 미리 마련하는 것이 효과적이다. 또한 작은 기능이라도 사용자 문제를 명확히 정의하고, 기존 데이터와 마이그레이션 비용까지 고려하면 실제 출시 가능한 제품으로 발전시킬 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템FigmaTypeScriptc+++2
figma3분 읽기큐레이션 요약

Config Europe 발표: 발표자

Figma는 커뮤니티의 경험과 아이디어를 중심으로 한 가상 컨퍼런스 **Config Europe**를 2020년 9월 17일 개최한다고 발표했다. 온라인 전환을 통해 지역과 규모의 한계를 넘어 누구나 참여할 수 있도록 했으며, 발표자 제안과 무료 참가 신청을 모두 열었다. 특히 처음 발표하는 사람도 환영하고 지원하겠다는 점을 강조했다. ## Config Europe 개최 배경 - Figma는 앞서 샌프란시스코에서 첫 사용자 컨퍼런스 Config를 개최했다. - 약 1,200명이 현장에 참석했고 온라인으로도 많은 사용자가 참여했다. - 하지만 행사 장소와 규모 때문에 참석하고 싶어도 참여하지 못하는 사람들이 있었다. - 세계 여러 도시에서 행사를 열 계획이었지만, 코로나19로 인해 오프라인 계획을 잠정 중단했다. - 온라인 행사를 통해서도 Config의 핵심 목표인 커뮤니티의 목소리 확대, 지식 공유, 연결을 실현하고자 했다. ## 발표자 모집과 참여 방식 - 발표 제안 마감일은 **2020년 7월 31일**이었다. - 발표 형식은 다음과 같이 다양했다. - 일반 발표 - 패널 토론 - 라이트닝 토크 - 워크숍 - 발표 경험이 없는 사람도 지원할 수 있으며, 첫 발표자를 적극적으로 환영했다. - 발표자로 선정되면 다음과 같은 지원을 제공했다. - IT 지원 및 장비 - Figma 제품 전문가의 도움 - 발표 아이디어를 구체화하는 편집 지원 - 선정되지 않은 제안도 라이브스트림이나 블로그 글 등 다른 콘텐츠 기회에 적합하면 별도로 안내할 예정이었다. ## 주요 콘텐츠 트랙 ### 디자인 시스템 구축과 유지 - 디자인 시스템을 처음 시작하는 방법 - 규모가 커지는 조직에서 디자인 시스템을 확장하는 방법 - 컴포넌트 구축과 관리 - 스타일 가이드 개선 - 팀 구성원의 참여와 도입을 이끌어내는 방법 ### Figma 심층 활용 - Figma에서 디자인 작업 속도를 높이는 방법 - 플러그인 활용 - Auto Layout 사용법 - 컴포넌트 기반 작업 - 효율적인 디자인 워크플로 구축 ### 프로세스, 문화, 팀 빌딩 - 디자이너와 팀원 채용 및 채용 기준 - 팀 문화를 만드는 방법 - 조직 내 프로세스와 협업 규칙 수립 - 원격 근무 환경에서의 팀 운영과 커뮤니케이션 ### 디자인의 개방과 포용성 - 디자인 프로세스를 더 포괄적으로 만드는 방법 - 접근성을 고려한 디자인 - 디자이너가 아닌 사람도 디자인 과정에 참여시키는 방법 - 다양한 구성원의 의견을 반영하는 협업 방식 ## 참가자 모집과 행사 운영 - Config Europe는 전 세계 누구나 무료로 참가할 수 있도록 계획됐다. - 2020년 8월 20일에 행사 일정 공개와 참가 등록을 시작할 예정이었다. - 발표자 외에도 다음과 같은 커뮤니티 프로그램이 마련될 예정이었다. - 멘토링 - 네트워킹 세션 - 소셜 이벤트 - 발표 제안 결과는 2020년 8월 11일까지 안내할 계획이었다. 이번 발표는 온라인 행사를 단순히 오프라인 행사의 대체재로 보는 대신, 더 많은 사용자가 참여하고 자신의 경험을 공유할 수 있는 커뮤니티 플랫폼으로 활용하려는 시도였다. 기술 행사나 커뮤니티를 기획할 때도 규모나 장소보다 참여 장벽을 낮추고, 초보자와 다양한 배경의 참가자가 기여할 수 있도록 지원하는 것이 중요하다는 점을 보여준다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma오픈 소스auto-layout+1
figma3분 읽기큐레이션 요약

BT가 통신 산업을 계속

174년 역사의 통신 기업 BT는 빠르게 변화하는 기술과 높아진 사용자 기대에 대응하기 위해 제품 개발 방식을 전환했다. 제품·엔지니어링·디자인 인력을 소규모 제품 스쿼드로 재편하고 Figma를 도입하면서 협업과 의사결정의 속도, 투명성을 높였다. 그 결과 도구 비용을 50% 절감하고, 원격근무 상황에서도 혁신을 지속할 수 있었다. ## 제품 스쿼드 모델로의 전환 - BT는 제품, 엔지니어링, 디자인 조직을 제품 스쿼드 중심으로 재구성했다. - 각 스쿼드는 특정 제품의 기획부터 출시까지 전 과정을 책임지는 소규모·유연한 팀으로 운영됐다. - 디자이너는 더 이상 디자이너끼리만 일하지 않고, 제품 담당자, 엔지니어, 콘텐츠 디자이너와 함께 협업했다. - 그러나 기존에는 문서, Sketch, InVision, Jira 등 여러 도구를 병행해야 했다. - 파일 이동과 여러 피드백 채널 관리에 시간이 소요되어 실제 디자인 작업과 팀 간 소통이 비효율적이었다. ## Figma 도입과 협업 방식 개선 - 180명 이상의 디자이너가 있는 만큼, BT는 먼저 한 제품 스쿼드에서 2개월간 Figma를 시험 운영했다. - 몇 주 만에 실시간 협업, 디자인 핸드오프, 파일 관리가 쉬워졌다는 긍정적인 피드백을 얻었다. - 디자인, 프로토타이핑, 발표를 하나의 도구에서 처리하면서 Sketch와 InVision 사이에서 파일을 옮길 필요가 줄었다. - 제품 담당자와 엔지니어도 진행 중인 디자인을 직접 확인하고 초기 단계부터 의견을 제시할 수 있게 됐다. - Figma 파일 링크만 공유하면 임원과 외부 이해관계자도 기기와 장소에 관계없이 디자인을 보고 댓글을 남길 수 있었다. - 파일럿 이후 BT는 모든 제품 스쿼드에 Figma를 확대 적용했다. ## 협업을 넘어선 효과 - **비용 50% 절감:** Sketch와 InVision을 Figma로 대체하고 디자인 도구를 통합했다. - **디자인의 의사결정 참여 확대:** 이해관계자가 디자인 과정에 더 잘 접근하게 되면서 디자인이 사업 의사결정과 투자 논의의 핵심 요소가 됐다. - **디자인 일관성 강화:** 브랜드, 제품, 여러 사업부를 아우르는 중앙화된 디자인 시스템 구축의 기반을 마련했다. - **업무 연속성 확보:** 코로나19로 재택근무가 시행된 뒤에도 구성원들이 Figma에서 함께 아이디어를 공유하고 문제를 해결할 수 있었다. - **발표 방식 변화:** 완성된 프레젠테이션을 만드는 대신 CEO와 라이브 디자인 파일을 함께 보며 ‘경험 walkthrough’를 진행했다. - **투명성과 효율 향상:** 팀 전체가 동일한 작업물을 실시간으로 확인해 공동의 이해를 빠르게 형성하고, 제품과 기능을 더 자신 있게 출시할 수 있었다. ## 실용적인 시사점 협업 도구 도입만으로 변화가 완성되는 것은 아니며, 먼저 조직을 제품 중심의 소규모 팀으로 재편하고 팀 간 공동 책임 구조를 만들어야 한다. 이후 파일럿 운영으로 효과를 검증한 뒤 도구를 확산하면 구성원의 수용성을 높이면서 비용 절감, 의사결정 가속화, 원격 협업 강화까지 함께 달성할 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma프로토타이핑design-collaboration+3
figma4분 읽기큐레이션 요약

Clearstep이 온라인에서 진료를

Clearstep은 증상 확인부터 적절한 의료기관 선택, 보험 자격 확인, 비용 추정, 예약까지 이어지는 의료 탐색 과정을 직관적으로 단순화했다. 이를 위해 반복적인 사용자 흐름 테스트와 Figma의 협업·스타일 관리·개발 전달 기능을 활용해 정확하고 일관된 제품 경험을 만들었다. 최종 목표는 환자가 불안과 검색 시간을 줄이고 자신에게 맞는 진료를 빠르게 찾도록 돕는 것이다. ## 의료 탐색 과정을 하나의 흐름으로 통합 - 2018년 증상 확인 및 진료 경로 안내 플랫폼을 출시했다. - 사용자가 증상에 따라 진료가 필요한지, 어떤 의료 제공자를 찾아야 하는지 판단하도록 지원했다. - 사용자의 위치와 보험 네트워크를 고려해 적합한 의료 자원을 연결했다. - 보험 계획에 따른 예상 비용을 제공하고, 플랫폼 안에서 진료 예약까지 진행할 수 있도록 확장했다. - 증상 확인, 의료기관 비교, 보험 확인, 비용 투명성, 예약을 하나의 경험 안에 통합해야 했기 때문에 설계 과정에서 높은 정확성과 반복 검증이 필요했다. ## 정보는 많지만 오류가 허용되지 않는 설계 - 의료 선택지가 많은 상황에서 사용자가 다음 행동을 명확히 이해하도록 사용자 흐름을 여러 차례 개선했다. - Figma의 **Smart Selection**을 활용해 증상 확인 결과 화면의 진료 옵션 순서를 드래그 앤 드롭으로 빠르게 재배치했다. - 헤더와 본문 글꼴의 미세한 차이도 사용자의 탐색 방식과 진료 옵션 평가에 영향을 주므로 반복적인 테스트를 진행했다. - 버튼 텍스트가 자동으로 크기에 맞춰 조정되어 다양한 문구를 빠르게 실험할 수 있었다. - 이러한 기능을 통해 단순 반복 작업을 줄이고, 사용성처럼 더 높은 판단이 필요한 설계 문제에 시간을 쓸 수 있었다. ## 고객별 브랜드를 빠르게 적용 - Clearstep은 여러 의료 시스템에 화이트 라벨 형태로 플랫폼을 제공한다. - 고객마다 다른 색상 체계를 사용하기 때문에 짧은 시간 안에 맞춤형 디자인을 제작해야 했다. - 고객 브리프마다 새로운 Figma 파일을 만들고 브랜드 색상을 문서에 추가했다. - **Color Styles**를 사용하면 광고나 목업의 여러 색상을 한 번에 수정할 수 있다. - 검증된 색상 스타일은 Figma **Library**에 등록해 모든 편집자가 동일한 스타일을 사용할 수 있도록 했다. - 이를 통해 고객별 맞춤화와 디자인 일관성을 동시에 유지했다. ## 원격 환경에서의 실시간 협업 - Figma의 멀티플레이어 기능으로 디자이너와 엔지니어가 같은 파일에서 동시에 작업했다. - 엔지니어가 디자인 핸드오프를 진행하는 동안 디자이너가 UX 개선점을 표시하거나 직접 수정할 수 있었다. - 텍스트와 색상 스타일을 수정·게시하면 팀원이 파일에 다시 들어왔을 때 최신 상태를 확인할 수 있었다. - 색상과 이름이 표시되는 커서를 통해 화상회의나 화면 공유 없이도 각자의 작업 위치와 피드백을 파악했다. - 다른 팀원의 아바타를 클릭해 관찰 모드로 전환하면 해당 팀원이 기능을 검토하는 과정을 실시간으로 따라갈 수 있었다. - 댓글을 하나씩 검토하고 답변하거나, 반영 후 댓글을 해결 처리하는 방식으로 피드백을 관리했다. ## 디자인에서 구현까지 연결 - 최종 디자인은 Figma의 **Color Styles**, **Code 패널**, UI 요소 간 간격과 오프셋을 보여주는 레이블을 통해 개발팀에 전달됐다. - 개발자는 별도로 에셋을 다운로드하거나 복잡한 설명을 주고받지 않고 필요한 리소스에 바로 접근할 수 있었다. - Figma의 내보내기 기능을 사용해 구현 과정에서 디자인 에셋을 즉시 활용할 수 있었다. - 디자인과 개발 사이의 전달 비용을 줄이고, 최종 구현이 설계 의도와 일치하도록 했다. ## 의료 서비스 접근성을 높이는 제품 철학 - Clearstep은 의료 정보를 단순히 제공하는 데 그치지 않고 사용자가 실제로 다음 행동을 선택하도록 안내하는 것을 목표로 한다. - 불안한 상태에서 검색 결과를 무작정 비교하지 않고, 증상·위치·보험·비용을 바탕으로 실행 가능한 선택지를 얻도록 설계했다. - 디자인 시스템과 실시간 협업 도구를 활용해 작은 팀으로도 많은 환자에게 영향을 주는 기능을 빠르고 안정적으로 개선했다. 실용적으로는 복잡하고 오류 비용이 큰 서비스일수록 사용자 흐름을 반복 테스트하고, 색상·텍스트·컴포넌트를 재사용 가능한 스타일로 관리하는 것이 중요하다. 또한 디자인 도구와 개발 전달 과정을 하나로 연결하면 원격 협업에서도 변경 사항을 빠르게 공유하고 구현 오류를 줄일 수 있다.

원문 읽기(새 탭에서 열림)
디자인 시스템Figma사용자 경험프로토타이핑+2