Apple Human Interface Guidelines 요약: 원칙, 레이아웃, 바, 버튼, 알림

HIG란

Human Interface Guidelines(HIG) 는 Apple이 자기 플랫폼(iOS, iPadOS, macOS, watchOS, tvOS, visionOS)의 앱을 어떻게 디자인할지 정리한 공식 가이드다. 플랫폼 관례를 따르면 사용자가 새 앱을 따로 배우지 않아도 되므로, Apple 기기용 앱이 아니어도 앱·모바일 UI의 교과서로 쓸 만하다. 디자인 개념을 처음 배울 때 블로그 글보다 플랫폼 공식 가이드부터 보는 이유다. Android 쪽 짝은 Google의 Material Design이다.

2022년 6월 플랫폼별로 따로 있던 문서를 하나로 합쳐 기초(Foundations), 패턴(Patterns), 컴포넌트(Components), 입력(Inputs), 기술(Technologies) 묶음으로 다시 짰다. 아래 내용은 그 안의 여러 페이지에 흩어져 있다.
2025년에는 반투명한 재질과 굴절 효과를 쓰는 새 디자인 언어 Liquid Glass가 들어와 바·버튼·아이콘의 모양이 바뀌었다. 모양은 바뀌어도 아래 원칙과 쓰임새 지침은 대부분 그대로다.
HIG는 영어로만 제공된다. 번역기로 읽어도 흐름을 이해하는 데는 큰 무리가 없다.
어느 플랫폼 기준으로 디자인할지는 우리 사용자가 무엇을 쓰는지로 정한다. 사용자의 대부분이 iPhone이면 HIG를, Android 비중이 크면 Material Design을 먼저 본다.

설계 원칙

예전 HIG가 iOS 디자인의 바탕으로 내세운 여섯 가지 주제다. 지금 문서 구조에서는 이름이 흩어졌지만 지침 곳곳에 그대로 깔려 있다.

원칙	뜻
미적 무결성(Aesthetic integrity)	모양과 동작이 기능과 잘 맞물린다. 진지한 업무 앱은 장식을 줄이고, 게임은 몰입감 있는 외형을 쓴다
일관성(Consistency)	시스템이 주는 인터페이스 요소, 잘 알려진 아이콘, 표준 글자 스타일, 통일된 용어를 써서 익숙한 관례를 따른다
직접 조작(Direct manipulation)	화면의 콘텐츠를 손으로 직접 움직이고 바꾸면 몰입과 이해가 빨라진다
피드백(Feedback)	모든 행동을 받았다고 알리고 결과를 보여 준다. 기본 앱은 모든 조작에 지각할 수 있는 반응을 준다
은유(Metaphors)	가상의 객체와 동작이 현실이나 디지털 세계의 익숙한 경험을 닮으면 빨리 배운다
사용자 제어(User control)	결정하는 것은 앱이 아니라 사람이다. 앱은 행동을 제안하거나 위험한 결과를 경고할 수 있지만 대신 결정하지 않는다. 사람이 할 수 있게 하는 것과 원치 않는 결과를 막는 것 사이에서 균형을 잡는다

레이아웃과 적응형 인터페이스

인터페이스는 기기 크기와 방향에 따라 모양과 크기가 자동으로 바뀌도록 만든다. iPhone 앱이라면 모든 iPhone 화면 크기에서 제대로 돌아야 한다. 웹에서 같은 문제를 다루는 법은 안전 영역과 폴더블 대응과 반응형 UI 패턴에 있다.

개념	내용
레이아웃 가이드	콘텐츠의 위치·정렬·간격을 정하는 사각형 영역. 시스템이 표준 여백과 읽기 좋은 글자 폭 제한을 미리 정의해 둔다
안전 영역(safe area)	상태 바, 내비게이션 바, 탭 바, 툴바 같은 막대에 가리지 않는 영역. 시스템이 정한 안전 영역과 여백을 지키면 기기와 상황에 맞는 안쪽 여백이 자동으로 잡힌다

지침	내용
기본 콘텐츠는 기본 크기에서 분명하게	확대하지 않아도 핵심 내용이 읽혀야 한다
일관된 모양	비슷한 기능의 요소는 비슷하게 보이게 한다
무게와 균형으로 중요도 전달	크고 무거운 요소가 눈길을 끈다
정렬로 구조 전달	정렬은 훑어보기를 돕고 묶음과 위계를 보여 준다
가로·세로 모두 지원	가능하면 두 방향을 다 지원한다
터치 영역	모든 컨트롤의 누를 수 있는 영역을 최소 44×44pt로 둔다

전체 화면(노치·둥근 모서리가 있는) 기기에서는 이렇게 한다.

배경과 시각 요소는 화면 가장자리까지 채운다. 표·컬렉션처럼 세로로 스크롤하는 화면은 맨 아래까지 이어지게 한다.
조작할 컨트롤을 화면 맨 아래와 모서리에 바짝 붙이지 않는다. 홈 표시기를 끌어올리는 시스템 제스처와 겹친다.
잘리면 안 되는 콘텐츠는 안쪽으로 들인다.
가로 전체 버튼은 양옆에 시스템 여백을 둔다. 화면 끝까지 닿은 버튼은 버튼처럼 보이지 않는다. 화면 아래쪽의 전체 폭 버튼은 모서리를 둥글게 하고 안전 영역 아래 경계에 맞추면 가장 자연스럽고, 홈 표시기와 겹치지 않는다.
노치 같은 디스플레이의 특징을 가리거나 일부러 꾸미지 않는다.
상태 바 높이를 고정값으로 가정하지 않는다. 기기마다 다르다.

내비게이션 구조

지침	내용
늘 분명한 길	사람은 자기가 어디 있고 다음 목적지로 어떻게 가는지 늘 알아야 한다. 경로는 논리적이고 예측 가능해야 하며, 보통 각 화면으로 가는 길은 하나로 둔다
빠르게 닿는 정보 구조	콘텐츠에 몇 번 안 눌러도 닿게 짠다
표준 컨트롤	페이지 컨트롤, 탭 바, 세그먼트 컨트롤, 테이블·컬렉션 뷰, 분할 뷰 같은 표준 내비게이션 컨트롤을 쓴다
계층은 내비게이션 바로	데이터 계층을 따라 들어가고 나오는 길은 내비게이션 바가 맡는다
같은 수준의 범주는 탭 바로	동등한 콘텐츠·기능 묶음 사이를 오가게 한다
같은 종류의 여러 페이지는 페이지 컨트롤로	페이지가 몇 개이고 지금 어디인지 한눈에 보인다

각 막대의 세부 지침은 아래 「바」 절에 있다.

계정

지침	내용
꼭 필요할 때만 가입 요구	핵심 기능에 계정이 필요할 때만 만들게 한다
이점을 설명	계정을 만들면 무엇이 좋은지와 가입 방법을 알린다
로그인은 최대한 늦게	쓸모 있는 일을 하기 전에 로그인부터 시키면 많은 사람이 앱을 떠난다. Apple로 로그인 같은 간편 로그인으로 부담을 줄인다

계정 삭제는 2022년 6월 30일부터 App Store 심사 지침이 요구한다. 앱 안에서 계정을 만들 수 있으면 앱 안에서 삭제를 시작할 수도 있어야 한다.

앱 안에서 계정 삭제를 시작하는 분명한 방법을 둔다.
앱에서 하든 웹사이트에서 하든 삭제 경험을 일관되게 한다.
삭제가 끝나면 알린다.
앱 내 구매·구독을 지원하면, 계정을 지울 때 결제와 해지가 어떻게 되는지(구독은 따로 해지해야 하는지) 알려 준다.

알림과 배지

지침	내용
짧은 제목	맥락을 주는 제목은 짧게 쓴다
간결한 본문	짧고 읽기 쉽게 쓴다
민감한 정보 금지	잠금 화면에도 보이므로 개인·기밀 정보를 넣지 않는다
같은 알림 반복 금지	반응이 없다고 같은 내용을 여러 번 보내지 않는다
미리보기가 숨겨질 때의 문구	미리보기를 숨긴 설정에서 보일 일반적인 설명 문구를 준다
앱 이름·아이콘 넣지 않기	시스템이 이미 함께 보여 준다
소리	알림을 보완하는 소리를 고려한다

배지는 읽지 않은 알림 수를 보여 줄 때 쓰고, 중요한 정보를 전달하는 수단으로 쓰지 않는다. 늘 최신 상태로 맞춘다.
마케팅 알림은 따로 허락을 받고 보낸다. 앱 안에서 알림 종류별로 켜고 끌 수 있게 한다.

알림 시스템을 서버 쪽에서 설계하는 법은 알림 시스템 설계에 있다.

평가와 리뷰 요청

사용자가 앱을 충분히 써 본 것이 드러난 뒤에만 평가를 요청한다(예: 몇 번째 작업을 끝낸 직후).
시간에 쫓기거나 스트레스가 큰 작업 중에는 방해하지 않는다.
시스템이 주는 평가 요청 창을 쓴다. 시스템은 한 사람에게 1년에 세 번까지만 띄운다.

시각 디자인

애니메이션

애니메이션과 모션 효과는 신중하게, 목적이 있을 때만 쓴다.
현실적이고 믿을 만한 움직임을 쓴다. 물리 법칙에 어긋나는 움직임은 어색하다.
앱 전체에서 같은 동작에는 같은 애니메이션을 쓴다.
애니메이션을 끌 수 있게 한다. 동작 줄이기(Reduce Motion) 설정을 따른다.

움직임 설계 원칙은 UI 모션 디자인에 있다.

브랜딩

브랜딩은 세련되고 눈에 거슬리지 않게 녹인다. 앱 아이콘의 색을 인터페이스 곳곳에 쓰면 자연스럽게 맥락이 생긴다.
브랜딩이 좋은 앱 디자인을 방해하지 않게 한다. 무엇보다 앱이 그 플랫폼의 앱처럼 느껴져야 한다. 여러 플랫폼에 나온 앱이라도 플랫폼 간 브랜딩 통일에 매달려 디자인을 흐리지 않는다.
브랜딩보다 콘텐츠가 먼저다. 브랜드 자산만 보여 주는 고정 막대를 화면 위에 두면 콘텐츠 공간이 준다. 색 구성, 글꼴, 은은한 배경처럼 덜 방해되는 방식을 쓴다.
맥락에 꼭 필요한 경우가 아니면 앱 곳곳에 로고를 넣지 않는다.

색

색만으로 구별하거나 중요한 정보를 전달하지 않는다. 색을 못 보는 사람도 알 수 있게 모양·글을 함께 쓴다.
강조색은 아껴 쓸 때 힘이 커진다.
앱 로고와 어울리는 제한된 팔레트를 고른다.
상호작용을 나타내는 색을 하나 정해 앱 전체에서 쓴다. 상호작용하는 요소와 아닌 요소에 같은 색을 쓰지 않는다.
강조색은 라이트 모드와 다크 모드용 두 벌을 준비한다.
나라와 문화마다 색의 의미가 다르다는 점을 고려한다.
콘텐츠를 알아보기 어렵게 만드는 색 조합을 쓰지 않는다.

시작 화면

시작 화면(launch screen)은 앱이 빨리 켜지고 바로 쓸 수 있다는 인상을 주기 위한 것이지 예술적 표현이나 광고의 기회가 아니다.

앱의 첫 화면과 거의 같게 만든다. 그러면 앱이 즉시 켜지는 것처럼 보인다.
글자를 넣지 않는다. 시작 화면은 바뀌지 않아 글자가 현지화되지 않는다.
로고나 브랜딩 요소는 첫 화면에 원래 있는 고정 요소가 아니면 넣지 않는다. 스플래시나 「정보」 창처럼 보이는 진입 화면을 만들지 않는다.

용어

앱의 모든 단어는 사용자와의 대화다. 문구 전반의 원칙은 UX 라이팅에 있다.

익숙하고 이해하기 쉬운 단어를 쓴다. 사용자가 모를 약어와 전문 용어를 쓰지 않는다.
인터페이스 문구는 짧고 분명하게 쓴다. 가장 중요한 정보를 찾기 쉽게 앞에 둔다.
버튼 같은 상호작용 요소는 무엇을 하는지 한눈에 알게 「연결」, 「보내기」, 「추가」처럼 동사로 이름 붙인다.
격식 없고 친근한 어조를 쓰되, 유머는 조심한다.
언어와 이미지가 지금 상황에 맞는지 늘 확인한다.
날짜를 정확하게 쓴다. 「오늘」, 「내일」은 사용자의 시간대를 고려하지 않으면 틀릴 수 있다.

타이포그래피

가능하면 시스템의 기본 글자 스타일(Dynamic Type)을 쓴다. 가독성을 지키며 위계를 표현한다.
굵기, 크기, 색으로 가장 중요한 정보를 강조한다.
사용자가 글자 크기를 바꿀 때 무엇을 우선 보여 줄지 정한다. 모든 콘텐츠가 똑같이 중요하지는 않다.
서체 수를 줄인다. 여러 서체를 섞으면 앱이 조각나고 조잡해 보인다.
가독성이나 공간 절약을 위해 행간을 조절한다.

이미지 크기와 해상도

iOS는 화면 좌표를 픽셀이 아니라 포인트(pt) 로 잡고, 포인트를 디스플레이 픽셀에 대응시킨다.

배율	뜻
@1x	1pt = 1px. 표준 해상도
@2x, @3x	고해상도 화면. 1pt가 2×2px, 3×3px이라 이미지도 그만큼 픽셀이 많아야 한다

아트워크는 8×8px 그리드에 맞춰 그린다(레이아웃 그리드와 간격 체계).
그림자·질감·하이라이트가 있는 비트맵은 PNG, 사진은 JPEG를 쓴다. 아이콘·심볼처럼 확대될 수 있는 그래픽은 벡터(PDF, SVG)로 넣으면 배율마다 따로 만들 필요가 없다.

앱 아이콘

지침	내용
단순하게	앱의 본질을 담는 요소 하나를 찾아 단순하고 독특한 형태로 표현한다
초점 하나	바로 눈길을 끌고 앱을 알아보게 하는 중심 하나로 디자인한다
알아볼 수 있게	앱의 목적을 예술적으로 드러내는, 아름다운 추상 아이콘도 좋다
단순한 배경, 투명도 피하기	주변 아이콘을 압도하지 않게 배경을 단순하게 둔다. 아이콘 전체를 내용으로 채울 필요는 없다
글자는 꼭 필요할 때만	로고의 일부가 아니면 앱 이름이나 「무엇을 하라」는 말을 넣지 않는다
사진·스크린샷·UI 요소 금지	작은 크기에서 알아볼 수 없고 실제 버튼으로 오해한다
앱 안 곳곳에 넣지 않기	같은 아이콘이 다른 용도로 보이면 혼란스럽다
여러 배경에서 테스트	사용자의 배경 화면을 예측할 수 없으므로 밝은 배경과 어두운 배경 모두에서 확인한다

iOS 18부터 홈 화면이 다크·틴트 아이콘을 지원해 아이콘을 여러 변형으로 준비하고, Liquid Glass 이후에는 Icon Composer로 겹을 나눈 아이콘을 만들어 시스템이 빛과 재질 효과를 입히게 한다. 아이콘 사용성 일반은 아이콘 사용성에 있다.

바

내비게이션 바

화면 위쪽, 상태 바 아래에 있으며 계층을 따라 화면을 오가게 한다. 반투명하고 배경색을 입힐 수 있으며, 키보드가 뜨거나 제스처가 있거나 화면 크기가 바뀔 때 숨기도록 설정할 수 있다. 몰입이 필요하면 잠시 숨긴다.

제목: 보통 현재 화면의 제목을 둔다. 제목이 중복되면 비워도 된다. 맥락을 더 강조하려면 큰 제목(large title)을 쓰고, 스크롤하면 작은 제목으로 줄어든다.
컨트롤: 제목, 뒤로 버튼, 화면 내용을 다루는 컨트롤 하나 정도만 둔다. 너무 많이 넣지 않는다.
표준 뒤로 버튼: 사람들은 이것으로 계층을 되짚는다는 것을 안다. 직접 만든다면 여전히 뒤로 버튼처럼 보이고, 기대대로 동작하고, 앱 전체에서 일관돼야 한다.
여러 단계의 경로(breadcrumb)를 넣지 않는다. 뒤로 버튼은 늘 바로 앞 화면으로 돌아가는 한 가지 일만 한다.
글자로 된 버튼에는 서로 붙지 않게 충분한 공간을 준다.

검색 바

많은 값 가운데 글자를 입력해 찾게 한다. 단독으로, 또는 내비게이션 바나 콘텐츠 안에 둔다. 내비게이션 바 안에 두면 늘 보이게 고정하거나, 아래로 쓸어내릴 때 나타나도록 접어 둔다.

검색에는 일반 텍스트 필드 대신 검색 바를 쓴다. 사람들이 기대하는 모양이 있다.
지우기 버튼을 켠다. 검색 전용 화면에는 검색을 바로 끝내는 취소 버튼도 둔다.
필요하면 무엇을 찾을 수 있는지 힌트를 자리 표시자로 보여 준다.
검색 바 아래에 최근 검색, 추천 같은 바로 가기를 두면 콘텐츠에 더 빨리 닿는다.
스코프 바(scope bar): 검색 범위를 좁히는 선택지를 검색 바에 붙인다. 범주가 분명할 때 유용하지만, 범위를 고르지 않아도 되게 검색 결과 자체를 좋게 만드는 편이 낫다.

상태 바

화면 맨 위에 시간, 통신사, 배터리 같은 기기 상태를 보여 준다.

시스템 상태 바를 쓰고 직접 만든 것으로 바꾸지 않는다.
배경이 투명하므로 뒤에 깔린 콘텐츠를 흐리게 가려 상태 바가 읽히게 하고, 그 콘텐츠가 눌린다고 오해하지 않게 한다.
전체 화면 미디어를 볼 때는 잠시 숨겨도 되지만, 영구히 숨기지 않는다. 시간이나 Wi-Fi를 보려고 앱을 나가야 한다.

탭 바

화면 아래에서 앱이 주는 정보·기능의 종류를 보여 주고, 각 섹션의 내비게이션 상태를 유지한 채 최상위 섹션 사이를 오가게 한다.

필요한 최소한의 탭만 둔다. 많으면 탭마다 누를 영역이 줄고 복잡해진다. iPhone에서는 보통 3~5개다.
다른 영역으로 들어가도 탭 바를 숨기지 않는다. 앱의 전역 내비게이션이다.
콘텐츠가 없다고 탭을 없애거나 비활성화하지 않는다. 탭이 나타났다 사라지면 앱이 불안정해 보인다. 비어 있으면 그 이유를 탭 안에서 설명한다.

툴바

화면 아래에서 지금 화면과 관련된 행동 버튼을 담는다. 기본은 반투명이고 뒤에 콘텐츠가 있을 때만 배경 재질을 쓰며, 키보드가 뜨면 숨는다.

지금 맥락에서 가장 자주 할 행동 몇 개만 눈에 띄는 고정 위치에 둔다.
맥락(섹션)을 바꾸는 용도라면 툴바가 아니라 탭 바를 쓴다.
버튼이 세 개 이하면 짧은 글자 제목이 더 분명하고, 세 개를 넘으면 공간을 아끼려고 SF Symbols 아이콘을 쓴다.

경고창

경고창(alert)은 앱이나 기기 상태에 관한 중요한 정보를 알린다. 제목, 선택적 메시지, 하나 이상의 버튼, 선택적 입력 필드로 이뤄지고, 이 구성 요소 외의 모양은 바꿀 수 없다. 흐름을 끊으므로 최소한으로, 정말 중요한 정보에만 쓴다. 대화상자 버튼 배치 일반은 모바일 앱 UI 가이드라인에 있다.

제목: 짧고 설명적인 여러 단어로, 가능하면 메시지 없이도 상황이 이해되게 쓴다(영어라면 완전한 문장은 문장식 대문자와 마침표, 문장 조각은 제목식 대문자에 마침표 없이).
메시지: 꼭 필요하면 스크롤 없이 한두 줄에 들어가는 짧은 완전한 문장으로 쓴다. 직접적이고 중립적이며 친근한 어조를 쓴다.
버튼을 설명하지 않는다. 제목과 버튼 이름이 분명하면 「확인을 누르면 ~됩니다」 같은 설명은 필요 없다.
버튼 이름: 결과를 설명하는 한두 단어로, 제목·메시지와 직접 이어지는 동사(「모두 보기」, 「답장」, 「무시」)를 쓴다. 단순 수락은 「확인(OK)」, 취소는 늘 「취소」라고 쓰고 「예/아니요」는 쓰지 않는다.
배치: 버튼이 둘이면 가장 누를 법한 버튼을 끝쪽(오른쪽)에, 취소를 앞쪽(왼쪽)에 둔다. 셋 이상이면 세로로 쌓고 가장 누를 법한 것을 위에, 취소를 맨 아래에 둔다.
파괴적인 버튼: 삭제처럼 되돌릴 수 없는 일을 하는 버튼은 파괴적 스타일(빨간색)로 구분한다.

버튼

시스템 버튼

시스템은 눈에 띄는 정도가 다른 네 가지 스타일(plain, gray, tinted, filled)을 세 가지 크기(small, medium, large)로 준다. 스타일로 행동의 위계를 보여 준다. 버튼 위계 일반은 모바일 앱 UI 가이드라인에 있다.

기능이 바로 이해되게 아이콘(글리프), 제목, 또는 둘 다로 목적을 전한다.
바로 끝나지 않는 작업은 버튼 안에 활동 표시기를 띄운다. 공간을 아끼면서 기다리는 이유가 분명해진다.
화면에서 가장 할 법한 행동에만 filled를 쓴다. filled 버튼이 많으면 무엇을 고를지 비교하느라 인지 부담이 커진다.
여러 선택지 중 선호하는 것은 크기가 아니라 스타일로 구분한다. 같은 크기의 버튼은 한 묶음의 선택지라는 신호다. 선호하는 것에 더 눈에 띄는 스타일을 준다.
가장 고를 법한 버튼에 기본(primary) 역할을 줘 Return 키로도 확정되게 한다.
파괴적인 행동에는 기본 역할을 주지 않는다. 가장 고를 법하더라도 그렇다. 눈에 띄는 기본 버튼은 읽지 않고 누르기 쉽다.

그 밖의 버튼

버튼	쓰임과 지침
토글 버튼	켬·끔, 보임·숨김처럼 반대되는 두 상태를 오간다. 스위치 모양만 토글이 아니다. 상태를 바꿀 뿐 아니라 지금 상태를 보여 줘야 한다. 기본은 켜짐에 강조색, 꺼짐에 회색인데, 색만으로 상태를 구분하지 않는다
팝업 버튼	서로 배타적인 선택지의 메뉴를 띄운다. 닫혀 있을 때도 현재 선택(아직 고르지 않았으면 대부분이 원할 기본값)을 보여 준다. 공간이 좁고 모든 선택지를 늘 보일 필요가 없을 때 쓴다. 결제 화면의 카드 선택이 예다
닫기 버튼	한 화면에 닫기 버튼과 완료 버튼 중 하나만 둔다. 둘 다 화면을 닫지만 반대 동작이 아니라 함께 있으면 무엇을 눌러야 할지 헷갈린다
흔한 버튼 유형	정보(ⓘ), 추가(+) 같은 버튼은 시스템 전체에서 같은 뜻이라 즉시 알아본다. 비슷하게 생긴 버튼을 만들면 기대대로 동작해야 한다. 목록·표의 행에 대한 추가 정보는 정보 버튼으로 보여 준다

진행 표시

로딩 UI 일반은 로딩 UI에 있다.

종류	지침
활동 표시기(빙글빙글 도는 표시)	작업량을 셀 수 있으면 이것보다 진행률 바를 쓴다. 멈춘 표시기는 멈춘 작업으로 읽히므로 계속 움직이게 한다. 기다리는 동안 도움이 되는 정보를 보여 주되 「로드 중」, 「인증 중」 같은 막연한 말은 쓰지 않는다
진행률 바	진행 상황을 늘 정확하게 보여 준다. 바빠 보이려고 부정확한 진행을 보여 주지 않는다. 양을 셀 수 있고 기간이 분명한 작업에만 쓰고, 그렇지 않으면 활동 표시기를 쓴다

텍스트 필드

한 줄짜리 고정 높이 입력란으로, 누르면 키보드가 자동으로 뜬다. 입력 설계 일반은 모바일 앱 UI 가이드라인에 있다.

비어 있을 때 「이메일」, 「비밀번호」 같은 자리 표시자로 목적을 알린다.
끝쪽에 지우기 버튼을 두면 Delete 키를 반복해 누르지 않고 한 번에 지운다.
비밀번호 같은 민감한 정보는 늘 보안 텍스트 필드로 가린다.
이미지와 버튼을 필드 안에 넣어 용도와 기능을 더한다(예: 검색 아이콘, 비밀번호 보기 버튼).

정리

HIG는 Apple 플랫폼의 공식 디자인 가이드이면서 앱·모바일 UI의 교과서다. 우리 사용자가 주로 쓰는 플랫폼의 가이드부터 본다.
바탕은 미적 무결성, 일관성, 직접 조작, 피드백, 은유, 사용자 제어다.
시스템 컴포넌트(바, 버튼, 경고창, 검색 바)를 쓰고 기대대로 동작하게 한다. 사람들은 이미 그 사용법을 안다.
브랜딩보다 콘텐츠, 장식보다 분명함. 시작 화면은 광고가 아니고 로고는 아낀다.
디테일이 평범함과 탁월함을 가른다. 경고창 버튼의 이름과 위치, 진행 표시의 정확성, 닫기와 완료 중 하나만 두기 같은 작은 지침이 쌓여 완성도가 된다.

버그 제보