brunch

You can make anything
by writing

C.S.Lewis

by UX 컨설턴트 전민수 Dec 26. 2016

모바일 폼 사용성 원칙 7가지

UX 디자인 배우기 #93

Today UX 아티클


babich.biz에 올라온 Nick Babich의 글 Mobile FormUsability 원저자의 허락을 받아 번역한 글입니다.


여러분이 만든 앱이나 사이트를 사용하는 모바일 유저는 특정한 목표를 가지고 있습니다. 보통 유저와 그의 목표 사이에 있는 것이 ‘폼(form)’입니다. 사실, 폼은 보통 목표 완수 여정의 마지막 단계라고 여겨집니다. 유저가 폼을 아무런 혼동 없이 최대한 빨리 마무리할 수 있는 것이 중요한 것도 이런 이유 때문입니다.


다음 7가지 룰을 따라 빠르고 쉽게 완성할 수 있는 폼을 만들어보세요.


룰#1. 폼은 유저가 데이터를 입력하는 방식에 맞춰야 한다


키보드와 같은 인터페이스 요소가 입력란을 가로막지 않는지 확인해야 합니다. 유저가 한 칸에 입력을 완료하면, 다음 칸이 보이도록 폼이 자동으로 위로 살짝 올려주는 것이 좋습니다.

(좌) 다음 입력란이 키보드 뒤에 숨겨져 있다

(우) 입력이 끝나면 폼이 미리 위로 올려져 있다. Image credit: Google


룰#2. 입력란 개수와 유저가 들여야 하는 노력을 최소화한다


폼이 더 길거나 복잡해 보일수록, 유저가 빈칸을 채우기 시작할 확률은 줄어듭니다. 특히 작은 스크린의 경우 더 그렇습니다. 입력란의 개수를 최소화하면 폼을 덜 부담스럽게 느끼게 됩니다. 특히 유저에게 많은 정보를 요청할 때는 더욱 그렇습니다.


폼은 최대한 짧고 간단하게 만든다. Image credit: lukew


하지만 입력란 개수를 최소화하는 것으로는 충분하지 않습니다. 유저가 데이터 입력에 들이는 노력에도 관심을 기울여야 합니다. 타이핑은 인터랙션 비용이 높습니다. 실제 키보드를 사용한다 해도 오류가 발생하기도 쉽고 시간 소모가 큽니다. (터치 스크린에서는 더 심하죠.)


그러므로 타이핑을 최소화해서 유저가 오류를 범하는 일을 방지하려고 노력해보세요.  다음과 같은 방법을 쓸 수 있습니다.


스마트 디폴트(Smart Defaults)


스마트 디폴트는 유저가 폼을 더 빠르고 정확하게 완성하게 해줄 수 있습니다. 예를 들어 위치 데이터를 활용해 유저의 국가를 미리 선택 주는 것입니다.


위치 자동 감지는 ‘호텔 찾기’ 폼에서 유저의 시간을 절약해줄 수 있습니다.


관련도가 높지만 상호 배타적인 선택지로 만든 라디오 그룹(radio groups)


리스트로 보여주는 옵션에서 유저가 선택해야 할 때는 가로형 태그 리스트를 사용하는 것을 고려해보세요. 스크린 상의 공간을 더 잘 활용할 수 있게 해줄 겁니다.



최저가/최고가 또는 예산 범위 설정에 쓰는 슬라이더


가격이나 예산이 들어가는 입력란에서는 슬라이더를 사용하는 것을 고려해보세요. 최저/최고 범위를 설정할 때 슬라이더 컨트롤을 움직이면 되도록 만드는 것이죠. 슬라이더는 가로로 스와이프하기 쉽고 유저가 자신의 상황에 맞춰 설정할 수 있다는 간단한 시각적 단서를 제공해주기도 합니다. 하지만 슬라이더를 조절할 때 숫자가 (두꺼운 손가락에) 가려지면 안 된다는 점을 염두해야 합니다.


에어비앤비에서 가격 범위 설정에 사용하는 슬라이더


룰#3. 폼 레이블은 폼 입력란 위에 배치하거나 플로팅 레이블(floating labels)로 만든다


레이블은 입력란의 목적을 유저에게 전달해주며, 레이블의 텍스트를 깔끔하게 만드는 것은 UI를 좀 더 접근성 있게 만드는 주된 방법 중 하나입니다.


인라인 레이블(inline labels)을 절대 사용하면 안 되는 이유


인라인 레이블(혹은 필드 레이블로 사용된 플레이스 홀더 텍스트)은 칸 안에 배치된 텍스트로 유저가 입력을 시작하면 사라져 버립니다.


인라인 레이블. Image credit: snapwi


인라인 레이블은 보이게도 좋고 스크린 공간을 절약해주긴 하지만, 이러한 이점이 엄청난 사용성 결점보다 지나치게 중요하게 여겨지고 있습니다. 가장 큰 문제는 맥락이 손실(loss of context)된다는 점입니다.

유저가 텍스트 박스를 한 번 클릭하고 나면, 레이블이 사라져 버려서 유저가 입력해야 할 내용을 제대로 입력했는지 재확인할 수가 없습니다.



플레이스홀더 텍스트는 비주얼 레이블을 제대로 대체해주지 못합니다. Imagecredit: Amazon


또 다른 문제는 유저가 텍스트 박스에 무언가 쓰여 있다고 알고 이미 입력했다고 생각해서 무시해 버릴 수도 있다는 점입니다.


왼쪽 정렬된 레이블이 모바일에서 안 좋은 이유


왼쪽으로 정렬된 레이블의 가장 큰 문제는 모바일 폰 화면의 크기 및 비율과 관련이 있습니다. 입력란 앞에 왼쪽 정렬된 레이블이 사용되면, 안 그래도 좁은 스크린에서 입력란의 너비가 줄어들게 됩니다. 유저가 입력하는 전체 내용을 보여주기에 너비가 충분하지 않게 된다는 사용성 이슈를 야기할 수 있습니다. 입력한 데이터를 볼 수 없게 되는 것은 유저에게 문제를 야기합니다. 폼을 제출해서 확인하기 전까지는 입력 오류를 찾아내기 어렵기 때문입니다. 이는 결국 오류가 있는 폼을 더 많이 제출하게 되는 결과로 이어집니다.



입력한 데이터가 완전히 보이지 않으면 오류를 잡아내기 어렵습니다. Imagecredit: baymard


레이블은 입력란 위 혹은 플로팅 레이블로 만든다.


폼 레이블은 입력란 위에 배치하여 유저가 입력해야 하는 내용이 무엇이고 왜 입력해야 하는지 쉽게 볼 수 있게 해줘야 합니다. 모바일에서 레이블을 입력란 위에 배치하는 것의 장점은 유저가 입력한 내용을 가로로 충분히 보여줄 수 있는 공간을 확보할 수 있다는 것입니다. (16px 정도의 괜찮은 폰트 사이즈로도 가능합니다) 추가적인 장점은 명확하게 쓸 수 있는 확률이 훨씬 더 높아지고, 레이블의 길이를 한 두 단어로 제한하지 않고 충분히 의미를 담아 만들 수 있다는 것입니다.


레이블을 입력란 위에 배치하는 것의 단점은 세로 공간을 더 많이 차지한다는 점입니다. 즉 유저가 스크롤을 더 많이 해야 한다는 거죠. 하지만 이건 그다지 큰 문제가 아닙니다. 요즘엔 스크롤링을 완전히 자연스럽게 느끼니까요.


아니면, 플로팅 레이블(floating lable)을 쓸 수도 있습니다. 유저가 제대로 입력을 하고 있는지 확인할 수 있도록 말이죠. 플레이스 홀더 텍스트를 디폴트로 보여주되 입력란을 한 번 탭 해서 플레이스 홀더 텍스트가 사라지면 레이블을 상단으로 이동시켜주는 겁니다.



Image credit: Matt D. Smith


룰#4. 폼에 입력한 내용은 실시간으로 검토한다


이상적인 세상에서는 유저가 반드시 필요한 정보로만 폼을 채우고 성공적으로 일을 끝낼 것입니다. 하지만 현실에서 유저는 종종 실수를 합니다. 하지만 유저는 제출을 한 후에 오류를 범했다는 것을 깨닫고 입력한 프로세스를 다시 따라가는 것을 싫어합니다. 유저가 제공한 데이터가 올바른지 아닌지에 대한 정보를 주는 적절한 타이밍은 유저가 해당 정보를 입력한 직후입니다. 실시간으로 검토를 해줘서 유저가 데이터를 수정해야 하는지 아닌지 즉시 알려주는 것이죠. 이러한 접근법은 유저가 완료 버튼을 누르고 오류를 보기 전에 오류를 빠르게 수정할 수 있게 해줍니다.



(좌) 제출할 때까지 폼에 입력한 내용이 올바르지 않은지 확인할 수 없고, 제공된 오류 메시지가 대처를 어떻게 해야 하는지 제대로 전달하지 못하고 있습니다

(우) 행동으로 옮길 수 있는 오류 메시지는 맥락에 맞게, 데이터를 입력하면 실시간으로 알려주고 있습니다.

Image credit: Google


만일 특정한 형식으로 칸에 입력을 해야 한다면, 적용된 룰을 추가적인 예시 없이 미리 알려줍니다.


Image credit: Material Design


아래 사례는 인라인 검토(Inlinevalidation) 역시 어려움을 줄여줄 수 있습니다. 아래 사례는 잠재적 문제를 고칠 수 있는 솔루션을 제공해주는 인라인 검토의 좋은 사례입니다.


Image credit: lukew


룰#5. 요구하는 입력 내용과 키보드를 매치한다.


유저는 입력해야 하는 텍스트에 맞는 키보드를 제공하는 앱을 좋아합니다. 예를 들어, 유저가 신용카드 번호를 입력해야 할 때는 다이얼패드만 보여주어 문자가 아닌 숫자만 입력할 수 있게 제한해주는 겁니다.



(좌) 숫자를 입력하려면 유저가 직접 키보드를 숫자 키보드로 바꿔야 합니다.

(우) 숫자 입력을 요구하는 칸에 맞춰 적절한 숫자 키보드가 자동으로 제공됩니다. Image credit: Google


특정 태스크에서만 이렇게 하지 말고, 앱 전체에 걸쳐 이 룰이 일관되게 적용되었는지 확인해 봐야 합니다.


 룰#6. 도움이 되는 정보를 맥락에 맞게 제공한다.


때로는 유저가 폼을 쉽게 채워나갈 수 있도록 맥락과 관련이 있는 정보를 준비해 둬야 합니다. 하지만 정말 필요한 곳에서만 텍스트 도움말을 보여줘야 합니다.

날짜를 스케줄링할 때, 유저는 요일을 확인할 수 있도록 달력을 보여주면 좋아합니다. 앱에서 나가 스마트폰에 있는 달력 앱을 확인해보지 않아도 되게 해주는 것이죠. 이는 유저가 다른 태스크로 인해 방해를 받는다는 리스크도 줄여줍니다.



(좌) 유저에게 적절한 날짜 선택 기능이나 도움말 텍스트가 제공되지 않고 있습니다.
(우) 데이터 입력에 쓸 수 있는 달력 위젯이나 간결한 설명 등 도움이 되는 기능이 제공되고 있습니다. Image credits: Google


사람들은 입력란 데이터에 대한 보안이나 프라이버시에 대해 걱정할 수도 있습니다. 제삼자에게 해당 데이터가 공유되지 않을 것임을 알려주어 안심시켜야 합니다.
Image credits: Google

경험법칙에 따르면 설명은 100자가 넘지 않는 것이 좋다고 합니다.


룰#7. 유연한 형식을 활용한다.


유저가 매우 정확하게 정보를 입력해야 하는 태스크도 있을 것입니다. 하지만 사람들에게 특정 포맷으로 그런 정보를 제공하도록 강요하는 것은 좋은 사용성 원칙에 어긋날 수 있습니다. 폼에서 유저에게 숫자로 된 정보를 요청하는 경우(예: 전화번호), 유저가 입력하는 다양한 입력 형식을 인식할 수 있도록 스크린을 디자인하세요. 그리고 실수를 방지하기 위해  (기계가 아니라 사람이) 훑어보기 쉽게 정보를 보여주세요.


(좌) 데이터 입력 형식 이미리 정해져 있음(예: 전화번호 입력에 칸 세 개 사용)

(우) 여러 정보 입력 형식을 유연하게 허락한 폼 입력란


결론


유저가 폼 채우기를 머뭇거릴 수 있기 때문에, 여러분은 이 프로세스를 최대한 쉽게 만들어야 합니다. 이 글에서 설명한 모든 변화는 폼 사용성을 굉장히 올려줄 것입니다.

고맙습니다!




전민수 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




브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari