brunch

You can make anything
by writing

C.S.Lewis

by UX 컨설턴트 전민수 Oct 27. 2016

아이콘 UX 디자인 원칙

UX 디자인 배우기 #60

Today UX 아티클


SmashingMagazine에 올라온 Nick Babich의 글 Icons As Part Of AGreat User Experience를 전문(全文) 번역한 글입니다. 


아이콘은 많은 유저 인터페이스의 기본적인 부분으로, 대상, 액션, 아이디어 등을 시각적으로 표현해줍니다. 제대로 만들면 핵심 아이디어와 제품이나 액션의 의도를 전달해주며, 스크린 상의 공간을 절약해주고 심미적 매력을 높여주는 등 유저 인터페이스에 좋은 이점을 많이 제공해줍니다. 끝으로, 대부분의 앱과 웹사이트에는 아이콘이 있습니다. 유저에게 익숙한 디자인 패턴이죠. 


이러한 장점에도 불구하고, 디자이너가 아이콘 뒤에 숨겨둔 기능을 알아채기 어렵다면 아이콘은 사용성 문제를 일으킬 수 있습니다. 


아이콘의 첫 번째 역할은 유저가 가야 할 곳으로 유저를 안내하는 것이며, 이번 글에서는 그것을 가능하게 하려면 무엇이 필요한지 살펴보겠습니다. 바로 아이콘을 만들어보고 싶다면, 무료로 바로 사용 가능한 어도비의 Experience Design CC를 다운로드하여 이용해볼 수 있습니다. 


Smashing Magazine에서 더 읽어볼거리


상대적으로 작은 공간에 더 많은 컨트롤들을 충분히 보여줄 수 있도록 아이콘을 촘촘하게 배치할 수도 있다. (Image: Adobe) (View large version)


모든 앱은 앱 스토에서 사람들의 마음을 끌면서 홈 스크린에서도 눈에 띄는 아름답고 기억 가능한 아이콘이 필요하다.  (Image: Apple) (View large version)


아이콘의 유형


앞서 언급했듯이, 아이콘은 대상, 액션 또는 아이디어를 시각적으로 표현한 것입니다. 만일 그 대상, 액션, 아이디어 자체를 유저가 즉각적으로 분명하게 이해하지 못하면, 아이콘은 ‘시각적 노이즈(visual noise)’가 되어 유저가 태스크를 완료하는 것을 방해하여 못하게 할 것입니다.  


아이콘에는 “보편적 아이콘”, “상충되는 아이콘”, “독특한 아이콘” 세 가지 유형이 있습니다. 각 유형과 그것이 사용자 경험에 미치는 영향에 초점을 맞춰봅시다.  


보편적 아이콘(Universalicons)


소수의 아이콘은 유저들이 거의 보편적으로 알아보는 특권을 누립니다. 가령 홈, 인쇄, 검색, 쇼핑 카트에 쓰이는 심벌이 바로 여기에 해당됩니다. 


쉽게 알아볼수 있는 아이콘(Image: Icons8)


다만 한 가지 문제가 있습니다. 보편적 아이콘은 매우 희귀합니다. 위에서 언급한 예시 외에 대부분의 아이콘은 모호합니다. 그런 아이콘은 인터페이스에 따라서 서로 다른 의미를 가집니다.  


상충된 의미를 가지는 아이콘


문제는 상용되는 픽토그램 중 모순되는 의미를 가진 아이콘을 적용할 때 발생합니다. 하트와 별 모양 아이콘이 훌륭한 사례입니다. 두 아이콘은 관련된 기능이 앱마다 다를 뿐만 아니라, 이 두 아이콘은 서로 경쟁하는 사이입니다.


(Image: UserTesting) (Viewlarge version)


그 결과, 이 아이콘들은 정확하게 해석하기가 어렵습니다. 각 앱의 맥락 안에서 보더라도, 유저가 어떤 걸 기대하고 있는데 다른 결과가 나오면 이런 심벌은 매우 혼란을 줄 수 있습니다. 이는 아이콘에 대한 유저의 이해를 지연시키고 유저가 미래에 경험할 때 아이콘에 의존하지 못하게 합니다. 


여러 의미를 가지고 있는 다른 유명한 아이콘은 다음과 같습니다.

(Image: UserTesting)(Viewlarge version)


독특한 아이콘


아이콘은 특히 추상적인 모든 것에 좋지 않습니다. 보통은 강력한 시각적 표현이 없기 때문입니다. 여러분은 독특한 대상이나 액션을 어떻게 설명하시나요? 예를 들어, 애플이 GameCenter 앱에서 사용한 아이콘은 컬러풀한 원들로 구성되어 있습니다. 이 아이콘이 의미하는 것은 도대체 무엇인가요? 게임과 어떤 관련이 있나요?


Game Center 아이콘은 게임의 개념을 전달하는 데 실패했다.


또 다른 사례가 있습니다. 구글이 Gmail 인터페이스를 간소화하기로 결정하고 모든 것을 추상적인 아이콘 뒤에 숨겼을 때, 듣자 하니 “구글 캘린더는 어디에 있나요?”와 같은 질문이 쇄도했다고 합니다. 


데스크탑용 Gmail 유저 인터페이스 (View large version)


아이콘이 무엇을 보여주려고 했던 것인지 한 번 알게 되면 아이콘을 완전히 이해할 수 있지만, 처음 이용하는 유저가 알아내는 데는 시간이 걸릴 수 있습니다. 또 다른 문제는 처음 이용하는 유저는 이해할 수 없는 인터페이스 요소를 피하고 싶어 한다는 것입니다. 미지의 것을 피하려고 하는 것은 인간의 본성입니다. 


아이콘 디자인을 위한 실용적인 권장사항


주어진 맥락에 맞는 아이콘 선택을 위한 간단한 테크닉과 전략을 살펴봅시다. 아이콘을 고르는 것은 보통 긴 시간이 걸리는 작업이며, 어떤 선택을 하건 실제 유저를 대상으로 인터페이스 안에서 아이콘을 테스트하는 것은 매우 중요합니다. 


추상적이거나 낯선 아이콘을 명확하게 해주기 위해 레이블을 사용한다


아이콘은 텍스트를 줄여줌으로 공간을 절약할 수도 있지만, 그 결과 인식(recognition)을 희생했습니다. 아이콘은 수많은 서로 다른 단어를 표현할 수 있는데, 그게 바로 문제점입니다. 이는 심각한 오해가 될 수 있습니다. 유저가 추상적인 픽토그램을 익숙해하거나 유저가 그 의미를 알아내는데 부가적인 시간을 들일 것이라고 가정하는 것은 심각한 오해입니다. 

위의 탭 바 아이콘은 처음 안드로이드를 사용하는 유저에게 혼란을 줄 수 있다. (Image: Google)(Viewlarge version)


유저는 보통 익숙하지 않은 인터페이스를 겁냅니다. 유저가 정말로 원하는 것은 익숙하지 않은 앱에서 액션을 취하기 전에 어떤 일이 일어날지 명확한 이해를 하는 것입니다. 유저가 아이콘을 클릭하거나 탭 하기 전에 명확한 기대를 할 수 있게 해줘야 하는 것도 그것 때문입니다. 


좋은 사용자 경험은 여러 방식으로 측정될 수 있는데, 그중 한 가지 방법은 얼마나 유저를 생각하지 않아도 되게 하는지 보는 것입니다. 명확성(Clarity)은 훌륭한 유저 인터페이스의 가장 중요한 속성입니다. 대부분의 아이콘을 괴롭히는 아이콘의 모호성을 피하기 위해서 텍스트 레이블을 넣어서 특정 맥락에서의 아이콘의 의미를 분명하게 전달할 수 있습니다. 특히 액션이 복잡하거나 기능이 추상적일 때는 더 그렇습니다. 


UserTesting은 레이블이 있는 아이콘과 없는 아이콘을 비교하는 여러 테스트를 하고 다음과 같은 내용을 발견했습니다.

유저는 레이블이 있는 아이콘을 탭 할 때 어떤 일이 벌어질지 88%의 경우 정확하게 예측할 수 있습니다.
이 수치는 레이블이 없는 아이콘에서 60%로 떨어집니다. 앱 특유의 아이콘에 레이블이 없는 경우에는 탭 할 때 어떤 일이 벌어질지 34%의 경우 정확하게 예측했습니다. 


보편적 아이콘의 경우에도 레이블을 넣는 것이 보통은 더 안전합니다.

레이블이 있는 아이콘은 사용될 확률이 더 높다.  (Image: Google) (View large version)


(좌) 레이블 없는 아이콘은 보통 오해하게 만들고 혼선을 야기한다
(우) 레이블 이는 아이콘은 쉽게 의미를 전달하고 계속해서 이해할 수 있게 해준다


아이콘만으로 충분한 경우


모든 유저가 관습적으로 이용되는 아이콘을 익숙해하는 것은 아닙니다. 이는 아이콘만 있는 인터페이스를 잠재적으로 더 이용하기 어렵게 만듭니다. 반면 경험이 풍부한 유저는 텍스트 레이블이 어디에나 있는 인터페이스를 지저분하다고 생각할 수 있습니다. 우리는 어떻게 해야 모두를 행복하게 할 수 있을까요? 


Michael Zuschlag이 언급했듯, 다음 세 가지 조건 중 최소 두 가지 조건에 해당하는 경우에만 아이콘만 써도 충분하다고 합니다.

공간이 매우 제한적이다 (예: 텍스트만 넣기엔 너무 좁다)
아이콘이 표준화되어 있다 (예: 보편적 아이콘)
아이콘이 강력한 신체적 아날로그 혹은 시각적 속성으로 대상을 표현한다 (예: 페이지의 배경을 빨강으로 설정할 수 있는 빨간 사각형)


아이콘의 툴팁이나 팝오버


어떤 디자이너는 레이블이 아이콘의 목적을 무효화하며 인터페이스를 복잡하게 만든다고 믿습니다. 그런 디자이너들은 레이블 이용을 피하기 위해서 툴팁을 이용합니다. 하지만 툴팁은 텍스트 레이블의 안 좋은 대안입니다. 텍스트 레이블은 절대 그래픽 툴팁을 필요로 하지 않는다는 사실은 텍스트가 아이콘보다 더 낫다는 상당히 좋은 단서입니다. 


또 다른 주요 단점은 터치스크린에서 툴팁이 제대로 보이지 않는다는 것입니다. 튜토리얼, 코치 마크, 팝오버 힌트를 이용하는 것도 또 다른 흔한 테크닉입니다. 하지만, 유저는 튜토리얼을 대충 빠르게 넘기며 다음에 앱을 켤 때 배웠던 모든 것을 잊어버리게 됩니다. 툴팁과 마찬가지로 튜토리얼은 직관적 디자인을 위한 대안이 아닙니다. 오히려 그 반대입니다. CocoaLove의 Matthew가 말했듯이 “당신 앱의 튜토리얼 화면은 당신이 실패한 방법의 리스트에 불과”합니다. 


Swarm 앱은 유저를 교육하기 위해 팝오버 힌트를 이용한다. (Image: Mobile Patterns) (View large version)아이콘과 버튼 레이블


아이콘과 버튼 레이블


레이블을 수반하는 아이콘은 제대로 된 위치에 배치하기만 하면 정보를 찾고 훑어보기 쉽게 만들어줍니다. 자연스러운 읽는 순서에 따라 아이콘을 배치하세요. UX Movement에서 논의했듯이 아이콘 위치를 결정하는 데는 두 가지 중요한 요인이 있습니다.

아이콘을 시각적으로 스캐닝에 도움이 되는 역할을 하도록 만들려면, 유저는 관련된 레이블을 보기 전에 아이콘을 봐야 합니다. 아이콘을 레이블 좌측에 두어 유저가 먼저 아이콘을 볼 수 있게 해야 합니다. 
아이콘은 헤딩과 바디 중간으로 정렬하지 말고 헤딩과 같은 줄에 배치해야 합니다. 아이콘을 먼저 보는 것은 유저가 페이지를 더 쉽게 훑어볼 수 있도록 도와줍니다. 
(Image: UXMovement) (Viewlarge version)


데이터 표에서 사용하는 아이콘


세로로 숫자가 들어간 표를 가지고 있는데, 그 값이 좋은지, 중간인지, 나쁜지 나타내 줄 아이콘이 필요합니다. 숫자 옆에 아이콘을 놓을 때는 어느 쪽에 매치하는 것이 적절할까요? 왼쪽? 오른쪽? Don Nickel이 설명했듯이 숫자 왼쪽에 놓이는 아이콘은 보통 데이터의 의도(intent)를나타내는 반면, 오른쪽에 놓이는 아이콘은 데이터의 특성(quality)을나타냅니다. 버튼 레이블이 있는 아이콘과 마찬가지로 아이콘의 배치는 자연스러운 읽는 순서를 따라야 합니다. 아이콘 배치에는 두 가지 가능한 방법이 있습니다.


상태(Status) 아이콘은 줄 제일 끝에 보여야 합니다. 아래 예시 화면에서 볼 수 있듯, 유저는 주제(subject)를 먼저 보고 그다음에 관련된 값을 본 다음에 최종적으로 값의 상태(status of the value)를 보게 됩니다. 

아이콘 자체가 주제(subject)라면, 줄 앞 쪽에 보이고, 나머지는 그다음에 보여야 합니다.        


아코디언 메뉴의 아이콘


아코디언 메뉴는 긴 리스트를 관리 가능한 그룹으로 줄여주는 UI패턴입니다. 내비게이션 메뉴에서 쓰기에 유용하며 특히 검색 필터에 쓰면 좋습니다.


(Image: Viget)(Viewlarge version)


아코디언 메뉴를 이용할지 말지 결정하는 것 외에도 디자이너들이 보통 아코디언 메뉴를 디자인하면서 힘들어하는 부분이 있습니다. 가장 흔히 하는 질문은 다음과 같습니다.

어떤 아이콘을 이용해야 하는가? 사용성 측면에서 아이콘이 정말 필요하긴 한 것인가?
아이콘은 메뉴 항목 왼쪽에 와야 하는가? 오른쪽에 와야 하는가? 


Lance Gutin은 다양한 유형의 아이콘(V형 아이콘, +- 아이콘, 세모 아이콘)과 위치(왼쪽, 오른쪽)를 가지고 실험을 했습니다. 3가지 아이콘과 2가지 위치, 그리고 아이콘이 없는 경우를 가지고 살펴볼 아이콘을 총 7가지로 만들었습니다.  

각 테스트의 클릭 위치 히트맵 써머리 (Image: Viget)(Viewlarge version)


결과를 분석하면서 그는 두 가지 중요한 결과를 언급했습니다.


가장 설득력 있는 데이터는 아이콘의 위치와 관련이 있었습니다. 아이콘을 메뉴 항목 우측에 보여주었더니 많은 유저들이 텍스트 레이블보다는 아이콘을 선택하기를 선호했습니다. 일부 유저는 아이콘과 레이블이 서로 다른 기능을 한다고 생각했을 수도 있습니다. 아이콘의 작은 사이즈와 레이블과 아이콘 사이의 좁은 간격은 태스크 완료에 걸리는 시간을 증가시켰고, 결과적으로 아이콘이 우측에 있는 아코디언 메뉴를 이용한 태스크 수행을 느리게 만들었습니다. 
아이콘 선택에 관해서는, + 아이콘이 좌측에 배치된 아코디언 메뉴가 가장 빠르다고 측정되었습니다. 참가자의 90%가 메뉴가 바뀔 것임을 예상했습니다. 하지만, 태스크 완료에 걸린 시간은 통계적으로도 다르지 않았고, 실질적으로는 전혀 차이가 없었습니다. 


이 연구 결과가 우리 모두 아코디언 메뉴에서 좌측에 배치된 +아이콘을 사용해야 한다는 의미는 아니라는 것을 알아야 합니다. 다만, 우측에 아이콘을 때는 충분히 큰 사이즈(최소 44x44 픽셀)로 아이콘을 만들어서 손가락이나 마우스로 누르기 쉽게 만들어야 합니다.  



햄버거 아이콘을 조심한다


세 개의 가로 줄로 된 일명 “햄버거” 아이콘은 메인 메뉴 버튼으로 관습처럼 사용되고 있습니다. 특히 모바일 웹사이트에서 말이죠. 


구글의 머티리얼 디자인 웹사이트


하지만, 햄버거 아이콘을 이용할지 말지 결정할 때는 두 가지 중요한 요인을 고려하세요.


Jon Rundle의 글에 기반한 A/B 테스팅을 보면 햄버거 아이콘 기능을 정확히 인지하는 정도와 유저의 나이가 연관성을 보였습니다. 햄버거 아이콘은 나이 있는 유저에게 익숙하지 않습니다. 그러므로 사용성 관점에서 봤을 때, 여러분 유저의 대부분은 누구인지 물어보세요.


(Image: EdgarAnzaldúa) (Viewlarge version)


닐슨 노먼 그룹의 리서치에 따르면 햄버거 아이콘은 여전히 명확성을 위해 레이블을 필요로 한다고 합니다.  James Foster가 진행한 다른 연구는 햄버거 아이콘이 “메뉴”라는 간단한 단어만큼 명확하지 않다는 점을 보여줍니다. 그러므로 “메뉴”라는 단어 이용(과 버튼처럼 보이게 만드는 것)은 방문자에게 더 도움이 될 수 있습니다. 
오리지널(기준), 변형1(“메뉴”+테두리), 변형2(“메뉴”+햄버거 아이콘+테두리), 변형3(테두리 없는 “메뉴”)
(Image: Sitesfor Profit) (Viewlarge version)




최대의 어포던스를 가진 아이콘 만들기


유저 인터페이스 요소를 디자인할 때는 사용성 원칙(일관성, 어포던스 등)을 고려해야 합니다. 어포던스는 중요한 개념으로 기본적으로 ‘아이콘은 직관적이어야 한다’와 같은 요소를 의미합니다. 


1. 아이콘을 아이콘은 간단하고 개략적으로 유지한다


대부분의 경우, 아이콘은 창의력을 발휘해야 할 곳이 아닙니다. 새로운 아이콘을 디자인한다면, 대상의 기본적 특성에 집중하여 시각적 디테일을 최소화하고 굉장히 현실적인 이미지는 피하세요. 그래픽 디테일이 더 적을수록 인식에 도움이 됩니다. 


한 아이콘에 두 가지 옵션이 있다면, 간단한 버전을 선택한다.


2. 익숙한 아이콘을 선택한다


아이콘에 대한 유저의 이해는 이전 경험에 기반합니다. 인터페이스에 아이콘을 넣기로 결정했다면 먼저 리서치를 하세요. 경쟁사에서 이용하는 아이콘과 타겟팅하고 있는 플랫폼에서 흔히 사용되는 아이콘(예: 시스템 아이콘)에 스스로 익숙해지세요. 그런 것들이 바로 유저가 가장 잘 인식하는 아이콘이기 때문입니다. 


3. 특정 플랫폼에 특화된 아이콘은 이용하지 않는다


안드로이드나 iOS에서 쓰는 앱을 만들 때는 다른 플랫폼에서 사용하는 특정 테마의 UI는 사용하지 않아야 합니다. 플랫폼은 공유, 문서 생성 및 삭제 등과 같은 공통된 기능에 대해 아이콘 세트를 제공합니다. 앱을 다른 플랫폼에 가져갈 때는 구 플랫폼에 특화된 아이콘은 지워버리고 타깃 플랫폼의 상응하는 아이콘을 넣으세요. 


안드로이드와 iOS에서 공통된 기능에 사용하는 아이콘


모바일 앱에선 터치하기 좋은 타깃으로 만든다


사람들은 손가락을 이용해 터치 기반 인터페이스와 상호작용합니다. UI 컨트롤은 타깃이 작아 유저가 의도하지 않은 액션을 하게 되어 유저가 좌절하지 않도록 충분히 크게 만들어야 합니다. 아래 이미지는 성인 남성의 평균 손가락 너비를 보여줍니다. 아기들은 8mm 정도 되는 반면 성인은 대략 11 mm 정도 됩니다. 어떤 농구 선수들은 손가락 너비가 19mm 이상이라고 합니다!



(Image: Microsoft) (View large version)

사람들은 보통 스스로 “뚱뚱한 손가락”을 가졌다고 말합니다. 하지만 아기 손가락 조차 대부분의 터치 스크린보다 더 넓습니다. 


터치스크린에서 권장하는 타깃 사이즈는 7에서 10mm 정도입니다. 아래는 애플과 구글이 각각의 플랫폼을 만들 때 권장하는 사항입니다. (“iOS Human Interface Guidelines” 와 MaterialDesign을 참고하세요.)


애플은 타깃 사이즈를 최소 44 x 44 픽셀 이상으로 할 것을 추천합니다. 화면 밀도에 따라 신체적 사이즈는 다양해지기 때문에 애플이 권장하는 픽셀은 아이폰의 320 × 480 픽셀 3.5인치 디스플레이에서 가장 잘 적용됩니다.
구글은 최소한 48 x 48 DP 정도 되도록 터치 타깃을 만들라고 추천합니다. 48 x 48 DP 정도 되는 터치 타깃은 스크린 화면에 상관없이 대략 9mm 됩니다. 
터치 타겟은 유저 인풋에 반응하는 영역을 포함한다. (Image: Material Design)



위 터치 영역에서, 아이콘은 아이콘은 24DP 정도되는데 터치 타겟은 48DP 정도 된다. 수치는 안드로이드앱에 적용된다. (Image: Material Design)


하지만 타깃 사이즈만 중요한 것이 아닙니다. 터치 타깃 사이의 충분한 공간 역시 중요합니다. 터치 타깃 사이의 최소 거리를 유지해야 하는 주된 이유는 유저가 잘못된 아이콘을 터치해서 잘못된 액션을 하는 것을 방지해주기 때문입니다. 특히 “저장”과 “취소” 같은 아이콘의 경우 서로 바로 옆에 위치하기 때문에 이런 점이 굉장히 중요합니다. 이런 경우 두 타깃 사이에는 최소 2mm 정도의 간격을 두는 것이 굉장히 중요합니다.


아이콘을 테스트한다


아이콘은 조심스럽게 다뤄져야 합니다. 언제나 앱의 사용성을 테스트하세요. 처음 이용하는 실제 유저가 UI를 어떻게 이용하는지 관찰하세요. 아이콘이 충분히 명확한지 아닌지 판단하는 데 도움이 될 것입니다. 


"아이콘의 인식 가능성(recognizability)을 테스트합니다."
아이콘이 무엇을 표현한다고 생각하는지 물어보세요. 유저는 무슨 일을 하는 것인지 고민해선 안됩니다. 인식 가능하지 않으면 찾아내는 데 문제가 생깁니다.
"아이콘의 기억 가능성(memorability)을 테스트한다."
기억하기 어려운 아이콘은 보통 비효율적입니다. 유저에게 다시 한번 테스트하면서 몇 주 전 들었던 아이콘의 의미를 기억하는지 물어보세요. 


결론


아이코노그래피(Iconography)는 UI 디자인의 핵심에 위치합니다. 인터페이스의 사용성을 더할 수도 있고 해 칠 수도 있습니다. 모든 아이콘은 도움이 되어야 합니다. 추가적인 노력을 요구하지 않고 유저가 해야 할 일을 하도록 도와줘야 합니다. 제대로 디자인 한 아이콘은 유저가 카피에 별로 의존하지 않고 직관적으로 워크플로우를 따라갈 수 있도록 안내해줍니다. 유저가 생각하게 만들지 마세요. 앱의 명확성을 우선순위로 삼으세요!





전민수 UX 컨설턴트 소개

https://brunch.co.kr/@ebprux/1332


[실시간 Live 강좌] (PM/PO/UI/UX) 수강생 모집 중 

(이비피알유엑스 라이브클래스에서 매월 Live 최소 1개에서 최대 4개 UX 강좌 (온라인) 줌 Live 강좌 진행하고 있습니다)

https://ebprux.liveklass.com/


[VOD 강좌] (PM/PO/UI/UX) 수강생 모집 중  

(인프런에서 총 20개 UX 강좌: 인터넷/VOD 오픈했습니다)

https://www.inflearn.com/users/196290



매거진의 이전글 선택 버튼 상태 분명하게 보여주기
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari