archuive

디자인 시스템 컴포넌트 만들 때의 고민, State와 Status의 차이?

디쟈이너 — Wed, 30 Oct 2024 16:57:24 +0900

State (상태)

정의: state는 컴포넌트의 현재 조건이나 내부 상호작용의 결과를 나타냅니다. 사용자 행동(클릭, 입력 등)에 따라 컴포넌트가 가진 변화하는 상태를 설명하는 데 사용됩니다.
예시:
- Button: state="active", state="disabled", state="loading"
- Input: state="focused", state="filled", state="error"
사용 목적: state는 컴포넌트 내부의 동적 변화와 직접적으로 연관되어 있어, 사용자 경험을 반영하는 데 중점을 둡니다. 예를 들어, 버튼이 비활성화되어 있는 경우 사용자 상호작용이 제한된 상태임을 나타냅니다.

2. Status (상태 표시)

정의: status는 컴포넌트의 외부 상황이나 현재 상황에 대한 설명을 제공합니다. 보통 시스템이나 데이터 상태를 나타내며, 사용자가 직접적으로 상호작용한 결과가 아닌 현재의 진행 상황이나 정보 알림을 전달하는 데 쓰입니다.
예시:
- Badge: status="success", status="error", status="warning"
- Notification: status="new", status="unread"
- Progress Indicator: status="in-progress", status="completed"
사용 목적: status는 컴포넌트가 가진 정보를 사용자에게 명확하게 전달하는 데 초점을 두고 있습니다. 예를 들어, 성공 상태를 나타내는 status="success"는 사용자가 현재 작업이 성공적으로 완료되었음을 확인하도록 돕습니다.

비교 및 구분

state는 컴포넌트 자체의 조건이나 UI의 동적 반응을 나타내며, 사용자와의 상호작용에 따라 변하는 상태에 집중합니다.
status는 컴포넌트의 외부 상황을 설명하고, 정보 전달에 목적이 있어 상황의 결과나 현재 상태를 나타내는 데 주로 쓰입니다.

사용 예시

Button 컴포넌트에서 state는 버튼이 활성화된 상태인지, 로딩 중인지 등을 나타낼 수 있으며, status는 버튼이 클릭 성공 여부를 표시하는 용도로 활용될 수 있습니다.
Alert 컴포넌트에서는 state는 열림/닫힘을 나타내고, status는 메시지 유형(에러, 경고, 정보 등)을 전달합니다.

[Framer] CMS의 Filter 기능을 활용해 탭을 구성하는 방법

디쟈이너 — Wed, 4 Sep 2024 18:53:55 +0900

프레이머(Framer) CMS의 강력한 필터 기능을 활용하면 콘텐츠를 손쉽게 관리하고 사용자가 원하는 방식으로 콘텐츠를 탐색할 수 있는 인터페이스를 만들 수 있습니다. 이번 포스팅에서는 프레이머 CMS의 필터 기능을 활용해 블로그 게시물 목록을 날짜별로 구분하는 탭을 구성하는 방법을 단계별로 설명하겠습니다.

1. CMS 컬렉션 설정하기

우선 프레이머 CMS에 블로그 게시물 컬렉션을 만들어야 합니다. 예를 들어, 4월과 5월에 게시된 블로그 포스트가 각각 4개씩 있다고 가정하겠습니다. 다음은 이를 기반으로 한 CMS 컬렉션을 만드는 방법입니다.

프레이머 프로젝트에 CMS 컬렉션 추가: CMS 탭에서 새로운 컬렉션을 생성하고, 필요한 필드(제목, 날짜, 콘텐츠 등)를 설정합니다.
데이터 입력: 해당하는 블로그 게시물들을 CMS에 추가합니다. 날짜 필드를 정확히 입력해야 필터가 올바르게 작동합니다.

2. 포스트 목록을 컴포넌트화하기

필터 기능을 구현하려면 블로그 포스트 목록을 하나의 컴포넌트로 만들어야 합니다. 이렇게 하면 필터 버튼과 게시물 목록을 일관되게 관리할 수 있습니다.

포스트 목록 컴포넌트 생성: 블로그 포스트가 표시될 영역을 선택한 뒤, 컴포넌트화합니다. 이 컴포넌트는 기본적으로 모든 게시물을 표시하는 상태를 유지해야 합니다.
기본 상태 설정: 이 컴포넌트의 첫 번째 변형(variant)을 기본 상태로 설정합니다. 기본 상태에서는 모든 게시물이 표시되도록 설정합니다.

3. 필터 버튼 추가 및 설정

이제 날짜별로 게시물을 구분하는 필터 버튼을 추가하고, 각 버튼을 필터에 맞게 설정해야 합니다.

필터 버튼 추가: April, May 등 원하는 필터 기준에 맞게 버튼을 추가합니다.
버튼 활성화 상태 설정: 각각의 버튼에 대해 활성화 상태(active state)를 설정합니다. 이렇게 하면 사용자가 어떤 필터가 활성화되었는지 시각적으로 알 수 있습니다.

4. 필터 변형(variant) 추가하기

필터 기능을 활성화하려면 각 필터 버튼에 맞는 변형(variant)을 추가해야 합니다. 예를 들어, 4월 게시물만 표시하는 변형과 5월 게시물만 표시하는 변형을 각각 만들어야 합니다.

새로운 변형 생성: April과 May 게시물에 맞는 변형(variant)을 각각 만듭니다. 첫 번째 변형은 'April', 두 번째 변형은 'May'로 이름을 설정합니다.
각 변형에 맞는 게시물 필터링: 각 변형에서 게시물 목록을 선택한 뒤, '날짜 필터'를 적용하여 4월 혹은 5월의 게시물만 표시되도록 설정합니다.

5. 날짜 필터 적용하기

프레이머 CMS는 '날짜 필터' 기능을 제공하므로, 이를 활용해 각 변형(variant)에서 해당 월의 게시물만 표시되도록 필터를 설정할 수 있습니다.

필터 추가: 변형(variant)을 선택한 뒤, CMS 컬렉션 리스트에서 필터 옵션을 클릭합니다.
날짜 필터 설정: '날짜 필터' 유형에서 'is between dates' 조건을 선택하고, 필터링할 날짜 범위를 지정합니다. 예를 들어, April 변형에서는 4월 1일부터 4월 30일까지의 날짜 범위를 설정합니다.
동일한 방식으로 다른 변형에 필터 적용: May 변형에도 같은 방식으로 'is between dates' 조건을 설정해 5월의 게시물만 표시되도록 합니다.

6. 필터 버튼과 변형(variant) 연결하기

이제 각 필터 버튼이 올바르게 작동하도록 변형(variant)과 연결해야 합니다.

버튼과 변형 연결: 각 필터 버튼을 선택한 뒤 해당 변형(variant)으로 링크합니다. 예를 들어, 'April' 버튼은 'April Variant'에 연결하고, 'May' 버튼은 'May Variant'에 연결합니다.
기본 변형 연결: 'All' 버튼은 기본 상태 변형(variant)으로 연결해 모든 게시물을 표시하도록 설정합니다.

프레이머 CMS 탭 만들기 성공

github GPG 설정 했는데 Signed-off-by: 표시 안되는 문제

디쟈이너 — Mon, 19 Aug 2024 14:27:14 +0900

GPG 키 설정을 완료하고 커밋을 남기면

This is my commit message

Signed-off-by: Random J Developer <random@developer.example.org>

이렇게 Sighned-off-by 가 표시되어야 하는데, 안되는 경우가 있다.

이 경우에는 커밋을 남길 때 아래와 같이 남겨보자.

git commit --signoff --message 'This is my commit message'

git commit -s -m "This is my commit message"

만약 이미 커밋을 남겼다면, 아래 명령어로 수정할 수 있다.

git commit --amend --signoff

이미 GitHub에 변경 사항을 푸시한 경우 이후에 git push -f 을 사용하여 브랜치를 강제 푸시해준다.

이렇게 커밋을 수정할 수 있다.

필터를 디자인할 때 고민해야할 UI 및 UX

디쟈이너 — Mon, 15 Jul 2024 20:28:44 +0900

UXPin의 Filter UI and UX 101 – An In-Depth Guide 를 참고해 작성된 글입니다.

필터는 사용자 인터페이스 디자인에서 강력한 도구로, 사용자 여정을 간소화하고 효율성과 콘텐츠 발견을 통해 사용자 참여를 높이는 데 기여합니다. 이 글에서는 UI 필터 디자인의 기본 원칙과 실무 사례를 통해 사용자 친화적인 필터 패턴을 설계하는 방법을 탐구합니다. 또한, 주요 기술 기업들의 예시를 통해 필터가 사용자 경험을 어떻게 향상시키는지 살펴봅니다.

UI 필터란 무엇인가?

UI 필터는 사용자가 특정 기준에 따라 데이터 집합이나 옵션을 좁히는 데 사용하는 디자인 요소입니다. 예를 들어, 전자상거래 사이트에서 사용자는 사이즈, 색상, 가격 등을 기준으로 제품을 검색할 수 있습니다. 필터 UI는 사용자가 원하는 것을 빠르게 찾을 수 있게 하여 시간을 절약하고 좌절감을 줄입니다.

필터가 사용자 경험에 미치는 영향

필터는 사용자가 콘텐츠를 찾고 경험하는 방식을 제어할 수 있도록 하여 작업 속도를 높이고 디지털 제품과의 상호작용을 개선합니다. 필터는 다음과 같은 방식으로 사용자 경험을 향상시킵니다:

내비게이션 효율성: 사용자는 관련 없는 데이터를 스크롤할 필요가 없습니다. 예를 들어, 전자상거래 사이트에서 수백 개의 신발을 검색하는 대신, 사용자는 사이즈, 색상, 브랜드로 필터링하여 가장 관련성 높은 결과를 찾을 수 있습니다.
개인화된 콘텐츠 제공: 필터는 사용자의 개별 선호도에 맞춰 콘텐츠를 제공합니다. 예를 들어, 뉴스 앱에서 '기술' 또는 '건강'과 같은 특정 카테고리를 선택하여 사용자가 관심 있는 뉴스를 제공합니다.
의사 결정 지원: 너무 많은 옵션으로 사용자를 압도하면 의사 결정이 어려워질 수 있습니다. 필터는 선택지를 제한하여 사용자가 결정을 내리기 쉽게 만듭니다. 예를 들어, 스트리밍 앱에서 수천 개의 영화를 검색하는 대신, '최고 평점' 또는 '새 릴리스'만 표시할 수 있습니다.
인지 부하 감소: 사용자는 과도한 정보를 처리할 필요가 없습니다. 필터는 필요한 것만 표시하여 사용자가 과부하나 피로를 느끼지 않도록 합니다.
만족도 및 유지율 향상: 사용자가 원하는 것을 신속하고 효율적으로 찾으면 만족도가 높아지고 플랫폼을 계속 사용할 가능성이 커집니다.

사용자 친화적인 필터 디자인의 원칙

단순함과 명확성

필터 인터페이스는 이해하기 쉬워야 하며, 너무 많은 옵션으로 사용자를 압도해서는 안 됩니다. 예를 들어, 온라인 의류 상점은 사이즈, 색상, 핏, 브랜드, 가격 등 명확한 카테고리를 제공해야 합니다. 복잡한 하위 필터는 쇼핑객을 혼란스럽게 할 수 있으므로 피해야 합니다.

반응성과 피드백

필터는 변경 사항을 신속하게 적용하고 사용자에게 피드백을 제공해야 합니다. 예를 들어, 필터가 적용된 결과 수를 표시하여 사용자가 스크롤할 항목 수를 예상하고 좌절감을 방지할 수 있습니다. 실시간 반응성과 명확한 피드백은 사용자 경험을 향상시키는 중요한 요소입니다.

필터의 우선순위 설정

모든 필터가 동일한 중요성을 가지지는 않습니다. 사용자 요구를 이해하고 가장 자주 사용되는 필터를 우선적으로 제공하고 나머지는 숨겨야 합니다. 예를 들어, 숙소 필터는 주요 UI에 날짜, 손님, 위치를 표시하고 "모든 필터 보기" 버튼이나 아이콘을 통해 나머지 필터를 접근할 수 있게 해야 합니다.

유연성과 제어

사용자가 실수를 쉽게 수정할 수 있어야 합니다. 예를 들어, '필터 초기화' 버튼을 통해 사용자가 기본값으로 빠르게 되돌릴 수 있어야 합니다. 필터 사용 중 실수로 인해 불편함을 겪지 않도록 유연한 제어를 제공하는 것이 중요합니다.

가시성과 접근성

필터는 페이지에서 쉽게 접근할 수 있어야 합니다. 예를 들어, 사용자는 검색 필드 근처에 필터가 있는 것을 기대합니다. 필터는 시각적으로 명확하고 접근하기 쉬워야 하며, 모든 사용자가 사용할 수 있도록 대비, 화면 판독기 호환성, 키보드 내비게이션 등을 고려해야 합니다.

플랫폼 간 필터 디자인

iOS와 Android의 디자인 패턴을 이해하고, 각 플랫폼에 맞는 일관된 사용자 경험을 제공해야 합니다.

iOS 플랫폼 패턴: iOS 디자인은 종종 필터를 위한 분할 컨트롤을 사용합니다. 예를 들어, 쇼핑 앱에서 '남성', '여성', '아동'과 같은 분할 컨트롤이 브라우징 화면 상단에 있을 수 있습니다.
Android 플랫폼 패턴: Android UI는 주로 기본 필터링 옵션을 위한 탭을 사용합니다. 드롭다운은 보조 필터링이나 정렬 옵션에 자주 사용됩니다.
플랫폼 간 일관성: 플랫폼별 패턴을 준수하여 네이티브 경험을 유지하는 것이 중요하지만, 핵심 기능은 모든 플랫폼과 모바일 앱에서 일관되게 유지해야 합니다. iOS에서 필터 옵션이 있는 경우, 동일한 기능이 Android에서도 접근할 수 있어야 합니다.
적응형 UI 컴포넌트: 사용자 기기와 운영체제에 맞게 적응하는 컴포넌트를 활용하여 원활한 경험을 제공해야 합니다.

효과적인 UI 필터 설계 방법

자연어 사용

사용자에게 친숙한 단어와 구문을 사용하여 사용자가 필터 옵션을 쉽게 이해할 수 있도록 해야 합니다. 예를 들어, 애완동물 전자상거래 상점에서 'Canine'과 'Feline' 대신 'Dogs'와 'Cats'를 사용해야 합니다.

필터 내 검색 기능 제공

긴 목록을 다룰 때는 검색 기능을 제공하여 사용자가 원하는 옵션을 쉽게 찾을 수 있게 해야 합니다. 예를 들어, 여러 장르가 있는 온라인 서점은 필터 내에 검색창을 제공하여 사용자가 '스릴러'를 입력하고 바로 해당 장르로 이동할 수 있게 해야 합니다.

점진적 공개 활용

가장 자주 사용되는 필터를 먼저 보여주고, 추가 필터 옵션을 제공해야 합니다. 예를 들어, 부동산 사이트는 가격, 도시, 가격 범위를 먼저 보여주고, '추가 보기' 필터 옵션을 통해 더 구체적인 옵션을 제공해야 합니다.

시각적 신호 활용

색상, 아이콘, 타이포그래피 등을 사용하여 필터 옵션을 명확하게 전달해야 합니다. 예를 들어, 필터 옵션 옆에 색상 견본을 표시하여 사용자가 결과를 더 빨리 스캔할 수 있도록 해야 합니다.

접근성 고려

모든 사용자가 필터를 사용할 수 있도록 대비, 화면 판독기 호환성, 키보드 내비게이션 등을 고려해야 합니다. 예를 들어, 앱이 필터 카테고리에 색상을 사용하는 경우, 색맹 사용자가 탐색하고 결과를 스캔할 수 있도록 아이콘을 추가해야 합니다.

좋은 필터 UI 디자인 사례

에어비앤비(Airbnb)

에어비앤비는 2023년에 더 접근 가능하고 사용자 친화적으로 필터 UI를 재설계하였습니다. 사용자는 검색 필터 옆의 보편적으로 인식 가능한 아이콘을 통해 검색 필터 오버레이에 접근할 수 있습니다. 에어비앤비는 사용자가 가격 필터를 쉽게 사용할 수 있도록 두 가지 UI 디자인 패턴을 제공합니다. 사용자들은 큰 버튼, 아이콘, 체크박스, 슬라이더, 스위치를 사용하여 자신의 선호도를 적용할 수 있습니다.

부킹닷컴(Booking.com)

부킹닷컴은 여행자에게 수백만 개의 숙소를 제공해야 하기 때문에 필터를 사용해 선택지를 좁힙니다. 부킹닷컴은 접근성을 높이기 위해 필터 아이콘과 라벨을 사용합니다. 가격 필터는 상단에 표시되고 인기 필터 목록은 아래에 제공되어 사용자가 너무 많이 스크롤하지 않고도 선택할 수 있게 합니다.

스포티파이(Spotify)

필터는 검색에만 적용되는 것이 아니라 사용자가 액세스하려는 콘텐츠를 결정하는 데도 도움이 됩니다. 스포티파이는 홈 화면에서 음악, 팟캐스트 및 쇼, 오디오북의 세 가지 주요 카테고리를 필터링하는 버튼을 사용합니다. 이러한 필터는 스포티파이의 홈 화면을 사용자 친화적이고 효율적으로 만들어 사용자가 한 번의 클릭으로 선호하는 콘텐츠를 선택할 수 있도록 합니다.

아마존(Amazon)

아마존의 데스크탑 인터페이스는 페이지 상단에 검색 필드를 표시하고 왼쪽 사이드바에 필터를 깔끔하게 정리하여 배치합니다. 사용자는 아이콘, 체크박스, 버튼 또는 맞춤 가격 입력란을 사용하여 필터를 적용할 수 있습니다. 필터 항목을 선택하면 필터 결과가 자동으로 로드되어 '적용 버튼'이 필요 없어지고 클릭 및 상호작용이 줄어듭니다.

구글 지도(Google Maps)

구글 지도는 일반적인 검색 카테고리를 표시하기 위해 수평 스크롤 내비게이션 패턴을 사용합니다. 사용자가 '커피'와 같은 광범위한 용어를 적용하면, 보조 필터를 사용하여 더 세부적으로 결과를 좁힐 수 있습니다. 구글 지도의 필터링 인터페이스는 다양한 옵션이 있는 상황에서도 최소한의 클릭과 타이핑으로 사용자가 원하는 것을 찾을 수 있도록 돕는 좋은 예입니다.

토스트 알림, 어떻게 사용해야할까.

디쟈이너 — Tue, 9 Jul 2024 07:12:42 +0900

토스트 얼럿을 어떻게 사용하면 좋을지 찾아보다 간략하게 정리를 잘 한 아티클을 발견해 한국어로 번약했습니다.

소프트웨어 애플리케이션의 성공은 사용자 경험에 크게 좌우되며, 사용자 경험이란 애플리케이션의 멋진 외관과 느낌이라고 잘못 이해하는 경우가 많습니다. 실제로, 사용자 경험의 개념은 애플리케이션의 사용성과 사용자 친화성을 향상시키는 것에 중점을 둡니다. 여기에는 다양한 측면과 요소들이 포함되며, 그 중 하나가 토스트 알림(Toaster Notification)입니다.

토스트 알림(Toaster Notification)/토스트(Toast)이란 무엇인가요?

토스트 알림은 사용자가 특별한 주의를 기울이지 않고도 확인할 수 있는 알림 메커니즘으로, 주로 다양한 사용자 정보를 전달하거나

상태를 표시하는 데 사용됩니다.

예를 들어, 오류나 성공 상태를 보여주거나

특정 작업을 수행하도록 유도할 수 있습니다.

색상 코딩이나 적절한 아이콘을 추가하면 알림을 더 효과적으로 전달할 수 있습니다.

언제 표시해야 하나요?

주의를 많이 요하지 않는 메시지를 전달할 때, 단일 상태 업데이트를 제공하는 데 적합합니다. 그러나 이 메커니즘은 일반적으로 시간이 제한되어 있으므로 주요 알림 방법으로 사용해서는 안 됩니다.

배치(위치)

토스트 알림을 어디에 띄워야할지 위치에 대해 고민하게 되는데, 토스트의 배치는 사용 사례와 표시하려는 정보의 종류에 따라 다릅니다. 예를 들어, 윈도우와 맥은 서로 다른 접근 방식을 취합니다. 두 시스템 모두 Law of Proximity 법칙을 따라 상태 표시줄과 가까운 위치에 알림을 배치하여 상태 표시줄과 토스트 알림 사이의 관계를 이해하기 쉽게 합니다. 반면에 피그마(Figma)는 화면의 하단 중앙에 알림을 표시하여 중요한 정보를 가리지 않도록 합니다.

접근성

사용자에게 단어당 500밀리초의 시간을 주는 것이 좋습니다. 짧은 알림의 경우 최대 10단어를 4000밀리초 + 1000밀리초 버퍼로 처리할 수 있습니다(모든 사용자가 영어를 모국어로 사용하는 것은 아니기 때문입니다). 텍스트가 140자(영어로 20-35단어) 이상인 경우, 알림 시간을 설정하지 않는 것이 좋습니다. 알림의 배치가 애플리케이션의 중요한 부분을 가리지 않도록 해야 합니다. UX 글쓰기와 색상 코딩을 사용하여 정보를 최적화할 수 있습니다.

애니메이션 조정

400ms — 인워드 애니메이션: 사용자가 화면을 보고 있을 때 주의를 기울이는 데 걸리는 시간입니다.
1800ms — 아웃워드 애니메이션: 사용자가 알림이 화면에서 사라지는 것을 관찰할 수 있는 충분한 시간입니다.
호버-스테이 추가: 사용자가 토스트 알림 위에 커서를 올리면 알림이 화면에 유지됩니다(정보에 따라 다름).

크기 조정

토스트 알림은 일정한 너비를 유지하며, 높이는 알림 메시지의 길이에 따라 조정됩니다. 내용 지침에 따라, 토스트 알림은 최대 두 줄의 텍스트로 제한하는 것이 좋습니다.

Clone vs. Duplicate: 개발자 중심 제품 디자인 시 용어 선택

디쟈이너 — Thu, 4 Jul 2024 18:21:56 +0900

개발자들이 사용하는 프로덕트를 만드는 UI/UX 디자이너들에게 있어, "clone"과 "duplicate" 중 어느 용어를 사용할지 헷갈리는 상황이 발생합니다. 이 둘 중 어떤 용어를 사용할지는 주로 대상 사용자의 친숙도와 사용 상황에 따라 달라집니다. 아래에서는 두 용어의 차이점과 각 용어가 어떤 상황에서 더 적합한지를 비교해 보겠습니다.

Clone vs Duplicate - Clone은 기술 사용자들을 위해 추천한다

Clone: 기술 사용자들을 위한 용어

선호 대상

주로 개발자와 기술 분야의 사용자들

의미

기본 구조와 설정을 포함한 정확한 복제를 의미합니다.
이는 원본 항목의 모든 설정과 구성이 동일하게 유지된다는 것을 나타냅니다.

사용 예

Jira 및 Azure DevOps와 같은 도구에서는 이슈나 테스트 계획의 정확한 복제를 위해 "clone"이라는 용어를 사용합니다. 예를 들어, Jira에서 클론된 이슈는 원본과 동일한 데이터를 포함하며, 이를 통해 사용자는 특정 작업이나 버그를 다른 프로젝트나 환경으로 쉽게 복사할 수 있습니다.
MS Learn 및 Elements에서도 이 용어가 사용되며, 기술적인 정확성과 일관성을 중시하는 상황에서 자주 활용됩니다.

Duplicate: 비기술 사용자들을 위한 용어

선호 대상

비기술 사용자들

의미

일반 비즈니스 응용 프로그램에서 사용되는 용어로, 문서나 파일의 복제를 의미합니다.
이는 복사본이 원본과 유사하지만, 반드시 모든 설정이 동일하게 유지되지 않을 수도 있음을 암시합니다.

사용 예

워드나 엑셀과 같은 소프트웨어에서 문서 복제를 위해 흔히 사용됩니다. 예를 들어, 엑셀에서 문서를 복제할 때, 사용자는 주로 데이터만 복사되길 원하며, 특정 설정이나 매크로는 제외될 수 있습니다.
User Experience Stack Exchange에서도 이러한 용어가 자주 사용되며, 기술적 요소보다는 사용 편의성을 중시하는 경우에 적합합니다.

결론 및 추천

개발자 중심의 제품

"Clone"을 사용하는 것이 더 적합합니다.
이 용어는 개발자들에게 기술적 정밀성을 기대하게 만들며, 복사된 항목이 모든 설정과 구성을 유지할 것이라는 신뢰감을 줍니다.

더 넓은 사용자 대상 또는 명확성을 중시하는 경우

"Duplicate"가 더 나을 수 있습니다.
이는 비기술 사용자들에게 더 친숙하고 이해하기 쉬운 용어로, 복사본이 원본과 동일하지 않아도 되는 경우에 적합합니다.

따라서, UI/UX 디자이너로서 어떤 용어를 선택할지 결정할 때, 대상 사용자의 기술적 배경과 사용 시나리오를 고려하는 것이 중요합니다. 개발자 중심의 환경에서는 "clone"을, 비기술 사용자들을 위한 환경에서는 "duplicate"를 사용하는 것이 바람직합니다.

웹 접근성: 모두를 위한 디자인의 중요성

디쟈이너 — Wed, 3 Jul 2024 19:46:01 +0900

오늘날 디지털 시대에서 접근성은 모든 사용자에게 중요한 요소입니다. 이 글에서는 접근성의 중요성, 포괄적 디자인의 원칙, 그리고 디자이너로서 우리가 할 수 있는 방법에 대해 다룹니다.

웹 접근성: 모두를 위한 디자인의 중요성

왜 접근성이 중요한가?

모든 사람이 시력, 청력, 이동성 면에서 완벽하지 않습니다. 일부 사람들은 안경을 착용하거나 색맹일 수 있으며, 이동 중이거나 주의력 장애가 있을 수 있습니다. 이러한 다양성을 고려하지 않으면 사용자 절반이 우리 제품을 제대로 사용하지 못할 수 있습니다. 접근성을 고려하면 사용자 만족도를 높이고 더 넓은 청중에게 도달할 수 있는 기회를 얻게 됩니다.

포괄적 디자인이란 무엇인가?

포괄적 디자인은 가능한 많은 사람들의 필요와 능력을 고려하는 디자인입니다. 이는 단순히 장애를 가진 사람들만을 대상으로 하지 않으며, 시간과 상황에 따라 변하는 다양한 요구를 예상하고 문제를 사전에 해결하는 것을 목표로 합니다.

POUR 원칙: 인지 가능, 운용 가능, 이해 가능, 견고성

POUR는 네 가지 핵심 원칙을 의미합니다.

인지 가능: 디지털 콘텐츠가 다양한 방식으로 쉽게 해석되거나 처리될 수 있어야 합니다.
운용 가능: 디지털 제품이 쉽게 작동하고 제어될 수 있어야 합니다.
이해 가능: 사용자가 인터페이스의 기능과 정보를 쉽게 이해할 수 있어야 합니다.
견고성: 디지털 제품이 다양한 보조 기술 및 기기와 호환될 수 있어야 합니다.

디자이너가 할 수 있는 일

디자이너로서 우리는 시각적, 청각적, 인지적, 운동적 경험을 개선할 수 있는 작은 디자인 결정들을 통해 큰 영향을 미칠 수 있습니다.

시각적 경험 개선하기

색상
- 대비 비율: 높은 대비를 사용하여 시각적 요소를 더 명확하게 만듭니다. 텍스트의 경우 최소 4:5:1의 대비 비율을 유지합니다.
- 밝기: 밝은 색상은 정보를 읽고 처리하는 데 방해가 될 수 있습니다. 배경이나 큰 표면에 밝은 색상을 피하고, 중요한 메시지는 색상 외의 방법으로도 전달합니다.
- 색맹: 색맹 상태를 고려하여 색상 조합을 테스트합니다. 텍스트와 그래픽 요소를 명확하게 구분합니다.
타이포그래피
- 폰트 선택: 간결하고 명확한 폰트를 선택하여 시각적 소음을 줄입니다.
- 폰트 스타일링: 큰 블록의 텍스트에는 기울임꼴을 피하고, 대문자는 본문에서 피합니다.
- 폰트 크기: 최소 16px 이상의 폰트 크기를 사용하여 작은 화면에서도 쉽게 읽을 수 있도록 합니다.
단락 형식
- 편안한 단락 형식을 사용하여 사람들이 내용을 쉽게 스캔할 수 있도록 지원합니다. 제목, 부제목, 글머리 기호 등을 사용하여 내용을 체계적으로 정리합니다.

청각적 경험 개선하기

시각적 디자인은 청각적 경험을 지원할 수 있습니다. 시각적 단서와 청각적 단서를 함께 제공하여 사용자에게 피드백을 제공합니다. 예를 들어, 오류 메시지나 알림을 시각적 단서와 함께 제공하여 사용자 경험을 향상시킵니다.

인지적 경험 개선하기

지각
- 시각적 명확성: 명확한 시각적 언어를 통해 사용자가 인터페이스를 쉽게 인식하고 이해할 수 있도록 합니다.
- 계층 구조: 시각적 요소의 크기와 색상을 통해 콘텐츠의 중요도를 나타내고, 사용자가 내용을 쉽게 탐색할 수 있도록 합니다.
상호작용
- 기억: 사용자가 페이지의 위치나 작업을 기억할 수 있도록 명확한 제목과 탐색 경로를 제공합니다.
- 의사 결정: 제공되는 옵션의 수를 줄이고, 명확하게 정의된 계층 구조를 유지하여 의사 결정을 돕습니다.
- 주의 집중: 페이지의 산만한 요소를 최소화하고, 주요 목표에 집중할 수 있도록 지원합니다.

운동 경험 개선하기

피츠의 법칙에 따라 목표 영역을 더 크게 하고, 사용자와 목표 간의 거리를 줄여서 상호작용 시간을 줄입니다. 또한, 보조 기술을 사용하는 사용자들을 위해 포커스 상태를 시각적으로 강조하고, 페이지의 구조를 명확히 합니다.

성능 개선하기

포괄적 디자인은 가능한 많은 사람들이 인터넷에 접근하고 목표를 달성할 수 있도록 돕는 것입니다. 이를 위해 불필요한 요소를 제거하고, 이미지를 최적화하며, 레이지 로딩 패턴 등을 사용하여 성능을 향상시킵니다.

공감 능력 향상하기

사용자를 더 잘 이해하고, 그들의 관점에서 디자인 결정을 내릴 수 있도록 공감 능력을 키우는 것이 중요합니다. 사용자의 경험을 이해하고, 그들의 필요에 맞춘 디자인을 통해 더 나은 접근성을 제공할 수 있습니다.

바우하우스에서 배우는 협업과 창의성: 현대 UX 디자인에 적용하기

디쟈이너 — Sun, 30 Jun 2024 19:01:30 +0900

안녕하세요, 오늘은 바우하우스(Bauhaus) 운동에서 영감을 받아 협업을 통한 창의성을 찾는 방법에 대해 깊이 있게 탐구해보려고 합니다. 이 글은 Google Design의 Jens Riegelsberger가 Medium에 기고한 글을 번역한 것으로, 바우하우스 철학이 현대 UX 디자인에 어떻게 적용될 수 있는지 살펴보겠습니다.

바우하우스: 협업에서 창의적 영감을 찾다

UX 디자인과 바우하우스 철학

UX 디자인은 아직 초기 단계에 있으며, 종종 최근의 기술적 능력에 너무 집착하는 경향이 있습니다. 이는 장기적인 관점을 흐리게 할 수 있습니다. 이에 대한 해결책으로, 저는 한 세기 전으로 돌아가 바우하우스 초기 시절에서 영감을 찾는 것이 유용하다는 것을 알게 되었습니다.

바우하우스는 장식적 요소를 비판적으로 보고, 제품과 건물의 사용자에게 실용적이고 유용한 방식으로 서비스를 제공해야 한다고 주장했습니다. 이는 UX 디자인에서도 적용될 수 있는 철학입니다. 바우하우스는 예술과 공예의 경계를 허물고, 기능과 형태를 결합하는 새로운 접근 방식을 제시했습니다. 바우하우스의 교육 방식은 이론과 실습을 결합하여 학생들에게 실제 작업을 통해 배우도록 했습니다.

Fagus Factory는 Walter Gropius가 1919년에 Bauhaus를 설립하기 전인 1911년에 설계한 것입니다. 유리 외관은 혁명적이었고, 이 시대의 전형적인 장식적이고 역사적인 스타일에서 확실히 벗어났습니다.

협업의 중요성

바우하우스는 다양한 배경을 가진 사람들이 협력하여 혁신적인 디자인을 만들어 내는 것을 강조했습니다. 이러한 협업은 현대 UX 디자인에서도 중요한 요소입니다. 디자이너는 자신의 직감을 따르면서도, 공동 창작의 열린 환경에서 디자인 결정을 설명할 수 있어야 합니다. 바우하우스의 협업 정신은 디자인 과정에서 다양한 관점을 수용하고, 팀원들과의 긴밀한 협력을 통해 더 나은 디자인 결과를 도출하는 데 중요한 역할을 합니다.

현대 UX 디자인에의 적용

바우하우스의 철학과 방법론은 현대 UX 디자인에 여러 가지 방식으로 적용될 수 있습니다.

과거에서 배우기

바우하우스의 초기 작품에서 영감을 받아, 현재의 디자인에 새로운 아이디어를 도입할 수 있습니다. 예를 들어, 바우하우스의 단순하고 기능적인 디자인은 사용자 중심의 UX 디자인에 중요한 영감을 줄 수 있습니다. 바우하우스의 디자인 원칙을 현대 UX 디자인에 적용하면, 사용자 경험을 더욱 직관적이고 효율적으로 만들 수 있습니다.

협업 강화

팀원들과의 긴밀한 협업을 통해 더 나은 디자인 결과를 도출할 수 있습니다. 바우하우스의 협업 정신을 바탕으로, 다양한 배경을 가진 디자이너들이 함께 일하며 서로의 아이디어를 공유하고 발전시키는 것이 중요합니다. 협업은 창의성을 촉진하고, 다양한 관점을 반영한 포괄적인 디자인을 만들어낼 수 있습니다.

장식성 배제

실용적이고 기능적인 디자인을 통해 사용자 경험을 개선할 수 있습니다. 바우하우스는 불필요한 장식을 배제하고, 기능과 형태의 결합을 강조했습니다. 이는 UX 디자인에서도 유효한 접근 방식으로, 사용자가 필요로 하는 기능에 집중하고 직관적인 인터페이스를 제공하는 데 도움이 됩니다.

바우하우스와 현대 UX 디자인의 유사점

바우하우스와 현대 UX 디자인 사이에는 여러 가지 유사점이 있습니다. 두 접근 방식 모두 사용자 중심의 디자인을 강조하며, 기능성과 실용성을 중시합니다. 또한, 두 접근 방식 모두 협업과 다양한 관점의 통합을 중요하게 생각합니다.

사용자 중심 디자인

바우하우스는 디자인이 사용자에게 실질적인 가치를 제공해야 한다고 믿었습니다. 이는 현대 UX 디자인의 기본 원칙과 일치합니다. UX 디자이너는 사용자의 필요와 기대를 이해하고, 이를 반영한 디자인을 만들어야 합니다. 사용자 중심 디자인은 사용자의 문제를 해결하고, 더 나은 경험을 제공하는 데 초점을 맞춥니다.

기능성과 실용성

바우하우스는 불필요한 장식을 배제하고, 기능성과 실용성을 중시했습니다. 이는 현대 UX 디자인에서도 중요한 원칙입니다. UX 디자이너는 사용자가 쉽게 이해하고 사용할 수 있는 직관적인 인터페이스를 설계해야 합니다. 기능성과 실용성을 강조한 디자인은 사용자가 목표를 달성하는 데 도움이 됩니다.

협업과 통합

바우하우스는 다양한 배경을 가진 사람들이 협력하여 혁신적인 디자인을 만들어 내는 것을 강조했습니다. 이는 현대 UX 디자인에서도 중요한 요소입니다. UX 디자이너는 팀원들과의 긴밀한 협업을 통해 다양한 관점을 통합하고, 더 나은 디자인 결과를 도출해야 합니다. 협업은 창의성을 촉진하고, 더 포괄적인 디자인을 만들어낼 수 있습니다.

바우하우스 철학의 현대적 해석

바우하우스 철학은 현대 UX 디자인에 다양한 방식으로 적용될 수 있습니다. 바우하우스의 디자인 원칙과 방법론을 현대적인 방식으로 해석하고 적용하면, 더 혁신적이고 사용자 중심의 디자인을 만들어낼 수 있습니다.

디자인 원칙의 적용

바우하우스의 디자인 원칙을 현대 UX 디자인에 적용하면, 사용자 경험을 더욱 직관적이고 효율적으로 만들 수 있습니다. 예를 들어, 바우하우스의 단순하고 기능적인 디자인은 직관적인 인터페이스 설계에 중요한 영감을 줄 수 있습니다. 바우하우스의 디자인 원칙을 바탕으로, 사용자가 쉽게 이해하고 사용할 수 있는 인터페이스를 설계할 수 있습니다.

협업의 강화

바우하우스의 협업 정신을 바탕으로, 다양한 배경을 가진 디자이너들이 함께 일하며 서로의 아이디어를 공유하고 발전시키는 것이 중요합니다. 협업은 창의성을 촉진하고, 다양한 관점을 반영한 포괄적인 디자인을 만들어낼 수 있습니다. 바우하우스의 협업 정신을 현대 UX 디자인에 적용하면, 더 나은 디자인 결과를 도출할 수 있습니다.

실용성과 기능성의 중시

바우하우스는 불필요한 장식을 배제하고, 실용성과 기능성을 중시했습니다. 이는 현대 UX 디자인에서도 유효한 접근 방식으로, 사용자가 필요로 하는 기능에 집중하고 직관적인 인터페이스를 제공하는 데 도움이 됩니다. 바우하우스의 실용성과 기능성을 중시한 디자인 원칙을 현대 UX 디자인에 적용하면, 사용자 경험을 개선할 수 있습니다.

결론

바우하우스의 철학과 방법론은 현대 UX 디자인에 다양한 방식으로 적용될 수 있습니다. 바우하우스의 디자인 원칙과 협업 정신을 바탕으로, 사용자 중심의 혁신적인 디자인을 만들어낼 수 있습니다. UX 디자이너는 바우하우스의 철학을 현대적으로 해석하고 적용하여, 더 나은 사용자 경험을 제공할 수 있습니다.

이 글이 여러분의 디자인 작업에 도움이 되길 바랍니다. 바우하우스 철학을 바탕으로 더 창의적이고 혁신적인 UX 디자인을 만들어보세요.

바우하우스에 대해 더 자세히 알아보려면 Google Arts & Culture가 새로운 Bauhaus Dessau 재단과 협력하여 만든 대화형 온라인 박물관인 Bauhaus Everywhere 를 살펴보세요.

Bauhaus Everywhere - Google Arts & Culture

Traces of a design school in everyday life

artsandculture.google.com

피그마 Config 2024: 디자이너라면 놓칠 수 없는 피그마 업데이트 신규 기능들

디쟈이너 — Fri, 28 Jun 2024 16:50:31 +0900

Muzli에 개제된 Muzli Recap: Highlights from Figma Config 2024를 번역한 글입니다.
2024년 피그마 컨피그에서 발표된 주요 업데이트와 기능들을 살펴보겠습니다.

혁신과 기대감이 가득한 분위기

피그마는 디자인 세계에서 점점 더 중요한 역할을 하고 있습니다. 이번 피그마 컨피그 2024는 디자인 커뮤니티의 주요 이벤트 중 하나였습니다. 샌프란시스코의 모스코니 센터는 열정적인 디자이너들과 기술 애호가들로 가득 찼습니다. 피그마는 이번 행사에서 혁신적인 업데이트와 기능들을 발표하며 디자인 프로세스의 미래를 제시했습니다.

Figma AI: 더 크게 생각하고 더 빠르게 빌드하세요

이번 컨퍼런스의 주요 하이라이트 중 하나는 Figma AI였습니다. Figma AI는 지능형 디자인 제안을 워크플로우에 직접 제공하여 디자이너들이 더 빠르게 작업할 수 있도록 돕습니다. AI는 레이아웃 추천, 간격 및 정렬 자동 조정, 색상 팔레트 제안 등을 통해 디자인 과정을 가속화하고 창의성을 높입니다. 또한, 비주얼 검색 기능을 통해 기존 디자인 요소를 쉽게 찾고 활용할 수 있습니다.

AI 기반 텍스트 및 이미지 도구는 현실적인 이미지 생성 및 텍스트 재작성 기능을 제공하여 디자인 프로세스를 더욱 효율적으로 만듭니다. 퀵 클릭 프로토타이핑 기능을 사용하면 인터랙티브 프로토타입을 몇 초 만에 생성할 수 있습니다. 자동 레이어 이름 변경 기능은 파일을 정리하고 탐색하기 쉽게 만들어줍니다. 텍스트 프롬프트로 디자인 생성 기능은 자연어로 원하는 디자인을 설명하면 초기 레이아웃, 구성 요소 및 스타일을 자동으로 생성합니다.

비주얼 검색
Figma AI에는 구성 요소와 자산을 쉽게 찾을 수 있는 비주얼 검색 기능이 포함되어 있습니다. 이 기능을 통해 디자이너는 기존 디자인 요소를 신속하게 찾고 활용하여 작업 흐름을 간소화하고 효율성을 높일 수 있습니다.

AI 기반 텍스트 및 이미지 도구
이제 Figma AI에는 몇 번의 클릭만으로 사실적인 이미지를 생성하고 텍스트를 작성할 수 있는 도구가 포함되어 있습니다. 이러한 AI 기반 기능을 통해 디자이너는 고품질의 시각적 콘텐츠와 매력적인 카피를 쉽게 만들 수 있습니다. 이 도구는 디자인의 맥락을 분석하고 관련 이미지와 텍스트 개선 사항을 제안하여 디자인 프로세스의 속도와 창의성을 모두 향상시킵니다.

퀵 클릭 프로토타이핑
Quick-Click 프로토타이핑은 대화형 프로토타입 제작을 간소화합니다. 이 새로운 기능을 사용하면 디자이너는 정적인 디자인을 클릭 가능한 프로토타입으로 몇 초 만에 변환할 수 있습니다. 요소를 선택하고 상호 작용 유형을 선택함으로써 디자이너는 흐름을 빠르게 설정하고 광범위한 설정 없이 사용자 경험을 테스트할 수 있습니다.

자동 레이어 이름 변경
정리와 명확성을 향상시키기 위해 Figma에는 이제 자동 레이어 이름 바꾸기 기능이 포함되어 있습니다. 이 기능은 AI를 사용하여 디자인 내의 콘텐츠와 컨텍스트를 기반으로 레이어 이름을 바꿉니다. 수동으로 이름을 바꿀 필요가 없으므로 특히 복잡한 프로젝트에서 파일이 깔끔하며 탐색이 쉬워질것입니다.

텍스트 프롬프트에서 디자인 생성
도입된 획기적인 기능은 텍스트 프롬프트에서 디자인을 생성하는 기능입니다. Figma AI는 원하는 디자인을 자연어로 설명함으로써 초기 레이아웃, 구성 요소 및 스타일을 만들 수 있습니다. 이 기능을 통해 디자이너는 처음부터 시작하지 않고도 아이디어를 빠르게 반복하고 새로운 개념을 탐구할 수 있습니다.

UI3: 피그마, 새롭게 디자인되다

새롭게 디자인된 인터페이스 UI3는 탐색을 더 직관적으로 만들고 워크플로우를 간소화합니다. UI3는 전 세계 검색 및 알림 기능이 포함된 파일 브라우저를 제공하여 사용자가 필요한 정보를 더 빠르게 찾고 프로젝트 변경 사항을 실시간으로 확인할 수 있습니다. 이 새로운 인터페이스는 컴포넌트에 중점을 두어 디자인 요소에 쉽게 접근하고 관리할 수 있게 합니다.

Figma 슬라이드: 빌드, 협업 및 프레젠테이션

Figma Slides는 프레젠테이션 제작 방식을 혁신적으로 변화시킵니다. Figma Slides는 Figma의 협업 기능을 슬라이드 제작에 도입하여 팀이 실시간으로 협업하고 라이브 디자인을 통합할 수 있도록 합니다. 또한, 확대된 그리드 뷰를 통해 슬라이드 레이아웃을 쉽게 관리할 수 있습니다.

‍ ‍ Dev Mode 업데이트: 디자인 완료에서 개발 완료까지

이번 컨퍼런스에서는 디자이너와 개발자 간의 간극을 줄이기 위한 Dev Mode 업데이트도 소개되었습니다. Ready for Dev View는 여러 디자인 탐색 중 개발자들이 필요한 것을 쉽게 찾을 수 있도록 도와주며, Focus View는 개발자가 실제로 빌드할 준비가 된 것만 볼 수 있게 합니다. 또한, Code Connect 기능은 디자인 시스템 코드를 다양한 프레임워크와 프로그래밍 언어에서 더욱 유용하게 만들어줍니다. 이러한 업데이트는 디자인과 코드가 더 긴밀하게 연결되어 핸드오프 프로세스를 더욱 원활하고 효율적으로 만들어줍니다.

️ 향상된 프로토타이핑 기능

피그마는 프로토타이핑 기능을 한층 더 강화했습니다. 마이크로 인터랙션 및 고급 애니메이션 효과를 통해 더 인터랙티브하고 현실적인 프로토타입을 생성할 수 있습니다. 향상된 장치 미리보기 옵션을 통해 다양한 장치와 화면 크기에서 프로토타입을 테스트할 수 있습니다. 조건부 로직 지원으로 복잡한 사용자 흐름을 정확하게 시뮬레이션할 수 있습니다.

이번 피그마 컨피그 2024는 디자인 프로세스를 근본적으로 변화시킬 혁신을 선보였으며, 피그마를 더욱 강력한 경쟁자로 만들었습니다. 새로운 AI 기능, UI3 인터페이스, Figma Slides, Dev Mode 업데이트 및 향상된 프로토타이핑 기능은 디자이너들이 더 창의적이고 효율적으로 작업할 수 있게 해줍니다. 그러나 이러한 혁신들이 실제로 제공될 수 있을지, 그리고 AI가 디자인의 재미와 창의성을 빼앗아 가지는 않을지에 대한 의문도 제기되고 있습니다. 앞으로의 발전과 도전 과제를 지켜보며, 디자이너들은 이러한 새로운 도구들을 최대한 활용하여 더 나은 디자인을 만들어 나가길 기대합니다.

Config 2024 전체는 아래 영상에서 보실 수 있습니다.

일론 머스크가 아이들에게 가르쳐야한다고 주장한 50가지 인지 편향

디쟈이너 — Thu, 27 Jun 2024 08:32:23 +0900

일론 머스크는 공학 및 혁신 분야에서 탁월한 성과를 이루며, 그 성공의 비결로 '기본 원칙 사고(first principles thinking)'를 강조합니다. 그는 최근 트위터를 통해 인지 편향을 어릴 때부터 가르쳐야 한다고 주장하며, 50가지 주요 인지 편향을 소개했습니다. 이 편향들은 우리가 일상생활과 업무에서 더 명확하고 논리적인 사고를 할 수 있도록 도와줍니다.

50가지 인지 편향 목록

⭐️ 기본 귀인 오류 (Fundamental Attribution Error): 타인의 행동은 성격 때문이고, 자신의 행동은 상황 때문이라고 생각하는 경향.
⭐️ 자기 중심 편향 (Self-Serving Bias): 성공은 자신의 능력 덕분이고 실패는 외부 요인 때문이라고 믿는 경향.
내집단 편애 (In-Group Favoritism): 자신이 속한 그룹을 더 호의적으로 보는 경향.
⭐️ 밴드왜건 효과 (Bandwagon Effect): 유행을 따라가는 경향.
집단사고 (Groupthink): 갈등을 피하기 위해 그룹의 의견에 따르는 경향.
후광 효과 (Halo Effect): 한 가지 긍정적인 특성이 다른 모든 특성도 긍정적일 것이라고 생각하는 경향.
도덕적 운 (Moral Luck): 성공한 사람을 도덕적으로 우월하다고 여기는 경향.
거짓 합의 효과 (False Consensus): 대부분의 사람들이 자신과 같은 의견을 가지고 있다고 믿는 경향.
⭐️ 지식의 저주 (Curse of Knowledge): 자신이 아는 것을 다른 사람들도 알 것이라고 가정하는 경향.
스포트라이트 효과 (Spotlight Effect): 다른 사람들이 자신을 더 많이 주목하고 있다고 생각하는 경향.
⭐️ 가용성 휴리스틱 (Availability Heuristic): 기억에 쉽게 떠오르는 예시를 바탕으로 판단하는 경향.
방어적 귀인 (Defensive Attribution): 자신이 피해자가 될 수 있는 범죄에 더 분노하는 경향.
정의로운 세계 가설 (Just-World Hypothesis): 세상은 공정하다고 믿고, 관찰된 부정의를 정당화하는 경향.
순진한 현실주의 (Naive Realism): 자신이 현실을 더 잘 이해한다고 믿는 경향.
순진한 냉소주의 (Naive Cynicism): 다른 사람들이 모두 자기 이익만을 추구한다고 생각하는 경향.
포러 효과 (Forer Effect): 모호한 진술이 자신에게만 적용된다고 생각하는 경향.
⭐️ 던닝-크루거 효과 (Dunning-Kruger Effect): 능력이 부족할수록 자신감이 높고, 능력이 높을수록 의심이 많아지는 경향.
⭐️ 앵커링 (Anchoring): 처음 들은 정보가 이후 논의의 기준이 되는 경향.
자동화 편향 (Automation Bias): 자동 시스템에 과도하게 의존하는 경향.
구글 효과 (Google Effect): 쉽게 검색할 수 있는 정보를 잊어버리는 경향.
반작용 (Reactance): 강요당한다고 느낄 때 반대로 행동하는 경향.
⭐️ 확증 편향 (Confirmation Bias): 기존 믿음을 확인시키는 정보를 더 선호하는 경향.
역효과 (Backfire Effect): 거짓 믿음을 반복적으로 언급할 때 오히려 더 믿게 되는 경향.
제3자 효과 (Third-Person Effect): 다른 사람들이 더 영향을 받는다고 믿는 경향.
신념 편향 (Belief Bias): 논증의 자체적 타당성보다는 결론의 그럴듯함으로 판단하는 경향.
가용성 폭포 (Availability Cascade): 더 많은 사람들이 믿고 이야기할수록 그것이 더 진실이라고 믿게 되는 경향.
퇴행주의 (Declinism): 과거를 낭만화하고 현재를 쇠퇴기로 보는 경향.
현상 유지 편향 (Status Quo Bias): 변화가 유익함에도 불구하고 현재 상태를 선호하는 경향.
⭐️ 매몰 비용 오류 (Sunk Cost Fallacy): 손실을 인정하지 않기 위해 추가 자원을 투입하는 경향.
도박사의 오류 (Gambler's Fallacy): 과거 사건이 미래 확률에 영향을 미친다고 생각하는 경향.
제로 리스크 편향 (Zero-Risk Bias): 더 큰 위험 감소 대신 작은 위험을 완전히 제거하려는 경향.
⭐️ 프레이밍 효과 (Framing Effect): 정보의 제시 방식에 따라 다른 결론을 도출하는 경향.
고정관념 (Stereotyping): 전체 그룹에 대한 일반적인 믿음을 개인에게 적용하는 경향.
외집단 동질성 편향 (Outgroup Homogeneity Bias): 자신이 속한 그룹의 다양성은 인정하면서 외집단은 모두 같다고 보는 경향.
권위 편향 (Authority Bias): 권위자에 지나치게 의존하는 경향.
플라시보 효과 (Placebo Effect): 실제로 효과가 없더라도 긍정적인 효과를 경험하는 경향.
생존자 편향 (Survivorship Bias): 승자만 기억하고 많은 실패자를 잊어버리는 경향.
타키사이키아 (Tachypsychia): 피로, 약물, 트라우마가 시간 감각을 왜곡시키는 현상.
사소한 것의 법칙 (Law of Triviality): 중요한 문제를 무시하고 사소한 문제에 과도하게 집중하는 경향.
자이가르닉 효과 (Zeigarnik Effect): 미완성 작업이 완료될 때까지 뇌를 괴롭히는 경향.
이케아 효과 (Ikea Effect): 자신이 만든 것을 과대평가하는 경향.
벤자민 프랭클린 효과 (Ben Franklin Effect): 자신이 호의를 베푼 사람을 더 긍정적으로 생각하는 경향.
방관자 효과 (Bystander Effect): 군중 속에서 책임감을 덜 느끼는 경향.
암시성 (Suggestibility): 다른 사람이 말한 생각이나 질문을 자신의 기억으로 착각하는 경향.
거짓 기억 (False Memory): 상상한 것을 기억으로 착각하는 경향.
크립토메시아 (Cryptomnesia): 진짜 기억을 상상한 것으로 착각하는 경향.
군집 환상 (Clustering Illusion): 무작위 데이터에서 패턴을 "보는" 경향.
비관 편향 (Pessimism Bias): 항상 유리잔을 반쯤 빈 것으로 보는 경향.
낙관 편향 (Optimism Bias): 항상 유리잔을 반쯤 찬 것으로 보는 경향.
⭐️ 맹점 편향 (Blind Spot Bias): 자신에게는 편향이 덜 있다고 믿는 경향.

이러한 인지 편향을 이해하고 인식하는 것은 UI/UX 디자이너들이 더 나은 디지털 제품을 설계하는 데 중요한 역할을 합니다. 인지 편향을 인식함으로써 디자이너는 사용자 경험을 개선하고, 사용자의 행동과 반응을 더 정확하게 예측할 수 있습니다. 예를 들어, 가용성 휴리스틱을 고려하여 정보의 배치나 강조점을 조정하면 사용자가 원하는 정보를 더 쉽게 찾을 수 있게 됩니다. 또한, 앵커링 효과를 활용해 중요한 결정을 유도하거나, 프레이밍 효과를 사용해 사용자의 선택을 긍정적인 방향으로 이끌 수 있습니다. 결과적으로, 인지 편향을 이해하고 디자인에 적용하는 능력은 사용자 중심의 직관적이고 효과적인 디자인을 구현하는 데 필수적입니다.

출처: Elon Musk Thinks Every Child Should Learn About These 50 Cognitive Biases

UI/UX 개선을 위해 점검할 7가지 마법 체크리스트

디쟈이너 — Wed, 26 Jun 2024 08:45:25 +0900

문제를 식별하고 웹/앱을 최적화하는 손쉬운 방법

디지털 제품이 사용자 기대에 미치지 못하면, 사용자는 대안을 빠르게 찾기 시작합니다. 웹사이트가 멋지고 다양한 기능을 갖추고 있어도, 정작 사용자들이 원하는 기능이 어디에 있는지 찾지 못하면 무용지물입니다. 높은 전환율을 기대했지만 결과가 좋지 않은 이유는 무엇일까요?

테스트를 시작하기 전에, "7가지 마법"을 통해 웹 또는 앱을 점검해 보세요. 이 효율적인 방법은 숨겨진 문제를 드러내어 마법처럼 작동합니다.

그렇다면 "7가지 마법"이란 무엇일까요? 나른한 저녁 식사 시간에 손님들이 접시에 음식을 담고 있는 장면을 상상해보세요. 무엇이 문제일까요? 음식이 맛이 없어서? 서비스가 좋지 않아서? 손님들이 배가 고프지 않아서? 아니면 분위기가 너무 여유로워서?

디지털 제품에서도 이와 같이 7가지 마법을 적용하여 부족한 문제점을 즉시 발견할 수 있습니다.

1: 더 많은 관심

사용자의 관심을 끄는 데 중점을 둡니다. 제품이 올바른 방향으로 가고 있나요? 사용자가 CTA에 도달하기 전에 이탈하나요?

사용자 관심 문제:

너무 많은 광고를 접함
중요하지 않은 디자인 요소에 주의를 빼앗김
갑작스러운 팝업
긴 텍스트나 포맷된 콘텐츠에 지침
화려한 콘텐츠에 정신을 빼앗김
시각적 가이드를 찾지 못함 (너무 단조로운 디자인)

이 중 하나의 문제만 해결해도 웹의 사용자 경험이 크게 향상되어 사용자가 목표를 더 쉽게 달성할 수 있습니다. 히트맵이나 설문조사를 통해 사용자 관심 문제를 파악하고 해결하세요.

2: 더 많은 가치

제품이 당신뿐만 아니라 다른 사용자에게도 가치 있고 꼭 필요한 것처럼 보이게 하세요. 그리고 회사에 대한 신뢰가 제품에 적용되어 더 많은 가치를 부여하도록 하세요.

가치 창출 요소:

제안이 인상적이고, 미적이며 매력적으로 제시됨
사용자가 제품의 장점을 즉시 인식할 수 있음
사용자가 제품 사용 방법을 쉽게 파악할 수 있음 (예: 명확한 가이드 제공)
소셜미디어 리뷰, 사진, 동영상, 인증서 등을 통해 자신감을 높임
배송비용이나 기타 비용이 명확하고 간단하게 표시됨

가치 창출은 일회성 작업이 아닌 지속적인 과정입니다. 시장은 끊임없이 변화하고 사용자 요구도 변합니다. 회사와 제품이 최신 상태에 있고, 관련된 제안을 제공하며, 최신 UI/UX 트렌드를 반영하고 있는지 확인하세요.

3: 더 많은 동기 부여

사용자가 필요한 작업을 수행하는 데 동기 부여가 부족하면 이탈하게 됩니다. 단순히 매력적인 트리거만으로는 충분하지 않습니다. 진정한 동기 부여는 호기심, 필요, 욕망을 자극해야 합니다.

동기 부여 전략:

사업적 동기 부여
학습 동기 부여
자기계발 동기 부여
레크리에이션 및 게임 동기 부여
유효성 확인 동기 부여
커뮤니케이션 동기 부여

동기 부여는 선물, 포인트, 사회적 인센티브 등을 통해 강화될 수 있습니다.

UI/UX에서 동기 부여 부족의 예:

트리거가 강조되지 않음 (추상적 설계)
트리거가 감정적으로 관여하지 않음
추가 트리거가 부족하거나 없음
트리거가 너무 많음 (과도한 침입 문제)
시각적, 정서적으로 동기 부여가 강화되지 않음
자극적인 요소가 부족함
인센티브가 부족하거나 사용자 관심이 없음

4: 더 많은 참여

활동

많은 웹과 앱이 수동적인 소비에 맞춰져 있어 낮은 전환율을 초래할 수 있습니다. 디자이너와 개발자들은 사용자 활동을 높이기 위해 더 많은 작업을 수행해야 합니다. 참여는 단순한 상호작용을 넘어서 감정, 미세한 상호작용, 게임화 등을 포함합니다.

접촉점

참여는 사용자와의 접점을 유지하는 것입니다. 접점은 의도적으로 생성되어야 하며, 모든 곳에서 사용자의 감정과 반응을 예측하고 전달해야 합니다. 프로젝트 목표와 사용자 기대치에 부합해야 합니다.
더 많은 참여가 반드시 더 많은 접점을 의미하지는 않습니다. 너무 많으면 사용자는 지치고 짜증이 날 수 있습니다. 너무 적으면 사용자는 지루해져 떠날 것입니다. 따라서 참여의 깊이가 중요하며, 감성적인 비주얼, 사용자 참여, 즐거운 상호작용, 반응적인 인터페이스를 위해 노력해야 합니다.

통제와 투자

더 많은 참여로 인해 통제력(사용자가 원하는 작업을 수행할 수 있는 활동 영역)과 투자(사용자가 사진, 비디오, 피드백 등을 제공하는 것)가 강화됩니다.
사용자의 시간은 소중하므로 모든 정보를 빠르고 효율적으로 제공해야 합니다.
사용자가 버림받았다고 느끼지 않도록 인터페이스 내에서 상호작용이 일어나야 하며, 각 단계마다 사용자를 관리해야 합니다. 예를 들어, 기다리는 시간을 재미있는 애니메이션으로 채우거나 404 페이지를 화려하게 디자인하는 것이 좋은 예입니다.

5: 더 많은 유용성

당신이 만든 제품이 유용하고 잘 제공되었다면, 사용자가 여러 번의 기회를 이용했을까요? 웹이나 앱은 핵심 콘텐츠 외에도 유용한 기능을 제공할 때 경쟁에서 우위를 점할 수 있습니다. 예를 들어, 무료 동영상 강의, 상담, 짧은 게임, 유용한 정보 등이 될 수 있습니다. 때로는 작은 기능 하나가 사용자가 당신의 제품을 선택하게 만드는 결정적인 요소가 됩니다.

디자인의 모든 요소가 중요합니다.

6: 더 신선한 가치

디지털 제품은 쉽게 질릴 수 있습니다. 새로움이 없는 제품은 구식 디자인 때문만은 아닙니다. 사용자 참여를 유지하는 가장 좋은 방법은 신선함을 유지하는 것입니다. 최신 콘텐츠와 트렌디한 디자인을 정기적으로 업데이트하세요. 콘텐츠 마케팅 연구소에 따르면, 유용하고 관련된 콘텐츠를 정기적으로 생성하면 검색 엔진 광고 및 배너보다 3배 더 많은 잠재 고객을 창출할 수 있습니다. 새로운 정보나 휴일 테마의 디자인을 웹이나 앱에 포함시켜 보세요. 정기적으로 변화를 주어 사용자가 이전에 봤던 오래된 콘텐츠와 같다고 느끼지 않도록 하세요.

✨ 7: 더 쉽게

웹이나 앱이 너무 복잡하면 사용자는 더 빠르고 쉬운 해결책을 찾습니다.

사용 편의성에 영향을 미치는 주요 요인:

시간
돈
인지 방향
물리적 방향
행동 패턴

제품을 사용하기 어렵게 만드는 요소를 파악하고 해결하려면 잠재적으로 부족하거나 잘못된 부분을 테스트해야 합니다. 예를 들어, 긴 로딩 시간, 시각적 또는 정보적 혼란, 과도하게 복잡한 양식, 사용자가 쉽게 지치는 경로 등이 있습니다. 모든 기회를 최대한 간편하게 만들어 사용성을 높이세요.

결론

디지털 세계에서 성공하려면 사용자 경험을 최적화하는 것이 필수적입니다. 사용자에게 더 많은 관심과 편안함, 유용성을 제공해야 합니다. 이를 위해서는 디테일에 대한 깊은 이해와 꾸준한 개선이 필요합니다. 각 사용자는 고유한 요구와 기대를 가지고 있으며, 이를 만족시키기 위해서는 지속적인 분석과 조정이 필요합니다.

최적화된 UX/UI는 단순히 아름다운 디자인을 넘어섭니다. 이는 사용자와의 심리적 연결을 통해 신뢰를 구축하고, 사용자가 자신의 목표를 쉽게 달성할 수 있도록 돕는 것입니다. 사용자가 불편함을 느끼지 않고 자연스럽게 제품을 탐색할 수 있도록 하세요. 사용자가 웹이나 앱에서 긍정적인 경험을 할수록, 그들은 더 자주 돌아오고 더 오래 머물 것입니다.

또한, 기술의 발전과 함께 UX/UI 디자인도 끊임없이 변화해야 합니다. 새로운 트렌드와 기술을 도입하여 사용자가 항상 신선하고 흥미로운 경험을 할 수 있도록 하세요. 이를 통해 사용자와의 지속적인 관계를 유지하고, 제품의 가치를 지속적으로 높일 수 있습니다.

프로덕트 디자이너가 알아야 할 효과적인 거절 방법

디쟈이너 — Tue, 25 Jun 2024 07:27:49 +0900

"No"라고 말하는 중요성

효과적으로 "No"라고 말하는 능력은 성공적인 프로덕트 디자이너가 되기 위해 필수적인 기술 중 하나입니다. 아이디어를 제안하는 사람은 회사의 중요한 이해관계자, 투자자, 또는 C레벨의 임원일 수 있습니다. 그들의 제안을 어떻게 하면 잘 거절하고, 디자인의 방향을 올바르게 유지할 수 있을까요?

회의 순간마다 절체절명의 피드백을 받는 프로덕트 디자이너를 위한 "No" 가이드 / 사진: Unsplash 의 Cherrydeck

"No"라고 말하는 데 대한 일반적인 오해

효과적인 기술을 논하기 전에, 잘못된 이유로 "No"라고 말하는 일반적인 오해를 짚고 넘어가겠습니다:

게으름: 단지 너무 많은 노력이 필요하기 때문에 아이디어를 거절함.
업무 과부하: 이미 업무가 많아서 제안을 거절함.
검증 부족: 적절한 평가 없이 아이디어를 기각함.
빡빡한 일정: 시간 압박과 일정 때문에 거절함.
습관적 부정: 잠재적인 가치를 고려하지 않고 습관적으로 "No"라고 말함.

올바르게 "No"라고 말하는 방법

검증 후 거절하세요
```
 ‍♂️  "이 아이디어는 정말 흥미롭고 작업을 시작하고 싶습니다. 그러나 우리의 데이터와 사용자 피드백을 살펴본 결과, 현재로서는 이 아이디어가 성공할 가능성이 낮아 보입니다."
```
정량적, 정성적 데이터를 통해 결정에 근거를 마련하세요. 성과 지표와 다양한 유입 경로를 확인하고, 사용자 인터뷰와 프로토타입을 통해 가설을 테스트하세요. 아이디어가 비효율적인 것으로 판명되면, 발견한 내용을 감정적으로 상처받지 않도록 공유하세요.
우선순위에 따라 거절하세요
```
 ‍♀️  "이 아이디어는 매우 흥미롭습니다만, 현재 비즈니스 목표와 맞지 않습니다. 따라서 지금은 다른 중요한 작업에 집중하는 것이 더 좋을 것 같습니다."
```
자원은 한정적이므로 모든 아이디어를 철저히 검증할 수는 없습니다. 디자인 작업의 우선순위를 정하고, 이 기능이 가져올 수 있는 비즈니스 가치를 계산하여 최종 결정을 내리세요. 이를 통해 "있으면 좋은" 아이디어와 "비즈니스적으로 필수적인" 아이디어를 구분할 수 있습니다.

대안을 제시하며 거절하세요

 ‍♂️  "검증을 통해 이 아이디어가 사용자 문제를 해결할 수 있다는 것을 알게 되었습니다. 하지만 사용자들이 이해하기 어려운 부분이 있어 개선이 필요합니다. 대신 이 문제를 해결할 수 있는 다른 접근법을 제안드립니다."

검증 과정에서 사용자가 직면한 문제를 확인할 수 있습니다. 아이디어가 문제를 해결하지만 해결책이 적절하지 않은 경우, 다른 대안을 찾아 제시하세요.

"Yes"라고 말하면서 거절하세요
```
 ‍♀️  "좋은 아이디어를 제안해주셔서 감사합니다. 이 아이디어로 제품이 개선될 수 있다는 점에 동의합니다. 이것을 검증할 수 있는 방법을 찾아본 후에 나중에 다시 논의하는 것이 좋겠습니다."
```
여러 방법에도 불구하고 이해관계자에게 직접 "No"라고 말하기 어려울 때, 제안에 대해 감사하며 더 나은 장소에서 논의할 수 있도록 회의 안건에서 제외하고 후속 조치를 취하세요.

프로덕트 디자이너의 역할

프로덕트 디자이너로서의 목표는 단순히 모든 제안에 동의하는 것이 아니라 제품을 향상시키는 것입니다. CEO의 아이디어라도, 제품을 더 좋게 만들지 않는다면 "Yes"라고 말하지 마세요. 판단력과 전문 지식을 사용하여 프로젝트에 이익이 되는 결정을 내려야 합니다.

효과적인 "No" 말하기 기술

이러한 전략을 효과적으로 구현하기 위해 다음 기술을 고려하세요:

1. 공감과 이해

아이디어를 거절할 때, 공감을 표시하세요. 제안자의 관점을 이해하고 그들의 노력을 인정하세요. 이는 부정적인 영향을 줄이고 대화를 긍정적으로 유지하는 데 도움이 됩니다.

    ‍♂️  "당신의 생각을 이해합니다. 이 아이디어는 매우 창의적이며 좋은 방향을 제시하고 있습니다. 하지만 현재의 우선순위를 고려할 때, 지금 당장 구현하기는 어려울 것 같습니다."

2. 투명성과 정직성

"No"라고 말하는 이유를 솔직하게 설명하세요. 아이디어가 프로젝트의 목표와 맞지 않거나 현재 실행 가능하지 않다면, 그 이유를 명확히 설명하세요.

    ‍♀️  "이 아이디어는 정말 좋습니다. 하지만 현재 우리의 리소스가 부족하여 이 아이디어를 실행하는 것은 어려울 것 같습니다. 나중에 다시 검토해보겠습니다."

3. 데이터 기반 결정

항상 "No"라는 결정을 데이터로 뒷받침하세요. 사용자 피드백, 시장 분석, 내부 지표 등 데이터를 바탕으로 객관적인 근거를 제시하세요.

    ‍♂️  "우리의 사용자 데이터는 이 기능이 현재 큰 가치를 제공하지 않는다고 보여줍니다. 더 큰 영향을 미칠 수 있는 부분에 집중하는 것이 좋겠습니다."

4. 미래를 위한 고려

현재는 적절하지 않지만 나중에 유용할 수 있는 아이디어는 백로그에 추가하고, 상황이 변할 때 다시 검토하세요.

    ‍♀️  "이 아이디어는 미래에 매우 유용할 수 있습니다. 상황이 변하면 다시 우선순위를 정해보겠습니다."

5. 건설적인 피드백 제공

아이디어가 왜 실행 불가능한지, 그리고 더 실행 가능하게 만들기 위해 필요한 사항에 대한 건설적인 피드백을 제공하세요. 이는 제안자에게 도움이 되고 지속적인 개선 문화를 장려합니다.

    ‍♂️  "이 아이디어는 매우 유망합니다. 몇 가지 도전 과제를 해결하면 더 실행 가능할 것입니다. 개선 사항을 함께 논의해보면 좋겠습니다."

6. 관계 유지

아이디어를 거절하는 것은 관계에 부담을 줄 수 있습니다. 외교적으로 처리하여 긍정적인 업무 관계를 유지하세요. 제안자의 입력을 인정하고 지속적인 아이디어 기여를 장려하세요.

    ‍♀️  "제안해주셔서 감사합니다. 제품을 향상시키기 위한 지속적인 아이디어 제공을 환영합니다. 앞으로도 좋은 아이디어를 기대하겠습니다."

결론

효과적으로 "No"라고 말하는 것은 공감, 투명성, 전략적 접근을 요구하는 균형 잡힌 작업입니다. 프로덕트 디자이너로서의 주요 책임은 프로젝트의 성공을 보장하는 것입니다. 이는 때때로 어려운 결정을 내리고 현재로서는 실행 불가능한 아이디어를 거절하는 것을 의미합니다. 데이터 기반 의사결정, 효과적인 우선순위 설정, 개방적 소통을 통해, 존중과 건설적인 방식으로 "No"라고 말할 수 있습니다. 목표는 더 나은 제품을 만드는 것이며, 때로는 "No"라고 말할 때도 있습니다.

[Figma] Shift + 방향키로 이동 간격 8px로 바꾸는 방법

디쟈이너 — Mon, 24 Jun 2024 07:54:38 +0900

Figma는 UI/UX 디자이너들이 효율적으로 작업할 수 있도록 다양한 기능을 제공합니다. 그 중에서도 도형이나 레이어를 미세하게 조절할 수 있는 Nudge Amount 설정은 작업의 정확성을 높여줍니다. 이번 글에서는 Nudge Amount를 설정하고 활용하는 방법에 대해 소개하겠습니다.

Nudge Amount란 무엇인가요?

Nudge Amount는 Figma에서 화살표 키를 사용해 도형이나 레이어의 위치를 이동할 때, 한 번에 얼마나 이동할지를 설정하는 기능이에요. 기본 설정은 작은 이동(Small Nudge)은 1픽셀, 큰 이동(Big Nudge)은 10픽셀이에요. 이 값을 조절하면 작업이 훨씬 더 수월해진답니다.

Nudge Amount 설정하기

Nudge Amount를 설정하는 방법은 다음과 같습니다:

Figma Shift로 이동 간격 조정

Figma 메뉴에서 Preferences 선택
- Figma 창 상단의 메뉴 바에서 'Preferences'를 클릭합니다.
Nudge Amount 설정 변경
- 'Preferences' 메뉴에서 'Nudge Amount' 옵션을 선택합니다.
- Small Nudge와 Big Nudge 값을 원하는 값으로 설정합니다. 예를 들어, Big Nudge를 8로 설정하면 특정 배수로 도형을 이동하거나 크기를 조절할 때 매우 유용합니다.

8배수 그리드 디자인의 중요성

웹이나 앱을 디자인할 때, 8의 배수로 그리드를 설정하는 경우가 많아요. 이 방법은 Material Design 가이드에서 권장하는 방식으로, 몇 가지 큰 장점이 있어요:

디자인 일관성 유지
- 모든 요소를 8의 배수로 맞추면 디자인의 일관성을 쉽게 유지할 수 있습니다. 이는 사용자가 일관된 경험을 할 수 있도록 도와줍니다.
개발자와의 협업 효율성 향상
- 개발자는 리소스나 크기 단위를 8의 배수로 통일하면 디자이너와의 작업에서 오차를 줄이고, 작업이 수월해집니다. 이는 전체 프로젝트의 생산성을 높이는 데 큰 도움이 됩니다.

8 point grid system

8배수 그리드 디자인과 Nudge Amount의 효율성

Figma에서 Nudge Amount를 설정하면 8배수 그리드 디자인을 더욱 효율적으로 구현할 수 있습니다. 다음은 그 활용 방법입니다:

도형 이동
- 도형을 선택한 후 화살표 키를 누르면 Small Nudge 값만큼 이동합니다.
- Shift 키를 누르면서 화살표 키를 누르면 Big Nudge 값만큼 이동합니다.
도형 크기 조절
- Cmd(또는 Ctrl) 키를 누르면서 화살표 키를 누르면 도형의 크기를 Small Nudge 값만큼 조절할 수 있습니다.
- Shift 키를 함께 누르면 Big Nudge 값만큼 크기가 조절됩니다.

이처럼 Nudge Amount를 적절히 설정하고 활용하면, 픽셀 단위로 정밀한 작업이 요구되는 프로덕트 디자인에서 시간과 노력을 절약할 수 있습니다. 특히 8의 배수로 움직이는 기능은 그리드 시스템을 사용하는 디자인에서 큰 도움이 됩니다.

Figma의 Nudge Amount 설정은 UI/UX 디자이너가 작업을 더 효율적으로 수행할 수 있도록 돕는 강력한 기능이에요. 자신의 작업 스타일과 필요에 맞게 Nudge Amount를 설정하고 활용해 보세요. 이를 통해 작업의 정밀도와 효율성을 크게 향상시킬 수 있을 거예요.

웹사이트 메뉴 디자인 체크리스트 : 17가지 UX 가이드라인으로 사용자 경험 향상하기

디쟈이너 — Fri, 21 Jun 2024 08:55:10 +0900

이 글은 닐슨 노먼 그룹(Nielsen Norman Group)의 아티클을 읽고 번역한 글입니다.

원문은 이곳에서 확인 가능합니다.

사용자는 콘텐츠를 찾고 기능을 사용하기 위해 메뉴에 의존합니다. 이 체크리스트를 사용하여 메뉴가 제대로 작동하는지 확인하세요. 너무 자주, 우리는 혼란스럽거나 조작하기 어려운 메뉴로 인해 사용자가 어려움을 겪는 것을 목격합니다. 이 가이드라인을 따르면 사용자가 메뉴를 통해 쉽게 콘텐츠를 찾고 기능을 활용할 수 있게 됩니다.

탐색 메뉴 가시성 확보

1. 큰 화면에서는 탐색 메뉴 표시

❌ 메트로폴리탄 오페라의 데스크탑 사이트: 충분한 공간이 있음에도 불구하고, 탐색 메뉴가 잘 보이지 않는 햄버거 메뉴로 숨겨져 있으며, 이는 상단의 흰색 막대에 배치되어 있습니다. 많은 사용자들이 이 메뉴를 무시할 가능성이 큽니다.

데스크탑 웹사이트와 앱에서는 햄버거 메뉴를 사용하지 않는 것이 좋습니다. 화면에 메뉴를 숨기지 말고, 충분한 공간이 있을 때는 메뉴를 명확히 표시하세요. 탐색은 단순히 경로를 안내하는 역할뿐만 아니라, 사용자가 당신의 자원이나 콘텐츠의 범위를 이해하는 데 도움을 줍니다. 탐색이 숨겨져 있으면, 사용자는 스스로가 누구이고 무엇을 하는지에 대한 중요한 맥락 단서를 놓치게 됩니다.

2. 예상 위치에 메뉴 배치

사용자는 특정 메뉴를 화면의 특정 영역에서 찾을 것으로 기대합니다. 이러한 기대를 활용하여 메뉴를 적절한 위치에 배치하세요.

메인 네비게이션 메뉴: 웹사이트의 경우 헤더에, 애플리케이션의 경우 화면의 왼쪽에 위치합니다.
유틸리티(또는 보조) 탐색: 주 탐색 메뉴와 검색 상자 위쪽, 화면 상단에 위치합니다.
로컬 네비게이션: 데스크탑 웹사이트의 경우 화면 왼쪽에 배치합니다.
푸터 메뉴: 화면 하단에 위치합니다.

3. 배경과 대비되는 링크 텍스트 색상 사용

메뉴 링크가 배경과 명확히 구분되도록 대비를 충분히 확보하세요. 많은 디자이너들이 대비 가이드라인을 무시하는 경우가 많습니다. 디지털 공간에서 탐색은 이미 혼란스럽기 때문에, 화면을 읽기 위해 눈을 가늘게 뜨지 않도록 해야 합니다.

❌ Gus Modern의 네비게이션은 회전하는 배경 캐러셀 위에 있어 거의 보이지 않습니다.

4. 큰 화면에서는 메뉴가 화면을 가리지 않게

큰 화면에서는 메가 메뉴나 하위 메뉴가 열릴 때 전체 화면을 가리지 않도록 하세요. 메뉴의 가시성과 가독성은 중요하지만, 열린 메뉴가 전체 화면을 차지해서는 안 됩니다. 열려 있는 메뉴는 동적이고 일시적인 UI 요소로, 별도의 페이지가 아닌 콘텐츠 위에 자리 잡아야 합니다. 사용자가 일시적으로 혼란을 느끼고 새로운 페이지로 잘못 이동했다고 착각할 수 있습니다. 모바일 장치에서는 이러한 가이드라인을 어길 수밖에 없다는 점을 유념하세요.

❌ Ideo의 햄버거 메뉴는 열렸을 때 화면 전체를 덮어 일시적인 혼란을 초래하고 기본 페이지를 가립니다. 이는 사용자가 사이트 내에서 현재 위치를 파악하고 다른 부분과의 관계를 이해하는 네비게이션의 주요 목적 중 하나에 반하는 디자인입니다.

현재 위치 표시

5. 메뉴에서 사용자의 현재 위치 표시

"내가 어디에 있지?"는 사용자가 성공적으로 탐색하기 위해 답해야 하는 기본적인 질문 중 하나입니다. 사용자는 메뉴(및 브레드크럼과 같은 다른 탐색 요소)로부터 시각적 단서를 받아 이 중요한 질문에 답을 얻습니다. 탐색 메뉴의 주요 역할 중 하나는 사용자를 안내하는 것입니다. 사용자가 홈 페이지에서 직접 들어오지 않는 경우가 많기 때문에, 현재 위치를 표시하지 않는 것은 웹사이트 메뉴에서 가장 흔한 실수 중 하나입니다.

❌ Anthropic는 사이트의 정보 구조에서 사용자가 어디에 있는지 명확히 구분하지 않습니다. 홈 페이지가 아닌 다른 페이지로 직접 도착한 사용자는 방향을 잡는 데 어려움을 겪을 수 있습니다.

✅ Whirlpool: 브레드크럼은 현재 위치를 표시하여 방문자를 안내합니다. 이는 특히 사용자가 찾고자 하는 페이지와 유사하지만 정확히 일치하지 않는 페이지에 도착했을 때 유용합니다. 사용자는 네비게이션 계층에서 한 단계 위로 쉽게 이동하여 다른 옵션을 시도할 수 있습니다.

6. 관련 콘텐츠에 대한 로컬 탐색 메뉴 제공

사람들이 자주 관련 제품을 비교하거나 단일 섹션 내에서 여러 작업을 완료하려고 할 때, 인근 페이지를 로컬 탐색 메뉴로 표시하여 사용자가 위아래로 '포고 스틱'하지 않도록 하세요. 예를 들어, 뉴욕시 도시 계획부 웹사이트의 경우 로컬 탐색 메뉴가 화면 왼쪽에 있어 사용자가 섹션을 가로질러 탐색할 수 있도록 합니다. 이는 탐색 브라우징을 촉진하고, 내부 페이지에 직접 도착한 사용자에게 유용합니다.

✅ NYC’s Department of City Planning: 왼쪽에 있는 로컬 네비게이션은 사용자가 관련 요소들로 이루어진 섹션을 이웃처럼 탐색할 수 있게 합니다. 이 디자인은 탐색 브라우징을 용이하게 하며, 사용자가 필요한 정보와 거의 일치하지만 정확히 일치하지 않는 내부 페이지에 도착했을 때도 유용합니다.

사용 가능한 옵션 표시

7. 링크 레이블에 명확하고 익숙한 용어 사용

사용자가 찾고자 하는 내용을 파악하고, 익숙하고 관련성 있는 카테고리 레이블을 사용하세요. 메뉴는 만든 단어, 내부 용어, 추상적인 고수준 카테고리화를 사용하는 곳이 아닙니다. 콘텐츠, 기능 또는 리소스를 명확하게 설명하는 용어를 사용하세요.

8. 링크 레이블 스캔이 용이하게

사용자가 메뉴를 읽는 데 걸리는 시간을 줄이기 위해 수직 메뉴는 왼쪽 정렬하고, 주요 용어를 앞에 배치하세요. 이는 사용자가 빠르게 원하는 정보를 찾는 데 도움을 줍니다.

9. 대형 웹사이트의 경우 여러 탐색 계층 표시

일반적인 사용자 경로가 여러 레벨을 통해 드릴 다운하는 경우, 메가 메뉴를 사용하여 사용자가 레벨(또는 두 레벨)을 건너뛸 수 있도록 하세요. 모바일 장치에서는 순차 탐색을 통해 사용자가 깊은 구조를 비교적 빠르게 탐색할 수 있도록 합니다. 예를 들어, 도요타는 모바일에서 순차 메뉴를 사용하여 사용자가 깊은 구조로 드릴 다운할 수 있도록 하며, 이미지로 추가 정보를 제공합니다.

✅ Toyota는 모바일에서 사용자가 깊은 구조로 비교적 빠르게 들어갈 수 있도록 순차적 메뉴를 사용합니다. 이미지로 추가 정보를 제공하여 네비게이션을 돕습니다. 이는 아코디언 메뉴에서는 쉽게 구현할 수 없는 기능입니다.

10. 긴 메뉴에는 시각적 단서 사용

긴 메뉴에는 시각적 커뮤니케이션(선택적으로 추가 신호)을 사용하여 정보 향을 증가시키세요. 이미지, 아이콘, 제한된 색상 사용은 낯선 옵션의 이해(또는 차별화)를 돕고, 스캔 가능성을 높일 수 있습니다. 하지만 이는 명확한 텍스트 레이블을 대체하는 것이 아니라, 추가적인 보조 요소로 사용해야 합니다. 접근성과 사용성 모두 명확한 텍스트 옵션을 제공해야 합니다.

조작 용이성 확보

11. 메뉴 링크를 쉽게 클릭하거나 탭할 수 있게

링크가 너무 작거나 가까이 배치되지 않도록 하세요. 작은 화면에서는 큰 링크가 더 쉽게 클릭할 수 있고, 큰 화면에서도 불필요하게 사용하기 어렵지 않도록 합니다.

12. 하위 메뉴는 캐럿 아이콘으로 명확히 표시

하위 메뉴가 있는 항목은 캐럿 아이콘으로 표시하여, 주요 탐색 항목이 새로운 페이지로 직접 연결되는 것과 하위 메뉴가 있는 항목을 쉽게 구분할 수 있도록 하세요. 예를 들어, 스탠포드 대학교 웹사이트는 캐럿 아이콘을 사용하여 하위 메뉴를 확장할 수 있는 항목과 페이지로 직접 연결되는 항목을 구분합니다.

13. 하위 메뉴는 클릭으로 활성화

호버는 보편적으로 사용할 수 없습니다. 터치스크린을 사용하는 사용자나 키보드를 주로 사용하는 사용자는 호버로 숨겨진 콘텐츠에 접근할 수 없습니다. 메뉴가 호버로 노출된다면, 이러한 사용자에게 백업 접근 방법을 제공해야 합니다. 장치와 입력 방식 전반에 걸쳐 일관되고 신뢰할 수 있는 인터랙션 패턴을 유지하는 것이 좋습니다. 또한, 호버로 활성화된 메뉴의 의도치 않은 트리거(및 해제)는 모든 사용자에게 불편합니다.

14. 다중 레벨의 중첩 메뉴는 피하기

단순한 드롭다운 메뉴는 한 레벨 탐색에 잘 작동하지만, 두 레벨이 되면 불편해집니다. 두 레벨 이상의 중첩 메뉴는 사용자가 하위 카테고리를 잘못 선택하거나 메뉴를 완전히 닫아 버릴 위험을 증가시킵니다. 하위 메뉴에 여러 레벨이 있는 경우, 메가 메뉴를 사용하거나 추가 옵션이 있는 라우팅 페이지로 사용자를 안내하세요.

❌ R Studio는 여러 레벨의 계단식 드롭다운 메뉴를 사용합니다. 이러한 메뉴는 물리적으로 조작하기 어렵고, 사용자가 메뉴에서 벗어나거나 잘못된 항목을 선택하는 오류를 자주 발생시킵니다.

15. 긴 페이지에는 스티키 메뉴 고려

긴 페이지의 사용자가 메뉴로 돌아가기 위해 화면 상단으로 스크롤해야 하는 번거로움을 덜기 위해, 스크롤 후에도 화면 상단에 메뉴가 계속 보이게 하는 스티키 메뉴를 사용하세요. 이는 작은 화면에서도 특히 환영받습니다.

16. 자주 사용하는 명령어는 쉽게 접근 가능하게 최적화

드롭다운 메뉴의 경우, 가장 자주 사용하는 항목을 드롭다운을 시작하는 링크 목표에 가깝게 배치하세요. 사용자의 마우스나 손가락이 멀리 이동하지 않도록 하세요. 핏츠 법칙에 따르면, 목표까지의 이동 시간은 목표까지의 거리와 비례합니다.

17. 혁신적이거나 기믹한 패턴 피하기

사용자에게 멋진 효과로 인상을 주려는 시도는 메뉴를 만들 때의 우선 순위가 되어서는 안 됩니다. 클라이언트나 이해관계자는 참신한 메뉴 디자인에 일시적으로 감동할 수 있지만, 사용자는 훌륭한 콘텐츠가 잘 제시되고 익숙한 메뉴를 통해 쉽게 접근할 수 있을 때 훨씬 더 감동받습니다. 예를 들어, 어도비의 CXM 웹사이트는 기존의 탐색 메뉴를 완전히 없애고 캐러셀 컨트롤을 사용하여 사용자를 페이지 중간의 임의의 위치로 건너뛰게 합니다. 어디로 이동하는지 알 수 없기 때문에, 사용자는 클릭할 유인이 거의 없습니다. 물론, 새로운 유형의 메뉴가 사용자 경험을 개선하는 경우도 있습니다. (햄버거 메뉴가 좋은 예입니다.) 또는 새로운 기술이 너무 달라서 이러한 가이드라인이 적용되지 않는 경우도 있습니다. 하지만 이러한 경우는 드물며, 대부분의 인터페이스는 이 원칙을 따를 때 더 사용하기 쉬워집니다.

❌ Adobe의 CXM 웹사이트는 전통적인 네비게이션을 완전히 생략하고, 대신 캐러셀 컨트롤을 사용하여 사용자를 페이지 아래 임의의 위치로 이동시킵니다. 사용자가 어디로 이동할지 알 수 없기 때문에 클릭할 동기가 거의 없습니다.

NNG에서는 또한 실무에서 활용할 수 있는 메뉴 디자인 체크리스트를 PDF 형태로 제공하고 있습니다.

아래에서 메뉴 디자인시 참고할 체크리스트도 함께 확인해보세요

[PDF] 메뉴 디자인 체크리스트: 17가지 UX 가이드라인

메뉴는 웹사이트와 애플리케이션에서 사용자가 콘텐츠를 찾고 기능을 사용하는 데 중요한 역할을 합니다. 사용자가 쉽게 이해하고 조작할 수 있는 메뉴를 제공하는 것은 좋은 사용자 경험(UX)을

archuive.tistory.com

[PDF] 메뉴 디자인 체크리스트: 17가지 UX 가이드라인

디쟈이너 — Fri, 21 Jun 2024 08:54:08 +0900

메뉴는 웹사이트와 애플리케이션에서 사용자가 콘텐츠를 찾고 기능을 사용하는 데 중요한 역할을 합니다. 사용자가 쉽게 이해하고 조작할 수 있는 메뉴를 제공하는 것은 좋은 사용자 경험(UX)을 제공하는 데 필수적입니다.

효과적인 메뉴 디자인은 사용자가 사이트나 애플리케이션을 사용하는 데 있어 중요한 요소입니다. 체크리스트를 활용하여 메뉴를 점검하고 개선하면 사용자가 보다 쉽게 콘텐츠를 찾고 기능을 활용할 수 있게 됩니다. 이러한 가이드라인을 따르면 사용자 경험을 향상시켜보세요!

PDF_Menu-Design-Checklist.pdf

0.06MB

이 PDF 파일의 자세한 적용은 아래의 글에서 확인해보세요.

웹사이트 메뉴 디자인 체크리스트 : 17가지 UX 가이드라인으로 사용자 경험 향상하기

이 글은 닐슨 노먼 그룹(Nielsen Norman Group)의 아티클을 읽고 번역한 글입니다.원문은 이곳에서 확인 가능합니다. 사용자는 콘텐츠를 찾고 기능을 사용하기 위해 메뉴에 의존합니다. 이 체

archuive.tistory.com

[UX Writing의 비밀] 해요체와 합니다체를 완벽히 활용하는 방법

디쟈이너 — Thu, 20 Jun 2024 08:35:10 +0900

합니다..? 해요..?

디지털 프로덕트를 만드는 UI/UX 디자이너 여러분께서는 사용자 경험을 최적화하기 위해 다양한 요소를 고려하셔야 하죠. 그 중에서도 UX Writing은 사용자와 인터페이스 간의 소통을 원활하게 하는 중요한 역할을 합니다.
UX Writing에서 사용하는 문체는 사용자 경험에 큰 영향을 미치며, 적절한 문체를 선택함으로써 사용자에게 더 나은 경험을 제공할 수 있습니다.

이번 글에서는 해요체와 합니다체를 언제, 어떻게 사용하면 좋을지 예시를 통해 알아보겠습니다.

해요체의 사용

해요체는 친근하고 부드러운 느낌을 줍니다. 사용자가 인터페이스와 상호작용할 때 편안함을 느낄 수 있도록 도와줍니다. 다음과 같은 상황에서 해요체를 사용하는 것이 적합합니다:

온보딩 과정: 처음 앱을 사용하는 사용자에게 친근하게 다가가고 싶을 때
알림 및 피드백 메시지: 오류나 성공 메시지를 전달할 때
도움말 및 안내 메시지: 사용자가 기능을 이해하고 사용할 수 있도록 돕고자 할 때

예시:

온보딩 화면: "앱에 오신 것을 환영해요! 시작하려면 아래 버튼을 눌러 주세요."
오류 메시지: "오류가 발생했어요. 잠시 후 다시 시도해 주세요."
성공 메시지: "성공적으로 완료했어요!"
도움말 메시지: "더 많은 정보를 원하시면 여기를 클릭해 보세요."

합니다체의 사용

합니다체는 격식을 갖춘 느낌을 주며, 신뢰성과 권위성을 높이는 데 효과적입니다. 다음과 같은 상황에서 합니다체를 사용하는 것이 적합합니다:

설정 및 개인정보 관련: 중요한 정보를 전달할 때
계약 및 법적 고지: 법적 구속력이 있는 내용을 전달할 때
고객 지원 및 FAQ: 공식적인 답변이 필요할 때
보안 관련 메시지: 보안과 관련된 중요한 경고를 전달할 때

예시:

설정 화면: "계정을 안전하게 보호하려면 비밀번호를 자주 변경하십시오."
개인정보 처리 방침: "당사는 귀하의 개인정보를 안전하게 보호하기 위해 최선을 다하고 있습니다."
고객 지원: "문의 사항이 있으시면 언제든지 고객 지원팀에 연락해 주십시오."
보안 경고: "이 작업을 수행하려면 추가 인증이 필요합니다. 보안을 위해 다시 로그인하십시오."

두 문체의 혼용

해요체와 합니다체를 적절히 혼용하면 사용자에게 친근함과 신뢰감을 동시에 줄 수 있습니다. 상황에 따라 두 문체를 유연하게 사용하여 사용자 경험을 최적화할 수 있습니다.
예시:

온보딩 화면: "앱에 오신 것을 환영해요! 시작하려면 아래 버튼을 눌러 주세요. 더 자세한 정보는 설정 메뉴에서 확인하실 수 있습니다."
오류 메시지: "오류가 발생했어요. 잠시 후 다시 시도해 주세요. 문제가 지속되면 고객 지원팀에 문의하십시오."
도움말 메시지: "더 많은 정보를 원하시면 여기를 클릭해 보세요. 자세한 안내는 FAQ 페이지에서 확인하실 수 있습니다."

문체 선택 시 고려 사항

사용자층 분석: 사용자의 연령, 성별, 성향 등을 고려하여 적절한 문체를 선택합니다.
브랜드 톤앤매너: 브랜드의 성격과 일치하는 문체를 사용하여 일관성을 유지합니다.
상황과 맥락: 메시지의 중요도와 상황에 맞는 문체를 선택하여 사용자에게 명확하고 적절한 정보를 전달합니다.

결론

UX Writing에서 해요체와 합니다체를 적절히 사용하는 것은 사용자와의 소통을 원활하게 하고, 사용자 경험을 향상시키는 중요한 요소라고 볼 수 있습니다. 해요체는 친근함과 편안함을, 합니다체는 신뢰성과 권위성을 전달하는 데 효과적입니다. 상황과 맥락에 따라 두 문체를 유연하게 혼용하여 사용자에게 최적의 경험을 제공하는 것이 중요합니다.

북마크, 즐겨찾기, 핀, 별표의 디자인 차이점

디쟈이너 — Wed, 19 Jun 2024 08:42:53 +0900

프로덕트 디자이너로서 우리는 북마크, 즐겨찾기, 핀, 별표와 같은 용어를 자주 접합니다. 이 기능들은 간단해 보일 수 있지만, 구현 방식에 따라 사용자 경험(UX)에 큰 영향을 미칩니다. 이 글에서는 이러한 요소들을 접근하는 방법을 다루며, 모호성을 줄이고 사용자 만족도를 높이는 방법을 공유합니다.

기본 개념 이해하기

북마크(Bookmarks): URL이나 문서를 나중에 쉽게 접근할 수 있도록 저장하는 기능입니다. 주로 웹 브라우저에서 사용되며, 예를 들어 사용자가 중요한 정보를 빠르게 찾을 수 있도록 도와줍니다.
즐겨찾기(Favourites): 사용자가 자주 사용하거나 선호하는 항목을 빠르게 접근할 수 있도록 표시하는 기능입니다. 예를 들어, 쇼핑몰 웹사이트에서 자주 구매하는 상품을 즐겨찾기에 추가할 수 있습니다.
핀(Pins): 목록의 상단에 고정하거나 눈에 잘 띄는 위치에 배치하여 항상 보이도록 하는 기능입니다. 예를 들어, 팀 협업 툴에서 중요한 공지사항을 핀으로 고정할 수 있습니다.
별표(Stars): 즐겨찾기와 유사하지만, 이메일이나 프로젝트 관리 도구 등 다른 문맥에서 사용됩니다. 예를 들어, 중요한 이메일에 별표를 달아 쉽게 식별할 수 있습니다.

용례 파악하기

맥락적 관련성

이러한 기능들이 사용될 맥락을 평가합니다. 예를 들어, 지식 관리 시스템에서는 '북마크'가 문서를 참조할 필요가 있는 사용자에게 더 직관적일 수 있습니다.

사용자 목표

사용자가 달성하려는 목표를 이해합니다. 자주 사용하는 항목을 강조하고 싶은 것인지(즐겨찾기), 중요한 정보를 항상 손쉽게 접근하고 싶은 것인지(핀) 등을 파악합니다.

명확성을 위한 디자인

일관된 용어 사용

애플리케이션의 생태계 내에서 친숙한 용어를 고수합니다. 한 부분에서 '북마크'를 사용한다면, 다른 곳에서 같은 의미로 '즐겨찾기'를 사용하지 않도록 합니다.
- 일관성 유지: 동일한 용어와 아이콘을 사용하는 것이 중요합니다. 예를 들어, 모든 기능에서 '별표'를 사용할 때는 동일한 별 아이콘을 사용해야 합니다.

시각적 구분

서로 다른 아이콘과 색상을 사용하여 사용자가 이러한 기능들을 빠르게 구분할 수 있도록 합니다. 예를 들어, '별표'에는 별 아이콘, '핀'에는 핀 아이콘을 사용합니다.

아이콘 디자인: 아이콘의 크기, 색상, 모양 등을 고려하여 사용자가 직관적으로 이해할 수 있도록 디자인합니다.
색상 사용: 예를 들어, 즐겨찾기는 노란색, 북마크는 파란색으로 구분하여 시각적으로 쉽게 인식할 수 있도록 합니다.

실제 예시

구글 드라이브

중요한 파일에 '별표'를 사용하여 주요 파일이 메인 작업 공간을 혼란스럽게 만들지 않으면서 눈에 띄게 합니다. 이는 사용자가 중요한 파일을 빠르게 찾을 수 있도록 도와줍니다.

기능 설명: 사용자가 파일 목록에서 중요한 파일을 별도로 표시하여 쉽게 접근할 수 있습니다.
사용자 피드백: 많은 사용자가 이 기능을 통해 작업 효율이 크게 향상되었다고 보고합니다.

Google Drive의 Star 기능. 영어권 유저는 Star, 한국 유저는 중요 문서함 이라 표기한다.

핀터레스트

시각적 북마크를 저장하는 용도로 '핀'을 사용하는 플랫폼입니다. 이는 사용자가 관심 있는 이미지를 빠르게 저장하고 공유할 수 있도록 합니다.

기능 설명: 사용자가 다양한 이미지를 핀으로 저장하여 나중에 참고하거나 공유할 수 있습니다.
사용자 피드백: 사용자는 이 기능을 통해 쉽게 이미지를 관리하고 필요한 정보를 찾을 수 있다고 평가합니다.

적절한 용어를 선택하고 이를 올바르게 구현하는 것은 사용자 만족도에 매우 중요합니다. 사용자 중심의 디자인 접근 방식을 적용하여 혼란을 줄이고 제품의 전체 UX를 개선할 수 있습니다. 항상 사용자 피드백에 따라 반복하고 개선하는 것을 잊지 마십시오.

정보와 경험의 구분이 디자인 시스템의 성숙도에 기여하는 방법

디쟈이너 — Tue, 18 Jun 2024 08:00:23 +0900

디자인은 단순히 시각적인 요소를 아름답게 만드는 것 이상의 의미를 가지고 있습니다. 디자인의 핵심은 사용자 경험을 향상시키고, 정보 전달을 효율적으로 하는 데 있습니다. 이번 글에서는 정보와 경험의 구분이 디자인 시스템의 성숙도에 어떻게 기여할 수 있는지에 대해 논의해보겠습니다.

디자인 시스템을 성숙시키자

정보와 경험의 차이

정보는 우리가 전달하려는 사실, 데이터, 지식 등을 의미합니다. 반면 경험은 사용자가 정보와 상호작용하면서 느끼는 감정과 인식을 포함합니다. 예를 들어, 웹사이트의 콘텐츠는 정보이고, 그 웹사이트를 탐색하는 과정에서 사용자가 느끼는 것은 경험입니다.

성숙한 디자인 시스템의 특징

성숙한 디자인 시스템은 단순히 정보를 제공하는 것에 그치지 않고, 사용자의 경험을 고려합니다. 정보와 경험을 균형 있게 조화시켜야 합니다. 그렇다면 정보와 경험의 조화는 어떻게 이루어질까요?

사용자 중심 디자인

사용자가 필요로 하는 정보를 정확하게 제공하는 동시에, 이를 쉽게 찾고 이해할 수 있도록 도와주는 것이 중요합니다. 이는 직관적인 내비게이션과 명확한 정보 구조를 포함합니다.

감정적 연결

사용자가 제품이나 서비스를 이용하면서 긍정적인 감정을 느낄 수 있도록 디자인해야 합니다. 이는 색상, 글꼴, 이미지 등 시각적인 요소를 통해 구현될 수 있습니다.

일관성

디자인 시스템의 일관성은 사용자가 정보와 상호작용할 때 혼란을 느끼지 않도록 합니다. 이는 전체적인 디자인 시스템과 스타일 가이드를 통해 달성될 수 있습니다.

#디자인 시스템의 성숙도를 높이기 위한 전략

사용자 리서치

사용자가 누구인지, 그들이 어떤 정보를 필요로 하는지, 어떤 경험을 기대하는지를 이해하는 것이 중요합니다. 이를 위해 사용자 인터뷰, 설문조사, 사용성 테스트 등을 활용할 수 있습니다.

프로토타입 테스트

실제 사용자 환경에서 디자인을 테스트하여 개선점을 찾아내는 것이 중요합니다. 프로토타입을 통해 사용자의 피드백을 받고, 이를 반영하여 디자인을 수정합니다.

데이터 분석

사용자 행동 데이터를 분석하여 디자인의 문제점을 파악하고, 이를 바탕으로 디자인을 개선합니다. 이는 사용자 흐름 분석, 클릭 맵, 히트맵 등을 통해 이루어질 수 있습니다.

디자인 시스템의 구축과 유지

일관된 디자인을 위해 디자인 시스템을 구축하고, 이를 지속적으로 업데이트하는 것이 중요합니다. 디자인 시스템은 컴포넌트 라이브러리, 패턴 라이브러리, 스타일 가이드 등을 포함합니다.

디자인 시스템의 예시

컴포넌트 라이브러리

버튼, 입력 필드, 네비게이션 바 등 재사용 가능한 UI 요소들을 모아놓은 라이브러리입니다. 이를 통해 일관된 디자인을 유지할 수 있습니다.

패턴 라이브러리

특정 기능이나 상호작용을 구현하는 디자인 패턴을 모아놓은 라이브러리입니다. 예를 들어, 사용자 로그인 패턴, 상품 검색 패턴 등이 있습니다.

스타일 가이드

색상, 타이포그래피, 아이콘 등 디자인 요소의 스타일을 정의한 가이드입니다. 이를 통해 브랜드 일관성을 유지할 수 있습니다.

정보와 경험을 조화시키기 위한 구체적인 방법

일관된 UI 요소 사용

일관된 버튼 스타일, 폰트, 컬러 팔레트를 사용하여 사용자에게 익숙한 환경을 제공합니다. 이렇게 하면 사용자는 새로운 정보나 기능을 쉽게 인식하고 사용할 수 있습니다.

사용자 피드백 반영

디자인 시스템을 개발하는 동안 사용자로부터 지속적으로 피드백을 받아 디자인에 반영합니다. 이는 사용자 경험을 개선하고, 사용자와의 감정적 연결을 강화하는 데 도움이 됩니다.

디자인 시스템 문서화

모든 디자인 요소와 패턴을 문서화하여 팀 전체가 동일한 가이드를 따를 수 있도록 합니다. 이는 디자인의 일관성을 유지하고, 새로운 팀원이 쉽게 적응할 수 있도록 돕습니다.

반복적인 테스트와 개선

디자인 시스템은 한 번 구축했다고 끝나는 것이 아닙니다. 지속적인 테스트와 피드백을 통해 지속적으로 개선해 나가야 합니다. 이를 통해 변화하는 사용자 요구와 트렌드에 신속하게 대응할 수 있습니다.

정보와 경험의 구분은 디자인 시스템의 성숙도를 높이는 데 중요한 역할을 합니다. 단순히 정보를 제공하는 것을 넘어서, 사용자 경험을 고려한 디자인 시스템이 필요합니다. 이를 위해 사용자 중심의 접근법과 지속적인 테스트, 데이터 분석, 그리고 일관된 디자인 시스템 구축이 필수적입니다. 성숙한 디자인 시스템은 사용자에게 더 나은 경험을 제공하고, 궁극적으로 비즈니스 목표 달성에 기여할 것입니다.

디자인 시스템을 통해 정보와 경험을 효과적으로 조화시키면, 사용자는 더욱 만족스러운 경험을 하게 되고, 이는 곧 제품이나 서비스의 성공으로 이어질 것입니다. 디자인 시스템은 그 자체로도 중요한 자산이지만, 이를 통해 사용자 경험을 최적화하는 것이야말로 진정한 목표라 할 수 있습니다.

[Framer] CMS 관리 - 페이지의 Description은 어떻게 작성하는것이 좋을까?

디쟈이너 — Thu, 2 May 2024 20:36:26 +0900

Framer에서 손쉽게 콘텐츠를 관리할 수 있는 CMS 기능.

CSM의 Settings 화면에 는 페이지별 Description을 어떻게 구성해 보여줄지 설정이 가능하다.

Google 검색 센터의 우수한 메타 설명을 만들기 위한 권장사항 살펴보자.

좋은 예와 나쁜 예를 이해하기 쉽게 정리해두었다.

디자이너는 화면의 흐름을 어떻게 표현할까? - 화면 흐름도, 정보 구조도, 유저 플로우로 알아보기

디쟈이너 — Thu, 28 Mar 2024 19:24:43 +0900

피그마에 화면을 나열하다보니 궁금한게 생겼다, 어디로 확장해야하지?

UI/UX를 디자인 할 때 고민해야 할 화면의 진행 방향성에 대해 작업자들이 동의할 수 있는 레퍼런스가 있는지 궁금했다.

그러다가 찾아보게된 화면 흐름도 (Screen Flow Diagrma), 정보 구조도 (Information Archtecture), 유저 플로우 (User Flow)!

왜 어떤건 가로, 어떤건 세로로 나열하게 되는걸까?

화면 흐름도 (Screen Flow Diagram)

유저가 서비스를 이용하는 흐름이나 기능을 정의하기 위해 만드는 문서이다.

화면이나 기능 단위로 유저의 동선을 설계하게 되며, 화살표와 도형을 사용해 도표(Diagram)을 만든다.

특징

화살표를 따라가다보면 사용자가 어떤 프로세스로 서비스를 이용하는지 파악할 수 있다.
각 도형의 의미가 명확해 작업자들이 설계할 때 유용하다
플로투 차트 심볼을 이용해 흐름을 도식화한다.
플로우 차트의 각 도형, 심볼은 여정의 터치포인트이자 노드(Node)라고도 불린다.
참고: 플로우 차트의 다양한 종류는 SmartDraw 사이트에서 확인하면 좋다.

화면 흐름도에 사용하는 도형들

이런것도 있다

정보 구조도 (IA, Information Architecture)

서비스 기획의 기본이라고 할 수 있다. 서비스의 구조를 계층화하여 설명하는 문서이다. 서비스의 메뉴를 분류하고 그룹화해 계층 구조로 설계한다. 말 그대로 정보 구조 설계!

특히 다양한 서비스를 제공하고 있을 때 이 정보 체계 내에서 탐색을 어떻게 할 것인지, 컨텐츠에 직관적으로 접근하고 효율적인 태스크 처리가 가능하도록 처리할 수 있을지 서비스를 설계하기 위한 문서이다.

잘 짜여진 IA는 아래와 같은 좋은 영향을 만들어낸다

제작자는 서비스의 전체 그림과 흐름을 파악하기 쉬워진다. 또한 서비스의 기능이 어떻게 묶여있는지 (Grouping) 파악하는 것을 돕는다
사용자는 찾고자 하는 기능을 빠르게 발견할 수 있다

일반적으로 이 IA가 스크린, 혹은 기능 단위로 묶여있기 때문에 WBS(Work Breakdown Structure)와 같은 문서로 파생시키기 좋다. 프로젝트 관리의 기반이 된다.

이해를 돕기 위한 예시: 곰 인형 정보 구조도 만들기

곰 인형의 정보 구조도 만들기

두 문서의 공통점

서비스의 전체 구조를 파악할 때 작성한다
프로젝트 규모를 빠르게 파악할 수 있다

이렇게, 기획단에서 작성한다고 알려진 두 문서에 대해 공부하다보니 내가 피그마에 설계하는 그림과는 같으면서도 다른점이 느껴졌다. 일단 화면 흐름도가 좌에서 우로 흘러가며 유저의 터치 포인트를 표현한다는 점에서 일부 힌트를 얻었다. 화면 나열은 좌에서 우가 적절하다.

반대로 두 문서가 기획단에서 디자이너나 개발자에게 전달하기 전에 그려지는 문서다보니 디자인과는 다르다고 느껴졌다. 그러다 발견한 유저 플로우 (User Flow) 컨셉

유저 플로우와는 비슷한 단어가 왕왕 나왔다. User Flow, UX Flow Chart, Wire Frame, Wire Flow…

유저 플로우(User Flow)

개념

사용자가 프로덕트와 인터랙션할 때 선택할 수 있는 다양한 방법을 글로 쓰거나 다이어그램으로 표현한 것.
온보딩 화면과 같이 프로덕트에 진입 한 시점에서 시작해 구매나 계정 가입과 같은 최종 태스크로 끝난다. 이 과정을 도식화 하며 디자이너는 사용자 경험을 평가하고 최적화해 전환율을 높일 수 있다.

유저 플로우(사용자 여정)의 각 터치포인트는 다이어그램에서 노드(Node)로 표시된다.
이 노드는 위에서 살펴본 화면 흐름도에서 사용하는 도형과 유사하다.

구성요소

목표(User Goal): 사용자가 서비스를 통해 얻고자 하는 결과
작업(Task): 목표를 위해 사용자가 수행하는 것
UI: 화면
행동(Action): UI상의 주 활동 및 보조 활동
판단(Decision): 사용자가 행동 후 결과가 분기되는 경우

(와이어 프레임의 형태 정도더라도...) UI를 포함하고 있다는 점에서 디자이너가 피그마에서 하는 작업과 유사해보인다.

결국 이러한 문서를 Figma에 접목하자면…

IA는 페이지나 섹션 구분의 근거가 된다.
Flow Chart는 스크린(Frame) 나열에 접목할 수 있다.

다른 디자이너들은 어떻게 작업할까?

레퍼런스 찾아보기!

Figma Community에 공개되어있는 디자인 파일들을 일부 찾아서 살펴보았다.

기능은 위에서 아래로, 기능 안에서 파생되는 태스크는 왼쪽에서 오른쪽으로

섹션 분류는 위에서 아래로, 화면의 흐름은 왼쪽에서 오른쪽으로

섹션 분류 없이 좌에서 우로 나열한 케이스

대부분 화면의 진행은 왼쪽에서 오른쪽으로, 해당 화면에 부가적인 기능이 발생하는 경우 아래로 표시하는 패턴이 있는 듯 했다.

디자인 시 화면에 바로 Arrow를 사용해 기능이나 다음 화면을 표시하기 때문에 Screen Flow 라는 키워드를 떠올렸던 것인데, 내가 작업하는 방식은 결국 정밀한 User Flow문서가 없는 경우, 디자인과 함께 플로우를 정의하는 작업하는 방식이었다고 볼 수 있다. 앞으로는 Decision을 좀 더 표시해 더 정확한 User Flow로 만들어봐도 좋을것 같다.

추가로 User Flow를 설계함과 동시에, 기능명세를 알고 있어야 더 탄탄하고 개발자의 되물음이 없는 프로젝트 진행이 가능하기 때문에 기능명세서에 대해서도 함께 알아봐야지. ‍♀️

Ref.

능동적인 인출 훈련으로 학습 효율을 올려보자

디쟈이너 — Tue, 25 Jul 2023 00:11:01 +0900

능동적 인출로 회상률을 올릴 수 있다?!

기억은 부호화 - 저장 - 인출 이라는 3개 과정으로 이루어진다. 인출은 기억된 정보를 사용하기 위해 장기기억에서 정보를 꺼내는 과정을 말하며 회상(recall)과 동일하다고 볼 수 있다.

능동적이라는 것은 기억(안)에서 꺼내어(output) 보는것을 말한다.

학습할 때 책을 읽고, 밑줄을 치고, 형광펜을 칠하는것과 같은 행위를 정보를 주입하는 수동적인 방식(input) 의 반대라고 볼 수 있다.

이러한 방식은 읽기만 하는 학습보다 회상률을 높일 수 있다고 한다.

즉 기억에서 되살려내 다른 사람에게 설명한다거나, 글을 작성하는 등 실질적인 지식으로 사용하는 확률을 높일 수 있다는 것이다.

이러한 의도적 인출과 함께 중요한 것은 반복학습(분산학습)이다.

한번에 집중해서 모든 내용을 익히는 집중학습보다 동일한 내용을 시간을 두고 학습 했을 때 더 회상률이 높았다고 한다.

특히 주기적으로 반복하는 것 보다 초반에 집중적으로 반복하다가 뒤로 갈 수록 느슨해지는 형태의 반복이 더욱 도움이 되었다고 한다.

인출하는 방법으로는 플래시 카드, 질문하기 등이 있는데 나는 TIL(Today I Learned)을 활용해보기로 결정했다.

TIL은 하루동안 내가 배운것이 무엇인지 회고하고 하루 하루 지식을 쌓아가는 방식인데 특히 개발자들이 GitHub에 잔디심기를 목표로 하며 번지기 시작했다.

TIL은 글로 작성해야 하기 때문에 공부한 것을 불러내고 내가 소화한 것을 글로 남기며 의도적인 인출이 가능할것 같다.

도전!

(이 글은 **학습과학의 이해와 적용(12) – <원리 11> ‘능동적 인출 연습’이 ‘수동적 복습’보다 효과적이고, ‘분산학습’이 ‘집중학습’보다 효과적이다[Revised]. 글을 읽고 두 번의 인출 과정을 통해 작성했습니다. )

닐슨 노먼그룹이 선정한 2022 UX 아티클 Top 10

디쟈이너 — Tue, 27 Dec 2022 12:29:20 +0900

2022년이 마무리되며

닐슨 노먼 그룹에서 한 해 발행된 사용자 경험 아티클 중 가장 많은 청중을 모은 글 10가지를 공개했다.

Data Tables: Four Major User Tasks
테이블은 1)특정 기준에 맞는 레코드 찾기 2)데이터 비교 3)단일 행 데이터 보기/편집/추가 4)레코드에 대한 작업 수행과 같은 일반적인 유저 태스크 네가지를 지원해야한다.
UX Strategy: Definition and Components
UX 전략은 솔루션을 설계하고 구현하기 전에 목표 달성 방향에 대한 이해를 공유하는 3단계 계획이다. 시간이 지남에 따라 UX 작업의 우선 순위 지정 및 실행을 안내하는 역할을 한다.
Best Font for Online Reading: No Single Answer
가독성 높은 폰트 중 최고와 최악의 읽기 속도가 35% 차이가 난다는 연구 결과가 나왔다. 사람들은 20살 단위로 11% 더 느리게 읽는다.
A Guide to Using User-Experience Research Methods
현대의 UX 연구 방법은 다양한 질문에 답한다. 언제 어떤 사용자 조사 방법을 사용해야 하는지 알 수 있도록 20가지 방법 각각이 일반적인 제품 개발 프로세스 내에서 시간 경과에 따라 3차원에 걸쳐 매핑해본다.
Infinite Scrolling: When to Use It, When to Avoid It
무한 스크롤은 상호작용 비용을 최소화하고 사용자 참여를 증가시키지만 모든 웹사이트에 적합한 것은 아니다. 일부의 경우 'pagination' 또는 'Load More' 버튼이 더 나은 솔루션이 될 수 있다.
Personas vs. Archetypes
UX 작업에 사용되는 Archetypes과 personas는 유사한 통찰력과 유사한 종류의 데이터를 기반으로 하며 주로 프레젠테이션에서 달라진다. Personas는 단일 인간 캐릭터로 표현되는 반면 Archetypes은 특정 이름이나 얼굴에 엮이지 않는다.
Setting UX Roles and Responsibilities in Product Development: The RACI Template
유연한 책임 할당 매트릭스(flexible responsibility-assignment matrix)를 사용하여 UX 역할 및 책임을 명확히 하고, 팀 협업 지점을 예상하고, 제품 개발에서 생산성을 유지하자.
Using Grids in Interface Designs
그리드는 사용자가 인터페이스를 쉽게 스캔하고 사용할 수 있도록 응집력 있는 레이아웃을 만드는 데 도움이 된다. 좋은 그리드는 다양한 화면 크기와 방향에 적응해 플랫폼 간에 일관성을 보장한다.
Two Tips for Better UX Storytelling
효과적인 스토리텔링에는 청중을 참여시키고 간결하면서도 효과적인 방식으로 스토리를 구성해야한다. 스토리 삼각형(story triangle)과 스토리 마운틴 템플릿(story-mountain template)의 개념을 활용하여 사용자 스토리를 개선할 수 있다.
Antipersonas: What, How, Who, and Why?
안티페르소나는 제품이 사용자와 비즈니스에 해를 끼치며 오용되는것을 예상하는것을 돕는다.

스터디 가이드 Top 10

닐슨노먼 그룹에서 study guide라는 새로운 포맷의 컨텐츠를 발행했는데, 아티클과 비디오를 하나의 주제로 합쳐 학습할 수 있는 가이드를 제공하는 컨텐츠였다. 2022년 한 해 동안 가장 사랑받은 10개의 학습 가이드 목록.

Bonus: 작년 아티클 Top 5

2021년에 발행 되었지만 2022년에도 사랑받은 아티클 5가지는 보너스로 챙겨보자.

Design Systems 101
디자인 시스템은 여러 페이지와 채널에서 공유된 언어와 시각적 일관성을 생성하는 동시에 중복성을 줄임으로써 규모에 맞게 디자인을 관리하기 위한 표준 세트이다.
Using “How Might We” Questions to Ideate on the Right Problems
How-might-we 질문을 통해 팀이 해결해야 할 올바른 문제에 집중하는 동시에 창의적인 솔루션을 생성할 수 있다.
Mapping User Stories in Agile
유저 스토리 맵은 애자일 팀이 구축할 대상을 정의하고 모든 것이 조화를 이루는지에 대한 가시성을 유지하는것을 돕는다. 사용자 중심의 대화, 협업 및 기능 우선 순위 지정을 통해 반복적인 제품 개발을 조정하고 안내할 수 있다.
The 6 Levels of UX Maturity
우리의 UX 성숙도 모델(UX-maturity model)은 UX의 프로세스, 디자인, 연구, 리더십 지원 및 수명을 다루는 6단계로 구성된다. 퀴즈를 사용하여 조직의 UX 성숙도에 대한 아이디어를 얻어보자.
Problem Statements in UX Discovery
UX 프로젝트의 발견 단계에서 problem statement은 탐색하고 해결해야 할 문제를 식별하고 프레임을 지정하며 발견의 범위와 초점을 전달하는 데 사용된다.

시간 날 때 마다 하나씩 차근차근 학습해보면 좋을것 같다.

네이밍 컨벤션(명명규칙)의 힘

디쟈이너 — Wed, 14 Dec 2022 14:11:11 +0900

다음 글은 The power of naming convention 을 번역한 글입니다.

우리는 모두 누군가(아마도 상사일 것입니다) 최신 이메일이나 게시판을 찾거나 얼마전에 만든 파일을 공유해 달라고 요청하면 찾기가 어려웠던 경험이 있었을 것이다.

어디에 있지?
어떻게 찾지?
어떻게 다시 이름 붙이지?

아마도 파일은 <final _final _RobertsFinal _shipping _version _final.ext> 와 같이 이름 붙어 있을것이며, 특별히 이 파일을 작업하지 않은 사람에게는 의미가 없는 이름입니다.

이와 같은 상황은 드물지 않습니다. 사람들이 다양한 비즈니스 상황에서 자산을 찾는 데 어려움을 겪는 연구를 관찰한 후 어떤 기술이 이 패러다임을 바꿀 수 있는지 궁금했습니다.

즉, 상속된 명명 규칙이나 구조 내에서 어떻게 탐색 할 것인가?
원하는 결과에 도달하기 위해 다른 방법을 적용할 수 있는가?
검색이 파일 위치에 대한 궁극적인 해답인가? (특히 우리가 무엇을 찾고 있는지 모르는 경우)
팀, 부서 또는 비즈니스 단위로서 명명 규칙에 대한 접근 방식을 어떻게 선택할 수 있습니까?

다음 네 개의 아티클은 우리가 어떤 구조에 있든 디지털 자산의 세계를 구성하는 데 도움이 되는 기본 원칙을 설정하는 것을 목표로 합니다. 마찬가지로 제어할 항목과 무시해야 할 항목에 대해 구분을 짓습니다.

네이밍 컨벤션(명명 규칙)에 대해 이야기해봅시다!

"IDC는 1,000명의 지식 근로자를 고용하는 기업이 정보를 검색하는 데 연간 최소 250만 ~ 350만 달러를 낭비하고 기존의 실행 가능한 정보를 찾지 못하는 것으로 추정합니다." – IDC 설문조사(2020)

이 도전을 더 잘 이해하려면 우리 모두가 어떻게 이 단계에 도달했는지에 대한 근거와 의미를 이해하기 위해 몇세기 전으로 되돌아가야 합니다.

장부기입(부기, bookkeeping)의 역사

Figure02: Bookkeeping

회계의 아버지인 Luca Pacioli는 부기 및 복잡한 명명 구조에서 이중 항목(double-entries)를 최초로 언급했습니다. 그는 나중에 참조할 수 있도록 항목을 식별, 기록 및 보관하기 위한 새로운 구조를 도입했습니다.

회계가 수세기에 걸쳐 발전함에 따라 단일 책(single book)은 책을 위한 책(book of books)이 되었고, 정보는 복잡한 것을 정리하는 또다른 접근방식이 필요하게 되었습니다. 기록 자체보다 더 복잡한 계정을 어떻게 기록하고 필연적으로 함께 연결되어 명백한 대상의 금전적 가치를 추구하는지에 대한 멘탈 모델에 관한 것이었습니다.

알파벳과 숫자

Figure03: Alphabets and Numbers

숫자를 사용하는 것은 물건을 분류하고 순서를 지정하는 가장 쉬운 방법이 되었습니다. (1, 2, 3 등, 여기서 1.1은 1.0의 하위 구조를 정의함).

초기 알파벳 시스템은 0-9 및 A-Z 조합으로 명명 규칙을 개선했습니다. 이를 통해 우리는 규모를 확장하고 더 복잡한 번호 체계를 가질 수 있었습니다. 20세기 초의 건강 기록을 생각해 보십시오. 사람들은 문자 A로 상자에 서명하고 Aa, Ab, Ac, Ad 등으로 구분선에 서명했습니다[007↗]. 일부 문자 기반 파일링 시스템[008↗]은 여전히 존재하며 전 세계적으로 소규모 GP 관행에 가치를 제공합니다.

카드와 박스

Figure04: Cards and Boxes

카드와 상자의 물리적 경험은 디지털 파일링 시스템으로 진화합니다. 진보적 멘탈 모델을 통해 관찰자는 복잡한 데이터 구조를 탐색할 수 있습니다[참고: Array↗]. 이는 우리가 데이터를 보는 방식과 사용 가능한 데이터 소스에서 데이터나 정보를 얻는것에 영향을 미칩니다.

우리가 직접 만들지 않은 다른 사람의 데이터를 제어해야 할 때 DropBox, One Drive 및 Google Drive는 점점 더 사용하기 어려워집니다. 상황은 Slack 및 Miro의 클라우드 드라이브 사본을 포함하여 12개의 서로 다른 드라이브에 흩어져 있는 12개 버전이 생성되는것으로 흐를 수 있습니다. 이제 우리는 수정이 가능한 링크 하나만 있으면 한개의 파일에서 수정할 수 있습니다.

파일과 폴더

Figure05: Naming Convention

디렉토리에 레이블을 지정하고 유지 관리하기 위해 수천 개의 구조 모델을 실험했습니다. 이러한 실험은 물리적 및 정신적 구조를 해결하는 최적의 방법을 찾기 위해 이러한 결과를 대기업 및 중소기업(기관 및 사내)와 공유하고 도전했습니다.

에이전시에는 일반적으로 무엇보다도 파일 구조를 결정하는 PM이 있으며 나머지 팀원은 이를 따릅니다. 디자이너로서, 당신은 당신이 만든 무엇이든 폴더 '05.Design'에 무엇을 넣던지 기억할 수 있지만 다른 디자이너들은 그렇지 않습니다. 또한 Sketch 및 Figma 파일은 더 이상 로컬 드라이브에 없습니다.

50명 이상의 디자인 팀이 3개 이상의 제안을 만들면서 아무도 디자인 시스템을 소유하거나 업데이트 하지 않는 것은 문제가 될 수 있습니다. 특히 명명 규칙을 지키지 않는 경우 더욱 그렇습니다.

환경

이로써 폴더, 파일 계층, 심지어 이메일까지 적용할 수 있는 멘탈 모델인 최종 요점에 도달했습니다.

이 방법은 3x3이라고 불리며, 이는 인간의 경로와 압박된 시간에 정보 조각에 초점을 맞추고 분류하는 방법을 설명합니다.

우리는 세 가지 "3" 멘탈 영역(이전 before, 도중 during, 이후 after)을 만듭니다. 예전에는 에이전시에 IN, WORK, OUT 같은 폴더가 있었어요. 지속적인 증분 전달 및 버전 관리는 궁극적으로 이러한 구조에 도전했습니다.

멘탈 모델은 동일하게 유지되었습니다. 아직 "before"(연구 및 분석)이 있습니다. 우리 모두는 "during”(종종 프로세스로도 말함)을 알고 있습니다. 그리고 "after"(출시 및 출력)는 특정 결과를 달성하는 것을 목표로 합니다.

다음 단계

모든 독자를 위해 현재 폴더 구조를 살펴보고 다음 질문을 자문해 보십시오.

내 데이터는 어디에 있습니까?
– 하나 또는 여러 위치?
– 여러 개라면 그 이유는 무엇입니까?
– 필수인가요?
이 폴더들은 같은 구조를 공유합니까?
– 그렇다면 귀하(또는 귀하의 팀)가 쉽게 탐색할 수 있습니까?
– 다르다면? (그 뒤에 이유는 무엇입니까)
데이터를 정리하는 데 얼마나 많은 시간을 할애합니까?
– 절대 (필요하지 않은 데이터가 얼마나 많은지 스스로에게 물어보십시오.)
– 자주(얼마나 많은 시간을 투자하고 정보를 빠르게 찾아 얻는지)
데이터를 찾는 데 얼마나 많은 시간을 할애합니까?
– 귀하의 구조에서
– 다른 사람의 구조에서
– 다르다면? (왜?)
데이터의 수석 설계자라면 어떻게 하시겠습니까?
– 자신을 위해?
– 타인을 위해?

Design Token support in Figma

디쟈이너 — Tue, 27 Sep 2022 10:48:11 +0900

디자인 토큰을 서드파티가 아니라 퍼스트파티 기능으로 사용하구싶다..!

Design Tokens 훌륭한 플러그인!

하지만 디자인 토큰은 디자인 파운데이션을 전부 다 흔들어야하는 작업이라

플러그인이기 때문에, 피그마가 급격히 변화하기 때문에, 쉽게 손대기가 망설여지는 부분이다.

관련해서 피그마 커뮤니티에서 논의중인 토픽: Design Token support in Figma

Design Token support in Figma

We have been managing our design system(s) for Desktop, Mobile, and TV applications in Figma for some time now and the experience overall has been great (especially with the updated Auto-Layout model) but one thing that has been extremely difficult to mana

forum.figma.com

열망을 담아 투표했따..

피그마 컴포넌트 프로퍼티 베타 기능 - 중첩 컴포넌트의 속성 노출

디쟈이너 — Wed, 21 Sep 2022 13:45:05 +0900

SpaceOne의 디자인 시스템은 Figma를 적극적으로 활용하여 작업 효율성을 극대화시키고 있습니다.

Component에 properties 활용도가 굉장히 높은데, 활용성을 더 증가시키기 위한 중첩 컴포넌트를 만들 경우 컴포넌트 하위에 중첩되어있는 컴포넌트들에 설정된 프로퍼티 속성들에 접근하기 어렵다는 문제가 있었습니다.

이러한 문제점들을 감안하고라도 중첩 컴포넌트가 가진 장점을 포기할 수 없어 중첩 컴포넌트를 사용하고 있었는데,

피그마에서 이 중첩 컴포넌트를 상위 컴포넌트에서 제어할 수 있는 기능을 베타 런칭했습니다!

유저들은 간단한 설정만으로 베타 기능을 사용해볼 수 있습니다.

1. 베타로 지원하는 기능 사용하려면?

컴포넌트를 선택한 뒤 좌측 패널에서 설정 버튼을 클릭.

Component properties Beta에 Try mew authoring features 토글 버튼을 켜주면 새로운 베타 기능을 사용할 수 있도록 활성화됩니다.

2. 중첩 인스턴스 설정하기

중첩 인스턴스 노출 설정 (1) Expose properties from > Nested instances 클릭

컴포넌트를 선택한 후 오른쪽 패널에서 Properties의 + 기호를 클릭하면 우측에 드롭다운 메뉴가 뜹니다.

여기에서 Expose properties from > Netsted Instances 클릭!

중첩 인스턴스 노출 설정 (2) expose 할 중첩 컴포넌트 선택

노출 가능한 중첩 컴포넌트 목록이 보여지게되고,

이 중 노출할 항목을 체크해줍니다.

버튼 컴포넌트에 중첩시켜둔 base 컴포넌트가 보이네요.

중첩 컴포넌트 프로퍼티 노출 설정 완료!!!

따란~!

우측 패널 프로퍼티 영역의 아랫 부분에 중첩 컴포넌트의 프로퍼티가 노출되는것을 확인할 수 있습니다.

기존 중첩 컴포넌트와 컴포넌트 프로퍼티 기능을 활용하며 발생하던 문제점을 훌륭하게 해결해주네요!

베타 기능이기 땜에 눈 감아주는 소소한 오류 (minor error)

사용해보며 겪은 트러블 슈팅을 기록합니다.

- 복제된 Instance가 없는 컴포넌트에 '중첩 컴포넌트 노출' 설정을 할 경우, 제대로 작동하지 않음 (22.09.21)

참고 자료

개발자가 이미지를 추출하지 못하는 문제, 해결 방법

디쟈이너 — Thu, 16 Jun 2022 18:05:02 +0900

개발자 혹은 다른 작업자들에게 피그마 파일을 공유했는데, 그들이 이미지나 에셋을 추출하지 못한다고 할 때 두가지를 확인해야합니다.

1. 에셋에 Export 설정을 했는가?

2. 파일 자체에서 복사나 공유가 제한되어있지 않은가?

이 중에서 2번, "파일에서 복사 및 공유가 제한된 경우" 해결 방법을 알아봅니다.

파일 복사 및 공유가 제한되면 can edit 권한을 가진 작업자들의 Inspect 패널에 "Export disabled - This file's editor has disabled exporting, copying, and charing" 메시지가 뜹니다.

피그마야 시키지도 않았는데 익스포트를 잠궈버린거야?

이런 경우, 파일의 공유 설정이 제한되어있으니 설정에서 간단하게 해결할 수 있습니다.

파일 우측 상단의 share 버튼 클릭
팝업 오른쪽 하단에 있는 설정 아이콘 클릭
Allow viewers to copy, share, and export from this file 를 선택하여 설정을 토글

피그마 공유 옵션 설정하기

이렇게 can view 권한을 가진 사용자에게 copy, share, export를 허용하면 다음을 수행할 수 있는 권한을 갖게 됩니다.

캔버스에서 프레임, 레이어 또는 텍스트 복사
파일을 자신의 계정에 복제
파일에서 에셋 추출하기
.fig 파일로 로컬 사본 저장

참고 자료: Restrict copying and sharing on files

2022 Config에서 공개한 피그마 대규모 업데이트!

디쟈이너 — Wed, 18 May 2022 11:27:02 +0900

Dark mode, 다크 모드
피그마 데스크탑과 웹 모두 다크모드 지원. https://bit.ly/39bdarm
Redesigned auto layout, 오토 레이아웃 재설계 이제 오토 레이아웃이 더욱 강력하면서 훨씬 간편해졌습니다. 새로운 것들은 아래와 같아요. → Properties 패널 → 캔버스에서 바로 조작 가능 → Layout 옵션 (absolute position, negative spacing 등!)
https://bit.ly/3L0TfZk
Component properties, 컴포넌트 속성https://bit.ly/3N5TyUg
컴포넌트에 빌트인 텍스트, 부울린을 추가하거나 인스턴스 커스터마이징이 가능합니다. 디자인 시스템을 심플하게 만들고 개발에 전달하는 과정을 더 유연하게 가져갈 수 있어요.
Spotlight, 스팟라이트피그잼과 피그마 모두에 적용되었습니다.
https://bit.ly/39Rm6m2
피그마로 팀원들과 의견 나누다보면 꼭 ‘저 보고 계신가요?’ 확인하곤 했는데 이제 물을 필요가 없어졌습니다. 모든 사람이 같은 페이지를 볼 수 있도록 자신을 스팟라이트로 강조할 수 있어요.
피그잼에 jira, asana, github위젯이 추가 되었어요. https://www.figma.com/community/widgets
Variable fonts, 가변 글꼴https://www.figma.com/typography/variable-fonts/
글꼴의 두께, 너비 및 기타 사양을 더 많이 사용하여 반응형이고 접근성이 고려되었으며 재미있는 디자인을 만드십시오.
Spring animation→ 클릭하고 드래그하여 자신만의 스프링을 정의할 수 있는 옵션bit.ly/39JR8vT
→ 부드럽고 빠르며 탄력 있는 새로운 사전 설정
두 가지 새로운 업데이트로 프로토타입에 보다 자연스럽고 유동적인 전환 애니메이션을 만들 수 있습니다.
Individual strokes, 개별 스트로크
drop shadow로 선을 그리는것에 안녕을 합시다. 이제 부분 테두리를 적용하여 테이블, 리스트, 패널을 구성할 수 있습니다! https://bit.ly/398Co9R

더 자세한 내용은 https://www.figma.com/whats-new/ 에서 확인할 수 있습니다.

DesignOps에 대한 포켓 가이드

디쟈이너 — Sat, 30 Apr 2022 12:48:38 +0900

빠져드는 디자인 옵스.

이번에는 Rachel Posman의 A Pocket Guide to Design Operations 를 번역하고 읽어보았습니다.

다음은 Design Operations에 관심이 있거나 처음 접하는 사람들로부터 가장 많이 받는 질문 중 8가지에 대한 답변입니다.

1. 디자인옵스란?

“우리 제품에서 훌륭한 경험을 하고 싶다면 우리는 만드는 경험에 대해 기분이 좋아야 합니다.”

“If we want to make great experiences in our products, we have to feel great about the experience of making.” — Miles Orkin

디자인 운영 실무자는 제작 경험이 경험을 만드는 것만큼 중요하다는 것을 이해합니다.

디자인 작업은 디자인이 무엇 에 집중할 수 있도록 하는 방법 에 중점을 둡니다 . 디자인의 의도적인 운영, 최적화 및 확장을 소유하는 것은 디자인 분야입니다.

디자이너와 디자인 팀은 우리의 "사용자"이며 우리는 디자인 팀의 경험, 시스템, 프로세스, 도구 및 프레임워크를 설계하여 더 좋고 행복하며 효과적인 팀을 지원합니다. 우리는 사람, 프로젝트 및 프로세스의 전문가 오케스트레이션을 통해 규모에 맞게 디자인 조직의 영향과 효율성을 증폭합니다. 우리는 더 넓은 비즈니스 기능 사이의 중개자이며 HR, 법률, 조달 및 재무와 같은 파트너 그룹 간의 중요한 다리 역할을 합니다. 그리고 우리는 존경받는 디자인 리더의 동료, 생각하는 파트너 및 신뢰할 수 있는 전문가입니다.

"우리는 팀이 개인적 및 직업적 성장을 달성하면서 고객 및 비즈니스 성공을 제공할 수 있도록 하는 UX 조직 배후의 확장 엔진입니다." — Jason Kriese, 부사장 및 COO UXOps @ Salesforce

“We are the scaling engine behind the UX org that enables teams to deliver customer and business success while they achieve personal and professional growth.” — Jason Kriese, VP and COO UXOps @ Salesforce

2. DesignOps가 왜 중요한가요?

"팀이 일하는 방식은 그들이 만드는 것만큼이나 중요합니다." —크리스틴 스키너, 디자인 조직을 위한 조직 디자인의 공동 저자

디자인 운영, UX 운영, 디자인 프로그램 관리; 이름은 많지만 한 가지 확실한 것은 DesignOps는 디자인 조직의 성공에 매우 중요하다는 것입니다.

2017년 Design Ops Summit 의 Kristin Skinner 기조 연설에서 Kristin은 디자인 팀의 성장 단계와 디자인 운영이 어떻게 발전하는지 설명합니다. 그녀는 초기에 몇 명의 디자이너로 구성된 팀에서 한 명의 디자이너가 초기 프로세스와 표준을 만드는 작업을 지시할 수 있다고 지적합니다. 팀이 확장되고 디자인 팀에서 디자인 조직으로 이동함에 따라 디자인 책임자는 20명 이상의 직원을 관리해야 하는 운영상의 문제에 직면하게 됩니다. 이 수준의 조정은 복잡한 작업입니다. 운영 및 관리 프로세스와 시스템이 적절하지 않으면 디자인 팀은 자신의 기술에 집중할 수 없습니다. 그녀는 이것이 전담 DesignOps 직원이 필요한 시기와 이유라고 설명합니다.

“UX 운영은 우리가 하는 가장 전략적인 일 중 하나이지만 보이지 않습니다. 이것이 우리의 비밀 소스입니다.” — 저스틴 맥과이어, Salesforce 최고 디자인 책임자

모호한 문제를 해결하고, 진화하는 요구를 예상하고, 복잡한 조직의 변화하는 흐름을 탐색하고, 변화하는 기술, 문화 및 속도에 적응하는 솔루션을 만드는 데 경험이 있는 전략적 운영 리더 없이는 설계 조직을 효과적으로 확장할 수 없습니다. 디자이너는 또한 행복하고, 활력이 넘칠 때, 성취감을 느끼고, 지원을 받고 영감을 받을 때 더 나은 제품을 디자인합니다. Design Operations는 디자이너가 최선을 다할 수 있는 환경을 조성합니다. 우리는 디자인 조직의 비밀 소스입니다.

3. DesignOps의 일반적인 기술과 초능력은 무엇입니까?

DesignOps 실무자는 유니콘입니다. 사상가, 해결사, 행동가의 마법 같은 조합.

"DesignOps의 초강대국은 개인이 획기적인 작업(DEI 직면, 리더십 스타일, 팀 프로그래밍, 자신과의 관계, 다른 사람과의 관계 등)을 달성하기 위해 필요한 조건을 만들고 있습니다." — Lauren Peters, Salesforce Design 수석 이사

우리는 디자이너입니다. 우리는 디자인 팀을 위한 시스템, 프로세스, 조직 및 서비스를 디자인합니다.

우리는 점 커넥터: 우리는 관계 구축을 좋아하고 여러 팀과 분야 에 걸쳐 부서 간 환경에서 협업하는 데 성공 합니다.

우리는 디자인과 그것이 어떻게 완성되는지 "얻는" 것 입니다. 우리는 언어를 사용하고 언제, 왜 발생하는지, 어떤 자연적 종속성이 존재하는지, 위험을 완화하는 방법을 이해합니다. 우리는 매일을 확대 및 축소합니다. 우리는 큰 그림을 그리는 전략적 사고와 세부적인 전술적 사고 사이에서 유연하게 대처할 수 있는 능력이 있습니다.

우리는 좋은 커뮤니케이터입니다. 우리는 프로젝트 또는 프로그램에 대한 지지 및 팔로워십 확보의 복잡성을 이해하고 다양한 청중에게 커뮤니케이션을 맞춤화하는 방법을 알고 있습니다. 우리는 타고난 문제 해결사입니다. 우리는 복잡한 조직과 프로세스를 탐색하는 방법을 알고 있으며 탐정처럼 행동하여 솔루션을 찾거나 존재하지 않는 경우 솔루션을 만듭니다.

우리는 아이디어를 실행합니다. 우리는 실행 가능한 단계를 만들고 전달에 대한 명확한 경로를 조각함으로써 모호한 아이디어에 생명을 불어넣을 수 있습니다. 우리는 동원하고 운영합니다.

우리는 항상 듣고 있습니다. 우리는 조직의 펄스에 연결되어 있습니다. 우리는 디자인 팀이 필요로 하는 것과 팀이 디자인에서 필요로 하는 것을 듣습니다. 우리는 우리 산업을 형성하는 트렌드를 활용합니다.

우리는 지도자입니다. 우리는 프로젝트와 프로그램을 관리하고 디자인 리더십을 위한 전략적 우선 순위를 실행하는 데 참여합니다.

우리는 팀의 탐색을 돕습니다. 우리는 디자인 프로세스를 통해 팀을 이끌고, 사람들을 올바른 답변에 연결하고, 조직의 리소스를 최대한 활용할 수 있도록 돕습니다.

4. 정확히 무엇을 합니까?

“우리는 디자인 품질을 주도하고 배송을 개선하며 사람들의 기분을 더 좋게 만듭니다. 우리 작업은 완료해야 하는 작업이 무엇이든 같습니다." — 다이앤 큐, 디자인 운영 리더 @ Zendesk

우리가 하는 일은 우리 가 속한 디자인 팀의 필요와 성숙도에 따라 크게 좌우됩니다 . 다음은 설계 운영 역할의 광범위하고 다양한 책임의 예입니다.

Design Operations 실무자를 위한 광범위한 초점 영역의 예.

5. 누가 DesignOps를 수행합니까?

디자인 작업을 전담하는 사람이 없으면 디자인 팀의 어깨에 떠맡깁니다. 역할이 있든 없든 대부분의 작업을 수행해야 합니다.

디자인 작업에 대해 두 가지 방식으로 생각할 수 있습니다.

실습(Practice)으로서의 DesignOps
역할(Role)로서의 DesignOps

실습으로서의 DesignOps

직함이 없더라도 현재 역할에서 디자인 작업을 수행할 수 있고 이미 수행하고 있을 수 있습니다. 디자인 팀이 더 나은 피드백을 제공할 수 있도록 새 프로세스를 만들거나 디자인 팀에서 사용할 새 도구를 출시했을 수 있습니다. 이는 훌륭하며 팀 운영 방식을 개선하는 것의 가치를 볼 수 있음을 의미합니다. 설계 작업은 팀의 모든 사람이 수용할 수 있고 또 수용해야 합니다. 작업에 접근할 때 규모, 표준화, 협업 및 효율성과 같은 것을 생각하면 DesignOps를 하나의 관행으로 채택하게 될 것입니다.

역할로서의 DesignOps

DesignOps 기능은 한 사람 또는 전체 팀이 될 수 있습니다. 전담 직원이 위의 지도에 설명된 모든 작업을 수행하거나 일부 작업을 수행할 수 있습니다. 비즈니스의 성숙도, 전략 및 규모에 따라 매우 광범위하거나 더 집중된 범위를 가질 수 있습니다. 설계 작업은 실무자마다 매우 다르게 보일 수 있지만 우리 모두를 연결하는 스레드는 우수한 사용자 경험을 확장하고 고기능 팀을 지원하기 위해 설계 관행을 운영하고 최적화하는 데 전념하는 것입니다.

“Design Ops 직원의 힘은 팀에 합류하여 진행을 방해하는 요소의 핵심에 도달하기 위해 깊이 경청하고 조사하고 감지하는 능력입니다. 이것이 프로세스입니까? 사람들? 도구? 그런 다음 Design Ops 실무자는 자신의 방대한 기술 세트에 의존하여 도전 과제를 쉽게 진행할 수 있는 방법을 제시합니다.” - 알라나 워싱턴, 디자인 및 운영 리더 @ Uber Freight

6. 다양한 DesignOps 역할은 무엇입니까?

우리의 역할은 나란히 비교하면 매일 매우 다르게 보일 수 있습니다. 그 이유는 우리의 임무가 고유한 문제를 해결하고 우리 팀의 특정 요구 사항에 적응하는 것이기 때문입니다. 이를 위해 다양한 수준의 확대/축소 작업을 수행할 수도 있습니다.

“무엇을 채택하든(프로그램, 프로세스 등) 적응해야 합니다. DesignOps 리더인 우리는 변화하는 조직의 요구 사항에 적응하는 전문가입니다.”- Anel Muller, UXOps Leader @ Paypal

세 가지 수준에서 디자인 및 DesignOps 파트너십.

7. DesignOps는 조직 내에서 어떻게 적합합니까?

대답은 매우 상황에 따라 다르기 때문에 각 조직마다 다르지만, 그렇지 않은 경우가 더 많습니다. Design Ops는 디자인 조직 내에 있습니다. 다음은 디자인 운영 분야에서 제가 경험한 두 가지 조직 구조입니다.

중앙 집중식: 이 모델에서 모든 DesignOps 실무자는 단일 디자인 운영 리더로 롤업합니다.

분산 및 임베디드: 이 모델에서 DesignOps 실무자는 제품 디자인 팀과 긴밀하게 연계되어 해당 팀 내의 디자인 리더십에 직접 보고합니다.

8. 자세한 내용은 어디에서 확인할 수 있습니까?

다음은 설계 작업에 대한 몇 가지 훌륭한 리소스입니다.

Reading:

Team Ops and Product Ops: The Perfect DesignOps Pair by Rachel Posman and John Calhoun
How Design Ops Can Influence Your Culture by Jason Kriese
Org Design for Design Orgs by Kristin Skinner and Peter Merholtz
Nielsen Norman Group — Design Ops 101
Design Ops Handbook By Dave Malouf, Meredith Black, Collin Whitehead, Kate Battles, and Gregg Bernstein (editor)
Why the Future of Designer Productivity Starts with DesignOps by Meredith Black
Coming Soon: The Essential Guide to Design Operations, by Kristin Skinner

Listening/Watching:

NCommon Podcast by Jacqui Frey and Alison Rand
Making Good Trouble: DesignOps Summit co-curator Alana Washington
Rosenfeld Review Podcast by Louis Rosenfeld
Design Ops Podcast Playlist curated by Scott Stephens
Careers in Design Operations | UX Coffee Social with Lindsay & Rachel

Connecting:

More Design Ops Resource Lists:

DesignOps Assembly Resources
DesignOps Resources created by Angelos Arnis

에이전시 Frog가 말하는 DesignOps 101

디쟈이너 — Fri, 29 Apr 2022 18:42:19 +0900

디자인옵스 대체 뭐지? 빠져든다 싶어서 계속 번역해보는 디자인옵스란?ㅎㅎ

요약: 디자인에 대한 조직의 투자 가치를 증폭하는 데 도움이 되는 DesignOps 요소

디지털 붐의 많은 방법론과 마찬가지로 DesignOps는 "순간"을 보내고 있습니다.

디자인옵스가 무엇인가요?
DesignOps는 개인, 프로세스 및 도구의 오케스트레이션을 지원하여 창의성과 영향력을 대규모로 증폭하는 보다 강력한 디자인 팀을 구축하기 위한 인간 중심 접근 방식입니다. 민첩하고 반복적인 접근 방식으로 개발 프로세스를 혁신한 DevOps와 마찬가지로 DesignOps를 사용하면 조직이 팀 전체에서 설계 프로세스를 빠르게 확장하고 반복할 수 있습니다.

지금 DesignOps가 중요한 이유는 무엇입니까?
오늘날 조직은 보다 의미 있는 고객 관계를 만들고 성공 전략의 일부로 디자이너의 창의성, 공감 및 혁신의 가치를 이해하기 위해 디지털 경험의 중요성을 깨닫습니다. 이러한 조직은 세계를 변화시키는 속도와 규모로 움직이는 다른 리더의 성공을 모방하기 위해 대규모 디자인 기능을 구축하는 데 투자합니다. 조직은 종종 고용된 전략이나 특정 디자이너 때문이 아니라 팀이 조직적으로 성공할 수 있도록 설정되지 않았기 때문에 투자의 전체 가치를 실현하는 데 어려움을 겪습니다. 이것은 성공이나 혁신을 위해 조직을 활성화하기 위해 고객과 협력할 때 흔히 볼 수 있는 문제입니다.

이것이 DesignOps의 시발점이다. 외로운 늑대 천재 디자이너의 아이디어는 죽었습니다. 오늘날 디자인은 포괄적인 팀 스포츠입니다. DesignOps는 디자이너와 엔지니어링, 마케팅, 비즈니스 및 제품 관리자와 같은 파트너 간의 고성능 협업을 전체적으로 가능하게 하는 것입니다.

DesignOps의 다음 요소는 모든 디자인 팀의 가치를 증폭하고 확장하는 데 도움이 됩니다.

DesignOps의 목표는 조직의 고객 중심 비전에 맞춰 디자인 팀을 지원하는 것입니다.

DesignOps는 인간에 초점을 맞추는 것으로 시작합니다. 우리의 손님들. 디자이너가 고객에게 대응할 수 있는 도구와 프로세스와 미래를 내다볼 수 있는 권한이 있을 때 이러한 팀은 시간이 지남에 따라 깊은 고객 관계를 유지하는 의미 있는 비전을 제공합니다.
의미 있는 고객 경험은 고무와 도로가 만나는 곳입니다. 제품 및 서비스 디자이너는 조직 내 다양한 접점 및 상호 작용에 참여하는 여정 전반에 걸쳐 고객이 느끼는 방식을 지원합니다. 훌륭한 경험을 제공하는 것이 핵심입니다.

인풋은 디자인 팀이 조직에 대규모로 제공할 수 있도록 하여 목표를 효과적으로 달성할 수 있는 능력을 안내합니다.

목적은 디자인 팀이 존재하는 이유와 승리 방법을 보여줍니다. 디자인 팀이 성숙해짐에 따라 그 임무는 점점 더 총체적이고 전략적이 되어 조직에 더 큰 가치를 창출합니다.
인재는 디자인 팀의 핵심입니다. DesignOps는 긍정적인 직원 경험을 가능하게 하고, 최고의 인재를 유치 및 성장시킬 수 있는 조직의 능력을 결정하고, 목적에 부합하는 기능과 행동에 중점을 둡니다.
프로세스는 "사람을 팀으로 만드는" 핵심 의식입니다. 이러한 연결을 통해 이해 관계자, 팀, 관리 및 운영 전반에 걸쳐 정보가 흐르는 방식이 가능합니다. 그들은 사일로와 싸우고, 지식 공유를 촉진하고, 결정을 내리고, 성공을 정의하고, 피드백을 수집하고, 학습을 포착하고, 성공을 축하하기 위해 다른 방법으로는 발생하지 않을 수 있는 연결을 만듭니다. 프로세스는 최적의 결과를 위해 린(Lean), SCRUM, 애자일(Agile) 및 기타와 같은 방법을 언제 활용해야 하는지, 설계가 적절한 순간에 어떻게 그리고 언제 적합한지 결정하는 데 도움이 됩니다.
인에이블러는 작업을 가능하게 하는 도구 및 자산입니다. 인에이블러는 커뮤니케이션 도구, 협업 촉진, 검토 및 피드백 메커니즘에 중점을 두어 학습을 촉진하고 의사 결정에 정보를 제공하며 팀 효율성을 향상시킵니다. 엔지니어링 분야에서 설계와 협업자 간의 마찰 지점을 제거하여 설계자의 영향력을 증폭시키는 역동적이고 진화하는 클라우드 기반 협업 도구가 많이 있습니다.
구조는 결정이 내려지는 방식과 권력과 권위가 있는 위치를 결정합니다. 제품, 혁신, IT 또는 전체 조직과 같은 기능 팀 내에서 또는 전체 팀에서 설계가 작동하는 조직 구조를 결정합니다. 디자인은 전략적이든 전술적이든 문제와 필요에 맞는 고도에서 작동해야 합니다. 물리적 작업 환경은 또한 작업 흐름에 대한 강력한 신호를 보냅니다.

아웃 컴즈(결과)는 디자인 팀의 창의성이 목표를 달성하기 위해 활용되고 있다는 증거를 제공합니다.

문화는 디자이너가 조직에서 일할 때 어떻게 느끼는가에 관한것입니다. 의미 있는 문화는 직원들에게 자신의 기여가 전체 목적을 달성하는 방법에 대한 명확한 이해를 부여하고 프로세스, 도구 및 구조에 의해 권한을 부여받은 방식으로 기여할 수 있는 자율성과 기관을 제공합니다.
결과는 영향이 측정되고 비즈니스(ROI, 수익/지출 KPI, 고객 만족도/유지), 효율성(출시 시간, 작업 방식) 및 문화(영향, 직무 만족도)를 가로지르는 방법입니다. 우리는 좋은 경험의 모양과 느낌을 정의하는 일련의 디자인 표준을 만들고 이를 시장에 효과적으로 전달할 수 있는 수단을 갖추고 있습니다.

DesignOps는 특히 디자이너가 가능한 가장 의미 있는 작업을 수행할 수 있도록 하여 창의성과 전반적인 영향을 모두 강화하는 데 중점을 둡니다. 물론 모든 조직의 디자인 팀에는 목표와 성숙도가 고유하게 혼합되어 있습니다. 설계가 일상적인 작업 구조의 일부가 되도록 하려면 조직 전체에서 신중한 조정이 필요합니다. 고객이 DesignOps를 성공적으로 배포할 수 있도록 지원함으로써 고객이 지속 가능한 변화를 설계할 수 있도록 돕고 있습니다.

우리의 사명은 비즈니스를 대규모로 변화시키는 제품과 서비스를 만드는 것입니다. DesignOps는 고객이 조직에서 디자인의 힘을 발휘할 수 있도록 하는 데 핵심적인 역할을 했습니다.

출처: Frog Designops 101

Master 말고 Main

디쟈이너 — Thu, 28 Apr 2022 11:10:11 +0900

Github에서 새로 레파지토리를 생성하면 기존의 master 브랜치가 main 으로 변경된걸 볼 수 있다.
2년 전에 업데이트 된 거였지만 글로 정리해두지는 않았었는데, 오늘 Carbon의 Icon에 기여하기 위한 가이드를 읽다가 mater라는 용어를 발견했다

마.마스터 파일이요...? 카본, 알유 시리어스?

Carbon의 기초 아이콘들을 모아둔 파일이 업로드 되어있는데, 오랜만에 master라는 용어를 본 것 같아 묘한 기분이 들어 이렇게 글을 작성해본다.

깃허브가 master 대신 main을 사용한건 2년전 미국의 Black lives matter 운동에서부터 기인했다고 한다.

기존에 master 브랜치를 사용하고 있던 다양한 프로젝트에서 문제가 발생할 수 있지만

"While it takes time to make these changes now, it's a one-time engineering cost that will have lasting impacts, both internally and externally," Sorenson said in an email. "We're in this for the long game, and we know inclusive language is just as much about how we code and what we build as it is about person-to-person interactions."

소렌슨은 이메일에서 "지금은 이러한 변화를 만드는 데 시간이 걸리지만, 이는 내외적으로 지속적인 영향을 미칠 수 있는 일회성 엔지니어링 비용입니다"라고 말했다. "우리는 긴 게임을 위해 이 일을 하고 있고, 포용적인 언어는 우리가 어떻게 코딩하고 무엇을 만드는지에 대한 것과 사람과 사람 사이의 상호 작용에 관한 것만큼이나 중요하다는 것을 알고 있습니다."

멋있다. IT인으로서의 뽕과 윤리관이 되살아나는 기분이다.

관련된 논의로 더 살펴보면 좋은 아티클들을 첨부한다.

추가로,
Figma는 기본적으로 복제된 컴포넌트의 오리지널 컴포넌트로 master가 아닌 main을 사용하고 있다

Figma 짱. 킹왕짱.

DesignOps란? 시작부터 끝까지

디쟈이너 — Tue, 26 Apr 2022 12:52:47 +0900

요약: 디자인 운영(Design Operations)의 실무는 디자이너가 일관되고 품질 높은 디자인을 만들 수 있도록 지원하는 프로세스와 측정(조치)에 초점을 맞춥니다.

DesignOps란 무엇인가?

정의: DesignOps는 대규모로 디자인의 가치와 영향력을 증폭시키기 위해 구성원, 프로세스 및 기술의 조정 및 최적화를 의미합니다.

DesignOps는 다음과 같은 과제를 해결합니다.

성장하고 발전하는 디자인 팀
적절한 기술을 가진 사람들을 찾고 고용하는 것
효율적인 워크플로우 생성
디자인 결과의 품질과 영향 개선

DesignOps의 목표는 이러한 과제에 대해 확장 가능한 솔루션을 지원하는 프로세스와 조치를 수립해 디자이너가 디자인 및 리서치에 집중할 수 있도록 하는 것입니다.

모든 분야는 규모가 커짐에 따라 증가하는 관료주의와 커뮤니케이션 오버헤드를 완화하는 방법을 알아내야 합니다. 각 분야에는 고유한 솔루션이 있으며 designOps는 디자이너들의 솔루션입니다. 조직이 UX의 가치와 높은 ROI를 실현하고 UX팀에 직원과 책임을 신속하게 추가하기 시작함에 따라 우리는 종종 빠른 속도로 성장할 수 있습니다.

모든 UX 전문가에게 적용되는 DesignOps

“디자인"과 “디자이너"라는 포괄적 용어를 사용하지만, DesignOps는 문제를 해결하기 위해 사용자 중심의 디자인 사고 프로세스를 사용하는 모든 사람에게 적용됩니다. 따라서 “디자이너"라는 용어에는 UX디자이너, 리서쳐, 비주얼 디자이너, 콘텐츠 전략가, 서비스 디자이너, 커뮤니케이션 디자이너, 최종 사용자 경험에 기여하는 모든 사람을 포함합니다.

지금 DesignOps가 중요한 이유

디자이너들이 서로 및 다른 팀과 상호 작용하는 방식에서 변화가 일어나고 있으며 이러한 변화는 DesignOps의 필요성에 빛을 비추고 있습니다.

여러 면에서 디자이너는 "테이블에" 앉기 위한 싸움에서 승리했습니다. 점점 더 광범위하고 전략적인 대화에 참여하고 있으며 많은 조직에서 더 이상 디자인의 가치를 확인받을 필요가 없습니다. 그들은 디자인의 가치를 갖습니다 (Yay! 살아있음이 느껴지는 시간!)

불행히도, 이러한 인식은 종종 우리가 디자인 및 리서치라는 "일상 업무"와 함께 전략적 작업에 참여하는 추가 작업량을 관리해야 함을 의미합니다. 요컨대: 디자이너는 너무 바빠서 디자인할 수 없는 경우가 많습니다.

이러한 현실과 디자이너가 그 어느 때보다 복잡한 컨텍스트와 씨름하고 있다는 사실을 연결시켜 보십시오. 많은 조직에서 임베디드 제품 또는 프로젝트별 팀 모델을 채 함에ㅇ라 해 당팀에 흩어져 있는 디자이너 간의 연결성이 점점 부족해지고 있습니다. 우리가 디자인하는 제품과 경험은 계속해서 정교해지며 팀은 종종 여러 곳에 분산됩니다. 결과적으로 워크플로와 의사 결정이 점점 더 분산되고 있습니다.

빠르게 증가하는 디자인 복잡성을 관리하기 위해서는 디자인 프로세스에 자체 디자인 사고 및 사용자 중심 방법을 적용하여 디자인을 확장해야 합니다.

Design Operations(디자인 운영)의 구성 요소

DesignOps는 일관되고 고품질의 디자인을 가능하게 하는 것과 관련된 많은 요소가 있기 때문에 광범위한 주제입니다.

저는 DesignOps를 선별된 포트럭 디너(손님이나 그룹이 집에서 서로 만든 음식을 함께 차려 먹는 공동 모임)처럼 생각하는 것을 좋아합니다. DesignOps에는 많은 구성 요소가 있으며 조직이 선택하거나 전달할 항목은 현재 요구 사항과 해당 조직의 가장 고통스러운 문제에 따라 달라집니다. 따라서 DesignOps의 형태는 조직마다 매우 다르게 보일 것이며 또 그렇게 되어야 합니다. 또한 단일 조직 내에서 DesignOps의 초점은 시간이 지남에 따라 과제가 진화하거나 변경됨에 따라 바뀔 수 있습니다.

The DesignOps Menu

다음은 종합적인 DesignOps 메뉴입니다. 조직이 디자이너를 지원하기 위한 프로세스를 계획하고 구현할 때 집중하도록 선택할 수 있는 요소의 유니버스입니다. 세 가지 주요 영역이 있습니다.

우리가 함께 일하는 방법
작업을 완료하는 방법
우리의 작업이 영향력을 만드는 방법

DesignOps 메뉴는 조직이 3가지 주요 영역에서 DesignOps 노력을 집중할 위치를 계획하는 데 도움이 됩니다. 공동 작업 방법, 작업 완료 방법, 작업이 영향을 생성하는 방법.

우리가 함께 일하는 방법

DesignOps는 다음을 계획하는 데 도움이 됩니다.

구성(Organize): 팀을 어떻게 구성하고 올바른 팀을 구성할까여? 구성하기에는 다음이 포함될 수 있습니다.
- 디자인 팀을 위한 조직 구조 디자인
- 보완적이고 완벽한 기술을 갖춘 디자인 팀 만들기
- 개별 디자이너의 역할과 디자인 부서 전체의 역할 정의
협력(Collaborate): 효과적인 의사 소통을 가능하게 하는 환경과 모임을 어떻게 만들 수 있을까요? 협업 구성 요소에는 다음이 포함될 수 있습니다.
- 정기적인 의식과 회의를 위한 구조 정의
- 그룹 공간과 환경이 협업에 도움이 되도록 보장
- 기술 및 관심 공유를 위한 실천 커뮤니티 구축
인간화(Humanize): 고용, 온보딩 및 전문성 개발 관행이 직원을 인간처럼 먼저 대우하도록 하려면 어떻게 해야 할까요? 인간화에는 다음이 포함될 수 있습니다.
- 디자인 팀의 요구 사항에 맞는 인터뷰 방식 설계
- 새로운 팀원을 성공적으로 구성하기 위한 일관된 고용 및 온보딩 관행 수립
- 관리 및 비관리 역할 모두에 대한 투명한 경력 경로 표준화

작업을 완료하는 방법

DesignOps는 다음을 계획하는 데 도움이 됩니다.

표준화(Standardize): 일관된 도구 세트와 프로세스를 통해 어떻게 설계 품질을 촉진할까요? 표준화에는 다음이 포함될 수 있습니다.
- 시작부터 테스트, 전달에 이르기까지 높은 수준의 설계 프로세스를 문서화하고 최적화
- 디자인 프로세스 내에서 목적 있는 디자인 활동 정의 및 조정
- 효율적인 협업을 위해 동일한 디자인 도구의 사용을 감사하고 시행
조화(Harmonize): 어떻게 하면 디자인 인텔리전스를 공유하고 확장하여 모두가 동일한 이해를 바탕으로 작업하고 공통의 기반을 구축할 수 있을까요? 조화에는 다음이 포함될 수 있습니다.
- 디자이너의 효율성을 높이기 위해 디자인 시스템 확장 및 관리
- 모든 사람이 액세스할 수 있는 사용자 연구 데이터 저장소 구축
- DAMS(디지털 자산 관리자) 또는 기타 시스템을 사용하여 팀 구성원 간에 설계 자산 및 템플릿 공유
우선 순위 지정(Prioritize): 어떤 프로젝트에 착수할 것인지, 언제 착수할 것인지 어떻게 결정하나요? 우선 순위는 다음으로 구성될 수 있습니다.
- 디자인 워크플로의 병목 현상 발견 및 노출
- 프로젝트를 정확하게 예측하고 할당하기 위한 디자인 팀의 역량 이해
- 객관적이고 일관된 방법을 사용하여 기능 또는 프로젝트의 우선 순위 지정

우리의 작업이 영향력을 만드는 방법

마지막으로 DesignOps는 다음과 같은 방법에 대해 생각하는 데 도움이 될 수 있습니다.

측정(Mesure): 디자인 품질을 정의하고 측정하여 책임 있는 디자인을 만들려면 어떻게 해야 할까요? 측정에는 다음이 포함될 수 있습니다.
- 디자인 팀을 위한 "좋음(good)"과 "완료(done)"의 정의 만들기
- 디자인 품질에 대한 메트릭 선택 및 정렬, 시간 경과에 따른 해당 메트릭 추적
- 디자인 프로세스 전반에 걸쳐 디자인 원칙을 만들고 객관적인 수단으로 사용
사회화(Socialize): 디자인의 역할과 가치에 대해 다른 사람들을 어떻게 교육할까요? 사교 활동은 다음과 같이 구성될 수 있습니다.
- 디자인의 역할과 가치에 대한 일관된 메시지를 만들고 그 메시지를 디자인 파트너와 능동적으로 공유
- 사용자 중심 설계 프로세스의 성공 사례 캡처 및 공유
- 작업에 디자인 관행을 적용하는 팀을 인지하고 보상
활성화(Enable): 디자인 팀 외부의 사람들도 디자인 활동에 대한 이해와 사용성을 키울 수 있을까요? 활성화에는 다음이 포함될 수 있습니다.
- 디자인 도구 및 활동을 사용하는 방법에 대해 디자인 팀 외부의 사람들 교육
- 병목 현상 같은 디자인 팀 문제를 방지하기 위해 접근 가능한 디자인 활동 플레이북 만들기
- 스킬 교육을 실시하여 활동을 적절히 이해하고 사용할 수 있도록 보장

조직에 DesignOps 구성 요소 조정

한 사람이나 팀이 이 모든 구성 요소에 한 번에 집중하는 것은 불가능합니다. DesignOps 팀과 사상가(thinkers)는 특정 상황에서 특정 비중을 차지하는 영역을 인식하고 목표로 삼습니다.

DesignOps를 시작하기 전에 내부 조사(예: 리스닝 투어, 이해 관계자 인터뷰, 설문 조사)를 계획하여 가장 큰 문제점과 잠재적 ROI가 가장 높은 영역을 평가하고 시작합니다.

누가 DesignOps를 "수행"하는가?

누구나 DesignOps를 할 수 있습니다. 조직 내에서 접근 방식을 결정하는 데 도움이 되는 DesignOps에 대해 생각하는 데는 DesignOps 역할과 DesignOps 사고 방식이라는 두 가지 접근 방식이 있습니다.

역할로써의 DesignOps

DesignOps 역할은 디자인 팀이 디자인 또는 리서치에 집중할 수 있도록 지원하도록 하는 특정 사람 또는 사람들의 그룹이 있음을 의미합니다. 보다 성숙한 관행에서 일반적인 DesignOps 역할은 다음과 같습니다.

디자인 프로듀서 또는 UX 프로듀서: 프로젝트 수준의 디자인 작업에 관련된 사람들
디자인 프로그램 관리자 또는 UX 프로그램 관리자: 프로그램 또는 조직 수준의 디자인 작업을 담당하는 사람
ResearchOps 전문가: 참가자 소싱 및 선별, 연구 요청 파이프라인 감독, 연구 저장소 유지 관리, 연구 도구, 공간 및 장비 관리와 같은 사용자 연구의 운영 측면을 책임지는 사람들

모든 조직에 DesignOps 역할이 필요한 것은 아닙니다. 매우 큰 팀, 포함된 팀 또는 일정이 짧고 움직이는 부분이 많은 대행사에는 다른 유형의 팀보다 먼저 DesignOps 역할이 필요할 수 있습니다.

마인드셋으로써의 DesignOps

그러나 모든 팀은 DesignOps Mindset의 혜택을 누릴 수 있습니다. 이는 단순히 생태계에서의 필요성을 인식하고 구현하거나 디자인을 지원하고 효율적으로 확장할 수 있는 표준화된 프로세스, 방법 및 도구의 집합을 의미합니다. 효율성을 높이고 아웃풋을 개선하기 위해 현재 프로세스를 관찰하는 데 DesignOps의 명시적 역할이 필요하지 않습니다.

DesignOps에 대한 요청

DesignOps는 디자인 조직을 하나로 묶는 접착제이자 여러 분야를 아우르는 팀원들의 협업을 가능하게 하는 다리입니다.

디자인 팀의 규모가 계속 커지고 UX 작업이 빠르게 요청되고, 디자인 팀 구성원이 계속 분산되고, 디자인 프로세스의 복잡성이 급증하는 환경에서 DesignOps는 나중에 생각할 수 없습니다.

우리가 함께 일하는 방법, 작업을 완료하는 방법, 작업이 영향을 미치는 방법은 의도적이고 지능적으로 만들어져야 합니다.

DesignOps 101을 읽고 번역한 글입니다. 오역에 대한 피드백 언제든지 환영합니다!

디자인옵스(DesignOps): 일반적인 팀 구조 5가지

디쟈이너 — Sat, 23 Apr 2022 21:45:23 +0900

요약: DesignOps 팀의 구조는 팀의 특정 과제와 요구로부터 출발해야 합니다. 이러한 팀 구조는 DesignOps 팀을 지원할 수 있는 다양한 접근 방식을 보여줍니다.

DesignOps는 일관되고 품질 높은 디자인을 가능하게 하는 것과 관련된 많은 요소들이 있기 때문에 광대한 기회를 가지고 있습니다. 조직이 DesignOps 실무에서 중점을 두는 것은 해당 조직의 요구와 목표가 반영된 것이어야 하며, 또한 DesignOps 팀이나 역할에 대한 해당 실무 구조도 반영해야 합니다.
이 기사에서는 DesignOps 팀의 일반적인 5가지 유형의 구조에 대해 설명합니다. 적합한 구조는 회사마다 정형화된 DesignOps 프로그램에 대한 전반적인 조직 구조, 목표 및 요구 수준에 따라 달라지며, 따라서 어디에나 잘 맞는 최고의 구조는 없습니다. 이러한 구조는 DesignOps 성숙도 모델에서 필수적이거나 점진적인 단계가 아니라 서로 다른 상황에 적합한 잠재적 모델로 보아야한다. 일부 조직은 확장됨에 따라 이러한 구조 변화를 자연스럽게 경험할 수 있지만, 팀은 적절한 지원과 리소스를 제공하는 구조 이외의 다른 구조를 목표로 할 필요가 없다.
일반적인 5개 유형의 DesignOps 구조:

Scattered(산발형): DesignOps의 노력은 일상적인 업무 책임의 일부로 다른 역할(예, 디자인 매니저)에 의해 수행된다. 조직 내에서 “DesignOps”는 용어로 사용되지 않고 형식화 된 개념으로 알려지지 않았을 가능성이 큼
Solitary(단독형): 1명으로 구성된 DesignOps 팀. 이 전담 DesignOps 역할은 초기에 반응적인 방식으로 디자인 팀의 가장 큰 문제점을 식별하고 프로그램을 개발
Specialized(전문형): 풀 타임으로 DesignOps의 특정 측면을 관리하거나 감독하는 소수의 사람들로 나뉘어진 형태
Distributed(분산형): 팀 간 조정에 중점을 두고 조직 전체에 걸쳐 개별 팀에 분산되어 있는 형태
Elevated(향상형): 전체 디자인 조직에 영향을 미치고 혜택을 주는 중앙 집중식 리소스와 프로그램을 제공하여 별도의 독립체로 확장된 형태

Type 1: Scattered(산발형)

DesignOps가 흩어져 있으면 많은 사람들이 DesignOps와 관련된 활동을 하지만 공식적인 관행이나 직함이 존재하지 않습니다. 많은 조직에서 “DesignOps”라는 용어를 들어본 적이 없거나 설명하는 내용을 이해하는 사람이 아무도 없을 것입니다. “DesignOps”라는 용어는 확실히 모든 조직에서 일상적으로 사용하는 용어가 아니며 대부분의 조직에는 정형화된 DesignOps역할 (즉, DesignOps에 전담하는 직원들)이 없습니다. (실제로 조사에 따르면 DesignOps의 리드 또는 매니저가 있는 팀은 13%에 불과했습니다.)
그러나 공식화된 DesignOps 관행과 역할이 없는 조직에서도 여전히 디자인 팀 및 프로세스와 관련된 운영상의 문제를 파악하고 해결하려는 사람들이 있습니다. 아마 그렇게 레이블을 붙이지 않아도 공식적으로 인정된 다른 직무와 함께 DesignOps 유형의 작업을 수행하는 상급 수준의 디자이너, 리드 및 관리자가 있을 수 있습니다.

산발형 구조에는 공식적인 DesignOps 역할이 없습니다. 디자인 팀 구성원은 디자인 책임과 함께 필요한 운영 작업을 수행합니다.

이 산발형 구조는 조직 전반에 걸쳐 DesignOps 성숙도가 낮다면 널리 퍼질 가능성이 있습니다. 557명의 UX 전문가를 대상으로 조직의 DesignOps 성숙도 수준을 조사했을 때, 응답자의 10%만이 팀 전반에 걸쳐 DesignOps에 대한 폭넓은 이해가 있거나 회사 문화 내에서 DesignOps의 가치가 확립되었다고 보고했습니다.

산발형 구조의 실천 아이디어

공식화된 DesignOps가 없다는 것은 전반적인 UX 성숙도가 낮음을 나타낼 수 있습니다. 확실히, UX의 가치를 인정하지 않거나 전반적인 UX 관행을 지원하지 않는 회사는 공식화된 DesignOps 관행을 지원하지 않거나 전담 DesignOps 전문가를 고용하지 않을 것입니다. 이러한 경우 디자인 책임자와 관리자는 운영상의 문제를 해결하고 디자인 작업을 하기 위해 시간과 자원을 허비하며, 이러한 노력에 대한 인식 없이 스스로에게 추가적인 부담을 주는 경우가 많습니다
산발형 DesignOps 구조는 DesignOps를 이해하고 가치를 알고 있는 구조에도 존재할 수 있습니다. DesignOps 여정의 초기에 있는 경우, 전담 DesignOps 역할에 대한 리소스가 없을 수도 있습니다. 이러한 역할이 널리 요구되는 경우에도 마찬가지입니다. 이러한 상황에서 팀은 작업 설명에 운영 관련 책임과 기존 디자인 역할의 책임을 포함하기로 결정할 수 있습니다. 예를 들어 디자인 매니저는 팀을 위한 방법론을 작성할 수 있는 권한과 리소스를 받을 수 있습니다. 또는 대표 디자이너로 구성된 위원회가 디자인 시스템 생성, 디자인 프로세스 문서화 또는 UX 회의 체계화와 같은 특정 DesignOps 과제를 수행할 수 있습니다.

산발형 구조의 도전 과제와 이점

통합된 DesignOps 구조가 없는 개별 팀은 도구와 방법을 자율적으로 선택하는 이점이 있지만 가장 큰 문제는 종종 일관성이 부족할 수 있다는 것입니다. 개별 팀이 정렬되지 않으면 프로세스, 방법 및 도구 스택이 광범위하게 변형되어 협업, 통찰력 및 템플릿 공유, 중복 작업 방지를 어렵게 할 수 있습니다.

Type 2: Solitary(단독형)

단독형 구조에서는 한 사람이 DesignOps에 풀타임으로 전념할 수 있독 인정과 권한을 부여받습니다. 이 사람은 종종 DesignOps 책임자, DesignOps 관리자와 같은 직함을 가지고 있으며 DesignOps 창의 끝이 되어 미지의 영역을 통해 길을 개척하고 팀을 DesignOps 개척지로 이끄는 역할을 합니다.
이 DesignOps 팀은 일반적으로 필요에 따른 피해 통제에 중점을 두고 운영 부채의 잔고를 파악하고 가장 명백한 문제점을 한 번에 하나씩 해결합니다. 이 역할은 여러 설계자 또는 설계 팀에서 작동하여 가장 큰 운영상의 문제를 식별하고 모든 팀에 도움이 되는 일관성과 표준을 개발합니다.

단독형 구조에서 전담 DesignOps 역할이 등장하여 여러 디자이너 또는 소규모 팀을 지원합니다.

종종 이 역할은 두 가지 주요 책임으로 나뉩니다. 디자인팀 연결, 팀 전체의 문제를 경청하고 종합하는 부분과 고충을 완화하고 디자이너를 더 잘 지원하는 접근 방식과 프로세스를 설계하는 부분입니다.

단독형 구조의 실천 아이디어

단독형 구조는 시간순으로 산발형 구조에서부터 오는 경우가 많습니다. 왜냐하면 결국 산발형 구조의 누군가가 개별 디자이너나 팀 전체의 불일치와 비효율성을 인식하고 이 문제를 해결하기 위해 모두 모여야한다는걸 제기하기 때문입니다.
규모가 2배 또는 3배로 빠르게 확장되는 작은 팀(디자이너 10명 미만)의 경우 기존 디자이너는 성장하는 팀 전체에서 프로세스와 협업을 유지하기가 점점 어려워지고 있음을 인식할 수 있습니다. 이 사람은 고통을 직접 느끼고 이러한 운영 문제를 해결하기 위해 경영진에게 사례를 제시하여 최초의 공식화된 DesignOps 역할을 만듭니다.
또는 회사가 일반적으로 잘 조정된 여러 팀에서 비교적 높은 수준의 UX 성숙도를 가지고 있다면, 경영진은 공식화된 DesignOps의 필요성을 사전에 인식하고 노련한 DesignOps 전문가를 불러들여 조직에서 DesignOps를 "설립"할 수 있습니다.

단독형 구조의 도전과제와 이점

단독형 구조에서 DesignOps는 공식적으로 인정받고 있습니다. 디자인 프로세스를 최적화하고 적어도 한 사람이 이 작업을 풀타임으로 맡을 수 있도록 하기 위해 일정 수준의 공식적인 승인과 동의가 있습니다. 그러나 이 사람은 해결해야 할 과도한 운영상의 문제와 이를 수행하는 데 필요한 많은 활동(예: 장애물 식별, 로드맵 활동, 추적을 위한 노력, 피드백 수집, 진화하려는 노력)에 빠르게 압도당할 수 있습니다. 이런 부하는 기존 디자이너가 풀타임으로DesignOps에 집중하기 전에 이것의 성공을 입증해야 하는 경우 악화됩니다.
게다가 이 새로운 역할은 불안정한 위치에 있습니다. 그들은 DesignOps 옹호하고 전파하려는 노력을 수행하며 이해 관계자와 변화를 수용하지 않으려는 다른 디자이너들의 저항에 직면할 수 있습니다. 단독형 구조에서 프로세스를 설계하고 적용하려는 DesignOps 전문가는 디자이너 시스템에서 거부되기 쉽기 때문에 경청 및 관계 구축 기술(이전 디자인 역할에서 온 사람에게는 더 쉬움)이 중요합니다.

Type 3: Specialized

전문형 DesignOps 구조에는 각각 특정 프로그램이나 전문 영역에 중점을 둔 여러 개의(제한된) 전용 DesignOps 역할이 있습니다. 모든 종류의 DesignOps 과제(예: 단독형 구조)를 식별하고 해결하는 데 중점을 두는 단일 DesignOps 제너럴리스트가 아니라 전문화되어 있습니다.
이 구조 내의 개별 DesignOps 전문가는 각자의 전문 지식 및 기술 영역에 맞춰진 운영상의 문제와 솔루션에 중점을 두지만, 서로 긴밀하게 협력하여 디자이너를 지원하기 위해 마련된 운영 프로그램이 상호 보완적이고 조정될 수 있도록 협력합니다.

전문형 구조에는 각자의 포커싱 영역이 있는 DesignOps 역할이 있습니다.

이 구조 내에서 DesignOps의 역할은 전문화된 필요 영역이 분명해진 후에 생성되며 종종 단독형 구조에서 과중한 역할을 완화하여 각 사람이 가장 동기 부여를 받고 가장 잘 알고 있는 영역에 집중할 수 있도록 합니다.

전문형 구조에서의 실행 아이디어

DesignOps가 추진력을 얻고 시간이 지남에 따라 어느 정도 측정 가능한 성공을 입증함에 따라 단일 역할이 처리하기에는 너무 많아질 수 있습니다. 한 명의 슈퍼휴먼이 DesignOps의 여러 영역을 장기적으로, 전문적으로 관리할 수 있다고 해도 다루어야 하는 DesignOps의 모든 잠재적 영역에 관심이 없거나 능숙하지 않을 수도 있습니다.
DesignOps 팀이 초기 DesignOps 노력을 성공적으로 마친다면 종종 추가 DesignOps 역할에 대한 동의를 얻을 수 있습니다. 여기에서 DesignOps 팀은 가장 영향력 있는 것으로 입증된 DesignOps의 특정 프로그램 또는 전문적인 측면에 집중할 수 있는 추가 전담 역할(시작할 사람이 한두 명일 수도 있음)을 추가하여 확장하게 됩니다.
예를 들어, 새롭게 부상하는 소규모 전문 구조에는 3명의 DesignOps 전문가가 있을 수 있습니다. 하나는 고용 및 온보딩과 같은 PeopleOps 이니셔티브에 집중하고, 다른 하나는 디자인 워크플로 최적화에 집중하고, 다른 하나는 도구 큐레이션, 라이선스 및 도구 온보딩에 중점을 둡니다.

전문형 구조의 도전 과제와 이점

전문형 구조에서 개별 DesignOps 전문가는 특정 작업 흐름에 집중하여 디자인 조직의 장기적 성공에 중요한 것으로 확인된 영역에 전념할 수 있습니다. 그러나 이러한 역할 간의 강력한 정렬이 없으면 DesignOps는 단편화될 것입니다.
또한, 성장하는 DesignOps 팀은 다른 사람들이 자신의 역할을 이해하도록 알리는 책임을 게을리해서는 안 됩니다. DesignOps가 제공하는 차별화된 가치에 대해 명확하게 제공해야 합니다. 또한 조직 내 다른 운영 역할(예: PeopleOps, MarketingOps, DevOps, BusinessOps 등)과 파트너십을 구축하여 모든 사람이 자신의 노력, 목표 및 커뮤니케이션에 동기화되도록 시간과 노력을 투자해야 합니다.

Type 4: Distributed(분산형)

분산형 구조에서 DesignOps 전문가는 조직 전체의 개별 디자인 팀에 전담적인 지원을 제공합니다. 이러한 DesignOps 역할은 그들이 지원하는 개별 팀의 일부이며 워크플로 관리, 디자인 목표 설정, 프로젝트 궤적 모니터링 또는 로드맵 작성과 같은 영역을 수행할 수 있습니다.

분산형 구조에서 DesignOps 역할은 DesignOps 지원이 필요하고 원하는 개별 팀 또는 영역을 전담합니다.

이상적으로는 이러한 DesignOps 역할이 함께 작동하여 전체 전략과 커뮤니케이션이 모든 팀에서 동기화됩니다. 모든 분산된 팀 구조와 마찬가지로 분산된 팀 구성원이 서로 공유하고 협업할 수 있는 시간을 제공하는 접점(예: 회의)이 설정되어야 합니다.

분산형 구조의 실천 아이디어

이 구조는 높은 수준의 확장을 경험하거나 팀이 널리 분산되어 있는 디자인 팀에 일반적입니다. 디자인 팀의 규모가 계속 커지면서 단 하나(또는 제한된 수)의 DesignOps 역할이 변화하는 요구와 과제를 따라잡기가 어려워질 수 있습니다. DesignOps는 디자인 조직의 상태를 더 잘 모니터링하고 최적화하기 위해 더 많이 실무에 발을 붙이고 있어야할 필요가 있습니다. 이 경우 전담 디자인 제작자 또는 디자인 프로그램 관리자가 일상적인 디 자인장프로로에서 장애물을 제거하는 데 도움을 줄 수 있습니다.
DesignOps을 전담하는 역할은 일반적으로 제너럴리스트이지만 항상 그런 것은 아닙니다. 예를 들어 빠르게 성장하는 팀은 전담 채용 및 온보딩에 전담하는 역할을 고용할 수도 있습니다.

분산형 구조의 도전 과제와 이점

이 접근 방식은 유연하며 모든 팀이 DesignOps의 지원을 받을지 여부를 선택할 수 있기 때문에 팀이 DesignOps에 대한 다양한 수준의 요구사항이나 수용 수준을 가지고 있는 조직에서 잘 작동합니다. 따라서 아직 그러한 역할의 필요성을 인식하지 못하는 팀에 "강제"할 수 없습니다.
추가로, 전담 DesignOps 지원을 통해 개별 팀의 요구 사항과 피드백을 더 잘 이해할 수 있습니다. DesignOps 역할이 전체 디자인의 정렬을 만들기 위한 건전한 구조를 가지고 있는 경우, 분산된 팀은 지식을 공유하고 일관된 프로세스를 가질 가능성이 높습니다.
그러나 전담 DesignOps 역할이 어디에 초점을 맞춰야 하는지 알기 어려울 수 있습니다. 개별 팀 프로젝트를 지원하는 데 더 많은 노력을 기울여야 하는가, 전반적인 UX 프로그램 및 프로세스를 최적화하는 데 더 많은 노력을 기울여야 하는가? 이 시점에서 전반적인 전략과 접근 방식을 주도하고 이 분산된 팀을 조정하기 위해 강력한 DesignOps 리더십이 필요합니다.

Type 5: Elevated

향상형 구조에서 DesignOps는 그 자체로 전체 디자인 조직을 지원하는 고급 도구와 프로그램을 만드는 데 중점을 둔 조직입니다.
여기에서 DesignOps와 디자인은 별개의 팀이지만 서로 일치된 구조와 목표가 있습니다. 이 구조는 팀 간 정렬이 최적화되고 안정화되어 일부 DesignOps 역할이 보다 전략적으로 될 수 있도록 할 때 발생합니다. 이 접근 방식에서 DesignOps의 역할은 글로벌 이니셔티브에 초점을 맞추는 경향이 있으며 디자인 팀과 해당 프로세스를 사전에 활성화하는 디자인 전반의 리소스를 생성하며 일상적인 디자인 활동 및 프로젝트 일정에서 더 많이 제거됩니다.

상위 구조에서 DesignOps는 자체 독립체로서 전체 디자인 조직에 중앙 집중식 도구와 리소스를 제공합니다.

이 구조에서 DesignOps는 조직 내 다른 부서의 리더십 역할과 유사한 역할을 가진 강력한 리더십이 필요합니다. DesignOps는 전략 수립의 일부이며 최고의 디자인을 제공하고 건강한 팀과 문화를 유지하기 위한 중요한 구성 요소로 간주됩니다.

향상형 구조의 실천 아이디어

일부 고급 DesignOps 팀은 개별 디자이너의 작업에서 공유 시스템(예: 디자인 시스템 또는 리서치 저장소)을 만들고 유지 관리하는 부담을 제거하도록 돕습니다. 이러한 DesignOps 팀에는 공유 시스템에서 풀타임으로 작업하는 자체 디자이너와 개발자가 있을 수도 있습니다.
중앙 집중식 DesignOps 팀에는 분산형 구조가 수반될 수 있습니다. 여기서 DesignOps 역할의 한 그룹은 개별 팀에 직접 전담되고 한 그룹은 문화 구축, 신신규 고용 경험 또는 커리어 패스웨이에 중점을둔 중앙 집중식입니다.

향상형 구조의 도전 과제와 이점

전담팀 구성원이 중앙 집중식 도구 및 프로그램에 대해 풀타임으로 작업하므로 이러한 이니셔티브는 유용하고 액세스 가능하도록 적절한 주의를 기울이고 디자이너는 이중 책임에 의해 방해받지 않고 디자인 작업에 집중할 수 있습니다. 그러나 DesignOps 팀은 계속해서 디자인 팀 피드백을 수집하고 이에 따라 조치를 취해야 합니다. 그렇지 않으면 관련이 없거나 쓸모없는 프로세스와 도구가 위에서 아래로 강요된다고 느끼는 팀이 경멸하게될 위험이 있습니다.
이 접근 방식에는 이니셔티브의 우선 순위를 지정하고 시간이 지남에 따라 DesignOps를 확장할 계획을 세우는 강력한 리더십이 필요합니다. 일부 역할은 DesignOps 목표에 대한 진행 상황을 평가하고, 비즈니스 요구 사항이 변경됨에 따라 DesignOps의 초점 영역을 발전시키고, 조직의 다른 부서와 평행하도록 DesignOps 리더십 및 영향력을 높이는 것과 같은 프로그램을 만드는 것에 대해 생각해야 합니다.

결론

조직에서 사용하는 DesignOps 구조를 인식하면 강점을 식별하고 기존의 성공적인 프로그램 및 노력을 기반으로 잠재적인 위험을 인식하는 데 도움이 됩니다. 또한 계속해서 수요와 규모가 확장됨에 따라 DesignOps 구조의 발전을 계획할 수 있습니다.
이러한 구조를 참조할 때 다음 사항에 유의하십시오.

이 목록은 완전하지 않습니다. 이것은 일반적인 DesignOps 구조의 집합이지만 포함되지 않은 다른 모델은 디자인 팀을 성공적으로 지원할 수 있습니다. 또한, 두 개 이상의 모델의 하이브리드가 존재하는 것이 합리적이고 일반적입니다.
이러한 구조는 성숙도 모델이 아닙니다. 이러한 DesignOps 구조는 DesignOps 성숙도와 반드시 일치하지는 않습니다. 일부 팀의 경우 DesignOps의 전담 역할(즉, 단독형 구조)이 적절한 수준의 지원입니다. 따라서 높은 구조가 없다고 해서 DesignOps 관행이 성숙하지 않은 것은 아닙니다. 구조는 현재 및 가까운 미래의 조직 요구 사항을 기반으로 해야 합니다.
모든 케이스를 커버하는 최고의 구조는 없습니다. 여기에는 옳고 그름이 없습니다. 조직마다 상황과 필요에 따라 다른 구조를 사용합니다.

DesignOps: 5 Common Team Structures 를 학습하기 위해 번역하여 옮긴 글입니다. 오역이 있다면 언제든지 피드백 환영합니다.

프레이머 Site 튜토리얼

디쟈이너 — Tue, 19 Apr 2022 15:37:17 +0900

Framer Sites: Get Started

Framer Login

프레이머 로그인시 Tool 내에서 직접 영상을 보며 실습을 진행할 수 있다.

override와 overwrite의 차이

디쟈이너 — Wed, 6 Apr 2022 20:51:12 +0900

사전적 정의

overwrite[│oʊvərraɪt]
(3인칭 단수 현재 : overwrites)
동사
1.중복 기재하다, 겹쳐 쓰다

혹은 덮어쓰기

override[│oʊvərraɪd]override
(3인칭 단수 현재 : overrides)
동사
1.(직권을 이용하여 결정·명령 등을) 기각[무시]하다 (=overrule)
2.…보다 더 중요하다[우선하다]
3.(자동으로 진행되는 과정을) 중단시키다

혹은 재정의

overriding[│oʊvərraɪdɪŋ]
형용사
1.다른 무엇보다 더 중요한, 최우선시 되는
the overriding factor/consideration/concern
다른 무엇보다 더 중요한 요소/고려 사항/우려 사항

한 구현을 다른 구현으로 완전히 교체하는 경우 이는 "overwriting" 또는 더 일반적으로 "replacing"을 사용합니다.

일부 특정 사례에 대해 구현을 다른 구현으로 교체하는 경우 이는 "overriding"입니다.

어떤 것을 "overwrite" 하는 것은 다른 것을 제자리에 놓고, 오버라이트된 것을 파괴하는 것입니다.

어떤 것을 "override"하는 것은 오버라이드된 것을 해치거나 변경하지 않고 다른 것이 대신 작동하도록 하는 것입니다.

override는 언어 영역에만 국한되지 않습니다.

override는 일부 이전 작업 또는 결정을 대체하는 것이며, overwrite는 이전에 작성된 내용을 덮어쓰는 것을 의미합니다.

직접적인 예로 dictionary.com에서

"overwrite"는 데이터를 파괴하고 그 자리에 새 데이터를 추가합니다.

"override"는 다른 사람의 권한으로 거부, 취소, 결정 할 수 있습니다.

간단하게 이야기하면,

- 행동과 결정은 재정의(Override) 됩니다.

- 정보는 덮어씁니다.(Overwritten)

Notion 단축키

디쟈이너 — Tue, 5 Apr 2022 16:45:11 +0900

노션을 사용하면서 마크다운 기본 문법과 / 만 활용했는데 생각보다 훨씬 더 다양하고 많은 단축키가 있어 정리해봅니다.
(사실 빠르게 quote 만들고 싶은데 클릭 -> 선택 하는게 너무 귀찮아서 찾아봄...)

마크다운 스타일

입력 하면서 사용:

**: 텍스트 양 옆에 작성하면 굵게(bold) 처리 됩니다.
*: 텍스트 양 옆에 작성하면 기울임꼴 처리 됩니다.
```: 텍스트 양 옆에 작성하면 인라인 코드처리 됩니다. (보통 숫자 "1"키 옆에 있습니다.)
~: 텍스트 양 옆에 작성하면 ~~취소선~~ 처리 됩니다.

새로운 컨텐츠를 입력하기 전에 사용:

*, -또는 + 를 입력하고 space 를 입력하면 불릿 리스트를 만들 수 있습니다.
[] 를 입력하면 체크박스를 만들 수 있습니다. (대괄호 사이에 space가 있으면 안됩니다.)
1., a. 또는 i. 를 입력하고 space 입력 시 순차 리스트를 만들 수 있습니다.
# 를 입력하고 space 입력 시 H1 형식을 입력할 수 있습니다.
## 를 입력하고 space 입력 시 H2 형식을 입력할 수 있습니다.
> 를 입력하고 space 입력 시 토글 블록을 만들 수 있습니다.
" 입력하고 space 입력 시 인용구를 만들 수 있습니다.

참고 자료: Notion - Keyboard shortcuts

content-to-chrome 비율 극대화 하기

디쟈이너 — Fri, 21 Jan 2022 20:07:40 +0900

수직 네비게이션에 대한 아티클을 읽다가 도무지 content-to-chrome 이라는 문구가 이해되지 않아 이 내용을 상세히 기술한 아티클에 도전한다.

들어가기 전, Chrome. 크롬이 도대체 무엇인가를 먼저 정의해야겠다.

Chrome is the visual design elements that give users information about or commands to operate on the screen's content (as opposed to being part of that content). These design elements are provided by the underlying system — whether it be an operating system, a website, or an application — and surround the user's data.

Nielsen Norman

즉, 여기서 말하는 ‘크롬’이라는것은 브라우저가 아니다. 사용자에게 화면 콘텐츠에 대한 정보나 명령을 제공하는 시각 디자인 요소다. 이러한 디자인 요소는 응용프로그램이나 사이트의 기본 시스템에 의해 제공되며 사용자의 데이터를 둘러싸고 있는것이라는 이야기!

An Event Apart: Content First 라는 아티클도 매우 훌륭하다고 하니 추후 읽어봐야쥥

다만 아래 아티클은 2014년에 작성되었다는것을 유의하는것이 좋다. 그러나 대부분의 UX 법칙들이 그러하듯 세월이 지나도 유의미해보인다.

TL;DR: 큰 화면에서 크롬을 숨기면 콘텐츠 대 크롬 비율이 거의 개선되지 않고 검색 가능성과 상호 작용 비용에 큰 영향을 미친다.

독자중 한 명이 최근의 트렌드를 “끔찍한 메뉴 없는 윈도우”라며, 자동차와 비교해 “대시보드의 기능이 모두 글로브박스 칸에 숨겨져 있다” 고 불평하는 메시지를 보냈다.

파이어폭스의 햄버거 메뉴는 일반 메뉴 옵션을 모두 숨기고 창 상단에 있는 기존 메뉴바를 대체한다.

햄버거 메뉴는 크롬(버튼, 메뉴, 기타 위젯과 같은 UI요소)을 바탕화면에 적게 표시하는 현재 트렌드로 발현됐다. 우리가 최근 홈페이지를 분석한 결과, 크롬과 내비게이션은 12년 전에 비해 홈페이지 점유율이 낮아진 것으로 나타났다.

이러한 안티크롬 운동 뒤에는 크롬보다 콘텐츠를 우선시해야 한다는 모바일에서 영감 받은 가정이 자리하고 있다. 물론, 사용자는 콘텐츠와 연관되어 웹사이트를 방문하며 영리한 UI에 감탄하지 않기 때문에 결국 중요한건 콘텐츠다. 그렇다면, 크롬을 숨기는건 나쁜가?

크롬을 숨기는 것의 비용

사실 크롬은 사용자들이 그 컨텐츠에 참여하는 방식을 지원하고 사이트가 유용한지 아닌지를 결정한다. 크롬을 숨기는건 상당한 비용이 발생한다.

사용자는 크롬을 발견해야만 한다. 크롬이 일반 메뉴 버튼 아래에 숨겨져 있든, 아니면 제스쳐(터치스크린의 윈도우8에서 처럼)아래에 숨겨져 있던 사람들은 크롬을 찾기 위해 버튼 아래를 찾아보거나 제스처를 취해야한다고 생각한다.
크롬을 발견한 후에도 사용자는 나중에 같은 세션 동안 크롬에 엑세스하는 방법을 기억해야한다. 내비게이션 옵션을 노출하는것은 기억을 상기시키는것 보다 인식에 유리하므로 10가지 사용적합성 휴리스틱 중 하나를 따르게된다.
Window8 테스트에서는 사용자가 크롬에 엑세스한느 방법을 발견했다가 나중에 잊어버리는 경우가 종종 발견되었다. 눈에서 멀어지면? 마음에서도 멀어진다!
비록 그들이 크롬에 접근하는 방법을 발견하고 기억하더라도, 사용자들은 크롬이 제공하는 기능에 접근하기 위해 더 많은 상호작용 비용을 부담한다. 햄버거 메뉴의 경우 단순한 네비게이션 선택을 바로 클릭하는것이 아니라, 먼저 메뉴 아이콘을 클릭한 다음 필요한 옵션을 한번 더 선택해야 한다. 물론, 한번 더 클릭하면 어떻냐고 생각할 수도 있다. 그러나 대부분의 경우 그 자체는 그리 많지 않지만, 사용자가 이러한 숨겨진 옵션에 반복적으로 액세스해야하는 경우 빠르게 성가신것이 된다.

콘텐츠 대 크롬 비율과 화면 사이즈

크롬이 너무 많다면 나쁘지만, 너무 적은 크롬도 나쁘다. 우리가 극대화해야 하는 것은 화면에서 콘텐츠가 차지하는 양이 아니다. 우리는 콘텐츠 대 크롬 비율을 극대화 해야한다. 그리고 그 비율은 화면 크기에 따라 조절되어야 한다. 작은 스크린에서, 8개의 항목이 있는 네비게이션 바는 사용 가능한 화면 공간의 절반 이상을 차지해버리기 쉽다. 그것은 콘텐츠를 대체할수 있고 사용자가 페이지에 대해 파악하기 위해 스크롤 하게 만든다. 콘텐츠 대 크롬의 비율이 너무 작은 경우, 메뉴 버튼 아래로 기능적인 버튼을 숨겨서 그 비율을 증가시키게 될 수도 있다. (작은 화면이라도, 햄버거 메뉴 아래에 네비게이션을 숨기는 것은 이상적이지 않다: 보이지 않는 것은 마음에서 멀어지며 사람들은 그것을 발견하기 위해 조금 더 많은것을 수행해야 한다. 제스처 기반 인터페이스에 대한 우리의 연구는 또한 보이지 않는 크롬이 접근하기 어렵다는 것을 보여준다. 하지만 스마트워치와 같은 작은 화면에서는 제스쳐가 유일한 방법이다.

훨씬 더 큰 데스크톱 모니터에서는 8개의 네비게이션 바가 콘텐츠 대 크롬 비율에 영향을 최소화한다. 네비게이션이 숨겨져 있으면 비율이 좀더 낮겠지만 크롬을 숨겨두는 비용을 정당화할 만큼 좋지는 않다. 또한 작은 아이콘은 작은 화면보다 큰 화면에서 간과하기 수비다.

궁극적으로, 사람과 기기간 커뮤니케이션 채널 용량이 작다면 정보를 압축해 최대한 적은 픽셀로 많은 가치를 전송해야한다. 주로 콘텐츠에 의해 가치가 전달되기 때문에 크롬을 최소화하는 것이 타당하다. 그러나 그 주장은 더 큰 화면에는 해당되지 않는다.

Chrome을 최소화하되 콘텐츠 대 크롬 비율에는 영향을 미치지 않는 데스크톱 디자인 패턴

최근 기사 중 몇가지는 데스크톱의 콘텐츠 대 크롬 비율을 잘못 개선하려는 모바일 종속 디자인 트렌드에 초점을 맞추고 있다. 이 과정에서 콘텐츠 대 크롬 비율을 최소한으로 변경하지만 사용성이 희생된다.

네비게이션의 햄버거 메뉴햄버거 메뉴는 모바일에서 더 쉽게 찾을 수 있다. 여전히 모바일에서 많은 사용자들이 메뉴 내부의 기능에 접근하지 않거나 단순히 확인하는것을 잊는다.
데스크탑에서의 햄버거 아이콘의 인기는 모바일에서의 보편성과 모든 기기에서 단일 디자인을 시도하는 반응형 웹사이트의 확산에서 영감을 받았다. 불행히도 햄버거 메뉴의 작은 크기 (큰 바탕 화면에 비해)는 발견하기 어렵다.
검색 박스 대신 돋보기 아이콘
검색 박스를 제거하고 돋보기 아이콘으로 교체하는 것은 모바일에서 거의 표준이 되었다. 데스크톱에서는 공간이 너무 커서 사용자가 작은 검색 아이콘을 찾을 인내심이 없다. 데스크탑에서 이 방법을 적용할 경우, 공간을 절약 한것이 검색 도구를 발견해내기 위해 낭비되는 시간을 정당화할 수 없다는것을 명심해라.
라벨이 없는 아이콘 (또는 썸네일)
아이콘이나 이미지가 더 몰입감 있는 경험을 제공하고 스크린의 공간을 절약한다고 생각할수 있지만 사실 대부분은 말보다 훨씬 애매하다. 아이콘이나 그림이 텍스트 없이 스스로 네비게이션에 사용되는 경우, 절약된 공간은 정보 향기 (information scent)의 손실을 정당화하지 못한다.

결론

데스크톱 및 모바일 화면 크기는 제약 조건이 다르므로 각자 다른 사용성 규칙이 따른다. 디자이너가 모바일에서 해야하는 절충점은 데스크탑에 잘 일반화되지 않으며, 그 반대의 경우도 마찬가지이다. 크롬을 없애는 시류에 편승하기 전에 두번 생각해보자. 스스로에게 물어보자. 감소된 크롬 인터페이스는 콘텐츠대 크롬 비율을 크게 향상 시키는가? 아니라고 대답한다면 크롬을 노출시켜라. 또한 같은 디자인이어도 디바이스마다 다르게 작업될 수 있다는걸 기억해라.

다른 디바이스간 디자인에 대해 공부하고 싶다면 Scaling user Interfaces 수업을 확인하라!

참고 자료: What does "chrome" mean in Microsoft design guidelines?
원문 바로가기: Maximize the Content-to-Chrome Ratio, Not the Amount of Content on Screen

데스크톱의 왼쪽 세로 네비게이션

디쟈이너 — Thu, 20 Jan 2022 20:45:47 +0900

역시 UX명가 닐슨노먼그룹 답게, 굉장히 좋은 아티클을 찾았다.

뼈에 새기기위해 직접 번역한 아티클!

원제: 데스크톱의 왼쪽 왼쪽 세로 네비게이션: 확장 가능하고, 응답성이 뛰어나며, 스캔이 간편. (Left-Side Vertical Navigation on Desktop: Scalable, Responsive, and Easy to Scan)

TL;DR: 세로 내비게이션은 광범위(broad)하거나 성장하는 IA에 적합하지만, 가로 내비게이션보다 더 많은 공간을 차지한다. 왼쪽 정렬, 키워드 전면 로드 및 가시성이 있는지 확인해야한다.

Information Architecture에 대한 UX 컨퍼런스 과정에서 광범위한 계층 구조(broad hierarchies)에 대해 이야기할 때마다 다음과 같은 두개 질문이 나온다.

글로벌 내비게이션에 상위 카테고리가 7~9개 이상이어도 괜찮은가? (스포일러: 괜찮습니다. 적절하게 계획되기만 한다면.)
상위 카테고리가 많으면 가로 내비게이션 바에 적합하지 않다. 어디로 가면 될까?

많은 팀들이 광범위한 네비게이션 하이라키를 데스크톱 사이트의 가로 네비게이션 바로 연결하려 할 것이다. 제한된 가로 공간에 카테고리의 목록을 맞추기 위해 지나치게 작은 글꼴을 사용하거나, 서로 가까이 있는 항목을 붐비게 하거나 비정상적으로 짧은 카테고리명을 만든다. 가장 나쁜것은 IA를 변경하여 사용 가능한 공간에 들어갈 수 있는 만큼의 주요 카테고리만 만들 수 있도록 하는것이다. 광범위한 정보를 소수의 카테고리로 제한하면, 우리는 결국 너무 포괄적이고 사용자가 필요한 것을 찾기 어렵게 되는 최상위 항목들로 끝나게된다. 또한 사용자는 관련 범주를 찾기 위해 더 많은 작업(클릭하여 다양한 하위 계층 범주 탐색)을 해야한다.

Accenture

Accenture는 최상위 카테고리의 수를 인위적으로 제한하기 위해 단일 서비스 카테고리 아래에 광범위한 정보를 숨겼다. 특정 컨설팅 영역을 찾기 위한 검색성은 낮아지고 상호 작용 비용 은 증가했다(유저가 여러 최상위 범주를 열고 스캔한 후 옳지 않다고 판단해야 했기 때문이다)

그러나 데스크탑에서 필요한 만큼 최상위 항목을 충분히 수용할 수 있는 또다른 유형의 네비게이션 UI가 있다 - vertical, left-side navigation!

Arbor 식당의 홈페이지

Arbor 식당의 홈페이지는 세로 네비게이션 패턴을 이용해 13개 글로벌 네비게이션 카테고리를 손쉽게 이용할 수 있도록 한다. 이 네비게이션 UI는 명확하고 정보 순위가 높은 주요 카테고리의 노출을 허용하며 특정 옵션을 보기 전에 일반 최상위 카테고리를 먼저 선택해야 하는 상호작용 비용을 절약한다

세로 네비게이션의 이점

이 네비게이션 UI의 주요 이점은 많은 최상위 카테고리를 나타낼 수 있는 충분한 공간에서 비롯된다.

특정 카테고리는 검색 용이성을 높이고 상호 작용 비용을 줄인다.
세로 네비게이션을 사용하면 카테고리 수를 제한하는 시각적 디자인 제약이 제거되어 팀은 자연스럽게 정보 공간에 맞는 IA를 만들 수 있으며, 계층 구조의 두 번째 계층을 파고들지 않고도 사용자에게 특정하고 높은 정보의 향기 (information scent) 카테고리를 노출할 수 있다.
세로 네비게이션은 성장을 위한 공간을 제공한다.세로 탐색에 카테고리를 추가하는 데는 네비게이션 UI를 다시 설계하는 주요 프로세스가 필요하지 않습니다. 유일한 중요한 결정은 새 항목을 기존 카테고리 구조에 어떻게 혼합해야 하는지에 대한 것이다.
세로 네비게이션은 향후 네비게이션이 성장할 가능성이 높은 사이트. 즉 B2B 기업, 정부, 고등 교육 및 의료 분야에서 서비스나 콘텐츠를 지속적으로 발전시킬 수 있는 대규모 조직에 탁월한 선택이다.
세로 네비게이션은 가로 네비게이션보다 더 효율적인 스캔을 지원한다.
우리는 아이트래킹 연구를 통해 웹사이트의 관심이 기울고 있다는것을 알고 있다. 사용자들은 항상 화면의 왼쪽 절반만 본다. 화면 왼쪽에 있는 에셋은 가치가 있으며, 여기에 네비게이션을 배치하면 사용자가 인식하고 스캔할수 있다.
추가로, 심리언어학 연구는 목록이 가로일 때보다 세로일 때 시각적 검색이 더 효율적이라는 것을 보여준다. 사람들은 눈을 더 조금 움직이고도 더 많은 정보를 얻을 수 있기 때문에, 관심 있는 항목을 찾을 수 있다. (눈이 정보를 인식한다는 것을 기억하라. 고정된 정확한 위치 뿐만 아니라 그 주변의 비교적 작은 영역에서도 볼 수 있다. 그 결과, 우리가 한 문장의 모든 단어를 읽을 때에도 우리는 그 중 몇 개에만 집중할 필요가 있다)
일반적인 오해 중 하나는 가로 네비게이션 디자인이 F자형 판독 패턴을 지원한다는 것이다. 그러나 F자 패턴은 사용자가 구조호되지 않은 텍스트를 읽을 때 마주치게 되는데, 이는 분명히 네비게이션, 헤더 등에는 해당되지 않는다.
사용자는 세로 네비게이션에 익숙하다. 현대의 웹 사이트에서는 덜 흔하지만, 세로 네비게이션은 데스크톱 애플리케이션(기본앱과 웹앱 모두)에서 자주 발견된다.
Slack과 Gmail은 왼쪽 세로 네비게이션을 사용하는 웹 애플리케이션의 예이다.

또한 많은 웹사이트들이 세로 로컬 네비게이션 (vertical local navigation i.e.., 사이트 하이라키(hierarchy)에서 동일한 카테고리에 속하는 현재 페이지의 “형제(sibling)” 페이지를 보여준다.
세로 네비게이션은 자연스럽게 모바일로 바뀔수 있다. 가로 메뉴바를 모바일 친화적인 디자인으로 변환하는 것은 메뉴바가 보통 세로 네비게이션으로 변환되기 때문에 약간의 조정이 필요할 수 있다. 반대로, 데스크톱과 모바일에서 세로 네비게이션을 사용하면 팀은 비교적 최소한의 적응으로 동일한 시각 디자인 선택을 적용할 수 있다. 테두리, 유형, 간격, 카테고리 순서 및 두 번째 하이라키 카테고리의 UI가 장치간에 공유될 수 있다.
따라서 세로(햄버거 또는 기타) 메뉴 아래에 데스크톱 네비게이션을 숨기려는 유혹을 가지지 말라라. 가시적 네비게이션은 모바일과 데스크탑 모두가 따를 수 있는 최고의 표준이다. 일부 모바일 웹사이트는 화면 공간이 제한되어 네비게이션의 대부분 또는 전부를 햄버거 메뉴 아래에 숨길 수 있지만, 눈에 보이는 네비게이션이 숨겨지면 사람들은 그것을 확인하는 것을 잊어버린다. 게다가, 데스크톱에서 햄버거 메뉴는 페이지의 나머지 부분에 비해 상대적으로 작은 공간을 가지고 있어 무시당할 가능성이 모바일에서보다 훨씬 더 크다.

세로형 네비게이션은 더 많은 공간이 필요하다

가로형 네비게이션에 비해 세로 네비게이션을 사용할 때 가장 큰 단점은 공간을 많이 차지해 콘텐츠를 보여줄 수 있는 공간이 적다는 점이다. 세로 네비게이션은 일반적으로 가로 네비게이션보다 content-to-chrome (콘텐트 대 색) 비율이 낮다.

Nua bikes의 예전 디자인과 새로운 디자인. 

(왼쪽) 이전 디자인은 content-to-chrome 비율 약 5:1의 세로, 왼쪽 네비게이션을 사용했다. (오른쪽) 사이트를 재디자인 하면서 동일한 화면 크기에 12:1 content-to-chrome 비율의 가로 네비게이션 바를 적용했다. 새로운 디자인은 가시적인 탐색에서 최상위 범주를 훨씬 적게 노출하지만 콘텐츠 공간을 훨씬 적게 차지한다.

작은 창 크기 (작은 디스플레이나 태블릿에서 볼 수 있는것같은) 에서는 이러한 절충을 수용하기 어려울 수 있다. 반응형 설계를 사용하는 경우 다양한 중단점(breakpoint, i.e., 창 크기)에 적합한 네비게이션 UI가 무엇인지, 세로 탐색을 통해 적절한 content-to-chrome 비율에 도달할 크기를 결정해야할 수 있다. 그러나 스펙트럼의 큰 창 크기에 접근할 때 세로 탐색은 content-to-chrome 비율에 더이상 영향을 미치지 않을 가능성이 높다. (디스플레이가 정말 클 때 뷰포트 영역이 오른쪽과 왼쪽에 빈 공간으로 채워지는 경우가 많음)

매우 긴 세로 네비게이션은 페이지를 접이고 그 아래에 일부 항목을 포함시킬 수 있다. 우리는 많은 연구를 통해 사용자가 접혀진 정보보다 접히는 UI위의 정보에 더 주의를 기울인다는 것으 알고 있다. 현재 목표에서 접힌 부분이 쓸모없어 보이면 스크롤조차 하지 않을 수 있다. (사용자는 그들에게 불필요하다 여기면 매우 빠르게 웹 페이지를 떠난다는것을 기억해라). 반면에, 세로 탐색은 충분히 잘 확립된 디자인 패턴으로 대부분의 사용자가 전체 메뉴를 볼 수 없는 경우 스크롤 할 수 있다. 즉, 접힌 곳 위에 보이는 정보가 유용하다는 것을 확신한다고 가정한다.

실용적인 세로 네비게이션 가이드라인

세로 네비게이션은 왼쪽에 놓고 눈에 띄는 디자인을 사용하라.
앞서 말햇듯이, 시각적 관심은 화면의 왼쪽에 쏠린다. 우리가 우측 레일 블라인드(사용자들이 광고를 포함할 수 있는 것처럼 보이면 페이지의 오른쪽열을 보는 것을 피하는것)를 자주 볼 수 있다는 사실과 결합하면, 페이지의 오른쪽 네비게이션은 눈에 띄지 않을 가능성이 있다. (왼쪽 대 오른쪽 지침과 마찬가지로 이 조언은 왼쪽에서 오른쪽으로 읽는 언어에 적용된다. 만약 당신의 언어가 오른쪽에서 왼쪽으로 읽는다면, 반대의 조언이 적용된다.)
메뉴를 가로 세로 양쪽으로 복제하지 마라.
최근 홀수 트렌드(odd trend)는 글로벌 네비게이션에 두 개의 중복 UI를 사용하는 것으로 구성된다. 가로 메뉴바와 동일한 카테고리의 햄버거 메뉴. 디자인 팀에서 어떤 UI를 사용할지 몰라 둘 다 포함한것 처럼 느껴진다. 대부분의 UI 요소 복제와 마찬가지로 이러한 복제는 불필요하며 혼란스러울 수 있다.
아이콘 뒤에 네비게이션 기능을 숨기지 마라.
세로 네비게이션은 가로 네비게이션보다 더 많은 공간을 차지하기 때문에 디자이너는 종종 이 영역을 최소하 하는것을 시도한다. 이것은 분명히 이해할 수 있는 목표지만, 그것을 달성하기 위한 몇몇 수단들은 결국 추가적인 문제를 야기한다. 한가지 새로운 경향은 카테고리에 텍스트 레이블 대신 아이콘을 사용하는 것이다. 모든 네비게이션 아이템에 텍스트 레이블을 사용할 수 있지만, 사용자는 네비게이션바를 클릭하거나 마우스를 움직일 때만 해당 레이블을 볼 수 있다.
우리는 수년동안 아이콘에 라벨을 추가하는것을 권장해왔다. 텍스트는 모호성을 줄일 뿐 아니라 타겟 사이즈를 증가시킨다. 그러나 사용자가 네비게이션 카테고리에 대한 아이콘을 즉시 이해할수 있다고 가정하는 몇몇 사이트는 여전히 존재한다. 나는 종종 네비게이션에서 말 한마디가 천장의 사진보다 낫다고 말한다.
네비게이션 텍스트 라벨을 숨기는 것은 사용자가 단순히 내베기에션(햄버거 메뉴와 마찬가지로)을 무시할 가능성이 높다는 것을 의미한다. 사용자는 인터렉션시 텍스트 라벨을 보기 위해 hover하거나 클릭하는 추가 상호 작용 비용 또는 아이콘의 의미를 디코딩하는 시도의 추가 인지 부하를 갖게된다.
일련의 아이콘에 대한 네비게이션을 최소화하는 전략 (기본값이 텍스트 레이블을 표시하고 숨기는 것은 선택사항)은 사용자가 카테고리가 무엇을 나타내는지 잘 배울 수 있는 매일 사용하는 응용 프로그램의 현실적인 절충안일 수 있다. 그러나 개별 사용자가 가끔 사용하는 것으로만 보이는 웹 사이트에서는 권장하지 않는 전략이다.
긴 메뉴에서는 중요하지 않은 메뉴를 맨 아래에 배치한다.
페이지 접힘으로 인한 가용성 문제 (위에서 논의함)로 인해 매우 긴 세로 메뉴는 스크롤하지 않고는 볼 수 없는 항목을 갖게될 수 있다. 안타깝게도 사용자마다 모니터 크기가 다르기 때문에 페이지 폴드가 사용자 개개인의 메뉴를 어디에 맞출지 알 수 없다. 긴 메뉴의 경우 스크롤하지 않고 보이지 않을 수 있는 항목이 덜 중요한 기능에 속하도록 항목의 우선순위를 지정해야한다.

요약

세로 네비게이션은 데스크톱에서 합리적인 선택이 될 수 있으며, 특히 광범위한 콘텐츠를 보유하고 있거나 빠르게 성장중이거나 단순히 사용자를 위해 특정 카테고리를 표시하고자 하는 사이트가 해당된다.

세로 네비게이션은 또한 모바일을 위한 반응형 대응이 용이하다.

세로 네비게이션의 장점을 유지하기 위해서, 햄버거 메뉴 아래에 숨기지 말아야 한다. 또한 왼쪽으로 정렬해야한다.

카테고리를 나타낼때는 아이콘 뿐만 아니라 키워드가 앞쪽에 있는 레이블을 사용해야한다.

세로 네비게이션의 이점이 콘텐츠를 보여줄 수 있는 공간을 빼앗는것을 정당화할 수 있는지 여부를 측정해보아야 한다.

네비게이션 디자인 트렌드

디쟈이너 — Fri, 14 Jan 2022 15:21:05 +0900

원본 아티클을 번역 및 간단히 요약한 글입니다.

탐색이 쉬운 웹사이트는 사용자가 원하는 콘텐츠에 더 빠르고 효율적으로 액세스할 수 있도록 한다. 가장 안전한 네비게이션 원칙과 요소들을 살펴본다.

Consistency (일관성)
- 메뉴는 사용자가 주제에 관계없이 쉽게 찾을 수 있도록 모든 페이지와 같은 위치에 있어야한다. Hubshout에서 수행한 설문조사에 따르면 사용자의 33%는 탐색하기 어려운 사이트를 떠난다고 한다.
Hamburger menu (햄버거 메뉴)
- 2014년의 햄버거 메뉴 논란
- 햄버거는 유용하다. UI를 깔끔하게 만든다.
- 또한 사용자들에게 이미 많이 학습되어 있다.
Simplicity and conciseness (단순함과 간결함)
- 탐색이 간결할수록 더 많은 홈페이지 권한이 내부 페이지로 이동한다.
- 검색엔진에서 좋은 순위를 가질 가능성을 높인다 (SEO에 좋다)
Pattern (패턴)
- 독창성(Originality)은 훌륭하지만, 네비게이션 구조를 디자인할때는 주의해야한다.
- 바퀴를 재발명하지 않는다.
- 특정 웹 규칙이 있으며 그들이 존재하는 이유는 그것이 잘 작동하기 때문이다.
- 사용자는 자신이 필요하다고 느끼는 위치와 비즈니스 목표를 달성하는데 필요한 위치에 정확히 도달해야한다.

트렌드 살펴보기

Fixed web navigation bars

스크린의 한 부분에 붙어있는 형태의 네비게이션
어디에서나 액세스할수 있어 보편적이고 모든 연령대의 사용자가 좋아한다.
회사 로고가 포함되어 브랜드 인지도가 높아진다

주의할점

고정형 네비게이션이 어떤 컨텐츠도 가리면 안된다. 특히 모바일에서!

ascensionlatorre.com

Vertical sliding navigation

수평적인것의 반대에 수직형 네비게이션이 있다.
모바일, 태블릿에 좋고 메뉴를 위한 공간이 많을때 좋다.
이커머스 웹사이트에 적절하다
경쟁자가 수평 네비게이션을 사용할 때, 차별점이 된다.
F자형 읽기 패턴에 익숙한 청중에게 정보를 인식하는 더 쉽고 스캔 가능한 방법을 제공하게된다

주의할점

메뉴명이 너무 길면 잘리거나 너무 많은 스크린 공간을 차지할 수 있다.
랩탑이나 데스크탑 사용 고객은 화면 전체에 걸쳐 메뉴의 스크롤을 왔다갔다 하는 이동에 피곤함을 느낄수 있다.
가로 메뉴에 비해 주의와 클릭이 적다

sokruta.com.ua

Fullscreen navigation

네비게이션 그 자체로 디자인이 된다
쿨하고 스타일리시하다
모바일에 적절하다

주의할점

네비게이션이 너무 컨텐츠가 뒤에 숨게되며, 이는 사용자 여정(User Journey)에 추가적인 장애물(hurdle)이된다

EAGLE FILMS

Subtle animation

사용성보다 시각적 매력과 우아함에 관한것이다. (but 아름다움도 실용적일 수 있음)
화려함과 매력을 더하며, 전체적인 컨셉을 더욱 생동감 있고 재미있게 만들어준다

주의할점

“미묘함”이 핵심! 제대로 수해오디지 않으면 애니메이션이 사용자의 주의를 산만하게 하고, 사이트 탐색을 방해할 수 있다.

Tab Bar Animation by Hoang Nguyen

Four Corner

사용자의 주의를 두가지 또는 네가지 방향으로 나눈다

주의사항

콘텐츠가 제한된 웹사이트에서만 실행 가능한 옵션일수 있다
사용자가 익숙한 탐색 방식이 아니라서 혼란스럽고 주의가 산만해질 수 있다

gothamsiti.it

Single page navigation

요즘 가장 인기있는것 중 하나
시각적 콘텐츠가 많은 웹사이트에 적합하고, 주의를 환기시키며, 모바일에 적절하다
내러티브를 제어할수 있으며 스크롤이 클릭보다 쉽다
일부 디자이너들은 “네비게이션 없음” 이라고 부르기도 한다

주의사항

SEO에 몇가지 단점이 있다
하나의 주요 개념을 중심으로 디자인되므로, 다양한 키워드에 대한 순위를 매길수 있는 능력이 제한된다
사용자는 미리 정의된 순서로만 정보를 얻어야 하는 필요성에 사로잡히기 때문에 더 적은 자유가 제공된다.

Web and interaction design by Vilius Vaicius

연말에 다시 생각해보면 좋을, 케빈 켈리의 68가지 조언

디쟈이너 — Wed, 29 Dec 2021 22:29:01 +0900

Wired 창립 편집장 케빈 켈리(KK)가 올해 68세 생일날 블로그에 올린 68가지 조언이라고 한다.

읽다보니 연말에 보길 참 잘했다 싶음.

• Learn how to learn from those you disagree with, or even offend you. See if you can find the truth in what they believe.
- 당신에게 동의하지 않는 사람, 심지어 당신을 불쾌하게 만드는 사람에게서도 배우는 방법을 익혀라. 그들이 믿는 것 중 진실을 찾을 수 있는지 보라.

• Being enthusiastic is worth 25 IQ points.
- 열정적인 것은 아이큐가 25 올라가는 수준의 효과가 있다.

• Always demand a deadline. A deadline weeds out the extraneous and the ordinary. It prevents you from trying to make it perfect, so you have to make it different. Different is better.
- 항상 데드라인을 요구하라. 데드라인과 관계없거나 평범한 일들을 쳐낼 수 있다. 데드라인이 ‘완벽하게’ 하지 못하게 방해하기 때문에 ‘다르게’ 만들어야 한다. 다른 것이 더 낫다.

• Don’t be afraid to ask a question that may sound stupid because 99% of the time everyone else is thinking of the same question and is too embarrassed to ask it.
- 멍청한 소리일까 봐 질문할 기회를 놓치지 마라. 99%의 사람들도 모두 같은 질문을 생각하지만, 부끄러워서 질문하지 못하는 중이다.

• Being able to listen well is a superpower. While listening to someone you love keep asking them “Is there more?”, until there is no more.
- 잘 들어주는 것은 초능력이다. 당신이 좋아하는 사람의 말을 들을 때는 그 사람이 더 말할 게 없을 때까지 ‘더 있어?’라고 물어라.

• A worthy goal for a year is to learn enough about a subject so that you can’t believe how ignorant you were a year earlier.
- 가치 있는 1년 목표는 하나의 주제를 충분히 공부해서 1년 전 얼마나 무지했는지 믿을 수 없도록 하는 것이다.

• Gratitude will unlock all other virtues and is something you can get better at.
- 감사함은 다른 모든 미덕을 여는 열쇠이며 당신을 더 나아지도록 한다.

• Treating a person to a meal never fails, and is so easy to do. It’s powerful with old friends and a great way to make new friends.
- 다른 이에게 식사를 대접하는 건 절대 실패하지 않으며, 너무나 쉬운 일이다. 오랜 친구에게도 효과가 좋으며 새 친구를 사귀기에도 굉장히 좋은 수단이다.

• Don’t trust all-purpose glue.
- 다목적 접착제를 믿지 마라.

• Reading to your children regularly will bond you together and kickstart their imaginations.
- 정기적으로 자녀에게 책을 읽어주는 것은 유대감을 늘리고 아이의 상상력을 키워줄 수 있다.

• Never use a credit card for credit. The only kind of credit, or debt, that is acceptable is debt to acquire something whose exchange value is extremely likely to increase, like in a home. The exchange value of most things diminishes or vanishes the moment you purchase them. Don’t be in debt to losers.
- 신용이 있다고 신용카드를 쓰지 마라. 신용, 즉 빚으로 살만한 가치가 있는 것은 집처럼 가치가 증가할 확률이 매우 높은 것뿐이다. 대부분 물건의 가치는 구매하는 즉시 떨어지기 시작한다. 그런 물건에 빚지지 마라.

• Pros are just amateurs who know how to gracefully recover from their mistakes.
- 전문가(Pro)는 단지 실수로부터 우아하게 회복할 줄 아는 아마추어일 뿐이다.

• Extraordinary claims should require extraordinary evidence to be believed.
- 엄청난 주장을 믿게 하려면 엄청난 증거가 필요하다.

• Don’t be the smartest person in the room. Hangout with, and learn from, people smarter than yourself. Even better, find smart people who will disagree with you.
- 지금 있는 자리에서 가장 똑똑한 사람이 되려고 하지 마라. 더 똑똑한 사람들과 어울리고 그들로부터 배워라. 나아가 당신에게 동의하지 않는 똑똑한 사람을 찾으면 더 좋다.

• Rule of 3 in conversation. To get to the real reason, ask a person to go deeper than what they just said. Then again, and once more. The third time’s answer is close to the truth.
- 대화에는 3의 법칙이 있다. 진짜 이유를 알고 싶다면, 상대방이 말한 것보다 더 깊이 들어가야 한다. 그리고 한 번 더 또 한 번 더 물어라. 세 번째 답이 진실에 가깝다.

• Don’t be the best. Be the only.
- 최고가 되지 말아라. 유일한 사람이 돼라.

• Everyone is shy. Other people are waiting for you to introduce yourself to them, they are waiting for you to send them an email, they are waiting for you to ask them on a date. Go ahead.
- 모두가 부끄러워한다. 다른 사람은 당신이 소개해주기를, 이메일을 보내주기를, 데이트를 요청하기를 기다리고 있다. 가라.

• Don’t take it personally when someone turns you down. Assume they are like you: busy, occupied, distracted. Try again later. It’s amazing how often a second try works.
- 누군가 당신을 거절할 때 개인적으로 받아들이지 마라. 그들도 당신과 같다. 바쁘고, 딴 데 정신 팔려 있고, 산만하다. 다음에 다시 시도하라. 두 번째 시도했을 때 성공할 때가 놀라울 정도로 많다.

• The purpose of a habit is to remove that action from self-negotiation. You no longer expend energy deciding whether to do it. You just do it. Good habits can range from telling the truth, to flossing.
- 습관의 목적은 자기 자신과 타협하는 행동을 제거하는 것이다. 할지 말지 결정하는데 에너지를 쏟지 않고 그냥 하는 것이다. 좋은 습관은 진실을 말하는 것부터 치실을 하는 것까지 다양하다.

• Promptness is a sign of respect.
- 신속함은 존경의 표시다.

• When you are young spend at least 6 months to one year living as poor as you can, owning as little as you possibly can, eating beans and rice in a tiny room or tent, to experience what your “worst” lifestyle might be. That way any time you have to risk something in the future you won’t be afraid of the worst case scenario.
- 젊었을 때 적어도 6개월에서 1년 정도 아주 작은 방이나 텐트에서 콩과 쌀만 먹으며 가난하게 살아보며, 최악의 생활이 어떤지 경험해보라. 그러면 미래에 위험을 감수해야 할 때 최악의 시나리오를 두려워하지 않을 것이다.

• Trust me: There is no “them”.
- 나를 믿어라: "그들"은 존재하지 않는다. (역주: 뭔가 내 의견에 반하는 '사람들'이 있는게 아니고 우린 모두 다른 의견을 가진 거라고 생각하고 번역했습니다.)

• The more you are interested in others, the more interesting they find you. To be interesting, be interested.
- 타인에게 관심을 가질수록, 타인도 당신에게 관심을 가진다. 관심을 받고 싶다면, 관심을 가져라.

• Optimize your generosity. No one on their deathbed has ever regretted giving too much away.
- 최대한 관대해져라. 누구도 죽을 때 너무 많이 베풀었다며 후회하지 않았다.

• To make something good, just do it. To make something great, just re-do it, re-do it, re-do it. The secret to making fine things is in remaking them.
- 무언가 좋은 걸 만들고 싶다면, 그냥 해라. 무언가 훌륭한 걸 만들고 싶다면, 그냥 다시 하고, 다시 하고, 다시 해라. 좋은 것을 만드는 비밀은 그것을 다시 만드는 데 있다.

• The Golden Rule will never fail you. It is the foundation of all other virtues.
- 황금률 (The Golden Rule, 다른 사람이 해 주었으면 하는 행위를 하라 [1])은 언제나 옳다. 황금률은 다른 미덕의 기초가 된다.

• If you are looking for something in your house, and you finally find it, when you’re done with it, don’t put it back where you found it. Put it back where you first looked for it.
- 집안에서 무언가를 찾을 때, 마침내 찾아서 쓰고 나면 찾은 곳에 다시 두지 말아라. 처음 찾았던 장소에 둬라.

• Saving money and investing money are both good habits. Small amounts of money invested regularly for many decades without deliberation is one path to wealth.
- 저축과 투자는 둘 다 좋은 습관이다. 깊이 생각하지 말고 수십 년간 소액의 돈을 투자하는 것이 부자가 되는 방법이다.

• To make mistakes is human. To own your mistakes is divine. Nothing elevates a person higher than quickly admitting and taking personal responsibility for the mistakes you make and then fixing them fairly. If you mess up, fess up. It’s astounding how powerful this ownership is.
- 실수를 하는 건 인간적인 일이다. 실수를 인정하는 건 성스러운 일이다. 빠르게 실수를 인정하고 바로 잡는 것보다 사람을 훌륭하게 만들어주는 것은 없다. 망쳤다면, 고백해라. 이렇게 인정하는 것은 놀라울 정도로 강력하다.

- Never get involved in a land war in Asia
- 아시아 영토 전쟁에 절대 개입하지 말라. (분에 넘치는 일은 하지 말라는 뜻)

• You can obsess about serving your customers/audience/clients, or you can obsess about beating the competition. Both work, but of the two, obsessing about your customers will take you further.
- 당신의 손님, 관객, 고객을 만족하는데 집착할 수도 있고, 경쟁에서 이기는데 집착할 수도 있다. 하지만 둘 중 하나를 골라야 한다면 고객에게 집착하는 게 더 멀리 갈 수 있다.

• Show up. Keep showing up. Somebody successful said: 99% of success is just showing up.
- 참석하라. 계속 참석하라. 성공한 사람이 말하길: 성공의 99%는 출석하는 것이다. (show up은 시작하다의 의미도 있다고 한다)

• Separate the processes of creation from improving. You can’t write and edit, or sculpt and polish, or make and analyze at the same time. If you do, the editor stops the creator. While you invent, don’t select. While you sketch, don’t inspect. While you write the first draft, don’t reflect. At the start, the creator mind must be unleashed from judgement.
- 창작의 과정과 개선의 과정을 분리하라. 쓰면서 편집하는 것, 조각하고 다듬는 것, 만들고 분석하는 것을 동시에 할 수는 없다. 만일 동시에 한다면, 편집자가 창작자를 막아서게 된다. 발명하는 동안에는 고르려고 하지 마라. 스케치하는 동안 점검하지 마라. 초안을 쓰는 중이라면 반추하지 마라. 시작할 때 창작자는 판단으로부터 자유로워야 한다.

• If you are not falling down occasionally, you are just coasting.
- 만일 이따금 넘어지지 않는다면, 그냥 설렁설렁하는 것에 불과하다.

• Perhaps the most counter-intuitive truth of the universe is that the more you give to others, the more you’ll get. Understanding this is the beginning of wisdom.
- 아마도 우주에서 가장 반 직관적인 진리가 있다면 ‘더 많이 줄수록, 더 많이 얻을 수 있다’는 사실이다. 이걸 이해하는 게 지혜의 시작이다.

• Friends are better than money. Almost anything money can do, friends can do better. In so many ways a friend with a boat is better than owning a boat.
- 친구가 돈보다 낫다. 돈으로 할 수 있는 거의 모든 것은 친구를 친구들이 더 잘한다. 배를 소유하는 것보다 배를 가진 친구를 사귀는 것이 많은 면에서 낫다.

• This is true: It’s hard to cheat an honest man.
- 분명한 사실: 정직한 사람은 속이기 힘들다.

• When an object is lost, 95% of the time it is hiding within arm’s reach of where it was last seen. Search in all possible locations in that radius and you’ll find it.
- 물건을 잃어버렸을 때 95%는 마지막으로 본 곳에서 팔 닿는 근처에 있다. 그 안에서 샅샅이 뒤져보면 찾을 수 있다.

• You are what you do. Not what you say, not what you believe, not how you vote, but what you spend your time on.
- 당신은 당신이 하는 일로 표현된다. 당신의 말도 아니고 당신이 믿는 것도 아니고 당신의 표도 아니고, 당신이 시간을 쓰는 것이 당신이다.

• If you lose or forget to bring a cable, adapter or charger, check with your hotel. Most hotels now have a drawer full of cables, adapters and chargers others have left behind, and probably have the one you are missing. You can often claim it after borrowing it.
- 케이블, 어댑터, 충전기를 깜빡했다면 호텔에 물어봐라. 호텔 대부분은 다른 사람이 두고 간 케이블, 어댑터, 충전기로 가득 찬 서랍을 가지고 있다. 당신이 필요한 물건도 거기 있을 수 있다. 가끔 빌리고 나서 가져갈 수도 있다.

• Hatred is a curse that does not affect the hated. It only poisons the hater. Release a grudge as if it was a poison.
- 증오는 증오의 대상에게는 영향을 주지 않는 저주다. 증오는 오직 증오하는 사람만을 해치는 독이다. 독이라고 생각하고 원한을 놓아주라.

• There is no limit on better. Talent is distributed unfairly, but there is no limit on how much we can improve what we start with.
- 더 나아지는 데에는 한계가 없다. 재능의 분배는 불공평하지만 일단 더 나아지려 시작하면 끝없이 나아질 수 있다.

• Be prepared: When you are 90% done any large project (a house, a film, an event, an app) the rest of the myriad details will take a second 90% to complete.
- 준비하라 : 집이나, 영화나, 행사나, 어플 등 큰 프로젝트를 90% 완성하면, 나머지 자잘한 디테일을 완성하는데 두 번째 90%가 걸린다.

• When you die you take absolutely nothing with you except your reputation.
- 죽을 때 유일하게 가져갈 수 있는 건 평판뿐이다.

• Before you are old, attend as many funerals as you can bear, and listen. Nobody talks about the departed’s achievements. The only thing people will remember is what kind of person you were while you were achieving.
- 늙기 전에 가능한 많은 장례식에 찾아가 경청하라. 누구도 고인의 업적에 대해 말하지 않는다. 사람들이 기억하는 것은 업적을 세우는 동안 그 사람이 어떤 사람이었는가 하는 것뿐이다.

• For every dollar you spend purchasing something substantial, expect to pay a dollar in repairs, maintenance, or disposal by the end of its life.
- 무언가 크게 지를 때는 거기에 들어가는 1달러마다 추가로 1달러만큼 수리, 유지보수, 폐기 처리하는 비용이 들어갈 것을 예상하라.

• Anything real begins with the fiction of what could be. Imagination is therefore the most potent force in the universe, and a skill you can get better at. It’s the one skill in life that benefits from ignoring what everyone else knows.
- 현실은 있을 법한 허구에서 시작한다. 그러므로 상상력은 우주에서 가장 강력한 힘이고 당신이 단련할 수 있는 기술이다. 상상력은 다른 사람이 알고 있는 걸 무시함으로써 도움이 되는 유일한 능력이다.

• When crisis and disaster strike, don’t waste them. No problems, no progress.
- 위기와 재난이 닥쳤을 때, 그걸 낭비하지 마라. 문제가 없다면 진전도 없다.

• On vacation go to the most remote place on your itinerary first, bypassing the cities. You’ll maximize the shock of otherness in the remote, and then later you’ll welcome the familiar comforts of a city on the way back.
- 여행을 갈 때는 도시를 벗어나 가장 멀고 동떨어진 곳으로 먼저 가라. 동떨어진 곳부터 시작하면 낯선 느낌이 주는 충격을 최대화 할 수 있고 도시로 돌아올 때 친숙한 편안함을 환영하게 된다.

• When you get an invitation to do something in the future, ask yourself: would you accept this if it was scheduled for tomorrow? Not too many promises will pass that immediacy filter.
- 미래에 뭔가 해달라는 초대를 받으면 자신에게 물어보라. 이 일이 바로 내일 생겨도 수락할 것인가? 지금 바로 할 것이냐는 질문에 그렇다고 할만한 약속은 그리 많지 않다.

• Don’t say anything about someone in email you would not be comfortable saying to them directly, because eventually they will read it.
- 제3자에게 직접 말하기 불편한 내용은 이메일에서도 쓰지 마라. 그 사람이 결국 그걸 읽게 될 것이다.

• If you desperately need a job, you are just another problem for a boss; if you can solve many of the problems the boss has right now, you are hired. To be hired, think like your boss.
- 당신이 절박하게 일자리가 필요하다면, 보스에게 당신은 그저 귀찮은 문제일 뿐이다. 보스가 당면한 문제를 해결해 줄 수 있어야 당신을 뽑을 것이다. 채용되려면 보스처럼 생각하라.

• Art is in what you leave out.
- 예술은 생략하는 것에 있다.

• Acquiring things will rarely bring you deep satisfaction. But acquiring experiences will.
- 물건을 얻는 것으로 깊이 만족하는 경우는 거의 없다. 하지만 경험으로는 가능하다.

• Rule of 7 in research. You can find out anything if you are willing to go seven levels. If the first source you ask doesn’t know, ask them who you should ask next, and so on down the line. If you are willing to go to the 7th source, you’ll almost always get your answer.
- 조사에는 7의 법칙이 있다. 7 단계를 거칠 수 있다면 무엇이든 찾을 수 있다. 첫 번째로 물어본 사람이 모른다면, 다음으로 어디에 물으면 되겠냐고 질문하고, 이 과정을 반복하라. 이걸 7번 반복하면 거의 매번 답을 찾을 수 있다.

• How to apologize: Quickly, specifically, sincerely.
- 사과 하는법 : 신속하게, 구체적으로, 진심을 담아.

• Don’t ever respond to a solicitation or a proposal on the phone. The urgency is a disguise.
- 전화로 오는 요청이나 제안에 응하지 마라. 긴급함은 위장이다.

• When someone is nasty, rude, hateful, or mean with you, pretend they have a disease. That makes it easier to have empathy toward them which can soften the conflict.
- 누군가 당신에게 무례하고 못되게 군다면 그들이 병에 걸렸다고 생각해라. 상대방을 이해하기 쉬워져 다툼을 줄일 수 있다.

• Eliminating clutter makes room for your true treasures.
- 잡동사니를 치우면 진짜 보물을 위한 공간을 만들 수 있다.

• You really don’t want to be famous. Read the biography of any famous person.
- 당신은 진짜로 유명해지고 싶지 않을 것이다. 누가 됐든 유명한 사람의 자서전을 읽어보라.

• Experience is overrated. When hiring, hire for aptitude, train for skills. Most really amazing or great things are done by people doing them for the first time.
- 경험은 과대평가되어있다. 누군가를 고용할 때 적성을 보고 뽑고 기술은 가르쳐라. 놀랍고 훌륭한 많은 일들이 그 일을 처음 하는 사람들에게서 나온다.

• A vacation + a disaster = an adventure.
- 휴가 + 재난 = 모험

• Buying tools: Start by buying the absolute cheapest tools you can find. Upgrade the ones you use a lot. If you wind up using some tool for a job, buy the very best you can afford.
- 도구를 살 때 : 가장 싼 도구부터 시작해서 많이 쓰는 도구를 업그레이드하라. 만약 직업을 위한 도구를 찾는다면, 가장 좋은 걸 사라.

• Learn how to take a 20-minute power nap without embarrassment.
- 부끄러워하지 않고 20분 동안 파워 낮잠을 잘 방법을 익혀라.

• Following your bliss is a recipe for paralysis if you don’t know what you are passionate about. A better motto for most youth is “master something, anything”. Through mastery of one thing, you can drift towards extensions of that mastery that bring you more joy, and eventually discover where your bliss is.
- 무엇에 열정을 갖고 있는지 모른 채 행복만을 좇으면 정체될 수밖에 없다. 젊은이들을 위한 더 좋은 모토는 ‘무언이 되었든 일단 마스터하라’이다. 하나를 마스터하면 다른 것으로 확장해 갈 수 있고, 결국 당신만의 행복을 찾게 될 것이다.

• I’m positive that in 100 years much of what I take to be true today will be proved to be wrong, maybe even embarrassingly wrong, and I try really hard to identify what it is that I am wrong about today.
- 나는 100년 뒤에 내가 오늘날 알고 있는 많은 것들이 틀렸다고, 창피할 정도로 무지했던 것으로 드러날 거라고 믿는다. 그래서 나는 오늘 틀린 것이 무엇인지 알아내기 위해 정말 많이 노력한다.

• Over the long term, the future is decided by optimists. To be an optimist you don’t have to ignore all the many problems we create; you just have to imagine improving our capacity to solve problems.
- 장기적으로 미래는 낙관론자들이 결정한다. 낙관론자가 되기 위해 많은 우리가 만드는 많은 문제를 무시할 필요는 없다. 그저 문제를 해결하는 역량을 키워낼 수 있다고 상상하면 된다.

• The universe is conspiring behind your back to make you a success. This will be much easier to do if you embrace this pronoia.
- 우주는 당신을 성공시키기 위해 뒤에서 계획을 꾸미고 있다. 이 낙관적 믿음을 받아들이면 인생은 훨씬 쉬워진다.

[Figma Basic] 부모(parents)와 자식(children), 형제 (siblings) 관계

디쟈이너 — Mon, 27 Dec 2021 21:37:43 +0900

부모(parents)와 자식(children), 형제 (siblings) 관계

피그마의 오브젝트(객체) 사이에는 부모, 자식, 형제 관계가 있다.

이 용어는 웹 개발이나 프로그래밍에서 유사한 관계를 설명하기 위해 일반적으로 사용하는 용어이다.

이 용어에 대해 명확하게 알아보자.

OOP(Object-Oriented Programming)을 경험해보았다면, 이러한 관계는 약간 다르다. 피그마의 부모/자식 관계는 실제 상속과 관련이 없다. 피그마에서, 이러한 관계는 DOM(Document Object Model)과 더 유사하게 작동한다. 즉, 내부에 엘리먼트를 포함하고 있는 컨테이너의 개념이다.

부모(parents)와 자식(children), 형제 (siblings)

우리는 캔버스에서 오브젝트와 오브젝으가 어떻게 관련되는지 설명하기 위해 이 용어를 사용한다.

부모(Parents): 다른 오브젝트를 포함하는 객체 즉 프레임, 콤포넌트, 그룹을 의미한다

자식(Children): 부모 내부에 속하는 오브젝트를 의미한다

형제(Sibilings): 동일한 부모(상위 항목)에 포함되어 있는 객체를 의미한다

내부에 객체가 있는 프레임에서, 프레임은 부모이고 내부의 객체는 모두 자식이다.
프레임만 있는 경우 부모라고 볼 수 없다. 내부에 객체가 있는 경우에만 부모이다.
부모에 하나 이상의 객체가 있는 경우, 자식 객체는 형제 관계이다.
객체(프레임, 그룹, 컴포넌트 등)는 부모도 될 수 있고 자식도 될 수 있다.

부모(parents)와 자식(children), 형제 (siblings)

부모 자식 상호관계

이러한 용어는 피그마에 명시적으로 사용되지는 않았지만, 객체가 어떻게 동작하고 서로 연관 되는지 이해하기 위해 매우 중요하다.

생물학적 비유처럼 명시적으로 상속되는것과는 달리, 그들은 서로 영향을 주고받는 컨테이너(parents)와 컨텐츠(children)의 역할을 한다.

Properties

서로 영향을 주고받는 부모/자식 관계가 있다. 대부분의 상황에서 부모는 프레임이다.

또한, 모든 자식 객체에 영향을 미치는 프레임에 다음 속성을 추가할 수 있다:

Layout Grids: 디자인에 대해 시각적 구조를 만든다
Auto Layout: 컨텐츠에 반응하는 다이나믹 프레임을 만든다
Clip Content: 프레임의 범위를 벗어나는 객체를 숨긴다

또한 자식 객체에 속성을 추가할 수 있다:

Constraints: 부모 프레임의 크기를 변경할 때 자식 객체가 응답하는 방식을 정의한다

Parenting 동작

캔버스안에 있는 객체를 이동시키면, 피그마는 객체를 다시 포함할지의 여부를 결정한다.

Reparenting은 객체가 현재 부모(예: 프레임)에서 벗어나 다른 프레임에 포함되는것을 의미한다.

피그마는 프레임에 새 객체를 추가할 때 parenting에 동일한 논리를 사용한다.

기본적인 동작은 아래와 같다:

객체가 프레임보다 작으면, 객체를 프레임의 자식 객체로 만든다
객체가 프레임보다 크면, 자식 객체로 만들지 않는다

기본 동작 건너뛰기

객체를 추가할 때, space 바를 누르면 피그마가 객체를 reparenting 하는 것을 방지한다
프레임의 경계를 넘겨 객체를 이동할때 space 바를 누르면 해당 객체를 현재 부모에 유지해준다

원본 링크: Parent, child and sibling relationships

Figma에서 객체들간의 관계성을 나타내는 부모, 자식, 형제라는 용어는 이미 CSS에서 많이 사용하던 용어라 굉장히 친숙하고 직관적이라 생각한다.
객체끼리의 관계성 뿐만 아니라 BEM에 대한 개념까지 내포하고 있는 듯.

[Fontello] 폰트 아이콘의 원리와 폰텔로 사용 방법

디쟈이너 — Sun, 26 Dec 2021 20:32:04 +0900

웹에 아이콘을 넣는 방식은 다양하다. 이미지(png, gif등)로 불러오기, SVG를 불러오기 그리고 웹폰트로 만들어 추가할 수도 있다. Fontello는 미리 제공하는 아이콘 중 원하는 아이콘을 선택해 경량화된 웹폰트로 만들수 있으며 특히 SVG 파일을 업로드해 원하는 아이콘을 추가할 수 있다.

아이콘을 폰트로 넣게되면 CSS의 color 속성을 사용해 코드의 컬러를 변경할 수 있으므로 이미지 리소스보다 유지보수에 효율적이다.

사용법

Fontello 사이트에서 원하는 아이콘을 선택하거나 Drag&Drop으로 폰트를 등록하고 Download webfont 버튼으로 다운받는다
HTML 문서에 다운받은 fontello.css파일을 불러온다
Demo 페이지에 있는 아이콘의 이름을 참고하여<i class="icon-name"></i> 형태로 클래스 명을 추가한다

원리

폰텔로가 제공하는 서비스는 쉽게 이야기하면 딩벳 폰트를 CSS로 사용하기 쉽운 방식으로 제공하는 것이다. HTML Entity라고도 하는데 우리가 특수문자 &을 HTML에 표현하기 위해 &라는 코드를 입력하는것과 같은 원리이다.

웹 페이지에 아이콘의 문자값을 입력하면 폰트에 등록된 값으로 출력된다. 그래서 각 아이콘의 문자값을 HTML에 추가하는 것과, 문자값이 깨지지 않고 출력될 수 있도록 font-family를 선언해 주는것이 필수적이다.

<!doctype html>
<html>
  <!-- font -->
  <link rel="stylesheet" href="css/fontelo.css">
  <style>
    body {
      font-family:"fontello";
    }
     </style>
</html>

폰텔로의 아이콘은 CSS의 :before, :after 선택자를 통해 화면에 나타난다.

.icon:before {
  content: "code";
}

위 코드는 특정 요소의 앞에 code라는 컨텐츠를 추가하는 코드이다.

fontello.css파일을 조금 더 자세히 살펴보면

font-face에서 font-family를 fontello 폰트 파일로 선언한다
icon-접두사를 가진 모든 요소의 :before에 각 아이콘의 content를 선언한다
각 아이콘마다 별도의 클래스명을 부여하고 그에 맞는 문자값을 content속성에 선언한다

클래스명과 컨텐츠 선언이 완료된 파일을 제공하기 때문에 우리는 CSS파일을 불러오고, 올바른 경로에 폰트 파일을 위치시키기만 하면 간단하게 원하는 아이콘을 사용할 수 있다.

폰트 만들고 유지보수 하기

폰트 만들기:

fontello 홈페이지에 드래그 앤 드롭으로 svg 파일을 추가한다.
Webfont를 다운로드 한다. 끝.

작업하는 컴퓨터를 바꾸거나 다른 브라우저를 사용할 경우 내가 선택한 아이콘의 정보가 사라진다.

이럴 경우 Download webfont 버튼 좌측의 도구 버튼 하위메뉴의 import 기능으로 내가 가진 fontello의 설정 파일인 setting.json 파일을 업로드해 기존 작업 내역을 불러올 수 있다.

또한 도구 버튼 하위메뉴 중 CSS prefix에서 원하는 접두사(prefix)로 변경이 자유롭다.

[Agile] 린 소프트웨어 개발 알아보기

디쟈이너 — Tue, 14 Dec 2021 09:44:18 +0900

기원

도요타 자동차의 독특한 색산 방식 원칙과 실천법을 정리하는데서 시작되었다. 우리나라 제조/생산 업계에서는 이미 도요타 생산 방식(TPS)를 오래 전부터 벤치마킹 해왔다. 린 (Lean)에서 중요한 개념은 JIT(Just In Time)이다. JIT는 필요한 시점에 필요한 만큼만 생산하는 것을 의미하며 이를 통해 재고를 최소화하고 비용도 최소로 줄여나간다. 또 하나의 중요한 용어가 칸반(Kanban)이다. 칸반은 일종의 작업 지시서로서 Pull 방식의 생산시스템을 구축하는데 중요한 역할을 한다

린 소프트웨어 개발의 시작

생산 방식으로서 린을 SW 개발에 적용하려는 시도는 여러번 있었다. 이를 체계적으로 정리한 것은 포펜딕(톰 포펜딕, 메리 포펜딕)부부이다. 린의 중요한 목표인 재구 절감을 SW개발에 대입해 불필요한 낭비를 제거하자는 운동으로 발전한 것이 린 소프트웨어 개발이다

린 소프트웨어 개발의 원칙

낭비를 제거하라

파레토 법칙 (2:8의 법칙)에 의거해 개발에 정말 중요한 20%에만 집중하고 낭비되는 요소(가외기능, 혼란, 경계 넘기)를 제거한다

가외기능: 80%의 가치를 제공하는 20%의 기능에 초점을 맞춰라. 20%의 가치를 제공하는 80%인 가외기능은 나중으로 미룬다
혼란: 요구사항 혼란을 겪는다면, 스펙을 너무 일찍 결정한 것이다. 테스트하고 수정하는데 혼란을 겪는다면 테스트를 너무 늦게 하는것이다
경계 넘어가기: 조직간의 경계는 통상 20% 이상의 비용을 증가시키는데, 버퍼를 만들고 응답시간을 늦춰 커뮤니케이션을 방해하기 때문이다

품질을 내재화 하라

개발 초기부터 각각의 SW 모듈에 대한 품질을 강조하면 마지막에 빅뱅식 통합이나 테스트 때문에 발생하는 문제를 해결할 수 있다

테스트 주도 개발(TDD)을 통해 코드 실수를 방지하라: 요구사항 문서 대신 실행 가능한 명세를 작성하라
레거시 코드를 만들지 마라: 레거시 코드는 자동화된 단위테스트와 인수테스트가 없는 코드다
빅뱅 통합은 진부하다: 지속적인 통합과 중첩된 동기화 기법을 사용하라

지식을 창출하라

표준은 개선하기 위해 존재하는 것이며 과학적 방법을 통해 누구나 변경하고 장려할 수 있도록 해야한다고 이야기한다

과학적 방법을 사용하라: 가설을 세우고, 신속하게 다양한 실험을 해보고, 문서를 간결하게 작성하고, 최선의 대안을 구현할 수 있도록 답을 가르쳐라
표준은 도전 받고 개선되기 위해 존재한다: 모든 사람들이 따라 하고 잘 알려진 실천법을 표준에 포함하되, 누구든지 표준에 도전하고 변경하도록 장려하라
예측 가능한 성과는 피드백에 기반한다: 예측 가능한 조직은 미래를 추측하고 그것을 계획이랗고 하지 않으며, 그보다는 미래가 펼쳐질 때 신속하게 대응하기 위한 역량을 개발한다

확정을 늦춰라

마지막까지 변화를 수용할 수 있도록 코드를 작성하낟. 돌이킬 수 없는 결정은 마지막에 내려라

의존성을 깨트려라: 시스템 아키텍처는 언제 어떤 기능이 추가되더라도 그것을 수용할 수 있어야 한다
옵션을 유지하라: 코드를 실험으로 생각하라. 변화를 수용할 수 있게 작성하라
돌이킬 수 없는 결정은 마지막 결정의 순간에 하라: 돌이킬 ㅜㅅ 없는 결정을 내리기 전에 가능한 많이 학습하라

전체를 최적화하라

고객 요구에서 SW 배포까지 전체적인 흐름에 초점을 맞춰야 한다

전체 가치 흐름에 초점을 맞춰라: 컨셉에서 현금까지, 고객 요구에서 소프트웨어 배포까지
완전한 제품을 인도하라: 소프트웨어만이 아닌 완전한 제품을 개발하라. 완전한 제품은 완전한 팀에 의해 만들어진다
더 높은 것을 측정하라: 국지적인 성과측정은 부분 최적화를 야기하며 낭비를 발생시킨다. 전체 가치 사슬의 시작과 끝의 소요시간, 일명 사이클 타임을 측정하라. 또는 인도된 비즈니스 가치로 팀 성능을 측정하라

사람을 존중하라

팀의 공동 목표 달성을 위해 자부심, 신뢰, 칭찬으로 맺어진 상호간의 책임의식을 가져야한다

팀은 자부심, 책임감, 신뢰, 칭찬을 통해 번성한다: 뭉서이 팀을 만드는가? 팀원들은 공동 모굪를 달성하기 위해 상호간 책임의식으로 뭉쳐있다
효과적인 리더십을 제공하라: 효과적인 팀에는 팀을 최고로 이끄는 훌륭한 리더가 존재한다
파트너를 존중하라: 파트너/외주 업체와 상생적 관계를 유지해야 한다. 그들은 우리의 종이 아니라 우리 SW를 함께 만드는 동료다

빨리 전달하라

한번에 전달되는 제품의 크기를 작게 하고 작업량을 줄여야 한다

신속한 인도, 고품질, 저비용은 공존할 수 있다
대기행렬 이론을 개발에 적용하라
일의 양을 할 수 있는 만큼으로 제한하라: 반복 개발에 안정적이고 반복 가능한 속도를 가져라. 고객에게 인도할 수 있는 역량에 맞게 대기열의 길이를 정기적으로 제한하라

린 소프트웨어 개발과 칸반

칸반은 생산시스템에서 일하는 작업자들이 어떤 작업을 해야 하는지 알려주는 작업 지시서에 해당한다. 린 소프트웨어 개발에서 이 칸반을 활용하면 다음과 같은 장점을 얻을 수 있다

워크플로를 가시화한다
- 일을 작게 나누어 카드에 하나씩 써서 벽에 붙인다
- 각 항목이 현재 어느 단계에 있는지 알 수 있도록, 워크플로를 나타내는 열에 제목을 붙인다
작업중인 것을 제한한다 (WIP)
- 워크플로상에 얼마나 많은 항목이 진행되고 있는지 제한을 둔다
작업에 소요되는 시간을 측정한다
- 한 항목을 완료하는데 걸리는 평균 시간 (사이클 타임으로 부르기도 함)
- 예측 가능하고 소요 시간을 최소화 하기 위해 프로세스를 최적화 한다.

[Agile] XP란?

디쟈이너 — Mon, 13 Dec 2021 08:30:57 +0900

XP는 eXtreme Programing의 약자로 애자일 소프트웨어 개발 방식의 하나이다. 보통 개발조직 기반의 중소규모 팀에 적합한 경량화된 개발방식임. 다른 애자일 개발 방식과 마찬가지로 '방법론'이라 불리는데 이견이 있을 수 있다.
특히나 XP는 테스트 주도 개발 (Test Driven Development), 일일 빌드 (Daily Build), 지속적인 통합 (Continous Integration) 등 개발 테크닉과 연관된 부분이 많기 때문에 종종 '방법론'으로 규정 짓는 것에 대해 논란이 되곤 한다. 팀의 개발 문화가 제대로 정립되어 있지 않거나, 계획 및 관리 중심으로 프로젝트를 유지하던 팀의 경우 XP 도입 초기에 난관이 존재하기도 한다.
최근에는 XP만 사용하기보다 스크럼등 보완적 애자일 개발 방식과 함께 사용하는 경우가 많다.
XP는 기본적으로 가치(value) 와 그 가치를 이루기 위한 실천법(practice), 이 두개를 큰 축으로 놓고 원칙(principle)을 세워서 그 둘 사이에 균형을 맞추는 것을 권장한다.

기원

1990년대 후반 켄트 백을 중심으로 여러 엔지니어들이 프로젝트를 진행하며 얻은 교훈을 기반으로 효과적이라 생각되는 개발 기법을 모아 방법론으로 정립함.

XP의 가치

의사소통
팀 활동을 하는 대부분의 조직이 발전적인 방향으로 존속하는데 있어 가장 중요한 점이 '의사소통'이라 할 수 있다. 이는 팀 원 각자가 겪는 문제에 대해 서로 인지하고, 문제가 반복하지 않도록 도우며, 문제가 감추어진 상태로 진행되다가 결국 걷잡을 수 없는 규모로 악화되지 않도록 하기 위해 매우 중요한 요소입니다. 의사소통을 잘 해야 한다는 점을 안다고 해서 쉽게 의사소통이 가능해 지는건 아니다. 이를 위해서는 개개인에게 의사소통시 발생하는 두려움과 마주할 때 필요한 개개인의 '용기'가 필요하다.
용기
SW개발 하는 것은 곧잘 커다란 미지의 두려움과 마주해야 하는 일상의 연속이다. 낯선 기수로가 모르는 사람들, 마찬가지로 알 수 없는 (고객을 포함) 타인의 감정과 대면했을 때 많은 경우 우리는 용기를 버리고 '속임', '회피', '분노' 혹은 '비난'을 선택하게 된다. 이를 극복하고 나아가기 위한 용기가 필요하다. 모르는걸 모른다 말할 수 있는 용기, 먼저 손을 내어 도움을 주고 도움을 요청할 수 있는 용기가 필요하다. 이 용기를 통해 우리는 성공적인 SW개발의 필수 요소인 '피드백'이라는 중요한 가치를 얻을 수 있게 된다
피드백
피드백은 SW개발 및 의사소통의 핵심이다. 좋은 팀은 의사소통과 피드백이 멈추지 않고 순환되는 분위기를 유지한다. SW 개발이 시작되면 가급적 빠른 시일 내에, 자주, 고객으로 부터 피드백을 받는 것이 좋다. 때로는 더 자주 더 많이 새로운 요구사항이 만들어진다는 점 때문에 피드백의 간격을 늘이거나 횟수를 줄이려는 경우가 많다. 이는 결과적으로 개발팀과 고객 모두에게 만족스럽지 못한 결과를 가져온다.
피드백을 자주 받고 새로운 요구사항을 제대로, 어렵지 않게 반영하기 위해서 유지해야하는 중요한 가치가 있다. 바로 '단순함'이다
단순함
SW개발은 어려운 문제를 해결하기 위해 점점 더 복잡해져가고 있다. 우리가 SW개발에 있어 직면하고 있는 큰 아이러니 중 하나는 복잡한 업무를 해결하기 위해 그 만큼이나 복잡한 방식으로 SW를 만들고 있다는 점이다. SW가 비용을 줄여주고 생활을 편리하게 만들어주는 것은 사실이지만, 복잡한 SW는 고장나기 쉽고, 문제를 일으키기 쉽고, 결국 버려지기 쉽게 변해버린다. 의사소통을 극대화하고 용기를 내서 적극적으로 피드백을 받는다 해도 SW가 간결하게 유지되지 않는다면 어려움은 해결되지 않을 것이다.
존중
위 가치를 추구하는 과정에서 반드시 유지되어야 하는 것은 바로 존중이다. 개개인에 대해 상호간의 '존중'이 없으면 팀은 결국 와해되어 버리거나 수준 높은 SW를 함께 개발하는 것이 불가능하게 된다.

소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다. 나도 중요한 사람이고, 당신도 중요한 사람이다.

켄트 백

XP의 기본 실천 방법들

함께 앉기: 팀 전체가 들어가기에 충분할 정도로 크고 열린 공간에서 진행한다
전체 팀: 프로젝트가 성공하기 위해 필요한 기술과 시야를 지닌 사람은 전부 팀에 포함시키다
정보를 제공하는 작업 공간: 작업 공간을 작업에 대한 것들로 채워라
활기찬 작업: 생산적으로 일할 수 있는 정도의 시간만, 그리고 일의 활력을 유지할 수 있는 정도의 시간만 일해라
짝 프로그래밍: 제품으로 출시할 프로그램을 두 사람이 컴퓨터 한 대에 앉아 작성해라
스토리: 고객에게 가치를 줄 수 잇는 최소한의 기능을 단위로 계획하라
일주일별 주기: 한 번에 일주일 분량의 일을 계획하라
분기별 주기: 한 번에 한 분기 분량의 일을 계획하라
여유: 어떤 계획이든, 일정에 뒤쳐질 경우 포기할 수 있는 비교적 급하지 않은 업무를 포함시켜라
10분 빌드: 10분만에 자동으로 전체 시스템을 빌드하고 모든 테스트를 돌려라
지속적인 통합: 변경한 것은 두 세시간만에 통합하고 테스트하라
테스트 우선 프로그래밍: 코드를 한 줄이라도 변경하기 전에, 자동화된 테스트를 먼저 작성하라
점진적인 설계: 시스템의 설계에 매일 투자하라

XP의 원칙

인간성: 소프트웨어는 인간이 개발한다
경제성: 이 모든것에 누군가는 돈을 지불한다는 경제성의 원칙을 인정한다
상호이익: 모든 활동은 그 활동에 관련된 모든 사람들에게 이익이 되어야 한다
자기 유사성: 어떤 해결책의 구조를 다른 맥락에도 적용해 보라
개선: 소프트웨어 개발에서 '완벽하다'란 없다. '완벽해 지기 위해 노력한다'만 있다
다양성: 팀에는 비록 갈등의 요소가 될 수 있을지라도 다양성이 필요하다
반성: 좋은 팀은 실수를 숨기지 않고 오히려 실수를 드러내어 거기에서 배운다
흐름: 개발의 모든 단계를 동시에 진행함으로써 가치 있는 SW를 물 흐르듯 끊임없이 제공해야 한다
기회: 가끔은 생각을 전환해 문제를 기회로 보는 방법을 배운다
잉여: SW개발에서 핵심적이고 해결하기 어려운 문제는 해결 방법을 여러 개 만들어 놓는다
실패: 성공하는데 어려움을 겪는다면 실패하라
품질: 품질을 희생하는 것은 프로젝트 관리의 수단으로 삼기에 효과적이지 않다
책임 소재: 어떤 일을 하겠다고 선언한 사람이 그 일의 책임도 가진다
아기 걸음: 단계를 작게 쪼갤때 걸리는 부하가, 큰 변화를 시도했다가 실패해서 돌아갈 때 드는 낭비보다 훨씬 작다는 사실을 인정하자

[Agile] 스크럼 알아보기

디쟈이너 — Sun, 12 Dec 2021 16:23:49 +0900

스크럼은 프로젝트 관리를 위한 애자일 방법론으로 추정 및 조정 기반의 경험적 관리 기법의 대표적인 형태이다.

기원

1986년 타케우치 & 노나카 교수가 HBR에 기고한 "The New New Product Development Game"을 기원으로 본다.
1995년 켄 슈와버와 제프 서덜랜드가 이 방법을 소프트웨어 개발에 소개하며 스크럼이라 부름

역할

제품 책임자 (Product Owner)
제품 기능 목록에 해당하는 백로그 (product backlog)를 만들고, 우선순위를 조정하거나 새로운 항목을 추가하는 일을 관리한다. 스프린트에 대해 계획을 수립할 때까지 중요한 역할을 하지만, 스프린트가 시작되면 최대한 팀 운영에 관여하지 않는걸 권장한다.
스크럼 마스터 (Scrum Master)
스크럼 원칙과 가치를 지키며 스크럼팀이 개발을 진행할 수 있도록 지원한다. 스크럼 팀의 업무를 방해하는 요소를 제거하기 위해 노력한다.
스크럼 팀 (Scrum Team)
보통은 5~9명으로 구성되며, 스프린트 기간동안 구현해야 할 기능을 사용자 스토리로 도출하고 구현한다. 스프린트 동안 구현해야 하는 기능을 완료하기 위해 노력하며 이를 위한 권한을 갖는다.

프로세스

스크럼의 프로세스는 스프린트와 3가지 유형의 미팅과 산출물이다.

스프린트 (Sprint): 달력 기준 1~4주 단위의 반복 개발 기간을 가리킨다
미팅: 일일 스크럼, 스프린트 계획, 스프린트 리뷰
산출물: 제품 백로그, 스프린트 백로그, 소멸 차트

스프린트 진행 방식

스크럼 산출물?

제품 백로그 (Product Backlog)
제품에 담고자 하는 기능의 우선순위를 정리한 목록이다. 고객을 대표하여 제품 책임자가 주로 우선순위를 결정한다. 제품 백로그에 정의된 기능을 사용자 스토리(요구 사항)라 부르며 업무량에 대한 추정은 주로 스토리 포인트라 불리는 기준을 이용한다.
스프린트 백로그 (Sprint Backlog)
하나의 스프린트 동안 개발할 목록으로 사용자 스토리와 이를 완료하기 위한 작업을 태스크로 정의한다. 각각의 태스크 크기는 시간 단위로 추정한다.
소멸 차트 (Burndown Chart)
개발을 완료하기까지 남은 작업량을 보여주는 그래프. 각 이터레이션 별로 남아있는 작업을 스토리 포인트라는 것으로 나타낸 것이다.

스크럼 미팅?

스프린트 계획 (Sprint Planing)
각 스프린트에 대한 목표를 세우고 제품 백로그부터 스프린트에서 진행할 항목을 선택한다. 각 항목에 대한 담당자를 배정하고 태스크 단위로 계획을 수립한다
일일 스크럼 (Daily Scrum)
매일 진행하는 15분간의 프로젝트 진행상황 공유 회의이다. 모든 팀원이 참석하여 매일매일 각자가 한 일, 할 일, 문제점 등을 이야기한다.
스프린트 리뷰 (Sprint Review)
스프린트 목표를 달성 했는지 작업 진행과 결과물을 확인하는 회의이다. 스크럼 팀은 스프린트 동안 작업한 결과를 참석자들에게 데모하고 피드백을 받는다. 가능하면 해당 스프린트 동안 진행된 모든 작업에 대해 데모한다. 고객이 참여하면 좋다. 이때, 스크럼 마스터는 스프린트 동안 잘된 점, 아쉬웠던 점, 개선할 사항 등을 찾기 위해 회고를 진행할 수 있다.

특징

투명성 (Transparency)

프로젝트가 현재 어떤 상태인지, 계획대로 진행되고 있는지, 어떤 문제점을 가지고 있는지 정확히 파악하기는 어려운 일이다.
스크럼은 스크럼 회의, 소멸 차트, 스프린트 리뷰와 같은 기법을 이용해 다른 방법론에 비해 프로젝트의 상태나 문제점을 잘 드러낸다

타임 박싱 (Time Boxing)

스크럼을 구성하는 모든 실천법에 있어 시간은 매우 중요하다. 일일 스크럼은 매일같이 15분이라는 짧은 시간에 진행해야 하며, 스프린트 리뷰는 매 이터레이션마다 주기적으로 진행한다. 스크럼 자체를 진행하는데 들어가는 시간을 엄격하게 제한함으로써 프로젝트 진행에만 집중할 수 있게 해준다.

커뮤니케이션 (Communication)

스크럼에서는 팀원 간 커뮤니케이션을 원활하게 하기 위해 많은 노력을 기울인다. 일일 스크럼에서 각 작업자들이 어떤 방해물(blocker)로 인한 문제를 겪고 있는지 공유하고, 흔히 플래닝 포커라는 방식으로 진행되곤 하는 각 사용자 스토리의 구현 난이도/시간을 토론하는 절차는 프로젝트 내 커뮤니케이션을 원활하게 해주는 스크럼 특징 중 하나이다

경험 주의 모델 (Inspct & Adapt model)

스크럼은 고유의 프로세스 모델을 가지고 있지만, 많은 기법들이 프로젝트에 참여하는 개개인의 경험에 기반한다. 프로젝트마다 고유한 상황과 특징을 가지고 있기 때문에 기존의 정형화된 프로세스로는 이런 최근의 프로젝트 상황을 따라가기 어렵다. 그러므로 스크럼은 기본적인 구조만 같을 뿐, 실제로 일을 진행하게 되면 팀마다 달라지는 것을 허용한다.

더 알아보기

사용자 스토리 (User Story)
통상 요구사항 이라 부르는 시스템의 기능 설명을 사용자 관점에서 이야기 한 것이다. 모든 요구사항을 사용자 스토리로 간주해서는 안되고, 사용자에게 가치 있는 것들만 골라내어야 한다. 요구 사항이 아니라 사용자 스토리라 부르는 이유는 '사용자 관점에서 사고' 한다는 의미가 되겠다.
스토리 포인트 (Story Point)
사용자 스토리를 실제 동작하는 기능으로 구현하는게 얼마나 어려운지 나타내는 값이다. 이 포인트는 개인이 주관적으로 정하는것이 아닌, 스토리 포인트를 사용하는 집단 다수의 관점에서 내리는 객관적인 값이다. MD(Man-Day) 로 나타내는 업무량 척도와는 다르게, 구현하려는 사용자 스토리 그 자체의 난이도에만 온전히 집중한다.

CSS 작성시 속성 선언 순서

디쟈이너 — Thu, 9 Dec 2021 15:33:57 +0900

CSS를 작업하다보면 하나의 클래스에 여러개 속성을 선언하는 경우가 자주 발생한다. 속성 작성에 규칙이 있다면 추후 코드를 들여다볼 때 조금 더 내용 파악이 쉽지 않을까? 하는 마음에 구글링을 해보니, 역시나 CSS 선언 순서와 관련된 내용이 방대하고도 자세하게 정리되어 있었다.

NHN 코딩 컨벤션

속성을 선언할 때는 그 쓰임새가 레이아웃과 관련이 큰 것에서 시작하여 레이아웃과 무관한 것 순서로 선언한다. 관련 속성은 대표되는 속성 다음으로 선언하며, 아래에 표기된 순서대로 선언한다.

레이아웃
1. display
2. visibility
3. overflow
4. float
5. clear
6. position
7. top
8. right
9. bottom
10. left
11. zindex
Box
1. width
2. height
3. margin
4. padding
5. border
배경
1. background
폰트
1. font,color
2. etter-spacing
3. text-align
4. text-decoration
5. text-indent
6. verticalalign
7. white-space
기타
1. 위에 언급되지 않은 나머지 속성들로 폰트의 관련 속성 이후에 선언하며, 기타 속성 내의 선언 순서는 무관함
2. 밴더속성과 핵속성은 해당 속성 뒤에 선언

Web Standards Darum

display (표시)
overflow (넘침)
float (흐름)
position (위치)
width&height (크기)
padding&margin (간격)
border (테두리)
background (배경)
color/font (글꼴)
animation
기타

Code Guide - CSS Declaration order

관련 속성 선언은 다음 순서로 그룹핑한다.

Positioning (포지셔닝)
Box model (박스 모델)
Typographic (타이포그라피)
Visual (시각 효과)
Misc (기타)

문서의 정상적인 흐름에서 엘리먼트를 없앨 수 있고, 박스 모델 관련 스타일들을 재정의할 수 있기 때문에 포지션 관련 선언이 가장 먼저 온다. 박스 모델이 그 다음에 오며 해당 엘리먼트의 크기와 위치를 지정한다.

나머지는 이전의 두 섹션에 영향을 주지 않거나 엘리먼트의 내부에서만 필요한 내용이기 때문에 마지막에 온다.

Wrap up

구글링을 통해 얻을 수 있는 다른 CSS 선언 순서도 유사한 형태를 띄고 있다.

정리하자면 밖에서부터 안쪽의 순서로 선언하길 권장하고 있다.

엘리먼트의 폰트 컬러, 배경 색상을 지정해뒀다 하더라도 화면에 보일것이냐 보이지 않을것이냐가 더욱 중요한 사항이기 때문일 것이다.

작업할 때는 구조와 스타일을 분리하기 때문에 위치 선정, 사이즈, 색상 디테일까지 하나의 엘리먼트에 선언하는 경우는 거의 없다.

그래도 CSS를 선언할 때 최소한의 순서를 숙지해두면 작성과 유지보수에 모두 도움을 줄 수 있을것이다.

참고 자료

ColorBox를 활용해 컬러 팔레트 만들기

디쟈이너 — Mon, 6 Dec 2021 18:57:04 +0900

colorbox.io 를 활용해 디자인 시스템의 컬러 팔레트를 구성해보자.

lyft의 디자이너였던 Kevyn Arnott가 새로운 ColorBox를 만들었다.

간단하게 특징을 요약해보자.

멀티 컬러 생성
한 워크스페이스에서 여러 개의 색상 팔레트를 추가할 수 있다
ColorBox로 멀티 컬러 팔레트 생성

접근성 표시 내장
색상을 알고리즘 접근 방식으로 풀어나간 이유는 모든 사람이 접근성에 최적화된 색상 시스템을 제작할 수 있도록 돕고싶었기 때문이라고 한다.
ColorBox에서 접근성과 관련하여 디테일하게 라벨까지 선택이 가능하다. 오른쪽 패널에서 색상 대비 레벨도 껐다 켤 수 있다.
Constast Colors에는 작성한 컬러 팔레트가 텍스트로 들어갈 배경 색상을 정의해준다고 생각하면 좋다.
ColorBox 우측 색상 대비 등 설정 화면
다크 모드
컬러를 선택한 뒤, 옵션 탭에서 다크모드를 활성화하면, 다크모드에 적합한 색을 자동으로 생성해준다.
ColorBox에 다크 모드 팔레트 자동 추가

매뉴얼하게 다크모드를 추가도 가능하다.
기타 알고리즘
1. 색조(Hue) 회전
  1. 색조(Hue) 회전(Rotation)이 Clockwise, Couter 두 종류 적용 가능하다
2. 사용자 정의 곡선
  1. 같은 명도(Brightness)를 적용해도 색조(Hue)에 따라 눈으로 볼 때 어떤 색은 다른 색보다 더 밝아보인다. 색조별로 각각 S와 B 값을 조정해줄 수 있다.
3. 기타
  1. easeOut: 빠르게 다음 값으로 이동하며 마지막에 자연스럽게 변화가 느려진다
  2. easeIn: 느리게 이동하다가 빠르게 끝난다

Typography 규칙 line-height 설계하기

디쟈이너 — Tue, 30 Nov 2021 12:02:30 +0900

포토샵과 같은 일부 현대 디자인 애플리케이션은 여전히 'leading'라는 용어를 사용하는 반면 HTML과 CSS에서는 이 속성을 'line-height'라고 부른다. leading, line spacing, line height는 모두 같은 것을 말합니다.

line height 또는 line spacing은 일반적으로 글꼴 크기의 백분율로 측정됩니다. 일반적인 통념으로는 130-150%의 행간격이 가독성에 이상적이지만 200%까지 허용됩니다.

완벽한 line height는 글꼴 자체의 디자인과 크기에 따라 달라집니다. 모든 텍스트에 적용되는 매직 넘버는 없습니다. 글꼴 크기의 1.5배 선 높이로 시작하는 것이 좋은 시작이며, 그에 따라 조정할 수 있습니다.

1.5 라인 높이를 사용할 때는 8 포인트 그리드 시스템을 사용하면 잘 작동합니다. 줄 높이가 8이고 기본 글꼴 크기가 16인 것이 이 원리에 딱 맞습니다.

최적의 줄 간격과 글꼴 크기를 계산하는 보다 발전된 방법은 황금 비율 타이포그래피 계산기를 참조하십시오. Justinmind.com은 line spacing에 대한 UX 모범 사례에 대한 전체 기사를 제공하며 다음 예를 사용합니다.

100% 단락에서, 여러분은 인접한 줄에 있는 글자들이 서로 위험할 정도로 가까이 오는 것을 볼 수 있습니다. 이것이 문제가 되는 이유는 약간의 시각장애가 있는 사람들은 읽기가 훨씬 더 어려워질 것이기 때문이다. 150%로 공간의 균형이 잘 잡혀 있고 텍스트를 읽을 수 있는 것처럼 느껴집니다. 반면 250% 띄어쓰기의 문단은 줄 간격이 너무 과장되어 텍스트를 읽는 것이 부자연스럽게 느껴진다. — 줄 간격 형식에 대한 UX 모범 사례 justinmind.com

Line Spacing은 글자 크기가 작을수록 실제로 증가해야 한다. 작은 글꼴은 이미 읽기가 더 어렵고, 눈이 쉽게 따라 할 수 있는 더 많은 공간이 필요하기 때문이다.

저스틴마인드의 톰 클라크는 line spacing에 대해 다음과 같은 6가지 황금 규칙을 제안합니다.

최적의 가독성과 접근성을 위해 약 140-180%를 목표로 합니다.
줄 길이를 70~80자로 제한합니다.
글꼴 크기는 16pt 이상이어야 합니다.
작은 글꼴은 띄어쓰기가 더 필요합니다.
따옴표나 다른 짧은 텍스트의 간격을 좁혀 실험합니다.
글꼴 또는 글꼴 크기를 변경할 때 줄 간격을 확인하십시오.

lazy loading

디쟈이너 — Fri, 5 Nov 2021 19:57:00 +0900

Lazy loading이란?

페이지 내에 바로 필요하지 않은 이미지들의 로딩 시점을 뒤로 미룬다.

성능 향상

페이지 초기 로딩 시 필요한 이미지의 수를 줄일 수 있다. 리소스 요청을 줄이는것은 다운로드 bytes를 줄이는 것이다.
비용 감소

이미지가 보여지지 않으면 절대 로딩하지 않으므로, 페이지 내에서 전달할 총 바이트 용량을 줄일 수 있다.

기술

태그를 이용한 일반적인 방법
- 이미지 로딩을 사전에 막는다.
- <img> 태그를 사용하는 경우, 이미지를 가져올 때 src 속성을 사용하는데, HTML은 무조건 모든 이미지의 src를 로드한다.
- 이를 막기 위해 src 가 아닌 data-src 에 이미지 URL을 지정한다.
- 그리고 이미지가 뷰포트에 들어오자마자 로딩할 수 있도록 브라우저에게 알려준다.
자바 스크립트 이벤트로 image load 하기
- 브라우저 내 scroll, resize, orientationChange 이벤트 리스너를 이용할 수 있다.
- scroll 이벤트는 사용자가 페이지에서 스크롤하는 시점을 확인한다.
- resize는 브라우저의 크기가 바뀔때 발생한다.
- orientationChange는 디바이스 화면이 가로에서 세로(혹은 반대로) 바뀔때 발생한다.
- 아직 로딩되지 않은 이미지를 모두 찾고, 윈도우 높이, 스크롤 위치, 이미지의 위치를 이용해 어떤 이미지가 뷰포트 안에 있는지 확인한다.
- 뷰포트 안에 들어가면 <img> 태그의 <data-src> 속성에 지정된 URL을 <src> 속성에 넣어 이미지를 로드한다.
- 이후, 나중에 트리거 이벤트를 위해 로딩을 지연시킬 이미지로 식별하던 lazy class 를 제거한다. 모든 이미지가 로딩되면 트리거를 일으키던 이벤트 리스너를 제거한다.
Intersection Observer API를 이용하여 image load 하기
- 모든 이미지에 옵저버를 부착한다.
- 엘리먼트가 뷰포트에 들어왔을 때, API가 감지하고 isIntersecting 속성을 이용해 URL을 data-src 에서 src 속서응로 이동시킨다. 전부 로드되면 lazy class 를 제거하고 옵저버도 제거한다.
Native Lazy Loading
- 최신 Google Chrom 브라우저 (Chrmone 76) 에서 지원하는 기능
- <img> 태그에 loading 속성만 추가하면 된다
- loading 속성에 사용할 수 있는 값
  - lazy - 뷰포트에서 일정한 거리에 닿을 때까지 로딩을 지연시킵니다.
  - eager - 현재 페이지 위치가 위, 아래 어디에 위치하던 상관없이, 페이지가 로딩되자마자 해당 요소를 로딩합니다.
  - auto - 이 속성은 디폴트로 로딩을 지연하는 것을 트리거합니다. 기본적으로 이것은 loading 속성을 쓰지 않을 것과 같습니다.
- 반드시 height 와 width 를 인라인으로 추가해야한다
CSS로 불러온 Background image를 Lazy Loading 하기
- CSS background image를 로드하기 위해서는 현재 문서내 DOM 노드에 CSS 스타일이 적용되는지 여부를 결정하기 위해 CSSOM(CSS Object Model)과 DOM(Document Object Model) Tree를 구성해야한다.
- 구현 방식은 위와 똑같다. 엘리먼트가 뷰포트에 들어올때 까지 CSS background image 속성을 적용하지 않는다.
- 이 때, CSS는 아래와 같은 처리가 필요하다
  - lazy 클래스 추가시 background-image: none 처리
  - 엘리먼트가 뷰포트에 들어오면 lazy 클래스 제거

사용성 향상하기

올바른 image placeholder 사용하기
- 단색 이미지(회색 등) 사용하기
- 이미지에 사용하는 주요 색상 사용하기
  - 이미지의 첫 1x1 픽셀로 스케일을 감소시키고, 해당 픽셀 요소로 placeholder를 채움
  - ImageKit을 사ㅛㅇ해 주요 단일 색상을 얻을 수 있음
- 저화질 이미지로 대체하기
  - 주요 색상보다 더 좋은 방식이다
  - 원본 이미지의 저화질 흐린 이미지를 사용함으로써 원본 이미지에 대해 어느정도 추측하도록 유도할 수 있다.
이미지 로딩을 위한 버퍼 시간 추가하기
- 이미지가 뷰포트에 들어왔을 때 이미지가 로딩되는 경우. 스크롤을 많이 했을때 사용자의 대기시간이 급격히 늘어날 수 있다. 이는 사용성에 좋지 않다
- 이미지의 로딩 트리거 시점에 마진값을 넣는다.즉, 뷰포트보다 500px 정도 아래에서 로딩을 하는것이다.
Lazy loading으로 인해 레이아웃이 깨지는 문제 방지하기
- 문제점: 이미지가 없을 때, CSS로 따로 지정해주지 않으면 콘텐트를 감싼 컨테이너는 공간을 따로 가지지 않아 0x0 픽셀로 공간이 없다가 이지가 추가되면 컨테이너를 리사이징 한다.
- 해결 방법: 컨테이너에 너비/높이를 지정해 문제를 피할 수 있다.

lazy loading 테스트 방법

크롬 브라우저 개발자 도구 > 내 네트워크 > 이미지 확인
스크롤을 아래로 내릴 때 이미지가 로딩된다

Skeleton UI

(더 찾아보고 싶은고..)

참고 자료

[2020.11.29] 웹 성능 최적화를 위한 Image Lazy Loading 기법

[Chrome] 크롬 브라우저에서 접근성 (색맹) 시야 테스트 하는 방법

디쟈이너 — Thu, 21 Oct 2021 15:08:05 +0900

개발자 도구 (F12) 에서 More tools → Rendering 메뉴

스크롤을 아래로 내리다보면 색맹을 시뮬레이션 해볼 수 있는 기능이 있음

Blurred vision: 흐린 시야
Protanopia: 적녹색약
- blue와 green, red와 green 구분이 어려움), 적색과 녹색을 혼동하거나 적색과 녹색 또는 청록색을 혼동하는 색맹의 한 형태입니다.
Deuteranopia: 제2색각이상(녹색약)
- 색조 감별에 영향을 미치는 것은 프로토노피아와 비슷하지만, 흐릿한 효과는 없다. 남성 인구의 약 1%에서 발견된다.
Tritanopia: 제 3색각이상(청색맹)
- 청색 망막 수용체가 전혀 없는 채 적색과 녹색 원추 색소만 존재하는 매우 드문 색각 장애다. 파란색은 초록색, 노란색과 오렌지는 분홍색, 그리고 보라색은 진한 빨간색으로 보입니다.
- 블루 옐로우 색맹이라고도 불린다. 이런 유형의 색맹을 가진 사람들은 파란색을 녹색과, 노란색을 보라색과 혼동한다. 파란색과 노란색에 대한 인식 저하.
Achromatopsia: 전색맹

색약들이 보는 색깔 스펙트럼 (출처: genassist)

색맹과 관련된 용어를 한글로 번역할 수 있는 용어가 없다는게 충격적이다.

용어는 wiki에 등록된 문서를 참고하여 작성했다.

참고 문서

[Figma] Branch 기능 살펴보기

디쟈이너 — Thu, 14 Oct 2021 10:26:38 +0900

피그마는 (오토 세이브 되는..) 버전 히스토리 기능도 매우 훌륭하다고 생각했는데, 어느새 워크 플로우를 관리하기 위한 브랜치 기능까지 추가되었다.

피그마에 작성된 브랜치 문서를 살펴보았다.

최근 브로들리 사용중이다. 이전 툴과는 다르다. 첫번째 원칙으로 단순성과 일관성에 초점을 맞췄다.

브랜치를 사용하기 적절한 예제

이미 존재하는 소스를 기반으로 작업을 시작할 때 고려하면 좋다. 특히 실험적이고, 반복적인 경우

디자인 라이브러리 유지보수

메인 파일은 항상 하나로 유지됨
공통 스타일 추가하거나 수정할때
기존에 존재하던 컴포넌트나 배리언츠 수정할때
라이브러리에 새로운 콤포넌트 만들때
컴포넌트 수정 제안이 편리해짐

의사 결정권자 혹은 콜라보레이터에게 공유할 때

개발 파트에 시안을 전달하기 위해 작업을 멈춰야할 때

기능을 위한 디자인 작업이 완료된 지점을 개발 파트에 공유할 때 시점을 지정해 전달해 디자인을 명확히할 수 있다.
디자인이 개발까지 완료되면, 디자인 시안은 메인 파일에 병합할 수도 있고 코드에도 병합된다
디자인과 개발 사이에 유사한 워크플로를 만들어 아이데이션에서 릴리즈까지 공통된 언어를 중심으로 응집력을 만들 수 있다

격리된 디자인 테스트 및 사용자 테스트

메인 디자인에서 분기된 파생 디자인의 프로토타입을 테스트할 수 있다

브랜치 모범 사례

네이밍 룰

명확하게 커뮤니케이션 할 수 있는 네이밍이 필요하다
개발 파트의 일반적인 브랜치 네이밍을 공유 받아 같이 사용해도 된다. 대화 및 문서에서 동일한 정보를 참조할 수 있기 때문에 전체 프로세스에 걸쳐 작업하는 데 도움이 될 수 있다.
예를들어, 이슈 티켓 이름, 우선순위 플래그, 업무 유형, 이모지 등을 접두어로 사용할 수 있다

브랜치 병합 (merging branches)

변경 사항을 메인 파일에 적용하고싶을 때, 브랜치를 병합한다.
엔지니어링의 PR 프로세스와 유사하다
코멘트와 @멘션을 활용하는것이다. editor에게 알람이 뜨면, 검토 해야할 브랜치로 넘어가 코멘트를 확인하고 추가적인 의견을 남길 수 있다 (review 단계~)
브랜치가 메인 파일에 병합되면, 자동적으로 모든 코멘트와 브랜치가 아카이브된다.
기존 버전으로 복원은 version history에서 가능하다

브랜치 보관 (archiving branches)

미사용 디자인을 아카이브 해도 메인 파일과 계속 연결 되어 있게 된다
보관된 브랜치는 언제든지 보거나, 복원할 수 있다
파일이 오래되어 다른 사용자가 파일에 액세스하는데 혼동을 일으킬 수 있는 여러 페이지가 생기는걸 방지할 수 있다

브랜치 사용에 부적절한 예제

탐색(exploration)을 위한 새 파일 만들기

처음부터 시작하거나 기존 설계에 대한 완전한 기초 정비를 수행하는 경우 새 파일부터 시작하거나 기존 파일을 복제하는 것이 좋다
이렇게 하면 모든 새 작업이 자체 파일로 완전히 분리되어 프로젝트, 팀 또는 개인 draft에 저장될 수 있다

모두 합의하는 마이너 업데이트

사소한 업데이트를 수행 중이거나 여러 공동작업자가 모두 약간의 다듬기 변경을 하는 경우 기본 파일을 업데이트한다
예를 들어 편집 복사, 레이어 구성, 공유 스타일을 사용하기 위한 색상 업데이트 또는 프로토타입의 와이어링은 메인 파일에서 바로 수행되어도 좋다

적극적으로 다른 디자인을 참조(referencing) 하는 경우

여러 개념을 탐색하거나 각 디자인을 적극적으로 참조해야 할 수 있는 다른 디자인과 협업하는 경우 동일한 파일의 페이지를 사용하는 것이 더 편리할 수 있다
페이지를 사용하면 개념 또는 공동작업자별로 여러 개의 스크래치 패드를 사용할 수 있으므로 페이지 간에 항목을 빠르게 이동할 수 있다

현재의 워크플로우를 유지

피그마는 이전 저장 지점을 새 파일로 되돌리거나 복제할 수 있는 자동 저장 및 버전 기록이 있다 (훌륭훌륭 )
현재와 같이 계속 작업하고 협업할 수 있음

더 읽을거리: Create branches and merge changes

참고자료:

archuive

디자인 시스템 컴포넌트 만들 때의 고민, State와 Status의 차이?

State (상태)

2. Status (상태 표시)

비교 및 구분

사용 예시

[Framer] CMS의 Filter 기능을 활용해 탭을 구성하는 방법

1. CMS 컬렉션 설정하기

2. 포스트 목록을 컴포넌트화하기

3. 필터 버튼 추가 및 설정

4. 필터 변형(variant) 추가하기

5. 날짜 필터 적용하기

6. 필터 버튼과 변형(variant) 연결하기

github GPG 설정 했는데 Signed-off-by: 표시 안되는 문제

필터를 디자인할 때 고민해야할 UI 및 UX

UI 필터란 무엇인가?

필터가 사용자 경험에 미치는 영향

사용자 친화적인 필터 디자인의 원칙

단순함과 명확성

반응성과 피드백

필터의 우선순위 설정

유연성과 제어

가시성과 접근성

플랫폼 간 필터 디자인

효과적인 UI 필터 설계 방법

자연어 사용

필터 내 검색 기능 제공

점진적 공개 활용

시각적 신호 활용

접근성 고려

좋은 필터 UI 디자인 사례

에어비앤비(Airbnb)

부킹닷컴(Booking.com)

스포티파이(Spotify)

아마존(Amazon)

구글 지도(Google Maps)

토스트 알림, 어떻게 사용해야할까.

토스트 알림(Toaster Notification)/토스트(Toast)이란 무엇인가요?

언제 표시해야 하나요?

배치(위치)

접근성

애니메이션 조정

크기 조정

Clone vs. Duplicate: 개발자 중심 제품 디자인 시 용어 선택

Clone: 기술 사용자들을 위한 용어

선호 대상

의미

사용 예

추천 이유

Duplicate: 비기술 사용자들을 위한 용어

선호 대상

의미

사용 예

추천 이유

결론 및 추천

개발자 중심의 제품

더 넓은 사용자 대상 또는 명확성을 중시하는 경우

웹 접근성: 모두를 위한 디자인의 중요성

왜 접근성이 중요한가?

포괄적 디자인이란 무엇인가?

POUR 원칙: 인지 가능, 운용 가능, 이해 가능, 견고성

디자이너가 할 수 있는 일

시각적 경험 개선하기

청각적 경험 개선하기

운동 경험 개선하기

성능 개선하기

공감 능력 향상하기

바우하우스에서 배우는 협업과 창의성: 현대 UX 디자인에 적용하기

UX 디자인과 바우하우스 철학

협업의 중요성

현대 UX 디자인에의 적용

바우하우스와 현대 UX 디자인의 유사점

사용자 중심 디자인

기능성과 실용성

협업과 통합

바우하우스 철학의 현대적 해석

디자인 원칙의 적용

협업의 강화

실용성과 기능성의 중시

결론