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

플러그인으로 사용자와 팀

Figma 플러그인은 반복적이고 팀별로 특수한 작업을 자동화해 디자이너의 생산성과 협업 품질을 높일 수 있다. 공개 플러그인을 사용하는 것만으로 해결되지 않는 문제라면, 제품·컴포넌트·스타일에 맞춘 맞춤형 플러그인을 직접 만드는 것이 효과적이다. GitHub, Atlassian, Uber의 사례는 작은 유틸리티에서 출발해 팀 전체의 통합 도구로 발전시키는 방법을 보여준다. ## 반복 작업을 줄이는 맞춤형 플러그인 - 공개 플러그인이 400개 이상 제공되더라도 특정 조직의 컴포넌트나 디자인 시스템에 맞는 기능은 직접 만들어야 할 수 있다. - 플러그인 개발의 좋은 출발점은 반복적이고 번거로우며 실수하기 쉬운 작업을 발견하는 것이다. - 처음에는 작은 유틸리티로 시작한 뒤, 팀의 여러 요구를 하나의 플러그인으로 통합할 수 있다. ## GitHub: 컴포넌트 관리와 테마 전환 자동화 ### 레이어 테두리 제어 - GitHub는 다양한 위치와 크기의 구분선을 하나의 리스트 아이템 컴포넌트 안에서 관리했다. - 여러 변형 컴포넌트를 따로 유지하는 대신, 플러그인이 필요한 레이어 조합의 표시 여부를 자동으로 전환했다. - 그 결과 컴포넌트 수와 유지보수 부담을 줄일 수 있었다. ### 색상 테마 관리 - 모바일 앱에서 라이트 테마, 다크 테마, 고대비 모드를 지원하기 위해 네 가지 색상 세트를 관리해야 했다. - 플러그인은 기능적 이름으로 지정된 스타일을 검색하고 관리하도록 도왔다. - 전체 디자인을 몇 번의 클릭만으로 다른 테마로 전환할 수 있게 했다. ### 실제 데이터 삽입 - 정확한 목업과 디자인 스트레스 테스트를 위해 API에서 실제 데이터를 가져오는 데이터 채우기 플러그인을 만들었다. - 무작위 데이터 샘플을 가져와 아바타, 사용자명, 이름 등을 컴포넌트의 레이어 이름에 맞춰 자동 매핑했다. - 이후 테두리, 테마, 데이터 삽입 기능을 하나의 ‘모노 플러그인’으로 통합해 팀원들이 단일 UI에서 여러 기능을 사용할 수 있게 했다. ## Atlassian: 제품에 맞는 콘텐츠와 가상 사용자 이미지 - 일반적인 더미 텍스트가 아니라 제품별로 서로 연결된 데이터를 생성하기 위해 ADG Data Generator를 개발했다. - Jira에서는 프로젝트명과 티켓 번호, Bitbucket에서는 브랜치명과 커밋 메시지처럼 작업 중인 제품에 맞는 콘텐츠를 제공했다. - 실제 인물 사진 대신 실제로 존재하지 않는 사람을 표현하는 AI 생성 이미지를 사용해 개인정보나 이미지 라이선스 문제를 줄였다. - Atlassian은 이 플러그인의 소스 코드를 공개해 유사한 도구를 만들려는 커뮤니티가 참고할 수 있도록 했다. ## Uber: 협업과 디자인 검증 지원 - Uber에서는 여러 플러그인을 만들어 협업을 강화하고 디자인 불일치를 줄이며 작업 속도를 높였다. - 모바일 디자인 리뷰를 위해 선택한 Figma 프레임을 URL과 QR 코드로 기기에 미러링하는 플러그인을 개발했다. - 리뷰 참가자들이 대형 화면을 함께 보는 대신 각자의 스마트폰에서 디자인을 직접 확인할 수 있어, 실제 사용 환경에 가까운 피드백을 제공할 수 있었다. - Uber 사례는 플러그인이 단순한 제작 자동화뿐 아니라 디자인 크리틱과 협업 방식 자체도 개선할 수 있음을 보여준다. ## 플러그인 개발 기회를 찾는 방법 - 자주 반복하는 수작업을 목록으로 만들고, 클릭·검색·레이어 전환이 많은 작업부터 자동화한다. - 팀의 제품 데이터나 디자인 시스템처럼 일반 플러그인이 알기 어려운 내부 맥락을 활용한다. - 하나의 거대한 도구를 처음부터 만들기보다 작은 기능을 검증한 후 관련 기능을 통합한다. - 팀 전체가 사용할 경우 설치와 실행 과정을 단순화하고, 하나의 통합 UI로 제공하는 것이 좋다. 실무에서는 “반복적으로 시간을 빼앗기지만 규칙이 명확한 작업”부터 플러그인화하는 것이 가장 효율적이다. 특히 테마 전환, 콘텐츠 생성, 컴포넌트 상태 변경, 실제 기기 검토처럼 오류가 발생하기 쉬운 작업이 좋은 대상이다.

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

디자인 시스템접근성figma-pluginsapi-integration+3

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

디자인 결정에 확신을

디자인 의사결정의 자신감은 타고나는 확신이 아니라 데이터와 경험을 쌓으며 형성된다. 디자이너는 복잡한 정보, 개인의 직관, 이해관계자의 서로 다른 관점을 조율해야 하므로 내면의 불안과 외부에 보여주는 확신 사이에서 갈등하기 쉽다. 이 글은 과거의 두려움을 돌아보고, 필요한 정보를 수집하며, 반복적인 실천을 통해 자신감을 키우는 방법을 제안한다. ## ‘자신감의 역설’ 이해하기 - 디자이너는 “내가 해결할 수 있다”는 태도를 보여야 하지만, 동시에 “정말 할 수 있을까?”라는 내적 의심을 경험한다. - 디자인 결정에는 다음 요소가 복합적으로 작용한다. - 개인과 팀의 경험 - 사용자 및 시장 데이터 - 프로젝트 목표와 동기 - 개인적 취향과 직관 - 서로 다른 이해관계자의 관점 - 모든 상황을 통제할 수는 없지만, 자신의 머릿속에서 문제를 해석하는 방식과 의사결정에 대한 서사는 통제할 수 있다. - 저자는 동료들과 소규모 그룹으로 관련 활동을 진행하면 서로의 경험을 이해하고 공감할 수 있어 효과적이라고 말한다. ## 과거의 두려움에서 자신감의 패턴 찾기 - 특정 기술이나 활동에 자신이 없었던 어린 시절의 경험을 떠올린다. - 당시 어떤 점이 두려웠는지, 자신감을 얻기 위해 어떤 행동을 했는지 기록한다. - 다른 사람들과 경험을 공유하면 자신감이 형성되는 과정이 개인의 능력 부족이 아니라 연습과 지원의 결과였음을 이해할 수 있다. - 글의 사례에서는 다음과 같은 방법이 사용됐다. - 소리 내어 읽는 연습을 반복하고 가족에게 교정을 받음 - 수영 수업에 등록하고 장비와 주변의 도움을 활용함 - 초기에는 외부의 도움에 의존하더라도, 반복적인 참여를 통해 점차 독립성과 자신감을 얻을 수 있다. ## 데이터와 검증으로 불확실성 줄이기 - 자신감이 부족한 이유가 정보 부족이라면 데이터를 더 수집해야 한다. - 유용한 정보의 출처는 다음과 같다. - 사용자와 문제를 직접 경험하는 사람 - 유사한 문제를 해결한 동료 - 팀원과 이해관계자 - 리서치, 검증 결과, 제품 사례 - 충분한 정보를 모으면 문제의 변수와 제약 조건을 더 명확히 파악할 수 있다. - 디자인 결정에 대한 확신은 단순한 개인 취향이 아니라, 문제를 구성하는 여러 요소를 이해하고 의미 있는 결론을 도출하는 데서 나온다. - 동료나 사용자에게 질문하고 피드백을 받는 과정은 디자인 판단을 객관화하는 데 도움이 된다. ## 반복적인 경험으로 실천적 자신감 만들기 - 자신감은 때로 시간이 지나야 형성되며, 단기간에 얻을 수 없는 경우도 있다. - 두려운 일을 반복해서 수행하면 익숙함이 생기고, 익숙함이 자신감으로 발전한다. - 경험의 축적 과정은 직선적이지 않다. - 비슷한 문제를 다시 해결할 때마다 과거 경험을 새로운 맥락에 맞게 적용한다. - 성공과 실패의 결과가 쌓이면서 자신만의 판단 기준이 만들어진다. - 과거 결정의 결과와 감정적으로 연결될수록 자신의 판단에 대한 신뢰가 강해진다. - 예를 들어 직접 보고를 주는 일이 두렵더라도, 필요한 피드백을 계속 전달하는 연습을 해야 점차 자연스러워진다. ## 현재의 자신감 문제 진단하기 - 자신감이 부족한 영역을 구체적으로 정한다. - 취미 - 디자인 프로젝트 - 디자인 기술 - 리더십이나 피드백 - 현재 문제의 원인이 데이터 부족인지, 경험 부족인지 구분한다. - 데이터가 부족하다면 리서치, 사례 조사, 질문, 피드백을 우선한다. - 경험이 부족하다면 작은 규모로 시작해 반복적으로 실행한다. - 실제로는 데이터와 경험이 모두 필요한 경우가 많으므로 두 가지를 함께 활용해야 한다. 두려운 결정을 피하기보다 필요한 정보를 수집하고 작은 실행을 반복하는 것이 가장 현실적인 자신감 형성 방법이다. 팀에서는 개인의 불안을 숨기기보다 동료들과 공유하고, 피드백과 연습을 통해 “확신 있는 태도”를 실제 역량으로 바꿔가는 것이 좋다.

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

프로덕트 디자인design-thinkinguser-researchdata-driven-design+2

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

창의적인 문화를 구축

문화는 추상적인 분위기가 아니라, 팀이 공유하는 믿음을 실제 행동으로 옮기는 방식이다. Dropbox는 창의적인 팀이 문화를 자연스럽게 방치하기보다 의도적으로 설계해야 혁신과 실행력을 높일 수 있다고 설명한다. 이를 위해 개인의 가치관을 발견하고, 공동의 가치와 행동 규칙을 정한 뒤, 습관으로 정착시키고 반복적으로 개선하는 접근을 제안한다. ## 문화의 의미와 중요성 - 문화는 개인이나 조직이 가진 믿음이 행동으로 나타나는 방식이다. - 회사 전체뿐 아니라 조직, 팀, 프로젝트 그룹에도 각자의 하위 문화가 형성될 수 있다. - 문화는 의도적으로 관리하지 않아도 자연스럽게 생기므로, 방치하면 특정 구성원이나 기존의 지배적 사고방식만 반영될 수 있다. - 건강한 문화는 소속감과 직원 만족도를 높이고, 인재 확보와 제품 출시 속도, 비즈니스 성과에도 영향을 준다. - 창의적인 팀일수록 혁신과 협업을 위해 문화를 의도적으로 설계할 필요가 있다. ## 개인의 믿음과 가치관 정의 - 팀원들이 자신의 업무 경험과 그 과정에서 중요하게 느낀 가치를 공유한다. - 각자의 이야기를 통해 개인이 중요하게 생각하는 원칙과 신념을 구체화한다. - 모든 구성원이 발언할 기회를 가져야 하며, 리더가 일방적으로 문화를 결정하지 않도록 한다. - 이 단계는 팀 문화를 포용적으로 시작하기 위한 기반이 된다. ## 공동의 가치 합의 - 팀원들이 제시한 다양한 표현에서 반복되는 주제와 공통점을 찾는다. - 예를 들어 ‘팀워크’, ‘파트너십’, ‘명확한 목표’가 반복되면 이를 ‘협업’이라는 하나의 가치로 묶을 수 있다. - 합의한 가치가 팀의 목표와 업무 방식에 어떤 도움을 주는지 논의한다. - 필요하다면 팀의 가치를 회사 전체의 가치와 연결해 조직 차원의 방향성과 일관성을 확보한다. ## 가치를 행동으로 구체화하기 - 가치는 선언만으로는 충분하지 않으며, 실제 업무에서 관찰 가능한 행동으로 표현되어야 한다. - 갈등 상황을 해결하고, 의사결정을 내리고, 서로 협업할 때 각 가치를 어떻게 적용할지 정한다. - 예를 들어 ‘협업’을 가치로 삼았다면 피드백 요청, 정보 공유, 부서 간 논의 같은 구체적인 행동을 정의할 수 있다. - 추상적인 가치와 일상적인 업무 행동 사이의 연결을 만들어야 한다. ## 습관과 업무 규칙으로 정착 - 정한 행동을 반복하게 만드는 커뮤니케이션 방식, 회의 규칙, 프로세스를 설계한다. - 협업을 강화하려면 부서 간 정기적인 소통, 피드백 절차, 공동 의사결정 방식 등을 마련할 수 있다. - 가치-행동-강화의 반복 구조는 팀 구성원 간의 사회적 약속이 된다. - 구성원들이 실제로 경험하는 행동과 상호작용이 결국 팀 문화로 인식된다. ## 평가와 반복적인 개선 - 새로운 문화가 자리 잡기까지 시간이 걸리므로 단기간에 결과를 판단하지 않는다. - 팀에 도움이 되는 관행은 유지하고, 효과가 없거나 부작용을 만드는 방식은 수정하거나 폐기한다. - 제품을 개선하듯 문화의 성공 기준도 정해야 한다. 예를 들어 협업 만족도, 피드백의 질, 의사결정 속도 등을 점검할 수 있다. - 분기별 오프사이트나 정기 회고 때 문화의 가치와 행동 규칙을 다시 검토하는 것이 좋다. ## 문화의 실제 적용 - 문화는 브레인스토밍, 기능 개발, 콘텐츠 제작, 피드백 등 팀의 모든 활동에 영향을 준다. - 팀이 선언한 가치를 실제 행동으로 실천해야 구성원들이 문화를 신뢰할 수 있다. - Dropbox는 이러한 과정을 실행할 수 있도록 개인의 가치 정의부터 평가와 개선까지 포함한 Team Values Toolkit을 제공한다. 팀 문화를 만들 때는 멋진 가치 문구를 정하는 데 그치지 말고, 구성원의 경험에서 출발해 구체적인 행동과 습관으로 연결하는 것이 중요하다. 이후 정기적으로 효과를 점검하고 개선하면 생산성, 창의성, 협업 관계를 함께 강화할 수 있다.

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

Figmateam-collaborationdesign-processdropbox+1

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

Config: 피그마의 첫 번째

Figma의 첫 사용자 컨퍼런스 Config는 1,000명 이상이 모여 배우고 교류하는 커뮤니티 중심의 행사로 기획됐다. Figma는 정해진 의제를 일방적으로 전달하기보다 참가자들의 제안과 참여를 바탕으로 행사를 구성했으며, 디자인을 공개적으로 공유하고 함께 발전시키는 “오픈 디자인”을 핵심 주제로 다뤘다. 기술은 사람을 고립시키는 도구가 아니라 공동체와 더 깊이 연결하는 수단으로 활용해야 한다는 메시지도 강조됐다. ## 커뮤니티가 직접 만든 컨퍼런스 - Config의 목표는 사용자 커뮤니티를 물리적인 공간으로 구현해 의미 있는 대화를 나누는 것이었다. - 팀 문화, 멘토링, 디자인 윤리 같은 주제를 중심으로 참가자들이 서로 배우고 경험을 공유하도록 했다. - Figma 직원이 사용자들의 목소리를 직접 듣고, 사용자들이 서로 만날 수 있는 기회를 마련했다. - 워크숍, 라이트닝 토크, 라운드테이블의 상당수가 참가자들의 제안으로 구성됐다. - 단순히 발표를 듣는 행사가 아니라, 참가자들이 직접 기여하는 공동 토론의 장을 지향했다. - 현장 참석자뿐 아니라 온라인 참가자도 세션 녹화 영상을 통해 행사에 참여할 수 있도록 했다. ## 오픈 디자인과 협업 - 컨퍼런스의 중심 주제는 디자인 분야에서의 “오픈하게 만들기(open design)”였다. - 엔지니어링의 오픈소스 문화처럼 디자인 결과물을 공유하고, 다른 사람이 이를 수정·재사용·확장하는 방식을 강조했다. - Devon Zuegel은 오픈소스의 원리가 디지털 제품을 넘어 도시 계획과 물리적 인프라에도 적용될 수 있다고 설명했다. - Jason Kunesh는 시카고 디자인팀의 자원이 부족한 상황에서 학생들이 팀의 확장된 구성원으로 참여해 디자인 시스템을 구축한 사례를 소개했다. - Miguel Solorio는 Microsoft가 커뮤니티를 디자인 과정에 참여시켜 제품 개발에 사용자 의견을 반영한 경험을 공유했다. - 이를 통해 디자인은 소수의 전문가가 완성하는 결과물이 아니라, 더 넓은 공동체가 함께 만드는 과정이라는 관점을 제시했다. ## 기술과 공동체의 관계 - Craig Mod는 스마트폰과 같은 기술이 사람을 원하는 장소로 순간 이동시키는 것처럼 작동해, 주변 사람들과의 관계를 단절시킬 수도 있다고 지적했다. - 기술을 현실에서 도피하는 수단으로 사용하기보다, 주변 사람들과 더 깊이 연결하는 방식으로 활용해야 한다고 강조했다. - 커뮤니티는 단순히 온라인에서 모인 사용자의 집합이 아니라, 서로 돌보고 참여하며 공동의 가치를 만들어가는 관계망으로 확장됐다. ## 기존 질서에 도전하는 태도 - May-Li Khoe는 자신이 중요하게 생각하는 공동체를 지원하면서도 기존의 규범과 현상 유지를 즐겁게 뒤집는 방법을 공유했다. - 참가자들에게 각자의 커뮤니티를 위해 어떤 변화를 만들 수 있을지 고민하도록 독려했다. - 이는 디자인 실무를 넘어 조직문화, 사회적 책임, 공동체 참여에까지 디자인의 역할을 확장하는 메시지였다. ## 실용적인 시사점 Config의 사례는 사용자 행사를 성공시키려면 일방적인 제품 발표보다 참가자들이 직접 의제와 콘텐츠를 만들 수 있는 구조가 중요하다는 점을 보여준다. 또한 디자인 조직은 결과물을 폐쇄적으로 관리하기보다 지식과 작업물을 공유하고, 사용자·학생·지역사회 등 다양한 사람을 설계 과정에 참여시키는 방식을 고려할 수 있다.

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

Figma디자인 시스템오픈 소스design-tools+2

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

더 개방적으로 창작하고 협

Figma는 Config 2020에서 디자인 제작, 협업, 커뮤니티 공유를 강화하는 7가지 기능을 발표했다. 반복 작업을 줄이고 반응형 디자인과 고품질 프로토타이핑을 지원하는 한편, 제품팀 간 맥락 공유와 외부 커뮤니티의 학습·재사용을 확대하는 것이 핵심이다. 이러한 기능의 기반으로 안정적이고 성능이 뛰어난 플랫폼에 대한 지속적인 투자도 강조했다. ## 2020년 Figma의 세 가지 방향 - **제작(Creation):** 반복적인 디자인 작업을 자동화해 더 빠르고 효율적으로 제작하도록 지원한다. - **협업(Collaboration):** 디자이너뿐 아니라 제품 개발에 참여하는 모든 구성원이 함께 작업할 수 있도록 한다. - **커뮤니티(Community):** 디자인 파일을 공개하고 서로 공유·학습·재사용할 수 있는 생태계를 만든다. - 위 기능들을 뒷받침하기 위해 안정성과 성능을 지속적으로 개선한다. ## Auto Layout 강화 - 컨테이너 크기에 맞춰 늘어나는 반응형 컴포넌트를 만들 수 있다. - 텍스트 길이에 따라 자동으로 크기가 바뀌는 버튼을 제작할 수 있다. - 리스트 항목을 쉽게 재배치할 수 있다. - 여러 디바이스 유형에 대응하는 디자인을 만드는 데 유용하다. ## 더 효율적인 글꼴 및 색상 관리 - 새 **Font Picker**는 자주 사용하는 글꼴, 조직에서 공유한 글꼴, 즐겨찾기 글꼴을 우선 표시한다. - 수많은 글꼴 중 원하는 글꼴을 빠르게 검색할 수 있다. - 현재 파일에서 사용된 모든 글꼴을 확인해 디자인 전반의 일관성을 점검할 수 있다. - **Selection Colors**를 사용하면 여러 객체의 채우기, 선, 텍스트 색상을 한 번에 변경할 수 있다. - 색상 속성을 개별적으로 조정하거나 동일한 색상으로 일괄 통일할 수 있다. ## 키보드와 게임패드를 지원하는 프로토타이핑 - 키보드, 게임패드, 접근성 컨트롤러를 프로토타입 상호작용의 트리거로 사용할 수 있다. - `Cmd + F`와 같은 애플리케이션 단축키를 시뮬레이션할 수 있다. - 게임 메뉴의 방향키 조작처럼 게임패드 기반 인터랙션도 표현할 수 있다. - 다양한 입력 장치를 사용하는 고충실도 프로토타입 제작을 지원한다. ## 링크를 통한 협업 맥락 보존 - 텍스트에 웹페이지 링크를 삽입할 수 있다. - Figma 파일 내부의 특정 페이지나 에디터의 특정 프레임으로 연결할 수 있다. - 제품 요구사항 문서 등 외부 자료를 직접 연결할 수 있다. - 클릭 가능한 목차를 만들어 대규모 파일에서 협업자가 원하는 화면으로 빠르게 이동하도록 할 수 있다. ## Plugin Inspector API - 플러그인이 속성 패널에 주요 정보를 표시할 수 있도록 새로운 API를 제공한다. - Notepad 같은 플러그인의 작업 항목을 현재 디자인 요소와 함께 확인할 수 있다. - Mapsicle처럼 특정 플러그인으로 생성된 콘텐츠의 출처를 확인하고 쉽게 업데이트할 수 있다. - 디자인 과정에서 사용한 도구와 결과물 사이의 연결성을 높인다. ## 프로토타입만 공유하는 권한 - 디자인 원본 파일은 공개하지 않고 프로토타입만 공유할 수 있는 권한을 추가한다. - 구현 전 아이디어를 외부 이해관계자에게 보여주면서 실제 디자인 파일은 보호할 수 있다. - 해당 기능은 Figma Professional 및 Organization 요금제에 제공될 예정이라고 발표됐다. ## Figma Community를 통한 공개와 학습 - 팀이나 조직 내부를 넘어 전체 디자인 커뮤니티와 파일을 공유하는 방향을 제시했다. - 공개된 라이브 디자인 파일을 다른 사용자가 직접 살펴보고, 수정하고, 학습할 수 있다. - 커뮤니티 베타 출시 후 수개월 동안 400명 이상의 제작자가 1,000개 이상의 파일을 공개했다. - 공유된 자료에는 와이어프레임 템플릿, 아이콘 세트, 디자인 시스템 예시, 디바이스 프레임, 프레젠테이션 템플릿, 일러스트 등이 포함됐다. Figma의 발표는 단순히 디자인 편집 기능을 늘리는 데 그치지 않고, 반응형 제작 자동화, 팀 간 정보 연결, 선택적 공유, 공개 리소스 재사용을 하나의 작업 흐름으로 통합하려는 전략을 보여준다. 실무에서는 Auto Layout과 Selection Colors로 반복 작업을 줄이고, 내부 문서 링크와 프로토타입 전용 공유를 활용해 협업 효율과 보안을 함께 높이는 것이 유용하다.

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

Figma디자인 시스템프로토타이핑collaboration+3

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

새로운 Maze 연동

Figma와 Maze의 통합으로 개발 단계까지 기다리지 않고 Figma 프로토타입을 초기부터 사용자 테스트할 수 있게 되었다. Figma 프로토타입 링크를 Maze에 복사해 가져오면 실제 사용자 행동을 정량적으로 측정하고, 제품팀이 연구 결과를 공유하며 개선 방향을 논의할 수 있다. 글은 효과적인 사용자 테스트를 위해 명확한 목표 설정, 사전 검증, 다양한 사용자 모집, 중립적인 과제 설계, 공동 분석을 권장한다. ## Figma와 Maze의 통합 - Figma 프로토타입 링크를 Maze에 복사·붙여넣기만 하면 테스트를 시작할 수 있다. - 개발 환경에서 A/B 테스트를 진행할 때까지 기다리지 않고, 디자인 초기 단계에서 사용성 문제를 발견할 수 있다. - Maze는 여러 사용자 흐름에서 경험을 정량적으로 측정한다. - 소규모 1:1 인터뷰부터 최대 5만 명 규모의 테스트까지 지원한다. - Maze는 Ring, Revolut, IBM 등 기업의 사용자 리서치에 활용되고 있다. ## 테스트 전에 성공 기준 정의 - 프로토타입을 만들기 전에 테스트의 목표와 성공 조건을 정해야 한다. - 목표는 구체적이고 측정 가능해야 한다. - 예를 들어 다음과 같이 기준을 수치로 정의할 수 있다. - 참가자의 80% 이상이 과제를 성공적으로 완료 - 오클릭 비율 2% 미만 - 테스트마다 검증하려는 목표와 평가 지표가 달라질 수 있으므로, 목적에 맞는 기준을 설정해야 한다. ## 실제 테스트 전 파일럿 진행 - 대규모 사용자 테스트 전에 내부 팀원, 친구, 가족 등을 대상으로 시험 운영을 한다. - 파일럿을 통해 다음 사항을 점검할 수 있다. - 과제 설명이 명확한지 - Figma 프로토타입의 인터랙션이 정상 작동하는지 - 테스트 목표가 실제로 의미 있는지 - 예상치 못한 오류나 혼란이 발생하는지 - 제품의 베타 테스트나 점진적 출시처럼 사용자 테스트도 사전 검증 단계가 필요하다. ## 기존 사용자와 비사용자 모두 모집 - 기존 사용자는 제품에 익숙하고 새로운 기능을 적극적으로 사용해볼 가능성이 높다. - 새로운 기능을 가장 많이 채택할 고객 세그먼트를 우선적으로 테스트하면 유용한 피드백을 얻을 수 있다. - 다만 기존 사용자만 조사하면 제품 구조에 익숙한 사람에게 편향될 수 있다. - 비사용자도 함께 테스트해 처음 접하는 사람의 관점과 직관성을 확인해야 한다. ## 유도하지 않는 과제와 질문 작성 - 사용자가 특정 답이나 경로를 따라가도록 지시하는 표현을 피해야 한다. - “여기를 클릭하세요”, “Signup 버튼으로 이동하세요”, “Feed 페이지로 가세요” 같은 표현은 사용자의 자연스러운 탐색 능력을 검증하지 못하게 한다. - 과제는 내부 기능명이나 구체적인 조작법보다 사용자가 달성해야 할 최종 목표 중심으로 작성해야 한다. - 이를 통해 인터페이스가 실제로 직관적인지 확인할 수 있다. ## 팀 전체가 참여하는 결과 분석 - 사용자 테스트의 어려움은 데이터를 얻는 것뿐 아니라, 결과에 대한 조직의 공감대를 형성하고 다음 행동을 결정하는 데 있다. - 제품팀 전체가 분석 과정에 참여하면 각자 결과를 해석하고 개선 방향을 논의할 수 있다. - Maze는 즉시 생성할 수 있는 리포트와 공유용 사용자 지정 URL을 제공한다. - 연구 결과를 팀원과 쉽게 공유해 발견 사항을 실제 제품 개선으로 연결할 수 있다. 실용적으로는 작은 파일럿 테스트부터 시작해 성공 지표를 검증한 뒤, 기존 사용자와 신규 사용자를 포함한 규모 있는 테스트로 확장하는 방식이 적절하다. 테스트 과제는 조작법이 아닌 사용자의 목표를 중심으로 작성하고, 결과 분석에는 디자이너·개발자·제품 담당자가 함께 참여하는 것이 좋다.

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

Figma사용자 경험프로토타이핑user-testing+3

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

사후 분석: 202

2020년 1월 21~22일 Figma 장애는 장시간 실행된 고비용 쿼리와 PostgreSQL의 잘못된 쿼리 실행 계획, 그리고 이로 인해 누적된 공격적 autovacuum이 복합적으로 발생한 사건이었다. 1월 21일에는 문제 쿼리를 취소해 복구했지만, 그 여파로 데이터베이스 정리 작업이 밀리면서 다음 날 쓰기 IOPS와 잠금 경합이 급증했다. Figma는 PostgreSQL 11로 업그레이드해 문제를 안정화했고, 이후 고비용 쿼리 모니터링과 실행 시간 제한을 강화하기로 했다. ## 장애 발생 경과 ### 1월 21일: 장시간 실행 쿼리 - 오전 6시 11분, 자동 모니터링에서 오류율 증가를 감지했다. - 조사 결과, 데이터베이스 CPU를 과도하게 사용하는 장시간 실행 쿼리가 발견됐다. - 오전 6시 54분 해당 쿼리를 취소하자 성능이 정상으로 돌아왔다. - 그러나 쿼리 취소 과정에서 데이터베이스 내부에 정리해야 할 작업이 누적되었고, 이것이 다음 날 장애의 배경이 됐다. ### 1월 22일: 쓰기 부하와 잠금 경합 - 데이터베이스 CPU는 평소보다 낮았지만 쓰기 IOPS와 잠금 경합이 증가했다. - 오전 11시 42분에는 API 요청이 대기열에 쌓이며 일부 사용자가 서비스를 이용할 수 없게 됐다. - 불필요한 쿼리를 취소하고 할당된 IOPS를 늘려 일시적으로 안정화했지만, 오후 2시경 다시 성능이 악화됐다. - 데이터베이스를 재시작해 문제를 일으킨 것으로 추정한 백그라운드 프로세스를 임시 비활성화했다. - 오후 7시부터 긴급 점검을 진행하며 PostgreSQL을 업그레이드했고, 오후 8시 15분 서비스와 데이터베이스 지표가 정상화됐다. ## 공격적 autovacuum의 영향 - PostgreSQL의 autovacuum은 오래된 행 버전을 정리하고 트랜잭션 ID 고갈을 방지하는 자동 유지보수 작업이다. - 1월 21일 장시간 쿼리가 종료된 뒤 정리 대상 데이터가 대량으로 쌓였다. - 이 backlog가 임계치를 넘으면서 트랜잭션 ID 래핑을 막기 위한 더 공격적인 autovacuum이 실행됐다. - 당시 사용하던 PostgreSQL 버전에서는 이 작업이 테이블 잠금과 쓰기 작업에 큰 영향을 줬다. - Figma가 대형 테이블에서 실행 중인 autovacuum을 취소하자 지표가 일시적으로 개선됐지만, 작업은 다시 재개됐다. - `autovacuum_freeze_max_age` 값을 조정하고 데이터베이스를 재시작해야 공격적 autovacuum을 완전히 억제할 수 있었다. - 다만 autovacuum을 비활성화한 뒤에도 쓰기 지연과 잠금 경합이 계속되어, 이것만이 유일한 원인은 아니라고 판단했다. ## 잘못된 쿼리 실행 계획 - 문제의 핵심 쿼리는 복잡한 서브쿼리를 포함하고 있었고, 잠금 경합에 반복적으로 관여했다. - PostgreSQL 9의 통계 정보가 변경된 뒤 쿼리 플래너가 비효율적인 실행 계획을 선택한 것으로 분석됐다. - 실행 계획은 실제 결과가 3개 행뿐인데도 2천만 개 이상의 행을 반환할 것으로 잘못 추정했다. - 그 결과 인덱스를 사용하지 않고 전체 테이블 스캔을 수행했다. - 처리 과정에서 임시 버퍼에 대량의 데이터를 기록해 높은 쓰기 IOPS와 임시 데이터 사용량을 유발했다. - 즉, 낮은 CPU 사용률만으로 데이터베이스 상태가 양호하다고 판단하기 어려웠으며, 쓰기 지연·잠금·임시 버퍼 사용량을 함께 살펴야 했다. ## PostgreSQL 11 업그레이드 - PostgreSQL 9.6 이후에는 autovacuum과 관련된 중요한 최적화가 포함됐다. - PostgreSQL 10 이상에서는 Amazon RDS의 성능 분석 도구가 개선되어 원인 조사에 도움이 된다. - Figma는 이미 스테이징 환경을 PostgreSQL 11로 업그레이드하고 수개월간 테스트한 상태였다. - 운영 환경 업그레이드 절차도 사전에 마련해 두었기 때문에 긴급 상황에서도 업그레이드를 진행할 수 있었다. - PostgreSQL 11의 개선된 쿼리 플래너는 문제가 된 실행 계획이 선택될 가능성을 제거했다. - autovacuum의 성능 특성도 PostgreSQL 9에서 11로 오면서 개선되어 두 가지 주요 원인을 함께 완화했다. ## 후속 조치 - 고비용·장시간 실행 쿼리에 대한 모니터링을 강화한다. - 쿼리가 실행될 수 있는 시간에 더 엄격한 제한을 둔다. - 실행 계획의 예상 행 수와 실제 행 수 사이의 큰 차이를 지속적으로 점검한다. - CPU뿐 아니라 쓰기 IOPS, 쓰기 지연, 잠금 경합, 임시 버퍼 사용량, autovacuum backlog를 함께 모니터링해야 한다. - 데이터베이스 버전 업그레이드는 장애 발생 후 처음 검토하기보다, 스테이징 테스트와 운영 전환 계획을 미리 준비해야 한다. 실무적으로는 장시간 쿼리에 타임아웃을 설정하고, 정기적으로 `EXPLAIN ANALYZE`와 실행 계획 변화를 검토하며, autovacuum 상태를 별도 지표로 관리하는 것이 중요하다. alc-vesm.

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

PostgreSQLamazon-rdsdatabase-monitoringquery-optimization+2

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

Figma on Figma: Figma

Figma는 제품 디자인뿐 아니라 마케팅 웹사이트에도 디자인 시스템이 필요하다고 판단하고, 기존 페이지의 시각 요소와 제작 방식을 체계화했다. 반복되는 요소를 통합하고 재사용 가능한 컴포넌트와 조합형 섹션을 구축한 결과, 일관성을 유지하면서도 코드 작성 없이 아이디어에서 출시까지 하루, 실제 사례에서는 48시간 이내에 웹페이지를 만들 수 있게 되었다. ## 기존 웹사이트의 불일치와 유지보수 문제 - 페이지마다 디자이너와 개발자가 각자 새로운 해결책을 만들고 있었다. - 비슷하지만 조금씩 다른 컴포넌트가 반복되어 사용자 경험과 브랜드 인상이 일관되지 않았다. - 페이지를 수정하거나 업데이트하기 어렵고, 새로운 페이지를 만들 때마다 작업 방식이 달라졌다. - 제품 디자인 분야에서 활용되던 디자인 시스템의 장점을 마케팅·웹 디자인에도 적용할 필요가 있었다. ## 전체 요소를 조사하고 패턴을 통합 - 먼저 폰트, 글자 크기, 색상, 컬럼 너비, 레이아웃 등 기존 사이트의 시각 요소를 Figma 파일에 모았다. - 조사 과정에서 다음을 구분했다. - 여러 페이지에서 반복되는 패턴 - 한 번만 사용되어 스타일 가이드에 포함하기 어려운 예외 요소 - 서로 유사하지만 세부 스타일이 다른 요소 - 큰 UI 요소는 더 작은 단위로 분해해 조합 가능한 구조로 만들었다. - 서로 다른 제목 스타일 12개를 H1~H3, 본문, 기술 문서용 텍스트 등으로 단순화했다. - 블로그와 긴 형식의 콘텐츠에는 풀 쿼트, 블록 쿼트 같은 전용 텍스트 스타일도 추가했다. ## 원자적 요소와 유연한 컴포넌트 - 작은 요소를 조합해 다양한 페이지 구조를 만들 수 있도록 디자인 시스템을 구성했다. - 핵심 목표는 특정 페이지에만 맞는 고정된 디자인이 아니라, 여러 콘텐츠와 레이아웃에 대응하는 유연한 빌딩 블록을 만드는 것이었다. - 정리된 시각 언어를 공유 라이브러리로 제공해 Figma 브랜드에 익숙하지 않은 사람도 일관된 결과물을 만들 수 있게 했다. - 타이포그래피, 간격, 패딩, 행간, 색상, 그리드 등을 하나의 기준으로 통일했다. ## FLEGOs: 조합 가능한 대형 섹션 - Figma는 컴포넌트를 조합해 자주 함께 사용되는 요소와 완성된 섹션도 미리 만들었다. - 이러한 대형 조합 단위를 “Figma + LEGO”라는 의미의 **FLEGOs**라고 불렀다. - 디자이너는 개별 텍스트나 버튼뿐 아니라 페이지의 주요 섹션을 FLEGOs로 빠르게 구성할 수 있었다. - 작은 요소부터 완성된 섹션까지 단계적으로 재사용할 수 있어 페이지 제작의 속도와 일관성을 함께 확보했다. ## Contentful 기반의 제작 workflow - 약 한 달 동안 소규모 팀이 스타일 가이드와 컴포넌트 라이브러리를 구축했다. - 시스템은 Figma 파일에만 머무르지 않고 CMS인 Contentful에도 반영했다. - 디자인팀은 Figma에서 FLEGO를 사용해 와이어프레임을 만들고, 같은 파일에서 콘텐츠를 협업한 뒤 CMS의 컴포넌트로 실제 페이지를 구성했다. - 대부분의 핵심 마케팅 사이트가 이 프레임워크를 기반으로 제작되었다. - 새로운 페이지를 만들 때 별도의 코드 작성 없이 기존 컴포넌트를 활용할 수 있었다. ## 출시 속도 향상 - 디자인 시스템 도입 후 콘셉트에서 출시까지 하루 안에 진행할 수 있게 되었다. - ‘What’s New’ 페이지는 제품 마케터와 웹 제작자가 FLEGOs로 빠르게 와이어프레임을 만들고 콘텐츠를 작성한 사례다. - 아이디어에서 실제 웹페이지 공개까지 48시간 이내에 완료했다. - 재사용 가능한 시스템 덕분에 속도를 높이면서도 브랜드의 시각적 일관성을 유지할 수 있었다. 디자인 시스템은 제품 UI에만 필요한 도구가 아니라, 마케팅 페이지와 콘텐츠 제작에도 효과적이다. 기존 결과물을 먼저 조사하고, 반복 패턴을 통합한 뒤, 작은 요소부터 조합형 섹션까지 단계적으로 라이브러리화하면 개발 부담을 줄이면서 빠르고 일관된 웹사이트 운영이 가능하다.

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

Figma디자인 시스템component-libraryatomic-design+2

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

Figma에서 커뮤니티

Figma는 2020년의 성장 전략 중심에 사용자 커뮤니티를 두고, 온라인·오프라인·제품 내부에서 사용자를 더 closely 연결하겠다고 밝혔다. 이를 위해 사용자 컨퍼런스와 지역 모임, 글로벌 지원 체계, 팀 협업 기능, 파일 공유 기반의 Figma Community를 확대할 계획이다. 궁극적으로는 디자인을 더 많은 사람이 배우고 공유하며 함께 발전시키는 개방형 생태계를 구축하려는 것이다. ## 오프라인 만남과 지역 커뮤니티 확대 - 2020년 2월 샌프란시스코에서 첫 사용자 컨퍼런스 **Config**를 개최한다. - 프로그램 상당 부분을 커뮤니티가 직접 구성해, 일방적인 강연보다 참여형 행사로 운영한다. - 오픈소스 디자인, 차세대 디자이너 교육, 디자인 의사결정에 대한 자신감, Chicago.gov 재설계 경험 등 실무 중심 주제를 다룬다. - 샌프란시스코에 참석하지 못하는 사용자를 위해 온라인 시청도 제공한다. - 전 세계 도시의 커뮤니티 리더들과 협력해 지역별 Figma 이벤트와 사용자 그룹을 확대할 예정이다. ## 글로벌 고객 지원 강화 - 기존 고객 지원은 북미와 유럽 업무 시간 중심이었지만, Figma 활성 사용자의 80% 이상이 미국 외 지역에 있다는 점을 고려해 지원 체계를 확장한다. - Zendesk로 지원 기술 스택을 이전해 전 세계 고객을 더 효과적으로 지원할 기반을 마련했다. - 2020년 중 다음과 같은 지원 서비스를 선보일 계획이다. - 제품 지식을 직접 검색할 수 있는 새로운 Help Center - 사용자끼리 질문하고 답변하는 커뮤니티 포럼 - Figma 내부의 처리 절차 개선을 통한 더 빠른 고객 응대 ## 제품팀 전체를 위한 협업 기능 - 2019년에는 Plugins, Auto Layout, Smart Animate, OpenType 지원, Design System Analytics 등을 출시했다. - 앞으로도 반복적이고 수동적인 디자인 작업을 줄여 창의적 생산성을 높이는 기능 개발을 이어간다. - 디자인은 디자이너만의 작업이 아니라 엔지니어, 제품 관리자 등 여러 직군이 함께하는 과정이라는 점을 강조한다. - 따라서 Figma를 개인용 디자인 도구를 넘어 제품팀 전체가 사용할 수 있는 협업 플랫폼으로 발전시키려 한다. - 대규모 조직의 Figma 파일에는 평균 6명의 협업자가 참여한다는 데이터도 제품 방향의 근거로 제시했다. - 2020년 제품 로드맵은 Config에서 경영진이 추가로 공개할 예정이라고 밝혔다. ## 파일 공유를 중심으로 한 Figma Community - 디자이너들이 서로 작업물을 공유하고 배우는 관행에서 영감을 받아 Figma Community 베타를 시작했다. - 공개된 파일을 다른 사용자가 살펴보고, 수정하거나 재활용하며 학습할 수 있다. - 발표 당시 300명 이상의 크리에이터가 약 600개의 파일을 공개했다. - 공유된 자료에는 다음이 포함된다. - 디자인 템플릿 - 실습형 교육 가이드 - 공개 디자인 라이브러리 - 향후 더 많은 크리에이터가 자료를 게시하도록 지원해, 전문 디자이너와 예비 디자이너 모두가 유명 브랜드와 제작자의 작업에서 배울 수 있는 공간으로 만들 계획이다. ## 커뮤니티와 함께 만드는 성장 전략 - Figma는 단순히 사용자를 늘리는 것보다 사용자가 서로 연결되고 지식을 나누는 구조를 만드는 데 초점을 둔다. - 컨퍼런스와 지역 모임은 사람과 사람을 연결하고, 지원 포럼과 Community는 온라인 지식 교류를 활성화한다. - 제품 자체는 여러 직군이 실시간으로 협업하는 공간으로 확장된다. - 회사는 커뮤니티의 의견을 제품, 행사, 지원 정책에 반영하기 위해 사용자에게 직접 아이디어를 요청했다. Figma의 방향은 디자인 도구를 넘어, 작업물·지식·사람이 함께 모이는 협업 생태계를 구축하는 데 있다. 사용자는 Config나 지역 모임에 참여하고, Figma Community의 파일을 공유·재활용하며, 포럼을 통해 다른 사용자와 문제를 해결하는 방식으로 이 생태계를 적극 활용할 수 있다.

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

Figma디자인 시스템auto-layoutplugins+4

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

디자인 시스템의 가치 측정하기

디자인 시스템은 반복 자산을 재사용하게 해 디자이너가 제작·검색·세부 의사결정에 쓰는 시간을 줄여준다. Figma의 실험에서는 관련성이 높고 최신 상태인 디자인 시스템을 사용할 때 디자이너의 작업 완료 시간이 그렇지 않을 때보다 **34% 빨랐다**. 다만 이는 과제에 직접 적용 가능한 디자인 시스템을 사용한 조건의 결과이므로, 실제 조직에서 얻을 수 있는 최대 시간 절감에 가까운 수치로 해석해야 한다. ## 디자인 시스템의 가치와 정량화 필요성 - 디자인 시스템은 제품 전반에서 반복적으로 사용하는 자산을 위한 **단일 기준점(single source of truth)** 역할을 한다. - Figma 엔터프라이즈 고객의 약 **75%**가 조직 전체에서 디자인 시스템을 활용하고 있다. - 디자인 시스템은 구축보다도 지속적인 유지·관리와 실제 사용 현황 파악이 어렵다. - 사용 데이터를 분석하면 디자인 시스템 팀이 어떤 라이브러리와 컴포넌트를 개선하거나 폐기할지 더 정확히 판단할 수 있다. - Figma는 이러한 분석을 지원하기 위해 라이브러리 사용 추이와 컴포넌트별 사용 현황을 제공하는 Design System Analytics를 공개했다. ## 잘 유지된 디자인 시스템이 시간을 줄이는 이유 디자이너가 디자인 시스템의 자산을 사용하면 다음 작업을 피할 수 있다. - 컴포넌트나 화면 요소를 처음부터 다시 제작하는 작업 - 기존 디자인 파일을 뒤져 이미 존재하는 자산을 찾는 작업 - 글꼴, 배치, 색상 등 세부적인 시각적 결정을 매번 새로 내리는 작업 - 색상 선택이나 스타일 조정 같은 반복적인 미세 의사결정 이렇게 절약된 시간이 누적되면 디자이너는 전략적이고 창의적인 업무에 더 집중할 수 있다. ## 실험 설계: 디자인 시스템 사용 여부 비교 Figma 데이터 과학팀은 동일한 디자이너가 디자인 시스템이 있을 때와 없을 때 어떻게 달라지는지 비교했다. - 금융 계정 통합 앱을 배경으로 두 가지 과제를 설계했다. - 특정 계정의 거래 내역과 추세를 보여주는 화면 제작 - 사용자 프로필에 새 금융 계정을 연결하는 흐름 설계 - 모든 참가자는 두 과제를 모두 수행했지만, 한 과제에서만 최신 디자인 시스템을 사용할 수 있었다. - 다른 과제에서는 디자인 시스템 대신 참고용 과거 디자인 파일이 제공됐다. - 두 과제의 난이도와 완료 시간이 개인별로 비슷하도록 구성해, 각 디자이너가 자신의 통제군 역할을 하게 했다. - 과제 순서에 따른 편향을 줄이기 위해 참가자마다 수행 순서를 번갈아 배정했다. - 참가자에게 자산을 미리 익힐 시간을 충분히 제공했다. - 프롬프트는 사용자가 수행해야 할 목표만 설명하고, 디자이너가 어떤 화면을 만들어야 하는지는 지정하지 않았다. - 품질 기준을 인위적으로 통일하지 않기 위해 참가자가 스스로 적절한 완료 시점을 판단하도록 했으며, 과제별 완료 시간을 측정했다. ## 실험 결과: 작업 시간 34% 단축 - 디자인 시스템에 접근할 수 있었던 참가자는 그렇지 않은 경우보다 목표를 **34% 더 빠르게 완료**했다. - 이 결과는 디자인 시스템의 자산이 과제에 직접 적용 가능하고, 최신 상태이며, 실제 작업과 관련성이 높을 때 얻어진 효과다. - 따라서 현실의 모든 작업에서 항상 34%가 절약된다는 뜻이라기보다, 디자인 시스템이 가장 효과적으로 작동하는 조건에서의 상한선에 가깝다. - Figma는 이 비율을 실제 디자인팀의 인력과 일정에 적용해 시간과 비용 절감 규모로 환산하려 했지만, 제공된 글은 해당 계산 과정 중간에서 끝난다. ## 실용적인 적용 방향 디자인 시스템의 투자 효과를 확인하려면 단순히 라이브러리를 만들어 두는 것보다 최신성·관련성·사용률을 지속적으로 관리해야 한다. 라이브러리 분석을 통해 자주 사용되는 컴포넌트와 거의 쓰이지 않는 자산을 구분하고, 실제 작업에 맞지 않는 요소를 개선하는 것이 시간 절감 효과를 높이는 방법이다.

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

Figma디자인 시스템데이터 사이언스design-system-analytics+1

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

Made in Figma, 201

2019년 Figma 사용 데이터를 보면 디자인은 더 개방적이고 협업적인 활동으로 발전했으며, 디자인 작업을 정량적으로 분석하려는 흐름도 커졌다. 사용자들은 차가운 계열의 색상과 Google Fonts를 선호했고, 데스크톱·모바일 등 다양한 화면 크기를 기준으로 작업했다. 또한 하나의 디자인 파일에 여러 직군이 참여하며, 파일은 개인 작업에서 협업 작업으로 확장되는 양상을 보였다. ## 분석의 배경과 방법 - Figma는 2019년 사용자들의 디자인 경향을 파악하기 위해 익명화된 제품 데이터를 분석했다. - 분석 대상에는 다음과 같은 항목이 포함됐다. - 자주 사용된 색상과 폰트 - 텍스트 스타일과 굵기 - 가장 많이 선택된 프레임 크기 - 하나의 파일에서 협업한 사용자 수와 작업 흐름 - 디자인 시스템 분석 기능의 등장으로 디자인 작업의 가치와 활용도를 수치로 평가할 가능성도 커졌다. ## 차가운 계열 색상의 선호 - 회색 계열을 제외하면 녹색과 파란색이 가장 많이 사용됐다. - 가장 많이 사용된 비회색 색상은 `#009688`이었다. - 그 뒤를 짙은 파란색인 `#455A64`, `#263238`이 이었다. - 이는 2019년 Pantone 올해의 색상인 Living Coral(`#FF6F61`)과는 대조적인 결과였다. ## Google Fonts 중심의 폰트 사용 - 가장 많이 사용된 폰트는 다음과 같았다. - Montserrat - Open Sans - Lato - 상위 10개 폰트 중 6개가 Google Fonts였다. - SF Pro Text, SF Pro Display, Proxima Nova처럼 기본 제공 폰트가 아닌 글꼴도 상위권에 포함됐다. - 시스템 폰트 중에서는 Helvetica보다 Arial의 사용량이 많았다. - Figma의 기본 폰트인 Roboto는 순위에서 제외됐지만, 이를 포함하면 상위 11개 폰트가 전체 폰트 사용량의 90%를 차지했다. - Font Awesome은 아이콘 폰트임에도 31위를 기록했다. - Times New Roman은 55위였고, 첫 번째 세리프 폰트인 Playfair Display는 22위에 올랐다. ## 굵은 글꼴과 텍스트 스타일 - 사용자는 이탤릭체보다 글꼴 굵기를 조정하는 경향이 훨씬 강했다. - 글꼴을 굵게 조정하는 작업은 이탤릭체 적용보다 13배 더 자주 발생했다. - Figma 파일의 약 3분의 1은 bold 또는 heavy 스타일을 사용했다. - 이는 가독성뿐 아니라 시각적 위계와 강조를 위해 굵은 글꼴이 널리 활용됐음을 보여준다. ## 프레임과 화면 크기 선택 - Figma는 디자인 시작점으로 사용할 수 있는 36개의 사전 정의 프레임을 제공했다. - 전체 파일의 33%가 이 프리셋 프레임 중 하나로 시작됐다. - 가장 인기 있는 프레임은 `1440 × 1024` 데스크톱 화면이었다. - 그 뒤를 iPhone X와 iPhone 8 프레임이 따랐다. - Windows 사용자가 macOS 사용자보다 훨씬 많다는 점을 고려하면, 실제 운영체제 점유율과 디자인 대상 기기의 우선순위가 반드시 일치하지는 않았다. ## 개인 작업에서 팀 협업으로의 확장 - Figma는 디자인을 더 개방적이고 협력적인 활동으로 만들겠다는 방향을 제품에 반영했다. - 대규모 조직의 파일을 기준으로 하면 파일당 평균 협업자 수는 6명이었다. - 협업자는 디자이너뿐 아니라 다음과 같은 직군을 포함할 수 있었다. - 개발자 - 제품 관리자 - 라이터 - 조직 내 다른 이해관계자 - 일반적인 파일은 처음에 한 명의 사용자가 독립적으로 작업하며 시작됐다. - 평균 19일이 지나면 첫 번째 협업자가 초대됐다. - 초대된 협업자는 리뷰, 댓글 작성, 공동 디자인 등의 방식으로 파일에 참여했다. ## 실용적인 시사점 - 디자인 시스템과 협업의 효과를 평가할 때 사용 빈도, 참여자 수, 파일의 변화 과정 같은 데이터를 활용할 수 있다. - 폰트와 색상 선택에서는 유행보다 브랜드 맥락과 가독성을 우선하되, 사용자가 익숙하게 접근할 수 있는 표준 리소스도 고려할 만하다. - 파일을 개인 작업물로 끝내지 않고 개발·기획·콘텐츠 담당자와 공유하면 디자인 의사결정 과정이 더 투명해질 수 있다.

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

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

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

More natural/engaging

2010년대 모바일 혁명은 기술 기업에서 디자인의 역할을 주변 업무에서 핵심 경쟁력으로 끌어올렸다. 스마트폰은 더 복잡한 사용 환경과 방대한 사용자 데이터를 만들어냈고, 디자이너는 기능 우선순위 설정과 지속적인 UI 실험을 주도하게 됐다. 특히 아이폰은 소비자가 기대하는 제품의 미적·사용성 기준을 높이며 기업 전반의 디자인 투자를 촉진했다. ## 모바일 물결이 디자인의 위상을 높이다 - 아이폰은 2007년에 출시됐지만, 2009년 인앱 결제와 2010년 아이패드 등장 이후 2010년대에 본격적으로 산업 전반을 변화시켰다. - 스마트폰 보급으로 제품이 일상생활의 중심이 되면서, 복잡한 기술 시스템을 간단한 상호작용으로 바꾸는 디자이너의 역량이 중요해졌다. - 과거 엔지니어 중심이었던 실리콘밸리 기업들은 디자인 인력을 대규모로 채용하기 시작했다. - IBM 같은 기업은 2년 동안 35개 이상의 디자인 에이전시를 인수할 정도로 디자인 역량 확보에 적극적으로 나섰다. ## 모바일 환경이 만든 복잡성 - 모바일 화면은 데스크톱보다 작고 기기별 크기도 다양해졌다. - 사용자는 마우스 클릭 대신 손가락으로 탭, 스와이프, 길게 누르기 등의 동작을 수행했다. - 사용 상황도 책상 앞에 한정되지 않고 걷거나 이동하는 중으로 확장됐다. - 기업은 제한된 화면과 사용자의 주의력 안에서 어떤 기능을 우선 제공할지 결정해야 했고, 이 과정에서 디자이너의 문제 정의와 우선순위 판단이 중요해졌다. - 컴퓨팅이 화면 안에만 머무르지 않고 사용자의 주변 환경과 일상 행동 속으로 확장됐다. ## 데이터 기반 디자인과 A/B 테스트 - 스마트폰은 카메라, 마이크, 위치 정보 등을 통해 과거보다 훨씬 많은 사용자 데이터를 만들어냈다. - 모바일 사용이 일상화되면서 제품팀은 버튼 색상, 문구, 화면 구성 같은 UI 변형을 지속적으로 실험했다. - 실험 결과는 가입, 구매, 공유 등 사용자의 실제 행동 변화로 평가됐다. - 페이스북을 비롯한 기업들은 이러한 실험을 수행할 디자이너를 적극 채용했다. - 디자인은 시각적 완성도를 만드는 일을 넘어, 성장 지표를 개선하는 데이터 기반 업무로 확장됐다. - 2011년부터 2019년 사이 미국 성인의 스마트폰 보유율은 35%에서 81%로 증가했다. ## 아이폰이 세운 디자인 기준 - 아이폰은 기술 제품이 단순히 기능적이기만 해서는 안 된다는 인식을 널리 퍼뜨렸다. - 과거의 소프트웨어가 투박하고 실무적인 도구로 여겨졌다면, 아이폰은 제품의 외관과 사용 경험 자체를 경쟁 요소로 만들었다. - 아이폰은 맥보다 더 넓은 대중에게 디자인 중심의 제품 경험을 보여주며 소비자의 기대치를 높였다. - 기업들은 애플처럼 보이고 작동하는 제품을 만들려 했고, 소비자 역시 애플 수준의 완성도를 기대하게 됐다. - 이런 영향은 아이폰뿐 아니라 안드로이드와 틴더 같은 모바일 중심 서비스의 디자인 방향에도 나타났다. - 애플의 영향은 긍정적인 디자인 혁신을 이끌었지만, 모든 제품이 애플의 미학을 모방하려는 결과도 낳았다. ## 실무적 시사점 모바일 제품을 설계할 때는 기능을 많이 넣는 것보다 사용자의 상황과 제약을 먼저 이해하고 핵심 상호작용을 선별해야 한다. 또한 정성적 사용자 이해와 A/B 테스트 같은 정량적 검증을 함께 활용하되, 단기 성장 지표뿐 아니라 전체 사용자 경험과 제품의 일관성까지 고려하는 것이 중요하다.

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

사용자 경험a-b-testingmobile-designux-ui-design+2

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

오토 레이아웃

Figma의 Auto Layout은 자유로운 디자인 탐색과 HTML/CSS·SwiftUI 같은 개발 환경의 구조적 레이아웃 장점을 결합한 기능이다. 텍스트나 콘텐츠가 바뀌면 버튼과 주변 요소의 크기·위치가 자동으로 조정되어 반복적인 수작업을 줄인다. 또한 프레임 중첩을 통해 콘텐츠에 반응하는 복잡한 인터페이스와 재사용 가능한 컴포넌트를 만들 수 있다. ## 디자인과 개발 환경의 간극 - Figma의 기존 자유 배치 방식은 창의적인 탐색에는 유리하지만 반복 작업이 많았다. - 버튼 문구를 수정하려면 텍스트 편집, 버튼 크기 조정, 인접 버튼 이동을 각각 수행해야 했다. - HTML/CSS나 SwiftUI는 객체 간 구조와 관계를 표현하므로 콘텐츠 변경에 강하지만, 자유로운 시각적 실험에는 불편하다. - Auto Layout은 CSS 박스 모델, 특히 flexbox의 핵심 개념을 Figma에 도입해 두 환경의 장점을 결합했다. - 프레임의 속성으로 제공되므로 컴포넌트뿐 아니라 일반 프레임에도 적용할 수 있다. ## 콘텐츠에 따라 자동으로 변하는 레이아웃 - Auto Layout을 적용하면 내부 요소가 가로 또는 세로 방향으로 순서대로 배치된다. - 컨테이너의 크기는 내부 요소들의 전체 크기에 맞춰 자동으로 결정된다. - 프레임 자체에 패딩, 채우기, 선, 모서리 반경을 설정할 수 있어 버튼 제작에 별도 레이어가 필요하지 않다. - “Buy”를 “Add to basket”으로 변경하면 버튼이 텍스트 길이에 맞춰 자동으로 늘어난다. - 인접한 버튼이나 요소도 레이아웃 흐름에 맞춰 함께 이동한다. - 요소 간 간격은 개별 요소가 아니라 컨테이너 수준에서 설정된다. 특정 요소 사이만 다르게 조정하려면 추가 작업이 필요하다. ## 리스트와 메뉴의 자동 재정렬 - 반복되는 UI 요소를 배치하는 리스트와 메뉴 제작에 특히 유용하다. - 요소를 드래그해 순서를 바꾸면 나머지 요소가 자동으로 재배치된다. - 항목을 하나씩 올바른 위치로 옮기던 반복적인 클릭 작업을 줄일 수 있다. - 기존 컴포넌트 라이브러리와 디자인 시스템에도 적용할 수 있으며, `Shift + A` 또는 옵션 메뉴에서 활성화할 수 있다. ## 중첩 프레임으로 복잡한 인터페이스 구성 - 여러 Auto Layout 프레임을 HTML의 중첩된 `div`처럼 조합할 수 있다. - 버튼, 카드, 리스트, 화면 전체를 계층적으로 구성하면서 각 영역이 콘텐츠 변화에 반응하도록 만들 수 있다. - 콘텐츠를 수정하거나 요소를 다른 Auto Layout 프레임 안팎으로 이동하기 쉽다. - 의도하지 않은 배치를 막기 위해 큰 이미지를 버튼 안에 넣는 등의 작업에는 안전장치가 작동한다. - 실제로 원하는 작업이라면 macOS에서는 `Command`, Windows에서는 `Ctrl` 키를 눌러 안전장치를 무시할 수 있다. - 콘텐츠 변형마다 별도 컴포넌트를 만들기보다, 다양한 콘텐츠를 수용하는 범용 컴포넌트를 제작할 수 있다. ## 향후 발전 방향 - Figma는 Auto Layout을 첫 출시로 보고, 향후 더 많은 기능을 추가할 계획이라고 밝혔다. - 사용자는 플레이그라운드 파일, 동영상, 공식 문서를 통해 기능을 학습할 수 있다. - 기능 사용 후 피드백과 개선 요청을 공유하도록 독려했다. 실무에서는 텍스트 길이가 달라지는 버튼, 반복 목록, 카드와 메뉴처럼 콘텐츠 변화가 잦은 UI부터 Auto Layout을 적용하는 것이 효과적이다. 이후 프레임을 중첩해 디자인 시스템 전반을 반응형이고 재사용 가능한 구조로 확장할 수 있다.

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

Figma디자인 시스템HTML반응형 디자인+3

figma·2019년 11월 21일·4분 읽기큐레이션 요약

일터에서의 인간미: Gust

Gusto는 기존 브랜드가 고객에게 제공하는 인간적인 경험을 충분히 반영하지 못한다고 판단해 전사적인 리브랜딩을 추진했습니다. 이 과정에서 Figma를 디자인 도구를 넘어 마케팅·콘텐츠·제품·브랜드 팀이 함께 사용하는 협업 플랫폼으로 활용했습니다. 그 결과 브랜드 철학을 로고와 캠페인뿐 아니라 제품 UI와 고객 경험 전반에 일관되게 적용하고, 여러 제품으로 확장 가능한 디자인 시스템을 구축했습니다. ## 사람 중심의 리브랜딩 - Gusto는 2012년 ZenPayroll로 시작해 10만 개 이상의 소규모 사업체에 급여, 복지, 인사 업무 자동화 서비스를 제공했습니다. - 고객들은 플랫폼을 긍정적으로 평가했지만, 기존 브랜드가 Gusto가 제공하는 인간적인 경험을 제대로 보여주지 못한다고 판단했습니다. - 리브랜딩의 목표는 로고만 바꾸는 것이 아니라 다음 요소를 하나의 브랜드 철학으로 통합하는 것이었습니다. - 브랜드 인지도 - 제품 개발 - 고객 경험 - 마케팅과 커뮤니케이션 - Gusto의 브랜드 책임자는 브랜드를 마케팅 부서나 브랜드 디자인 팀만의 소유물이 아니라, 사용자가 회사와 접촉하며 경험하는 모든 것의 총합으로 정의했습니다. ## 전사적 동의를 만드는 과정 - 리브랜딩의 가장 큰 과제는 약 1,000명의 구성원이 새 브랜드를 이해하고 실제 업무에 적용하도록 만드는 것이었습니다. - 이를 위해 모든 팀이 같은 도구를 사용하며 다음 활동을 할 수 있어야 했습니다. - 진행 중인 디자인을 실시간으로 확인 - 아이디어 공유 - 디자인에 대한 의견 교환 - 결과물에 대한 공동 소유 의식 형성 - Figma는 디자인팀뿐 아니라 콘텐츠, 제품 마케팅, 고객 확보팀 등 다양한 조직이 프로젝트에 참여할 수 있게 했습니다. - 디자인 과정이 공개되면서 비디자이너도 디자인이 만들어지는 방식과 의사결정 과정을 이해할 수 있었고, 디자인의 가치에 대한 공감대도 높아졌습니다. ## 비디자이너를 디자인 과정에 참여시키기 - Gusto는 Figma를 다음과 같은 리브랜딩 작업 전반에 활용했습니다. - 무드보드 - 타이포그래피 - UI 디자인 - 광고판과 같은 오프라인 캠페인 - 브랜드 적용 예시 - 실시간 협업 기능을 통해 관련자들이 동일한 파일을 보며 작업 상황을 확인했습니다. - 댓글 기능을 사용해 이메일이나 Slack처럼 분리된 대화가 아니라 디자인 파일 안에서 직접 의견을 주고받았습니다. - 이러한 방식은 피드백의 맥락을 보존하고, 디자이너와 다른 직군 사이의 커뮤니케이션 비용을 줄였습니다. ## 브랜드팀과 제품팀의 공동 작업 - Gusto는 제품 디자인팀과 브랜드 디자인팀을 리브랜딩의 동등한 참여자로 구성했습니다. - 두 팀은 공동 브레인스토밍과 워크숍을 열어 다음 요소를 함께 결정했습니다. - 색상 팔레트 - 타이포그래피 - 제품에 적용할 브랜드 스타터 템플릿 - Figma에서 여러 사람이 동시에 작업하면서 새 브랜드 요소를 제품의 다양한 영역에 적용해 볼 수 있었습니다. - 제품팀은 브랜드 가이드라인과 워크숍 결과를 바탕으로 새로운 UI 키트를 제작했습니다. - 목표는 단순히 제품 전체에 브랜드를 반복 적용하는 것이 아니라, 특정 화면과 순간에 브랜드를 더욱 인상적이고 영감을 주는 방식으로 드러내는 것이었습니다. - 초기 단계부터 브랜드와 제품팀이 함께했기 때문에 브랜드를 제품 경험 전체로 확장하는 과정이 자연스럽게 이어졌습니다. ## 여러 제품으로 확장 가능한 디자인 시스템 - 리브랜딩은 시각적 결과물뿐 아니라 디자이너들이 협업하는 방식과 시스템을 정립하는 계기이기도 했습니다. - Gusto는 제품이 어떤 모습이어야 하는지에 대한 단일 기준, 즉 “시스템 오브 레코드”가 필요했습니다. - 이를 위해 제품 디자인팀은 Figma의 다음 기능을 활용해 UI 키트를 구축했습니다. - 공유 라이브러리 - 재사용 가능한 컴포넌트 - 브랜드 가이드라인을 반영한 UI 요소 - 이 시스템은 각 제품과 화면에서 일관된 디자인을 유지하고, 새로운 브랜드를 회사 규모에 맞게 확장하는 기반이 되었습니다. ## 실용적인 시사점 - 리브랜딩은 브랜드팀만의 프로젝트가 아니라 제품, 마케팅, 콘텐츠, 개발 등 고객 경험에 관여하는 모든 팀의 공동 작업이어야 합니다. - 디자인 파일을 협업의 중심에 두고 실시간 확인과 댓글을 활성화하면 비디자이너의 참여와 이해를 높일 수 있습니다. - 브랜드 가이드라인을 실제 UI 키트, 라이브러리, 컴포넌트로 연결해야 브랜드가 제품 경험에 일관되게 적용되고 장기적으로 확장됩니다.

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

Figma디자인 시스템collaborative-designuser-interface-design+2

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

Figma의 인프라: 웹

Figma는 웹 기반 디자인 도구도 데스크톱 애플리케이션 수준의 속도와 안정성을 제공해야 한다고 주장한다. 이를 위해 클라우드 기반의 단일 진실 공급원, 실시간 협업, 프로토타이핑과 개발자 핸드오프를 통합했으며, 사용자와 데이터가 증가함에 따라 인프라를 확장 가능한 구조로 전환하고 있다. 핵심 과제는 불필요한 데이터 로딩을 줄이고, 데이터베이스를 수평 확장하며, 전 세계 사용자의 지연 시간을 낮추는 것이다. ## Figma가 해결하려는 문제 - 기존 디자인 작업은 특정 데스크톱 애플리케이션과 플랫폼에 종속됐다. - 파일을 내보내거나 여러 도구 사이에서 옮기는 과정에서 최신 버전 관리와 협업이 어려웠다. - Figma는 디자인 파일을 클라우드에 저장하고 고유 URL을 부여해 팀 전체의 단일 진실 공급원으로 만든다. - 프로토타이핑과 개발자 핸드오프 기능을 제품 안에 포함해 별도 도구와 파일 변환의 필요성을 줄였다. ## 실시간 협업과 인프라 요구사항 - 여러 사용자가 하나의 파일을 동시에 보고 편집할 수 있는 멀티플레이어 기능을 제공한다. - 디자인 파일에는 복잡한 도형과 대용량 이미지가 포함될 수 있어 백엔드와 네트워크로 전송되는 데이터가 많다. - 사용자는 데스크톱 도구와 같거나 더 나은 상호작용 성능을 기대한다. - 따라서 인프라는 다음 요구사항을 동시에 충족해야 한다. - 낮은 상호작용 지연 시간 - 높은 가용성 - 대규모 파일과 동시 접속 처리 - 실시간 변경사항 동기화 ## 초기 인프라의 한계 - 초기 Figma는 단순한 백엔드 구조를 사용해 빠르게 제품을 개발하고 운영했다. - 예를 들어 파일을 로드할 때 사용자가 접근 가능한 공유 컴포넌트를 모두 미리 불러왔다. - 공유 디자인 요소가 수천 개일 때는 효과적이었지만, 조직의 라이브러리가 약 1만 개에 가까워지면 백엔드에 큰 부담이 발생했다. - Microsoft, Uber 같은 대규모 조직의 도입과 글로벌 사용자 증가로 이러한 문제가 일반적인 확장성 문제로 나타났다. ## 필요한 데이터만 불러오는 구조 - 기존 시스템은 사용자가 실제로 즉시 필요로 하지 않는 데이터까지 파일 로드 시점에 미리 가져오는 경우가 있었다. - 이 방식은 초기 진입 속도와 백엔드 부하 모두에 악영향을 준다. - 단순히 서버 성능만 개선하는 것으로는 해결되지 않으며, 클라이언트와 서버 간 상호작용 방식을 다시 설계해야 한다. - 클라이언트가 필요한 정보만 요청하도록 제품의 데이터 로딩 방식과 사용자 경험을 함께 바꿔야 한다. - 인프라 팀뿐 아니라 제품과 클라이언트 개발팀의 협업이 필요한 문제다. ## 단일 데이터베이스에서 수평 확장으로 - 당시 Figma의 전체 인프라는 AWS의 매우 강력한 단일 데이터베이스 인스턴스에 의존했다. - 단순한 구조를 선호하는 KISS 원칙 덕분에 초기에는 운영이 쉬웠고 빠르게 성장할 수 있었다. - 그러나 단일 인스턴스는 성능과 용량 확장에 한계가 있다. - 다음 단계에서는 여러 노드로 확장할 수 있는 수평 확장형 데이터베이스 계층을 구축하려 했다. - 데이터베이스를 거의 모든 시스템과 서비스가 사용하므로, 일관성·장애 처리·서비스 의존성까지 함께 재설계해야 하는 대규모 작업이다. ## 글로벌 사용자의 지연 시간 개선 - 주간 활성 사용자의 80% 이상이 미국 외 지역에 있었다. - 당시 요청은 미국 오리건의 데이터센터까지 왕복해야 했기 때문에, 사용자 경험이 물리적 네트워크 거리에 영향을 받았다. - 이를 개선하기 위해 사용자와 가까운 곳에 인프라 구성 요소를 배치하려 했다. - 첫 단계로 전 세계 주요 지역에 원격 프록시를 전략적으로 배치해 데이터센터까지의 네트워크 지연을 줄이는 방안을 추진했다. - 장기적으로는 글로벌 사용자에게 더 가까운 위치에서 요청을 처리하는 방향으로 인프라를 발전시키려 했다. ## 실용적인 결론 웹 기반 협업 도구의 확장은 서버를 더 큰 장비로 교체하는 것만으로 해결되지 않는다. 필요한 데이터만 지연 로딩하고, 데이터베이스를 수평 확장하며, 사용자가 가까운 위치에서 서비스를 이용하도록 네트워크 구조를 개선하는 등 제품 경험과 시스템 아키텍처를 함께 재설계해야 한다.

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

AWSreal-time-collaboration분산 시스템성능 최적화+2