sketch-import

3 개의 포스트

figma

퀄리티 위크 동안 Figma에서 (새 탭에서 열림)

Figma는 신규 기능 개발만큼 기존 제품의 품질 개선도 중요하다고 보고, 전 직원이 일주일 동안 버그 수정에 집중하는 ‘Quality Week’를 운영했다. 이 기간에는 사소하지만 반복적으로 사용자 경험을 해치는 버그와 완성도가 낮은 기능을 집중적으로 개선했으며, 제품을 더 빠르고 안정적이며 직관적으로 만드는 데 목적이 있었다. Quality Week는 사용자 만족뿐 아니라 구성원들이 평소 다루지 않던 코드 영역을 경험하고 팀 전체의 품질 의식을 높이는 기회가 되었다. ## 전사적인 품질 개선 주간 - 2017년 초 Figma는 첫 공식 Quality Week를 시작했다. - 엔지니어와 디자이너를 포함한 전 직원이 기존 프로젝트를 잠시 멈추고 제품의 “봄맞이 청소”에 참여했다. - 대상은 치명적인 장애뿐 아니라 다음과 같은 문제였다. - 기능은 동작하지만 사용하기 불편한 버그 - 전문적인 디자인 도구의 기준에 미치지 못하는 세부 동작 - 오랜 시간 반복 사용될 때 불편함이 누적되는 작은 결함 - 디자이너는 Figma를 장시간 사용하므로 작은 오류도 반복되면서 큰 불만으로 이어질 수 있다고 판단했다. - 기능 출시를 계속하는 대신 버그 수정에 집중함으로써 제품의 속도, 안정성, 직관성을 높이려 했다. ## Quality Week 2018의 주요 개선 사항 - 2018년부터 Quality Week를 정기적인 Figma의 전통으로 만들었다. - 두 엔지니어링 팀이 협력해 다양한 버그를 폭넓게 처리하고, 특히 전문 디자인 도구로서 문제가 되는 기능을 우선순위에 두었다. - 대표적인 개선 내용은 다음과 같다. - **Figma Mirror**: 모바일에서 디자인을 확인하는 미러링 앱의 안정성을 높이고 충돌을 줄였다. - **Sketch 가져오기**: Sketch 파일을 편집기 창으로 직접 드래그 앤 드롭할 수 있게 했으며, 텍스트 객체의 변환 정확도를 개선했다. - **Chromebook 지원**: 검색 키와 드래그를 조합해 객체를 복제할 수 있도록 해 학생 등 Chromebook 사용자의 편의성을 높였다. - **레이어 패널**: 레이어를 이동할 때 그룹과 프레임 안에 더 자연스럽게 중첩되도록 동작을 개선했다. - 모든 버그를 해결한 것은 아니며, Quality Week는 연중 진행되는 일반적인 버그 수정과 별도로 집중적인 개선 시간을 확보하는 방식이다. ## 오래된 버그를 해결하는 조직적 가치 - Quality Week의 효과는 사용자에게 제공되는 수정 사항에만 국한되지 않았다. - 개발자와 디자이너가 평소 담당하지 않던 코드베이스와 기능 영역을 살펴볼 수 있었다. - 이를 통해 구성원들이 제품 전체 구조를 더 폭넓게 이해하고 협업할 기회를 얻었다. - 2015년부터 Windows 사용자에게 영향을 주던 오래된 버그가 해결되었고, 이를 기념해 ‘가장 오래된 버그’ 상을 수여했다. - 버그 수정 과정을 행사와 시상식으로 즐겁게 만들어, 반복적이고 비 glamour한 작업에도 성취감을 부여했다. ## 사용자 피드백을 품질 개선에 활용 - 수정된 버그 중 상당수는 Figma 커뮤니티가 제보한 문제에서 비롯되었다. - 사용자는 제품 내부의 도움말 메뉴에서 **Contact Us**를 선택하거나 Twitter, 커뮤니티 포럼, 이메일을 통해 피드백을 보낼 수 있었다. - Figma는 지원팀만이 아니라 엔지니어, 경우에 따라 CEO까지 직접 사용자 지원에 참여하는 ‘전사적 지원’ 문화를 강조했다. - 이는 실제 사용 환경에서 발견되는 문제를 개발팀이 빠르게 이해하고 제품 개선에 반영하는 기반이 되었다. ## 실용적인 결론 신규 기능 출시와 기술 부채·버그 정리는 균형 있게 운영해야 한다. 정기적으로 전사 또는 팀 단위의 집중 품질 개선 기간을 마련하고, 오래된 버그와 반복적인 사용성 문제를 사용자 피드백에 따라 우선 처리하면 제품 완성도와 팀의 코드베이스 이해도를 함께 높일 수 있다.

figma

피그마 페이지를 소개합니다 (새 탭에서 열림)

Figma Pages는 하나의 파일 안에서 브레인스토밍, 와이어프레임, 최종 디자인 등을 여러 페이지로 나누어 관리할 수 있게 해주는 기능이다. 디자인 단계나 플랫폼별 작업을 분리하면서도 파일을 벗어나지 않고 탐색·편집할 수 있어 정리와 협업이 쉬워진다. 다만 페이지를 버전 관리 용도로 사용해 대형 파일을 반복 복제하면 성능이 저하될 수 있으므로, 버전 관리는 별도의 Version History를 사용해야 한다. ### 디자인 단계를 분리하는 페이지 구성 - 브레인스토밍, 와이어프레이밍, 픽셀 단위의 최종 작업을 각각 다른 페이지에 배치할 수 있다. - 초기 단계의 자유로운 스케치와 최종 결과물을 분리해 파일 내 혼란을 줄인다. - 여러 작업 단계를 하나의 파일에서 관리하므로 문서를 오가며 작업할 필요가 없다. ### 플랫폼과 요소별 분류 - 모바일 앱을 제작할 때 iOS 화면과 Android 화면을 별도 페이지에 구성할 수 있다. - 복잡한 인터페이스에서는 공유 컴포넌트, 아이콘 등 특정 요소를 별도 페이지에 모아 관리할 수 있다. - 하나의 파일에서 여러 프로토타입을 제작해야 할 때 프로토타입별로 페이지를 나눌 수 있다. ### 페이지 관리 방식 - 디자인 파일의 왼쪽 패널에서 페이지를 추가·전환·삭제할 수 있다. - 페이지 메뉴는 조작이 끝나면 자동으로 접히며, 패널을 Control-click하면 열린 상태로 고정할 수 있다. - 컴포넌트를 다른 페이지로 옮기려면 마우스 오른쪽 버튼을 클릭한 뒤 **Move to Page**를 선택하면 된다. - Sketch 파일을 가져올 때는 Sketch에서 구성한 페이지와 심볼 구조가 Figma에도 동일한 방식으로 import된다. - 페이지 수에는 제한이 없다. ### 썸네일과 파일 탐색 - 브라우저에서 파일을 쉽게 훑어볼 수 있도록 대표 썸네일에 사용할 페이지를 설정할 수 있다. - 왼쪽 패널에서 원하는 페이지를 첫 번째에 배치하면 해당 페이지가 파일 썸네일에 활용된다. ### 공유 시 개인정보와 접근 범위 - 특정 페이지만 공유하더라도, 공유받은 사람은 그 페이지가 포함된 파일의 나머지 내용도 볼 수 있다. - 따라서 페이지를 보안 경계나 접근 권한 분리 수단으로 사용해서는 안 된다. - 민감한 디자인을 분리해야 한다면 별도의 Figma 파일을 만들어야 한다. ### 버전 관리와 성능 주의사항 - 페이지를 버전 관리 목적으로 추가로 만드는 것은 권장되지 않는다. - Figma에는 별도의 Version History 기능이 있으므로 이전 버전 확인과 복원에는 이를 사용해야 한다. - 큰 디자인 파일을 여러 페이지에 반복 복제하면 파일 용량과 렌더링 부담이 커져 성능이 저하될 수 있다. 실무에서는 페이지를 작업 단계, 플랫폼, 디자인 요소, 프로토타입 단위로 나누고, 접근 권한 분리와 버전 관리는 각각 별도 파일과 Version History로 처리하는 것이 적절하다.

figma

피그마의 첫 (새 탭에서 열림)

Figma는 브라우저에서 복잡한 그래픽을 빠르게 처리하면서도 여러 사용자가 동시에 작업할 수 있는 디자인 도구를 만들겠다는 목표로 첫해를 보냈다. 초기에는 “장난감”이라는 평가와 기술적 한계에 대한 의심이 있었지만, 멀티플레이어 편집과 컴포넌트·디자인 시스템 기능을 통해 협업 도구로서의 가치를 입증했다. 또한 성능 개선과 Sketch 가져오기 기능을 강화하며 기존 디자인 워크플로에 쉽게 편입되는 제품으로 발전했다. ## 브라우저 기반 디자인 도구의 도전 - 웹 브라우저에서 복잡한 그래픽을 렌더링하면서도 높은 성능을 유지해야 했다. - 기존 디자인 도구에 익숙한 디자이너들이 새로운 협업 방식을 신뢰하도록 설득해야 했다. - 초기에는 Figma를 실제 업무용 도구가 아닌 “장난감”으로 보는 시선이 있었다. - Figma는 디자이너, 엔지니어, 제품 관리자와 대화하며 규모가 커지는 팀의 요구를 파악했다. ## 빠른 제품 개선과 성능 투자 - 출시 후 작업 흐름을 단순화하고 제품 완성도를 높이기 위해 수많은 기능과 업데이트를 배포했다. - 파일 로딩과 그래픽 렌더링 속도를 높이는 데 상당한 엔지니어링 자원을 투입했다. - Sketch 파일을 Figma로 가져오는 기능을 지속적으로 개선해 사용자가 기존 작업물을 처음부터 다시 만들지 않도록 했다. - 업데이트가 매우 빠르게 진행되어 사용자가 모든 변화를 따라가기 어려울 정도였으며, 첫해를 기념해 주요 발전 사항을 한곳에 정리했다. ## 실시간 협업과 단일 진실 공급원 - 2016년 9월 28일 멀티플레이어 편집 기능을 공개했다. - 디자인 도구에서 여러 사람이 동시에 편집하는 방식은 당시 새로운 개념이었고, 디자이너들 사이에서도 찬반 논쟁이 있었다. - 실제 사용 사례로는 다음과 같은 협업이 가능해졌다. - 촉박한 일정 안에서 여러 디자이너가 함께 제품을 완성 - 세계 각지의 예비 디자이너 멘토링 - 더욱 효율적인 디자인 리뷰와 비평 - 멀티플레이어의 가장 큰 장점은 단순한 동시 편집이 아니라 팀의 **단일 진실 공급원(single source of truth)** 을 제공하는 데 있다. - 하나의 URL로 디자인을 공유할 수 있고, 파일이 수정되어도 URL은 유지된다. - 이에 따라 파일을 복사하거나 최신 버전을 확인하고 디자인 자산을 동기화하는 복잡한 과정이 줄어든다. - 카피라이터는 디자인 안에서 문구를 직접 시험할 수 있고, 개발자는 디자인 속성을 확인해 코드로 옮길 수 있으며, 제품 관리자는 별도 메시지 없이 프로젝트 상태를 파악할 수 있다. - 여러 사람이 오래된 파일을 사용하거나 서로의 작업을 덮어쓰는 문제도 줄어든다. ## 컴포넌트와 확장 가능한 디자인 시스템 - 2016년 12월 8일 컴포넌트 기능을 출시했다. - 제품이 커질수록 상태 표시줄, 내비게이션 메뉴, 아이콘처럼 반복되는 UI 요소를 여러 파일과 팀원 사이에서 일관되게 관리해야 한다. - 컴포넌트를 사용하면 기본 요소를 수정했을 때 관련 디자인에 변경 사항을 일관되게 반영할 수 있다. - 디자이너가 모든 화면을 수동으로 찾아 업데이트해야 하는 부담을 줄여 준다. - **컴포넌트 오버라이드**를 통해 개별 인스턴스의 색상이나 텍스트 폰트 등 특정 속성만 바꿀 수 있다. - 개별 화면에 필요한 차이를 허용하면서도 전체 디자인 시스템과의 연결은 유지할 수 있다. - 2017년 2월 15일에는 여러 파일과 팀에서 컴포넌트를 공유하기 위한 Team Library 베타를 공개했다. ## 실용적인 결론 Figma의 첫해 성장은 단순히 기능을 많이 추가한 결과가 아니라, 디자인 파일을 팀 전체가 함께 사용하는 중앙 작업 공간으로 바꾼 데서 비롯됐다. 협업이 중요한 팀이라면 실시간 편집뿐 아니라 공유 URL, 최신 버전 유지, 컴포넌트 재사용, 기존 Sketch 자산의 이전 가능성까지 함께 고려하는 것이 Figma식 워크플로의 핵심이다.