인터페이스 다듬기 (Interface Polish)
인터페이스를 더 읽기 쉽고, 대상 지점을 정확히 가리키기 쉽고, 탐색하기 쉽게 만듭니다. 존재하는 제품(타입페이스, 아이콘, 색상, 밀도, 컴포넌트, 프레임워크)에서 시작합니다. 이러한 선택들 간의 관계를 개선합니다. 관찰된 문제나 사용자 요청이 정당화할 때만 시각적 관례를 변경합니다.
사용 시 마찰점 찾기
실제 화면에서 대표적인 작업을 하나 추적합니다. 메뉴를 열고, 행을 선택하고, 패널을 좁히고, 필터를 적용한 후, 다시 콘텐츠로 돌아갑니다. 눈에 보이는 문제 뒤에 숨은 컴포넌트와 토큰 정의를 읽습니다. 스크린샷은 계층 구조와 간격을 보여주고, 인터랙션은 잘린 포커스, 닿을 수 없는 컨트롤, 튀는 모션을 드러냅니다.
미관상의 불일치보다 읽기나 액션을 방해하는 실패를 우선시합니다. 각 제안된 변경 사항을 구체적인 증상(사라지는 메타데이터, 뷰 밖으로 밀려나는 후행 액션, 떨리는 숫자, 크기는 변하면서 불투명도는 희미해지는 메뉴)과 연결합니다. 광범위한 요청의 경우, 일관성 있는 작업을 선택하여 구현합니다. 검토 전용 요청의 경우, 위치와 증거를 포함한 조사 결과를 제시합니다.
편집 전에 저장소의 지침, 지원되는 툴체인, 기존 검사 사항을 확인합니다. 현재의 캐스케이드와 겹치는 변경 사항을 읽습니다. 한 브랜치에서 동일해 보이는 토큰 대체가 다른 브랜치에서 해당 토큰을 업데이트한 후에는 지오메트리를 변경할 수 있습니다.
텍스트와 아이콘에 별도의 역할 부여하기
적은 수의 텍스트 역할을 설정합니다. 행 제목이 이끌고, 메타데이터가 설명하고, 액션이 인식 가능하도록 합니다. 밀도 높은 데스크톱 인터페이스는 14px/600 제목, 12px/400 메타데이터, 16px 섹션 레이블을 사용할 수 있습니다. 이를 출발점으로 간주합니다. 읽기 중심 또는 터치 우선 앱은 더 큰 텍스트가 필요할 수 있습니다. 필요한 굵기를 표현할 수 있다면 기존 폰트를 유지합니다.
더 많은 상자나 색상을 추가하기 전에 간격과 굵기를 사용하여 역할을 분리합니다. 관련 메타데이터는 의도적인 간격을 두고 제목 아래에 둡니다. 업데이트되는 개수에는 표 형식의 숫자를 사용하고, 예상되는 가장 큰 값에 충분한 너비를 확보합니다. 짧은 제목의 균형을 맞추거나 지원되는 곳에서 더 나은 단락 줄바꿈을 사용하되, 너비가 좁은 패널을 줄바꿈 규칙에 의존하여 고치지 않습니다.
지원되는 모든 테마에서 실제 배경에 대한 보조 텍스트의 명도 대비를 측정합니다. 일반 텍스트는 최소 4.5:1의 명도 대비가 필요합니다. 불투명도는 표면 색상과 결합되므로, 그럴듯한 토큰 값만으로는 충분하지 않습니다. 제품의 팔레트와 의미론적 색상 역할을 유지합니다. 특정 폰트, 강조 색상, 아이콘 라이브러리, 또는 중립 색상 전용 테마가 필요하지 않습니다.
역할 내에서 아이콘 크기와 광학적 무게를 일관되게 유지합니다. 스트로크 너비를 변경하기 전에 기존 세트를 검사하세요. 라이브러리마다 다른 지오메트리를 사용하기 때문입니다. 작은 글리프는 더 큰 버튼 안에 들어갈 수 있습니다. 아이콘 전용 컨트롤에는 접근 가능한 이름을 제공하고, 보조 기술에는 장식용 중복 항목을 숨깁니다.
지오메트리가 액션을 지원하도록 만들기
기존 반경 스케일을 일관되게 사용합니다. 스케일 자체에 작업이 필요한 경우, 모든 모서리를 하나의 반경으로 교체하는 대신 크기를 역할(예: 작은 칩, 컨트롤, 플로팅 패널)에 매핑합니다. 중첩된 형태의 경우, 내부 반경은 외부 반경에서 실제 인셋(테두리 및 패딩 포함)을 뺀 값으로 계산합니다. 필요할 때는 0으로 고정(clamp)합니다.
보이는 아이콘 또는 텍스트와는 별도로 인터랙티브 대상의 크기를 조정합니다. 컴팩트한 컨트롤의 경우 최소 24x24 CSS 픽셀을 목표로 하고, 공간이 허락하는 곳에서는 더 관대한 터치 대상을 사용합니다. WCAG에는 간격 및 기타 예외 사항이 있습니다. 이를 신뢰하기 전에 명시적으로 확인하세요. 버튼 패딩이나 래핑 레이블을 선호합니다. 보이지 않는 히트 영역 확장은 잘림, 겹침, 인접 컨트롤의 우발적 활성화를 확인해야 합니다.
그룹화, 상태, 또는 높이(elevation)를 위해 테두리와 그림자가 도움이 될 때 사용합니다. 또 다른 그림자 평면이 약한 계층 구조에 대한 첫 번째 수정인 경우는 드뭅니다. 잘린 목록 내부에서 보이는 포커스를 유지하고, 적절할 때는 인셋 처리를 사용합니다. 터치 장치를 포함하여 호버 없이도 필수 액션을 발견할 수 있도록 합니다.
컴포넌트가 가진 공간에 반응하기
넓은 창이라도 사이드바나 인스펙터가 열리면 좁은 작업 영역을 포함할 수 있습니다. 재사용 가능한 헤더, 행, 컴포저의 크기를 사용 가능한 패널 너비로 조정합니다. 관련 조상에 컨테이너 쿼리를 배치하고 자손을 적용합니다. 크기 쿼리는 자체 쿼리 컨테이너의 크기를 조정할 수 없습니다. 컨테이너를 도입한 후에는 오버레이 위치 지정 및 쌓임 순서를 확인합니다.
무엇이 먼저 축소될지 결정합니다. 레이블을 min-width: 0으로 축소하고, 후행 액션을 위한 안정적인 트랙을 확보한 다음, 기본 작업을 압축하기 전에 보조 크롬을 축소합니다. 숨겨진 레이블에도 여전히 접근 가능한 이름이 필요합니다. 장식용 공개(disclosure)를 제거하는 것과 행을 활성화하는 유일한 방법을 제거하는 것은 다릅니다.
긴 제목, 큰 개수, 실제 메타데이터, 빈 목록, 필터링된 결과를 테스트합니다. 뷰가 비어 있는 이유를 설명하고(예: 필터 지우기, 항목 생성) 적절한 복구 방법을 제공합니다. 배경 새로고침 중에는 기존 콘텐츠가 여전히 유효한 경우 유지합니다. 요청이 시작되었다고 해서 로드된 행을 스켈레톤으로 대체하지 마십시오.
패널 반응성, 중첩 컨트롤, 또는 오버레이를 변경할 때는 구현 함정을 읽으십시오.
모션이 상태 변화와 일치하도록 만들기
이미 존재하는 애니메이션 시스템과 이징 토큰을 사용합니다. 클래스나 토큰 교체가 모션을 변경한다고 주장하기 전에 계산된 스타일을 검사합니다. 실제로 변경되는 속성만 명시적으로 전환합니다. 개별 CSS scale 및 translate는 transform과 별개입니다.
일상적인 컨트롤에는 작은 이동과 빠른 안정화를 선호합니다. 등장은 약 150-250ms, 더 짧은 퇴장이 유용할 수 있지만, 빈도와 목적이 타이밍을 결정합니다. 아무것도 없는 곳에서 행을 확장하거나, 작업 목록에서 느린 지연 도착(staggered arrival), 스트리밍 업데이트마다 애니메이션을 적용하는 것을 피하십시오. 누군가가 변경 사항을 따라가는 데 도움이 되는 것만 애니메이션화하십시오.
호버 움직임은 호버가 가능한 정밀 포인터 조건 뒤에 유지합니다. 필수 컨트롤은 키보드 및 터치 사용자에게 계속 사용 가능해야 합니다. 열기 중에 닫기는 보이는 상태에서 역방향으로 진행되어야 하며, 종료되는 요소는 입력 수신을 중지해야 합니다. 다이얼로그나 메뉴 프리미티브가 이미 존재와 포커스를 관리하는 경우, 지원되는 종료 라이프사이클을 사용하십시오. 두 번째 언마운트 타이머나 경쟁하는 포커스 핸들러를 추가하지 마십시오. 논리적 해제와 포커스 복원은 장식용 종료 모션을 기다리지 않고 프리미티브의 동작을 따라야 합니다.
축소 모션(reduced motion)은 공간적 이동 없이 동일한 사용 가능한 최종 상태에 도달해야 합니다. 전환이 제거될 때 완료 로직을 확인하십시오. 복잡한 스프링, 안무, 또는 애니메이션 아키텍처에는 전용 모션 스킬을 사용하십시오. 이 작업에는 다른 스킬 패키지를 설치할 필요가 없습니다.
사람들이 사용할 결과 확인하기
모든 변경 후 결합된 결과를 동일한 데이터로 이전과 이후를 비교하여 검사합니다. 좁은 패널이 있는 넓은 화면, 전화기 크기의 뷰포트, 지원되는 테마, 키보드 탐색, 터치 스타일 접근을 포함합니다. 모션 편집의 경우 중간 전환 역방향과 축소 모션을 확인합니다. 정지된 스크린샷만으로는 종료 애니메이션이 올바르게 동작하는지 확인할 수 없습니다.
지원되는 런타임을 사용하여 저장소의 관련 테스트, 린트, 타입체크, 빌드를 실행합니다. 패치를 비난하기 전에 실패를 조사합니다. 기준 비교가 필요한 경우, 동일한 런타임 및 구성을 사용하여 재현합니다. 변경된 경로에 대한 동작 검사를 선호합니다. CSS 문자열 어설션만으로는 명도 대비, 지오메트리, 포커스 가시성, 또는 애니메이션 연속성을 확립할 수 없습니다.
무엇이 변경되었고 그 이유, 실제로 수행된 검사, 남아있는 불확실성을 보고합니다. 관찰된 개선 사항과 보이는 효과가 없는 토큰 정리를 구분합니다. 통합 후에는 설명과 증거를 최신 상태로 유지합니다. 외부 영감을 위해 현재 소스를 검사하고, 원칙을 이 제품에 적용하며, 공개 소스를 출처로 표시합니다. 출처에 접근할 수 없었을 때는 인용이나 지지를 만들어내는 대신 그 사실을 명시합니다.