figma2021년 12월 15일

Frame 2021: 숫 (새 탭에서 열림)

2021년 Figma와 FigJam의 데이터는 원격·하이브리드 근무가 디자인과 협업을 국경과 직무의 경계 너머로 확장했음을 보여준다. 협업은 더 일찍 시작되고, 디자이너뿐 아니라 PM과 개발자까지 디자인 프로세스 전반에 참여하게 됐다. FigJam에서 아이디어를 구상한 뒤 Figma에서 구체적인 인터페이스를 설계하는 흐름도 정착되고 있다. ## 국경과 시간대를 넘는 협업 - Figma는 235개 국가와 지역에서 사용되고 있다. - 미국에서는 뉴욕과 캘리포니아가 주요 협업 중심지였으며, 워싱턴과 텍사스에서도 활동이 증가했다. - 전 세계적으로는 미국과 러시아가 협업 허브 역할을 하고 있고, 인도·브라질·인도네시아의 참여도 커지고 있다. - Figma 사용자의 83%가 미국 외 지역에 있으며, 서로 다른 대륙 간 협업 비율은 2020년 초 8%에서 약 14%로 증가했다. - 마드리드와 웰링턴, 베이징과 부에노스아이레스처럼 매우 먼 거리의 사용자들도 공동 작업을 진행했다. ## 아이디어에서 출시까지 이어지는 협업 - 2021년 Figma 사용자의 약 52%가 다른 사람과 협업했다. - 공유 파일에는 중앙값 기준 4명이 초대됐다. - 협업자는 디자이너에 국한되지 않고 PM과 개발자 등 다양한 직군으로 확대됐다. - 디자인 도구가 단순한 제작 공간이 아니라 아이디어 구상부터 개발 전달까지 전체 프로세스를 담는 공간으로 활용되고 있다. ## FigJam에서 Figma로 이어지는 흐름 - FigJam은 원격 근무 환경에서 초기 아이디어를 자유롭게 교환할 수 있는 공간으로 도입됐다. - 활성 FigJam 사용자 중 약 15%는 템플릿으로 작업을 시작한다. - 가장 인기 있는 템플릿 유형은 브레인스토밍이다. - 팀은 FigJam에서 브레인스토밍과 아이디어 발산을 진행한 뒤, Figma에서 실제 인터페이스와 제품 디자인을 구축하는 경향을 보였다. ## 더 일찍 시작되는 디자인 협업 - Figma 파일이 생성된 뒤 첫 번째 협업자가 파일을 확인하기까지 걸리는 시간은 평균 10일이다. - 이는 2019년 협업자 초대까지 평균 19일이 걸렸던 것과 비교해 크게 단축된 수치다. - 디자이너들이 PM이나 개발자 같은 직군을 디자인 초기 단계부터 참여시키고 있음을 의미한다. - 개발자가 참여하는 협업 파일은 전체 협업 파일의 40%를 차지한다. - 개발자와의 핸드오프는 디자인 생성 후 보통 33일 뒤 시작되며, 첫 코드 검토 이후에도 45일간 이어진다. - 핸드오프 활동은 최종 디자인 수정이 끝난 뒤에도 계속되는 장기적인 협업 과정으로 나타났다. ## 디자인을 넘어선 FigJam 활용 - 하이브리드·디지털 중심 근무가 확산되면서 대면 활동을 온라인 환경에 맞게 재구성할 필요가 커졌다. - Figma는 FigJam을 스탠드업, 아이스브레이커, 로드맵 작성, 회고 등 다양한 팀 활동에 활용했다. - FigJam은 디자인 전용 도구라기보다 원격 팀의 소통과 의사결정을 지원하는 협업 공간으로 확장되고 있다. 실무적으로는 초기 아이디어 단계부터 PM과 개발자를 참여시키고, FigJam의 브레인스토밍 결과를 Figma의 구체적인 설계로 연결하는 프로세스가 효과적이다. 또한 핸드오프를 일회성 전달이 아니라 개발 과정 전체에 걸친 지속적인 협업으로 관리하는 것이 중요하다.

design-processfigmafigjamdesign-collaboration+2

figma2020년 10월 14일

팀으로 배우고 실패하기 | (새 탭에서 열림)

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

design-processfigmadesign-systemsaccessibility+3

figma2020년 3월 1일

창의적인 문화를 구축 (새 탭에서 열림)

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

design-processfigmateam-collaborationdropbox+1

figma2019년 4월 3일

Figma UI 개편: (새 탭에서 열림)

Figma는 기능 구조를 크게 바꾸기보다 타이포그래피, 레이아웃, 색상, 아이콘 등 UI 표면을 다듬는 방식으로 시각적 리프레시를 진행했다. 기존 UI가 제품 성장에 따라 일관성을 잃고 한계에 부딪혔기 때문에, 전사적 브레인스토밍과 이슈 통합, 정성·정량 조사를 거쳐 변경 범위를 결정했다. 핵심은 모든 사용자를 만족시키려 하기보다 문제를 체계적으로 수집하고, 중요한 개선점에 집중하는 것이었다. ## 리디자인이 필요해진 배경 - Figma의 UI는 제품과 기능이 성장하면서 점점 일관성을 잃었다. - 기존 컴포넌트로 새로운 기능을 표현하기 어려워질 때마다 팀이 임시 컴포넌트와 맞춤형 해결책을 만들었다. - 그 결과 다음과 같은 문제가 누적됐다. - 서로 다른 형태의 테이블, 버튼, 입력 컨트롤 - UI 곳곳에 흩어진 여러 색조의 회색·빨강·파랑 - 기능마다 다른 알림과 대화상자 처리 방식 - 가독성, 여백, 아이콘 체계의 불일치 - 마지막으로 UI 전체를 검토했을 때는 아직 Multiplayer나 Components 같은 핵심 기능이 없었다. - 즉, 기존 UI의 기반이 현재의 Figma를 충분히 반영하지 못하게 된 것이 리프레시의 주요 배경이었다. ## 표면적 변화에 집중한 전략 - 목표는 사용자가 큰 혼란 없이 새 UI를 받아들이도록 만드는 것이었다. - 정보 구조나 제품의 기본 동작을 재설계하기보다는 다음과 같은 시각적 요소를 중심으로 개선했다. - 타이포그래피 - 레이아웃 - 색상 - 아이콘 - 컴포넌트의 시각적 일관성 - 출시 전 수개월 동안 정성적·정량적 조사를 진행했다. - 세부 변경 사항마다 여러 팀이 깊이 논의해 최종 결과에 동의하도록 했다. - 특히 디자이너는 시각적 변화에 민감하므로, 리디자인이 모든 사람에게 동일하게 환영받을 수 없다는 점도 고려했다. ## 1단계: 제한 없이 문제 수집하기 - 전체 디자인 팀이 참여하는 2시간 브레인스토밍 세션을 열었다. - 팀원들은 실제로 Figma를 사용하면서 제품의 구석구석을 살펴봤다. - 발견한 내용을 다음 방식으로 기록했다. - UI의 문제점과 불편한 점 - 마음에 드는 부분 - 관련 스크린샷 - 특정 문제가 미치는 영향에 대한 메모 - 모든 결과물을 Figma 파일에 모아 공동으로 검토했다. - 팀원들이 강하게 반응한 문제, 즉 모두가 “이건 심각하다”고 느낀 항목을 별도로 표시했다. - 이 반응은 어떤 문제가 사용자 경험에 큰 영향을 줄 가능성이 있는지 판단하는 초기 신호로 활용됐다. - 브레인스토밍 직후 결론을 내리지 않고 며칠간 거리를 둔 것도 중요했다. 시간이 지나면서 문제의 우선순위와 구성원들의 의견이 자연스럽게 바뀌었기 때문이다. ## 2단계: 문제를 통합하고 범주화하기 - 후속 회의에서 각 문제를 다시 검토하며 처음의 판단을 재평가했다. - 일부 문제는 생각보다 중요하지 않다고 판단했고, 다른 문제는 해결 필요성을 더 강하게 주장할 수 있도록 논거를 보완했다. - 긴 문제 목록을 팀원들에게 나누어 전달하고, 각자가 이를 포스트잇 형태의 짧은 항목으로 재작성했다. - 이 과정에서는 개별적인 증상을 그대로 옮기기보다 공통된 근본 문제로 추상화했다. - 예: “특정 화면의 알림 모양이 다르다” - 통합된 표현: “제품 전체의 알림 처리 시스템이 필요하다” - 비슷한 포스트잇을 함께 묶어 반복적으로 나타나는 주제를 확인했다. - 그 결과 다음과 같은 범주가 도출됐다. - 아이콘, 타이포그래피, 가독성, 색상 - 대화상자, 툴바, 말투 - 에디터와 파일 브라우저 - 모드, 팀 페이지, 속성 사이드바 - 컴포넌트, 레이어, 히스토리 - 공유, 퍼블리싱, 내보내기 - 포스트잇의 반복은 단순한 중복이 아니라 중요한 문제가 여러 방식으로 나타나고 있다는 신호가 되었다. - 다만 범주를 다시 “시각적 문제에서 기초 구조적 문제까지”라는 축으로 정렬하려 한 것은 지나치게 복잡한 접근이었다. ## 범주화 과정에서 얻은 교훈 - 문제를 조직화할 때 지나치게 추상적인 기준을 만들면 오히려 판단이 어려워진다. - “제품의 개성”처럼 거의 모든 문제를 포함할 수 있는 범주는 유용하지 않다. - 반대로 특정 대화상자 하나처럼 지나치게 좁은 범주도 전체적인 개선 방향을 잡는 데 적합하지 않다. - 가장 좋은 범주는 서로 비슷한 문제를 묶으면서도, 실제 개선 작업으로 이어질 수 있을 만큼 구체적이어야 한다. - 완벽한 분류 체계를 만드는 것보다 중요한 문제의 신호를 잡음에서 분리하는 것이 우선이다. ## 실무에 적용할 때의 추천 - 리디자인을 시작할 때 바로 해결책을 만들기보다, 먼저 팀 전체가 제품을 직접 사용하며 문제를 폭넓게 수집한다. - 각 문제를 개별 사례가 아닌 반복되는 시스템적 문제로 재정의한다. - 브레인스토밍 직후 결론을 확정하지 말고 일정한 숙고 시간을 둔다. - 범주화는 단순하고 이해하기 쉽게 유지하며, 지나치게 추상적이거나 복잡한 분류 축은 피하는 것이 좋다.

design-processfigmadesign-systemsui-ux+2