본 글은 uxdesign.cc에 기재된 글을 각종 번역기와 의역, 배경지식을 활용해 번역한 글입니다. 최대한 이해가 가기 쉽게 번역했지만, 영어 능력이 좋으시다면 이 글 보다는 아래의 원글을 보시는 것을 권해드립니다. (본 글의 저작권은 Taras Bakusevych 및 UX Collective에 있습니다.)
사용자 인터페이스에서 중심이 되는 인터렉티브 블록을 만들기 위해 버튼 디자인에 대해 알아볼 필요가 있습니다.
올바른 인터렉션 디자인을 위해서 우리는 물리적인 버튼에 대한 기원과 변화의 과정을 살펴봐야 합니다.
기기나 자동차 혹은 시스템을 조작하는 데 있어 작동 원리를 이해하지 못해도 조작이 가능하다는 측면에서 버튼은 놀랍습니다.
Rachel Plotnick(레이첼 플로트닉)은 오늘날 누르는 버튼이 어떻게 나왔고, 디지털 UI에 주요 수단으로 적용이 되었는지 유래와 이유를 설명합니다.
“버튼을 누르면, 알아서 사진을 찍어줍니다.” — Kodak 카메라는 매력적인 문구를 직접적으로 소비자에게 드러냈습니다.
(덧붙임) 과거의 카메라는 조리개, 초점, 셔터속도를 일일이 조정해야 했지만, Kodak 카메라는 버튼 하나로 이를 알아서 해준다는 점에서 위 문장을 이해하면 좋을 것 같습니다.
코닥의 이 문구는 사용자를 매료시키는데 오늘날에도 유효합니다. 오늘날 가전제품 혹은 다양한 장치들이 터치스크린 안에서 컨트롤이 가능하도록 바뀌었음에도 불구하고 물리적으로 누르는 버튼은 사라지지 않을 것입니다. 오히려 물리적인 버튼에서 형성된 행동 습관이 버튼 디자인이 얼마나 직관적으로 사용하기 쉬운지 일깨워 줄 것입니다.
버튼 vs 링크
버튼은 사용자가 수행하려는 동작을 나타내고 전달합니다. 보통 대화상자(Dialog), 양식(Forms), 툴바(Toolbars) 등에 위치하며 버튼과 링크의 차이는 아래와 같습니다.
링크는 주로 모두 보기, Roger Wright(피아니스트)의 프로필 등과 같이 다른 페이지로 이동할 때 사용합니다.
버튼은 주로 제출(Submit), 병합(Merge), 새로 만들기, 업로드와 같은 특정 작업(혹은 행동)을 수행할 때 사용합니다.
(덧붙임) 링크는 페이지가 완전히 전환되고, 버튼은 페이지 내에 새로운 모달이나 일부분만 바뀔 때 사용된다고도 이해해도 좋을 것 같습니다.
버튼의 상태(States)는 사용자에게 현재 어떤 상태인지를 알려줍니다.
버튼에 올바른 인터렉션과 스타일을 만드는 것은 디자인 프로세스에서 가장 중요한 부분 중 하나입니다. 버튼의 상태(States)는 다른 상태와 주변 레이아웃과 명확히 구별되게 디자인되어야 하며, 구성 요소를 크게 변경하거나 시각적인 방해 요소를 만들어서는 안 됩니다.
Normal — 버튼이 활성화(클릭 가능) 되어 있음을 나타냅니다.
Focus — 사용자가 키보드 혹은 다른 입력 방법을 통해 포커스를 이동하여 해당 위치에 머물러 있음을 강조합니다.
Hover — 사용자가 버튼에 커서를 위치할 때를 나타납니다.
(덧붙임: 모바일 터치 환경에선 active가 명시되지 않을 때 클릭하면 hover 상태가 나타납니다.)
Active — 활성 혹은 버튼이 눌렀음을 나타냅니다.
Progress/Loading — 작업이 바로 이루어지지 않아 요청 사항이 진행 중임을 알리는 경우에 사용됩니다.
Disabled — 버튼이 비활성화되어 현재 사용할 수 없지만, 나중에 다시 활성화 될수 있습니다.
버튼은 다양한 색상, 모양 및 크기로 제공됩니다.
버튼의 가장 흔한 디자인은 모서리가 있는 스타일로, 쉽게 식별할 수 있고 입력 필드(input) 옆에서도 잘 보입니다. 버튼에 적합한 스타일을 정하는 것은 디자인 대상의 목적, 플랫폼 및 지침에 따라 다릅니다. 가장 많이 사용되는 스타일은 다음과 같습니다.
버튼의 스타일은 동작 수행의 중요성을 알립니다.
버튼의 스타일을 통해 중요도를 구분하기 위해서 혹은 다양한 선택지가 있다는 것을 사용자에게 알려주는 일련의 힌트를 제공할 수 있습니다. 일반적으로 가장 눈에 띄는 버튼 (보통 이러한 스타일은 primary라고 말함)과 중간단계의 secondary, 더 낮은 단계인 tertiary를 사용합니다.
기본값이 없는 버튼도 있습니다.
보통 가장 일반적으로 선택(혹은 사용)되는 버튼을 “default”(primary)로 두고 눈에 띄는 강조 상태로 두어 행동을 유도하세요. 이는 대다수의 사용자가 작업을 더 빨리 완료하고 올바른 행동을 할 수 있도록 도와줍니다.
생각하게 하지 마세요.
Don’t Make Me Think (사용자를 생각하게 하지 마!)는 사용성 엔지니어 Steve Krug의 책 제목입니다. (덧붙임 — 실제로 최근 국내에서도 인기가 많습니다.) 책에서 강조하는 점 중 하나는 퍼즐이나 미로를 만들지 않고 사용자에게 인터페이스를 명확하게 전달하는 것이 중요하다는 것입니다. 버튼은 과거부터 시작해 지금까지 다양한 기기들에 적용되면서 어떻게 보이고 작동하는지에 대한 관습이 형성되어 있습니다. 관습(원문에선 표준)으로 보이는 것과 크게 다르다면 사용자는 버튼을 인식하는 데 시간이 오래 걸리고 혼란을 겪게 됩니다.
버튼과 버튼이 아닌 요소(ex_ 배경)에 동일한 색을 사용하지 마세요. 동일하게 사용할 경우 사람들이 어디를 클릭해야 하는지 알기 어렵습니다.
일관성은 속도와 정확성을 향상시킵니다.
“일관성은 가장 강력한 사용성 원칙 중 하나입니다. 특정 동작이 항상 동일하게 행동할 때 사람들은 무슨 일이 일어날지 고민할 필요가 없습니다.” Jacob Nielsen(야콥 닐슨)
일관성은 속도와 정확성을 향상시키고 오류를 방지합니다. 버튼을 디자인할 때 사용자가 통제할 수 있음을 느끼게 하고 쉽게 목표를 달성할 수 있도록 예측 가능성을 높여보세요. 기본 스타일(primary), 두 번째(secondary), 세 번째(tertiary) 스타일을 지정할 때 색상, 모양과 같은 몇 가지 공통 요소를 찾아보세요. 디자인 시스템 내에서 일관성을 유지할 뿐만 아니라 적용되는 플랫폼의 디자인과도 어우러져야 합니다.
원활한 클릭을 위해 버튼을 충분히 크게 만드세요.
버튼은 쉽고 간단하게 누를 수 있어야 합니다. 사용자가 버튼을 실수로 누르지 못하거나 근처 다른 요소를 누르게 된다면 시간이 낭비되고 부정적인 경험이 쌓이게 됩니다.
손가락 터치를 이용하는 모바일 환경을 위해 클릭 가능한 영역을 최소 48x48DP 이상으로 잡아주세요. 이 크기는 화면 크기에 상관없이 물리적 크기가 약 9mm로 나타납니다. 터치스크린에서 누를 수 있는 요소의 권장 크기는 최소 7–10mm 입니다.
아이콘 버튼의 경우 터치 가능한 영역이 아이콘을 넘어 확장되는지 확인하세요. (덧붙임 — 쉽게 말해 padding, 아이콘 주변으로 여백을 줍니다.) 이는 모바일이나 태블릿에만 적용되는 것이 아니라 마우스와 같이 PC 웹의 포인터 장치에서도 동일하게 적용됩니다.
접근성을 위한 디자인
버튼뿐만 아니라 모든 구성요소에 접근성을 고려해 디자인해야 합니다. 바로 위에 언급된 버튼의 크기는 접근성에 영향을 미치는 요소 중 하나였습니다. 이외에 글꼴의 크기, 색상, 대비도 있습니다. 접근성을 충족하는지 확인하는 측정하는 다양한 도구들이 있습니다.
(덧붙임) 접근성과 관련해 도움이 되는 국내 사이트는 NAVER NULI(nuli.navercorp.com) 입니다. 보통 명도 대비는 글꼴의 크기에 따라 달라지지만, 최소 3:1, 보통은 4.5:1 이상이 되어야 합니다.
다음(현 카카오) 다룸(darum.daum.net)도 있지만 업데이트가 되지 않은 지 오래되어서 저는 주로 NAVER NULI를 참고합니다.
이외에 레진코믹스(https://github.com/lezhin/accessibility/), NHN TOAST UI도 도움이 많이 됩니다.
디자이너는 개발자와 긴밀하게 협업하면서 버튼이 스크린 리더에서 잘 작동하는지 확인해야 합니다. 사용자가 특정 행동을 활성화할 때 응답을 트리거하는 요소에 버튼을 사용해야 합니다. role =”button”을 추가하면 스크린 리더에 버튼 컨트롤로 나타납니다. (덧붙임 — role를 사용하면 버튼 요소 외에도 버튼처럼 지정할 수 있지만 W3C에서도 권장하지 않으며, 될 수 있으면 button 그 자체를 사용하는 것이 좋습니다.)
제스처는 생각보다 많은 곳에 적용되어 있습니다.
제스처는 사용자가 터치를 사용해 애플리케이션과 상호작용 할 수 있도록 도와줍니다. 기본적인 터치에서 진화된 다양한 방법(단순 클릭이 아닌 더블클릭, 스와이프 등)을 사용하면 작업을 수행하는 데 있어 시간을 절약하고 다채로운 터치 제어가 가능해집니다.
스와이프 혹은 더블클릭하여 좋아요, 길게 누르기 등은 상황에 맞게 행동을 유도할 수 있지만 아직은 일반 사람들에게 명확하지 않습니다. 대신 이러한 제스처는 이해도가 높은 고급 사용자들을 위한 부가 요소(없어도 그만이나 있으면 좋은 요소)로 사용하는 것이 좋습니다.
좋은 버튼 디자인은 사용자의 행동을 유도하는 이름을 사용합니다.
버튼의 이름(=label)은 버튼의 디자인만큼 중요합니다. 잘못된 이름을 사용하면 사용자가 혼란스러워하고 시간 낭비와 실수가 발생할 수 있습니다.
좋은 버튼 이름은 사용자로 하여금 행동을 취하게 합니다. 동사(ex_ ~하기) 등을 사용하는 것이 가장 좋으며 실제 수행하는 작업에 해당하는 이름으로 사용하세요. — 사용자에게 “장바구니에 추가하시겠습니까?” 또는 “주문 확인하시겠습니까?”라고 묻는 것과 같은 것이 좋습니다.
예, 아니오 또는 제출하기와 같이 일반적인 이름은 사용하지 마세요.
확인/취소 또는 취소/확인, 두 버튼의 위치는 어느 쪽이든 상관없습니다.
둘 다 선택지일 뿐이며, 디자이너들은 자신의 선호도에 따라 몇 시간 동안 논쟁할 수 있습니다.
[확인/취소]
이는 순서에 맞춰 자연스럽게 읽힙니다. 사용자가 “확인”이 선택될 가능성이 가장 높다는 것을 알고 있다면 시간을 절약하는 데 도움이 됩니다.
Microsoft Windows가 이러한 방식 사용[취소/확인]
“확인”을 마지막에 위치시키면 흐름이 개선됩니다. 이전, 다음과 같이 왼쪽에서 오른쪽으로 흘러가는 측면에서 보면 취소 다음에 “확인”이 오는 것이 적절하게 여겨집니다. 또한 사용자가 최종 “확인” 버튼을 누르기 전에 모든 옵션을 검토함으로써 실수와 급한 결정을 막을 수 있습니다.
Apple은 이러한 방식 사용
(덧붙임) 이 부분에 대해 좀 더 자세히 읽기 쉽게 다뤄진 좋은 글이 있어 추가로 링크합니다.
확인/취소 또는 취소/확인에서 어느 쪽이든 각자 합리적인 근거를 가지고 있으며, 무엇을 선택하던 사용성에 문제가 발생하지는 않을 것입니다. 저는 개인적으로 대부분 대화상자(Dialog)와 같은 동작을 선택하는 UI에 “확인” 버튼을 마지막에 넣었습니다. (주로 mac을 사용하기 때문에 그럴 수도…)
짜증나는 비활성화(Disabled) 버튼
모두가 이런 상황을 한 번쯤 겪어봤을 겁니다. 화면에 몇 초 또는 몇 분 동안 Disabled 된 상태로 머물러져 있는 이유가 무엇이고, 이를 다시 활성화하려면 어떻게 해야 하는지를 모른 채 헤매는 경우를요.
비활성화(Disabled)는 현재의 구성요소를 동작할 수 없다는 것을 알리기 위해 사용되지만, 나중에 활성화될 수 있음을 나타냅니다. 비활성화(Disabled) 버튼은 기본 위치에서 버튼이 없다가 나중에 생겨나면 사용자에게 혼란을 줄 수 있기 때문에 사용합니다.
가능하면 비활성화(Disabled) 버튼을 사용하지 않는 것이 좋습니다. 항상 활성화된 상태로 두는 것이 좋으며, 사용자가 필요한 정보를 입력하지 않은 경우 비어있는 필드(fields)를 강조하거나 알림을 표시하세요.
다음 글에서는 어떤 구성요소를 알아보고 싶나요? 의견 주세요.
추신: 가능한 많은 독자들이 제 콘텐츠를 사용할 수 있도록 하고 싶습니다. 내용이 유용했다면 Patreon https://www.patreon.com/tarasbakusevych에서 저를 응원해 주세요.
번역 후기
처음 가볍게 훑어봤을 때 브랜드의 기원(자기의 가축을 표시하기 위해 불도장을 만든 것부터 시작)과 같은 내용이 있을 것 같아 번역을 시작했는데 뒤로 갈수록 그러한 내용이 아니라서 실망했으나 좋은 내용이 많아 번역하면서 도움이 되었습니다.
사내에서 디자인시스템을 부트스트랩에 커스터마이징해서 반영하는 작업을 하고 있는데 버튼의 상태(status)가 명확하게 나와 있어 지금은 아니지만, 나중에 UI를 할 때 도움이 될 것 같습니다.
접근성 부분은 읽으면서 디자이너도 중요하지만, 개발자분들도 많은 관심이 있었으면 하는 아쉬움이 있었습니다. 개발할 때 모든 요소를 div로만 처리하는데 최소한 role을 지정하고 해당 목적에 맞는 HTML Eletement를 사용했으면 좋겠는데 요구하기가 쉽지 않습니다.
나머지는 알고 있지만 쉽게 적용하지 못하는 부분인데 오랜만에 다시 한번 상기시킬 수 있어 좋은 시간이었던 것 같습니다.
번역이 어려워(사실 제가 직접 해석하는 것 보다 번역기가 99%) 제멋대로 해석한 부분이 몇부분 있는데 잘못된 부분을 알려주시면 반영하겠습니다.