접근성

58 개의 포스트

figma3분 읽기큐레이션 요약

개방적이고 포용

프로세스는 팀의 협업 방식뿐 아니라 제품이 얼마나 개방적이고 포용적인지도 결정한다. 좋은 디자인은 핵심 사용자와 이상적인 사용 사례를 넘어 다양한 환경·능력·문화의 사용자를 고려하고, 디자인·개발·현지화 팀이 초기부터 함께 검토하는 구조를 갖춰야 한다. 특히 원격 근무 환경에서는 업무 현황과 가용 시간을 투명하게 공유하는 루틴이 중요하다. ## 이상적인 사용 사례를 넘어선 사용자 이해 - 대표 페르소나와 핵심 사용 사례만을 기준으로 삼으면 실제 사용 환경의 복잡성을 놓치기 쉽다. - 제품을 직접 사용하는 사람뿐 아니라 배달원처럼 제품의 결과물을 전달하거나 운영하는 사람의 상황도 체험해야 한다. - 예를 들어 배달 앱은 다음과 같은 현실적 제약을 고려해야 한다. - 고장 난 엘리베이터 대신 계단을 이용해야 하는 상황 - 외진 지역에서 GPS가 작동하지 않는 상황 - 사용자의 범위를 넓혀 바라보면 접근성 문제도 더 구체적으로 발견할 수 있다. - 문구를 단순화하고, 색상 대비·글자 크기·레이아웃을 개선하는 것부터 시작할 수 있다. - 접근성은 장애뿐 아니라 특정 상황에서 일시적으로 발생하는 제약도 포함한다. - 시끄러운 장소에서 소리를 듣기 어려운 경우 - 휴대폰 화면이 깨진 경우 - 조직 내에서 접근성 개선을 책임질 담당자를 명확히 정해야 지속적인 변화로 이어진다. - 특정 사용자에게 필수적인 기능은 결과적으로 모든 사용자에게도 유용할 수 있다. ## 현지화를 제품 개발의 일부로 만들기 - 현지화는 단순히 문구를 번역하는 작업이 아니라 다음 요소를 함께 고려하는 과정이다. - 언어별 문장 구조와 문법 - 문화적 뉘앙스 - 번역된 문구가 실제 화면에 들어갈 수 있는지 여부 - Deliveroo는 기존에 디자이너가 경험을 설계한 뒤 개발자에게 넘기고, 개발자가 번역 문구마다 화면을 수동으로 확인하는 방식으로 작업했다. - Phrase Figma 플러그인을 도입해 디자이너가 여러 언어의 디자인을 빠르게 만들고 공유할 수 있도록 개선했다. - 이 방식으로 현지화 팀은 개발 전에 다음 문제를 발견할 수 있었다. - 번역이 부정확한 문제 - 번역문이 화면 영역을 초과하는 문제 - 현지화 담당자는 전체 사용자 흐름을 한 번에 확인하고 초기 단계에서 피드백을 제공할 수 있다. - 결과적으로 현지화는 디자인팀과 현지화팀 사이의 일회성 인계가 아니라, 글로벌 사용자 여정을 함께 설계하는 제품 개발 과정으로 바뀌었다. ## 조직 전체의 긴밀한 협업 - 포용적인 제품을 만들려면 디자인팀 내부뿐 아니라 디자인·개발·현지화 등 관련 조직이 일찍부터 협력해야 한다. - 기존의 순차적 핸드오프 방식은 문제를 늦게 발견하게 만들고, 이미 구현된 화면을 다시 만드는 비용을 높인다. - 가벼운 프로토타입을 공유하면 각 팀이 자신의 전문성을 디자인 단계에서 반영할 수 있다. - 협업 과정에서 중요한 것은 단순히 시간을 절약하는 것뿐 아니라, 각 팀이 전체 사용자 경험과 제품 맥락을 이해하는 것이다. ## 원격 환경에서 투명한 팀 프로세스 만들기 - 원격 근무에서는 사무실에서 자연스럽게 얻던 공간적·시각적 정보가 사라지므로 업무 상황을 더 의도적으로 공유해야 한다. - 팀 구성원이 무엇을 하고 있는지, 회의에 얼마나 참여할 수 있는지 파악할 수 있도록 업무 시간을 시각화할 필요가 있다. - Team Capacity Template과 같은 도구를 활용하면 다음 정보를 공유할 수 있다. - 각자의 주간 업무 일정 - 회의 가능 시간 - 업무량의 공백이나 과부하 - 정기적인 회의와 짧은 스탠드업은 업무 진행 상황뿐 아니라 개인적인 안부를 확인하는 역할도 한다. - 사무실의 즉흥적인 대화와 브레인스토밍을 보완하기 위해 자유롭게 참여하고 나갈 수 있는 화상 작업 세션을 운영할 수 있다. - 원격 상황에서는 효율성만을 앞세우기보다 팀이 현재 상황을 견뎌내는 데 필요한 소통과 관계 형성에 충분한 시간을 배정해야 한다. 실무적으로는 프로젝트 초기에 다양한 사용자와 실제 사용 환경을 점검하고, 현지화·접근성 담당자를 디자인 리뷰에 참여시키는 것이 좋다. 또한 원격 팀이라면 업무 가시성과 정기적인 협업 시간을 명시적인 프로세스로 만들어야 포용적인 제품과 건강한 협업 문화를 함께 구축할 수 있다.

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

Figma 커뮤니티

Figma Community는 사용자들이 디자인 시스템, 아이콘, 와이어프레임, 일러스트, 프로토타입 등을 공개하고 서로 탐색·재사용·리믹스할 수 있는 공간이다. 2020년 8월부터 전체 Figma 사용자에게 단계적으로 공개되었으며, 검색과 태그 탐색, 프로필 핸들, 좋아요, 파일 복제 기능을 제공한다. 글은 베타 기간 동안 커뮤니티가 만든 다양한 리소스와 그 제작 배경을 소개하며, Figma Community가 협업과 지식 공유의 기반으로 성장할 가능성을 강조한다. ## Figma Community의 공개와 기능 - 수천 명의 제작자가 베타에 참여해 파일과 프로필을 공개했다. - 사용자는 다음과 같은 자료를 검색하고 탐색할 수 있다. - 디자인 시스템 - 아이콘 팩 - 와이어프레임 - 일러스트레이션 - 애니메이션 프로토타입 - 보드게임 등 실험적인 작업물 - 주요 기능은 검색, 태그 탐색, 프로필 핸들 선점, 좋아요, 파일 복제다. - 초기 공개 단계에서는 모든 사용자가 파일과 프로필을 볼 수 있지만, 파일을 직접 게시하려면 여전히 베타 참여가 필요했다. - Microsoft, Google Material Design, Mixpanel 같은 조직과 개인 디자이너들이 실용적인 리소스를 공개했다. ## Material Design Baseline Kit: 디자인 시스템의 출발점 - Google Material Design 팀의 Jessie Z가 제작한 리소스다. - 디자인 시스템을 처음부터 구축하는 부담을 줄이고, 다양한 프로젝트에서 활용할 수 있도록 설계됐다. - 두 부분으로 구성된다. - **Material Theme**: 타이포그래피와 색상 팔레트를 수정하고, 변경 사항이 컴포넌트·상태·예시 레이아웃에 미치는 영향을 빠르게 확인한다. - **Sticker sheet**: 기존 컴포넌트를 조합하고 활용하는 전통적인 UI 리소스 모음이다. - 사용자는 이 키트를 기반으로 Material 가이드라인을 학습하거나, 제품과 브랜드에 맞는 테마를 시각화할 수 있다. ## Open Figures: 재사용 가능한 일러스트 라이브러리 - Bonnie Kate Wolf가 제작한 일러스트레이션 라이브러리다. - 특정 회사의 브랜드 가이드에 얽매이지 않고 독립적인 스타일을 만들 수 있었던 프로젝트다. - 제품 화면, 프레젠테이션, 개인적인 창작 활동 등 다양한 목적에 사용할 수 있도록 구성됐다. - 모듈형 일러스트를 설계하면서 접근성과 포용성을 고려했다. - 휠체어를 사용하는 캐릭터의 의상 교체가 가능하도록, 드레스나 긴 재킷처럼 다른 요소와 충돌하는 형태를 조정했다. - 단순히 보기 좋은 그림을 제공하는 것을 넘어, 다양한 사용자를 표현할 수 있는 디자인 구조를 보여준다. ## Spotify Ways of Working: 팀 협업 방식의 공유 - Spotify의 Barton Smith, Cliona O’Sullivan과 Figma 워킹 그룹이 제작했다. - Figma에서 팀의 업무를 조직하고 협업하는 방식을 외부 커뮤니티에 공개한 자료다. - Spotify는 회사마다 Figma 파일과 프로젝트를 정리하는 표준 방식이 없고, 이를 어려워하는 팀이 많다는 점에서 출발했다. - 이 파일은 특정 도구 사용법보다 실제 조직이 업무를 구조화한 사례를 보여주는 데 목적이 있다. - Spotify 팀 역시 운영 과정에서 얻은 학습을 바탕으로 기존 결정을 계속 수정하고 있다고 설명한다. ## 커뮤니티가 만드는 공유 생태계 - Figma Community는 완성된 결과물뿐 아니라 제작자의 문제의식과 작업 방식을 공유하는 장으로 기능한다. - 대기업의 디자인 시스템부터 개인 창작자의 일러스트, 팀 운영 문서까지 자료의 범위가 넓다. - 공개된 파일을 복제해 자신의 프로젝트에 맞게 수정할 수 있어 학습과 실무 적용이 동시에 가능하다. - Figma는 초기 출시를 완성된 제품이 아니라 앞으로 확장될 기반으로 설명하며, 사용자들이 무엇을 만들고 어떻게 활용하는지에 따라 발전시킬 계획을 밝혔다. 실무에서는 Material Design Baseline Kit처럼 구조화된 시스템을 출발점으로 삼고, Open Figures처럼 재사용 가능한 시각 자산을 활용하며, Spotify 사례처럼 팀의 파일 관리 규칙을 문서화하는 방식으로 Figma Community를 활용할 수 있다.

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

플러그인으로 사용자와 팀

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

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

마이크로소프트가 워

Microsoft는 Figma 플러그인을 활용해 Fluent 디자인 시스템의 도입을 여러 제품·조직·팀으로 확장하고, 디자인 과정의 일관성과 효율성을 높였다. 특히 승인된 콘텐츠를 불러오고, 제품별 라이브러리를 전환하며, 반복 작업을 자동화하는 사내 도구를 개발했다. 이 글은 조직의 고유한 업무 방식에 맞춘 비공개 플러그인이 디자이너의 창의적 작업에 더 많은 시간을 돌려줄 수 있다고 설명한다. ## Fluent 디자인 시스템과 플러그인의 역할 - Microsoft는 모든 제품에서 사용성, 일관성, 접근성을 높이기 위해 Fluent 디자인 시스템을 운영했다. - 여러 제품군과 조직, 팀에 디자인 시스템을 적용하려면 단순한 가이드라인만으로는 부족하고 효율적인 도구가 필요했다. - Figma 플러그인은 반복 작업을 줄이고, 조직별 데이터와 규칙을 디자인 프로세스에 직접 통합하는 수단으로 활용됐다. - 공개 플러그인뿐 아니라 특정 팀의 승인 절차와 콘텐츠 정책에 맞춘 사내 전용 플러그인도 개발했다. ## 승인된 디자인 콘텐츠를 불러오는 Content Reel - 일반적인 더미 텍스트나 Lorem Ipsum은 실제 디자인 의도와 콘텐츠 특성을 충분히 반영하지 못한다. - Microsoft는 사내용 Content Reel을 만들어 승인된 다음 요소를 Figma 디자인에 바로 삽입했다. - 승인된 텍스트 문자열 - 아바타 - 아이콘 - 디자이너가 콘텐츠를 직접 찾거나 사용 승인을 다시 받을 필요가 없어 작업 속도가 향상됐다. - 조직마다 자체 콘텐츠 저장소와 승인 기준을 연결한 Content Reel을 만들 수 있다는 점을 보여준다. ## 제품별 라이브러리를 빠르게 전환하는 Themer - Microsoft는 제품마다 고유한 라이브러리와 스타일을 사용하며, Figma 안에 수백 개의 라이브러리가 존재했다. - 제품 스타일에 맞게 디자인을 수동으로 변경하는 작업은 규모가 커질수록 비효율적이었다. - Jackie Chui가 개발한 Themer는 Work, Outlook 등 여러 제품 테마 사이를 빠르게 전환하도록 지원했다. - 공개 버전 Themer는 라이브러리에서 게시된 스타일을 쉽게 교체하는 기능을 제공한다. - 이를 통해 하나의 디자인을 여러 제품의 시각적 체계에 맞게 적용하는 비용을 줄였다. ## 반복 작업을 줄이는 워크플로 도구 Microsoft 디자이너들은 창의적인 문제 해결에 집중하기 위해 반복적인 작업을 자동화하는 여러 플러그인을 제작했다. - **Find and Replace** - 페이지 내 텍스트를 검색하고 일괄 교체한다. - 일반적인 텍스트 편집기의 찾기·바꾸기와 유사하다. - **Paste to Fill** - 복사한 이미지를 선택한 레이어의 Fill로 붙여 넣는다. - 이미지 URL을 입력해 레이어의 이미지 Fill로 불러올 수도 있다. - **Button Resizer** - 버튼의 라벨 너비에 맞춰 버튼 크기를 쉽게 조정한다. - Jackie는 Figma API가 공개된 이후부터 플랫폼을 활용해 팀의 디자인 작업을 개선하는 도구를 꾸준히 개발했다. - Figma가 Microsoft의 주요 디자인 도구가 된 만큼, 그 위에 자체 업무 도구를 구축하는 것이 자연스러운 선택이었다. ## 접근성을 프로세스에 포함하려는 시도 - Microsoft 디자이너 Tiffany Chen은 Modern Input and Accessibility 팀에서 제품 경험의 포용성을 높이는 업무를 담당했다. - 접근성이 제품 개발 마지막 단계에 덧붙이는 작업으로 취급되는 문제를 지적했다. - 그녀는 디자이너들이 초기 단계부터 접근성을 고려하도록 돕는 플러그인을 개발했다. - 제공된 글은 해당 플러그인의 구체적인 기능 설명이 중간에 끊겨 있어 상세 내용까지는 확인할 수 없다. 조직에 맞는 승인 콘텐츠, 디자인 토큰과 라이브러리, 반복 작업을 플러그인으로 연결하면 디자인 시스템의 실제 활용도를 크게 높일 수 있다. 특히 팀 내 반복 작업을 먼저 찾아 작은 자동화 도구로 해결한 뒤, 효과가 검증된 도구를 조직 전체로 확장하는 접근이 실용적이다.

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

유용한 플러그인으로 디자인

접근성을 디자인 초기부터 반영하지 않으면 시각·운동 능력 등에 제약이 있는 많은 사용자가 제품에서 배제될 수 있다. 이 글은 Figma에서 색상 대비와 키보드 포커스 순서를 점검할 수 있는 네 가지 플러그인을 소개하며, WCAG 기준을 디자인·개발 과정에 적용할 것을 권한다. 접근성 검사를 별도 단계가 아니라 디자인 워크플로의 일부로 만드는 것이 핵심이다. ## 색상 대비와 WCAG 기준 - 텍스트와 배경 사이의 충분한 대비는 다양한 시각 능력을 가진 사용자가 콘텐츠를 읽는 데 필수적이다. - WCAG는 색상 대비를 AA 또는 AAA 등급으로 평가하는 기준을 제공한다. - 소개된 플러그인들은 선택한 두 객체의 색상을 분석해 대비 비율과 기준 충족 여부를 확인한다. - 단순히 색상을 고르는 데 그치지 않고, 실제 텍스트 크기와 배경 조합을 고려해 가독성을 검증할 수 있다. ## Able: 대비 검사와 색각 이상 시뮬레이션 - 선택한 두 객체의 색상 대비를 분석한다. - 선택 영역이 바뀌면 결과도 자동으로 업데이트된다. - 텍스트와 배경 조합을 미리 볼 수 있는 프리뷰를 제공한다. - 다양한 색각 이상 유형에서 색상이 어떻게 보이는지 시뮬레이션할 수 있다. - 텍스트 색상과 배경 색상을 서로 바꿔 비교할 수 있다. - 각 색각 이상 유형별 영향을 받는 인구 비율도 확인할 수 있다. ## Contrast Checker: 대비 비율과 등급 확인 - 선택한 두 객체의 정확한 색상 대비 비율을 표시한다. - 선택된 레이어 중 텍스트 레이어가 있는지에 따라 상황에 맞는 미리보기를 제공한다. - AA/AA+와 AAA/AAA+ 등 여러 접근성 등급별 충족 여부를 보여준다. - 글꼴 크기가 18pt를 초과하는 경우에 적용되는 대비 기준도 별도로 확인할 수 있다. - Sketch 사용자에게 익숙한 Stark의 Figma용 대비 검사 도구다. ## Color Blind: 캔버스에서 보는 색각 이상 결과 - 선택한 디자인 요소가 여러 색각 이상 유형에서 어떻게 보이는지 확인한다. - 단순한 미리보기 대신, 선택한 요소를 복제해 캔버스에 직접 결과물을 생성한다. - 각 복제본은 해당 시각 유형을 나타내는 이름의 그룹으로 정리된다. - 완성된 화면 전체의 색상 체계와 정보 전달 방식이 색각 이상 사용자에게도 충분히 구분되는지 검토하는 데 유용하다. ## Focus Orderer: 키보드 탐색 순서 설계 - 브라우저가 키보드 포커스를 이동시킬 요소와 순서를 디자인에 표시한다. - 요소를 선택해 포커스 지점을 만들고, 캔버스에 순번을 표시할 수 있다. - 플러그인 UI에서 항목을 드래그하면 포커스 순서가 변경되고 캔버스의 번호도 자동으로 갱신된다. - 실제로 모든 요소를 탭 키로 순회하며 포커스 흐름을 테스트할 수 있다. - 디자인 단계에서 키보드 내비게이션을 고려하게 해, 구현 과정에서 접근성 요구사항이 누락되는 것을 줄인다. ## 접근성을 워크플로에 포함하기 - 색상 대비 검사는 시각적 가독성을, 포커스 순서 검사는 키보드 사용성을 다룬다. - 두 영역 모두 개발 완료 후 수정하기보다 디자인 단계에서 문제를 발견하는 편이 효율적이다. - WCAG 문서를 기준으로 플러그인 결과를 해석하고, 실제 사용자 환경에서의 사용성도 함께 검증해야 한다. - Figma 플러그인 API와 개발자 커뮤니티를 활용하면 팀에 맞는 접근성 검사 도구를 직접 만들 수도 있다. 이 플러그인들을 디자인 시스템과 리뷰 과정에 포함하면 접근성을 일회성 점검이 아니라 지속적인 품질 기준으로 운영할 수 있다. 특히 텍스트·배경 대비, 색각 이상 시뮬레이션, 키보드 포커스 순서를 모든 주요 화면에서 반복적으로 확인하는 것이 실용적인 접근이다.

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

업무 자동화, 데이터 활용,

Figma는 2019년 8월, 누구나 플러그인을 사용하고 직접 만들 수 있는 공개 플러그인 플랫폼을 출시했다. 플러그인은 반복 작업 자동화, 실제 데이터·이미지 활용, 접근성 검사 등 Figma의 기능을 확장하며 디자이너가 필요한 도구를 직접 만들 수 있게 한다. Figma는 웹 개발과 유사한 프로그래밍 경험을 제공하면서도 플러그인의 보안성·안정성·성능을 확보하는 것을 목표로 했다. ## 플러그인 플랫폼을 만든 배경 - 기존 디자인 플러그인에는 두 가지 문제가 있었다. - 공식적으로 충분히 지원되지 않는 API를 사용하는 경우가 많아 안정성과 보안이 떨어졌다. - 디자이너가 직접 코딩하지 못하면 필요한 플러그인을 다른 사람이 만들어주길 기다려야 했다. - Figma는 플러그인을 단순한 부가 기능이 아니라 디자이너의 작업 흐름을 강화하는 “파워업”으로 정의했다. - 내부 목표는 “기본적인 HTML과 JavaScript로 웹 페이지를 만들 수 있다면 Figma 플러그인도 만들 수 있어야 한다”는 것이었다. - 웹 기반 디자인 도구를 위한 플러그인 아키텍처를 새롭게 설계했으며, 이를 통해 더 많은 개발자가 창의적인 플러그인을 만들 수 있도록 했다. ## 누구나 사용하고 만들 수 있는 생태계 - 베타 공개 6주 만에 40개 이상의 공개 플러그인이 제공됐다. - Figma 제품 안에서 플러그인을 검색하고 한 번의 클릭으로 설치할 수 있다. - 디자인 파일에서 마우스 오른쪽 버튼을 클릭해 사용 가능한 플러그인을 실행할 수 있다. - Figma Organization 요금제에서는 다음 기능도 제공된다. - 회사 내부용 비공개 플러그인 제작 및 배포 - 관리자가 승인된 플러그인 목록을 큐레이션 - 관리자가 조직 구성원을 대신해 플러그인 설치 ## 반복 작업을 자동화하는 유틸리티 플러그인 - **Similayer** - 비슷한 속성을 가진 레이어를 한꺼번에 선택한다. - 여러 레이어를 일괄 수정해야 하는 반복 작업을 줄여준다. - **Super Tidy** - 프레임 이름을 정리하고 레이어 목록의 순서를 재배치한다. - 디자인 파일의 구조와 탐색성을 개선한다. - 이런 플러그인은 픽셀 단위의 수작업을 줄이고, 디자이너가 더 중요한 설계 작업에 집중하도록 돕는다. ## 실제 콘텐츠와 시각 자료를 가져오는 플러그인 - **Unsplash** - Unsplash의 이미지를 Figma 파일에 직접 삽입할 수 있다. - 이미지 검색과 배치 과정을 간소화해 디자인 작업에 실제 시각 자료를 빠르게 반영한다. - **Content Reel** - 텍스트, 아바타, 아이콘 등 디자인에 필요한 콘텐츠를 검색하고 배치한다. - 더미 데이터 대신 맥락에 맞는 콘텐츠를 사용해 현실적인 시안을 만들 수 있다. - 이러한 플러그인은 디자인 시스템이나 화면 설계 단계에서 콘텐츠를 수동으로 준비하는 부담을 줄인다. ## 접근성 문제를 발견하는 플러그인 - **Contrast Checker** - 색상, 시각 요소, 타이포그래피의 대비 수준을 검사한다. - 읽기 어렵거나 가독성이 낮은 디자인을 식별하는 데 도움을 준다. - **Color Blind** - 8가지 색각 이상 유형을 기준으로 디자인이 어떻게 보이는지 확인한다. - 디자이너가 다양한 사용자의 시각적 경험을 이해하고 접근성을 개선하도록 돕는다. - 플러그인은 디자이너가 육안으로 놓치기 쉬운 접근성 문제를 작업 과정에서 조기에 발견하게 한다. ## 플러그인이 확장하는 디자인 작업 방식 - 플러그인은 Figma에 없는 기능을 외부 도구로 보완하는 수준을 넘어, 팀과 개인의 고유한 작업 방식에 맞는 도구를 만들게 한다. - 디자이너는 엔지니어링 리소스를 기다리거나 다른 사람이 만든 도구에 의존하지 않고, 필요한 기능을 직접 구현할 수 있다. - Figma는 공개 플러그인과 조직 전용 플러그인을 함께 지원해 개인 창작자와 기업 팀 모두를 플랫폼에 참여시켰다. 플러그인은 반복 업무 자동화, 실제 콘텐츠 활용, 접근성 검증처럼 디자인 프로세스의 구체적인 문제를 해결하는 수단이다. Figma를 사용하는 팀이라면 자주 반복되는 작업과 품질 검사를 먼저 찾아보고, 적합한 공개 플러그인을 도입하거나 조직 전용 플러그인으로 직접 자동화하는 것이 효과적이다.

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

플러그인 비하인드

재키 추이는 Microsoft의 UX 디자이너이자 Figma API와 플러그인 베타 초기 사용자로, 디자이너의 작업을 더 빠르고 효율적으로 만드는 도구를 개발해왔다. 그는 접근성 기능을 만들기 위한 해커톤에서 Figma API를 접한 뒤 플러그인 개발에 매료되었고, 개인 프로젝트를 커뮤니티용 플랫폼으로 확장했다. 이 인터뷰는 디자이너와 개발자의 경계가 가까워지는 흐름과 Figma 플러그인 생태계의 가능성을 보여준다. ## 디자이너이자 도구 제작자가 된 배경 - 어린 시절 LEGO로 무언가를 만들고 발명하는 것을 좋아했던 경험이 UX 디자인과 개발에 대한 관심으로 이어졌다. - UX 디자이너로 일하면서 코딩을 익혀 자신이 설계한 제품을 직접 구현할 수 있게 되었다. - 다른 사람들이 만든 작업을 관찰하고, 서로 다른 아이디어를 연결해 자신의 프로젝트에 적용하는 방식으로 영감을 얻는다. - 디자인과 개발을 함께 수행하며 아이디어가 실제 결과물로 완성되는 과정을 중요하게 여긴다. ## Figma API를 접한 계기 - 2018년 Microsoft OneWeek Hackathon에서 팀원들과 디자인 도구에 접근성 기능을 추가하는 프로젝트를 진행했다. - Figma가 웹 기반으로 만들어졌다는 점에 흥미를 느껴 Figma 플랫폼과 API를 탐색하기 시작했다. - API를 이용해 사용자 동작을 프로그래밍 방식으로 시뮬레이션할 수 있다는 사실을 발견하면서 본격적으로 플러그인 개발에 빠져들었다. - 기능을 하나씩 발견할 때마다 새로운 가능성이 열린다고 느꼈으며, 공식 API의 사용 편의성과 안정성을 높이 평가했다. ## 개발한 Figma 플러그인 - **Find and Replace** - Figma 커뮤니티를 위해 만든 대표적인 플러그인이다. - 디자인 파일 안의 텍스트나 요소를 찾아 일괄적으로 변경하는 작업을 지원한다. - **Paste to Fill** - 복사한 콘텐츠를 디자인 요소의 채우기 영역에 적용하는 도구다. - **Button Resizer** - 버튼의 크기를 보다 쉽게 조정할 수 있도록 돕는다. - 이외에도 Microsoft의 업무와 일반 Figma 사용자 모두에게 유용한 다양한 플러그인을 제작했다. ## Figma Plus로 확장된 개인 프로젝트 - 초기에는 브라우저에서만 동작하는 Chrome 확장 프로그램 형태로 플러그인을 만들었다. - 커뮤니티의 긍정적인 반응을 통해 Figma 데스크톱 앱에서도 사용할 수 있는 도구에 대한 수요를 확인했다. - Mirko Santangelo, Ahmad Al Haddad와 협업해 자신들이 알고 있던 Figma API 지식을 통합하는 플랫폼을 개발했다. - 작은 프로젝트로 시작했지만 다음 요소를 포함한 완전한 시스템으로 발전했다. - 자체 API - 플러그인 스토어 - 플러그인 게시 및 배포 프로세스 - Figma가 공식적으로 플러그인 베타를 시작하자 팀도 베타 프로그램에 참여했다. - 추이는 여러 플러그인 중에서도 역설적으로 이 대규모 시스템 프로젝트인 **Figma Plus**를 가장 자랑스럽게 여긴다. ## 디자인과 개발의 미래 - 앞으로 5년 동안 디자이너와 개발자는 업무 과정에서 더욱 긴밀하게 협업하게 될 것으로 전망한다. - 미래의 디자인 도구는 현재 존재하는 디자인과 개발 사이의 간극을 줄일 것이다. - 디자이너가 기본적인 코딩 역량을 갖추고 직접 도구를 제작하는 흐름이 이런 변화를 촉진할 수 있다. ## Figma 커뮤니티를 위한 개발 - Microsoft에서 Figma가 주요 디자인 도구로 자리 잡았기 때문에, 팀의 업무 흐름을 개선하는 플랫폼 위에서 개발하는 것이 자연스러운 선택이었다. - 내부 업무용 도구를 만드는 데서 멈추지 않고, 더 넓은 Figma 커뮤니티에 공개해 다른 사용자에게도 혜택을 주려 했다. - 2019년 8월 1일부터 추이의 플러그인들이 Figma 커뮤니티에 공개될 예정이었다. 디자이너가 자신의 반복 작업과 불편을 직접 관찰하고 Figma API로 해결책을 구현하면, 업무 효율을 높이는 동시에 커뮤니티 전체에 기여할 수 있다. 이 사례는 디자인 도구를 단순히 사용하는 것을 넘어, 필요한 기능을 직접 만들고 공유하는 방식이 Figma 생태계를 확장한다는 점을 보여준다.

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

플러그인 비하인드

티파니 첸은 Microsoft의 접근성과 포용성 팀에서 일하며, Figma 플러그인으로 접근성 주석 작성 과정을 자동화하고 있다. 그녀는 플러그인이 디자이너가 필요한 기능을 직접 만들 수 있게 해 주며, 접근성 향상과 디자인 진입 장벽 완화에 기여한다고 본다. 또한 다양한 전공과 배경을 가진 사람들이 디자인에 참여할수록 더 풍부하고 포용적인 결과를 만들 수 있다고 강조한다. ## 접근성 주석 작업을 자동화하는 플러그인 - 티파니가 개발 중인 플러그인은 **접근성 중심의 주석(annotation) 도구**다. - 디자인에 접근성 관련 정보를 표시하는 수작업을 자동화해 반복적인 작업을 줄이는 것을 목표로 한다. - Microsoft의 내부·외부 접근성 강화 노력과 맞닿아 있으며, 포용적인 제품 경험에 대한 인식을 높이려는 목적이 있다. - 이 프로젝트는 티파니가 처음 만든 Figma 디자인 플러그인이기도 하다. ## Figma 플러그인을 선택한 이유 - 새로운 플러그인 시스템과 Figma API가 사용하기 쉬워 설정이나 디버깅보다 실제 제작에 더 많은 시간을 쓸 수 있었다. - 기존 디자인 도구가 모든 디자이너의 요구를 충족할 수는 없지만, 플러그인을 통해 필요한 기능을 직접 만들 수 있다. - 다른 개발자가 기능을 추가해 주기를 기다리는 대신, 자신과 커뮤니티에 필요한 도구를 직접 제안하고 구현할 수 있다. - Figma 커뮤니티가 친절하고 협력적이라는 점도 개발 동기가 됐다. ## 다양한 배경이 디자인에 주는 가치 - 티파니는 심리학, 인류학, 국제관계, 컴퓨터과학 등 비전통적인 배경을 가진 사람들이 디자인에 진입하는 것을 돕고 싶어 한다. - 다양한 경험과 지식은 디자인 커뮤니티에 새로운 관점과 문제 해결 방식을 제공한다. - 컴퓨터과학 배경 덕분에 디자인을 평가하고 구현할 때 **기술적 실현 가능성**과 **새로운 시도** 사이에서 균형을 잡는 편이라고 설명한다. - 디자인이 특정 전공자만의 영역이 되지 않도록 진입 장벽을 낮추는 것이 중요하다고 본다. ## 기술과 창작을 결합한 작업 - 가장 자랑스러운 프로젝트로 사람들에게 “어릴 때 어떤 거짓말을 들었나요?” 같은 질문을 던지고, 그 답변을 이야기와 일러스트로 발전시킨 작업을 꼽았다. - 참여자들의 경험을 시각화해 아트 디렉션 웹사이트로 제작했다. - 레이어링과 패럴랙스 효과를 활용해 이야기를 입체적으로 표현했다. - 이 프로젝트를 통해 기술적 역량과 창의적 작업을 결합하는 데 흥미를 느끼게 됐다. ## 사회적 영향을 고려하는 기업관 - 티파니는 B Corporation의 원칙에 관심을 보였다. - B Corp 인증 기업은 의사결정 시 노동자, 고객, 공급업체, 환경에 미치는 영향을 함께 고려한다. - Ben & Jerry’s, Kickstarter, Patagonia 등이 대표적인 B Corp 사례로 언급된다. - 이는 제품과 기업 활동이 수익뿐 아니라 사회와 환경에 미치는 영향까지 책임져야 한다는 관점과 연결된다. ## 더 포용적인 디자인 생태계 - 디자인 업계에는 모든 사람을 포괄하는 제품과 경험에 대한 인식이 더 필요하다. - 동시에 디자이너가 되려는 사람들의 진입 장벽도 낮아져야 한다. - 온라인에 공개된 학습 자료가 늘면서 이러한 장벽은 점차 낮아지고 있다. - 단순하면서도 강력한 도구인 Figma와 플러그인 생태계가 이 변화를 더욱 빠르게 만들 수 있다고 기대한다. 접근성을 별도의 사후 작업으로 다루기보다 디자인 과정에 자연스럽게 통합하려면, 반복적인 접근성 검토를 자동화하는 도구를 적극 활용하는 것이 좋다. 또한 디자인 팀은 다양한 전공과 배경의 구성원이 참여할 수 있도록 학습 자료와 제작 도구를 개방하는 방향을 고려할 필요가 있다.

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

DesignSystems.com의 새로운

DesignSystems.com은 디자인 시스템을 만들고 운영하는 디자이너·개발자·관리자를 위한 지식 공유 플랫폼으로 자리 잡고 있다. 이 글은 2019년 6월에 공개된 주요 콘텐츠 네 가지를 소개하며, 아이콘 설계부터 접근성 높은 React 컴포넌트, 에이전시 협업, 화이트라벨링까지 디자인 시스템의 실무 범위를 보여준다. 핵심은 재사용성과 일관성을 유지하면서도 다양한 사용자와 제품 요구에 유연하게 대응하는 것이다. ## 아이콘 시스템 설계와 구현 - 아이콘 제작의 기본 원칙부터 개발자 전달까지 다루는 종합 가이드를 소개한다. - 주요 내용은 다음과 같다. - 아이콘의 스트로크와 필(fill) 설계 - Boolean 연산을 활용한 아이콘 제작 - 아이콘을 체계적으로 구성하고 관리하는 방법 - 개발자 핸드오프를 위한 파일 및 자산 준비 - 아이콘은 단순한 그래픽 요소가 아니라 디자인 시스템의 일관성과 사용성을 좌우하는 핵심 자산으로 설명된다. ## 에이전시 관점의 디자인 시스템 구축 - Instrument는 Nike, Google, Airbnb 등과 협업하며 일회성 결과물이 아닌 확장 가능한 디자인 시스템을 구축한다. - 재사용 가능한 기능성 컴포넌트를 여러 애플리케이션과 규모에 걸쳐 활용하는 것을 중시한다. - 디자인 시스템의 성공을 위해서는 다음 과정이 중요하다. - 클라이언트와 시스템의 목표 및 범위에 대한 공통 이해 형성 - 높은 수준의 협업을 통한 요구사항 조율 - 특정 프로젝트를 넘어 장기적으로 활용 가능한 구성요소 설계 - 디자인 시스템은 산출물 하나가 아니라 브랜드, 제품, 기술을 연결하는 협업 프로세스로 제시된다. ## 접근성을 공유하는 React 컨테이너 - Zendesk의 오픈소스 디자인 시스템 Garden은 접근성 및 키보드 조작을 공통 패턴으로 관리하기 위해 “컨테이너” 패턴을 사용한다. - 컨테이너는 화면 UI를 직접 렌더링하지 않고 다음 기능을 담당한다. - 키보드 및 마우스 상호작용 처리 - React 컴포넌트 간 접근성 로직 공유 - RTL(오른쪽에서 왼쪽으로 읽는 언어) 레이아웃 지원 - 새 라이브러리인 `react-containers`는 스타일이 포함된 전체 패키지를 설치하지 않아도 비시각적 로직만 사용할 수 있도록 별도 저장소로 분리됐다. - 기존 패턴보다 더 작고 효율적으로 다시 작성됐으며, WAI-ARIA Authoring Practices 1.1에 더욱 가깝게 구현됐다. ## 사용자에게 권한을 제공하는 화이트라벨링 - Dawn Labs는 제3자가 디자인 시스템을 직접 커스터마이즈할 수 있으면서도 제품 전체의 일관성을 유지해야 하는 문제를 다뤘다. - 사용한 기술은 다음과 같다. - `styled-components` - `styled-system` - GraphQL 백엔드 - CSS 변수와 전역 CSS 주입 - 기본 디자인 토큰과 구조는 통제하면서도, 최종 사용자가 클라이언트의 개입 없이 원하는 스타일을 수정할 수 있도록 “스타일링 탈출구”를 제공했다. - 화이트라벨 시스템은 일관된 기본 경험과 사용자별 커스터마이징 사이의 균형이 중요하다. ## 커뮤니티 중심의 지식 공유 - DesignSystems.com은 디자인 시스템 제작자, 디자이너, 개발자, 관리자가 경험과 실무 지식을 공유하는 것을 목표로 한다. - 다양한 분야의 기고를 통해 디자인 시스템을 시각 디자인에만 한정하지 않고 다음 영역까지 확장한다. - 접근성 - 컴포넌트 아키텍처 - 협업과 운영 - 사용자 커스터마이징 - 플랫폼의 성장은 운영팀뿐 아니라 커뮤니티 구성원의 사례와 기여에 기반한다. 디자인 시스템을 구축할 때는 재사용 가능한 컴포넌트와 명확한 시각 규칙뿐 아니라 접근성, 협업 프로세스, 확장 가능한 커스터마이징 구조까지 함께 설계하는 것이 좋다. 특히 공통 로직은 별도 모듈로 분리하고, CSS 변수나 디자인 토큰을 활용하면 일관성과 유연성을 동시에 확보할 수 있다.

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

디자인 시스템 전파의

디자인 시스템의 확산은 UI 키트나 컴포넌트 라이브러리를 만드는 기술적 작업만으로 이루어지지 않으며, 사람과의 협업을 통해 조직 문화로 정착되어야 한다. 특히 페어링은 다른 디자이너·엔지니어와 함께 작업하며 시스템의 문제를 발견하고, 비판을 협력으로 전환하며, 시스템의 가치를 자연스럽게 전파하는 가장 효과적인 방법이다. 디자인 시스템 팀은 “규칙을 지키라”고 요구하기보다 사용자의 일을 더 빠르고 높은 품질로 만들어 주는 파트너가 되어야 한다. ## 디자인 시스템은 기술 프로젝트가 아니라 문화 프로젝트 - UI 키트나 컴포넌트 라이브러리를 혼자 구축하는 것만으로는 조직의 불일치를 해결할 수 없다. - 디자인 시스템은 디자이너, 엔지니어, 제품 관리자, 고객 사이의 관계와 조직 문화를 반영한다. - “파란색을 쓰지 마라”, “이 컴포넌트를 왜 새로 만들었나”처럼 잘못을 지적하는 방식은 디자인 시스템 팀과 다른 팀을 대립 구도로 만들 수 있다. - Gusto는 다음과 같은 소통 장치를 마련했다. - 피드백과 질문을 위한 Slack 채널 - 디자인 시스템 팀의 오피스 아워 - 신규 구성원을 위한 UI 소개 키트 - 그러나 가장 효과적으로 시스템을 전파한 방법은 직접 함께 작업하는 페어링이었다. ## 페어링은 디자인 시스템의 사용자 조사다 - 다른 디자이너와 나란히 작업하면 실제 사용 과정에서 다음을 관찰할 수 있다. - 어떤 컴포넌트와 패턴이 혼란스러운가 - 문서나 Figma 파일에서 어떤 정보가 부족한가 - 기존 시스템에서 이상하거나 잘 작동하지 않는 부분은 무엇인가 - 팀이 사용자의 필요를 추측하는 대신, 실제 사용 데이터를 바탕으로 컴포넌트와 문서를 개선할 수 있다. - 페어링 중에는 다음과 같은 질문에 답할 수 있다. - 디자이너와 엔지니어가 컴포넌트 라이브러리의 존재를 알고 있는가 - HTML·CSS의 최신 모범 사례를 이해하고 있는가 - 특정 컴포넌트를 사용하는 것이 조직 전체에 왜 유리한지 설명하고 있는가 - 개인 작업에서 유용한 레이아웃을 공식 패턴으로 발전시킬 수 있는가 - 오피스 아워는 사용자가 언제 도움을 받아야 하는지 판단하지 못해 참여율이 낮을 수 있지만, 페어링은 실제 작업 흐름 안에서 문제를 발견한다. ## 비판을 협업으로 전환하는 페어링 - 디자인 시스템 팀과의 협업은 추가적인 디자인 리뷰가 아니라, 작업 속도를 높이고 향후 버그를 줄이는 과정처럼 느껴져야 한다. - 초기 디자인 시스템은 복잡하고 문서화가 부족한 경우가 많다. - 사용할 수 있는 색상이 제한되어 있다는 사실 - 이미 동일한 용도의 컴포넌트가 존재한다는 사실 - 특정 구현 방식이 접근성 기준을 위반한다는 사실 - 이런 규칙을 한꺼번에 강요하면 통제적으로 보일 수 있고, 엔지니어는 문서를 무시하며 디자이너는 기존 시스템과 어울리지 않는 UI를 만들 수 있다. - 페어링은 디자인 시스템 팀이 머릿속에만 보관하던 코드베이스의 제약과 조직의 지식을 직접 전달하게 한다. - 동시에 디자인 시스템 팀도 제품 디자이너가 실제로 어떤 일을 해야 하는지 이해하게 된다. - 결과적으로 디자인 시스템 팀은 현장의 요구를 파악하고, 제품 팀은 프런트엔드 컴포넌트와 패턴을 배우면서 양쪽 모두 더 빠르게 작업할 수 있다. ## 시스템의 지지자를 만드는 방법 - 페어링을 경험한 디자이너와 엔지니어는 디자인 시스템을 단순한 규칙 모음이 아니라 자신의 작업을 개선하는 도구로 이해하게 된다. - 직접 협업을 통해 얻은 지식은 각 팀으로 돌아가 자연스럽게 공유될 수 있다. - 디자인 시스템의 채택을 높이려면 규칙 준수를 감시하기보다, 시스템이 창의성을 제한하는 것이 아니라 작업에 “추진력을 더해준다”는 경험을 제공해야 한다. - 이런 경험이 축적되면 디자인 시스템 팀 외에도 시스템을 설명하고 추천하는 내부 전도자(evangelist)가 늘어난다. 실무적으로는 정기적인 페어링 세션을 실제 디자인·개발 과제와 연결하고, 세션에서 발견한 혼란과 요구를 컴포넌트·문서 개선으로 바로 반영하는 것이 좋다.

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

한 디자이너가 더 윤리

Cat Noone은 접근성을 제품 개발의 마지막 점검이 아니라 초기 설계 원칙으로 삼아야 한다고 주장한다. 그녀는 의료 정보 공유 앱 Iris Health, 색각 이상 접근성 도구 Stark, 자폐 아동용 의사소통 앱 Lyra를 통해 소외되기 쉬운 사용자도 제품의 기본 사용자로 고려해야 한다는 점을 보여준다. 접근성을 높이는 일은 디자인을 제한하는 것이 아니라 더 많은 사람에게 제품을 열어 주는 방법이다. ## 접근성을 처음부터 고려해야 하는 이유 - 장애가 있는 사용자 중 상당수가 온라인 서비스를 이용하므로, 접근성을 무시하면 잠재 사용자층의 약 10%를 놓칠 수 있다. - 접근성을 “UI를 나쁘게 만드는 제약”으로 보는 인식을 비판한다. - 제품 기획 단계부터 신체적·인지적·감각적 특성이 다른 사용자들을 조사하고, 각 집단에 맞게 UI와 기능을 조정해야 한다. - “전형적인 사용자”라는 가정 자체가 기술 업계의 사각지대를 만들 수 있다. ## Iris Health: 위급 상황에서 의료 정보를 전달하는 서비스 - 해외 체류 중 사고가 발생하면 가족이나 의료진이 사용자의 알레르기, 복용 약, 혈액형, 당뇨 여부 등을 알기 어렵다는 문제에서 출발했다. - 사용자가 병원에 있는 것으로 감지되면 안부를 확인하고, 10분 안에 응답이 없을 경우 등록된 비상 연락처에 문자 메시지를 보낸다. - iPhone 잠금 화면에 의료 카드가 표시되어 의료진이 이름, 약물, 알레르기, 장기 기증 여부 등의 정보를 빠르게 확인할 수 있다. - 만성질환자뿐 아니라 해외 거주자, 응급 상황에서 의사 표현이 어려운 사람에게도 유용하도록 설계됐다. - **교훈:** 사용자의 상황을 여러 각도에서 상상하고, 다양한 사용자 집단이 실제로 서비스를 어떻게 사용할지 충분히 검토해야 한다. ## Stark: 색각 이상과 대비를 확인하는 디자인 도구 - 의료 앱을 만들면서 접근성을 지원하는 디자인 도구가 부족하다는 문제를 발견해 개발했다. - Sketch에서 레이어를 선택해 다양한 색각 이상 유형을 시뮬레이션할 수 있다. - 텍스트와 배경색의 대비 비율을 확인해 색상 조합이 읽기 어려운지 판단할 수 있다. - Twitter, ESPN, Palantir, Dropbox, Microsoft 등의 팀에서도 사용됐다. - 접근성 검사를 별도 업무로 미루지 말고 디자인 워크플로에 기본 기능처럼 포함해야 한다. - Stark 외에도 Contrast, W3C 접근성 체크리스트 등을 활용해 표준 준수 여부와 개선점을 점검할 수 있다. - 시각과 촉각을 함께 고려한 Braille Neue 같은 서체도 접근성을 확장하는 사례로 소개된다. ## Lyra: 자폐 아동을 위한 기호-음성 의사소통 앱 - 대학 시절 다양한 특수 필요를 가진 아동들과 일한 경험을 바탕으로 시작됐다. - 비언어적 자폐 아동이 기호를 선택해 음성으로 의사를 표현할 수 있도록 돕는다. - 1985년부터 사용된 라미네이트 카드와 벨크로 방식의 의사소통 도구를 디지털 환경에 맞게 현대화하려는 프로젝트다. - 기존 방식은 아동이 디지털 세계에 참여하는 데 한계가 있으므로, 더 편리하고 자연스러운 의사소통 수단을 제공하려 한다. - 개발팀은 당시 베타 버전 출시를 준비하고 있었다. - **교훈:** 접근성 디자인을 제대로 만들려면 관련 사용자와 문제 영역을 스스로 학습해야 하며, Microsoft의 Inclusive Design 가이드 같은 자료부터 참고할 수 있다. 제품을 만들 때 접근성을 출시 직전의 검수 항목으로 두기보다, 사용자 조사·정보 구조·시각 디자인·개발 도구에 기본값으로 포함하는 것이 좋다. 특히 실제 장애 사용자와 함께 테스트하고, 색상 대비·키보드 사용·의사소통 방식 등 구체적인 사용 조건을 반복적으로 검증해야 한다.

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

피그마 스타일 베타: 텍

Figma Styles 베타는 텍스트와 레이어 속성을 독립적인 스타일로 관리해 디자인 전반의 일관성과 유지보수성을 높이려는 기능이다. 텍스트 형식·색상·정렬 등을 분리해 조합할 수 있으며, 팀 라이브러리를 통해 최신 스타일을 공유하고 변경 사항을 동기화한다. 또한 하나의 텍스트 필드 안에서도 일부 문장에 서로 다른 스타일을 적용하면서 원본 스타일과의 연결을 유지하는 것이 핵심이다. ## 스타일 속성의 모듈화 - 기존 디자인 도구에서는 텍스트 스타일에 글꼴, 색상, 정렬 등이 함께 묶였다. - 예를 들어 제목·부제목·본문 3종에 색상 3개를 적용하면 최소 9개의 스타일이 필요했다. - Figma Styles는 다음 속성을 개별적으로 설정하고 조합할 수 있게 한다. - 텍스트 형식 - 채우기 및 색상 - 정렬 - 레이아웃 그리드 - 효과 - 선(stroke) - 링크 색상처럼 특정 색상만 바뀌는 경우, 해당 채우기 스타일 하나만 수정하면 이를 사용하는 모든 디자인에 변경 사항이 전파된다. ## 팀 라이브러리를 통한 일관성 관리 - 스타일은 팀 라이브러리에서 공유할 수 있다. - 팀원 모두가 최신 버전의 디자인 시스템을 사용할 수 있다. - 팀이 스타일을 활성화하면 변경 사항에 대한 알림을 받을 수 있다. - 개인 작업뿐 아니라 여러 디자이너가 참여하는 대규모 디자인 시스템 관리에도 적합하다. ## 텍스트 필드 내부의 부분 스타일 적용 - 기존 도구에서는 하나의 텍스트 필드에 단일 스타일만 적용되는 경우가 많았다. - 문장 일부를 링크로 만들거나, 특정 부분을 소제목처럼 표시하면 원래 텍스트 스타일과의 연결이 깨질 수 있었다. - Figma에서는 텍스트 일부를 선택해 서로 다른 텍스트 스타일이나 채우기 스타일을 적용할 수 있다. - 한 텍스트 필드 안에서 다음과 같은 구성이 가능하다. - 본문 중 일부를 링크 색상으로 표시 - 문장 일부를 소제목으로 지정 - 특정 구간에 별도의 서식 적용 - 부분적으로 다른 스타일을 적용해도 관련 스타일과의 연결이 유지되므로, 스타일 변경 시 해당 부분도 함께 업데이트된다. ## 베타 도입 방식과 기대 효과 - 이 기능은 2018년 5월 비공개 베타로 공개됐다. - 작은 팀부터 큰 팀 순서로 마이그레이션하며, 한 번 진행하면 되돌릴 수 없는 방식이었다. - 새로운 스타일 관리 방식에 적응이 필요하지만, 반복적인 수동 수정과 스타일 중복을 줄이는 것이 목적이다. - 개인 디자이너에게는 일상적인 편집 작업을 단순화하고, 팀에는 확장 가능한 디자인 시스템 운영을 제공한다. Figma Styles의 핵심 장점은 스타일을 세부 속성 단위로 분리하고, 그 연결 관계를 유지한다는 점이다. 디자인 시스템을 운영한다면 색상·타이포그래피·효과를 독립적으로 관리하고 팀 라이브러리에서 공유하는 방식이 변경 대응과 일관성 유지에 유리하다.

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

18명의 디자이너가 전망

2018년 UI/UX의 중심 과제는 시각적 유행보다 사용자의 경험과 사회적 책임을 개선하는 데 있다는 전망이다. 18명의 디자이너는 접근성, 윤리, 협업, 디자인 시스템, 개발 도구의 통합을 주요 변화로 꼽았다. 동시에 표준 시스템을 무비판적으로 따르거나 효율성만 추구하는 흐름에 대한 경계도 제시한다. ## 접근성이 디자인의 우선순위가 된다 - 디자이너의 개성이나 시각적 과시보다 모든 사용자가 콘텐츠를 이해하고 사용할 수 있는지가 중요해진다. - 필수 요소에 지나치게 옅은 회색을 사용하거나, 장식적인 애니메이션을 과도하게 적용하는 관행을 줄여야 한다. - 접근성은 부가 기능이 아니라 제품 설계 초기부터 고려해야 할 기본 조건으로 제시된다. - 다만 접근성·포용적 디자인은 필요한 작업임에도 업계의 관심과 참여가 부족할 것이라는 비관적인 전망도 함께 나온다. ## 디자인 협업이 엔지니어링 방식에 가까워진다 - 디자인 팀도 개발 팀처럼 체계적인 협업과 검토 절차를 도입할 것으로 예상된다. - 코드 리뷰와 유사한 디자인 리뷰가 일반화될 수 있다. - 디자인 도구가 코드 린터처럼 일관성이나 오류를 자동으로 점검하는 방향으로 발전할 수 있다. - 오픈소스 엔지니어링 프로젝트처럼, 사용자 경험과 정보 설계를 위한 오픈소스 디자인 패턴이 늘어날 가능성이 있다. ## 디자이너의 윤리적 책임이 커진다 - UX/UI 디자인은 사용자의 행동과 선택에 직접 영향을 주므로, 디자이너는 자신의 영향력을 더 자각해야 한다. - 제품의 편의성과 전환율만이 아니라 디자인 결정이 사용자와 사회에 미치는 윤리적 결과를 고려해야 한다. - 어떤 사용자를 배제하거나 조작하는지, 정보와 선택지를 공정하게 제공하는지 검토하는 태도가 중요해진다. ## 표준 디자인 시스템의 무비판적 사용 - Material Design이나 Microsoft Fluent 같은 업계 표준 디자인 시스템에 대한 의존도가 높아질 수 있다. - 검증된 컴포넌트와 규칙은 일관성과 개발 효율을 높이지만, 모든 제품과 사용자에게 적합한 것은 아니다. - 표준을 그대로 적용하기보다 제품의 목적, 브랜드, 사용 맥락에 맞는지 비판적으로 판단해야 한다. - 디자인 시스템이 창의적 문제 해결을 대체하는 처방전처럼 사용될 위험이 있다. ## 디자인과 개발 도구의 통합 - 디자인 도구와 개발 도구가 계속 수렴하면서, 하나의 중앙화된 환경에서 디자인 시스템을 만들고 다양한 기술·플랫폼에 구현하는 흐름이 강화될 것으로 보인다. - CSS Grid와 사용자 정의 변수는 레이아웃과 스타일을 더 유연하고 효율적으로 구현하게 한다. - Vue와 React 같은 프레임워크는 디자인 결과물을 실제 제품으로 연결하는 과정을 단순화한다. - 구현 효율이 높아진 만큼 절약된 시간을 더 책임감 있고 포용적인 경험을 설계하는 데 사용해야 한다. ## 접근성과 효율성 사이의 긴장 - 업계는 생산성과 구현 속도를 높이는 기술에는 빠르게 반응하지만, 접근성과 포용적 디자인처럼 많은 조사와 세심한 작업이 필요한 분야에는 상대적으로 소극적이다. - 따라서 접근성이 중요한 트렌드로 인정받더라도 실제 프로젝트 우선순위에서 밀릴 수 있다. - 진정한 발전은 새로운 도구를 도입하는 데 그치지 않고, 효율성을 사용자 모두의 경험 개선으로 연결하는 데 달려 있다. ## 실용적인 적용 방향 디자인 팀은 접근성 검토를 초기 요구사항에 포함하고, 정기적인 디자인 리뷰와 공통 컴포넌트 검증 절차를 마련하는 것이 좋다. 또한 Material이나 Fluent 같은 표준을 그대로 복사하기보다 사용자와 제품 맥락에 맞게 조정하고, 개발 효율로 확보한 시간을 포용성·윤리성·사용성 개선에 투자해야 한다.

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