사용자 인터페이스

71 개의 포스트

figma2분 읽기큐레이션 요약

그마, 이제 제

Figma는 UI 디자이너와 프런트엔드 개발자 간 협업을 개선하기 위해 Zeplin과의 연동을 지원한다고 발표했습니다. 디자이너는 Figma의 프레임을 Zeplin으로 내보내 개발자 중심의 방식으로 공유할 수 있으며, 기존 업무 흐름을 유지하면서 두 서비스를 seamless하게 사용할 수 있습니다. 다만 원본 디자인이 변경되면 Zeplin으로 다시 내보내야 합니다. ## Figma와 Zeplin 연동의 목적 - 팀마다 디자인·프로토타이핑·개발 방식이 다르다는 점을 고려해 다양한 협업 시스템을 지원합니다. - Zeplin은 UI 디자이너와 프런트엔드 개발자 간 핸드오프에 특화된 도구입니다. - 개발자에게 디자인 데이터를 직관적으로 제공해 구현 과정의 이해와 협업을 돕습니다. - Figma 사용자의 요청이 많았던 기능으로, Zeplin을 중심으로 작업하던 팀도 Figma를 도입하기 쉬워졌습니다. ## Figma와 Zeplin의 역할 차이 - Figma는 디자인 제작과 협업, 프로토타이핑을 위한 플랫폼입니다. - Zeplin은 개발자 경험에 초점을 맞춘 핸드오프 도구입니다. - Figma의 코드 모드와 달리, Zeplin으로 내보낸 디자인은 자동으로 최신 상태가 되지 않습니다. - Figma에서 디자인을 수정한 경우 변경 사항을 반영하려면 Zeplin으로 다시 내보내야 합니다. ## 연동 설정 및 사용 방법 - Zeplin을 설치하고 프로젝트를 생성합니다. 실험용 프로젝트도 사용할 수 있습니다. - Figma의 왼쪽 상단 메뉴에서 **Integrations > Zeplin**을 선택해 연동을 활성화합니다. - Figma에서 개발자에게 전달할 프레임을 만듭니다. - 해당 프레임을 선택한 뒤 **Export > Export to Zeplin**을 실행합니다. - 자동으로 열린 Zeplin 앱에서 **Import**를 선택합니다. - 이후 Zeplin에서 Figma 디자인을 확인하고 개발 핸드오프에 활용할 수 있습니다. ## 협업 생태계 확장 - 디자인 도구와 개발 도구 간 통합은 팀의 업무 전환 비용을 줄이고 협업 흐름을 매끄럽게 만듭니다. - Figma는 Zeplin 같은 외부 파트너와의 연동을 통해 플랫폼 생태계를 확장하려고 합니다. - 글에서는 새로운 협업 도구와 파트너십 제안을 계속 환영한다고 밝힙니다. 실무에서는 Figma를 디자인의 원본으로 관리하고, 변경이 완료된 시점에 프레임을 Zeplin으로 재내보내는 운영 방식을 권장합니다. 이를 통해 Zeplin에 전달된 화면이 실제 디자인과 불일치하는 문제를 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)
figma2분 읽기큐레이션 요약

놓치셨을 분들을

Figma는 창립 1주년을 기념해 월요일부터 토요일까지 매일 새로운 기능을 공개하는 `#6DaysofShipping` 이벤트를 진행했다. 고급 사용자를 위한 기능부터 초보자를 위한 단축키 안내까지 다양한 수준의 기능을 연속적으로 선보이며, 빠른 제품 개발과 사용자 커뮤니티의 기대감을 강조했다. 이 글은 해당 주간에 공개된 기능과 사용법을 간단히 정리한 회고다. ## 6일간 이어진 기능 출시 이벤트 - Figma 팀은 제품 출시 속도에 대한 사용자들의 관심과 기대에 호응해 6일 연속 기능을 공개했다. - 이벤트는 월요일부터 토요일까지 매일 하나의 기능을 소개하는 방식으로 진행됐다. - 주요 대상은 다음처럼 다양했다. - 중첩 인스턴스 교체 같은 파워 유저용 기능 - 키보드 단축키 목록처럼 입문자에게 유용한 기능 - 서로 성격이 다른 기능을 한 주에 묶어 공개함으로써 다양한 사용자에게 새로운 기능을 제공했다. ## 드래그로 속성값을 조절하는 Scrubbable Inputs - 속성 패널의 숫자 값을 직접 입력하는 대신, 마우스로 드래그해 빠르게 변경할 수 있다. - `Option` 키를 누른 상태에서 값을 클릭하고 드래그하면 값이 조절된다. - 커서를 위쪽으로 움직이면 값의 변화 속도를 더 빠르게 할 수 있다. - 반복적으로 크기, 위치, 간격 등의 값을 바꿔야 하는 디자인 탐색 과정에서 특히 유용하다. - 정확한 숫자를 매번 입력하기보다 시각적으로 결과를 확인하며 여러 대안을 빠르게 비교할 수 있다. ## 모서리 반경을 빠르게 조정하는 단축 동작 - 사각형의 모서리 반경을 별도의 입력 과정 없이 직접 조절할 수 있다. - 도형에 마우스를 올린 뒤 모서리 조절 핸들을 클릭하고 드래그하면 원하는 둥근 정도를 설정할 수 있다. - `Alt` 키를 누른 상태에서 드래그하면 네 모서리를 한꺼번에 바꾸는 대신 특정 모서리 하나만 조절할 수 있다. - 따라서 전체적으로 둥근 카드뿐 아니라 한쪽 모서리만 둥근 형태도 빠르게 만들 수 있다. - 디자인 시안을 수정할 때 속성 패널과 캔버스 사이를 오갈 필요가 줄어든다. ## 파워 유저와 초보자를 함께 고려한 기능 구성 - 이번 출시 주간은 하나의 큰 기능에 집중하기보다 작업 속도와 접근성을 높이는 여러 기능을 폭넓게 다뤘다. - 중첩 인스턴스 교체처럼 컴포넌트 기반 작업을 강화하는 기능과 키보드 단축키 안내를 함께 제공했다. - Figma는 기능 자체뿐 아니라 사용자가 기능을 발견하고 익히는 과정도 중요하게 보고 있었다. - 매일 새로운 내용을 공개하는 형식은 사용자들이 다음 출시를 기대하게 만들고 커뮤니티의 참여를 유도했다. 실무에서는 숫자 값을 반복해서 수정할 때 Scrubbable Inputs를 사용하고, 모서리 형태를 조정할 때 드래그와 `Alt` 조합을 활용하면 디자인 탐색 속도를 높일 수 있다. 또한 새로운 기능을 한꺼번에 익히기보다 단축키와 캔버스 직접 조작 기능부터 작업 흐름에 조금씩 적용하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

이번 트위터 논란은

디자인 시스템은 아직 업계에서 하나의 고정된 정의로 합의되지 않은 개념이다. Airbnb의 Karri Saarinen은 이를 제품 전체의 디자인을 규정하는 “공유되고 통합된 원칙과 패턴의 집합”으로 설명하며, 규모가 큰 장기 프로젝트일수록 일관성과 제약이 필요하다고 주장한다. 글은 Saarinen의 트위터 논쟁을 통해 디자인 시스템의 의미와 범위가 여러 디자이너의 관점 속에서 형성되고 있음을 보여준다. ## 디자인 시스템 정의가 분명하지 않은 이유 - 디자이너마다 디자인 시스템을 다르게 이해한다. - UI 컴포넌트와 스타일 가이드의 모음으로 보는 관점 - 제품의 디자인 원칙과 패턴을 포함하는 체계로 보는 관점 - 조직 전체의 협업 방식과 의사결정 기준까지 포함하는 관점 - 2017년 당시에도 디자인 시스템은 비교적 새로운 개념이었으며, 업계 리더들조차 범위와 핵심 요소를 계속 정립하는 단계였다. - 따라서 디자인 시스템은 단순한 시각적 규칙집이라기보다, 제품을 일관되게 설계하기 위한 여러 원칙과 패턴의 통합된 체계로 논의되고 있다. ## 규모가 커질수록 필요한 제약과 일관성 - Saarinen은 대규모·장기 프로젝트가 성공하려면 디자인 시스템이 필요하다고 설명했다. - 여러 팀과 플랫폼이 동시에 제품을 개발할 때 디자인 시스템은 다음을 돕는다. - 화면과 기능 간 시각적 일관성 유지 - 반복적인 디자인 의사결정 감소 - 팀 간 협업 기준 통일 - 제품이 확장될 때 디자인 품질 유지 - 여기서 제약은 창의성을 제한하기 위한 것이 아니라, 팀이 매번 기본 요소를 새로 결정하지 않고 중요한 문제에 집중하게 하는 장치로 볼 수 있다. ## Airbnb의 디자인 시스템 구축 방향 - Saarinen은 Airbnb의 디자인 시스템을 만들면서 제품의 전반적인 경험을 하나의 언어로 통합하려 했다. - 그가 제시한 주요 원칙은 다음과 같다. - **Unified**: 제품 경험이 서로 연결되고 통일되어야 함 - **Universal**: 다양한 상황과 사용자에게 적용될 수 있어야 함 - **Iconic**: Airbnb만의 분명하고 기억에 남는 정체성을 가져야 함 - **Conversational**: 사용자와 자연스럽게 소통하는 경험을 제공해야 함 - 이 접근은 디자인 시스템을 색상, 버튼, 아이콘 같은 시각 요소의 목록으로 한정하지 않고, 제품이 사용자에게 전달하는 태도와 경험까지 포함한다. ## 트위터 논쟁이 보여준 관점의 다양성 - Saarinen이 자신의 최신 정의를 공개하면서 다른 디자인 리더들과 공개적인 논의가 시작됐다. - 그의 정의는 디자인 시스템을 다음과 같이 본다. - 제품 전체 디자인을 규정하는 원칙과 패턴 - 여러 팀이 공유하고 함께 사용하는 통합된 기준 - 개별 화면이 아니라 제품 전반의 경험을 다루는 구조 - Facebook의 제품 디자이너 Sean Blanton을 비롯한 업계 인사들의 반응은 디자인 시스템의 범위를 둘러싼 의견 차이를 드러냈다. - 글은 이 논쟁을 통해 정답 하나를 제시하기보다, 디자인 시스템의 핵심이 무엇인지 업계가 실시간으로 조정하고 구체화하는 과정을 보여준다. ## 디자인 시스템은 완성된 산출물이 아닌 evolving한 체계 - 디자인 시스템은 한 번 만들어 배포하면 끝나는 문서나 라이브러리가 아니다. - 제품, 조직, 플랫폼이 변하면 원칙과 패턴도 함께 조정되어야 한다. - 중요한 것은 특정 구성 요소의 개수보다 다음과 같은 통합성이다. - 디자인 원칙과 실제 UI 패턴의 연결 - 디자이너와 개발자가 공유하는 언어 - 여러 제품 영역에 걸친 일관된 사용자 경험 - 조직이 성장해도 유지되는 의사결정 기준 실무에서는 디자인 시스템을 단순한 컴포넌트 라이브러리로 시작하되, 색상·타이포그래피·레이아웃 같은 시각 규칙뿐 아니라 제품 원칙과 사용자 경험의 방향까지 함께 정의하는 것이 좋다. 또한 조직과 제품의 규모에 맞춰 범위를 정하고, 실제 팀의 사용과 피드백을 반영하며 지속적으로 발전시켜야 한다.

원문 읽기(새 탭에서 열림)
figma2분 읽기큐레이션 요약

피그마 가이드 출시 |

Figma는 사용자 요청이 많았던 Guides 기능을 도입해 디자인 요소를 정렬하고 배치할 수 있도록 했다. Guides는 자를 기준으로 빠르게 생성·이동할 수 있으며, 프레임 단위로 관리하거나 픽셀 단위로 조정할 수 있다. Layout Grids보다 간편하게 사용할 수 있는 보조선이라는 점이 핵심이다. ## Guides의 목적과 특징 - Guides는 디자인 요소의 위치를 맞추기 위한 가로·세로 기준선이다. - Layout Grids보다 생성과 조작이 빠르다. - 2017년 출시 당시 6개월 동안 약 100건의 사용자 요청이 접수될 정도로 수요가 높았다. - Figma는 이 기능을 인턴 Shirley Miao와 엔지니어 Kenrick Rilee가 함께 개발했다고 소개한다. ## Guides 표시와 생성 - 메인 메뉴에서 **View → Show rulers**를 선택해 자를 표시한다. - 캔버스 상단의 가로 자 또는 왼쪽의 세로 자 위에 마우스를 올리면 오프셋 값이 표시된다. - 원하는 위치의 자를 클릭하면 해당 위치에 Guide가 생성된다. - 자의 여러 위치를 클릭해 여러 개의 Guides를 한 번에 만들 수 있다. ## Guides 이동과 삭제 - 생성된 Guide는 얇은 빨간 선으로 표시된다. - Guide를 드래그해 다른 오프셋으로 이동할 수 있다. - 삭제하려면 Guide를 선택한 뒤 Delete 키를 누르거나 화면 바깥으로 드래그한다. - 자 보기 기능을 끄면 Guides도 화면에서 사라진다. - 실수로 위치를 변경한 경우 `Command + Z`로 되돌릴 수 있다. - 화살표 키를 사용하면 Guide를 픽셀 단위로 미세 조정할 수 있다. ## 프레임 수준의 Guides - Guide를 프레임 안으로 드래그하면 해당 프레임에 종속된 프레임 수준 Guide가 된다. - 이를 활용하면 전체 캔버스에 Guides가 과도하게 표시되는 것을 줄일 수 있다. - 프레임 수준 Guides는 최상위 프레임에서만 작동한다. - Guides가 포함된 프레임을 다른 프레임 안으로 이동하면 해당 Guides는 사라진다. ## 실용적인 활용 - 자를 켠 뒤 주요 콘텐츠의 좌우 여백이나 상하 정렬 기준을 Guide로 표시하면 배치를 일관되게 유지할 수 있다. - 여러 화면이나 컴포넌트의 공통 정렬선을 빠르게 확인할 때 유용하다. - 세밀한 간격 조정에는 화살표 키와 실행 취소 기능을 함께 활용하는 것이 좋다. - 복잡한 캔버스에서는 프레임 수준 Guides를 사용해 화면별 기준선을 관리하는 것을 추천한다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

한 디자이너가 내

Pivotal의 디자이너와 개발자 간 인수인계는 디자인 파일을 이미지로 내보내고 프로젝트 카드에 반복 업로드하는 방식이라 비효율과 오류가 많았다. Figma를 도입한 뒤에는 최신 디자인을 링크 하나로 공유하고 디자인 위에 직접 댓글을 남길 수 있어, Colby는 프로젝트마다 약 이틀의 문서 관리 시간을 절약했다. 또한 맥락이 포함된 실시간 리뷰가 가능해져 협업과 결과물의 품질에도 긍정적인 영향을 주었다. ### 반복적인 이미지 내보내기와 업로드의 문제 - Colby는 디자인 프레임을 이미지로 export한 뒤 Pivotal Tracker의 개발 카드에 업로드했다. - 프로젝트마다 이 작업을 15~20회 반복해야 했다. - 프로젝트 하나에 수백 개의 카드가 있어 최신 카드를 찾는 데도 많은 시간이 들었다. - 이미지를 업데이트하지 않고 잊어버리면 개발자가 오래된 디자인을 기준으로 작업할 수 있었다. - 이 과정은 디자이너뿐 아니라 개발자의 시간도 낭비하고, 잘못된 구현으로 이어질 위험이 있었다. ### 브라우저 기반 디자인 공유 - Figma 파일은 브라우저에서 관리되므로 별도 프로그램 설치 없이 접근할 수 있었다. - 링크를 공유하면 모든 협업자가 동일한 최신 파일을 확인할 수 있었다. - 디자인이 변경되어도 개발 카드를 매번 이미지로 갱신할 필요가 없었다. - Colby는 카드를 처음 만들 때 Figma 링크만 추가하면 되었고, 프로젝트마다 약 이틀의 작업 시간을 절약했다. - Figma는 단순한 디자인 제작 도구를 넘어 파일 공유와 변경 관리까지 지원하는 “디자인 관리 도구”로 활용되었다. ### 디자인 위에 남기는 맥락 있는 댓글 - 기존 디자인 리뷰에서는 엔지니어들이 포스트잇에 의견을 적고 차례로 구두 공유했다. - 포스트잇은 어떤 디자인 요소에 대한 의견인지 맥락이 분리되어 이해하기 어려웠다. - Figma에서는 댓글을 특정 프레임이나 디자인 영역에 직접 연결할 수 있었다. - 리뷰 참여자는 의견이 적용되는 위치를 즉시 확인할 수 있어 피드백이 더 명확해졌다. - 결과적으로 주간 디자인 리뷰가 더 짧고 효율적으로 진행되었다. ### 실시간 협업과 리뷰 조정 - 엔지니어가 파일을 검토하는 동안 Colby는 각자의 커서와 활동을 실시간으로 확인할 수 있었다. - 특정 컴포넌트처럼 이미 스타일 가이드로 정해진 부분에 리뷰가 집중되면, Colby가 피드백 방향을 조정할 수 있었다. - 리뷰를 받는 디자이너가 어떤 영역에 피드백을 원하는지 직접 안내할 수 있었다. - 디자이너와 개발자가 같은 파일을 보며 의견을 주고받아 정보 전달의 누락을 줄였다. ### 협업 품질 향상 - Figma는 디자인에서 개발로 넘어가는 인수인계 과정의 반복적인 관리 작업을 줄였다. - 팀은 파일 버전과 피드백을 추적하는 데 쓰던 시간을 제품의 완성도에 더 투자할 수 있었다. - Pivotal은 개발자와 디자이너를 포함한 다양한 구성원의 의견이 더 나은 제품을 만든다고 보았고, Figma가 이를 지원한다고 평가했다. 실무에서는 디자인 파일을 이미지로 복사해 전달하기보다 최신 원본 링크를 단일 기준으로 삼고, 피드백은 해당 디자인 요소에 직접 남기는 방식이 효과적이다. 이를 위해 프로젝트 관리 카드에 Figma 링크와 버전 규칙을 명확히 기록하면 오래된 시안으로 작업하는 문제를 줄일 수 있다.

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

워크플로에서 컨스트레인 (새 탭에서 열림)

Figma의 '제약 사항(Constraints)' 기능은 다양한 화면 크기에 대응해야 하는 현대 디자이너들의 작업을 효율적으로 만들어주는 강력한 도구입니다. 이 기능을 활용하면 요소가 상위 프레임의 크기 변화에 따라 어떻게 반응할지 정의할 수 있어, 반복적인 수작업 없이도 유연한 반응형 디자인을 완성할 수 있습니다. 결과적으로 디자이너는 한 번의 설계로 PC부터 모바일까지 모든 해상도에서 의도한 레이아웃을 유지하는 견고한 인터페이스를 구축할 수 있습니다. **버튼의 고정 위치 설정** * 모바일 UI에서 자주 쓰이는 '플로팅 액션 버튼(FAB)'과 같은 요소를 프레임의 특정 위치에 고정할 수 있습니다. * 제약 사항을 'Bottom'과 'Right'로 설정하면 화면 크기가 늘어나거나 줄어들더라도 버튼이 지정된 구석 위치를 이탈하지 않고 유지됩니다. **컴포넌트와 제약 사항의 결합** * Figma의 컴포넌트(반복되는 디자인 단위) 기능과 제약 사항을 함께 사용하면 디자인 시스템 운영 효율이 극대화됩니다. * 주요 요소에 제약 사항을 설정한 뒤 이를 컴포넌트로 만들고 다양한 기기 크기의 프레임에 복제하면, 원본의 색상이나 텍스트 스타일을 한 번만 수정해도 모든 해상도의 인스턴스에 즉시 반영됩니다. **그리드와 연동한 반응형 레이아웃** * 제약 사항을 'Stretch(늘리기)' 타입의 레이아웃 그리드와 결합하면 하단 내비게이션 바와 같은 복잡한 요소도 정교하게 제어할 수 있습니다. * 내비게이션 바 프레임에 'Left & Right' 및 'Bottom' 제약을 설정하고, 각 아이콘을 그리드 열 내부에 배치한 뒤 'Center'로 설정하면 화면 너비 변화에 맞춰 아이콘 간격이 자동으로 균등하게 조절됩니다. **유연한 테이블 셀 설계** * 텍스트와 아바타가 포함된 그룹은 'Center-Left'로, 우측의 버튼 그룹은 'Center-Right'로 제약 사항을 다르게 부여하여 테이블 셀을 구성합니다. * 이렇게 설계된 셀은 프레임 너비가 어떻게 변하든 각 정보가 좌우 끝단에 밀착되어 정돈된 형태를 유지하므로, 정보 밀도가 높은 목록형 UI를 설계할 때 매우 유용합니다. **일러스트레이션의 창의적 활용** * 제약 사항은 UI 요소뿐만 아니라 일러스트레이션이나 드로잉에도 적용하여 재미있는 시각 효과를 줄 수 있습니다. * 수평 또는 수직 제약을 활용해 이미지를 의도적으로 늘리거나 줄임으로써, 프레임 크기 변화에 따라 캐릭터의 형태가 변하는 위트 있는 디자인을 연출할 수 있습니다. 효율적인 워크플로우를 위해 단순히 요소를 배치하는 것에 그치지 말고, 초기 설계 단계부터 제약 사항을 고려하는 습관을 들이는 것이 좋습니다. 특히 컴포넌트와 레이아웃 그리드를 제약 사항과 유기적으로 연결하여 사용한다면, 복잡한 디자인 시스템도 훨씬 유연하고 일관성 있게 관리할 수 있습니다.

figma3분 읽기큐레이션 요약

해커톤이 테크 디

해커톤은 디자이너를 기술 업계로 유입시키는 효과적인 통로가 될 수 있지만, 기존 개발자 중심 문화 때문에 디자이너들이 애초에 자신을 위한 행사라고 느끼지 못한다. Hack@Brown의 사례는 브랜딩 개선, 디자인 전용 시상, 적극적인 참가자 모집과 기업 멘토링을 통해 이 장벽을 낮출 수 있음을 보여준다. 따라서 디자이너 부족 문제를 해결하려면 해커톤 주최자뿐 아니라 기술 기업도 직접 디자이너를 찾아가고 성장 경로를 제시해야 한다. ## 디자이너에게 해커톤이 필요한 이유 - 해커톤은 짧은 시간 안에 팀을 구성하고 아이디어를 제품으로 발전시키는 행사다. - 디자이너는 해커톤에서 다음과 같은 경험을 얻을 수 있다. - 엔지니어와 협업 - 제품 아이디어 구상과 빠른 반복 - 화면과 플랫폼 제약을 고려한 디자인 - 이론적으로는 기술 업계의 디자이너 채용을 위한 자연스러운 인재 발굴 경로가 될 수 있다. - 그러나 실제 해커톤은 개발자 중심의 분위기와 이미지가 강해, 디자이너들이 자신은 어울리지 않는다고 생각하기 쉽다. ## Hack@Brown의 디자이너 유치 전략 - Brown University의 Hack@Brown은 약 500명이 참여하는 대학 해커톤으로, 디자인 전공 학생을 적극적으로 끌어들이는 모델을 제시했다. - RISD 학생들 중에는 코딩을 못하면 참여할 수 없거나, 기술 기업에서 일하는 것을 “매도”처럼 여기는 인식이 있었다. - 주최 측은 이를 바꾸기 위해: - 행사 브랜딩을 더 전문적이고 디자인 친화적으로 개편 - UX·UI 분야를 위한 별도 상금 마련 - 전국 디자인 동아리에 직접 연락 - 참가자의 프로비던스 왕복 교통비 지원 - 디자인 전공자를 운영진에 더 많이 포함 - 그 결과 디자인 참가자는 2013년 15~20명에서 2017년 100명 이상으로 증가했고, 전체 참가자의 약 20%를 차지했다. ## 기술 업계로 가는 보이지 않는 경로 - 엔지니어에게는 학습 방법과 취업으로 이어지는 비교적 명확한 경로가 있지만, 기술 업계의 제품 디자이너가 되는 과정은 덜 정립되어 있다. - 디자이너가 해커톤에 참여하더라도 개발자 채용 부스만 보이면 자신이 환영받지 못한다고 느낄 수 있다. - 한 참가자는 행사장이 엔지니어 중심이라는 인상을 받자 곧바로 떠나기도 했다. - 따라서 기업이 디자이너가 있는 곳으로 직접 찾아가야 한다는 주장이 제기된다. - 제품 디자이너가 될 가능성이 있는 학생을 발굴 - 현업 디자이너를 멘토로 파견 - 참가자에게 직무와 채용 경로를 설명 - Hack@Brown 운영자였던 Atty Eleti도 행사에서 현업 디자이너를 만나 자신의 진로를 엔지니어에서 디자이너로 전환했다. 잠재력을 알아보고 격려해 주는 한 번의 만남이 진로 형성에 결정적일 수 있다는 사례다. ## 해커톤에서 채용으로 이어지는 퍼널 - Hack@Brown은 단순한 행사 참여를 넘어 기업과 학생을 연결하는 채용 퍼널로 발전했다. - Facebook 등 기술 기업은 행사에 멘토를 보내 잠재력 있는 학생을 만나고, 이후 후속 통화나 캠퍼스 방문으로 관계를 이어갔다. - 당시 기술 기업들은 디자이너 채용을 크게 늘리고 있었다. - Facebook의 디자이너 채용 목표가 과거보다 크게 증가 - LinkedIn과 Dropbox는 엔지니어 4~5명당 디자이너 1명 수준의 채용 비율을 목표로 설정 - IBM과 GE도 디자이너 대규모 채용을 추진 - 해커톤 참가자 상당수는 기술·제품 디자인 업계 진입에 불안을 느꼈지만, 기업 입장에서는 아직 발굴되지 않은 인재가 풍부한 공간이었다. 해커톤이 디자이너 부족 문제의 만능 해결책은 아니지만, 행사를 개발자만의 공간이 아니라 디자이너와 엔지니어가 함께 제품을 만드는 공간으로 설계한다면 강력한 인재 발굴 경로가 될 수 있다. 주최자는 디자인 친화적인 환경을 만들고, 기업은 현업 디자이너를 파견해 참가자에게 구체적인 진로와 채용 기회를 보여주는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

스냅챗은 논란의

Snapchat의 성공은 전통적인 사용성 원칙을 따랐기 때문이 아니라, 오히려 복잡하고 숨겨진 UI를 통해 독특한 문화와 참여 방식을 만들었기 때문이라는 글이다. 직관성 대신 친구에게 기능을 배우고 공유하게 만드는 ‘공유 가능한 UI’를 택했으며, 카메라 중심 화면과 제스처 기반 탐색으로 모바일 소셜 앱의 새로운 방향을 제시했다. 다만 이러한 성공이 의도적인 전략인지 우연히 형성된 결과인지는 명확하지 않다. ## 전통적인 사용성 원칙을 거스른 UI - Snapchat은 사용자가 앱을 쉽게 이해하도록 만드는 일반적인 디자인 원칙을 따르지 않았다. - Stories 메뉴는 세로와 가로로 모두 스크롤되며, 화면마다 기능 배치와 탐색 방식이 일관되지 않았다. - 앱 전체를 아우르는 보편적인 내비게이션 바가 없고, 기능이 여러 화면과 제스처 속에 분산되어 있었다. - 이런 구조는 사용성을 떨어뜨리지만, 디자인의 목표가 항상 ‘가장 쉽게 이해되는 화면’을 만드는 데 있는 것은 아니라는 점을 보여준다. - Bobby Goodlatte는 디자인이란 픽셀이나 미적 완성도보다 문제 해결에 관한 것이며, 때로는 덜 다듬어진 공간이 더 적절한 해결책이 될 수 있다고 설명한다. ## 숨겨진 기능이 만든 사용자 문화 - Snapchat의 일부 기능은 화면에 명확히 드러나지 않아 다른 사용자에게 배워야 했다. - 라이브 영상 통화나 필터 기능처럼 숨겨진 기능을 친구가 직접 알려주면서 사용자 사이에 일종의 ‘부족 지식(tr ial knowledge)’이 형성됐다. - 앱 사용법을 아는 사람과 모르는 사람 사이에 경계가 생기면서, Snapchat은 부모 세대가 쉽게 접근하기 어려운 젊은 사용자만의 공간이 되었다. - 복잡하고 정돈되지 않은 인터페이스가 오히려 젊은 세대의 혼란스럽고 비정형적인 일상과 잘 맞는다는 해석도 제시된다. ## 카메라 중심 설계와 모바일 UX의 혁신 - Snapchat은 앱을 실행하면 피드가 아니라 카메라가 먼저 열리도록 설계한 최초의 대형 소셜 앱 중 하나였다. - 이 선택은 다른 사람의 콘텐츠를 소비하는 데서 벗어나, 사용자가 직접 사진과 영상을 만들도록 유도했다. - 화면을 스와이프해 앱의 다른 영역으로 이동하는 다차원적 탐색은 기존 메뉴 버튼보다 모바일 환경에 더 자연스러울 수 있었다. - 더블 탭, 스와이프, 길게 누르기 같은 터치 동작을 독자적인 명령어처럼 활용했다. - 이미지 위에서 필터를 바로 끌어오는 방식도 기존 앱의 썸네일 목록 중심 필터 UI와 달랐다. - 카메라를 열자마자 재미있고 창의적인 행동을 제안한다는 점이 Snapchat의 핵심 차별점이었다. ## ‘직관적인 UI’에서 ‘공유 가능한 UI’로 - Greylock의 Josh Elman은 Snapchat의 접근을 ‘공유 가능한 UI(shareable UI)’라고 설명한다. - 모든 제품이 처음부터 직관적일 필요는 없으며, Facebook이나 Excel도 처음 사용하는 사람에게는 즉시 이해되지 않았다는 논리다. - 중요한 것은 사용자가 혼자 메뉴를 헤매지 않고, 친구에게 기능을 묻고 사용법을 공유할 만큼 강력하고 매력적인 제품을 만드는 것이다. - 특히 소셜 앱에서는 기능을 알려주는 행위 자체가 사용자 간 관계와 참여를 강화할 수 있다. - Snapchat의 필터처럼 누군가 직접 보여줘야 알 수 있는 기능은 단순한 사용법이 아니라 사용자 확산 방식으로 작동했다. ## 의도된 전략인가, 우연한 성공인가 - 인터뷰에 참여한 디자이너들은 Snapchat의 성공을 완전히 계획된 디자인 전략으로 보지는 않았다. - 일부는 여러 가지 서투른 디자인이 우연히 하나의 앱에 모였고, 이후 젊은 세대의 취향에 맞았다고 평가했다. - 반대로 결과적으로는 기존 디자인 규칙을 깨면서 새로운 사용 행태와 모바일 소셜 경험을 만들어냈다. - Snapchat의 사례는 좋은 디자인이 반드시 정돈되고 예측 가능하며 즉시 이해 가능한 디자인과 같지는 않다는 점을 보여준다. 제품을 설계할 때는 무조건 직관성을 극대화하기보다, 사용자가 친구에게 알려주고 싶을 만큼 강력한 기능과 문화를 만들 수 있는지도 고려할 만하다. 다만 숨겨진 UI는 제품의 핵심 기능까지 가리지 않도록 설계해야 하며, Snapchat의 성공을 그대로 모방하기보다는 타깃 사용자와 서비스 목적에 맞게 적용해야 한다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

Figma의 팀 라이

Figma의 Team Libraries는 여러 파일과 팀원이 동일한 컴포넌트를 공유하고 동기화하도록 해 디자인 시스템 구축을 돕는 기능이다. 기존처럼 파일마다 심볼을 복사해 수동으로 교체하는 방식의 불일치 문제를 해결하고, 컴포넌트를 게시·삽입·업데이트하는 흐름으로 단일 진실 공급원을 유지한다. 이를 통해 디자인 시스템을 더 빠르고 일관되게 확장할 수 있다. ## 기존 디자인 도구의 한계 - 전통적인 디자인 도구는 사진 편집, 일러스트 제작, 정적인 화면 구성에 초점을 맞췄다. - 실제 애플리케이션의 반응형 동작이나 플랫폼의 제약 조건을 충분히 표현하지 못했다. - 디자인 시스템을 하나의 마스터 파일에서 관리하더라도 컴포넌트를 다른 파일로 복사하면 서로 다른 버전이 된다. - 작은 변경도 여러 문서를 찾아 각 심볼과 오버라이드를 수동으로 수정해야 했다. - Facebook, Google, Airbnb 같은 기업은 이러한 한계를 보완하기 위해 자체 디자인 시스템 도구와 전담 인력을 구축했다. ## Figma가 제시한 기반 - Figma는 시각 디자인과 동적인 사용자 인터페이스 설계를 연결하는 것을 목표로 했다. - 벡터 편집, 시스템 동작에 대응하는 제약 조건, 재사용 가능한 동적 컴포넌트를 제공해 디자인 시스템의 기반을 마련했다. - Team Libraries를 통해 이 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있게 했다. - 웹 기반 구조 덕분에 파일 간 동기화 지연이 거의 없고, 여러 기기와 플랫폼을 위한 레이아웃을 일관된 규칙으로 설계할 수 있다. ## 엔지니어링 원칙을 반영한 디자인 시스템 - React 같은 프레임워크처럼 애플리케이션을 명확히 정의된 작은 단위로 구성하는 방식을 디자인에도 적용했다. - 재사용 가능하고 유지보수하기 쉬운 구조는 제품 개발 주기 전체의 효율을 높인다. - 다만 프로그래밍 개념을 그대로 가져오기보다 디자이너가 쉽게 사용할 수 있도록 인터페이스와 작업 흐름을 단순화했다. ## 게시(Publish): 단일 진실 공급원 만들기 - 파일에서 컴포넌트를 선택하고 Inspector의 **Add to Library**를 눌러 라이브러리에 추가한다. - 여러 컴포넌트를 선택한 뒤 변경 사항을 검토하고 팀 라이브러리에 게시한다. - 라이브러리와 원본 파일을 분리해 디자인 시스템의 변경 권한을 통제할 수 있다. - 원본 파일에 편집 권한이 있는 사람만 소스 컴포넌트를 수정할 수 있다. - 원본 파일을 볼 수 있는 사람은 게시된 컴포넌트를 사용할 수 있지만 규칙 자체를 변경할 수는 없다. - 예를 들어 프로덕션 디자이너는 아이콘을, 브랜드 디자이너는 색상 문서를 관리하고 다른 팀원은 이를 재사용할 수 있다. ## 삽입(Insert): 여러 파일에서 컴포넌트 재사용 - 라이브러리에 게시된 컴포넌트는 원본 파일을 볼 권한이 있는 팀원에게 제공된다. - 각 파일의 툴바에서 컴포넌트 도구를 선택해 공유 컴포넌트를 삽입한다. - 컴포넌트 안에 다른 컴포넌트를 중첩할 수 있다. - 개별 요소로 모듈을 구성한 뒤, 이를 더 복잡한 화면과 사용자 흐름에서 재사용할 수 있다. - 깊게 중첩된 컴포넌트도 원본과 연결되므로 단일 진실 공급원을 예측 가능하게 유지할 수 있다. ## 업데이트(Update): 변경 사항의 동기화 - 브랜드 가이드나 UI 자산을 변경할 때 기존 컴포넌트를 수정하고 다시 게시한다. - 재게시 전 확인 단계를 거치며, 이전 버전과 무엇이 달라졌는지 시각적 diff로 확인할 수 있다. - 원본 파일에서 컴포넌트를 삭제한 뒤 게시하면 팀 라이브러리에서도 해당 컴포넌트가 사라진다. - 따라서 팀에는 현재 유효한 디자인 시스템 요소만 공유된다. - 공유 컴포넌트의 변경이 여러 탐색 작업에 영향을 줄 수 있으므로, 작업 손실을 막기 위한 추가 확인 절차를 둔다. ## 실용적인 결론 Team Libraries는 디자인 시스템을 복사본이 아니라 연결된 컴포넌트 구조로 관리하게 해준다. 팀에서는 원본 파일의 편집 권한을 제한하고, 색상·아이콘·버튼·복합 모듈을 라이브러리로 게시한 뒤 변경 사항을 검토하며 재게시하는 운영 방식을 마련하는 것이 좋다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

피그마에서 콘텐츠 디자인

Figma는 콘텐츠 디자이너가 UI가 완성된 뒤 문구를 채우는 방식에서 벗어나, 디자인 초기부터 제품의 모습과 메시지를 함께 설계하도록 돕는다. 실시간 협업, 실제 콘텐츠 사용, 대화형 시나리오 작성, 사용자 여정 매핑을 통해 콘텐츠와 UI의 불일치를 조기에 발견할 수 있다. 결과적으로 콘텐츠 디자이너는 협업 과정에 더 깊이 참여하고 사용자 경험 전반에 미치는 영향도 효과적으로 보여줄 수 있다. ## 실제 콘텐츠로 UI 설계하기 - 화면, 모달, 작은 인터랙션을 만들 때부터 가능한 한 실제 문구를 사용한다. - 실제 콘텐츠를 넣으면 다음 문제를 조기에 발견할 수 있다. - UI가 전달하려는 메시지를 혼란스럽게 만드는 경우 - 콘텐츠가 들어갈 공간이 부족한 경우 - 문구 때문에 인터랙션이나 사용자 흐름을 다시 설계해야 하는 경우 - 콘텐츠를 UI 완성 후 추가하면 문제가 발견됐을 때 이미 많은 디자인을 다시 작업해야 한다. - Figma에서는 콘텐츠 디자이너와 제품 디자이너가 동시에 작업하며 UI와 메시지를 함께 다듬을 수 있다. - 특히 콘텐츠 디자이너가 프로젝트 초기에 참여하지 못했더라도 실제 문구를 넣어 기존 UI의 문제를 빠르게 검토할 수 있다. ## 대화로 시작하는 콘텐츠 우선 설계 - 인터랙션을 실제 대화처럼 상상하고, 시스템과 사용자가 주고받을 말을 먼저 작성한다. - Figma 안에 대화 전용 프레임을 만들거나 댓글로 시나리오를 기록할 수 있다. - 한 사람이 시스템 역할을 맡고 다른 사람이 사용자가 되어 역할극을 하면 다음을 파악하는 데 도움이 된다. - 사용자 목표와 예외 상황 - 정보의 흐름과 우선순위 - 시스템 용어가 아닌 자연스러운 사용자 언어 - 시각적 UI를 만들기 전에 대화를 작성하면 콘텐츠와 디자인이 같은 방향으로 발전한다. - 대화 스크립트가 최종 설계의 완벽한 청사진은 아니지만, 반복적인 수정 과정에서 중요한 기준점이 된다. ## Figma에서 사용자 여정 매핑하기 - 콘텐츠 디자인은 특정 화면 하나가 아니라 사용자 여정 전체를 이해해야 한다. - 이전 단계에서 사용자가 무엇을 했고 다음 단계에서 무엇을 기대하는지 알아야 적절한 안내와 정보를 제공할 수 있다. - 팀과 함께 Figma에서 전체 여정을 시각화하고, 각 단계 아래에 필요한 콘텐츠를 정리한다. - 이 방식은 시각적 탐색이 콘텐츠 요구사항을 바탕으로 시작되도록 유도한다. - 웹 기반 협업 도구이므로 지리적 제약이나 화이트보드·스케치 파일의 공유 한계를 줄일 수 있다. - 엔지니어, 제품 관리자, 제품 디자이너가 실시간으로 작업을 볼 수 있어 콘텐츠 디자이너의 역할과 기여도도 자연스럽게 드러난다. ## 댓글로 콘텐츠 결정 협업하고 기록하기 - 제공된 글 내용은 이 섹션의 도입부에서 끝나 있어 구체적인 댓글 활용 방법까지는 확인할 수 없다. - 다만 제목과 앞선 내용에 따르면 Figma 댓글은 콘텐츠 선택의 근거를 팀과 공유하고, 주요 결정 사항을 디자인 파일 안에 남기는 협업 수단으로 제시된다. - 문서나 별도 회의록이 아니라 실제 디자인 맥락에 결정을 기록하면 이후 수정과 검토 과정에서 내용을 추적하기 쉬워진다. 실무에서는 초기부터 실제 문구를 넣고, 주요 플로우를 대화로 먼저 검증한 뒤, 사용자 여정과 콘텐츠 요구사항을 하나의 Figma 파일에서 관리하는 것이 효과적이다. 이를 통해 콘텐츠를 마지막 단계의 산출물이 아니라 제품 경험을 함께 결정하는 설계 요소로 다룰 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

가구에서 스크린까지

가구는 완성 후 실수를 고치기 어렵지만, 디지털 제품은 매일 개선할 수 있다는 차이에서 출발한다. Figma는 가구처럼 사용자의 작업을 돕되 스스로는 눈에 띄지 않는 도구를 지향하며, 가구 디자인의 원칙을 도구·조작감·색상 설계에 적용했다. 궁극적으로 좋은 디자인 도구는 사용자가 도구 자체가 아니라 자신의 아이디어에 집중하게 해야 한다. ## 사용자의 삶을 돕고 사라지는 제품 - 가구의 목적은 빈 공간을 채우는 것이 아니라 그 안에서 이루어지는 생활을 지원하는 데 있다. - Figma 역시 제품 자체가 주인공이 아니라, 사용자가 다른 제품과 아이디어를 만들어내도록 돕는 기반이 되어야 한다. - 따라서 인터페이스는 기능을 제공하면서도 사용자의 창작 활동을 방해하지 않고 배경으로 물러나야 한다. ## 최소한이지만 강력한 도구 - 기본 도구 수를 줄이되, 단순한 작업부터 복잡한 작업까지 대응할 수 있도록 설계했다. - 망치 하나로 작은 수납장부터 집 전체를 만들 수 있듯이, 핵심 도구는 다양한 결과물을 만들어낼 만큼 유연해야 한다. - Figma의 펜 도구는 물리적인 펜처럼 느껴지도록 재구성했다. - 벡터 객체를 전통적인 경로가 아니라 점들의 네트워크로 구성해, 임의의 점을 서로 연결할 수 있게 했다. - 이 방식은 정해진 절차를 따라가는 대신 결과물을 자연스럽게 만들어가는 데 집중하게 한다. - 편집기는 필요한 도구가 잘 정리된 작업대처럼 느껴져야 하며, 도구의 배치와 접근성은 작업의 기본 조건이다. ## 손에 잡히는 조작감과 사용자 제어 - 물리적 도구를 사용할 때의 촉각적 익숙함은 디지털 도구에서도 통제감을 높인다. - 키보드 단축키는 사용자가 작업을 빠르고 직접적으로 제어하게 만드는 대표적인 수단이다. - Figma의 `Command` 키와 드래그 조합은 중첩된 요소를 선택할 때의 불편을 해결한다. - `Command`를 누른 채 드래그하면 컨테이너와 내부 요소를 구분하는 휴리스틱이 작동해, 컨테이너 자체가 아니라 포함된 요소만 선택한다. - 예를 들어 툴바 배경은 제외하고 그 안의 아이콘만 한 번에 박스 선택할 수 있다. - 사용자는 레이어 계층 구조를 일일이 생각하지 않고 화면 속 요소를 직접 조작할 수 있다. ## 눈에 띄지 않되 의미를 전달하는 색상 - 초기 Figma는 거의 단색에 가까운 ‘무스킨’ 스타일을 사용해 UI가 디자인을 방해하지 않도록 했다. - 그러나 기능이 늘어나면서 단색 UI만으로는 서로 다른 구성 요소를 명확히 구분하기 어려워졌다. - 해결책은 UI를 완전히 사라지게 하는 것이 아니라, 사용자가 의식하지 않아도 의미를 파악할 수 있도록 만드는 것이었다. - 현재의 색상 체계는 색을 시각적 장식이 아니라 의미의 추가 계층으로 활용한다. - 초록색: 실행이나 행동 - 파란색: 선택 상태 - 이러한 색상 그룹은 화면을 한눈에 이해하게 하고, 사용자가 “어떻게 도구를 쓰는가”보다 “무엇을 그리고 있는가”에 집중하도록 돕는다. ## 분야를 넘나드는 디자인 원칙 - 디자인 도구를 발전시키려면 현재 업계의 관습과 기준을 계속 재검토해야 한다. - 유용한 해결책은 과거의 디자인뿐 아니라 다른 분야에서도 발견될 수 있다. - 가구 디자인처럼 분야를 초월하는 원칙—기능 지원, 사용성, 절제, 재료와 도구의 이해—을 디지털 제품에 적용할 수 있다. - 디자이너는 자신의 전문 영역에만 머무르지 않고 역사와 타 분야를 폭넓게 참고해야 혁신적인 도구를 만들 수 있다. Figma를 설계할 때는 기능을 늘리는 것보다 사용자의 작업을 얼마나 자연스럽게 지원하는지에 초점을 두는 것이 중요하다. 최소한의 유연한 도구, 직관적인 조작, 의미를 전달하는 시각 체계를 갖추면 제품은 사용자의 창작을 돕면서도 전면에 나서지 않을 수 있다.

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