techlist.io
KREN

접근성

58 개의 포스트

figma3분 읽기큐레이션 요약

Thumbtack이 디자인

Thumbtack은 디자인 시스템 **Thumbprint**를 토큰, Atomic CSS, 컴포넌트의 3계층으로 구성해 유연성과 생산성을 함께 확보한다. 하위 계층일수록 세밀한 제어와 확장성이 높고, 상위 계층일수록 접근성·일관성·개발 생산성이 높아진다. 필요한 경우 각 계층 내부에도 추가 계층을 두어, 개발자가 일반적인 상황에서는 간편한 추상화를 사용하면서도 특수한 요구에는 더 낮은 계층으로 내려갈 수 있게 했다. ## 3단계 계층 구조 - **Thumbprint Tokens** - 시스템의 가장 낮은 추상화 계층이다. - 색상, 타이포그래피, 모서리 반경, 간격, 크기, 그림자 등 세부 디자인 속성을 변수로 정의한다. - 웹과 네이티브 클라이언트 모두에서 사용된다. - 가장 세밀하고 유연하지만, 이를 직접 조합해야 하므로 개발 생산성은 상대적으로 낮다. - **Thumbprint Atomic** - Thumbprint Tokens 위에 구축된 원자적 CSS 라이브러리다. - 개발자가 별도의 커스텀 CSS를 작성하지 않고도 UI를 구성할 수 있다. - 예를 들어 `aspect ratio` 클래스를 사용하면 YouTube나 Vimeo 같은 외부 미디어의 가로세로 비율을 일정하게 유지할 수 있다. - 토큰보다 생산성이 높지만, 완전히 자유롭게 스타일을 제어하는 것보다는 유연성이 낮다. - **Thumbprint Components** - 가장 높은 추상화 계층으로, 자주 사용하는 UI 패턴을 접근성까지 고려해 미리 구현한다. - 알림, 버튼, 날짜 선택기, 별점 등 공통 컴포넌트를 제공한다. - 개발자는 반복적인 UI 구현보다 핵심 제품 기능에 집중할 수 있다. - 제공되지 않는 컴포넌트가 필요하면 Atomic CSS를 사용해 직접 구성하고, 그보다 더 낮은 수준의 제어가 필요하거나 네이티브 환경이라면 디자인 토큰을 직접 사용할 수 있다. ## 계층에 따른 트레이드오프 - 하위 계층으로 내려갈수록: - 디자인 속성을 세밀하게 제어할 수 있다. - 새로운 제품 요구사항에 유연하게 대응할 수 있다. - 대신 구현과 유지보수에 더 많은 개발 노력이 필요하다. - 상위 계층으로 올라갈수록: - 접근성, 시각적 일관성, 개발 생산성이 높아진다. - 공통 UI를 빠르고 안정적으로 구현할 수 있다. - 대신 사전에 정해진 동작과 스타일이 많아져 특수한 요구에는 덜 유연할 수 있다. ## 계층 안의 계층 - 하나의 계층도 목적에 따라 여러 하위 계층으로 나눌 수 있다. - Thumbprint의 React 모달은 다음처럼 구성된다. - `ModalCurtain`: 시각적 스타일보다 사용성·기능에 집중한 낮은 계층 컴포넌트 - `Modal`: `ModalCurtain`을 기반으로 시각적 스타일과 일반적인 모달 사용 방식을 제공하는 상위 컴포넌트 - 대부분의 개발자는 바로 사용할 수 있는 `Modal`을 사용한다. - `Modal`이 지나치게 제한적일 때는 `ModalCurtain`으로 내려가 더 자유롭게 구성할 수 있다. - 이후 반복적으로 필요한 기능은 다시 상위 `Modal`에 추가해 시스템을 발전시킬 수 있다. ## 디자인 토큰의 다단계 추상화 - 디자인 토큰도 여러 단계로 상속·추상화할 수 있다. - Adobe Spectrum의 예처럼: - `button-cta-background-color` - `cta-background-color` - `blue-400` - 토큰이 구체적인 의미에서 일반적인 색상 값으로 이어지는 구조다. - 개발자는 자신의 상황에 적용 가능한 가장 높은 수준의 토큰을 사용하는 것이 일반적이다. - 이를 통해 제품별 요구에는 대응하면서도 디자인 언어의 일관성을 유지할 수 있다. ## 실용적인 적용 방향 Thumbprint의 방식은 모든 개발자가 가장 낮은 수준의 API를 직접 다루게 하는 대신, 기본적으로는 접근성과 생산성이 높은 컴포넌트를 제공하고 필요할 때만 Atomic CSS와 토큰으로 내려가도록 설계한다. 따라서 디자인 시스템을 만들 때는 단일 추상화 계층에 모든 요구를 담기보다, **일반적인 사용 사례를 위한 높은 계층과 예외적인 요구를 위한 낮은 계층을 함께 제공하는 구조**가 효과적이다.

원문 읽기(새 탭에서 열림)
접근성디자인 시스템React디자인 토큰+3
figma3분 읽기큐레이션 요약

4년이 지난 지금, Config가

Config 2023 발표 제안 1,000여 건을 분석한 결과, 디자인 업계는 어려운 환경 속에서도 예상보다 낙관적인 태도를 보였다. 디자인 시스템은 창의성을 제한하기보다 반복 작업을 줄이고 새로운 아이디어를 위한 여유를 만드는 도구로 받아들여지고 있다. 다만 이 분석은 Config 제출작의 경향을 바탕으로 하므로 업계 전체를 대표하는 조사라기보다는 커뮤니티의 관심사를 보여주는 지표에 가깝다. ## Config 제안 수 증가와 분석 방식 - 발표 제안 수는 2021년 420건에서 2022년 520건, 2023년 1,000건 이상으로 크게 늘었다. - Figma는 제안서의 주제와 표현을 전년 대비 분석해 디자인·기술·제품 개발 분야의 관심 변화를 파악했다. - 제안 주제는 AI를 활용한 미래 구상, 디자인 시스템, 접근성, 협업 등 폭넓은 영역을 포함했다. - 많은 사람이 발표를 제안했다는 사실 자체가 커뮤니티의 참여 의욕과 관심이 높다는 신호로 해석됐다. ## 예상 밖의 낙관적 분위기 - 긍정적인 내용의 제안 비율은 2021년 63%에서 2023년 72%로 증가했다. - “지금이야말로 더 나은 시기다”, “이 방법 덕분에 성장할 수 있었다”와 같은 표현이 많이 등장했다. - 반대로 낡고 일관성 없는 디자인이나 해결되지 않는 문제를 비판하는 표현은 상대적으로 줄었다. - 팬데믹 관련 언급은 2021년의 6분의 1 수준으로 감소했다. - “remote”라는 단어의 등장도 2021년보다 약 20% 줄어들어, 업계 대화의 중심이 팬데믹과 원격근무의 충격에서 점차 이동했음을 보여준다. - 지난 몇 년의 혼란이 완전히 사라진 것은 아니지만, 사람들은 새로운 환경에 적응하며 문제보다 가능성에 더 집중하기 시작했다. ## 디자인 시스템과 창의성의 결합 - 디자인 시스템을 중시하는 사람과 자유로운 창작을 중시하는 사람 사이의 경계가 점차 약해지고 있다. - 디자인 시스템은 창의성을 억누르는 규칙이 아니라 반복적이고 소모적인 작업을 줄여 창작에 더 많은 시간을 쓰게 하는 기반으로 인식된다. - 디자인 토큰을 비롯한 시스템 자산을 축적하면 팀이 빠른 속도와 큰 규모로 작업하면서도 일관성을 유지할 수 있다. - 2021년 제안서는 디자인 시스템의 구축, 감사, 확장성 같은 기본 운영 문제를 주로 다뤘다. - 2023년에는 디자인 시스템과 함께 `art`, `transition`, `color`, `creating`처럼 표현적이고 시각적인 언어가 더 자주 등장했다. - 이는 디자인 시스템이 단순한 관리·표준화 도구를 넘어 새로운 아이디어를 생산하는 창의적 자산으로 발전하고 있음을 의미한다. ## 실용적인 시사점 디자인 조직은 시스템을 창의성의 반대편에 두기보다, 반복 업무를 자동화하고 일관성을 확보해 디자이너가 더 중요한 문제와 새로운 표현에 집중하도록 만드는 기반으로 활용할 수 있다. 또한 업계의 분위기를 판단할 때는 문제의 규모만 보기보다, 사람들이 어떤 해결책을 제안하고 어떤 가능성을 이야기하는지도 함께 살펴볼 필요가 있다.

원문 읽기(새 탭에서 열림)
접근성FigmaAI디자인 시스템+3
figma3분 읽기큐레이션 요약

디자인 시스템의 미래는 접근

디자인 시스템은 접근성을 제품 전반에 일관되게 적용할 수 있는 가장 강력한 기반이다. 공통 컴포넌트와 가이드에 접근성 기준을 내장하면 색상, 구조, 상호작용 등의 품질을 규모 있게 관리하고 변경 사항도 전체 제품에 전파할 수 있다. 앞으로는 WCAG 같은 표준과 AI 도구를 활용하되, 접근성을 사후 점검이 아닌 제품 개발 초기부터 우선순위로 삼아야 한다. ### 디자인 시스템과 접근성의 결합 - 전 세계 약 10억 명이 장애를 가지고 있으며, 이들의 연간 가처분소득은 약 1조 2천억 달러로 추정된다. - 접근성은 법적 의무나 체크리스트를 넘어 사용자 신뢰, 기업의 신뢰도, 성장 기회를 만드는 요소다. - 디자인 시스템에는 다음과 같은 접근성 기준을 포함할 수 있다. - 충분한 전경색·배경색 대비 - 접근성을 고려해 설계하고 테스트한 UI 컴포넌트 - 일관된 상호작용 규칙 - 구현자와 디자이너를 위한 구체적인 문서 - 공통 컴포넌트를 사용하면 한 번 수정한 접근성 개선 사항을 제품 전체의 컴포넌트 인스턴스에 확산할 수 있다. - 일관성, 문서화, 지속적인 피드백 구조가 접근성 실천을 조직 전체로 확장하는 기반이 된다. ### 접근성 확산을 돕는 디자인 시스템의 성장 - 2020년 Material Design 조사에서 기업 내부 디자인 시스템 구축은 전년 대비 22% 증가했다. - 응답자의 47%는 자신의 디자인 시스템에 접근성 가이드라인이 포함되어 있다고 답했다. - 디자인 시스템에 포함되는 대표 산출물은 다음과 같다. - 아이콘 라이브러리: 84% - UI 키트: 83% - 스타일 가이드: 75% - 컴포넌트 코드 라이브러리: 74% - WCAG 같은 표준, 접근성 도구의 발전, 법적·상업적 요구가 접근성 적용을 촉진하고 있다. - 그럼에도 2022년 기준 웹의 접근성 수준은 약 3%에 불과해, 실제 적용에는 여전히 큰 격차가 남아 있다. ### 접근성 분야의 책임 있는 AI 활용 - 디자인 시스템 팀은 AI를 활용해 접근성 문제를 더 빠르게 발견하고 개선하려 하고 있다. - 기사에서 언급하는 AI 기반 도구는 다음과 같은 작업을 자동화하는 것을 목표로 한다. - 이미지에 대체 설명 자동 생성 - 레이블이 없는 버튼에 적절한 레이블 추가 - 시맨틱 구조 도입 - 웹 접근성 문제 탐지 및 수정 - AI 도구는 접근성 검수와 반복 작업을 보조할 수 있지만, 자동화만으로 포괄적인 접근성을 보장할 수는 없다. - 생성된 설명이나 수정 결과가 실제 맥락에 적합한지 사람이 검토하고, 장애 당사자의 피드백과 표준 검사를 함께 활용해야 한다. ### 처음부터 접근 가능한 제품 만들기 - 접근성은 개발 완료 후 결함을 수정하는 단계가 아니라 디자인 시스템과 제품 설계 초기부터 포함해야 한다. - 공통 컴포넌트에 접근성 요구사항을 내장하면 개별 팀이 매번 같은 문제를 다시 해결하지 않아도 된다. - 색상, 컴포넌트 동작, 의미 구조, 문서화 등 모든 시스템 구성 요소에서 접근성을 점검해야 한다. - 접근성을 기본값으로 만들수록 제품 팀의 부담은 줄고, 전체 제품 생태계의 품질은 높아진다. ### 실용적인 적용 방향 - 디자인 토큰과 컴포넌트에 색상 대비, 키보드 탐색, 포커스 상태, 시맨틱 구조를 기본 규칙으로 포함한다. - WCAG 기준에 따라 자동 검사와 수동 테스트를 함께 운영한다. - AI는 반복적인 탐지·생성 작업에 활용하되 최종 판단은 전문가와 실제 사용자 검증을 거친다. - 접근성을 디자인 시스템의 부가 기능이 아니라 모든 컴포넌트의 필수 품질 기준으로 관리해야 한다.

원문 읽기(새 탭에서 열림)
접근성AI디자인 시스템wcag+2
figma4분 읽기큐레이션 요약

디자인 시스템의 미래는

플러그인, 위젯, AI 기반 도구의 발전으로 디자인 시스템은 단순한 컴포넌트 모음에서 반복 작업을 자동화하고 디자인 의사결정을 보조하는 실행 환경으로 진화하고 있다. 이러한 자동화는 디자이너와 개발자의 역할을 없애기보다, 생산성을 높이고 더 높은 수준의 문제 정의·판단·창의적 작업에 집중하게 만들 가능성이 크다. 다만 자동 생성 결과를 검토하고 맥락에 맞게 조정하는 인간의 역할은 여전히 중요하다. ## 플러그인과 위젯의 등장 - 플러그인은 기존 소프트웨어의 기능을 확장하는 추가 도구이며, 디자인 소프트웨어와 함께 발전해 왔다. - 초기 플러그인은 텍스트 편집기와 출판 프로그램에서 효과, 브러시, 스타일 등을 추가하는 방식으로 사용됐다. - 오늘날에는 커뮤니티와 앱 마켓플레이스를 통해 사용자가 직접 만든 도구를 공유하고, 팀의 작업 방식에 맞게 Figma를 확장한다. - 디자인 시스템 관련 플러그인은 크게 두 유형으로 나뉜다. - 기존 작업 흐름을 자동화하는 도구 - 분석, 테스트, 접근성 개선 등 새로운 기능을 추가하는 도구 ## 반복 작업을 자동화하는 플러그인 - 여러 화면에 동일한 변경 사항을 적용하거나, 레이어와 컴포넌트를 정리하는 반복 업무를 자동화한다. - 디자인 토큰, 컴포넌트, 스타일을 일관되게 적용해 수작업에서 발생하는 누락과 실수를 줄인다. - 콘텐츠 삽입, 레이아웃 정리, 이름 변경, 문서화와 같은 작업도 자동화 대상이 될 수 있다. - 디자이너는 단순한 실행 업무보다 사용자 경험과 제품 문제를 정의하는 일에 더 많은 시간을 쓸 수 있다. ## 기능을 확장하는 플러그인 - 플러그인은 디자인 시스템의 사용 현황과 품질을 점검하는 기능을 제공한다. - 어떤 컴포넌트가 얼마나 사용되는지, 디자인 시스템이 실제 파일에서 제대로 활용되는지 분석할 수 있다. - 접근성 검사, 디자인 테스트, 개발 handoff, 코드 생성 등 기존 디자인 도구가 직접 제공하지 않던 기능도 보완한다. - 결과적으로 디자인 시스템은 정적인 라이브러리가 아니라 측정·검증·개선이 가능한 운영 체계가 된다. ## 정보를 시각화하고 정리하는 위젯 - 위젯은 캔버스 안에서 실행되는 상호작용형 도구로, 디자인 파일에 정보와 기능을 직접 배치할 수 있다. - 팀의 작업 현황, 의사결정, 일정, 피드백 등을 시각적으로 공유하는 데 활용된다. - 디자인 시스템의 규칙이나 컴포넌트 정보를 작업 공간 가까이에서 확인하게 해 협업과 커뮤니케이션을 돕는다. - 디자인 파일이 단순히 결과물을 보여주는 공간을 넘어, 팀이 함께 사고하고 정리하는 협업 공간으로 확장된다. ## AI가 강화하는 디자인 도구 - 2017년부터 저해상도 와이어프레임을 바탕으로 디자인 시스템과 코드를 자동 생성하려는 실험이 진행됐다. - 당시에는 가능성을 보여주는 프로토타입에 가까웠지만, 생성형 AI 기술의 발전으로 실제 제품화 가능성이 커졌다. - Diagram의 Genius와 같은 도구는 Figma 파일을 분석하고, 기존 디자인 시스템의 컴포넌트를 활용한 디자인 제안을 생성한다. - AI는 다음과 같은 작업을 보조할 수 있다. - 자연어를 기반으로 한 디자인 생성 - 기존 컴포넌트와 패턴 추천 - 디자인 파일 분석 및 개선안 제시 - 디자인에서 코드로의 변환 - AI가 디자인 시스템의 규칙을 학습할수록, 조직의 브랜드와 패턴에 맞는 결과를 더 빠르게 만들 수 있다. ## 자동화에 뒤처지지 않기 위한 변화 - 도구가 발전하면 디자인 시스템 팀은 새로운 플러그인과 AI 기능을 단순히 도입하는 것을 넘어, 조직의 작업 흐름에 어떻게 연결할지 고민해야 한다. - 자동화의 효과를 높이려면 컴포넌트, 스타일, 변수, 명명 규칙이 체계적으로 정리되어 있어야 한다. - 디자인 시스템이 일관되지 않거나 문서화가 부족하면 AI와 자동화 도구도 부정확한 결과를 낼 수 있다. - 따라서 자동화는 잘 정립된 시스템을 대체하기보다, 품질 높은 시스템을 더 넓고 빠르게 활용하도록 돕는 방식으로 작동한다. ## 인간 디자이너의 역할 - 자동화가 작업의 일부를 대신하더라도 문제의 맥락을 이해하고 우선순위를 정하는 일은 여전히 인간에게 요구된다. - AI는 여러 결과를 빠르게 생성할 수 있지만, 어떤 결과가 사용자와 비즈니스에 적합한지 판단하지는 못한다. - 디자이너의 역할은 픽셀을 직접 배치하는 일에서 다음과 같은 업무로 확장될 수 있다. - 올바른 문제 정의 - 사용자 요구와 비즈니스 목표의 조율 - 생성 결과의 평가와 수정 - 디자인 시스템의 원칙과 품질 관리 - 새로운 도구와 협업 방식의 설계 - 자동화는 디자이너를 없애기보다, 디자이너가 더 전략적이고 창의적인 역할을 수행하도록 업무의 성격을 바꿀 가능성이 크다. 실무에서는 반복 작업부터 플러그인으로 자동화하되, 컴포넌트와 디자인 토큰을 먼저 정비하는 것이 좋다. AI가 생성한 결과는 초안으로 활용하고, 접근성·일관성·사용자 맥락을 사람이 반드시 검토해야 한다.

원문 읽기(새 탭에서 열림)
접근성FigmaAI디자인 시스템+4
figma3분 읽기큐레이션 요약

비하인드 스토리: 국제 키

Figma는 미국 키보드 기준으로 설계된 단축키가 국제 키보드 사용자에게 작동하지 않는 문제를 해결하기 위해 1년간 단축키 시스템을 개선했다. 문제는 단순히 키 조합을 추가하는 것이 아니라, 브라우저의 키보드 이벤트 처리, 문자 정규화, 키보드 레이아웃 감지 등 여러 계층에 걸쳐 있었다. 특히 독일어 `ß`처럼 대소문자 변환만으로는 안전하게 처리할 수 없는 문자와 수천 가지 키보드 레이아웃이 복잡성을 높였다. ### 국제 키보드에서 발생한 단축키 문제 - Figma의 기존 단축키는 미국 키보드를 기준으로 설계되었다. - 일부 사용자는 키보드에 존재하지 않는 키를 요구받았다. - `⌘ + \`로 UI를 전환해야 하지만 `\` 키가 없는 경우 - `/` 키를 누를 수 없어 Cursor Chat을 시작할 수 없는 경우 - 단축키는 작업 효율성과 접근성에 중요한 기능이므로, 모든 지역의 사용자가 동일한 기능을 이용할 수 있어야 했다. - 이를 해결하기 위해 에디터 사용성 팀을 중심으로 여러 직군이 참여한 프로젝트가 시작되었다. ### Figma의 단축키 처리 구조 - 사용자가 키를 누르면 브라우저가 `KeyboardEvent`를 Figma에 전달한다. - Figma는 이벤트를 에디터가 해석할 수 있는 내부 표현으로 변환한다. - 가능한 단축키와 실행할 동작은 JSON 파일에 정의되어 있다. - 단축키 활성화 여부는 다음과 같은 상태에 따라 달라진다. - 사용자 설정 - 현재 사용 중인 Figma 제품 - 운영체제 - 기타 제품 상태 - 입력된 키 조합을 정의된 단축키 목록과 비교해 일치하면 해당 동작을 실행한다. ### 단순한 단축키 추가로 해결되지 않은 이유 - 처음에는 키보드별 대체 조합을 JSON에 추가하면 될 것처럼 보였다. - 스웨덴어 키보드: `⌘ + ]` 대신 `Meta + Ä` - 한국어 키보드: `⌘ + \` 대신 `₩` - 그러나 단축키를 정규화하는 과정에서 언어별 문자의 특수성이 드러났다. - 독일어 키보드의 `Meta + Alt + ß`를 처리할 때 JavaScript의 `"ß".toUpperCase()`가 `SS`로 변환되었다. - 하나의 키 문자가 두 글자로 늘어나면서 단일 키 단축키라는 전제가 깨졌다. - 더 나아가 `"ß".toUpperCase().toLowerCase()`도 원래의 `ß`로 되돌아가지 않았다. - Figma는 대문자 에스체트인 `ẞ`를 사용해 우회했다. - `ẞ`는 대문자로 변환해도 동일하게 유지된다. - 이 문자는 2017년 독일 철자위원회에서 공식 채택되었지만, 프로그래밍 언어와 도구의 지원은 아직 완전하지 않았다. ### 키보드 레이아웃 감지의 어려움 - 전 세계에는 매우 많은 키보드 레이아웃이 있어, 처음부터 모두 지원하기는 어려웠다. - Figma는 사용자가 많이 사용하는 레이아웃부터 지원하기로 했다. - 데스크톱 앱에서는 운영체제의 키보드 설정을 직접 감지할 수 있었다. - 브라우저에서는 운영체제 정보를 충분히 얻기 어려워 실험적인 Keyboard API와 휴리스틱을 사용했다. - API가 제공하는 키 위치별 문자를 알려진 레이아웃과 비교해 사용자의 레이아웃을 추정했다. - 예를 들어 `Quote` 키 위치에 `ä`가 입력되는지 확인하고 다른 키 정보와 조합해 스웨덴어 키보드인지 추론한다. - 실제 사용 데이터를 수집한 결과, 30일 동안 Figma에서 2,500개가 넘는 서로 다른 키보드 레이아웃이 관찰되었다. - 이는 키보드 레이아웃의 다양성이 예상보다 훨씬 크며, 국제 단축키 지원이 단순한 지역별 매핑 이상의 문제임을 보여준다. 국제 키보드 단축키를 설계할 때는 특정 국가의 키 조합을 추가하는 데 그치지 말고, 문자 정규화의 언어적 예외, 브라우저와 데스크톱 환경의 감지 차이, 레이아웃의 폭넓은 다양성을 함께 고려해야 한다. 특히 키 이름이나 문자를 문자열로만 처리하면 `ß` 사례처럼 예기치 않은 변환이 발생할 수 있으므로, 키 위치와 입력 문자를 구분하는 견고한 설계가 필요하다.

원문 읽기(새 탭에서 열림)
접근성jsoninternationalizationkeyboardevents+3
figma3분 읽기큐레이션 요약

디자인 시스템의 미래는 복잡

디자인 시스템은 제품과 사용자 요구가 복잡해질수록 단순한 시각 규칙 모음이 아니라, 여러 팀과 시스템을 조율하는 운영 구조가 되어야 한다. 브랜치·머지, 로컬 시스템, 오픈소스 같은 코드의 방식을 활용하면 확장성과 협업을 높일 수 있지만, 지나친 규제는 창의성과 실험을 막는다. 따라서 미래의 디자인 시스템은 구조와 유연성 사이의 균형을 지속적으로 조정해야 한다. ## 디지털 제품의 복잡성과 디자인 시스템의 변화 - 초기 디자인 시스템은 사용자가 디지털 인터페이스를 이해하도록 돕는 시각적 은유에 크게 의존했다. - Google Material Design은 종이를 쌓은 듯한 표면, 가장자리, 그림자를 사용해 조작 가능한 요소를 설명했다. - 당시에는 완전한 스큐어모피즘 없이도 사용자가 인터페이스를 직관적으로 이해하도록 만드는 것이 주요 과제였다. - 그러나 다양한 디바이스와 폼팩터가 등장하면서 단일 은유만으로는 충분하지 않게 됐다. - 접근성 기준 - 새로운 입력 방식과 상호작용 - 성능 요구사항 - 여러 화면과 플랫폼에 대응하는 반응형 경험 - Instagram처럼 하나의 핵심 기능만 제공하던 앱도 검색, 광고, 파트너십, 쇼핑 등으로 확장됐다. - 이에 따라 디자인 시스템은 더 많은 기능과 사용자 유형, 서로 연결된 제품 경험을 지원해야 한다. ## 구조로 혼란 다루기 - 디자인팀은 소프트웨어 개발에서 사용하던 프로세스와 프레임워크를 디자인 시스템에 적용하고 있다. - 대표적인 방식이 브랜치와 머지다. - 기여자가 별도의 브랜치에서 새로운 컴포넌트나 수정안을 작업한다. - 기존의 메인 시스템에 영향을 주지 않고 실험할 수 있다. - 디자인 시스템 관리자가 변경 사항을 검토한 뒤 공식 시스템에 반영한다. - 이 방식은 디자인 시스템을 중앙 팀만 관리하는 자산이 아니라, 커뮤니티와 함께 발전시키는 구조로 만든다. - Spotify의 Encore는 하위 팀이 시스템을 포크해 각자의 “로컬 시스템”을 만들도록 허용했다. - 광고 팀의 비디오 플레이어처럼 특정 도메인에 특화된 컴포넌트가 발전했다. - 이러한 결과물이 다시 전체 디자인 시스템의 방향과 적용 범위를 넓혔다. - 오픈 디자인 시스템은 외부 기여와 피드백을 받을 수 있다는 장점이 있다. - 다양한 사용자의 요구를 파악할 수 있다. - 제품과 조직의 작업 방식을 공개해 신뢰와 인지도를 높인다. - 디자인 지식을 업계와 공유할 수 있다. ## 지나치게 엄격한 시스템의 문제 - 구조를 규모 있게 적용하면 일관성은 높아지지만, 시스템이 지나치게 제한적으로 변할 수 있다. - 디자이너는 다음과 같은 문제를 경험할 수 있다. - 새로운 아이디어를 실험하기 어려움 - 제품 특성에 맞는 예외를 만들기 어려움 - 기존 컴포넌트에 억지로 맞추느라 디자인 품질이 떨어짐 - 디자인 시스템의 목적은 창의적 표현의 진입장벽을 낮추는 것이지, 창작 자체를 어렵게 만드는 것이 아니다. - 모든 상황을 사전에 정의하려는 접근은 복잡한 제품과 예상하지 못한 사용자 요구에 제대로 대응하지 못한다. ## 건축보다 정원에 가까운 운영 - Shopify의 José Torre는 디자인 시스템을 완성 후 고정하는 건축물보다 계속 돌보고 변화하는 정원에 비유한다. - 건축적 접근: - 세부 사항을 미리 결정한다. - 설계와 구축이 끝나면 결과물을 완성된 상태로 간주한다. - 정원식 접근: - 기본적인 씨앗과 구조를 심되, 최종 형태는 성장 과정에서 발견한다. - 실제 사용 중 나타나는 문제와 새로운 요구에 따라 개입한다. - 불필요한 요소는 제거하고 유용한 패턴은 발전시킨다. - 계획된 디자인 시스템 안에서도 새로운 버튼이나 메뉴 변형이 자연스럽게 등장할 수 있다. - 이런 변형을 무조건 제거하기보다, 실제 제품 요구에서 비롯된 것인지 평가하고 필요하다면 시스템에 흡수하는 유연성이 중요하다. 디자인 시스템은 엄격한 규칙집이 아니라 제품과 조직의 변화에 맞춰 계속 진화하는 기반으로 운영하는 것이 바람직하다. 공통 구조와 검토 절차는 유지하되, 브랜치·로컬 시스템·실험 공간을 허용해 팀의 자율성과 창의성을 보장해야 한다.

원문 읽기(새 탭에서 열림)
접근성디자인 시스템오픈 소스material-design+1
figma3분 읽기큐레이션 요약

Schema 2022 미리 보기

Figma의 연례 디자인 시스템 콘퍼런스 Schema 2022는 디자인 시스템의 구체적인 과제와 기회를 깊이 다루기 위해 뉴욕, 런던, 도쿄 및 온라인에서 개최된다. 글은 행사 일정뿐 아니라 디자인·개발 협업, 디자인 토큰, 플러그인과 통합 등 주요 관심사를 소개하며, 다양한 수준의 참가자가 배울 수 있도록 프로그램을 구성했다고 설명한다. 행사의 발표 영상은 이후 DesignSystems.com에 공개되었다. ### 도시 순회 및 온라인 행사 - Schema 2022는 다음 방식으로 진행된다. - 뉴욕, 런던, 도쿄에서 오프라인 행사 개최 - 장소와 관계없이 참여할 수 있는 온라인 행사 제공 - 각 도시 행사는 해당 지역과 연사에 맞춘 개별 프로그램으로 구성된다. - 오프라인 행사는 초청제로 운영되지만 참가 신청이 가능하다. - 각 도시에서는 지역 디자인 커뮤니티를 위한 밋업도 열린다. - 온라인 콘퍼런스는 오프라인 참석이 어려운 사람도 참여할 수 있도록 공개된다. ### 디자인 시스템에 집중한 전문 콘퍼런스 - Config가 디자인 전반을 다룬다면, Schema는 디자인 시스템에 초점을 맞춘 보다 전문적인 행사다. - 디자인 시스템의 고유한 기회와 문제를 깊이 탐구할 수 있다는 점이 Schema의 특징이다. - 주제가 구체적이기 때문에 연사와 참가자가 다음과 같은 논의에 집중할 수 있다. - 디자인 시스템 구축과 운영 - 조직 내 협업 방식 - 디자인 시스템의 확장과 활용 - 동시에 디자인 시스템을 처음 접하는 사람과 숙련된 실무자 모두에게 의미 있는 발표를 제공하는 것이 프로그램 구성의 과제다. - 발표 내용은 새롭고 혁신적이어야 하면서도, 디자인 시스템의 기본 개념을 배우려는 사람도 이해할 수 있어야 한다. ### 디자이너와 개발자의 창의적 교류 - 디자인 시스템은 디자인뿐 아니라 개발, 도구 제작, 조직 협업 등 다양한 역량을 필요로 한다. - Schema는 디자이너와 개발자가 서로의 작업과 아이디어를 공유하는 공간으로 기능한다. - 디자이너는 다음과 같은 주제에 대해 아이디어를 나눌 수 있다. - 플러그인 - 확장 기능 - 외부 서비스 및 도구와의 통합 - 개발자는 자신들이 구축한 도구와 시스템을 소개하며 디자인 분야와 연결점을 찾는다. - 이러한 상호작용을 통해 디자인 시스템이 단순한 시각 요소 모음이 아니라, 여러 직군이 함께 발전시키는 기술·프로세스라는 점이 드러난다. ### W3C 디자인 토큰 커뮤니티 그룹 - 디자인 토큰은 특정 도구나 플랫폼에 종속되지 않고 디자인 스타일을 관리·공유하기 위한 방법론이다. - 디자인 토큰은 여러 도구, 디바이스, 플랫폼에서 디자인을 확장하는 데 활용될 수 있다. - W3C Design Tokens Community Group은 다음을 목표로 한다. - 디자인 시스템의 스타일 정보를 도구 간에 공유할 수 있는 표준 마련 - 제품과 디자인 도구가 대규모로 디자인 토큰을 활용할 수 있는 기반 제공 - 디자인 토큰은 디자이너와 개발자가 공통의 언어로 시스템을 다루게 하는 연결 고리로 소개된다. - 표준화 논의에서는 특히 다음과 같은 주제를 장기적으로 고려한다. - 국제화 - 접근성 - 다양한 플랫폼과 환경에서의 일관성 ### 실무적 시사점 디자인 시스템을 도입하거나 확장하려는 팀이라면 시각 디자인 요소뿐 아니라 개발자 핸드오프, 도구 간 통합, 디자인 토큰의 표준화까지 함께 고려해야 한다. 특히 디자이너와 개발자가 초기부터 공통 언어와 공유 가능한 토큰 체계를 마련하면 여러 제품과 플랫폼으로 시스템을 확장하기 쉬워진다.

원문 읽기(새 탭에서 열림)
접근성Figma디자인 시스템디자인 토큰+2
figma3분 읽기큐레이션 요약

다크 모드 밝히

Figma의 다크 모드는 색상만 어둡게 바꾸는 단순한 프런트엔드 작업이 아니라, 제품 전반의 UI 상태와 접근성, 향후 테마 확장성을 함께 해결해야 하는 시스템 구축 프로젝트였다. Figma는 사용자 요청에 대응하는 동시에 시각적 접근성을 높이고, 새로운 기능이 처음부터 다크 모드를 지원하도록 만드는 것을 목표로 했다. 이를 위해 전체 UI를 조사하고 여러 팀의 공통 컴포넌트를 체계적으로 refactoring하는 방식을 택했다. ## 다크 모드가 필요했던 이유 - 다크 모드는 Figma 사용자들이 가장 많이 요청한 기능 중 하나였다. - 야간 작업 시 밝은 화면으로 인한 불편을 줄일 수 있었다. - 시각 장애나 특정 시각적 질환이 있는 사용자에게 다크 모드가 더 읽기 쉬울 수 있었다. - 색상 대비는 WCAG 접근성 지침의 핵심 요소이므로, 다크 모드는 Figma의 “디자인을 모두에게 accessible하게 만든다”는 목표와도 연결됐다. - 일반적으로는 라이트 모드가 시각적 수행 능력에 유리하지만, 백내장 등 특정 질환이 있는 사람은 다크 모드에서 더 나은 성능을 보일 수 있다. ## 단순한 색상 교체가 아니었던 이유 - 처음에는 모든 밝은 색을 어두운 색으로 바꾸면 된다고 생각했지만, 실제로는 UI의 상태와 맥락을 함께 고려해야 했다. - 다크 모드 전환 시 다음 요소를 결정해야 했다. - 밝은 편집기 패널을 어둡게 바꾸고 아이콘과 텍스트를 밝게 할지 - 라이트 모드에서도 이미 어두운 툴바와 메뉴를 그대로 유지할지 - 캔버스 배경처럼 사용자가 만든 콘텐츠까지 테마에 따라 변경할지 - C++ 렌더링 엔진이 그리는 투명도 격자 등의 색상도 변경할지 - Figma 전체가 아니라 편집기 등 특정 영역만 지원할지에 대한 제품 범위 결정도 필요했다. ## 전체 UI 감사와 범위 설정 - 개발에 앞서 각 팀원이 Figma 앱의 UI 표면을 조사하고, 다크 모드로 재구성하기 어려운 부분을 파악했다. - 프로젝트 시작 당시 Figma에는 10개의 제품 엔지니어링 팀이 있었고, 각 팀이 모달, 패널, 툴바 등 주요 UI 영역을 담당했다. - 하나의 UI 요소도 여러 상태와 복잡한 예외 상황을 포함할 수 있었다. - 특정 조건에서만 나타나는 상태 - 여러 뷰와 화면 - 숨겨진 서브모달과 드롭다운 - 따라서 표면적으로 보이는 화면뿐 아니라 모든 상태와 엣지 케이스까지 다크 모드 범위에 포함해야 했다. ## 확장 가능한 테마 시스템의 목표 - 목표는 현재 다크 모드만 구현하는 것이 아니었다. - 두 가지 장기 목표를 세웠다. - 개발자가 새로운 기능을 다크 모드 지원과 함께 바로 만들 수 있도록 하기 - 향후 Figma와 FigJam에 새로운 테마를 쉽게 추가할 수 있도록 하기 - 공통 UI 컴포넌트는 다크 모드를 지원해야 하지만, 다크 모드가 적용되지 않는 화면에서는 기존 동작과 외관을 유지해야 했다. - 구현 과정에서 기존 기능을 깨뜨리지 않는 회귀 방지(regression-proof) 구조가 중요했다. - 새로운 엔지니어의 온보딩과 향후 예측하지 못한 요구사항 대응까지 고려해, 적용과 유지보수가 쉬운 방식이 필요했다. ## 프로젝트 규모가 만든 엔지니어링 과제 - Figma의 UI가 여러 팀에 분산되어 있어 소수의 엔지니어만으로 전체를 처리하기 어려웠다. - 각 팀이 소유한 컴포넌트와 화면을 공통 원칙에 맞게 바꿔야 했다. - 단순히 색상 값을 교체하는 것이 아니라, 컴포넌트가 어떤 표면과 상태에서 사용되는지까지 체계적으로 분리해야 했다. - 이 경험은 개별 기능을 추가하는 방식보다, 제품 전체에서 재사용할 수 있는 디자인·엔지니어링 시스템을 구축하는 접근이 필요하다는 점을 보여준다. 다크 모드처럼 겉보기에는 간단한 기능도 실제로는 UI 상태, 접근성, 팀 간 소유권, 공통 컴포넌트, 향후 확장성을 함께 설계해야 한다. 유사한 기능을 구현할 때는 특정 화면의 색상부터 바꾸기보다 전체 범위를 먼저 감사하고, 테마 토큰과 공통 컴포넌트를 중심으로 회귀를 방지할 수 있는 구조를 마련하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
접근성디자인 시스템사용자 인터페이스wcag+2
figma3분 읽기큐레이션 요약

lli Type으로 본격적인

가변 폰트는 하나의 파일로 다양한 굵기·기울기·광학 크기 등을 조정할 수 있어, 타이포그래피의 정밀도와 표현력을 높이는 표준 기술이다. Grilli Type의 Thierry Blancpain은 가변 폰트가 디자이너와 개발자의 협업을 단순화하고, 웹을 더 역동적이고 읽기 쉬운 경험으로 만드는 핵심 도구라고 설명한다. 특히 디자인 도구에서 가변 폰트를 직접 지원해야 실제 구현 과정의 간극과 불필요한 우회 작업을 줄일 수 있다고 강조한다. ## 폰트 크기 변화와 가독성의 문제 - 명함에서 광고판으로, 모바일에서 데스크톱으로 글자 크기가 커지면 글자 사이의 공간감과 비율도 달라진다. - 특정 크기에서 읽기 쉬웠던 문장이 다른 크기에서는 형태가 무너지고 가독성이 떨어질 수 있다. - 크기와 가독성을 유지하려면 다음 요소를 세밀하게 조정해야 한다. - **커닝(kerning):** 개별 글자 사이의 간격 - **트래킹(tracking):** 글자 묶음 전체의 간격 - 굵기와 스타일별로 별도 파일을 사용하면 에셋과 코드가 늘어나고, 다운로드 용량·관리 복잡성·오류 가능성이 커진다. ## 하나의 파일로 여러 표현을 만드는 가변 폰트 - 가변 폰트는 여러 스타일을 각각 저장하는 대신, 하나의 폰트 파일 안에 다양한 표현 범위를 담는다. - 디자이너는 축(axis)을 조절해 다음과 같은 속성을 연속적으로 변경할 수 있다. - 굵기(weight) - 기울기나 경사(slant) - 광학 크기(optical size) - 그 밖의 폰트 제작자가 정의한 형태적 특성 - 굵기와 광학 크기를 동시에 조절하는 등 기존 정적 폰트보다 정밀한 타이포그래피 설계가 가능하다. - 하나의 파일을 여러 도구와 환경에서 사용할 수 있어, 애플리케이션별 폰트 버전을 따로 준비해야 하는 문제도 줄어든다. ## 현대적인 디자인 표준과 도구 지원 - Blancpain은 가변 폰트가 새로운 표준 형식이므로, Figma 같은 주요 디자인 도구가 이를 지원하는 것이 중요하다고 말한다. - 도구가 표준 형식을 지원하지 않으면 디자이너와 개발자는 별도 변환이나 우회 방법을 찾아야 한다. - Grilli Type은 과거 Figma에서 가변 폰트를 사용할 수 없을 때도 가변 폰트 기반 웹사이트를 제작했지만, 디자이너와 개발자가 분리된 조직에서는 이런 방식이 현실적으로 어렵다고 설명한다. - Figma에서 디자인 단계부터 가변 폰트를 사용하면 최종 코드 구현까지 동일한 타이포그래피 의도를 유지하기 쉬워진다. ## 디자이너와 개발자의 협업 개선 - 개발자에게는 폰트 패밀리 전체를 하나의 파일로 관리할 수 있다는 점이 큰 장점이다. - 파일 업데이트가 단순해진다. - 코드와 에셋 관리가 깔끔해진다. - 여러 폰트 파일을 조합할 때 생기는 관리 오류가 줄어든다. - 디자이너는 원하는 굵기나 광학 크기를 세밀하게 선택할 수 있다. - 가변 폰트는 디자이너에게 표현의 자유를, 개발자에게는 구현과 유지보수의 효율성을 제공한다. - 따라서 두 직군이 서로 다른 도구와 파일을 사용하며 생기는 간극을 줄여준다. ## 웹 타이포그래피의 동적 표현 - 가변 폰트는 웹에서 글자를 단순한 정보 전달 수단이 아니라 시각적 표현 요소로 활용하게 한다. - 예를 들어 마우스 오버 시 일반 굵기에서 굵은 글씨로 자연스럽게 전환하는 효과를 만들 수 있다. - `GT Maru Mega`처럼 매우 개성적인 서체도 작은 크기에서 사용할 수 있도록 형태와 광학 특성을 조정할 수 있다. - 폰트 축을 애니메이션과 결합하면 정적인 웹사이트보다 더 생동감 있고 상호작용적인 경험을 제공할 수 있다. - Blancpain은 웹 경험이 점점 더 움직임을 포함하는 방향으로 발전할 것이라고 전망한다. ## 실용적인 결론 가변 폰트는 파일 수를 줄이는 기술을 넘어, 반응형 화면에 맞는 가독성과 정밀한 타이포그래피, 인터랙션까지 함께 구현하는 방법이다. 디자이너와 개발자는 가능한 한 디자인 단계부터 동일한 가변 폰트를 사용하고, 굵기·광학 크기·기울기 축을 화면 크기와 사용자 상호작용에 맞춰 활용하는 것이 좋다.

원문 읽기(새 탭에서 열림)
접근성Figma사용자 경험typography+3
figma3분 읽기큐레이션 요약

접근성 향상을 위한

Figma는 디자인을 모든 사람이 참여할 수 있게 만드는 것을 목표로 하며, 이를 위해 시각장애·저시력 사용자를 위한 프로토타입 스크린 리더 베타를 발표했다. Figma 디자인은 일반 HTML이 아니어서 기존 스크린 리더가 내용을 읽기 어려웠지만, 프로토타입을 스크린 리더 전용 HTML로 변환하는 방식으로 문제를 해결했다. 이는 중요한 진전이지만, ARIA 역할·탭 순서·대체 텍스트 설정 등 접근성 지원을 확대하기 위한 추가 과제가 남아 있다. ## 프로토타입 스크린 리더 베타 - 기존에는 시각장애 사용자가 Figma 프로토타입을 열어도 스크린 리더에 “빈 캔버스” 레이블만 표시됐다. - 텍스트, 이미지, 버튼 등 프로토타입의 핵심 콘텐츠를 스크린 리더가 인식하지 못하는 문제가 있었다. - 베타 기능은 다음을 지원한다. - 텍스트 노트 읽기 - 이미지 대체 텍스트(alt text) 읽기 - 버튼과 키보드 동작을 통한 프로토타입 탐색 - Tab 키 등을 이용한 키보드 내비게이션 - 2022년 8월 업데이트를 통해 이 기능은 모든 사용자가 이용할 수 있는 오픈 베타로 전환됐다. ## Figma 디자인을 HTML로 변환하는 방식 - Figma는 웹 기반 애플리케이션이지만 디자인 결과물이 일반적인 HTML 요소로 그려지지 않는다. - 따라서 대부분의 스크린 리더가 Figma 캔버스의 텍스트와 인터페이스 구조를 직접 해석할 수 없었다. - Figma는 프로토타입을 스크린 리더 전용 HTML 표현으로 변환해 보조공학 기술에 제공하는 구조를 구현했다. - 이 변환 계층을 통해 스크린 리더가 화면에 표시된 콘텐츠와 상호작용 요소를 읽고 탐색할 수 있게 됐다. ## 함께 진행된 접근성 개선 - 다크 모드와 색상 대비 개선을 통해 다양한 시각적 요구를 지원했다. - WCAG 3.0 초안 기준에 부합하도록 색상 대비 준수를 강화했다. - Figma 데스크톱 앱과 Pro·Org·Enterprise 요금제에서 오디오 채팅 실시간 자막 기능을 오픈 베타로 제공했다. - Deque의 플랫폼 전반 접근성 평가를 받아 다음과 같은 개선 영역을 확인했다. - 키보드만으로 기능을 사용할 수 있도록 개선 - ARIA 레이블을 모범 사례에 맞게 적용 - Adee, Deque, Stark 등의 플러그인과 커뮤니티 파일을 통해 색상 대비 검사 등 접근성 도구 생태계도 확대되고 있다. ## 개발 프로세스에 접근성을 내재화 - Figma는 팀이 접근성을 고려하도록 권장하는 수준을 넘어, 제품을 설계·개발할 때 접근성을 필수적으로 반영하도록 하고 있다. - 키보드 전용 사용자와 스크린 리더 사용자를 지원하는 재사용 가능한 UI 컴포넌트를 제작하고 있다. - 새 기능과 코드가 접근성 모범 사례를 따르는지 확인할 수 있는 내부 도구도 개발 중이다. - 알파·베타 테스트에 접근성 사용자를 조기에 참여시켜 실제 사용 경험을 설계 과정에 반영하고 있다. ## 남은 과제 - 사용자가 디자인 요소에 직접 대체 텍스트를 지정할 수 있도록 해야 한다. - 컴포넌트에 ARIA 역할을 설정하는 기능이 필요하다. - 프로토타입 요소의 키보드 탭 순서를 지정할 수 있어야 한다. - 스크린 리더 지원은 시작 단계이며, 커뮤니티와 지속적으로 테스트하고 피드백을 받아 개선해야 한다. 실용적으로는 Figma에서 프로토타입을 제작할 때 이미지에 의미 있는 대체 텍스트를 제공하고, 키보드만으로 탐색 가능한 흐름과 충분한 색상 대비를 함께 검토하는 것이 권장된다.

원문 읽기(새 탭에서 열림)
접근성HTMLwcagkeyboard-navigation+3
figma3분 읽기큐레이션 요약

모션의 예술과 영향력

디지털 제품의 모션은 장식이 아니라 사용자의 이해를 돕고, 상태와 피드백을 전달하며, 물리적 세계와 유사한 정신 모델을 형성하게 하는 중요한 설계 도구다. 좋은 애니메이션은 실용성과 개성을 함께 갖추되 사용자의 시간을 존중하고 방해하지 않아야 한다. 특히 접근성을 해치거나 불필요하게 산만한 모션은 제품 경험과 브랜드 인상을 악화시킬 수 있다. ## 물리적 세계를 디지털 경험으로 번역하는 모션 - 인간은 3차원적이고 움직임이 존재하는 물리적 환경에 적응해 왔기 때문에, 움직임을 통해 많은 의미를 직관적으로 해석한다. - 디지털 인터페이스에 모션을 추가하면 사용자가 별도의 설명 없이도 공간과 기능을 이해하는 데 도움이 된다. - 예를 들어 메뉴가 서랍처럼 열리고 닫히는 애니메이션은 다음과 같은 정신 모델을 전달한다. - 콘텐츠 상자가 열리고 닫힌다. - 다시 열어도 이전과 같은 내용이 있다. - 사용자가 인터페이스의 상태 변화를 예측할 수 있다. - 모션은 디지털 공간에서 “무엇이 일어나고 있는지”를 시각적으로 설명하는 역할을 한다. ## 상태와 피드백을 전달하는 움직임 - 로딩 바는 작업이 진행 중이며 곧 완료될 것이라는 정보를 제공한다. - 잘못된 비밀번호 입력 시 입력창이 흔들리는 효과는 고개를 젓는 동작처럼 오류를 직관적으로 전달한다. - 새로고침 후 차트나 그래프가 재배치되는 애니메이션은 데이터가 갱신되었다는 사실을 보여준다. - FigJam 타이머의 종료 시 흔들리는 축하 애니메이션처럼, 모션은 단순한 상태 전달을 넘어 감정과 분위기도 만들 수 있다. - Figma의 커서 채팅에서는 입력 중인 대화 말풍선이 커지며, 즉흥적이고 자연스러운 대화감을 형성한다. ## 마이크로애니메이션은 목적 중심으로 설계해야 한다 - 마이크로애니메이션은 짧은 시간 동안 UI를 활성화하거나 사용자의 흐름을 안내하는 움직임이다. - 아이콘을 의미 없이 추가하지 않듯, 애니메이션도 “움직임을 넣기 위해” 넣어서는 안 된다. - 각각의 애니메이션은 구체적인 사용자 문제를 해결해야 한다. - 오래된 백엔드 시스템 때문에 발생하는 처리 지연을 1~2초의 전환 애니메이션으로 자연스럽게 감출 수 있다. - 이때 애니메이션은 실제 처리 속도를 높이지 않더라도 제품이 더 빠르고 덜 끊기는 것처럼 느끼게 한다. ## 실용성과 개성을 함께 갖춘 좋은 모션 - 좋은 모션은 기능적 목적과 제품의 개성을 균형 있게 결합한다. - 사용자의 시간을 존중하고, 주의를 빼앗거나 작업을 지연시키지 않아야 한다. - 애플의 창 최소화 애니메이션은 창이 독의 아이콘 속으로 빨려 들어가는 듯한 효과를 보여준다. - 이 효과는 짧고 미묘하지만 다음 정보를 동시에 전달한다. - 창이 어디로 이동했는지 - 창을 다시 열려면 어떤 아이콘을 눌러야 하는지 - 창이 사라진 것이 아니라 보관되었다는 사실 - 다시 창을 열 때는 아이콘에서 창이 자라나는 듯한 역방향 애니메이션을 사용해 상태 변화의 연속성을 보여준다. ## 과도한 모션과 접근성 문제 - 애니메이션이 없어도 핵심 기능을 사용할 수 있도록 설계해야 한다. - 특정 움직임은 간질 환자 등 일부 사용자에게 발작을 유발할 수 있으므로 접근성을 고려해야 한다. - 모션은 다음과 같은 부작용을 일으킬 수 있다. - 화면을 복잡하고 산만하게 만든다. - 사용자의 작업을 중단시킨다. - 불필요한 단계를 추가한다. - 사용자를 혼란스럽게 하거나 불편하게 한다. - 반복되면서 브랜드에 대한 호감도를 서서히 떨어뜨린다. - 화면 곳곳에서 빠르고 과장된 움직임이 반복되면 사용자는 정확한 원인을 의식하지 못하더라도 제품을 피곤하고 성가시게 느낄 수 있다. - 따라서 각 애니메이션은 가장 우아하고 절제된 방식으로 사용자 문제를 해결하는지 검토해야 한다. 모션은 기능을 이해시키고 상태 변화를 설명하는 경우에 우선 적용하는 것이 좋다. 구현 전에는 “이 움직임이 어떤 정보를 전달하는가”, “없어도 사용 가능한가”, “접근성 설정이나 모션 감소 환경에서도 문제가 없는가”를 확인해야 한다.

원문 읽기(새 탭에서 열림)
접근성Figma사용자 경험motion-design+2
figma2분 읽기큐레이션 요약

Figma의 새로운 소식:

2021년 11월 Figma 업데이트는 팀이 작업 흐름을 끊지 않고 더 빠르게 협업하도록 돕는 데 초점을 맞췄다. 특히 피드백을 남기고 관리하는 댓글 기능을 개선했으며, Figma와 FigJam 안에서 음성 대화와 오디오 피드백을 더 많은 사용자가 이용할 수 있도록 자막 기능을 베타로 도입했다. 핵심 방향은 아이디어를 공유하고 논의하는 과정을 디자인 파일 안에서 더욱 직관적이고 포용적으로 만드는 것이다. ## 댓글 기능 개편으로 피드백 처리 개선 - Figma와 FigJam의 댓글이 더 눈에 잘 띄도록 시각적으로 강화됐다. - 댓글을 추가하고 답변하는 과정이 직관적으로 바뀌어 협업자의 의견을 더 쉽게 수집할 수 있다. - 디자이너는 피드백을 확인하고 관리하며, 작업물에 반영하는 과정을 보다 효율적으로 진행할 수 있다. - 다양한 직군의 구성원이 디자인 과정에 참여하는 상황을 고려해, 피드백을 공유하고 실행하는 흐름을 단순화했다. - 목표는 아이디어 구상부터 구체적인 결과물 제작까지, 피드백 때문에 작업 흐름이 끊기지 않도록 하는 것이다. ## Figma·FigJam 내 커뮤니케이션 확장 - 몇 달 전 도입된 오디오 기능을 통해 같은 파일 안에서 팀원과 음성으로 대화할 수 있게 했다. - 커서 채팅을 사용하면 별도의 창으로 이동하지 않고 현재 커서 위치를 통해 질문이나 짧은 메시지를 전달할 수 있다. - FigJam에서는 협업 중 하이파이브와 같은 반응을 보내며 보다 가볍고 즉각적으로 소통할 수 있다. - 디자인 작업, 아이디어 회의, 피드백 논의를 하나의 파일 안에서 이어갈 수 있도록 커뮤니케이션 수단을 확장했다. ## 오디오 자막으로 접근성 강화 - 청각장애인 및 난청 사용자를 위해 Figma 데스크톱 앱에서 실시간 폐쇄 자막 기능을 베타로 제공했다. - 오디오 통화 중 누가 말하고 있는지, 어떤 내용을 말하는지 더 명확하게 확인할 수 있다. - 음성 기반 피드백에 참여하기 어려운 사용자도 팀의 논의와 의사결정을 따라갈 수 있도록 지원한다. - 협업 파일에 참여한 모든 사람이 중요한 논의에 접근할 수 있게 해, Figma의 실시간 협업 기능을 더욱 포용적으로 만들었다. 실무에서는 댓글을 단순한 메모가 아니라 작업 항목으로 활용하고, 음성 피드백이 중요한 팀이라면 오디오 자막 베타 기능을 함께 사용해 구성원 모두가 논의 내용을 확인할 수 있도록 하는 것이 좋다.

원문 읽기(새 탭에서 열림)
접근성Figmafigjamcollaborative-design+2
figma3분 읽기큐레이션 요약

플러그인 비하인

Cards for Humanity는 팀이 다양한 사용자의 필요와 장애를 이해하고, 포용적·접근 가능한 제품을 설계하도록 돕는 카드 게임형 Figma 플러그인이다. 사람의 특성과 필요를 조합해 가상의 사용자를 만들고 해결책을 논의하는 방식으로, 추상적인 포용적 디자인을 구체적인 워크숍 대화로 바꾼다. 제작팀은 도구 자체도 포용적이어야 한다는 원칙에 따라 사용자 피드백을 반영하며 발전시켰고, 포용적 디자인은 윤리적 의무이자 더 나은 제품을 만드는 핵심 과정이라고 강조한다. ## 카드 게임을 통한 공감과 문제 정의 - 게임에는 두 종류의 카드가 있다. - 인물 카드: 이름, 나이, 성격 특성 - 필요 카드: 해당 인물이 가진 필요, 장애, 개인적 도전 - 두 카드를 조합해 가상의 인물을 만들고, 그 인물의 요구를 충족할 제품·서비스를 고민한다. - 카드를 클릭하면 특성이나 장애와 관련된 구체적인 고려사항이 표시된다. - 이러한 정보는 특정 장애나 상황에 대해 디자이너가 임의로 가정하는 것을 줄여준다. - 정해진 답이 없는 개방형 방식이므로 워크숍, 브레인스토밍, 접근성 관련 대화 등 다양한 상황에 활용할 수 있다. - 핵심은 사용자를 추상적인 ‘타깃’이 아니라 구체적인 인간으로 바라보게 하는 것이다. ## 원격 환경에 맞춘 플러그인과 웹사이트 - 원래는 클라이언트 워크숍에서 사용할 실물 카드 게임으로 시작했다. - 코로나19로 업무 환경이 원격화되자 온라인 도구로 빠르게 전환했다. - Figma 플러그인과 별도 웹사이트를 제공해 팀이 물리적으로 한 공간에 모이지 않아도 게임을 진행할 수 있게 했다. - 이를 통해 접근성 논의를 특정 워크숍 형식이나 장소에 제한하지 않았다. ## 도구 자체를 포용적으로 설계하기 - 제작팀은 개발 초기부터 내부 구성원에게 자신의 특성이나 장애를 공유할 의향이 있는지 질문하며 연구를 시작했다. - 이후 온라인 제품 커뮤니티의 의견을 받아 카드에 포함할 특성과 상황의 범위를 넓혔다. - 출시 후에는 예상보다 다양한 사용자에게서 피드백을 받았다. - 디자이너와 개발자뿐 아니라 변호사, 게이머, 임상의, 교육자 등도 활용했다. - 예상하지 못한 대상이 주요 사용자일 수 있으므로, 다양한 독자를 고려한 언어와 표현이 필요하다는 점을 배웠다. - 전문용어를 피하고 이해하기 쉬운 문장을 사용하는 것이 접근성의 중요한 요소로 제시된다. - 접근성 도구가 스스로 배제적이어서는 안 되므로, 지속적인 피드백 수집과 반복 개선이 필수다. ## 에이전시 업무와 내부 프로젝트의 균형 - 크리에이티브 에이전시는 수익이 직접 발생하는 고객 업무와, 즉각적인 ROI가 불분명한 내부 프로젝트를 함께 수행한다. - Cards for Humanity 같은 도구는 내부 프로젝트이지만, 장기적으로는 고객이 더 나은 제품을 만들도록 지원하고 에이전시의 영향력을 확장한다. - 팀원들의 개인적인 관심과 자발적인 시간 투자가 프로젝트를 지속시키는 동력이 됐다. - 도구를 고객 업무 프로세스에 통합함으로써, 한 번의 내부 프로젝트가 여러 고객과 그 고객의 최종 사용자에게 확산될 수 있었다. - 포용적 디자인은 단순한 비용이나 사업 기회 계산을 넘어, 더 많은 사람이 사용할 수 있는 제품을 만드는 기본 조건으로 설명된다. ## 포용적 디자인은 대화에서 시작된다 - 이 도구의 목적은 특정한 정답이나 사용 절차를 강요하는 것이 아니다. - 카드에 적힌 인물의 상황과 필요를 함께 이야기하는 것만으로도 팀 내 포용적 디자인 논의를 시작할 수 있다. - 접근성과 포용성은 프로젝트 후반에 추가하는 기능이 아니라, 초기 문제 정의와 설계 과정부터 고려해야 한다. - 제작자는 제품과 서비스가 사회 구성원에게 미치는 영향을 생각할 책임이 있으며, Cards for Humanity는 그 책임을 실천하기 위한 대화의 출발점이다. 팀에서 접근성 논의를 시작하려면 Cards for Humanity 같은 구체적인 시나리오 도구를 활용하고, 다양한 사용자의 필요를 가정하기보다 실제 피드백을 받아 설계 과정에 반복적으로 반영하는 것이 좋다.

원문 읽기(새 탭에서 열림)
접근성Figma프로덕트 디자인inclusive-design+1
figma4분 읽기큐레이션 요약

In the file: Config

Config 2021의 Coda와 Stripe 사례는 디자인팀이 불확실성과 단기 요구를 다루면서도 장기적인 제품 방향과 확장성을 확보하는 방법을 보여준다. Coda는 사용자 데이터가 없는 0→1 단계에서 경쟁사 분석과 팀의 직관으로 관점을 세웠고, Stripe는 장기적 관점·튼튼한 기반·엄격한 품질 기준을 통해 복잡한 결제 경험을 단순화했다. 두 사례 모두 명확한 비전과 이를 공유하는 프로세스가 팀 정렬과 좋은 제품 결정의 핵심이라고 강조한다. ## 0→1 제품에서 맥락 만들기 - Coda의 Helena Jaramillo는 기존 제품을 개선하는 대신, 새로운 퍼블리싱 플랫폼을 처음부터 구축하는 과제를 맡았다. - 초기 제품에는 기존 사용자의 행동 데이터나 인터뷰할 사용자 자체가 없었기 때문에 일반적인 리서치 인사이트를 활용하기 어려웠다. - 이를 보완하기 위해 경쟁 제품과 인접 분야의 서비스를 조사했다. - 조사 결과를 Figma 파일에 스크린샷과 주석으로 정리해 다음을 공유했다. - 어떤 접근 방식이 효과적인지 - 어떤 방식은 Coda에 적합하지 않은지 - 경쟁 제품에서 참고할 만한 패턴은 무엇인지 - 데이터가 부족한 초기 단계에서는 외부 사례를 체계적으로 분석해 팀이 논의할 수 있는 공통 맥락을 만드는 것이 중요하다. ## 강한 제품 관점과 비전 수립 - Coda는 사람들이 왜 Coda에서 콘텐츠를 발행해야 하는지, Coda만의 차별점이 무엇인지부터 질문했다. - 퍼블리싱 경험이 다음 중 무엇에 가까워야 하는지 검토했다. - 블로그 글을 발행하는 경험 - 노코드 앱을 만드는 경험 - 웹사이트를 제작하는 경험 - Helena 자신의 퍼블리셔 경험과 팀 토론을 바탕으로 두 가지 우선순위를 도출했다. - 발행 과정을 쉽게 만들 것 - 발행자가 자신의 결과물을 자랑스럽게 느끼게 할 것 - 이 관점은 구체적인 제품 결정으로 이어졌다. - 인터랙티브 문서를 쉽게 발행할 수 있는 흐름 - 사진, 부제목, 작성자 정보를 추가할 수 있는 기능 - 사용자 인사이트가 부족하더라도 팀이 함께 명확한 관점을 세우면 일관된 제품 방향을 결정할 수 있다. ## 복잡한 아이디어를 이야기로 전달하기 - Helena는 기능 목록만 설명하는 대신 제품이 만들고자 하는 경험을 하나의 이야기로 전달했다. - 이를 위해 Figma에 “tl;dr 페이지”를 만들고 다음을 포함했다. - 핵심 사용자 흐름 - 소수의 대표 목업 - 팀이 만들려는 경험의 전체적인 서사 - 이 페이지는 세부 기능을 모두 설명하기보다, 협업자가 짧은 시간 안에 제품의 방향을 이해하도록 돕는 역할을 했다. - 크로스펑셔널 팀을 설득할 때는 상세한 사양보다 문제, 사용자 경험, 제품의 의도를 한눈에 보여주는 자료가 효과적이다. ## 단기 요구와 장기 확장성의 균형 - Stripe 디자인팀은 기업과 최종 사용자가 겪는 복잡한 프로세스를 최대한 단순하고 쉽게 만드는 것을 목표로 한다. - 이를 위해 당장의 요구를 해결하는 동시에 장기적으로 확장 가능한 시스템과 프로세스를 구축한다. - Connie Yang은 이를 “도시 계획가의 사고방식”에 비유했다. - 개별 건물이나 차량만 설계하지 않는다. - 도로의 폭과 교통 흐름을 고려한다. - 시스템 간 연결 관계를 설계한다. - 화재나 재난 같은 미래의 예외 상황에도 대비한다. - 팀은 현재의 속도를 유지하면서도 “2030년까지 작동할 구조인가”를 질문한다. ## 튼튼한 기반과 확장 가능한 시스템 - 장기적 관점은 인프라와 디자인 시스템에 대한 투자로 구체화된다. - Stripe가 말하는 견고한 기반에는 다음이 포함된다. - 빠르고 접근성 높은 제품과 플랫폼 구축 - 임시방편보다 확장 가능한 시스템 개발 - 반복적으로 활용할 수 있는 공통 규칙과 구조 마련 - Stripe 디자인 시스템의 색상 테이블에는 색상 대비와 접근성 평가 정보가 내장되어 있다. - 디자이너가 매번 접근성을 별도로 확인하지 않아도 되며, 시스템 자체가 더 나은 결정을 유도한다. - 이런 기반은 팀의 생산성을 높이는 동시에 최종 사용자의 경험과 접근성도 개선한다. ## 엄격한 품질 기준과 사용자 신뢰 - Stripe에서는 “디테일이 중요하다”는 원칙을 중시한다. - Stripe는 결제 승인과 대금 지급처럼 신뢰가 핵심인 업무를 다루므로, 작은 UI 요소도 사용자 경험과 신뢰에 영향을 준다. - 때로는 구현이 더 어렵거나 시간이 오래 걸리더라도, 최종적으로 더 안전하고 명확한 경험을 제공하는 방식을 선택한다. - 단기적으로 빠른 해결책을 택하기보다 품질, 정확성, 접근성을 높이는 선택이 장기적인 제품 신뢰로 이어진다. ## 실무에 적용할 때의 시사점 - 데이터가 부족한 초기 제품이라면 경쟁사와 인접 분야를 조사해 팀의 공통 맥락을 만든다. - 팀의 직관을 막연한 의견으로 두지 말고, 명확한 제품 원칙과 우선순위로 정리한다. - 세부 기능보다 사용자 흐름과 제품의 핵심 이야기를 먼저 공유한다. - 단기 요구를 해결할 때도 디자인 시스템, 접근성, 성능처럼 미래에 반복될 기반을 함께 설계한다. - 빠른 실행과 장기적 품질 사이에서 균형을 잡되, 사용자 신뢰가 중요한 영역에서는 품질 기준을 낮추지 않는 것이 좋다.

원문 읽기(새 탭에서 열림)
접근성Figma디자인 시스템사용자 경험+2
figma3분 읽기큐레이션 요약

팀으로 배우고 실패하기 |

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

원문 읽기(새 탭에서 열림)
접근성Figma디자인 시스템remote-collaboration+3