brunch

You can make anything
by writing

C.S.Lewis

by 김자유 Jul 03. 2019

UI  폼 디자인의 모든 것 (2부)

해외 디자인 아티클 번역 뉴스레터 '디독' 구독링크: http://bit.ly/2FNQNpv


목차


<엔지니어링(Engineering)>

30. 가능한 한 자동 완성으로 필드를 채운다.

31. 모바일에서 폼 필드에 맞는 키보드를 사용한다.

32. 모바일에서는 암호 입력을 자동으로 숨기지 않는다.

33. 다음 필드로 자동으로 넘어가도록 하지 않는다.

34. 폼을 단축하기 위해 적절한 곳에 조건부 논리를 사용한다.

35. 마우스 없이도 폼을 사용할 수 있도록 설정한다.

36. 긴 드롭다운 대신 예측 검색을 사용한다.

37. 사용자가 필드의 크기를 적절하게 조정할 수 있도록 설정한다.

38. 폼 데이터를 자동저장(Auto-save)한다.

39. 엔터키로 폼을 제출하는 것은 의도적이어야 한다.

40. 복사 붙여넣기 허용한다.

41. 데스크톱에서 단일화면 폼(Single-screen form)을 모바일의 다중화면 폼(Multi-screen form)으로 분할하는 것을 고려한다.

42. 모든 주요 브라우저와 기기에서 폼을 테스트하고 최적화한다.

43. 모바일에서는 날짜 선택기 및 기타 특수 입력에 기본 OS기능을 사용한다.


<검사(Validation)>

45. 가능한 한 다양한 입력 형식을 허용한다.

46. 필수가 아니라면 자동 로그인 방지 시스템(Captcha)을 지양한다.

47. 인라인 검사를 통해 사용자 진행 상황을 확인한다.

48. 오류 메시지가 사용자가 오류를 수정하는 데 도움이 되는지 확인한다.

49. 유효성 검사가 완료될 때까지 ‘다음’ 또는 ‘제출’ 버튼을 비활성화한다.



엔지니어링(Engineering)



30. 가능한 한 자동 완성으로 필드를 채운다.


폼 필드를 자동으로 채우는데는 두 가지 방법이 있다. 시스템이 가지고 있는 정보를 사용하는 방법과, 사용자의 브라우저가 가지고 있는 정보를 사용하는 것이다. 대부분의 최신 브라우저에는 "브라우저 자동 채우기(browser auto-fill)”가 있다. 당신의 폼에 이것을 비활성화할 이유가 없다면, 활성화하여 사용자의 작업량을 최소화해라.


31. 모바일에서 폼 필드에 맞는 키보드를 사용한다.


모바일의 모든 폼 필드에서 표준 쿼티(QWERTY) 키보드를 사용하는 것은 가장 흔한 실수이다. 만약 숫자 입력이 필요하다면 숫자 키보드로 표시해야 한다. 개발자에게 디자인을 전달할 때 이를 지정해주는 게 필요하며, 결과적으로 사용자는 이 기능에 고마워할 것이다.



32. 모바일에서는 암호 입력을 자동으로 숨기지 않는다.


모바일에서 다른 사람들이 사용자의 비밀번호 입력을 엿볼 위험은 매우 낮다. 화면이 작기도 하고, 다른 사람들이 화면을 쉽게 볼 수 없는 방식으로 휴대폰을 사용하기 때문이다. 사용자에게 토글로 암호 입력을 숨길 수 있는 옵션을 제공해도 좋지만, 자동으로 숨기지 않도록 고려해라. 비밀번호를 자동으로 숨기지 않으면, 사용자가 자신이 입력한 내용을 볼 수 있고, 폼을 제출하기 전에 한 번 더 검증할 수 있다는 장점이 있다.



33. 다음 필드로 자동으로 넘어가도록 하지 않는다.


이를 밑받침하는 여러 가지 주장을 살펴보면,


대부분의 사람은 이 기능에 익숙하지 않다.

사용자가 컨트롤하는 게 힘들어진다.

입력한 데이터를 시각적으로 확인하고 수정하기가 더 어려워진다.

탭(Tab) 키를 사용하는 사용자가 실수로 필드를 건너뛸 수 있다.

이전 필드를 수동으로 다시 이동해야 하므로 짜증이 날 수 있다.


위 근거를 바탕으로, 사용자가 현재 폼 필드 끝에 도달하면 커서를 그 위치에 그대로 두는게 좋다.


34. 폼을 단축하기 위해 적절한 곳에 조건부 논리를 사용한다.


사용자의 응답에 따라서 여러 가지 입력란을 채우지 않아도 될 수 있다. 이 때는 사용자가 실제로 완료해야 하는 입력란만 표시해라. 이러한 방법을 “단계적 진행(progressive disclosure)”라고 한다.



35. 마우스 없이도 폼을 사용할 수 있도록 설정한다.


사용자는 탭과 엔터키만 사용하여 폼을 작성하고 제출할 수 있어야한다. 폼에 마우스 클릭이 필요한 경우 사이트나 앱을 일부 사용자가 사용할 수 없게된다.



36. 긴 드롭다운 대신 예측 검색을 사용한다.


거주 국가같이 매우 많은 개별 옵션이 있는 필드는 드롭다운 메뉴보다 예측 검색을 사용하는 게 좋다. 이 패턴을 통해 사용자가 자신의 국가를 입력하면, 시스템은 사용자가 선택할 수 있는 완료 옵션을 제안해준다.



37. 사용자가 필드의 크기를 적절하게 조정할 수 있도록 설정한다.


특히 자유 형식의 텍스트 필드에서는, 사용자마다 입력한 텍스트의 양이 다를 수 있으므로 사용자가 직접 필드를 확장 할 수 있도록하는게 좋다. 가능한 한 이 기능을 활성화해라. 



38. 폼 데이터를 자동저장(Auto-save)한다.


경험을 통해 생각해보면, 오랜시간 폼을 작성하고 제출한 후에 와이파이가 떨어졌음을 깨닫고 모든 작업을 잃을 때보다 짜증나는 일은 없다. 가능한 한 시스템은 입력된 데이터(서버 쪽이든 클라이언트 쪽이든)를 캐싱하고 사용자가 중단한 부분을 찾도록 도와야 한다.



39. 엔터키로 폼을 제출하는 것은 의도적이어야 한다.


이메일 등록과 같은 간단한 폼에서는 사용자가 입력 필드를 선택한 상태에서도 엔터키로 폼을 제출하는 데에 아무런 문제가 없다. 그러나 복잡한 폼이나 대출 신청처럼 "제출”하는 행동이 가장 중요한 경우, 실수가 발생할 우려가 있다면 이 기능을 제한하는 게 좋다.


엔터키를 누르기 전에 키보드 사용자 탭에서 "제출" 버튼을 눌러 폼을 제출하거나, "대출 신청서를 제출하시겠습니까?"라는 확인 대화 상자를 넣을 수도 있다.


긴 텍스트 입력 시 사용자가 엔터키를 눌러 줄 바꿈을 할 수 있으므로, 실수로 폼을 제출하지 않도록 특별히 주의를 기울여라.


40. 복사 붙여넣기 허용한다.


사람들은 주소처럼 많은 정보를 붙여넣기하고 싶을 수 있다. 특수한 경우, 사용자는 암호 관리 도구에서 암호를 붙여넣을 수도 있다. 암호 필드에서 이 작업을 허용하는지 확인해라.


41. 데스크톱에서 단일화면 폼(Single-screen form)을 모바일의 다중화면 폼(Multi-screen form)으로 분할하는 것을 고려한다.


서로 다른 기기(Device)는 서로 다른 시각적 및 사용 편의성을 제공한다. 데스크톱에서 단일화면으로 작동하는 양식은 모바일보다 더 많아 보일 수 있다. 이 경우 비좁거나 긴 단일화면 레이아웃을 고집하는 대신, 모바일의 다중화면 폼으로 전환하는 것이 좋다.


42. 모든 주요 브라우저와 기기에서 폼을 테스트하고 최적화한다.


폼은 브라우저가 HTML 폼 요소를 처리하도록 프로그래밍이 된 방식에 크게 달라진다. 즉, 다른 기기와 플랫폼에서 예기치 않은 문제가 발생할 수 있다. 가장 흔하게 사용하는 브라우저로 시작하되, 특이한 경우들도 간과해선 안 된다. 스탯카운터(StatCounter)*에 따르면 2018년 10월 현재 6% 이상의 사람들이 Internet Explorer를 사용하고 있다. 더불어 모바일에서 데이터 입력은 데스크톱과는 매우 다른 경험이므로, 두 기기에서 테스트 및 최적화에 충분한 시간과 자원을 투자해야한다.


43. 모바일에서는 날짜 선택기 및 기타 특수 입력에 기본 OS기능을 사용한다.


구글의 안드로이드와 애플의 iOS는 모두 날짜 선택기(Date picker)와 같은 특정 종류의 데이터 입력을 위한 인터페이스를 내장하고 있다. 가능한 한, 직접한 프로그래밍보다는 이러한 기본 요소를 사용해라. 사용자들은 기본 옵션에 친숙해지고, 더 효과적으로 수행할 가능성이 커진다. 

 * 스탯 카운터(Statcounter): 1999년에 설립 된 웹 트래픽 분석 도구이다. 스탯카운터의 통계는 순방문자가 아닌 조회수를 토대로 하는 통계로써, 매달 300만 개의 사이트에서 150억 건 이상의 사이트 방문 횟수를 통계의 기반으로 한다. -위키백과



검사(Validation)

44. 유효성 제출을 위해 인라인 유효성 검사(Inline validation)를 사용한다.


사용자가 양식을 제출하거나 다음 화면으로 이동하려고 할 때 유효성 검사를 한꺼번에 하기보다, 데이터 입력시에 바로 유효성을 확인하는 게 좋다. 사용자가 폼을 제출할 때 오류를 표시하면, 오류를 수정하기보다 아예 포기할 가능성이 높다. 즉, 사용자가 정보를 생각하는 동안 오류를 해결하는 것이 더 효율적일 수 있다.


시스템은 사용자가 오류를 정확히 식별할 수 있도록 적절한 위치에서 정보를 제공해야 한다. 가령 “숫자를 충분히 입력하세요”와 “무엇을 의미합니까?"처럼 말이다.


45. 가능한 한 다양한 입력 형식을 허용한다.


가능하다면 시스템은 사용자 대신 형식 오류를 수정해야 한다. 예를 들어, 신용 카드 번호에 대시를 넣었다면 시스템은 오류를 반환하지 않고 단순히 코드를 제거하여 해결해야 한다.


46. 필수가 아니라면 자동 로그인 방지 시스템(Captcha)을 지양한다.


자동 로그인 방지 시스템(보안 문자)은 거친 이미지 안의 숫자를 입력하는 작은 상자이다. 이것은 흐름 완료에 큰 영향을 미치므로, 전환이 중요한 곳에는 자동 로그인 방지 시스템을 사용하면 안 된다.


47. 인라인 검사를 통해 사용자 진행 상황을 확인한다.


인라인 유효성 검사를 사용하여 사용자가 진행 중인지 확인할 수 있다. 이는 올바른 입력 후에 필드 옆에 나타나는 “알림(Tick)” 아이콘으로 확인할 수 있다.



48. 오류 메시지가 사용자가 오류를 수정하는 데 도움이 되는지 확인한다.


오류 메시지는 따로 설명이 필요 없다고 가정하지 않는다. 신용카드 번호 옆에 표시된 "부적합한 데이터(invalid data)"는 사용자가 오류를 식별하는 데 도움이 되지 않을 수 있다. 대신, "숫자를 놓쳤다.” 와 같은 문구를 사용해라. 


49. 유효성 검사가 완료될 때까지 ‘다음’ 또는 ‘제출’ 버튼을 비활성화한다.


사용자에게 데이터 입력내용이 제출 준비가 되었음을 시각적으로 명확히 보여줄 수 있다.


읽어 주셔서 감사합니다!

폼 설계에 대한 디자인 팁이 도움이 되셨다면, 다음 2부에는 전환율최적화, 시각디자인 팁 및 포괄적인 폼을 디자인하는 방법에 대해 이야기해보겠습니다.


저자 : trydesignlab

원문 링크: https://trydesignlab.com/blog/ui-design-best-practices-form-design-ux-part-1/

*무단 전재 및 재배포 금지(링크 공유 가능)


해외 디자인 아티클 번역 뉴스레터 '디독' 구독링크: http://bit.ly/2FNQNpv


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