open-design

2 개의 포스트

figma

Config: 피그마의 첫 번째 (새 탭에서 열림)

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

figma

피그마 드래프트 (새 탭에서 열림)

Figma Drafts는 완성된 결과물을 공유하기 전, 아이디어를 자유롭게 실험하는 개인 작업 공간이다. 글쓴이는 공개 협업 환경에서 파일의 완성도나 정리 상태를 평가받을까 하는 두려움을 Drafts로 완화했고, 이를 디지털 노트처럼 활용했다. 핵심 원칙은 먼저 만들고 나중에 정리하며, 발전시킬 아이디어만 프로젝트로 옮기는 것이다. ## 공개 협업에서 생기는 부담 - 다른 사람이 작업 중인 파일을 볼 수 있으면 다음과 같은 걱정이 생길 수 있다. - 8px 그리드를 지키지 않았다는 평가 - 레이어 이름을 정리하지 않았다는 지적 - 아이콘을 만드는 과정이나 파일 구조가 미숙해 보일 가능성 - 이 부담 때문에 실제 문제 해결이나 다양한 시도보다 파일을 “보여줄 만한 상태”로 꾸미는 데 시간을 쓰게 된다. - 글쓴이는 이러한 두려움이 공개적이고 협력적인 디자인 환경에서 더 커졌다고 설명한다. ## Drafts의 역할과 장점 - Drafts는 팀이나 프로젝트와 마찬가지로 파일을 보관하는 조직 단위지만, 개인 폴더라는 점이 다르다. - 팀이나 프로젝트의 권한 및 공유 설정에 종속되지 않는다. - Drafts 전체를 다른 사람에게 공개할 수는 없고, 필요한 경우 개별 파일만 선택적으로 공유할 수 있다. - 완성품이 아니라는 의미가 이름에 내포되어 있어, 실험과 미완성 작업을 심리적으로 허용한다. - 디자이너의 블록을 극복하고 색상, 타이포그래피, 화면 흐름 등을 정하기 전에 우선 아이디어를 시각화하는 공간으로 활용할 수 있다. - 글쓴이는 Drafts를 낙서, 스케치, 미완성 목록이 섞여 있는 개인 노트의 디지털 버전으로 사용한다. ## “먼저 만들고, 나중에 정리하기” - Drafts에서는 iOS 앱 아이디어나 Figma 기능을 활용한 실험처럼 빠르게 떠오른 생각을 즉시 기록한다. - 파일 이름이 없거나, 기본 회색 도형만 있거나, 구조가 엉성해도 문제로 보지 않는다. - 중요한 원칙은 **Create first, organize second**이다. - 먼저 다양한 해결책을 시도한다. - 아이디어가 발전한 뒤 파일명, 레이어, 구성 등을 정리한다. - 초기 단계에서 정리와 완성도를 지나치게 신경 쓰면 탐색의 폭이 줄어들 수 있으므로, Drafts에서는 혼란스러운 상태를 작업 과정의 일부로 받아들인다. ## Drafts를 프로젝트로 옮기는 방법 - 아이디어가 더 발전해 팀과 공유하거나 체계적으로 관리해야 할 시점이 되면 Drafts 파일을 프로젝트로 이동한다. - 파일 브라우저에서 파일을 선택한 뒤 원하는 프로젝트로 드래그 앤 드롭하면 된다. - 파일 내부에서 파일명 왼쪽의 “Drafts” 메뉴를 클릭하고 이동할 프로젝트를 선택할 수도 있다. - 예를 들어 와이어프레임을 고해상도 화면으로 발전시키려는 경우, 전체 파일을 프로젝트로 옮기는 방식이 적절하다. ## 원본 보존과 반복 작업 - 아이디어를 여러 페이지나 파일에서 계속 발전시킬 예정이라면, 먼저 Drafts 파일을 복제한다. - 복제본은 Drafts에 남겨 초기 아이디어의 스냅샷으로 보존한다. - 복제한 파일을 프로젝트로 옮겨 팀 작업이나 정리 작업을 진행한다. - Drafts에는 정리되지 않은 원본을 유지하고, 프로젝트 파일에서는 실제 작업에 필요한 요소를 다듬는 방식이다. ## 파일 관리와 검색 - Drafts가 많아지면 파일 브라우저의 필터 기능을 활용할 수 있다. - 파일명, 생성일, 마지막 수정일 등을 기준으로 파일을 찾고 정렬할 수 있다. - 다만 정리 자체를 너무 일찍 시작하기보다, 아이디어가 충분히 발전한 뒤 필요한 파일만 프로젝트로 옮기는 흐름이 권장된다. 개인 작업에서는 Drafts를 “공개 전 검수 공간”이 아니라 자유롭게 실패하고 탐색하는 디지털 스케치북으로 사용하는 것이 좋다. 완성도와 정리는 아이디어가 검증된 뒤에 진행하고, 팀 공유가 필요해졌을 때 파일을 복제하거나 프로젝트로 이동하면 창의성과 협업을 모두 확보할 수 있다.