Human Interface Guidelines, HIG는 애플에서 제공한 UI/UX 관련 가이드라인 문서입니다. 다음 링크에 들어가면 확인하실 수 있습니다. https://developer.apple.com/design/human-interface-guidelines/

다시 말해 애플 피셜 좋은 앱 만드는 방법을 모아둔 가이드라인입니다. 이를 제대로 지키지 않으면 앱 심사도 통과시키지 않을 수 있다고 적혀있는데, 그렇게 빡빡하지는 않습니다.

이 HIG의 목적은 위 이미지에서도 보이는 문장에 잘 적혀있다고 생각합니다.

저는 여기서 두 가지 포인트를 잡고 싶은데요.

첫 번째는 designing great apps입니다. 훌륭한 앱을 만들기 위해 정보와 UI 요소를 제공한다는 말을 하고 있습니다. 애플 입장에서는 앱스토어에 좋은 퀄리티의, 훌륭한 앱이 많이 올라오기를 바랄겁니다. 애플이 생각하는 훌륭함의 기준을 가이드라인을 통해 제공하고 있다고 볼 수 있겠습니다.

두 번째는 integrate seamlessly with Apple platforms입니다. 여기서 integrate가 핵심이라고 생각합니다.

유저는 아이폰 앱을 사용할 때, 알게 모르게 익숙해져있는 아이콘, 체득한 제스처가 있을겁니다. 그리고 그런 행동들이 어느 앱을 사용하든 기본적으로 이용할 수 있기를 기대할 것입니다.

이 가이드라인에서는 iOS 전반적으로 여러 디자인 요소를 맞추고, 통일성 있는 경험을 할 수 있도록 돕기 위해 꽤나 세세한 포인트까지 제안하고 있습니다. 그렇게 함으로써 integrate, 즉 통합할 수 있다는 뜻입니다.

앞에도 말했지만, HIG의 양은 엄청나게 방대합니다. 저는 여러 가이드라인 중 iOS만 읽었는데도 불구하고 엄청나게 오래걸렸습니다. 이걸 다 설명하려면 세미나 한 번이 아니라 아예 스터디를 잡아서 같이 공부했어야 할 것입니다.

그래서 여기서는 가장 처음에 있는 iOS Theme에 있는 6가지의 중요한 점에 대해서만 짚어보고, 그 다음은 실제 캐시미션 앱과 비교해가며 진행해보도록 하겠습니다.

첫 번째는 Aesthetic Integrity입니다. 이는 앱의 모습과 그 기능이 얼마나 일치하는지 여부입니다.

엑셀 같은 전문적인 기능을 하는 앱의 경우에는 눈에 띄지 않는 그래픽과, 표준적이고 예측할 수 있는 기능을 해야 합니다. 적어도 셀을 누르면 그 셀이 선택된다, 이런 기대를 충족해줘야죠. 반대로 게임 같은 경우는 화려한 그래픽과 유저를 즐겁게 해줄 예측 불허한 기능이 있는 것이 좋죠.

따라서 이 앱이 어떤 기능을 하느냐에 따라 그 외견을 어떻게 적절하게 가져갈지 생각하는 것이 중요합니다.

두 번째는 Consistency입니다.

일관성으로, 시스템(iOS)에서 제공하는 인터페이스 요소, 아이콘, 텍스트 등을 통해 유저가 익숙한 디자인, 일관적인 경험을 제공해야 한다는 뜻입니다.

개인적으로는 이 일관성은 OS 단위 뿐만이 아니라 하나의 앱 내부에서도 유지하는 것이 중요하다는 생각이 들기도 합니다. 같은 앱 내에서라면 일관적으로 디자인을 가져가야겠죠?

세 번째는 Direct Manipulation입니다.

유저가 제스처를 이용하거나, 폰을 기울이는 등, 유저가 직접 조작을 할 수 있도록 기능을 제공하는 것입니다.

네 번째는 Feedback입니다.

유저가 어떤 행동을 하면 그에 따른 화면의 변화, 피드백을 보여줘야 한다는 뜻입니다. 만약 어떤 버튼을 눌렀을 때 서버로부터 데이터를 받아와야 할텐데, 그 찰나의 딜레이 동안 앱이 뭔가 멈춰있는 것처럼 보인다면 유저 입장에서는 당황스러울 것입니다. 그렇기에 앱이 멈춰있지 않다는 인상을 주고 유저의 요청이 진행되고 있다는 것을 알리기 위해 피드백이 꾸준히 발생하는 것이 좋을 것입니다.

다섯 번째는 Metaphor입니다.

이미 존재하는 것을 만들 때, 그것과 비슷한 느낌으로 기능을 만들면 좋다는 항목입니다. 예를 들면 책을 읽는 앱에서는, 오른쪽 귀퉁이를 잡고 제스처하는 것을 통해 책장을 넘기는 듯한 효과를 주는 경우가 많습니다. 이런 것은 실제 세계에 존재하는 책의 기능을 비유해 사용했다고 볼 수 있겠죠.

마지막은 User Control입니다.

앱이 유도하고자 하는 사용 방향과 사용자의 자율 사이에서 적절한 균형을 잡는 것이 필요하다는 의미를 담고 있습니다.

예를 들어 드로잉 앱에서 실수로 다 지워버리는 버튼을 누르는 경우가 있을 것입니다. 앱 입장에서는 유저가 그리던걸 실수로 날리는 것을 원하지는 않을 것입니다. 따라서 ‘정말로 지우겠습니까?’하는 문구를 띄워 진짜 모두 지울지 남겨둘지 한 번 막아줄 수 있습니다. 이러면 앱은 앱이 원하는 방향대로 유도하면서도, 유저에게는 자신이 주도권을 가지고 있다고 생각할 수 있게 합니다.

그러면 이제 위에서 확인한 6가지의 포인트를 머리 속에 넣고 ‘캐시미션’과 비교해보려고 합니다.

하지만 그 전에 한 가지 짚고 넘어가자면, HIG에 있는 항목이라고 해서 진리는 아닙니다.

정말 좋은 내용이 많기에 도움이 되는 것은 맞으나, 상황에 따라 적절히 활용했을 때 더더욱 좋은 것이지, 무턱대고 적용해야 하는 것은 아닙니다.

만약 HIG에서 말하는 ‘글자 크기가 설정에 따라 유동적으로 변하도록 해라’라는 항목 때문에 모든 문구를 유동적으로 변할 수 있도록 처리했다면, 의도치 않게 앱의 UI가 망가지거나, 앱의 기능상 문구의 크기가 변하지 않아야 할 수도 있는데 문제가 될 수도 있겠습니다. 오히려 HIG를 따르려다가 앱의 기능을 망치는 상황이 올 수도 있겠죠.

따라서 HIG를 무조건 적용할 필요는 없다! 라고 생각해주시고 함께 ‘캐시미션’도 확인해보면 좋을 것 같습니다.

캐시미션의 Launch Screen, 그리고 이어지는 Start Screen입니다. 이런 느낌의 앱 시작은 익숙하실겁니다. 이렇게 앱을 시작할 때 앱의 로고가 보이거나, 스플래시가 보이고 나서 시작화면으로 넘어가는 경우는 굉장히 많습니다.

하지만 애플에서는 이에 대해 다르게 생각하고 있었습니다.

우선 Launch Screen을 First Screen과 비슷하게 디자인하라는 말이 있습니다. 그 밑에는 이유도 나와있죠. Launch Screen을 First Screen과 비슷하게 만들면, 일단 앱이 즉시 시작하는 것과 같은 느낌을 유저에게 줄 수 있습니다. 실제로는 로딩 중인데도 불구하고 바로 켜진 것만 같고, 첫 시작 작업이 끝나고 나면 어색함 없이 자연스레 First Screen으로 연결될 수 있죠.

그리고 Launch Screen은 Branding 기회가 아니라는 말도 있습니다. 스플래시 스크린이나 로고를 넣는 것을 지양하라고 말하고 있습니다. 대부분의 앱들이 시작 화면에서 로고를 보여주는데, 애플의 생각은 조금 다르네요.

그러면 일단 애플이 생각하는 적절한 Launch Screen의 예시를 한 가지 볼까요?

조금 예전 버전 Safari입니다. 이 사진을 보면 Launch Screen과 First Screen을 비슷하게 만든다는 것이 어떤 느낌인지 확 오시죠?

Safari 앱은 켜지자마자 보이는 Launch Screen을 위 이미지처럼 구성함으로써 왠지 앱이 로딩 없이 즉시 켜진 것 같은 느낌을 주고, 빈 공간에 자연스레 컨텐츠가 로딩될 것을 기대하게 만듭니다. 그리고 자연스레 오른쪽 사진처럼 웹페이지를 보여줄 것입니다.

이 부분에서 애플이 중요시하는 점을 정리해보자면, ‘유저가 앱을 빠르다고 느끼고, 부드럽게 연결된다고 생각하게 하는 것‘이 아닐까 합니다. 앱이 제대로 연결되지 않으면 앱이 제대로 만들어지지 않았다고 느낄 것이고, 유저가 앱을 느리다고 느끼면 그냥 앱을 꺼버릴 수도 있겠죠. 앱의 사용자를 유지하고 훌륭한 경험을 제공하기 위해서는 중요한 포인트입니다.

그렇다면 우리의 캐시미션도 Launch Screen을 변경해야 할까요? 저는 굳이… 라는 생각이 듭니다.

위 Safari 같은 경우 First Screen이 앱의 핵심 기능을 이미 하고 있습니다. 웹 브라우저 답게 웹 페이지와 주소창, 툴바를 시작부터 보여주고 있죠. 그래서 Launch Screen을 First Screen과 비슷하게 하면 기능에 바로 접근할 수 있는 듯한 모습을 보여준다고 생각할 수 있습니다.

하지만 캐시미션은 First Screen이 앱의 핵심 기능이라고 하기엔 무리가 있습니다. 그냥 메인 화면일 뿐이고, 데이터 라벨링 등의 기능들은 그 메인 화면에서 어떤걸 할 지 선택해야 합니다.

그래서 굳이 캐시미션의 Launch Screen을 첫 메인 화면과 비슷하게 만들어야 할 필요까지는 없어보입니다. 다만 요즘 트렌드는 Launch Screen의 스플래시와 초기 세팅 과정을 보다 빨리 끝내고, First Screen이 로딩되는 모습을 보여주는 방식이 많이 사용되는 것으로 알고 있습니다. 캐시미션도 그런 식으로 한번 개선해보는 것은 좋을 것 같습니다.

대다수의 앱에서 로딩이라는 개념은 존재할 것입니다. 주로 조금 처리가 오래 걸리는 작업이나, 비동기 작업을 수행할 때 그 딜레이를 로딩이라고 합니다. 결국 기다리는 시간이라는 점인데, 그 기다린다는 행동을 어떻게 유저에게 전달할 것인가도 중요한 문제 중 하나죠.

물론 애플도 HIG를 통해 이 로딩을 어떻게 처리하면 좋을지 제시해주고 있습니다.

일단 로딩이 진행되고 있음을 티를 내달라고 하고 있습니다. 최소한 Activity spinner, 도는 표시라도 사용해서 뭔가 로딩하고 있음을 알려주는 것이 좋다고 합니다. 가능하면 얼마나 로딩되었는지 상태를 알려주는 것도 좋다고 하네요.

그리고 최대한 빨리 화면을 구성해 보여줘야 한다고 합니다. 예를 들어 이미지가 보이는 화면에서 이미지가 로딩될 때까지 전체 화면이 랜더링되지 않고 멈춰있는 것이 아니라, 이미지가 등장할 곳에는 Placeholder를 제공해 이 곳에 곧 이미지가 로딩될 것이라는걸 알려주고, 이미지 외의 요소는 빠르게 유저에게 보일 수 있도록 해야 합니다.

여기서 애플이 원하는 것도 Launch Screen의 경우와 비슷하다고 느껴집니다. 애플은 여기서도 유저가 앱이 빠르다고 인식하게 하고, 컨텐츠까지 부드럽게 연결되며, 지금 로딩이 일어나고 있다는 피드백까지 받을 수 있도록 화면을 구성해야 한다는 의지를 보여주고 있습니다.

그렇다면 캐시미션의 로딩은 어떨까요?

건너뛰기를 눌러서 다음 이미지 및 결과를 불러올 때마다 뭔가 자연스러운 전환이 되지 않는 듯한 모습입니다. 이미지가 새로 로딩되는 동안 Spinner라도 돌아간다거나 하면 좋을텐데, 현재로서는 그런 처리가 되어있지 않네요.

다만 어떤 경우에는 처리가 되어있기도 합니다. 여기서는 제출 버튼을 눌렀을 때 버튼 안에 Spinner가 돌아가면서 현재 비동기 작업이 처리 중에 있다는 것을 나름 유저에게 알려주고 있습니다. 사실 이 버튼을 이렇게 만든 의도는 버튼을 여러번 누르는 것을 막기 위해 도입된 것 같긴 하지만… 어찌되었던 괜찮은 역할을 하고 있습니다.

현재 캐시미션 앱에서는 잘 알려주고 있는 경우도 있지만, 확실히 세심하게 처리를 해두지 못한 부분이 상당수 존재하고 있습니다. 앞으로는 이런 부분에서도 일관성을 유지할 수 있도록 노력해야겠다는 생각이 들었습니다.

HIG에서는 색상 사용에 대해서도 굉장히 많은 조언을 담고 있는데요. 이번에는 그 중에서도 Color와 Branding 사이에 대해 소개드리려 합니다.

우선 Branding에 대해 간단하게나마 말씀드려야겠네요. 여기서 말하는 Branding은 우리 앱만의 특별한 브랜드 아이덴티티를 구축하는 것을 말합니다. 뒤에서도 언급하겠지만, 아이콘, 색상, 폰트 등 다양한 요소를 이용해 앱에 브랜드 요소를 효과적으로 녹여낼 수 있습니다.

Branding은 앱을 사용하는 상황에서 유저에게 익숙한 흐름을 제공한다는 장점도 있지만, 프로덕트 차원의 관점을 넘어 회사의 브랜드를 구축하거나, 자동차처럼 패밀리룩을 구축하기 좋다는 여러 장점이 있습니다. 그래서 디자이너, 마케팅 담당자 등 다양한 사람들이 함께 고민해야 하는 사항이기도 하죠.

그 중에서도 색상은 브랜딩의 핵심 요소입니다.

다들 카카오톡하면 노란색, 페이스북 하면 파란색이 바로 떠오르지 않나요? 실제로 각 앱은 디자인 요소나 강조되는 요소를 노란색, 파란색 같은 색상을 사용함으로써 앱의 색상을 일관성 있게 가져가고 있습니다.

애플이 HIG에서 하고 있는 조언을 살짝 살펴봅시다.

사용하는 색상의 개수를 제한하고, 앱 로고와 맞추어 색상을 사용하라는 제안을 해주고 있습니다. 그리고 상호작용할 수 있는 요소들의 색상을 하나로 골라서 앱 전체적으로 일관되게 유지하라는 제안도 함께 해주고 있습니다.

애플이 제공하는 기본 앱도 이걸 지키고 있음을 확인할 수 있습니다.

애플의 메모 앱은 앱 로고부터 노란색이 포인트 색상으로 들어가있습니다. 실제로 앱 내에서도 상호작용하는 요소(완료 버튼, 텍스트 영역 선택 등)을 노란색으로 맞춰갔습니다. 아이폰 유저라면 딱 봐도 애플의 메모 앱이라는 것을 알 수 있겠죠.

그렇다면 캐시미션은 어떨까요? 개인적으로는 점점 나아지고 있는 것이 아닐까 생각하고 있습니다.

음… 일단 앱 로고만 봐서는 카카오나 페이스북처럼 어떤 하나의 색상을 정하기에는 무리가 있어보입니다.

그래도 기존의 캐시미션은 앱 내부에서 정말 많은 색상을 사용하고 있었는데, 최근 디자인 가이드를 개편하면서 Color Palette도 한번 정리할 수 있었습니다.

디자인 가이드의 극히 일부를 떼왔습니다. 이렇게 사용하는 색상과 포인트 색상을 기존에 비해 훨씬 개수를 줄여 일관적으로 색상을 제공할 수 있도록 했습니다.

왼쪽은 과거에 만들어졌던 출금 정보를 제출하는 화면이고, 오른쪽은 최근에 구현된 마이페이지입니다. 왼쪽 화면은 이렇게 다시 보니 서툰 점이 많이 있어 부끄럽긴 하네요.

왼쪽은 그냥 단순히 흰색, 회색, 검은색만 들어있었지만, 최근에 만들어진 오른쪽 화면은 포인트 컬러들을 적절히 활용하고 있습니다. 또한, 출금신청 버튼은 앱 로고와 비슷하게 검은색 배경에 파란색 버튼이 포함되는 느낌의 디자인이 적용되었습니다.

지금까지는 앱 Branding을 위한 Color 활용에 조금 소극적이었지만, 최근부터는 디자인 가이드를 통해 사용하는 색상을 제한하고, 디자인도 변화하고 있어서 캐시미션도 점점 좋아지지 않을까 생각하고 있습니다. 저도 만드는 개발자의 입장이지만 앞으로 어떤 디자인으로 점점 발전할지 기대하고 있습니다!

HIG를 읽다보면 유독 System Provided 요소, Standard 요소를 사용하라는 말이 많이 보입니다.

iOS 앱을 개발하기 위해서는 애플에서 제공하는 UIKit, 혹은 SwiftUI 같은 프레임워크에 대해 알아야 합니다. 이 프레임워크 위에서 앱을 만들면, 앱의 전반적인 라이프 사이클에 대한 설정이 기본적으로 되어있고, 프레임워크에서 제공하는 다양한 요소를 사용해 앱을 만들 수 있습니다.

위에서 말한 System Provided 요소라는 것이 바로 이 프레임워크에서 제공하는 요소인데요. 예를 들어 애플의 SwiftUI는 SF Symbols를 통해 수많은 기본 아이콘을 제공하고 있습니다. 또한 스크롤할 수 있는 화면을 만들기 위한 ScrollView라든가, 기본적인 버튼의 디자인과 기능을 하고 있는 Button도 있습니다.

이런 요소들을 사용하면 기본적인 기능은 모두 해주고 있기 때문에 편하지만, 커스텀에 한계가 생긴다는 단점도 함께 가지고 있습니다.

그런데 HIG에서는 System Provided를 왜 이렇게 강조하는 것일까요?

Gesture 파트와 Navigation Bar 파트에서 비슷한 요구를 하고 있는 항목을 가져와봤습니다.

한번 살펴보면, 표준적인 Gesture를 사용하면 사람들이 이것에 대해 ‘familiar’하고, 이를 변형할 시 ‘confusion’을 유도한다고 적혀있습니다. 예를 들어 아이폰X 이상 사용자라면, 화면 아래쪽을 쓸어올려 현재 앱에서 메인 화면으로 나갈 수 있다는 것을 자연스레 알고 있습니다. 이렇게 유저가 이미 경험을 통해 이런 제스처를 하면 이렇게 동작할 것이라는걸 기대하고 있으니, 이 표준적인 제스처를 변형하거나 하지 말라는 뜻이죠.

Navigation Bar의 경우도 비슷합니다. 여기서는 Back Button을 얘기하고 있는데요. 사람들은 표준적인 Back Button을 ‘know’, 알고 있고 이를 눌렀을 때 이전 화면으로 간다는 것을 이미 자연스레 알고 있다는 말입니다. 아이폰을 사용하다보면 자연스럽게 왼쪽 위의 ‘<’ 모양과 함께 있는 문구의 버튼이 뒤로 가기라는 사실을 체득하게 되니까요.

여기서 애플이 System Provided 요소를 사용해야 한다고 주장하는 이유를 알 수 있습니다.

바로 유저가 아이폰을 사용하면서 일관적이고 통일성 있는 경험을 할 수 있도록 해야 한다는 뜻이 담겨있었습니다. 이 글 초반에 우리 앱이 애플 생태계에 integrated, 통합되는 것도 중요하다는 말씀을 드렸습니다. 애플에서 제공하는 UI 요소와 기능을 채용함으로써 보다 유저에게 자연스러운 경험을 전달할 수 있겠죠.

그런데 캐시미션은 사실 시스템 제공 요소를 그다지 사용하고 있지 않습니다. 이 화면에서는 아마 스크롤을 위한 ScrollView를 제외하면 대부분 직접 만들어낸 커스텀 UI 요소를 사용하고 있습니다. Page Indicator, 아이콘이 커스텀인 것은 물론이고, 색상, 폰트 같은 요소도 모두 커스텀해서 사용하고 있습니다.

그러면 캐시미션의 요소들도 System Provided 요소로 변경해야 할까요?

그럴 필요는 없습니다. 아까 말했듯 앱의 Branding은 굉장히 중요합니다. 색상 뿐만이 아니라 아이콘이나 폰트 같은 경우도 브랜드 요소로 유저에게 은연 중에 계속 제시할 수 있죠. System Provided 요소만 사용하면 그런 점에서 효과를 보기 쉽지 않습니다. (물론 커스텀 요소 사용하는 이유가 모두 Branding 때문은 아니고, 기능과 더 좋은 디자인을 위해서 하는 경우가 대다수이긴 합니다.)

예시를 하나 들어보자면 우아한 형제들의 배달의 민족 폰트가 있겠군요. 이 기사를 보시면 배민은 그들만의 폰트를 만들어내 사용하고, 배포함으로써 브랜드를 계속 전파하고 있습니다. 여러분도 어느새 저런 글씨체를 보면 딱 배민이 바로 떠오르지 않나요?

셀렉트스타는 아직 직접 폰트를 제작해내는 것까진 아닙니다. 하지만 iOS, 안드로이드, 웹이라는 여러가지 플랫폼에서 캐시미션의 공통적인 Branding을 적용해야 하는만큼, 한 OS에 기반한 요소들을 마구마구 사용할 수는 없습니다. 물론 OS의 특징에 따라 조금씩은 기능이나 화면이 다를 수 있겠지만, 디자인에서의 전반적인 색상, 폰트, 아이콘 등은 여러 플랫폼에서 통일성 있게 가져갈 수 있어야겠죠.

그래서 현재 캐시미션이 System Provided 요소를 그대로 사용하는 것이 아닌 커스텀해서 사용하는 것 자체는 적절한 판단이라고 생각합니다.

하지만 주의해야 할 점도 있죠. 애플이 원하는건 ‘사용자가 아이폰을 사용하면서 일관적이고 통일성 있는, 익숙한 경험을 하는 것’입니다. 커스텀을 했을 때 유저가 익숙해져있는, 앱을 사용할 때 기대하고 있는 기능을 유지할 수 있도록 해야 합니다.

캐시미션의 예시를 살펴보면서 System Provided 요소를 사용할 때의 장점과, 주의해야 하는 사항에 대해서 알아봅시다.

이는 SwiftUI에서 제공하는 ScrollView를 사용해 구현한 스크롤이 되는 화면입니다. 아이폰 사용자 분들이라면 거의 다 아시겠지만, 이런 스크롤 되는 화면의 경우 상단 상태바를 한 번 탭해주면 다시 제일 상단으로 돌아갑니다.

애초에 ScrollView를 커스텀하는 것도 어렵겠지만, 만약 ScrollView 기능을 커스텀해서 만들면 OS에서 제공해주는 이런 기본적인 기능을 직접 만들어야 할 것입니다. 만들지 않는다면 이미 이 기능이 익숙해져있는 유저 입장에서는 불편함을 느낄 것입니다. iOS 전반적으로 퍼져있는 어떤 ‘통일성’을 느끼지 못하는 것이죠. 이런 사소한 포인트들은 애초에 개발자가 체크하기 어려운 것이기도 하니, 기본 제공 요소를 썼을 때 편한 점도 있을 것입니다.

실제로 문제가 된 적이 NavigationView에서 있었습니다. 지금 위 이미지에서 확인할 수 있으신 것처럼, iOS의 NavigationView에서는 화면 왼쪽에서부터 스와이프를 할 때 바로 이전 화면으로 넘어갈 수 있습니다.

하지만 제가 처음 회사에 들어왔을 때는 이 제스처 처리가 제대로 되어있지 않은 상황이었습니다. 아이폰 유저라면 이 제스처에 굉장히 익숙한 편일텐데, 이 제스처가 제대로 동작하지 않으면 상당한 불편을 초래하겠죠.

캐시미션은 지금 NavigationView는 기본 제공으로 사용하고 있지만 NavigationBar를 커스텀해서 사용하고 있습니다. 상단 NavigationBar 부분을 보시면 기본 제공이 아닌 커스텀임을 확인하실 수 있을겁니다. 이런 화면을 위해서는 원래 NavigationView에서 제공해주는 기본 NavigationBar는 아예 숨기고, 우리의 커스텀 Bar를 화면 위쪽에 배치하는 방식으로 만들게 됩니다.

그런데 이 기본 NavigationBar를 숨겨버리면 저 뒤로가기 제스처가 비활성화됩니다. 그래서 이를 다시 활성화해주려면 직접 NavigationView로 가서 다시 활성화해주는 과정이 필요했습니다. 이게 되는지 체크해보라는 의미의 항목도 HIG에 귀신같이 들어있었습니다.

그래서 커스텀이 필요할 때는 기본 제공에서는 제공해주는 기능들도 놓치지 않도록 주의하며 커스텀해야 애플 플랫폼에 적절히 통합되는 UI를 만들 수 있을 것입니다.

지금까지 HIG 일부 항목과 캐시미션에서 체크해볼만한 파트를 함께 비교해보았습니다. 엄청나게 방대한 HIG 항목 중 정말 극히 일부만 본 것이긴 하지만, 그럼에도 캐시미션에서 발전시킬 수 있는 포인트를 꽤 짚어낼 수 있었던 것 같습니다.

개인적으로 HIG를 읽으면서 가장 놀랐던건, 제가 생각보다 앱을 만들 때 덜 사려깊게 만들고 있었구나 하는 생각이었습니다. HIG는 여러 상황의 UI, UX에 대해 정말 세세하고 다양한 조언을 해주고 있었습니다. 읽다보면 ‘그 앱에서는 이런 것도 신경썼던거구나’라는 생각이 들기도 했습니다. 평상시에 웹, 모바일 애플리케이션을 사용할 때 불편한게 있으면 ‘왜 이런 것도 처리 안해둔거야’하고 짜증낼 때가 있었는데, 실제로 제가 앱을 만들 때는 그런 생각을 안하고 있었다는 것을 깨닫고 나니 부끄럽더라고요.

HIG를 공부해보면서 UI, UX에 대해 조금이나마 알게 되었고 기획이나 디자인된 것을 볼 때 어떤 의도로 이렇게 하신건지 좀 더 생각해볼 수 있게 되었습니다. iOS 개발자라면, 그리고 iOS 앱 디자이너라면 한번쯤 읽어보시면 좋을 내용인 것 같습니다. 추천드립니다.

긴 글 읽어주셔서 감사합니다!