딱 1년 전, 작년 추석 연휴 기간에 <나홀로 해커톤>을 진행했다.
6일 내내 작업을 했고, 연휴 마지막 날에 리마인더 앱 <아차차>를 출시하였다.
기획, 디자인, 개발까지 혼자 진행했었고, 프로젝트에 대한 자세한 내용과 회고를 이곳에서 확인할 수 있다.
(* 해커톤이라고 지칭하긴 했지만, 기획 및 디자인은 이미 몇 달 동안 고민하고 설계한 상태였다. 6일은 개발만 집중했다.)
이 <아차차> 프로젝트는 초기부터 UI에 신경을 많이 썼었다.
애초에 "개발이 복잡하고 어려운 서비스"가 아니라, "디자인적으로 이쁘고 명확한 서비스"를 만들고 싶었다.
출시 후 주변 피드백을 반영하며 총 5번의 업데이트를 하며 UI를 개선했다.
이 글에서는 "아차차"의 UI에 대해서 이야기해보고자 한다.
1. UI디자인 법칙
대학생 때, <UI디자인>이라는 전공과목을 수강했다.
그것도 벌써 몇 년 전 일이기에, 급변하는 IT 서비스의 특성상 내가 배운 지식이 지금도 유효한지 자신은 없다.
그렇지만, 내가 UX/UI와 관련해서 알고 있는 내용을 이것이 전부라서, 이 지식을 기반으로 프로젝트를 제작하고 개선했다.
(혹시 UX/UI 디자이너나 전문가가 글을 읽으신다면 미리 양해의 말씀 드립니다.)
내가 배운 UI디자인 법칙은 크게 아래의 4가지이다.
(1) 가항성 (Navigability)
(2) 간결성 (Simplicity)
(3) 명확성 (Clarity)
(4) 일관성 (Consistency)
(1) 가항성은 유저가 원하는 바에 효율적으로 도달할 수 있도록 해주는 것을 의미한다.
Navigability라는 용어에서 유추할 수 있듯 사용자가 서비스를 편하게 "내비게이트"할 수 있도록 하는 것이 가항성이다.
유저가 현재 어떤 상태에 있는지 파악하게 해주고, 다음 단계로 갈 수 있도록(유저가 원하는 목적을 달성할 수 있도록) 인도하여서 자연스러운 사용자 경험을 제공해줘야 한다.
제작자가 원하는 특정 행동을 하도록 유도하는 것(ex. 깜빡이는 UI로 상호작용이 가능한 요소라는 것을 표시, 일부 콘텐츠를 노출하여서 스크롤 시 더 많은 콘텐츠가 있음을 드러내기 등) 또한 가항성의 예시이다.
(2) 간결성은 불필요한 요소를 없애서 단순하고 알아보기 쉬운 인터페이스를 제공하는 것을 의미한다.
중요 요소만 남기고 나머지 요소들은 숨김으로 한눈에 인지할 수 있게 하는 것, 규칙화 및 조직화(ex. 요소들의 크기나 여백을 통일하기, 성격에 따라서 그룹핑하여 UI로 표현하기 등)하여서 많은 정보들을 효율적으로 파악하게 하는 것이 간결성을 증대한 예시이다.
(3) 명확성은 유저가 기능이나 요소를 알 수 있도록 분명하게 표시하는 것을 의미한다.
가시성을 개선하거나, 현재 수행하는 동작(ex. 진행 현황이나 현재 버튼 액션 상태 등)을 시각적으로 표현하는 것, 2개 이상의 표현(ex. 색상+모양으로 현재 신호를 알려주는 신호등 등)으로 현 상태를 표시하는 것 등이 명확성에 속한다.
(4) 일관성은 인터페이스 요소에 규칙을 적용해서 일관되게 하는 것을 의미한다.
전체 서비스 내에 일관된 상호작용이나 일관된 디자인 표현을 제공하는 것, 혹은 소위 디자인시스템이라고 불리는 일종의 디자인 규칙을 적용하는 것이 일관성의 예시이다.
4개로 분류해서 기술하기는 했지만, 특정 법칙만 개선시키는 것도 어렵다.
가령, 가항성을 높이려고 유저 동작에 힌트를 추가하다 보면, 자연스레 명확성이 높아질 수 있다.
반대로, 법칙을 모두 지키는 것 또한 어렵다.
명확성을 높이고자 설명을 추가한다면 필연적으로 간결성에 위배될 수 있다.
그렇기에 특정 법칙을 지키려고 집착하기보다는 그때그때 서비스의 성격에 맞춰서 더 나은 디자인이 무엇인지 고민해야 한다고 배웠다.
2. 아차차의 UI 개선안
<아차차>는 추석 기간 해커톤을 해서 출시하는 것이 목표였기 때문에, 연휴 마지막 날에 맞춰서 작업을 1차로 마무리하여 출시하였다.
이후, 스스로 아쉬운 UI와 주변 피드백으로 불편함을 인지한 UI들을 개선해서 1.1.2 버전까지 출시하였다.
이제부터 1.0.0부터 1.1.2에 이르기까지 어떤 부분이 개선되었는지 소개하고자 한다.
(* 글의 편의상, 앞으로는 초기 버전을 V1으로, 5번 업데이트를 한 후인 1.1.2버전을 V5로 지칭하겠다.)
2-1. 도움말 UI
앱의 메인탭에 서비스 이용 도움말로 유도하는 UI가 위치해 있다.
복잡하지 않은 서비스를 제공하다 보니, 유저의 의지와 무관하게 서비스 설명을 들어야 하는 온보딩 페이지가 불필요하게 느꼈다.
그보다는 선택적으로 서비스 설명을 볼 수 있는 도움말 형태가 더 적절하다고 판단하였다.
그래서 메인탭에 진입하면 볼 수 있는 도움말 UI를 추가하였다.
하단에 쌓이는 알림 리스트와 이질감이 없도록 유사한 형태로 UI를 디자인했다.
같은 화면에 보여지는 UI 요소끼리의 일관성을 지키기 위한 선택이었다.
그러나 나의 의도와 다르게 앱을 최초 실행한 유저가 보게 되는 화면은 아래와 같았다.
초기에는 알림 리스트가 없기 때문에 도움말 UI만 표시되었다.
그로 인해 일관성을 지킨 장점을 가려졌고, 동시에 홀로 표시된 해당 UI가 눌린다는 사실조차 인지되지 않았다.
이를 개선하고자 아래와 같이 "더 알아보기" 캡션을 추가해서 해당 UI가 탭액션이 있다는 단서를 제공해 주었다.
캡션이 추가되더라도 UI가 복잡해 보이지 않도록 색상을 통해서 정보의 계층 구조를 드러냈습니다.
가장 강조되어야 하는 제목을 진하고 굵게 표기하여서 해당 UI가 초기 유저를 위한 콘텐츠임을 알도록 했다.
2-2. 하단 탭바 아이콘
지금 돌아보면 가장 치명적인 실수를 한 부분이었다.
이를 계기로 자신의 디자인에 익숙해지는 것이 얼마나 위험한지를 알게 되었다.
V1의 탭바 아이콘은 의미 자체가 V5와 달랐다.
첫 번째 탭의 경우, "알림 리스트를 보여주는 화면"이라는 것에 지나치게 초점이 맞춰져 있었다.
직사각형 여러 개가 수직 방향으로 붙은 형태 등을 생각하다가, 결국에는 수평선 세 개가 세로로 이어진 아이콘을 채택하였다.
너무나도 익숙한 "햄버거 버튼" 그 자체였으나, 알림 리스트의 형태에 잠식된 나는 인지하지 못했다.
더불어서, active와 inactive 상태의 색상 차이가 크지 않은데, 작고 얇은 아이콘들로 탭이 구성되다 보니, 현재 선택된 탭이 무엇인지 한눈에 알기 어려웠다.
탭의 아이콘을 명확하게 바꾸고자, 알림 리스트 형태에 대한 집착을 버렸다.
알림 리스트 화면을 표현할 아이콘을 찾는 대신, 홈의 의미로 아이콘을 변경하였다.
아이콘의 전반적인 형태도 stroke상태와 fill상태로 각각 표현할 수 있는 형태로 수정하였다.
2-3. 알림 설정
더보기 탭에는 알림 설정(시스템 설정)으로 이동시키는 버튼이 있다.
<아차차>는 주요 기능과 컨셉이 알림 제공이기 때문에, 알림을 허용하지 않으면 서비스 전체를 사용하지 못하는 격이다.
그렇기에 더보기 화면의 최상단에 알림 설정 버튼을 추가하였다.
초기에는 아이콘의 역할을 하는 종모양 이미지와 "허용"("허용 안 함") 텍스트가 표시되었다.
여기에는 2가지 문제가 있었다.
첫 번째로, 더보기 화면을 제외한 모든 곳에서 해당 종모양 이미지는 active, inactive 두 가지 상태를 표현하도록 사용되고 있었다.
더보기 화면에서는 아이콘의 역할을 하기 때문에 active, inactive 표현 없이 neutral하게 이미지를 사용하려고 했으나, 앱 전반은 사용하면 경험이 쌓인 유저에겐 오히려 헷갈림을 유발했다.
두 번째는 "허용"이라는 말에 있었다.
현재 상태를 표시하는 것인지, 해당 버튼을 누르면 허용이 된다는 뜻인지 헷갈린다는 주변의 피드백이 있었다.
종모양 이미지마저 허용/비허용 여부를 표현하지 않고 있었으니, 이 부분이 더 혼란스럽게 다가갔던 것으로 보인다.
이에 현재 상태 허용/비허용 상태에 따라서 종모양 이미지의 형태가 변경되도록 수정하였고,
"허용"("허용 안 함") 대신에, "허용됨"("허용 안 됨")을 사용하여 현재 상태를 표현하는 것임을 명확히 하였다.
종모양 이미지가 상태를 반영하면서, 아래의 다른 항목들과의 일관성을 깨지게 되었다.
그렇지만, 주요 기능인 알림의 활성화 상태가 보다 명확하고 직관적으로 보인다는 점에서 V5의 UI가 더 적절하다고 판단했다.
2-4. 의도한 동작으로의 유도
마지막으로, 알림의 프로필을 설정하는 부분에서 의도한 동작으로 유도하는 장치를 추가하였다.
알림 프로필에는 한 글자의 문자를 입력할 수 있고, 미입력 시 알림 이름의 첫 글자를 따도록 설계되어 있다.
심미성이나 서비스의 분위기를 고려하여서 프로필은 이모지를 사용하기를 권장하고 싶었다.
서비스 설명이나 앱스토어, 인스타그램 등 다양한 채널 속 예시에서 "이모지"를 사용함을 알 수 있다.
그렇지만, V1에서는 이 부분에 대해서 직접적인 유도가 없었다. (설명을 추가하기는 했지만, 텍스트가 눈에 잘 보이지 않았다.)
V5에서는 프로필 변경을 하려고 할 때, 일반 키보드가 아닌, 이모지 키보드가 올라오도록 하였다.
이를 통해, 추가적인 설명 없이도 유저가 이모지를 입력하도록 인도했다.
3. 마치며
프로젝트 회고에도 작성하였지만, "아차차" 프로젝트를 개발하고 개선하며 타인(특히 유저)의 의견을 꼭 들어봐야 한다는 것을 절실히 느꼈다.
서비스에 대한 이해도는 제작자인 내가 제일 높겠지만, 일반 유저는 제작자가 아니다.
그렇기 때문에 생각하는 것보다 조금 더 친절할 필요가 있다. (유저가 적응하기까지 기다리는 건 무책임한 태도인 것 같다.)
또, 한 프로젝트를 오래 봐오다 보니 객관성을 잃게 된다.
한 걸음 떨어져서 서비스를 바라보는 시간이 필요한데, 이미 객관성을 잃은 상태에서 서비스와 멀어지기는 쉽지 않다.
서비스에 대한 애정과 고민이 너무 깊어지면 오히려 유저 경험을 헤칠 수 있다는 것을 깨달았다.
+ 따로 부탁하지 않았는데, 서비스를 사용해 보고 피드백을 줬던 주변 분들께 감사함을 전합니다.
'iOS' 카테고리의 다른 글
| [Swift] 갈대 유리 효과 구현하기 (효과 설계 과정, CIFilter) (4) | 2024.10.13 |
|---|---|
| [Swift] 뉴모피즘 구현하기 (inner Shadow, HSB 색상 추출) (0) | 2024.10.02 |
| '주니어 제너럴리스트'의 중간 점검 (4) | 2024.08.26 |
| [iOS] Border과 CornerRadius에 대한 고찰 (1) | 2024.06.24 |
| [Swift] 글래스모피즘 구현하기 (UIVisualEffectView, UIViewPropertyAnimator) (1) | 2024.06.03 |