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

Tailwind UI 공식 피그

Tailwind Labs는 Tailwind UI의 코드 컴포넌트를 디자이너와 개발자가 함께 사용할 수 있는 공식 Figma 키트로 재구성했다. 약 1,400개의 컴포넌트와 10,000개의 요소를 제작하면서, 최종 코드 구조를 디자인 파일의 기준으로 삼고 레이어 이름·구조·변형을 체계화했다. 핵심 결론은 디자인 시스템을 실제 제품처럼 배포하려면 시각적 완성도뿐 아니라 일관된 구조와 사용성까지 세밀하게 설계해야 한다는 것이다. ## Tailwind UI Figma 키트 제작 배경 - Tailwind UI는 Tailwind CSS 기반의 반응형 HTML 컴포넌트 모음이다. - 고객들의 Figma 파일 요청이 지속적으로 늘어나 공식 Figma 키트를 제작하게 됐다. - 400개가 넘는 코드 컴포넌트를 바탕으로 1,400개 이상의 Figma 컴포넌트와 10,000개의 개별 요소를 구축했다. - 일반적인 작업용 디자인 파일과 달리, 상용 디자인 키트는 파일 자체가 최종 제품이므로 모든 세부 요소가 사용자 경험에 영향을 준다. ## 디자인 파일을 코드의 구조에 맞추기 - 최종 HTML 코드가 디자인 파일이 따라야 할 픽셀 단위 기준이 되도록 했다. - Figma의 오토 레이아웃, 레이아웃 그리드, 레이아웃 제약 조건을 활용해 HTML 마크업과 유사한 레이어 구조를 만들었다. - 디자인과 코드가 비슷한 구조를 가지면 디자이너와 개발자가 레이아웃 가능성을 공통으로 이해할 수 있다. - 반복되는 반응형 패딩이나 중앙 정렬된 최대 너비 컨테이너 같은 패턴을 디자인 파일에서 발견하고, 이를 개발자가 재사용 가능한 컨테이너 구조로 구현할 수 있었다. ## 일관된 레이어 이름 - 모든 레이어에 일관된 명명 규칙을 적용했다. - 예를 들어 버튼의 텍스트 레이어를 항상 `Text`로 지정하면, 버튼 크기나 변형을 바꿔도 사용자가 입력한 텍스트가 그대로 유지된다. - 복잡한 컴포넌트에서도 아이콘, 제목, 본문, 링크 등의 사용자 지정 내용이 다른 인스턴스나 변형으로 교체할 때 보존된다. - 일관된 레이어 이름은 단순한 정리 규칙이 아니라 Figma의 오버라이드 동작을 안정적으로 만드는 기반이다. ## 변형으로 컴포넌트 수 줄이기 - 여러 개의 유사한 컴포넌트를 개별적으로 관리하는 대신, 하나의 컴포넌트에 다양한 변형을 정의했다. - 예를 들어 80개의 배지 컴포넌트를 따로 만드는 대신 `type`, `size`, `theme`, 보조 요소 등의 속성을 가진 하나의 Badge 컴포넌트를 구성했다. - 코드 컴포넌트에서 사용하는 속성과 Figma의 변형 속성에 동일한 이름과 개념을 사용해 디자인과 개발 사이의 대응 관계를 명확히 했다. - 여러 컴포넌트에서 반복적으로 사용할 수 있는 변형 이름은 다음과 같다. - `type` - `size` - `theme` - `position` - `breakpoint` - `state` - 변형 패널 자체가 컴포넌트의 가능한 상태와 옵션을 설명하는 문서 역할을 한다. - 최종 키트에는 평균 7개의 변형을 가진 1,430개 컴포넌트가 포함됐다. - 변형을 사용하지 않았다면 컴포넌트 수가 10,000개를 넘었겠지만, 변형 덕분에 실제 코드 컴포넌트 수인 약 400개에 가까운 수준으로 관리할 수 있었다. ## 실용적인 결론 상용 Figma 키트를 만들 때는 화면을 예쁘게 복제하는 것보다 코드와 디자인의 구조를 일치시키는 일이 중요하다. 레이어 이름과 변형 속성을 처음부터 표준화하고, 반복되는 레이아웃 규칙을 컴포넌트 구조에 반영하면 사용자는 더 쉽게 커스터마이즈할 수 있고 디자인·개발 간 협업도 효율적으로 유지할 수 있다.

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

Figma디자인 시스템CSSHTML+3

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

노선도 완성하기

Courtney Garg Brousseau가 제작하던 샌프란시스코 베이 지역 대중교통 지도를 Figma가 그의 가족 허락을 받아 재현하고, 미완성 상태로 Figma Community에 공개했다. 이 글은 대중교통·지도·디자인에 관심 있는 사람들이 파일을 복제해 지도를 완성하고 다시 공유하는 협업을 제안한다. 프로젝트를 통해 Courtney의 작업과 공공교통에 대한 열정을 기리고, 커뮤니티 기반 창작의 가치를 보여준다. ## Courtney의 작업을 이어받은 지도 프로젝트 - Courtney Garg Brousseau는 뉴욕 지하철 지도에서 영감을 받아 샌프란시스코 베이 지역의 디지털 대중교통 지도를 Figma로 제작하고 있었다. - 그가 세상을 떠난 뒤 Figma 팀은 가족과 협의해 그의 작업을 기리고 발전시키기로 했다. - 원본 Figma 파일에 접근할 수 없었기 때문에, 팀원들은 당시 남아 있던 몇 장의 이미지와 자료를 바탕으로 지도를 처음부터 다시 만들었다. ## 미완성 지도를 커뮤니티에 공개한 이유 - 재현된 지도에는 참고 자료가 부족해 일부 노선과 세부 정보가 빠져 있었다. - Figma는 완성된 결과물을 일방적으로 제공하기보다, 미완성 파일 자체를 Figma Community에 공개했다. - 사용자가 직접 작업을 추가하고 서로의 결과물을 발전시키는 Figma Community의 공유·협업 문화를 프로젝트에 적용했다. - 대중교통 애호가, 지도 제작자, 디자이너가 각자의 지식과 관점을 보태기를 기대했다. ## Figma에서 참여하는 방법 - Figma Community에서 해당 transit map 파일을 연다. - **Duplicate** 버튼을 클릭해 자신의 Drafts에 복사한다. - 복제된 파일 이름에는 `(Community)`가 자동으로 추가된다. - 누락된 노선이나 정보를 추가하고, 기존 작업을 수정·확장한다. - 완성한 기여물을 다시 Figma Community에 게시하고 댓글을 통해 다른 참여자와 의견을 나눈다. ## 프로젝트가 전하는 의미 - 지도 제작은 단순한 시각화 작업을 넘어 지역의 이동 방식과 공공 인프라를 기록하는 일이다. - 한 사람의 개인 프로젝트가 커뮤니티의 참여를 통해 계속 확장될 수 있음을 보여준다. - Courtney의 삶과 유산을 소개하고, 그가 열정을 쏟았던 비영리단체를 지원할 방법도 함께 안내한다. 실용적으로는 원본을 그대로 완성하려 하기보다, 공식 자료를 확인하면서 누락된 노선·역·환승 정보를 검증하고 변경 사항을 댓글이나 설명에 기록하는 방식이 적절하다.

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

Figmadigital-designfigma-communitytransit-mapping+1

figma·2021년 3월 17일·3분 읽기큐레이션 요약

숫자로 보는 리모트

Figma는 원격 근무를 지원하기 위해 협업 템플릿을 제공했고, 실험 결과 템플릿을 사용한 그룹의 협업률이 5% 증가했다. 템플릿은 디자인뿐 아니라 화이트보딩, 팀 빌딩 등 다양한 업무로 협업을 확장했으며, 새로운 기능과 Figma Community 콘텐츠의 발견도 촉진했다. 원격 환경에서는 적절한 도구와 콘텐츠를 통해 협업을 의도적으로 설계하는 것이 중요하다는 결론이다. ## 원격 근무에 맞춘 협업 방식의 변화 - Figma는 오프라인에서 진행하던 브레인스토밍, 리서치, 팀 빌딩 등의 업무를 온라인으로 전환했다. - Figma를 단순한 디자인 도구가 아니라 원격 업무의 가상 공간으로 활용했다. - 데이터 과학팀은 성장팀에 임베디드되어 실험을 통해 사용자에게 가장 큰 가치를 주는 기능과 경험을 검증했다. - 원격 전환 이후 다음과 같은 협업 변화가 관찰됐다. - 지역과 시간대를 넘어 협업하는 사례 증가 - 디자이너와 다른 직군 간의 협업 강화 - 디자인 프로세스 초기에 더 많은 협업자 참여 ## 원격 협업 템플릿 가설 - Figma는 원격 근무에 특화된 템플릿을 개발·제공하면 협업이 증가할 것이라고 가정했다. - 템플릿이 제공할 수 있는 효과는 다음과 같았다. - 빈 파일에서 시작해야 하는 부담 감소 - 원격 브레인스토밍과 디자인 스프린트 같은 업무의 즉시 실행 - 디자인 외 업무에서도 Figma를 활용하도록 유도 - 성장팀은 사용자가 빈 프리셋이나 원격 업무용 템플릿을 선택해 새 파일을 만들 수 있는 ‘템플릿 피커’를 구축했다. ## 템플릿 피커 실험 결과 - 기존 사용자 일부를 대상으로 대조군과 실험군을 나누어 템플릿 피커의 효과를 측정했다. - 공유 파일에서 편집하거나 댓글을 작성한 사용자 비율을 협업률로 정의했다. - 템플릿 피커를 제공받은 그룹은 협업률이 **5% 증가**했다. - 템플릿은 특정 직군에만 효과가 있지 않았다. - 디자이너 - 제품·기획·개발 등 크로스펑셔널 동료 - 디자인 스프린트, 화이트보딩, 팀 빌딩 활동 사용자 ## 기능 발견과 커뮤니티 활용 증가 - 템플릿 피커는 협업뿐 아니라 Figma 기능 탐색에도 영향을 미쳤다. - 실험군에서: - 프레임 프리셋을 발견한 사용자가 **10% 증가** - 파일 생성 과정에서 Figma Community 파일을 활용한 사용자가 **90% 증가** - 사용자들은 템플릿을 실제로 사용했을 뿐 아니라, 소셜 미디어를 통해 긍정적인 반응을 보이고 더 다양한 용도의 템플릿을 요청했다. - 다른 사용자가 만든 작업물을 공유하고 재사용하는 Figma Community가 원격 환경에서 협업과 학습을 연결하는 역할을 했다. ## 실용적인 시사점 - 원격 협업 도구는 기능만 제공하기보다 업무별 시작점을 제시해야 한다. - 템플릿은 사용자의 초기 진입 장벽을 낮추고, 새로운 기능과 콘텐츠를 자연스럽게 발견하게 만든다. - 조직은 디자인 업무에 한정하지 않고 화이트보딩, 회고, 팀 빌딩 등 다양한 협업 시나리오에 맞는 템플릿을 마련하는 것이 좋다. - 이러한 변화는 추측보다 사용자 그룹을 나눈 실험과 협업률 같은 구체적인 지표로 검증해야 한다.

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

Figmaremote-collaboration데이터 사이언스figma-community+2

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

기능 비하인드

Figma는 Community 파일에서 사용자와 제작자가 더 깊이 소통할 수 있도록 일반 댓글과 캔버스 위치에 연결되는 컨텍스트 댓글을 도입했다. 기존 에디터 댓글 기능을 그대로 재사용하는 작업으로 시작했지만, 읽기 전용 파일 뷰어를 양방향 커뮤니케이션 공간으로 바꾸면서 UI·성능·공간 설계 문제가 발생했다. 최종적으로는 사용자가 캔버스를 클릭하면 전체 화면 댓글 보기로 전환하는 방향을 택했다. ## 커뮤니티에 댓글이 필요했던 이유 - Figma Community는 파일과 플러그인을 공유하고 발견하는 공간이었지만, 초기에는 제작자와 사용자 간 직접적인 소통 수단이 부족했다. - 글쓴이는 파일의 프로토타입 시작 프레임 오류를 발견했지만, 제작자에게 연락하기 위해 개인 웹사이트와 트위터를 거쳐 이메일을 찾아야 했다. - 이러한 경험을 개선하려면 단순한 리소스 공유를 넘어 질문, 의견, 피드백을 쉽게 주고받을 수 있어야 했다. - 이를 위해 두 가지 댓글 방식을 구상했다. - **일반 댓글**: 파일 아래 피드 형태로 표시 - **컨텍스트 댓글**: 에디터의 댓글처럼 파일 속 특정 위치에 연결 ## 기존 댓글 기능을 커뮤니티에 적용하며 생긴 문제 - 처음에는 기존 에디터 댓글 UI와 코드를 파일 미리보기에 그대로 덧붙이면 될 것으로 예상했다. - 하지만 다음과 같은 기술적 수정이 필요했다. - 뷰포트 정보를 주고받을 수 있도록 기존 iframe 기반 파일 미리보기 구조를 교체 - 댓글 수가 많아질 때 발생할 수 있는 성능 문제 검토 - 더 큰 어려움은 코드보다 상호작용 설계였다. - 에디터 내부 댓글과 비슷해 보이려면, 읽기 전용 커뮤니티 뷰어에서는 오히려 다른 상호작용을 설계해야 했다. - 기존 Community는 제작자가 콘텐츠를 공개하고 사용자가 이를 소비하는 일방향 구조였지만, 댓글은 사용자에서 제작자로 향하는 새로운 소통 경로를 만들었다. - 특히 컨텍스트 댓글은 일반적인 세로형 댓글 피드와 달리 다음 문제를 해결해야 했다. - 댓글을 디자인의 특정 지점에 고정하는 방법 - 댓글을 보면서 캔버스를 이동하고 탐색하는 방법 - 댓글 기능이 기존의 편안한 읽기 전용 경험을 방해하지 않도록 하는 방법 ## 초기 디자인 탐색과 협업 - 엔지니어링, 디자인, 제품 팀은 개발 과정 내내 긴밀한 피드백 루프를 유지했다. - 정적인 와이어프레임보다 댓글 생성과 캔버스 이동을 보여주는 GIF와 인터랙션 프로토타입을 적극 활용했다. - 여러 시안을 통해 다음과 같은 방향을 탐색했다. - 댓글 피드를 배치할 위치 - 캔버스 미리보기에서 댓글을 확인하는 방식 - 댓글 위치를 이해하기 위한 미니 뷰어와 전체 화면 뷰어 - 구체적인 프로토타입 덕분에 기술적 실현 가능성, UI 예외 상황, 출시 일정에 따라 기능 범위를 빠르게 좁힐 수 있었다. ## 초기 출시를 위한 세 가지 목표 - 사용자가 최대한 빠르고 쉽게 댓글 기능에 진입하도록 해 참여를 유도한다. - 컨텍스트 댓글이 달린 파일 위치를 충분히 크게 보여주어 사용자가 댓글의 의미와 디자인 맥락을 이해하도록 한다. - 출시 일정 안에서 구현 가능하고 지나치게 복잡하지 않은 해결책을 선택한다. ## 전체 화면 기반 컨텍스트 댓글 - 위 목표와 제약을 바탕으로 컨텍스트 댓글은 **전체 화면 보기에서만** 표시하도록 결정했다. - 전체 화면은 댓글이 연결된 디자인 영역을 충분히 확인할 수 있는 공간을 제공한다. - 사용자가 축소된 캔버스를 클릭하면 전체 화면 뷰어로 확장되도록 설계했다. - 반대로 축소된 캔버스에서는 클릭과 패닝을 비활성화해, 일반적인 파일 탐색 경험과 댓글 상호작용이 충돌하지 않도록 했다. - 결과적으로 댓글 기능을 기존 파일 뷰어에 무리하게 끼워 넣기보다, 댓글을 확인하고 위치를 탐색하는 별도의 집중된 경험으로 분리했다. ## 실용적인 시사점 기존 기능을 다른 제품 영역에 재사용할 때는 코드 복사보다 사용 맥락의 차이를 먼저 검토해야 한다. 특히 읽기 전용 화면에 편집기용 상호작용을 도입한다면, 기능 자체보다 진입 방식·공간 배치·탐색 흐름·성능과 같은 전체 사용자 경험을 함께 재설계하는 것이 중요하다.

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

Figma사용자 인터페이스interaction-designiframe+2

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

Inside Figma: 피그마를

Figma 팀은 Figma를 제품 디자인뿐 아니라 브레인스토밍, 팀 활동, 원격 리서치 등 다양한 협업에 활용한다고 소개합니다. 핵심은 특정 숙련도나 직무에 상관없이 누구나 쉽게 참여하도록 시각적 템플릿과 구조화된 프레임워크를 사용하는 것입니다. 특히 영감 수집과 연구 참여를 자연스럽게 만드는 방법을 통해 창의성과 협업을 촉진합니다. ## 다양한 직무에서 활용하는 Figma - 엔지니어링, 제품, 디자인, 리서치 등 여러 팀이 Figma를 업무 전반에 사용합니다. - 제품 디자인 외에도 다음과 같은 용도로 활용합니다. - 팀 빌딩 활동 - 원격 사용자 리서치 - 브레인스토밍과 아이디어 발상 - 협업을 통한 창작 작업 - 라이브스트림에서는 키보드 단축키, 빠른 작업 방법, 블렌드 모드, 이징 커브 등을 소개했습니다. - Figma의 장점은 다양한 숙련도의 사용자가 각자의 방식으로 활용할 수 있다는 점입니다. ## 마인드맵 스케치북으로 아이디어 확장 브랜드 디자이너 Remilla Ty는 영감을 모으고 여러 방향을 탐색하기 위한 ‘마인드맵 스케치북’ 방법을 소개합니다. - **Prompt** - 프로젝트 이름이나 작업의 핵심 문장을 적습니다. - **Image** - 작업에 영감을 주는 이미지를 수집합니다. - **Keywords** - 이미지와 관련된 단어나 문구를 적고, 이를 프로젝트의 프롬프트와 연결합니다. - 이미지와 키워드 사이의 공통 주제를 찾으면 새로운 크리에이티브 콘셉트로 발전시킬 수 있습니다. - Figma 브랜드 팀은 Figma Community의 브랜딩 방향을 탐색할 때 이 프레임워크를 사용했습니다. - 이 과정에서는 정답이나 오답을 판단하기보다 다양한 방향을 열어 두는 것이 중요합니다. ## 리스트와 무드 보드로 브랜드 방향 구체화 두 번째 방법은 프로젝트를 언어적으로 정리한 뒤 시각 자료로 확장하는 방식입니다. - 리스트를 다음 세 부분으로 나눕니다. - **Prompt:** 현재 작업 중인 내용을 있는 그대로 설명 - **Beyond:** 프로젝트의 추상적인 의미나 한 단계 확장된 해석 - **Look and feel:** 결과물을 본 사람이 느끼기를 원하는 분위기 - 작성한 내용에서 반복되는 테마와 키워드를 뽑아 무드 보드에 배치합니다. - 관련 이미지와 색상 팔레트를 추가해 여러 요소가 어떻게 조화를 이루는지 확인합니다. - 마지막으로 콘셉트 문장을 작성해 브랜드 아이덴티티의 방향을 정리합니다. - Figma 팀은 Maker Week의 새로운 방향을 탐색할 때 이 방법을 활용했습니다. - 이러한 프레임워크는 팀원들이 프로젝트를 어떻게 이해하고 있는지 공유하는 데도 도움이 됩니다. ## 창작 과정에서 ‘몰입 상태’ 만들기 - 브레인스토밍 초기에 결과의 완성도나 방향의 정답 여부를 판단하지 않습니다. - 이미지, 단어, 감정, 색상 등 다양한 재료를 자유롭게 모으며 사고를 확장합니다. - 시각적으로 아이디어를 공유하면 팀원들의 관심사와 프로젝트에 대한 관점을 빠르게 파악할 수 있습니다. - 목표는 올바른 답을 즉시 찾는 것이 아니라, 가장 창의적으로 생각할 수 있는 ‘몰입 상태’에 들어가는 것입니다. ## 리서치를 편안하게 만드는 활동 리서처 Nannearl Brown은 Figma를 활용해 연구 참여자가 부담을 덜 느끼도록 연구 과정을 구성한다고 설명합니다. - 연구 참여자가 자신의 정보를 공유할 때 편안함을 느끼도록 사전 활동과 인터랙티브한 연습을 제공합니다. - 연구 시작 전에 ‘Figma 트레이딩 카드’를 사전 과제로 보낼 수 있습니다. - 트레이딩 카드에는 다음과 같은 질문이 포함됩니다. - 가장 좋아하는 Figma 기능 - Figma를 사용하는 방식 - 참여자에 관한 개인적인 질문 - 이 활동은 참여자가 자신의 경험을 미리 정리하게 하고, 본격적인 연구 세션에 자연스럽게 참여하도록 돕습니다. Figma를 단순한 디자인 제작 도구로 보기보다, 아이디어를 구조화하고 팀의 생각을 공유하는 협업 공간으로 활용하는 것이 이 글의 실용적인 제안입니다. 처음에는 마인드맵이나 무드 보드 템플릿처럼 부담이 적은 방식부터 도입하고, 결과보다 탐색과 참여를 우선하는 것이 좋습니다.

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

Figmauser-researchremote-collaborationbrainstorming+2

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

피그마 내부 이야기: 엄

Figma는 TypeScript의 `strictNullChecks`를 도입해 `null`·`undefined`로 인한 런타임 오류를 컴파일 단계에서 줄이고 코드 유지보수성을 높였다. 약 1,162개 파일과 4,000개 이상의 오류가 있는 대규모 코드베이스였지만, 제품 개발을 중단하지 않고 파일 단위의 점진적 허용 목록 방식으로 마이그레이션했다. 이 사례는 기존 코드베이스의 타입 안전성을 높일 때 전면 전환보다 점진적이고 지속 가능한 전략이 효과적임을 보여준다. ## `strictNullChecks`가 해결하는 문제 - 기본 TypeScript 설정에서는 대부분의 값이 `null`이 될 수 있어 다음과 같은 대입이 허용된다. ```ts var v: Vector = { x: 1, y: 2 } v = null ``` - `strictNullChecks`를 활성화하면 `null`을 허용하는 타입을 명시적으로 선언해야 한다. ```ts var nullableVector: Vector | null = { x: 1, y: 2 } nullableVector = null ``` - 컴파일러는 제어 흐름 분석을 통해 값이 `null`인지 확인한 뒤 안전하게 사용할 수 있는지 검사한다. - `if (v)` 같은 조건문을 통과하면 `v`의 타입을 `Vector | null`에서 `Vector`로 좁혀, 안전하지 않은 프로퍼티 접근을 방지한다. - 그 결과 `cannot access .name of undefined`와 같은 오류를 컴파일 단계에서 발견할 수 있다. ## 오류 감소와 코드 유지보수성 향상 - Figma의 과거 장애 데이터에 따르면, 심각도가 높은 일부 프로덕션 장애는 strict null checks를 적용했다면 배포 전에 발견할 수 있었다. - 타입에 `null` 가능성이 명시되면 “이 시점에 파일 정보가 로드되어 있는가?” 같은 질문에 코드 자체가 답을 제공한다. - 함수가 `Vector`만 받는지, `Vector | null`도 받을 수 있는지 타입으로 명확히 표현할 수 있다. - null 처리 로직이 암묵적인 관례가 아니라 타입 시스템에 드러나므로 코드 이해와 변경이 쉬워진다. ## 대규모 레거시 코드베이스의 난점 - Figma는 TypeScript 2.0에서 `strictNullChecks`가 도입되기 전에 TypeScript를 사용하기 시작했다. - 기존 JavaScript 코드에 타입을 점진적으로 추가한 프로젝트에서는 null이 기본적으로 허용되는 경우가 많다. - 설정을 한 번에 켜자 약 1,162개 TypeScript 파일에서 4,000개 이상의 오류가 발생했다. - 한 오류를 수정하면 그 수정으로 인해 새로운 오류가 드러나는 연쇄적인 문제가 있었다. - 마이그레이션 중 코드베이스도 376,000줄에서 464,000줄로 증가했기 때문에, 일반적인 개발을 멈추지 않는 전략이 필요했다. ## 전면 중단 방식의 한계 - 모든 엔지니어가 기존 업무를 멈추고 마이그레이션에 참여하는 방식이다. - 마이그레이션 작업은 병렬화에 한계가 있어 모든 인력을 투입해도 효율적이지 않다. - 당시 제품 개발을 중단하면 사업 모멘텀을 잃을 수 있었다. - 조직과 팀 규모가 커질수록 여러 팀의 업무를 동시에 조정하기도 어려워진다. ## 오류를 장기간 병행 수정하는 방식의 한계 - strict null checks를 실제 빌드 규칙으로 활성화하지 않고 CI에서만 오류를 점진적으로 수정하는 방식이다. - 기존 개발 흐름을 거의 방해하지 않는다는 장점이 있다. - 그러나 강제되지 않는 상태에서는 새 코드가 계속 오류를 추가할 수 있다. - 오류를 수정하는 속도보다 새 오류가 생기는 속도가 빠르면 전체 진척도가 오히려 후퇴한다. - Figma는 이러한 방식이 오류를 줄이는 속도가 오류 유입 속도보다 빠를 때만 적절하다고 평가했다. ## 파일 단위의 점진적 허용 목록 - Figma가 선택한 방식은 strict null checks를 통과한 파일을 허용 목록에 하나씩 추가하는 것이다. - 코드베이스를 두 번 컴파일한다. - 전체 파일은 기존처럼 strict null checks 없이 컴파일한다. - 허용 목록에 포함된 파일은 strict null checks를 켠 상태로 컴파일한다. - 이를 통해 마이그레이션이 완료된 파일은 엄격한 타입 검사를 받으면서도, 아직 수정되지 않은 파일은 기존 개발 흐름을 유지할 수 있다. - Figma는 VS Code 팀의 유사한 마이그레이션 도구에서 출발해 자체 코드베이스의 특성에 맞게 확장했다. - 이 전략은 제품 개발을 중단하지 않고도 마이그레이션 진행 상황을 명확히 관리할 수 있게 한다. 기존 TypeScript 프로젝트에 strict null checks를 도입할 때는 설정을 한 번에 켜기보다, 파일·모듈 단위의 허용 목록과 별도 컴파일 구성을 활용하는 것이 현실적이다. 특히 새 코드가 계속 추가되는 조직에서는 “언젠가 고치기”보다 통과한 영역을 즉시 엄격한 규칙으로 보호하는 방식이 효과적이다.

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

TypeScriptJavaScriptcode-migrationstrict-null-checks+1

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

드롭박스의 일하는 방식 리

코로나19로 Dropbox는 사무실 중심 문화를 버리고 ‘virtual-first’ 업무 모델로 전환하면서, 온라인에서 협업과 창의성을 재현하는 방식을 다시 설계했다. 디자인팀은 Figma를 단순한 디자인 도구가 아니라 브레인스토밍, 리뷰, 핸드오프, 부서 간 커뮤니케이션이 이루어지는 업무의 중심 공간으로 활용했다. 또한 Figma 사용법을 전사적으로 교육해 디자인 외 조직까지 시각적 협업에 참여하도록 만들었다. ## 사무실 중심 문화에서 virtual-first로 - Dropbox는 12개 글로벌 오피스에 Maker Room과 협업 공간을 운영하며 대면 창의성을 업무 문화의 핵심으로 삼고 있었다. - 디자인팀은 포스트잇, 마커, 장난감 등을 활용해 디자인 스프린트와 즉석 브레인스토밍을 진행했다. - 원격근무에서는 우연히 만나 아이디어를 주고받거나 같은 공간에서 자연스럽게 몰입하는 일이 어려워졌다. - 따라서 기존의 물리적 협업 방식을 온라인 환경에 맞게 의도적으로 재설계해야 했다. ## Figma를 활용한 원격 협업 - Dropbox 디자인팀은 2018년 Sketch에서 Figma로 전환한 덕분에 브레인스토밍, 와이어프레임, 프로토타이핑, 댓글 작성 등 원격 협업의 기반을 이미 갖추고 있었다. - 대면 디자인 리뷰 대신 Figma의 **관찰 모드(Observation mode)** 를 사용해 발표자의 화면을 실시간으로 따라갔다. - 디자이너들은 책상 옆에서 함께 작업하는 대신 Figma 링크를 공유하고 같은 파일에 들어가 아이디어를 빠르게 수정했다. - 엔지니어와 PM도 Figma 기반 디자인 스프린트에 참여하면서 부서 간 협업이 쉬워졌다. - 디자인 파일 자체가 결과물뿐 아니라 논의와 의사결정이 기록되는 커뮤니케이션 공간이 되었다. ## 비동기 핸드오프로 커뮤니케이션 단순화 - Design System 팀과 Brand Studio 팀은 아이콘 전달 과정을 Figma 템플릿으로 표준화했다. - 브랜드 디자이너가 아이콘 작업을 완료하면 해당 페이지에 체크 표시를 남긴다. - 디자인 시스템 팀은 매주 월요일 파일을 확인해 새 아이콘을 마스터 라이브러리에 반영하고 게시한다. - 별도의 반복적인 메시지나 진행 상황 확인 없이 파일 상태만으로 업무 진행 여부를 알 수 있게 되었다. - 이 방식은 다른 협업 라이브러리에도 적용할 수 있는 효율적인 비동기 프로세스로 평가됐다. ## Figma를 전사 협업 도구로 확장 - 디자인팀은 다른 부서가 Figma를 사용할 수 있도록 댓글, 내보내기, 화면 보기 및 따라가기 기능을 중심으로 워크숍을 진행했다. - 워크숍에는 마케팅, 리서치, 데이터 사이언스 등 200명 이상의 구성원이 참여했다. - 교육의 목적은 원격 환경에서도 실제 사무실의 화이트보드처럼 함께 보고, 말하고, 아이디어를 발전시키게 하는 것이었다. - 디자인 외 조직도 Figma에서 다음과 같이 활용하기 시작했다. - QA: 디자인 플로우를 복제해 테스트 계획과 테스트 케이스 작성 - 디자인 리서치: 설문 데이터와 정성적 인사이트를 나란히 배치해 발표 - 여러 조직: 프레젠테이션 공동 제작 - 그 결과 Figma는 Dropbox 전체 구성원이 시각적으로 소통하고 공동 작업하는 공용 공간으로 자리 잡았다. ## 실용적인 시사점 원격 협업을 정착시키려면 기존 대면 업무를 화상회의로 단순히 옮기는 데 그치지 말고, 협업 산출물·상태·의사결정을 하나의 공유 공간에 남기는 방식으로 프로세스를 재설계해야 한다. 특히 명확한 템플릿, 상태 표시, 비동기 핸드오프 규칙을 마련하고 비디자이너까지 도구 교육에 참여시키는 것이 효과적이다.

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

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

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

브라우저에서 만나요 |

Figma는 디자인 도구를 브라우저로 옮김으로써 협업·투명성·접근성을 기본값으로 만들고, 디자인을 소수 전문가의 영역에서 모두가 참여하는 활동으로 확장하려 했다. 이러한 변화는 멀티플레이어 편집, 플랫폼 독립성, 저렴한 접근성을 제공하지만 기존의 통제권과 전문성에 대한 인식을 흔들어 반발도 일으켰다. 글은 브라우저가 단순한 기술적 실행 환경이 아니라 조직과 사회의 협업 방식을 바꾸는 매체라고 결론짓는다. ## 브라우저 기반 디자인을 선택한 이유 - Figma는 출시 초기부터 데스크톱 애플리케이션이 아닌 브라우저 중심 제품에 모든 것을 걸었다. - Google Docs와 같은 인터넷 네이티브 소프트웨어가 다음 가치를 구현한다고 보았다. - 실시간 협업 - 정보와 파일의 투명한 공유 - 플랫폼과 기기에 구애받지 않는 접근성 - 기존 디자인 도구의 오프라인·단일 사용자 방식을 온라인 협업 환경으로 전환하려 했다. ## 기존 디자인 문화의 반발 - 일부 디자이너는 브라우저 기반 디자인을 디자인 직업 자체에 대한 위협으로 받아들였다. - 부정적인 반응의 배경에는 다음과 같은 우려가 있었다. - 작업 과정이 지나치게 공개되어 디자인의 전문성이 희석될 수 있음 - 다른 사람의 실시간 개입으로 마이크로매니지먼트가 심해질 수 있음 - 투명성이 높아지면서 일정과 업무 압박이 커질 수 있음 - 다른 사람이 파일을 수정하거나 재구성하면서 디자이너의 통제권이 줄어듦 - 누구나 디자인할 수 있다면 전문 디자이너의 역할은 무엇인지에 대한 정체성 문제 - 디자인이 개인의 창작물처럼 느껴지는 만큼, 작업물을 공개하고 다른 사람이 수정하도록 허용하는 일은 심리적으로 큰 변화였다. ## 브라우저가 제공하는 기술적 변화 - 브라우저는 본질적으로 여러 사용자가 동시에 참여하는 멀티플레이어 환경이다. - Figma가 강조한 구체적인 이점은 다음과 같다. - 파일의 단일 진실 공급원(single source of truth) - 운영체제와 기기에 상관없는 크로스 플랫폼 지원 - 여러 사용자가 하나의 파일을 동시에 편집하는 멀티플레이어 편집 - 고가의 전문 하드웨어에 대한 의존도 감소 - 팀원이 막힌 상황을 숨기기보다 함께 문제를 해결하는 작업 방식 - 따라서 브라우저 전환은 단순히 저장 위치나 UI를 바꾸는 것이 아니라, 사용자가 협업하는 방식을 바꾸는 일이다. ## “내 아이디어”에서 “우리의 아이디어”로 - 협업 도구를 사용하면 팀은 개인 소유 중심의 사고에서 공동 창작 중심의 사고로 이동한다. - 이를 위해서는 다음과 같은 조직 문화가 필요하다. - 작업 중인 아이디어를 일찍 공유하는 신뢰 - 실패와 미완성 상태를 숨기지 않는 투명성 - 다른 사람이 아이디어를 발전시키거나 재해석하도록 허용하는 개방성 - Figma의 협업 공간은 디자인 결과물뿐 아니라 아이디어가 만들어지는 과정에도 더 많은 사람을 참여시킨다. ## 물리적 공간에서 디지털 공간으로 - 브라우저 기반 협업은 코로나19로 가속된, 물리적 공간에서 디지털 공간으로의 장기적인 이동의 일부다. - 물리적 공간에는 벽과 좌석, 권한 구조가 존재하지만 디지털 공간은 기본적으로 더 개방적이고 비위계적이다. - 누구나 같은 공간에서 브레인스토밍하고, 만들고, 실험할 수 있다는 점이 디지털 협업의 중요한 특징이다. - Figma는 기술을 단순한 생산성 도구가 아니라 사람들을 연결하고 공동의 사고를 가능하게 하는 매체로 바라본다. ## 디자인 접근성의 확대 - Figma의 장기적인 목표는 디자인을 모든 사람이 접근할 수 있는 활동으로 만드는 것이다. - 디자인 도구 사용 능력이 특정 전문가의 자격처럼 취급되지 않고, Google Docs 사용 능력처럼 당연한 기본 역량이 되기를 지향한다. - 이를 위해서는 아이디어 구상부터 실제 제작까지 디자인 프로세스의 모든 단계와 역할을 지원해야 한다. - 하드웨어, 전문 도구, 직함이 사람들의 참여를 막는 장벽이 되어서는 안 된다는 메시지도 강조한다. ## 실용적인 결론 브라우저 기반 도구를 도입할 때는 기능이나 비용 절감만 볼 것이 아니라, 작업 공개·실시간 협업·권한 공유를 받아들일 조직 문화를 함께 준비해야 한다. 팀은 미완성 작업을 공유해도 안전하다는 신뢰를 만들고, 특정 전문가만 의사결정하는 방식에서 벗어나 더 많은 구성원이 디자인과 문제 해결에 참여하도록 설계하는 것이 좋다.

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

Figmacollaborative-designmultiplayer-editingweb-browser+1

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

모두 더해보기: 커리어

평균적인 커리어는 약 9만 시간으로 이루어지지만, 그 경로가 처음부터 정해진 직선처럼 보이는 것은 아니다. 저자는 현재의 선택을 과거의 성공적인 이야기로 끼워 맞추기보다, 여러 관심사와 경험이 교차하는 지점을 탐색하며 커리어를 설계해야 한다고 말한다. 커리어의 방향은 사후적으로만 선명해지므로, 각 단계에서 지속적으로 자신의 선택을 점검하고 새로운 가능성을 실험하는 것이 중요하다. ## 산점도로 살아가는 커리어 - 사람들은 커리어를 설명할 때 현재에서 과거를 되돌아보며 여러 경험을 연결한 ‘추세선’으로 이야기하는 경향이 있다. - 하지만 추세선은 데이터가 쌓인 뒤에야 그릴 수 있다. 실제 삶은 관심사와 직업을 이리저리 옮겨 다니는 산점도에 가깝다. - 현재 시점에서는 앞으로 어떤 추세선이 만들어질지 예측하기 어렵기 때문에 다음 선택이 불안하게 느껴진다. - 평균적으로 사람은 깨어 있는 시간의 약 3분의 1인 9만 시간을 일에 사용한다. - 일은 생계뿐 아니라 안정감, 목적의식, 좌절, 자부심 등 삶의 중요한 감정과도 연결되어 있다. - 따라서 커리어를 의미 있고 지속 가능한 방향으로 만들려면, 자신의 경험과 선택을 정기적으로 분석해 실제 경로를 더 정확히 이해해야 한다. ## 관심사의 교집합을 찾는 벤 다이어그램 - 벤 다이어그램은 서로 다른 집합의 교집합을 보여주는 도구이며, 커리어에서는 서로 무관해 보이는 관심사들이 만나는 지점을 탐색하는 데 활용할 수 있다. - 취미와 직업을 양자택일로 구분하면 “취미는 어른이 되면 포기해야 한다”와 같은 잘못된 이분법에 빠질 수 있다. - 서로 다른 분야의 결합은 새로운 직업과 혁신의 출발점이 될 수 있다. - 저자는 어린 시절 CorelDRAW로 포스터를 만들던 경험을 통해 디자인에 흥미를 느꼈지만, 당시에는 그 관심을 커리어와 연결하지 못했다. - 대학 시절에는 채용, 마케팅, 엔지니어링, 프로젝트 관리 등 여러 인턴십을 경험하며 기술 업계에 관심을 넓혔다. - 한 디자이너에게서 디자인 실력은 타고난 재능보다 반복적인 작업과 끊임없는 개선으로 발전한다는 점을 배우면서 디자인을 직업으로 시도할 자신감을 얻었다. - 결과적으로 기술, 스토리텔링, 사람에 대한 관심이 제품 디자인이라는 분야에서 교차했다. - 현재의 전문 분야에 대한 열정이 약해지더라도, 관심사의 교집합을 살펴보면 다른 직업적 선택지를 발견할 수 있다. ## 커리어를 사후적으로만 해석하지 않기 - 자기소개나 이력서는 과거의 경험이 처음부터 현재의 직업을 향해 이어져 온 것처럼 보이게 만든다. - 그러나 실제 커리어는 우연한 만남, 다양한 실험, 예상 밖의 경험이 쌓여 형성된다. - 과거의 경험을 하나의 완성된 서사로 포장하기보다, 아직 의미를 발견하지 못한 경험도 미래의 가능성이 될 수 있다고 봐야 한다. - 현재 좋아하는 일뿐 아니라 어린 시절의 취미, 잠깐 시도했던 활동, 주변 사람에게서 받은 자극도 커리어 선택의 단서가 될 수 있다. 자신의 커리어를 결정된 운명처럼 해석하기보다, 관심사·경험·기술이 만나는 지점을 주기적으로 살펴보는 것이 좋다. 여러 분야를 직접 시도하고 그 결과를 기록하면, 시간이 지난 뒤 자신에게 맞는 커리어의 추세선을 더 선명하게 그릴 수 있다.

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

프로덕트 디자인data-visualizationhuman-computer-interactioncoreldraw+1

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

기능 비하인드: 새로운

Figma의 새 Auto Layout은 수동으로 요소 크기와 간격을 조정하던 작업을 자동화하면서도, CSS Flexbox의 강력함을 그대로 복잡하게 노출하지 않는 방향으로 설계됐다. 핵심 원칙은 “Flexbox의 신중한 부분집합”으로, 코드와 디자인의 정렬을 돕되 누구나 쉽게 이해하고 사용할 수 있게 만드는 것이었다. 새 버전은 사용자 피드백을 바탕으로 유연성과 기능을 확장한 결과다. ## 수동 리사이징 문제에서 출발한 Auto Layout - Auto Layout 출시 전에는 버튼의 텍스트가 길어지면 다음 작업을 직접 해야 했다. - 버튼 크기 조정 - 주변 버튼 위치 이동 - 대화상자 컨테이너 크기 조정 - 패딩과 간격 재조정 - 이런 수작업은 단순히 번거로운 것을 넘어 반응형 디자인 시스템 구축의 장애물이 됐다. - Figma 초기 설계에도 프레임 내부 객체를 자동으로 배치하는 아이디어가 있었지만, 제품 출시 당시에는 구현되지 않았다. - 2018년 Maker Week에서 제품 디렉터 Sho가 초기 아이디어를 다시 프로토타입으로 발전시켰고, 이후 전담 팀이 Auto Layout을 실제 기능으로 구현하기 시작했다. ## Flexbox를 참고하되 단순하게 설계 - 팀은 웹 기술인 CSS Flexbox의 강력함과 범용성에서 영감을 얻었다. - 디자인과 코드 사이의 개념적 일치를 높이려면 Flexbox와 유사한 모델이 유리했다. - 그러나 사용자가 브라우저와 CSS를 깊이 이해해야 한다면 Figma의 접근성이 떨어질 수 있었다. - 이에 따라 “Auto Layout은 Flexbox의 신중한 부분집합이어야 한다”는 설계 원칙을 세웠다. - 이 원칙은 기능을 추가하면서도 설정 항목과 동작 규칙을 불필요하게 복잡하게 만들지 않도록 팀의 의사결정을 이끌었다. ## 첫 번째 Auto Layout의 핵심 개념 - 프레임에 Auto Layout을 적용하면 내부 요소를 수직 또는 수평으로 배치할 수 있다. - 요소 사이의 수직·수평 간격을 지정할 수 있다. - Auto Layout 프레임은 기본적으로 주축 방향에서 내부 컴포넌트 크기에 맞춰 늘어나거나 줄어든다. - 반대축 방향도 고정 너비 또는 내부 콘텐츠에 맞추는 방식으로 설정할 수 있다. - 프레임 내부의 각 컴포넌트는 컨테이너 기준으로 개별 정렬할 수 있다. - 수직 레이아웃에서는 좌·중앙·우 정렬 - 수평 레이아웃에서는 상·중앙·하 정렬 ## HTML 프로토타입과 초기 검증 - Auto Layout 디자이너 Marcin은 처음부터 HTML로 프로토타입을 제작했다. - 실제 웹 환경과 유사한 프로토타입을 통해 기능의 사용감과 동작을 조기에 확인할 수 있었다. - 이 과정에서 다음과 같은 세부 동작을 구체화했다. - 프레임 핸들의 시각적 장식 - 객체를 드래그할 때의 동작 - Auto Layout 프레임의 외곽선 표시 - 초기 프로토타입은 기능 목록을 정하는 데 그치지 않고, 편집기에서 사용자가 기능을 어떻게 인식하고 조작할지 검증하는 역할을 했다. ## 기능 확장과 사용성 사이의 균형 - 초기 Auto Layout은 접근성과 직관성을 우선해 설계됐다. - 이후 사용자 피드백을 반영하면서 더 강력하고 유연한 레이아웃 기능을 추가했다. - 다만 유연성을 높일수록 설정과 예외 상황이 늘어나 사용성이 떨어질 수 있으므로, 기능의 범위를 의도적으로 제한했다. - 새 버전은 단순한 UI 변경이 아니라, 초기의 단순한 모델을 유지하면서 더 다양한 반응형 레이아웃 요구를 수용하려는 설계 개선이다. Auto Layout을 설계할 때는 Flexbox처럼 검증된 레이아웃 모델을 참고하되, 사용자가 모든 내부 규칙을 학습하지 않아도 되도록 핵심 개념만 제공하는 것이 중요하다. 또한 실제 편집 환경을 반영한 프로토타입과 사용자 피드백을 통해 기능의 유연성과 조작의 직관성을 함께 검증해야 한다.

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

Figma디자인 시스템CSSHTML+3

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

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

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

기능 비하인드:

Figma의 오토세이브는 단순히 파일 전체를 주기적으로 디스크에 저장하는 기능이 아니다. 브라우저 기반 실시간 협업 환경에서는 대용량 문서, 단일 스레드 실행, 동시 편집, 충돌 해결이 서로 얽히기 때문에 전체 파일 대신 오프라인 이후의 변경분(delta)을 저장하는 방식이 적합하다. Figma는 이 변경분을 IndexedDB에 보관했다가 문서를 다시 열 때 최신 문서에 적용하고 서버로 업로드한다. ## 오프라인 작업에서 발생하는 데이터 손실 - 온라인 상태에서는 Figma가 변경 사항을 서버로 즉시 전송한다. - 하지만 인터넷 연결이 끊기면 변경 사항을 서버와 동기화할 수 없다. - 기존에는 브라우저 탭이나 컴퓨터가 종료되면 오프라인 상태에서 작업한 내용이 사라질 위험이 있었다. - 확장된 오토세이브 시스템은 문서가 서버와 연결되지 않은 시점부터 변경 사항을 디스크에 저장한다. - 이후 문서를 새 탭에서 열면 저장된 변경 사항을 복원하고 서버에 업로드한다. ## 전체 파일 저장 방식의 한계 - 가장 단순한 방법은 메모리에 있는 scenegraph 전체를 직렬화해 백업 파일로 저장하는 것이다. - Figma 문서는 레이어 노드 트리인 **scenegraph**로 표현된다. - 큰 파일은 압축된 바이너리 기준 수십 MB, 메모리상에서는 수백 MB까지 커질 수 있다. - 전체 scenegraph를 직렬화하는 데 수 초가 걸릴 수 있으며, 저장할 때마다 사용자가 지연을 경험하게 된다. - 직렬화 시간을 10~20배 줄여 100ms 수준으로 만들어도 브라우저 환경에서는 충분하지 않다. - JavaScript와 WASM이 기본적으로 단일 스레드에서 실행되기 때문이다. - 사용자는 저장 시마다 약 100ms의 끊김을 느낄 수 있다. - 작업을 여러 프레임에 나누어 실행할 수 있지만, 직렬화 중 사용자가 문서를 수정하면 어떤 상태를 저장해야 하는지 문제가 발생한다. - 변경되지 않는 immutable scenegraph를 사용하면 해결할 수 있지만, 애플리케이션 전반의 대규모 구조 변경이 필요하고 메모리 사용량과 쓰기 성능 저하라는 비용도 따른다. ## 실시간 협업이 만드는 저장 문제 - Figma 파일은 클라우드에 저장되고 여러 사용자가 동시에 편집할 수 있다. - 오프라인 백업 파일 전체를 서버의 기존 파일로 덮어쓰면, 다른 사용자가 이후에 만든 최신 변경 사항을 잃을 수 있다. - 백업 파일을 별도 복사본으로 남기는 방법도 충분하지 않다. - 일부 파일은 디자인 시스템의 버튼이나 모달 같은 공유 컴포넌트의 원본이기 때문이다. - 복사본을 만드는 순간 공유 자산의 원본과 실제 작업 내용이 분리될 수 있다. - 따라서 오토세이브는 단순한 파일 복구가 아니라, 협업 시스템의 변경 병합 및 충돌 해결 방식과 함께 설계되어야 한다. ## 전체 문서가 아닌 변경분 저장 - Figma는 전체 파일 대신 사용자가 오프라인이 된 이후 발생한 변경 사항만 저장한다. - 이 변경분은 기존 멀티플레이어 편집 시스템에서 이미 서버 전송 및 확인을 위해 관리하던 데이터다. - 전형적인 흐름은 다음과 같다. - 사용자가 문서를 불러온다. - 서버 연결이 끊긴다. - 사용자의 변경 사항이 메모리의 pending changes buffer에 쌓인다. - 일정한 간격으로 버퍼의 내용이 디스크에 저장된다. - 문서나 브라우저 탭이 예기치 않게 종료된다. - 사용자가 문서를 다시 연다. - 저장된 변경분을 역직렬화한다. - 최신 문서 위에 변경분을 적용한다. - 복원된 변경 사항을 서버에 업로드한다. - 최신 문서에 변경분을 적용하므로, 오래된 전체 백업으로 최신 서버 상태를 덮어쓰는 문제를 피할 수 있다. ## IndexedDB를 활용한 브라우저 저장 - 브라우저에서 대용량 데이터를 저장하기 위해 IndexedDB를 사용한다. - IndexedDB는 다음 요구사항에 적합하다. - 많은 양의 데이터 저장 - 데이터를 작은 단위로 나누어 저장 - 인덱스를 통한 빠른 접근 - 트랜잭션을 통한 데이터 무결성 보장 - pending changes는 파일별, 노드 또는 레이어별 속성 변경 집합으로 저장된다. - 노드 단위의 세분화는 저장 공간과 불필요한 입출력 사이의 균형을 맞춘다. - 변경 사항을 지나치게 잘게 나누면 각 레코드의 관리 오버헤드가 커진다. - 반대로 모든 노드의 변경 사항을 하나의 객체에 넣으면 일부 변경만 발생해도 전체 변경 집합을 다시 기록해야 하므로 불필요한 I/O가 증가한다. ## 실용적인 결론 대용량 실시간 협업 애플리케이션의 오토세이브는 전체 상태를 반복 저장하기보다 변경 로그나 delta를 안정적으로 보관하는 방식이 효과적이다. 특히 저장 데이터의 단위, 트랜잭션 처리, 최신 서버 상태에 변경분을 재적용하는 복구 절차를 함께 설계해야 성능 저하와 협업 데이터 덮어쓰기를 모두 줄일 수 있다.

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

JavaScriptwebassemblyautosaveindexeddb+3

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

킴벌리클라크가 사랑

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

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

팀으로 배우고 실패하기 |

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

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

Figma디자인 시스템접근성remote-collaboration+3

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

피그마의 첫 번째 학생

팬데믹으로 학생들의 캠퍼스 활동이 어려워지자 Figma는 지역별 온캠퍼스 프로그램 대신, 온라인에서도 확장 가능한 학생 지원 모델을 실험했다. 학생들을 프로그램 설계와 실행에 직접 참여시킨 결과, 10주 만에 수업 템플릿·학생 콘텐츠·Virtual Campus 커뮤니티·온라인 메이커톤 등을 만들며 큰 성과를 거뒀다. 이 펠로십은 단기 결과물뿐 아니라 향후 학생 앰배서더 및 커뮤니티 프로그램의 기반도 마련했다. ## 팬데믹에 맞춘 프로그램 방향 전환 - 처음에는 학생들을 위한 캠퍼스 내 밋업을 핵심 활동으로 계획했다. - 그러나 가을 학기에 많은 학생이 캠퍼스로 돌아가지 못할 가능성이 커지면서 계획을 재검토했다. - 학생들과 대화하며 다음과 같은 문제를 파악했다. - 가을 학기의 학교 운영 방식은 어떻게 달라지는가? - 온라인 수업에서 협업적인 교실 분위기를 어떻게 재현할 수 있는가? - 학생들이 교외 프로젝트를 함께 진행하려면 어떤 환경이 필요한가? - 이를 바탕으로 다음 네 가지 영역에 집중했다. - 수업용 리소스 - 학생들의 경험과 관점을 담은 콘텐츠 - Virtual Campus Slack 커뮤니티 - 온라인 해커톤 및 메이커톤 ## 학생이 직접 설계한 펠로십 - Figma는 학생들이 실제로 유용하고 즐겁게 사용할 수 있는 것을 직접 만들도록 프로그램에 참여시켰다. - 목표는 단순히 콘텐츠를 출시하는 것이 아니라 학생 커뮤니티에 장기적으로 영향을 줄 수 있는 협업 방식을 구축하는 것이었다. - 학생 커뮤니티뿐 아니라 Figma 내부 구성원과 더 넓은 디자인 생태계까지 연결하는 것을 지향했다. - 결과물은 학생들이 쉽게 접근할 수 있으면서도 성장 의욕을 자극하는 수준을 목표로 했다. - 여러 작업 흐름으로 나뉘어 일했지만, 참가자들은 하나의 cohesive한 팀으로 협력했다. ## 교실용 템플릿과 학습 자료 - 10주 동안 온라인 및 오프라인 수업에서 활용할 수 있는 템플릿 6개를 제작했다. - 대표적인 자료는 다음과 같다. - 리서치 프로젝트를 운영하기 위한 툴박스 - Figma 에디터에 익숙해지기 위한 플레이그라운드 파일 - 수업 과제를 배포하기 위한 템플릿 - 커뮤니티 곳곳에 흩어진 Figma 교육 자료도 선별해 교사와 학생이 학습·제작에 활용할 수 있도록 정리했다. - 특정 학교나 지역에 한정되지 않고 다양한 교실에서 사용할 수 있도록 범용성을 고려했다. ## 학생들의 현실적인 고민을 다룬 콘텐츠 - 학생들과 대화하면서 많은 학생이 “갭 이어를 선택해야 하는가?”라는 고민을 공유하고 있음을 발견했다. - 이에 따라 ‘Back To School?’ 영상 시리즈를 제작했다. - Figma CEO 딜런 필드가 마크 앤드리슨, 메이리 코, 칼리 클로스, 존 마에다, 로라 데밍 등을 인터뷰했다. - 인터뷰에서는 갭 이어의 의미와 교육의 가치, 각자의 진로 경험을 다양한 관점에서 다뤘다. - 학생 펠로우 Abigail Africa는 청중 분석, 자신감 있는 발표, 스토리텔링을 중심으로 피칭과 프레젠테이션 방법을 소개했다. ## Virtual Campus와 온라인 커뮤니티 - 여름 동안 1,000명 이상의 학생이 Slack 기반 Virtual Campus에 새로 참여했다. - 커뮤니티의 목적은 학생들이 서로 연결되고, 가르치고, 배우며 함께 즐길 수 있는 공간을 제공하는 것이었다. - 물리적인 캠퍼스를 이용할 수 없는 상황에서 온라인 커뮤니티가 소속감과 협업을 보완하는 역할을 했다. - 다양한 시간대의 학생 수백 명이 참여한 2일간의 온라인 메이커톤 ‘Camp Figma’도 개최했다. - 참가자들은 함께 제작 활동을 진행했으며, FigmAdventure와 Slice 같은 프로젝트가 우수작으로 선정됐다. ## 프로그램의 성과와 확장 가능성 - 이 프로그램은 학생 대상 지원을 단순한 교육 자료 제공에서 커뮤니티·콘텐츠·협업 경험을 포함한 종합적인 모델로 확장했다. - 학생들이 수혜자에 머무르지 않고 직접 문제를 정의하고 해결책을 제작했다는 점이 특징이다. - Figma는 이번 실험을 바탕으로 향후 펠로십 프로그램을 발전시키고, 캠퍼스 앰배서더 및 Friends of Figma와 연계할 기반을 마련했다. - 지역적 오프라인 활동이 어려운 상황에서도 온라인 리소스와 커뮤니티를 통해 더 넓은 학생층에 도달할 수 있음을 보여줬다. 학생 대상 프로그램을 만들 때는 일방적으로 콘텐츠를 제공하기보다 대상 학생을 초기 기획 단계부터 참여시키는 것이 효과적이다. 특히 재사용 가능한 템플릿, 지속적인 커뮤니티, 실제 고민을 다루는 콘텐츠를 함께 설계하면 일회성 행사를 넘어 장기적인 참여와 확장성을 확보할 수 있다.

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

Figma프로토타이핑collaborative-designslack+2