[iOS][HIG] HIG란 무엇일까?

 

2021년 취업준비를 하며 보았던 iOS개발자 채용 공고들 중 RxSwift, MVVM, MVC만큼이나 많이 볼 수 있었던 단어가 있었습니다.

"HIG" = Human Interface Guide

https://developer.apple.com/design/human-interface-guidelines/

Human Interface Guidelines - Design - Apple Developer

 

HIG를 알아야 하는 이유? 

1. 사용자들이 사용하기 편한 앱을 만들 수 있다. 

  -> 애플스러운 앱을 만들 수 있다..

2. 이를 지키지 않으면 스토어에서 리젝사유가 될 수 있다.

  -> 재직하던 때 서비스를 업데이트 하였는 데, "권한요청 시 이를 허락함으로써 유저가 얻는 정보가 부족하다."로 리젝 되였었습니다.

3. 디자이너, 기획자와 협업 시 원활한 소통을 기대할 수 있다.

 

 

타 플랫폼과 iOS의 차별점.

1. 명확성 
  - 문자는 각각의 크기마다 읽기 쉬워야 함.

  - 아이콘은 정확하고 뚜렷해야 함.

  - 기능에 명확히 집중할 수 있는 디자인 ( 중요한 요소에는 미묘하게 강조 )

2. 존중

  - 모든 화면을 활용하여 컨텐츠를 표시.

  - 베젤, 그라데이션, 그림자를 최소화 하여 컨텐츠를 강조.

  -> 인터페이스는 가볍게, 내용에 집중하도록 만듦.

3. 깊이 

  - 뚜렷한 시각적 레이어와 사실적인 모션은 계층 구조를 이해하기 쉽게 돕는다.

  - 터치와 검색 기능은 컨텐츠에 접근하기 쉽도록 도와줌.

  - 컨텐츠 탐색 시 깊이감을 제공하도록 화면전환을 제공함.

HIG - iOS

1. 디자인 원칙

1. 미적 온전함 : 앱의 기능과 디자인이 잘 어울리는가?

2. 일관성 : 앱의 아이콘, 텍스트 스타일 등 일관된 디자인으로 사용자에게 편리함 제공.

3. 직접적인 조작 : 사용자들이 앱을 조작함으로 이에 대한 반응을 즉각적 시각적으로 확인 가능.

4. 피드백 : 탭 - 짧게 강조, 오래걸리는 작업 - 인디케이터, 동작의 결과 - 소리, 애니메이션.

5. 메타포 : 책을 넘기는 실제경험과 빗대어 사용자가 스와이프하며 화면을 전환.

6. 사용자의 통제 : 사용자가 전체적으로 앱을 통제하고 있는 느낌을 알려줌. -> 인스타그램에서 혐오적인 컨텐츠는 표시전에 노티.

 

2. 인터페이스 필수요소

iOS에서의 UI구성은 모두 UIKit을 사용합니다. 

이를 사용함으로써 일관적인 모습을 유지해주고 자유롭게 커스텀하여 사용할 수 있습니다. 일관성유지, 자유로운 커스텀 가능.

1. Bar

  - 사용자가 어디있는지 알려주며, 네비게이션을 제공. 동작을 시작하거나 정보를 전달하기 위한 버튼이나 다른 요소를 포함가능.

2. View

  - 텍스트, 그래픽, 애니메이션, 상호작용 요소와 같이 사용자가 앱에서 보는 주요한 내용을 포함합니다. 뷰는 스크롤, 삽입, 삭제나 배치와 같은 동작을 가능케 합니다 (가계부앱 일기장과 같이 기록, 삭제, 수정이 가능.)

3. Control

  - 동작을 시작하며 정보를 전달합니다. 버튼, 스위치, 텍스트 영역, 작업 진행 표시자(인디케이터) 등이 컨트롤의 예입니다.

 

 

HIG - App Architecture

1. Launching

- 사용자가 앱을 시작할 때 느끼는 감정을 중요하게 생각하자.

- 앱의 화면에서 첫내용을 보여줘야 할 때 이를 로딩하는 동안 런칭화면을 보여주어 사용자가 앱과 빈틈없이 상호작용하는 느낌을 주자.

- 시선을 많이 끌지 않는 간소한 화면으로 디자인하자.

- Adaptive Layout을 고려하자.

- 정보 설정 여부를 처음에 물어보지 말아야 한다. 필요하다면 앱을 사용하다가 사용자가 할 수 있도록 해주자.

- 앱에서 인앱 라이센스의 동의 및 철회를 보여주지 말자. -> 이는 사용자가 앱을 다운로드하는 시점에서 충분히 알 수 있게 해고 인 앱에서는 보여주지 않는 것을 지향. 꼭 보여줘야 한다면 사용자의 앱 경험을 최대한 망치지 않는 한에서 보여주자.

- 앱이 재시작될 때 이전상태를 저장하고, 같은 절차를 반복하지 않도록 하자.

- 재시작을 장려하지 말자. -> 재시작을 장려한다면, 사용자는 앱의 신뢰도가 떨어질 것이다. 만약 꼭 해야한다면 사용자에게 충분한 노티를 주자.

- 앱의 평가를 너무 자주 요구하지 말자. -> 너무 자주 이를 묻는 건 사용자의 짜증을 유발할 수 있으며 이는 낮은 평가를 받을 수 있다.

 

2. Onboarding

- 온보딩은 새로온 사용자, 오랜만에 돌아온 사용자를 다시 연결해 줄 수 있습니다. 빠르고 재밌으며 사용자가 직접 경험하지 않아도 앱을 전반적으로 이해할 수 있게 해줍니다.

- 온보딩은 사용자가 즐기는 화면이 되도록 하자. -> 온보딩에서 사용자의 설정을 요구하지 말자.

- 빠르게 사용할 수 있게 하자. -> 건너뛰기 기능을 제공해야 하며, 다시 돌아온 사용자에겐 자동으로 보여주지 않아야 한다.

- 필요나 도움을 미리 예측하자. -> 사용자가 사용 중 막히는 상황을 미리 예측하고 해당 대책을 미리 강구하자.게임의 경우 캐릭터가 이동하지 않는 경우 가볍게 유용한 팁을 보여줄 수 있다.

- 튜토리얼엔 중요한 것만 담자. -> 너무 많은 가이드가 필요하다면 앱의 디자인을 다시 생각해보고, 교육이 완벽하다고 멋진 앱 디자인을 대체할 순 없다.

- 즐겁고 쉽게 배울 수 있게 하자. -> 애니메이션과 상호작용을 통해 글을 읽고 배우는 것 보다 재밌게 배우도록 하자. 상호작용이 가능할 것 같은 스크린샷은 피하자.

 

3. Modality 

모달은 디자인 기술 - 사용자가 현재 접하는 내용(화면)과 분리된 모드에서 내용을 보여주며 이를 나가기 위해 확실한 동작을 요구합니다.

• 사용자를 독립적인 임무나 서로 가깝게 연관된 옵션들에 집중할 수 있게 합니다.
• 사용자에게 매우 중요한 정보를 확실히 주고, 필요한 경우 바로 동작하도록 할 수 있게 합니다.

1. 시트프레젠테이션

아래 내용을 부분적으로 가려지지않은 상단은 어둡게 표시되고 상호작용이 불가합니다. -> 사용자들이 현재 카드를 열기 전에 이미 진행하고 있던 일을 기억할 수 있게 돕습니다. 

나가는 방법 

• 스크린을 위에서 아래로 스와이프
• 카드 내용이 최상단으로 스크롤 되었을 때, 스크린을 아래서 어디로든 스와이프
• 버튼 탭

2. 풀스크린

화면 전체를 덮는 방법입니다.

이전의 화면을 완전히 가려 해당 기능에 온전히 집중하도록 도와줍니다. 사용자가 버튼을 탭하여 나갈 수 있습니다.

몰입도가 높은 작업, 복잡한 작업을 할 때 이를 활용하세요.

 

- 맥락에 맞는 모달을 사용하세요. -> 이를 사용함으로써 확실한 이득을 얻을 때 사용해야 합니다.

- 중요한 정보를 전달할 때에는 알람을 보류하세요. -> 알람은 보통 무언가 문제가 생겼을 때 발생합니다. 알람은 경험을 중단시키며 닫기 위해 탭을 요구하므로, 사용자로 하여금 그 방해가 정당한 것임을 느끼게 하는 것이 중요합니다. Alert가이드 참조.

- 모달에서 수행하는 일을 간단하게, 짧게, 좁은 범위에 초점을 맞추도록 하세요 -> 단일책임원칙과 같은 맥락입니다.

- 항상 모달 화면을 없앨 수 있는 버튼을 포함시키세요.

- 필요하다면, 모달 뷰를 닫기 전 사용자에게 확인을 받아 데이터 손실을 막으세요. -> 사용자가 만든 내용을 손실시킬 수 있다면, 상황을 설명할 수 있는 액션 시트를 만들어 사용자들이 해결할 수 있도록 하세요.

- 팝오버 상단에 카드를 보여주지 마세요. -> 팝오버 안에 카드를 배치할 수는 있으나, 팝오버의 상단에는 아무것도 나오지 말아야 합니다.

- 기본적으로 모달에서 어떤 일을 수행하는지 알려주는 제목을 표시하세요

- 당신의 앱과 모달 화면을 서로 잘 어울리게 하세요.

4. Navigation

네비게이션 바가 그 자체로 주의를 끌지 않으면서, 앱의 목적과 구조를 잘 지지하도록 해야합니다. 자연스럽고 친숙하게 느껴져야 하되 화면에 가장 중요한 특징이 되거나, 내용으로부터 시선을 뺏도록 하지 말아야 합니다.

 

iOS의 네비게이션 3가지.

1. 위계질서형 네비게이션.

설정앱에서 사용.

2. Flat Navigation

음악앱, 앱스토어에서 해당 방식을 사용.

 

3. 내용 혹은 경험중심 네비게이션

몇몇 앱들은 여러개의 네비게이션 스타일을 혼합하기도 합니다. 예를 들어, 평면형 네비게이션을 사용하는 앱은 각 카테고리 안에 위계 질서형 네비게이션을 사용할 수도 있습니다.

 

- 사용자들은 언제나 자신이 앱 안 어디에 있는지, 다음 목적지를 어떻게 갈지 알아야 합니다. 네비게이션 스타일에 관계없이, 콘텐츠로 이동하는 길은 논리적이고, 예측가능해야하며, 따라가기 쉬워야 합니다. -> 각 화면으로 가는 선택지는 하나씩만 주세요. 여러맥락에서 한 화면을 보여줘야 할 시 모달을 참고하세요.

- 탭, 스와이프, 스크린의 갯수가 최소한으로 요구되도록 정보 구조를 체계화하세요.

- 마찰을 최소화하며 화면을 이동할 수 있도록 하세요. 예를 들어, 이전 화면으로 돌아가기 위해 (별다른 버튼을 누르지 않아도) 화면 한쪽을 스와이프 하게 만들 수 있습니다.

- 사용자들이 익숙해하는 일반적인 네비게이션 컴포넌트를 사용하세요.

- 아이패드에선, 탭바 대신 스플릿 뷰를 사용하세요. 

- 페이지 조작방식(컨트롤)은 같은 형태의 내용 페이지가 많은 경우 사용하세요.

 

5. Setting

- 시스템에서 얻을 수 있는걸 추측해보세요. -> 현재 위치를 표시하기 위해 사용자에게 우편번호를 입력하라고 요구하는 대신 현재 위치 정보를 사용하도록 허가를 요구하세요.

- 앱 내에서의 환경설정 옵션을 우선적으로 처리하세요. 

- '설정' 앱에선 자주 바뀌지 않는 환경설정 옵션을 보여주세요. 설정은 시스템 전반의 환경설정을 바꿀 수 있는 앱이긴 하지만, 사용자들은 설정 앱에 접근하기 위해 당신의 앱을 떠나야 합니다.

- 적절한 경우, '설정' 앱으로 가는 지름길을 제공하세요. 만약 당신의 앱이 "설정 > 앱 > 보안 > 위치 설정 으로 가세요" 와 같이 길을 알려주는 문장을 포함한다면, 그 위치를 자동으로 열 수 있는 버튼을 제공 (예 : 권한설정 )

 

6. Requesting Permission

- 앱에 확실하게 필요한 개인정보만 요구하세요. - 위치추적기능이 켜져있을 때만 해당 권한을 요구할 수 있습니다.

- 왜 앱에서 이 정보가 필요한지 설명하세요-> 예시를 포함시키세요. 텍스트는 짧고 구체적으로, 첫 글자가 대문자로 시작하는 문장 형태를 사용하며*, 사용자가 압박감을 느끼지 않도록 정중하게 사용하세요.

- 앱 기능에 꼭 필요한 경우에만 첫 시작화면에서 사용 허가을 요구하세요.

- 불필요하게 위치 정보를 요구하지 마세요. 장소 정보에 접근하려 하기 전에, 시스템에서 위치 서비스를 사용할 수 있는지 확인해보세요. 

 

 

HIG - App Architecture, HIG-iOS

관련 애플HIG문서 내용들을 다뤄보았습니다..

영어로 되어있고 번역본은 글자가 이상하여 여러블로그들도 같이 참고하며 포스팅해보았습니다.

감사합니다!