😍구독링크 복사해서 공유하기😍
http://bit.ly/2FNQNpv

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. 유효성 검사가 완료될 때까지 ‘다음’ 또는 ‘제출’ 버튼을 비활성화한다

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

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

• 대부분의 사람은 이 기능에 익숙하지 않다
• 사용자가 컨트롤하는 게 힘들어진다
• 입력한 데이터를 시각적으로 확인하고 수정하기가 더 어려워진다
• 탭(Tab) 키를 사용하는 사용자가 실수로 필드를 건너뛸 수 있다
• 이전 필드를 수동으로 다시 이동해야 하므로 짜증이 날 수 있다

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

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억 건 이상의 사이트 방문 횟수를 통계의 기반으로 한다. -위키백과

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

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

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

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

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

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

49. 유효성 검사가 완료될 때까지 ‘다음’ 또는 ‘제출’ 버튼을 비활성화한다
사용자에게 데이터 입력내용이 제출 준비가 되었음을 시각적으로 명확히 보여줄 수 있다.

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

아래의 뉴스 레터에 가입하시면 다음 글이 게시 될 때 까지 이메일을 받아보실 수 있습니다!

1~29번은 지난 메일을 참고해주세요