모바일 UI・UX 디자인 시 고려해야 할 가이드라인 48가지

Bard·2021년 4월 28일
73

UI/UX Design

목록 보기
2/3
post-thumbnail

본 포스팅은 최철호님의 모바일 UI・UX 디자인 시 고려해야 할 가이드라인을 정리한 글입니다. 요약의 목적으로 작성했습니다.

이 가이드는 바이블이 아닙니다. 절대적인 원칙은 없으므로 무조건적으로 지킬 필요는 없습니다. 단지 모바일에서 최적의 UX 디자인을 하기 위해서 고려해야 할 사항이 어떤 것인지 참고만 하시고 디자인하시면 됩니다.

모바일 앱과 웹 디자인

모바일 앱과 웹 디자인은 데스크톱 웹 디자인과는 많은 부분이 다릅니다. 이는 각 기기의 특성과 사용 맥락의 차이에서 기원합니다.

🥑 모바일은 데스크톱에 비해 화면의 크기가 작습니다.

데스크톱은 의자에 앉아서 실내에서 사용합니다. 큰 모니터에서 많은 정보를 탐색하고 업무를 보며 몇 시간 동안 집중해서 사용할 수 있습니다.
그에 비해 모바일은 야외에서, 또는 이동 중에 사용합니다.
모바일의 이동성은 데스크톱에 비해 집중할 수 있는 사용자 환경이 아닙니다.

🥑 또한 모바일은 외부 입력도구가 없습니다.

데스크톱과 달리 손가락으로 스크롤하고, 선택하고, 텍스트를 입력해야 합니다. 따라서 스마트폰의 다양한 사용 시나리오를 개발하고 이를 디자인 작업 과정에 그대로 반영해야 합니다.

🥑 야외에서 콘텐츠를 보는 사용자를 감안해야 합니다.

햇빛이 비치는 야외에서 한 손으로 콘텐츠를 보는, 또는 뉴스를 보거나 쇼핑하는 사용자를 감안해서 디자인해야 합니다. 따라서 모바일 사용에는 필요하지 않거나 중요도가 떨어지는 기능은 숨기거나 제거하여 기능을 최소화합니다.
깊은 계층구조는 피하여 네비게이션 구조를 단순화해야 합니다.

모바일 UI・UX 디자인 가이드라인

1. 모바일에서는 모달 상태의 경고창 alert 상단 우측 "X" 버튼은 노출하지 않습니다.

모바일에서 창 닫기 버튼은 우측 상단보다 하단이 사용성이 좋습니다. 닫기 버튼이 하단에 있으면 한 손으로 사용하는 경우 엄지 손가락 터치가 쉽습니다.

2. 풀프레임 대화창 Dialog에 "X" 버튼은 왼쪽 상단을 권장합니다.

풀프레임 대화창은 사용자가 특정 정보의 입력을 요청할 경우 사용됩니다. iOS와 안드로이드 OS 모두 네비게이션 바 왼쪽에는 햄버거 버튼이나 뒤로가기 버튼같은 네비게이션 컨트롤이 위치해 있습니다.
우측에는 확인이나 기타 부가적인 컨트롤을 위치시키는 것을 기본으로 합니다.
사용자 인터페이스 일관성 측면에 네비게이션 관련 컨트롤은 동일 위치에 둘 것을 권장합니다.

3. 긍정적인 액션 버튼은 우측에 배치합니다.

모바일에서 대화창 또는 경고 메시지창 alert에서 긍정적인 액션은 오른쪽에 위치시키는 것을 원칙으로 합니다.

구글의 가이드 라인은 "대체적으로, 부정적 행동은 왼쪽에 있는 반면 긍정적 행동은 오른쪽에 있다."고 설명합니다.

4. 입력을 완료하지 않은 상태에서 완료 버튼(보내기/로그인)은 오류를 방지하기 위해서 비활성화를 권장합니다.

사용자가 모바일 환경에서 작업을 수행할 때 성공하는 경우보다 실패하는 경우가 더 많다고 합니다. 사용자의 오류가능성을 최소화해야 합니다. 사용자에게 발생할 수 있는 실수를 막고 ,오류를 방지하기 위해 인터페이스에서 어느 정도의 제약을 통해 오류가 최대한 발생하지 않게 노력해야 합니다. 오류 메시지는 사용자 경험을 해치는 주범입니다.

5. 입력 내용에 맞는 키보드를 제공해야 합니다.

모바일 환경에서 사용자가 정보를 입력할 때, 화면의 반을 가상의 키보드가 차지합니다. 화원가입같은 양식을 입력할 때, 키보드에 가려저 필드가 3개 이하로 노출됩니다. 그 이상의 필드를 입력할 때 사용자는 화면을 스크롤하면서 입력해야 합니다. 필드가 많아질수록 타이핑이 힘들고 오타가 날 확률이 높습니다.
숫자 입력란에 문자입력 키보드를 제공하는 것처럼 적절하지 못한 키보드 제공은 키보드를 변경하여 입력해야하는 번거로움이 있습니다.

6. 검색 필드 우측에 검색 버튼은 추천하지 않습니다.

검색바에서도 검색 필드 우측에 검색 버튼은 ios와 안드로이드에서 모두 추천하지 않습니다. 검색어 입력 후 키보드의 검색 버튼을 탭하는 것이 사용성이 더 높습니다.

7. 스크롤을 고려하여 콘텐츠의 그리드를 화면 하단에 정확하게 정렬하지 마세요.

사용자는 디자이너의 생각보다 스크롤을 많이 하지 않습니다. 특정한 요인이 없는 이상 스크롤 하지 않고 곧바로 검색같은 네비게이션 아이콘을 탭합니다. 스크롤하면 더 많은 컨텐츠가 있음을 예상할 수 있는 시각적인 단서를 제공해야 합니다.

8. 탭은 중첩되지 않아야 합니다.

탭은 2단으로 중첩되게 하기보다는 항목을 줄이거나(최대 5개) 좌우스크롤을 권장합니다.

9. 버튼 스타일은 중요도에 맞게 사용해야 합니다.

로그인 화면에서는 로그인이 화면의 가장 중요한 버튼입니다. [회원가입]은 로그인과 같은 형태로 디자인하면 안됩니다. 한 화면에서 다른 기능을 가진 버튼을 동일하게 디자인하지 마세요.

10. 시각적 노이즈는 최소화해야 합니다.

사용자가 콘텐츠에 집중할 수 있도록 디자인해야 합니다. 작은 화면의 모바일을 디자인 할 때, 모든 시각적인 요소는 목적과 의미를 가지고 있어야 합니다.

목적이 없는 디자인 요소는 화면을 산만하게 할 수 있습니다.

색상의 수는 제한하고 사용자의 행동을 유도하는 요소 외에는 색상을 적용하지 않아야 합니다.
작은 화면안에 기능과 콘텐츠를 촘촘하게 채우기 보다는 모바일의 사용환경을 고려하여 충분한 여백을 줍니다.
콘텐츠가 많다면 시각적인 계층구조를 명확히 하고 연관 정보는 그루핑을 통해서 화면의 복잡함을 줄입니다.

11. 네비게이션 바에서 아이콘과 텍스트 레이블을 함께 사용하지 마세요.

햄버거 아이콘 아래 menu 텍스트 레이블은 사용을 권장하지 않습니다. 사용성이 문제라면 텍스트 레이블만 사용해야 합니다. 아이콘만 사용할 것을 권장합니다.
Tab bar에서는 아이콘과 레이블 사용이 기본입니다.

12. 키보드를 통해 많은 정보를 입력하는 대화창에서 "완료" 버튼은 상단 네비게이션 바 우측을 권장합니다.

많은 정보를 입력해야 하는 풀프레임 대화창에서 입력을 위해 키보드가 노출될 경우 하단의 "완료" 버튼은 키보드에 가려지게 됩니다.

13. 회원가입 또는 로그인 시 입력한 비밀번호를 가리거나 볼 수 있는 옵션을 제공하세요.

입력한 비밀번호는 기본적으로 (••••••) 형태로 가려져 있어야 합니다. 모바일에서는 작은 키보드로 인해 오타 발생이 빈번합니다. 사용자가 입력한 비밀번호를 볼 수 있는 옵션을 토글 형태로 제공한다면 빠르게 수정이 가능합니다.

14. 네비게이션 드로워는 1단으로 하길 권장합니다.

5개 이상의 주요 탐색 경로가 있을 경우 네비게이션 드로워를 사용할 수 있습니다. 모바일은 네비게이션 구조를 단순화해야 합니다. 작은 화면에 지나치게 많은 메뉴를 보여주면 인지하기가 어렵습니다.

15. 사용자가 입력하는 내용이 형식에 맞을 경우 실시간 피드백을 해주세요.

텍스트 필드에 사용자가 입력하는 내용이 형식에 맞을 경우 실시간 데이터 확인을 통해 적절한 실시간 피드백을 제공해야 합니다. 이는 사용자의 입력 오류를 줄여주고 다이얼로그의 양식 form 입력을 완료할 가능성을 높입니다.

16. 버튼에 사용한 스타일을 다른 요소(섹션 제목)에 사용하지 마세요.

CTA(Call to Action)는 사용자에게 어떤 행위를 권하거나 유도하는 도구 또는 기법을 말합니다. 주문서 화면에서 "결제하기"는 CTA 버튼입니다. 즉, 화면에서 사용자에게 가장 눈에 띄게 해야할 요소 중에 하나입니다. 버튼은 화면 요소에서 시각적으로 차별화해야 합니다.

17. 수량 선택 기능은 오류 방지를 위해 드롭다운보다 스텝펴 사용을 권장합니다.

18. 텍스트 필드에 입력한 텍스트를 모두 지울 수 있는 Clear button은 필수적으로 제공해야 합니다.

모바일에서 텍스트를 입력하는 것만큼 지우는 것 또한 어렵습니다. 텍스트를 즉시 지울 수 있는 버튼을 기본으로 제공해야 합니다.

19. 라디오버튼은 언제나 하나의 항목이 기본으로 선택되어 있어야 합니다.

라디오 버튼 그룹 중 사용자가 가장 많이 선택할 옵션이나 편리한 옵션을 기본으로 선택되어 있게 하세요. 탭을 한번이라도 단축하는 효과가 있습니다.

20. 옵션 선택을 완료하지 않은 상태에서 오류를 방지하기 위해 완료버튼은 비활성화를 권장합니다.

만약 시스템적인 문제나 그 외 문제로 인해 옵션을 드롭다운으로 해야만 한다면 옵련을 선택하지 않은 상테에서 완료버튼을 활성화시키지 않아야 합니다.

21. '예', '아니오' 같이 두 개의 옵션만 있는 경우 하나의 체크박스 또는 토글스위치를 사용합니다.

예를 들어 동의함 라이오 버튼과 동의 안합 라디오 버튼을 각각 사용하는 대신 "동의함" 체크박스를 사용합니다.

22. 키보드에 중요한 액션 버튼이 가리지 않아야 합니다.

폼 스크린에서 로그인 등 입력 필드 하단에 확인 버튼이 있는 경우 키보드에 버튼이 가려지지 않아야 합니다. 키보드가 있는 상태에서 완료가 가능해야 합니다.

23. 모바일에서 팝업을 권장하지 않지만 꼭 필요하다면 풀프레임 팝업을 고려해보세요.

모달 팝업은 사용자에게 거부감을 줍니다. 꼭 필요한 팝업이라면 풀프레임 팝업을 고려해 보세요.

24. 모바일에서 좌우 슬라이드 되는 컨텐츠는 가로 그리드에 딱 맞출 필요는 없습니다.

모바일의 한정된 화면 크기에서 콘텐츠를 부각할 방안을 고민해야 합니다. 좌우 슬라이더 하단의 도트 페이지네이션 공간을 절약하는 것도 하나의 방법입니다.

25. 메인 페이지의 슬라이더 이미지는 3~5개가 적정합니다.

사용자는 자주 슬라이더를 둘러보지 않습니다. 따라서 두 번째, 세 번째 이상의 프로모션은 노출이 적고 효과가 크지 않습니다.

26. 라디오 버튼은 소팅 기능에 사용할 수 없습니다.

라디오 버튼은 선택과 관련된 기능에서만 사용되어야 합니다. 라디오 버튼을 탭했을 경우 하나의 옵션만 선택 상태가 변경되고 그 외의 액션이 실행되지 않아야 합니다. 따라서 사용자가 옵션을 선택했을 때 화면의 상태가 바뀌는 액션 실행은 iOS의 세그멘트 컨트롤이나 탭으로 디자인되어야 합니다.

27. 라디오 버튼 옵션 내에 또 다른 옵션을 넣지 않습니다.

라디오 버튼 항목 안에 다른 라디오 버튼이나 체크박스나 입력 필드 등 다른 옵션을 만들지 않아야 합니다. 모든 라디오 버튼 옵션은 선택과 관련된 하나의 레벨로 디자인되어야 합니다.

28. 링크 텍스트에 밑줄은 사용하지 않습니다.

모바일 앱의 경우 링크와 버튼은 구분하지 않고 버튼으로 표현합니다.

29. 선택 옵션이 5개 이하일 경우 드롭다운보다는 옵션을 노출하는 게 좋습니다.

드롭다운은 옵션의 개수가 많을 경우 화면의 공간을 줄여주는 좋은 요소입니다. 일반적으로 7개 이상의 옵션일 경우 드롭다운 사용을 권장합니다.

30. 탭 바의 항목은 최대 5개로 제한됩니다.

iOS에서 말하는 탭바(안드로이드 Bottom Navigation)의 항목은 최대 5개로 제한됩니다.

31. 경고창의 버튼은 테두리가 없는 텍스트 버튼 사용을 권장합니다.

테두리나 면으로 된 랜딩페이지의 CTA 버튼 같은 중요한 경우에만 사용할 것을 권장합니다. 그 외에 경고창 같은 화면에서는 텍스트 버튼 사용을 권장합니다.

32. 테두리가 있거나 면으로 된 버튼보다는 테두리가 없는 텍스트 버튼을 기본으로 사용하세요.

테두리를 사용해서 터치할 수 있다는 것을 표현하기 보다는 버튼 레이블을 의미 있는 단어로 지정하고 메인 컬러나 시스템 컬러를 사용해서 해당 요소가 인터랙션 가능하다는 것을 알립니다.

33. 중요한 콜 투 액션 버튼의 경우 사용자가 스크롤하더라도 지속적으로 볼 수 있어야 합니다.

콜 투 액션 버튼은 전환율과 직접적으로 연관성이 높습니다. 사용자가 페이지 내에 상세한 콘텐츠를 보다가도 필요할 때 사용 가능하게 화면 하단에 지속적으로 노출되어야 합니다.

34. 네비게이션 요소와 UI 요소가 컨텐츠보다 더 부각되지 않아야 합니다.

네비게이션 요소와 컨트롤은 사용자가 컨텐츠를 탐색하고 상호작용할 수 있게 해주는 수단일 뿐입니다. 이 두 요소는 컨텐츠보다 부각되어서는 안됩니다.

사용자가 네비게이션의 존재를 느끼지 못한다면 가장 훌륭한 네비게이션입니다.

35. 삭제와 같이 되돌릴 수 없는 액션의 경우, 다시 한번 확인 요청을 합니다.

사용자가 실수로 항목을 삭제할 경우 되돌리기는 매우 어렵습니다. 항목을 삭제하거나 입력을 하던 중 취소할 경우, 정말로 실행할 것인지 확인요청을 해야 합니다.

36. 사용자의 노력으로 만들어진 정보는 쉽게 삭제할 수 없게 디자인되어야 합니다.

블로그, 주소록, 장바구니에 담긴 상품 등 사용자가 직접 입력하거나 실행하여 만들어진 정보는 삭제가 어렵게 만드는 것이 좋습니다.

37. 리스트에서 선택 또는 실행 버튼은 불필요합니다.

리스트의 항목 하나하나를 터치할 경우 주요 액션이 실행됩니다. 따라서 주 액션을 실행하기 위한 버튼이나 아이콘, 텍스트는 사용하지 않습니다. 리스트 내에 주 액션 외의 부수적인 액션은 오른쪽에 놓습니다.

38. 주 액션과 되돌릴 수 없는 액션은 같은 위치에 배치하지 않을 것을 권장합니다.

화면에서 주 액션을 부가적인 액션과 동일한 위치에 배치하지 않아야 합니다. CTA 버튼은 가장 강조되고 그 외의 부가적인 버튼이 부각되지 않아야 합니다.

39. 본문의 행간은 150% 이상이어야 읽기가 쉽습니다.

모바일 화면에서 정보를 읽을 때 이해도 점수는 데스크톱 수준의 48%에 그친다고 합니다. 모바일은 작은 화면으로 웹보다도 가독성이 떨어지는 환경이므로 글줄의 간격은 더 넓어야 합니다.

40. 네비게이션 바에 너무 많은 컨트롤은 피하세요.

일반적으로 컨텐츠 페이지와 상세정보 화면에서 네비게이션 바에는 현재 화면 타이틀, 뒤로 가기, 화면 컨텐츠를 관리하는 컨트롤 외에 추가적인 요소는 넣지 않는 것을 권장합니다.

41. 한 화면에 뒤로 가기 버튼은 하나여야 합니다.

작은 화면에 동일한 기능을 중복 배치하는 것은 사용자에게 혼란을 줍니다. 하단 탭바가 있는 앱의 경우 네비게이션 바와 기능이 중복되지 않아야 합니다.

42. 상단 네비게이션 바에 네비게이션 요소의 중복을 피할 것을 권장합니다.

모바일 앱의 컨텐츠 페이지 또는 상세 페이지에서 네비게이션 바 왼쪽에 뒤로 가기와 같은 네비게이션 요소가 있다면 우측에 네비게이션 요소는 없어야 합니다. 이 경우 네비게이션 우측은 편집, 완료, 공유 버튼 같은 컨트롤이 있어야 합니다.

43. 뒤로 가기 옆의 레이블은 이전 화면명입니다.

iOS에서는 일반적으로 뒤로가기 화살표 옆에 이전 화면명을 배치시킵니다. 즉 현재 페이지의 상위 그룹으로 이동을 의미합니다. 현재 페이지의 화면명은 혼란을 피하기 위해 네비게이션 바의 중앙에 위치시켜야 합니다.

44. 모바일에서는 Breadcrumbs를 사용하지 않습니다.

모바일에서는 네비게이션을 단순화해야 합니다. 브레드크럼이 있어야 한다면 네비게이션이 복잡함을 의미합니다. 브레드크럼이 여러 장점이 있지만 이는 데스크탑 웹사이트에 한해서입니다. 모바일에서는 사용하지 않는 것이 좋습니다.

45. 모바일에서 탑 버튼을 사용하지 않아도 됩니다.

모바일에서는 데스크탑에 비해 탑 버튼이 불필요할 수 있습니다. 꼭 사용해야 한다면 사용자가 아래로 스크롤할 경우 노출하지 않고 스크롤을 멈추거나 위로 스크롤할 때 노출하는 인터랙션을 고민하세요.

46. 가독성을 위해서 중앙 정렬은 피하세요

사용자는 F패턴으로 콘텐츠를 훑어봅니다. 중앙 정렬은 F패턴으로 읽을 경우 가독성이 떨어집니다. 이로 인해 눈의 피로가 발생할 수 있어 많은 양의 글에는 가운데 정렬을 피하세요. 특히 이동중일 경우 사용자는 읽기를 포기할지도 모릅니다.

47. 비활성화 요소에 활성화 요소와 동일한 색상을 사용하지 마세요.

비활성화 요소는 탭을 해도 반응하지 않음을 의미합니다. 비활성화 요소가 활성화 요소와 같은 색을 띠면 사용자는 어떤 요소가 탭이 가능한지 구분하기 어렵습니다.

48. 버튼에 사용자의 의도와 관련이 없는 예, 아니오 같은 레이블은 사용하지 않아야 합니다.

버튼은 사용자가 클릭하거나 터치할 때 발생할 동작을 표현합니다. 사용자가 버튼을 누를 때 발생할 동작을 설명하는 텍스트 레이블을 사용해야 합니다. 버튼의 레이블은 명확하고 예측 가능해야 합니다. 즉, 사용자는 버튼을 탭할 때 어떤 일이 발생하는지 명확하게 예상할 수 있어야 합니다.

profile
The Wandering Caretaker

2개의 댓글

comment-user-thumbnail
2021년 4월 29일

잘쓰셧네요 ㄷㄷ 내일 출근할때 읽겠습니다

답글 달기
comment-user-thumbnail
2021년 8월 20일

감사합니다

답글 달기