UX 및 HTML5: 사용자가 모바일 양식을 작성할 수 있도록 돕자(1부)

양식은 사용자가 웹사이트(및 모바일 앱)와 갖게 되는 가장 기본적인 기본 상호작용 중 하나입니다. 그들은 사람들을 함께 연결하고 의사 소통을 할 수 있습니다. 그들은 기사에 대한 논평을 하게 하고 그들이 작성한 내용에 얼마나 강하게 동의하지 않는지 저자에게 설명합니다. 그들은 사람들이 "하나"를 만나기 위해 데이트 앱에서 직접 채팅할 수 있도록 합니다. 포럼, 제품 주문, 온라인 커뮤니티, 계정 생성 또는 온라인 결제를 위해 양식은 사용자의 온라인 생활에서 큰 부분을 차지합니다.

2018년, 전 세계적으로 데스크톱 사용자보다 모바일 사용자가 더 많습니다 . 그러나 우리는 여전히 이러한 사용자를 웹의 2급 시민으로 취급합니다. 모든 사람은 항상 사용자 경험에 대해 글을 쓰고 이야기합니다. 그래서, 왜, 왜, 왜 그렇게 많은 웹사이트와 제품이 여전히 잘못되고 있습니다. 전 세계 절반의 모바일 사용자 경험이 손상된 이유는 무엇입니까? 여전히 고통스러운 이유는 무엇입니까? 오늘날 모바일 형식으로 항공편을 예약하고 계정을 등록하는 것이 여전히 어려운 이유는 무엇입니까? 사용자는 더 나은 것을 기대합니다!

추천 자료 : 부유한 서부 웹이 아닌 월드 와이드 웹

이것은 두 개의 기사 시리즈 중 첫 번째 부분입니다. 이 문서에서는 스캔 가능성 및 가독성을 포함하여 모바일 양식을 개선하기 위한 몇 가지 필수 모범 사례를 요약합니다. 레이블 및 입력 배치, 크기 및 최적화에 대해 안내해 드리겠습니다. 상호 작용 비용을 줄이기 위해 올바른 양식 요소를 선택하는 방법을 살펴보겠습니다. 마지막으로 모바일 양식의 오류를 방지하고 처리하는 방법을 배웁니다.

2부에서는 특정 모바일 기능과 HTML5 양식 요소에 대해 자세히 살펴보고 기존 양식 요소를 넘어 독특하고 즐거운 웹 애플리케이션과 웹사이트를 만들기 위해 노력할 것입니다.

참고 : 이 기사의 대부분의 코드 개선 사항은 웹과 관련되어 있지만(Swift 또는 Java를 모르기 때문에) 사용성 모범 사례는 모바일 애플리케이션에 적용 됩니다.

양식 디자인 101: 가독성과 가독성 우선

"형식은 레이블 및 입력 필드로 표시되는 컴퓨터에 데이터를 저장하기 위한 구조의 이름, 값, 쌍입니다." 이것은 회의에서 Luke Wroblewski가 직접 인용한 것입니다. 그와 마찬가지로, 나는 대부분의 사용성 문제가 데이터베이스의 구조를 사용자에게 제공하려는 이러한 경향에서 비롯된다고 믿습니다.

강력한 정보 아키텍처

더 나은 양식을 작성하려면 먼저 데이터베이스 구조에서 몇 단계를 벗어나야 합니다. 사용자가 양식을 채우는 방법을 이해하려고 노력하십시오. 여기에서 양식에 대한 사용성 테스트 및 사용자 연구를 수행하는 것이 편리합니다. 사용자 멘탈 모델은 이를 도와줄 수 있는 UX 개념입니다. Nielsen Norman Group은 이를 "사용자가 현재 시스템에 대해 믿는 것"으로 설명합니다. 테스터에게 큰 소리로 생각하고 양식을 채우는 방법을 알려달라고 요청하십시오. 그들은 어떤 단계를 기대합니까? 무엇이 먼저입니까? 다음은 무엇입니까? 이렇게 하면 보다 사용자 친화적인 방식으로 양식을 구성하는 방법에 대한 더 나은 아이디어를 얻을 수 있습니다.

함께 속한 필드를 시각적으로 그룹화하면 사용자가 양식을 채우는 데 도움이 됩니다. 코드에서 fieldset 태그를 사용하여 프로그래밍 방식으로 그룹화합니다. 또한 스크린 리더가 계층 구조를 이해하는 데 도움이 됩니다.

형식이 긴 경우 기본적으로 모든 것을 노출하지 마십시오 . 당신이 표시하는 것에 대해 현명하십시오. 분기를 현명하게 사용하여 사람들이 필요로 하는 필드만 표시합니다. 예를 들어, 결제 양식에서 모든 배송 옵션에 대한 모든 세부 필드를 표시하지 마십시오. 이것은 사용자를 압도할 것입니다. 올바른 배송 옵션을 선택하는 데 도움이 되는 충분한 정보를 표시합니다. 그런 다음 해당 선택과 관련된 세부 정보 및 필드만 표시합니다.

사용자의 주의 시간은 시간이 지날수록 짧아집니다. 양식 끝에 선택 사항을 요청하세요 . 예를 들어, 귀하의 양식이 고객 만족도 설문조사인 경우 마지막에 인구통계학적 정보를 요청하십시오. 더 나은 방법은 가능하면 자동으로 채우는 것입니다. 필요한 것만 사용자에게 물어보세요.

마지막으로 현지화를 미리 계획하십시오. 양식이 번역되면 어떻게 됩니까? 독일인에게 무슨 일이 일어날까요? 당신의 디자인은 여전히 ​​유효합니까?

라벨 배치 및 입력 최적화

단일 열 레이아웃이 가장 잘 작동합니다.

공간이 부족하기 때문에 모바일 화면에 레이블과 필드를 배치하기 위한 끝없는 옵션이 제공되지 않습니다.

• 단일 열 레이아웃으로 필드를 표시합니다. 모바일에는 여러 열을 위한 공간이 없습니다. 다중 열 형식은 어쨌든 데스크탑에서 좋은 아이디어가 아닙니다.
• 세로 모드에서는 사용자가 입력할 때 필드에 무엇이 있는지 볼 수 있도록 필드 상단에 레이블 을 배치하는 것이 좋습니다.

• 가로 모드에서는 화면 높이가 줄어듭니다. 왼쪽에 레이블을, 오른쪽에 입력 을 넣을 수 있습니다. 그러나 작동하는지 테스트하십시오.

레이블 배치에 대한 자세한 내용은 Baymard Institute의 "모바일 양식 사용성: 필드 위에 레이블 배치"를 참조하십시오.

레이블은 명확하고 가시적이어야 하며 컨텍스트 없이 작동해야 합니다.

필드에 초점이 맞춰지면 키보드가 열리고 화면 영역의 최소 1/3을 차지한다는 것을 기억하십시오. 작은 모바일 화면에서 사용자는 양식을 채우기 위해 스크롤해야 합니다. 즉, 양식을 채우는 동안 컨텍스트의 일부가 손실됩니다. 그에 따라 계획:

• 레이블은 문맥 없이 읽고 이해할 수 있는 명확하고 눈에 띄는 텍스트여야 합니다. 사용자는 컨텍스트가 손실되더라도 각 레이블과 필드 쌍을 별도의 작업으로 완료할 수 있어야 합니다.

• 가능한 한 전문 용어, 약어 및 산업별 언어를 사용하지 마십시오.
• 일관성을 유지하십시오. 레이블에서 "customer"를 한 번 사용했다면 그 단어를 고수하십시오. 사용자에게 혼란을 줄 수 있으므로 나중에 "클라이언트"를 사용하지 마십시오.
• 글꼴 크기는 충분히 커야 합니다. 가능한 한 빨리 실제 장치에서 양식을 테스트하고 그에 따라 크기를 조정하십시오.
• 일부 사용자는 대문자로 된 텍스트를 읽기 어려울 수 있습니다. 레이블에 전체 대문자 텍스트를 사용하지 않는 것이 좋습니다.
• 라벨 사본은 짧고 스캔 가능해야 합니다. 필드에 설명이 필요한 경우 레이블에 넣지 마십시오. 대신 필드 설명을 사용하십시오.

입력 크기 모범 사례

가능한 경우 입력 요소의 크기는 예상되는 콘텐츠의 크기와 일치해야 합니다 . 이렇게 하면 사용자가 양식을 빠르게 채우고 예상되는 내용을 이해하는 데 도움이 됩니다.

모바일에서 입력 분할을 피하기 위해 마스크 사용하기

형식화를 위해 입력을 분할하지 마십시오 . 사용자가 필드 사이를 탐색하기 위해 키보드를 사용할 수 없는 모바일에서 특히 성가시다. 양식을 작성하기 위해 다음 필드로 이동하려면 추가 탭이 필요합니다. "하지만 해당 필드에 필요한 수의 문자가 입력되면 자동으로 다음 필드에 포커스를 둡니다."라고 생각할 수도 있습니다. 효과가 있을 수 있습니다. 그러나 사용자가 예측할 수 없는 UI를 제어하게 됩니다. 또한 자동으로 다음 필드로 보내어 마지막 필드에서 수정해야 하는 경우 고통스러울 것입니다. 마지막으로 분할 입력에서 필수 항목을 추측하는 것은 더 복잡합니다. 따라서 "하지만 어쩌지" 게임을 중단하고 단순히 입력을 분할하지 말자.

이해합니다. 여전히 사용자의 데이터를 작은 조각으로 형식화하여 필드를 채우는 데 도움이 되기를 원합니다. 그리고 당신은 그것에 대해 완벽하게 맞습니다. 그렇게 하려면 마스크를 사용할 수 있습니다. 입력을 분할하는 대신 사용자가 입력을 채우는 데 시각적으로 도움이 되도록 마스크를 맨 위에 놓기만 하면 됩니다. 다음은 사용자가 신용 카드 필드를 채우는 데 도움이 되는 마스크의 모양에 대한 비디오 예입니다.

마스크는 사용자를 올바른 형식으로 안내하여 오류를 방지하는 데 도움이 됩니다. 점차적으로 드러내지 말고 형식을 직접 보여주십시오. 또한 마스크에 가짜 값을 넣지 마십시오 . 사용자는 이미 채워져 있다고 생각할 수 있습니다. 그래서 데모에서 숫자를 작은 "X"로 교체했습니다. 입력 유형에 가장 적합한 것을 찾으십시오.

마지막으로 일부 데이터는 국가마다 다를 수 있으며 때로는 형식도 변경됩니다(예: 전화번호). 그에 따라 계획하십시오.

효율적인 필드 설명

효율적인 필드 설명을 표시하면 원활한 양식 경험과 고통스러운 양식 경험 사이의 차이를 만들 수 있습니다.

설명은 무엇에 사용할 수 있습니까?

설명은 여러 면에서 사용자에게 도움이 될 수 있습니다. 다음은 몇 가지 예입니다.

• 정확히 무엇을 요구하고 있습니까?
  

  데이터베이스와 관련된 이유가 무엇이든 일부 배송 회사에서는 "주소 1" 및 "주소 2" 필드를 요청합니다. 이것은 사용자에게 매우 혼란스러운 일이지만 여기에서 선택의 여지가 없을 수도 있습니다. 사용자가 각 필드에 입력해야 하는 내용을 이해하는 데 도움이 되도록 설명 필드를 추가합니다.

  

  약어와 약어도 마찬가지입니다. 나는 당신이 그들을 피해야한다고 말했지만 때로는 할 수 없다는 것을 압니다. 예를 들어 특정 산업에 대한 복잡한 양식을 작업하는 경우 고유한 약어 세트가 있을 수 있습니다. 양식을 작성해야 하는 신규 사용자는 (아직) 해당 약어에 익숙하지 않을 수 있습니다. 어딘가에 설명이 있으면 도움이 될 것입니다.

• 이 정보가 필요한 이유는 무엇입니까?
  사용자가 개인 정보가 필요한 이유 와 개인 정보로 무엇을 할 것인지 이해하지 못하는 경우 개인 정보 제공을 꺼릴 수 있습니다. 그러나 때때로 법적 이유(예: 주류를 판매하는 웹사이트의 생년월일)로 이러한 정보를 요청해야 합니다. 여기에서 필드 설명을 사용하면 사용자가 이러한 종류의 정보가 필요한 이유를 이해하는 데 도움이 됩니다.
  
  

  전자 상거래 웹 사이트에서 배달 담당자가 연락해야 할 경우를 대비하여 사용자의 전화 번호를 요청할 수 있습니다. 이것은 정당한 이유입니다. 따라서 다시 설명을 사용하여 전자 상거래 사용자에게 전화 번호가 필요한 이유를 설명하십시오.

  

“정보는 어디에서 찾을 수 있습니까?”
사용자가 양식을 작성하기 위해 다른 곳에서 특정 정보를 찾아야 하는 경우 해당 정보를 찾을 수 있는 위치를 알려주세요. 나는 사용자가 집을 추적할 수 있는 모바일 앱을 개발했습니다. 사용자는 일련 번호를 사용하여 앱을 모니터링 장치에 페어링해야 했습니다. 장치에서 이 일련 번호를 찾는 것은 그리 쉬운 일이 아닙니다. 약간의 지시가 필요합니다. 우리는 조금 추가 ? 일련 번호 필드 옆에 있는 버튼. 버튼은 사용자가 모니터링 장치에서 일련 번호를 찾을 수 있는 위치를 이해하는 데 도움이 되는 그림과 일부 표시를 보여주는 모달을 엽니다. 전자 상거래 웹 사이트는 프로모션 코드와 동일한 작업을 수행합니다. 사용자에게 코드를 찾을 수 있는 위치를 알려주는 표시기를 제공합니다.



• "정보 형식을 어떻게 지정해야 하나요?"
  일부 필드에는 특정 형식 이 필요합니다. 이 경우 사용자가 서식 규칙을 미리 알 수 있도록 설명을 사용합니다. 다음은 몇 가지 예입니다.
  • 전화번호: 입력란 앞에 국제전화번호(+xx)를 입력해야 하나요?
  • 최대 길이가 있습니까? 모바일 트위터는 이 기능을 잘 활용하고 있습니다.
  • 화폐 금액을 처리할 때 형식이 쉼표(예: 10,000) 또는 공백(예: 10,000)입니까?
  • 날짜 형식은 무엇입니까? 그것이 얼마나 악몽인지 위키피디아에서 확인하도록 하겠다. DD MM YY와 MM DD YY의 차이는 온라인 예약 시 사용자에게 *많은* 문제를 일으킬 수 있습니다.
  이러한 서식 문제의 대부분은 입력 마스크로 해결할 수 있습니다. 우리는 기사의 뒷부분에서 이에 대해 설명할 것입니다(또는 참을성이 없으면 바로 뛰어들 수 있습니다).

  

설명을 표시하는 방법

위의 예에서 필드 설명을 표시하는 몇 가지 방법을 보았습니다. 수행할 작업을 요약하면 다음과 같습니다.

• 인라인 설명은 필드 옆에 직접 표시되고 표시되어야 합니다.
• 무거운 콘텐츠로 더 자세한 설명이 필요한 경우 툴팁이나 모달 을 사용할 수 있습니다. 툴팁은 일반적으로 데스크톱에서는 마우스를 가져가고 모바일에서는 탭할 때 트리거됩니다. 모달도 마찬가지입니다. 예를 들어 사용자가 도움말 아이콘이나 "더 보기" 링크를 탭할 때 엽니다.

자리 표시자에 주의

알겠습니다. 공간을 확보하고 대신 자리 표시자를 사용하기 위해 모바일에서 필드를 제거하고 싶은 유혹이 있습니다. 우리는 모두 그 길을 걸어왔습니다. 하지만 그러지 마세요. HML5 사양은 이에 대해 명확합니다. "placeholder 속성은 사용자의 데이터 입력을 돕기 위한 짧은 힌트(단어 또는 짧은 구문)를 나타냅니다." 이유는 다음과 같습니다.

• 사용자가 입력을 시작하면 자리 표시자가 사라집니다. 그런 다음 사용자는 필드에 입력해야 하는 내용을 기억하기 위해 단기 기억에 의존 해야 합니다. 표시할 수 없는 경우 표시를 보려면 필드를 비워야 합니다.
• 필드에 더 이상 레이블 표시가 없기 때문에 사용자가 제출하기 전에 필드를 다시 확인하기가 어렵습니다 .
• 다시 말하지만 사용자를 도울 레이블이 없기 때문에 필드가 제출되면 오류에서 복구하기 어렵습니다 .

레이블이 있는 자리 표시자를 사용하더라도 여전히 몇 가지 문제가 있을 수 있습니다. 채워진 필드와 자리 표시자가 있는 필드의 차이점을 구분하기 어렵습니다 . 저는 모바일 폼 디자인에 대해 글을 쓰는 UX 디자이너이며 지난 주에도 그 중 한 명에게 속았습니다. 나에게 발생하면 사용자에게 발생합니다. 그 점에 대해 저를 믿으십시오. 마지막으로, 대부분의 자리 표시자에는 밝은 회색 텍스트가 있으므로 대비 문제도 있을 수 있습니다.

이 주제에 대해 더 자세히 알아보려면 "Placeholder Attribute Is Not A Label"이라는 훌륭한 기사가 있으며 Joshua Winn과 FeedbackGuru는 이것이 왜 나쁜 생각인지 자세히 설명합니다. Nielsen Norman Group은 "양식 필드의 자리 표시자는 유해합니다"라는 주제에 대한 글도 썼습니다.

HTML5에서는 자리 표시자가 필수가 아닙니다 . 사용성 관점에서 볼 때 양식의 모든 필드에 자리 표시자가 필요하지는 않습니다. 그러나 Bootstrap 및 기타 프레임워크의 대규모 채택으로 많은 사람들이 구성 요소를 복사하여 붙여넣는 것처럼 보입니다. 이러한 구성 요소에는 자리 표시자가 있으므로 사람들이 코드의 자리 표시자에 무언가를 추가해야 할 의무가 있다고 생각합니까? 양식의 자리 표시자가 "여기에 - 레이블을 입력하세요."와 같이 표시되면 잘못 입력한 것입니다.

그럼에도 불구하고 필드 내부의 레이블 은 필드를 예측할 수 있는 짧은 형식에서 잘 작동할 수 있습니다. 로그인 양식은 이에 대한 좋은 후보입니다. 그러나 이것을 코딩하기 위해 HTML5 자리 표시자를 사용하지 마십시오. 코드에서 실제 레이블을 사용하고 CSS 및 JavaScript로 이동합니다.

Android의 머티리얼 디자인의 성공 이후로 플로팅 라벨이라는 패턴이 등장하기 시작했습니다. 이 레이블은 필드가 채워지지 않을 때 필드 안에 있으므로 모바일에서 세로 공간을 조금 덜 차지합니다. 사용자가 필드와 상호 작용하기 시작하면 레이블이 필드 위로 이동합니다.

이것은 위에서 언급한 "레이블 대신 자리 표시자" 문제를 일으키지 않고 공간을 확보하는 흥미로운 방법처럼 보입니다. 그럼에도 불구하고 사용자가 자리 표시자를 채워진 콘텐츠로 착각하는 문제는 해결되지 않습니다.

성공적인 양식을 위한 상호 작용 비용 절감

작업을 수행하는 사용자의 상호작용 비용(예: 탭, 스와이프 수 등)을 줄이면 원활한 양식 경험을 구축하는 데 도움이 됩니다. 이를 달성하기 위한 다양한 기술이 있습니다. 그 중 몇 가지를 자세히 살펴보겠습니다.

인터넷의 마법 연구에 따르면 필드 수를 줄이십시오.

더 많은 필드는 더 적은 전환을 의미합니다, 그렇죠? "가입 양식을 11개에서 4개 필드로 줄이고 전환율이 160% 증가했습니다"라는 연구를 접했을 것입니다. 클래식입니다. 그리고 그들의 연락 양식을 보면 어느 정도 이해가 됩니다. 왜 사용자는 회사에 연락하기 위해 11개의 필드를 채우고 싶어할까요? 당신을 거의 알지 못하는 사람들에게 그렇게 큰 헌신을 요구할 수는 없잖아요?

유용한 정보만 요청하는 것으로 시작하십시오. 계정을 만드는 데 사람의 성별이 필요한 이유는 무엇입니까? 가입 양식이 온라인 서비스용인 경우 주소에 대해 두 줄이 있는 이유는 무엇입니까?

필요한 정보만 요청하세요. 그런 다음 상황에 맞는 정보를 요청하세요. 전자 상거래 웹사이트가 있는 경우 사용자는 등록할 때보다 결제 프로세스의 배송 섹션에서 주소를 제공하는 경향이 더 높을 수 있습니다. 모바일에서 전자 상거래 등록 양식을 훨씬 더 쉽게 작성할 수 있습니다!

또한 인터넷에서 찾은 모든 통계와 연구를 맹목적으로 신뢰하지 마십시오. 11-fields-to-4 연구를 기억하십니까? 더 최근의 또 다른 연구에 따르면 필드를 9에서 6으로 줄이면 전환이 14% 감소했습니다. 충격적이죠? 왜요? 글쎄, 그들은 가장 매력적인 필드를 제거했습니다. 간단히 말해서, 그들은 9개의 필드로 돌아가 가장 중요한 필드를 맨 위에 놓았고 짜잔, 전환율이 19.21% 증가했습니다.

결론은 이러한 연구가 흥미롭긴 하지만 해당 웹사이트는 귀하의 웹사이트가 아니라는 것입니다. 인터넷에서 찾은 첫 번째 연구를 맹목적으로 믿지 마십시오.

그래서, 당신은 무엇을 할 수 있습니까? 테스트. 테스트. 그리고 테스트!

• 사용자 테스트를 수행하여 모바일 양식이 완성되는 데 걸리는 시간을 확인하십시오.
• 탈락을 측정합니다.
• 특정 필드의 문제를 측정합니다.
• 특정 필드와 관련된 불만을 측정합니다. 사용자는 해당 정보를 얼마나 기꺼이 제공합니까? 얼마나 개인적인 정보입니까?

터치 상호 작용 최적화

터치 친화적인 컨트롤 만들기

필드가 너무 작거나 도달하기 어려운 경우 사용자는 오류를 범하고 목표를 달성하기 위해 추가 상호 작용이 필요합니다. 피트의 법칙을 기억하시나요? 모바일 디자인에도 적용할 수 있습니다. 터치 대상 크기를 늘려 레이블, 필드 및 양식 컨트롤을 탭하기 쉽게 만듭니다. 웹상의 라벨의 경우 패딩을 조금 더 추가하면 터치 가능한 영역이 늘어날 수 있습니다. 탭을 놓칠 수 없도록 요소 사이에 여백을 추가해야 하는 경우도 있습니다.

또한 및 ID 값을 쌍 for 구성하여 레이블을 구성 요소와 연결하는 것을 잊지 마십시오. 이렇게 하면 사용자가 레이블 탭을 놓친 경우 해당 필드에 계속 포커스가 있게 됩니다.

Steven Hoober는 터치 영역에 대한 몇 가지 사용자 연구를 수행했습니다. "터치용 디자인"에서 요약을 찾을 수 있습니다. 그가 발견한 것을 바탕으로 그는 작은 플라스틱 눈금자 도구인 모바일 터치 템플릿을 만들었습니다. 이 도구를 사용하면 터치 영역이 모바일 양식과 더 일반적으로 모바일 디자인에 충분히 큰지 확인하는 데 도움이 될 수 있습니다.

터치를 위한 디자인에 대해 자세히 알아보려면 다음을 참조하세요.

• "손가락 친화적인 디자인: 이상적인 모바일 터치스크린 타겟 크기"
• "The Thumb Zone: 모바일 사용자를 위한 디자인"

피드백 제공

모바일 사용자는 마우스가 없으므로(농담 아님) 데스크톱 사용자가 버튼을 눌렀을 때 받는 "클릭" 피드백을 받지 못합니다. 모바일 양식 사용자는 요소와 상호 작용할 때 명확한 피드백이 필요합니다.

• 사용자가 상호 작용하는 양식 필드에 대한 포커스 상태를 제공합니다 .
• 사용자가 버튼과 상호작용할 때 시각적 피드백을 제공합니다.

나는 버튼에 대한 머티리얼 디자인의 파급 효과를 그다지 좋아하지 않습니다. 그러나 Android의 애니메이션은 사용자가 버튼과 상호 작용할 때 명확한 피드백을 제공한다는 점을 인정해야 합니다.

다음 및 이전 버튼 순서 존중

마지막으로 모바일 키보드의 다음 및 이전 버튼을 존중합니다. 사용자는 필드를 빠르게 탐색하는 데 사용할 수 있습니다. tabindex 순서는 필드 및 구성 요소의 시각적 순서와 일치해야 합니다.

가능하면 모바일에서 드롭다운을 피하세요.

웹의 드롭다운(HTML 선택 요소)에는 많은 탭과 상호 작용이 필요합니다. 따라서 Luke Wroblewski가 말했듯이 최후의 수단으로 UI가 되어야 합니다. 많은 다른 UI 구성 요소가 많은 상황에서 드롭다운보다 더 잘 작동합니다.

세그먼트 컨트롤과 라디오 버튼 은 2~4개의 옵션이 있는 경우 드롭다운에 대한 좋은 대안입니다. 모든 옵션을 한 화면에 직접 표시할 수 있는데 왜 드롭다운 아래에 옵션을 숨기나요? 라디오 버튼과 마찬가지로 세그먼트 컨트롤은 상호 배타적입니다.

국가 목록 은 구성 요소에 대한 좋은 후보입니다. 100개가 넘는 국가의 드롭다운은 모바일에서 상호작용의 악몽입니다. 아프가니스탄(목록 시작 부분) 또는 짐바브웨(목록 끝 부분)를 찾고 있다면 괜찮습니다. 룩셈부르크를 찾고 있다면 목록의 중간에 도달하기 위해 스크롤하고 문자 M으로 너무 멀리 이동하고 L로 돌아오려고 하는 등의 게임으로 끝납니다.

긴 드롭다운은 예측 텍스트 입력 필드로 대체될 수 있습니다 . 사용자가 L을 입력하기 시작하면 인터페이스에서 9개 국가를 제안합니다. U를 추가하면 — 짜잔! — 룩셈부르크입니다. 2개가 아닌 4개의 상호 작용과 드롭다운을 사용하여 6~7개의 스크롤 상호 작용이 있습니다.

사용자가 날짜를 선택해야 하는 경우 사람들이 종이 양식에서 하는 것처럼 날짜를 일, 월 및 연도 드롭다운으로 분할하는 것을 잊어버리십시오 . 여러 날짜 드롭다운을 날짜 선택기로 바꿉니다 . HTML5 입력 type=date 는 대부분의 경우 작동합니다. 그러나 특히 예약 비즈니스(호텔, 자동차, 항공편)에 종사하는 경우 특별한 요구 사항이 있어서 JavaScript로 자신만의 날짜 선택 도구를 구축해야 할 수도 있습니다.

Klaus Schaefers는 자신의 기사 "Mobile DropDowns Revisited"에서 도착 및 출발 날짜에 날짜 선택기를 사용하여 상호 작용이 60% 빨라진 방법을 설명합니다.

예약 사업에 충실합시다. 사용자가 일정에 여러 여행자를 추가해야 한다고 가정합니다. **드롭다운 * 을 * 스테퍼**로 교체하여 승객 수를 선택할 수 있습니다. 스테퍼는 사용자가 단순히 + 및 - 버튼을 눌러 값을 늘리거나 줄일 수 있는 컨트롤입니다. 6명 미만을 추가해야 하는 경우 더 빠른 경향이 있습니다. 또한 더 직관적입니다. 다음은 Android 네이티브 Airbnb 앱에서 게스트를 선택하고 모바일에 최적화된 Kayak 웹사이트에서 승객을 추가하는 데 사용되는 스테퍼의 예입니다.

드롭다운의 마지막 대안은 목록 보기입니다. 옵션은 예를 들어 라디오 버튼과 같이 특정 하위 보기에 나열됩니다 . 이것은 대부분 Android 설정이 작동하는 방식입니다.

자동 완성으로 똑똑해지기

양식의 상호 작용 비용을 줄이려면 현명해야 합니다. 사용자가 제공한 다른 정보를 기반으로 자동 감지하거나 추측할 수 있는 정보를 요청하지 마십시오. 가능한 한 많이 자동 완성하고 미리 채우세요.

장소 및 주소

사용자가 장소를 검색하거나 주소를 입력해야 하는 경우 자동 완성 기능을 제공하여 도움을 줄 수 있습니다. 입력할 때 API는 나머지 주소를 채웁니다. 이것은 또한 오류를 줄입니다.

다음을 사용할 수 있습니다.

• Google 지역 정보 API
• OpenStreetMap 기반 Algolia Places

프랑스와 다른 많은 국가에서는 지역 코드를 기반으로 도시를 추측할 수 있습니다. 따라서 프랑스 사용자가 지역 코드를 입력하면 자동으로 자동 완성되거나 최소한 도시를 제안할 수 있습니다. 내 조국 룩셈부르크는 작습니다(날 놀리지 마세요). 내 지역 번호는 내 거리에 연결되어 있습니다. 따라서 지역 번호를 입력하면 양식에서 내 거리를 제안할 수도 있습니다.

신용 카드

자동 감지가 쉬운 또 다른 영역은 신용 카드입니다. 사용자에게 어떤 종류의 신용 카드를 가지고 있는지 물어볼 필요가 없습니다. 입력한 초기 숫자를 기반으로 이를 자동으로 감지할 수 있습니다. 작업을 수행할 수 있는 라이브러리도 있습니다.

HTML5 자동 완성 사용(자동 완성)

HTML 자동 완성 속성은 사용자의 이전 입력을 기반으로 필드를 미리 채울 수 있습니다. 이 속성에는 켜짐 및 꺼짐 상태가 있습니다. 일부 똑똑한 사람들은 이 사양을 더 강력하게 만들고 양식 필드의 자동 완성 속성을 확장하기 위한 사양 작업을 시작했습니다. WHATWG에는 흥미로운 목록도 있습니다.

Chrome 및 기타 모바일 브라우저는 이미 신용 카드 및 이름에 대한 확장 값 중 일부를 지원합니다. 이것은 사용자가 다른 웹사이트에서 사용하는 자신의 이름과 신용 카드 데이터로 양식을 미리 채울 수 있음을 의미합니다.

요컨대, 서로 다른 시스템 중에서 선택해야 하는 경우 각각에 필요한 상호 작용 수를 계산하십시오.

실수 발생: 모바일 양식의 오류 처리

더 나은 모바일 양식을 향한 여정의 마지막 단계는 오류와 실수를 처리하는 것입니다. 우리는 사용자의 인지 부하를 완화하기 위해 실수를 줄이려고 노력할 수 있습니다. 또한 양식 디자인이 아무리 훌륭해도 실수가 발생하기 때문에 오류 복구를 도울 수 있습니다.

양식 작성 중 오류 방지

어머니는 “예방이 치료보다 낫다”고 말씀하셨습니다. 양식 디자인에서도 마찬가지입니다. 오류를 방지하면 모바일 양식의 경험이 향상됩니다.

명시적 형식 제한

“당신이 하는 일에 보수적이 되십시오. 당신이 다른 사람들로부터 받아들이는 것에 대해 자유로워지십시오.” 이 견고성 원칙은 양식 필드에도 적용될 수 있습니다. 가능하면 사용자가 어떤 형식으로든 데이터를 입력할 수 있도록 하십시오.

사용자가 필드에 입력할 수 있는 항목을 제한해야 한다고 생각되면 먼저 "이유"를 물어보십시오. 사용자 경험 분야에는 "세 가지 이유"라는 기술이 있습니다. 대답이 "데이터베이스 때문에"라면 아마도 상황을 바꿔야 할 때일 것입니다. 예를 들어 사용자 이름 필드에서 e, a 및 o와 같은 특수 문자를 거부하는 이유는 무엇입니까? 사용자 이름으로 "Stephanie"를 입력하려고 할 때 양식이 얼마나 무례한지 설명하는 기사를 작성했습니다. 나는 여전히 (데이터베이스 이유는 제외하고) 좋은 ​​이유를 알아 내려고 노력하고 있습니다.

사용자에게 특정 형식을 요구하는 합당한 이유가 있는 경우 이를 미리 명시하세요. HTML5 자리 표시자를 사용하여 사용자에게 데이터가 어떻게 표시되어야 하는지에 대한 힌트를 제공할 수 있지만 다시 한 번 주의해야 합니다. 이 기사의 시작 부분에서 설명한 모든 필드 설명 기술 을 사용할 수도 있습니다. 마지막으로, 입력 마스크는 사용자를 올바른 형식으로 안내할 수 있습니다.

필수 필드 표시(및 선택 필드)

사용자가 필수 필드에 대해 알려주기 위해 반쯤 완성된 양식을 제출할 때까지 기다리지 마십시오. 필드가 필수인 경우 사용자는 이에 대해 알아야 합니다 . 필수 필드를 별표( * )와 범례로 표시하는 것이 양식의 표준 패턴이 되었습니다. 좋은 점은 공간을 많이 차지하지 않는다는 것입니다. 문제는 의미론적 가치가 없으므로 코딩이 잘못되거나 양식 상호 작용이 사람들의 습관에 의존하는 경우 접근성 문제가 발생할 수 있다는 것입니다.

대신 "필수"(또는 "필수") 및 "선택 사항" 이라는 단어로 필수 및 선택 필드를 모두 명시적으로 표시 할 수 있습니다. Baymard Institute와 Luke Wroblewski 모두 이에 동의합니다. 이것은 스크롤러를 사용할 때 다른 작업을 진행한 다음 돌아와서 필수 필드가 별표 또는 다른 것으로 표시되었는지 기억하지 못하는 경우와 같이 모바일에서 긴 형식의 모호성을 방지합니다.

결국 이러한 필드를 표시하는 방법에 대한 결정은 필드의 디자인과 길이 및 컨텍스트에 따라 달라집니다. 올바른 결정을 내렸는지 확인하는 가장 좋은 방법은 다시 한 번 양식을 테스트하는 것입니다.

합리적인 기본값

양식에서 기본적으로 선택된 옵션에 주의하십시오 . 이전 직장에 지원할 때 정보 양식이 있었습니다. 결혼 여부는 선택 사항이었습니다. 그들은 드롭다운의 첫 번째 요소인 "divorced"를 기본 필드로 만들었습니다. 그래서 (선택사항이라) 답변을 못 하고 시스템에서 이혼한 것으로 믿게 하거나, 원하지 않더라도 이를 바로잡고 실제 혼인상태를 공개할 수 없었습니다.

또한 성별에 주의하십시오. 다시 말하지만 공개를 원하지 않는 사람들을 위한 옵션이 있습니다. 성별을 묻는 이유를 명확히 하세요. 더 나은 방법은 대명사를 요청하거나 실제로 필요하지 않은 경우 묻지 않는 것입니다. 이 주제에 관심이 있으시면 "성 다양성과 포용성을 위한 양식 디자인"을 추천합니다. And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• 로그인 시
  로그인 양식에서 마스크/비밀번호 마스크 해제 옵션 은 사용자 경험을 크게 향상시킵니다.
  Amazon은 로그인 양식에서 비밀번호를 반복하는 흥미로운 역사를 가지고 있습니다. 비밀번호를 볼 수 없는 버전이 있었습니다. 다음 반복에서는 사용자가 이를 공개할 수 있었습니다. 그러면 기본적으로 비밀번호가 공개되며 숨길 수 있습니다. 2015년의 모습은 이렇습니다.

  

  아마존은 마지막 버전을 테스트했고 60%가 의심했습니다. 따라서 "비밀번호 숨기기"가 선택되지 않은 확인란을 "비밀번호 표시" 확인란으로 대체했습니다. 이렇게 하면 사용자가 입력하는 동안 필드 아래에 더 작은 문자로 암호가 표시됩니다. 이 기사를 작성하는 시점의 모습은 다음과 같습니다.

  

  보시다시피, 항상 개선의 여지가 있습니다.

인라인 검증

사용성 원칙에 익숙하다면 게슈탈트 근접 법칙을 알 수 있습니다. 모바일에서는 사용자가 제출 버튼을 탭한 후 컨텍스트 정보 없이 페이지 상단에 오류 요약이 표시되지 않도록 합니다.

대신 오류 메시지는 오류 자체에 가깝게 위치해야 합니다 .

실시간 검증

또한 사용자가 제출 버튼을 누를 때까지 기다릴 필요가 없습니다. 사용자가 필드를 채우는 동안 필드의 유효성을 검사하고 피드백을 표시 할 수 있습니다.

몇 가지 팁:

• 앞에서 언급했듯이 암호 필드는 각 키 입력에 대한 실시간 유효성 검사 및 피드백의 이점을 얻을 수 있습니다.
• 계정을 생성할 때 실시간으로 사용자 이름을 확인하여 사용 가능한지 확인할 수도 있습니다. 트위터는 그 일을 잘합니다.
• 모든 키 입력을 확인하지 마십시오. 사용자가 입력을 마칠 때까지 기다리십시오. (웹 양식에 JavaScript blur 를 사용하거나 몇 초만 기다리면 비활성을 감지할 수 있습니다.)

참고 : *Mihael Konjevic은 "Inline Validation in Forms: Designing the Experience"에 대한 멋진 기사를 작성했습니다. 그는 " 일찍 보상하고 늦게 처벌 한다"는 개념을 설명합니다.*

" 유효한 상태의 필드에 사용자가 데이터를 입력하고 있다면 데이터 입력 후 유효성 검증을 수행하십시오."

" 잘못된 상태의 필드에 사용자가 데이터를 입력하는 경우 데이터 입력 중에 유효성 검사를 수행하십시오."

색상 문제

나는 나의 현재 생강, 분홍색, 보라색 머리 색깔 때문에 색깔이 중요하다고 말하는 것이 아닙니다. 색상은 양식 디자인에서 정말 중요합니다.

웹에는 깨고 싶지 않은 몇 가지 규칙이 있습니다. 색맹이 아닌 사용자는 빨간색은 오류, 노란색은 경고, 녹색은 거의 항상 확인 또는 성공을 나타냅니다. 이 3가지 색상을 유지하는 것이 가장 좋습니다. 그러나 빨간색은 사람들을 불안하게 만들 수 있습니다. 사용자는 정말 심각한 실수를 저질렀다고 생각할 수 있습니다. 오류 메시지에 주황색 또는 노란색을 사용하면 패닉을 덜 유발할 수 있습니다. 노란색과 주황색의 문제는 색맹 친화적 인 색조를 찾기가 어렵다는 것입니다.

색맹에 대해 말하자면: 색상이 오류 메시지를 전달하는 유일한 방법이 되어서는 안 됩니다 . 접근성 기준입니다.

아래 왼쪽 예에서 오류가 있는 필드는 주황색으로, 수정된 필드는 녹색으로 표시됩니다. 중간에 스크린샷을 찍기 위해 색맹 테스트 도구를 사용했습니다. 기본 회색 테두리와 녹색 테두리를 더 이상 구분할 수 없습니다. 마지막 스크린샷에 일부 아이콘을 추가하면 오류 메시지가 색맹인 사람들에게 전달됩니다.

오류 복구: 사용자 친화적인 오류 메시지 작성

이 시점에서 사용자가 양식을 작성하고 오류를 방지할 수 있도록 최선을 다했습니다. 그러나 때로는 최선의 노력에도 불구하고 실수가 발생합니다. 사용자가 이러한 실수를 복구하는 데 도움이 되는 방법을 알아낼 때입니다.

첫째, 기억하십시오. 시스템 제어권을 가로채지 마십시오. 문제가 심각하지 않은 경우 사용자는 가능한 한 인터페이스의 나머지 부분과 계속 상호 작용할 수 있어야 합니다. 가능할 때마다 사용자를 차단하는 JavaScript 경고 오류 메시지 및 모달을 피하십시오. 또한 양식에 일부 권한이 필요한 경우 사용 흐름에서 요청하십시오. 권한이 부여되지 않은 경우 오류가 아니기 때문에 이를 오류로 간주하지 마십시오. 여기에서 사용하는 사본에 주의하십시오.

당신은 로봇이 아니며 사용자도 아닙니다

로봇은 멋지다, 나도 알아. 그러나 당신은 로봇이 아니며 사용자도 아닙니다. 그러나 너무 많은 오류 메시지가 여전히 제대로 작성되지 않았습니다. 다음은 사람에게 친숙한 오류 메시지에 관한 몇 가지 팁입니다.

• "유형 2393의 오류가 발생했습니다."와 같은 원시 오류 메시지를 표시하지 마십시오. 서버에서 작업을 완료할 수 없습니다." 대신 에 인간의 언어로 무슨 일이 일어났는지, 왜 그런 일이 일어났는지 설명하십시오 .
• "오류가 발생했습니다."와 같은 막다른 오류 메시지를 표시하지 마십시오. 대신 오류에서 복구하는 방법을 제안하십시오 . 실행 가능한 사본을 작성하십시오.
• "지정된 호스트 이름을 가진 서버를 찾을 수 없습니다"와 같은 모호한 오류 메시지를 "다시 시도" 버튼과 함께 표시하지 마십시오. 대신 오류 메시지를 유익하고 일관성 있게 만드 십시오. 로봇처럼 들리지 마십시오.
• 사람들이 메시지의 맥락을 알고 있다고 가정하지 마십시오. 사용자는 기술에 정통한 괴짜가 아닙니다. 대신 기술적인 전문 용어 없이 이 오류에서 복구하는 방법을 일반 언어로 설명하십시오 .

메시지에 사용하는 언어를 조심하십시오

무엇을 쓰든 사람들이 실수에 대해 어리석게 생각하지 않도록 하십시오. 가능 하면 부정적인 단어를 생략 하십시오. 그들은 사람들을 겁주고 더 불안하게 만드는 경향이 있습니다. 대신 예의 바르고 긍정적이며 긍정하는 어조를 사용하십시오.

실수에 대해 사용자를 비난하지 마십시오 . 대신 시스템을 비난하십시오. 시스템은 원한을 품지 않을 것입니다, 약속합니다. 시스템이 작업을 처리할 수 없는 방법으로 사용자의 주의를 전환 하고 솔루션을 찾는 방법을 설명합니다.

작은 트릭은 자신의 메시지를 큰 소리로 읽는 것입니다. 그것이 작동하는지 또는 너무 거칠거나 너무 캐주얼한지 등을 듣는 데 도움이 될 것입니다.

오류 메시지로 창의력을 발휘하고 이미지와 유머를 통합 하여 덜 위협적으로 만들 수도 있습니다. 하지만 이는 브랜드의 정체성과 어조에 따라 달라집니다.

더 나은 오류 메시지를 작성하는 데 도움이 되도록 다음을 읽는 것이 좋습니다.

• “UX Writer가 없는 제품 팀을 위한 6포인트 현미경 검사 목록”
• "오류 메시지의 기술: 일이 잘못될 때를 위한 명확하고 유용한 사본 작성"

양식 제출 시간

사용자가 양식을 작성했으며 더 이상 오류가 없으며 모든 것이 좋아 보입니다. 마지막으로 양식을 제출할 시간입니다!

첫 번째 규칙은 제출 버튼을 가리지 않는 것입니다. 진지하게! 어떤 꼬인 마음이 이 아이디어를 생각해 냈는지 궁금하지만 어떤 형태로든 본 적이 있습니다. 제출 버튼은 모든 필수 필드가 오류 없이 채워진 경우에만 표시됩니다. 사용자가 뭔가 잘못된 것인지, 양식의 버튼이 로드되지 않았는지, 웹사이트가 깨졌는지 등을 궁금해하는 것은 혼란스럽습니다.

필수 필드가 누락되었거나 유효성 검사 오류가 있는 경우 사용자가 제출 버튼을 누르지 못하도록 하려면 submit 입력에서 disabled 된 HTML 속성을 사용하세요. 양식이 유효하고 제출할 준비가 되면 JavaScript를 사용하여 버튼을 다시 활성화해야 합니다.

기본 및 보조 클릭 유도문안이 있는 경우 색상, 크기 및 스타일을 사용하여 계층 구조를 표시합니다 .

확인 버튼이 취소 버튼 앞에 와야 하는지 뒤에 와야 하는지 궁금하다면 저도(그리고 많은 사람들이) 그렇습니다. 기본 앱을 빌드하는 경우 OS 지침을 따르십시오. Android가 네 번째 버전에서 버튼 위치를 변경한 이후로 특히 재미있어졌습니다. 웹에서는 실제 지침이 없기 때문에 더 복잡합니다. OS에 관계없이 모바일에 최적화된 제출 버튼에 대한 몇 가지 일반적인 지침은 다음과 같습니다.

• 행동을 촉구하는 설명적이고 실행 가능한 동사를 제공하십시오.
• 사용자가 탭할 때 시각적 피드백을 제공합니다.
• 두 개의 버튼 이 있는 경우 기본 작업을 눈에 띄게 만드세요 .
• 매우 구체적인 백오피스 기업 형태로 작업하지 않는 한(이 경우 모바일에 최적화하는 데 많은 어려움을 겪을 수 있음) 재설정 버튼을 피하세요 . 사용자는 제출 버튼과 혼동할 수 있으며 실수로 모든 데이터를 잃게 됩니다.

결론

이 첫 번째 부분에서는 양식을 다음 단계로 끌어올리고 사용자가 양식을 작성하는 데 도움이 되는 몇 가지 간단한 기술에 대해 논의했습니다. 이러한 일반 지침 및 모바일 권장사항 중 일부는 100% 작동하지 않을 수 있습니다. 바로 이것이 문제입니다. 모범 사례와 함께. 따라서 항상 실제 사용자와 실제 장치에서 양식을 테스트하고 사용자의 특정 요구 사항과 경험에 맞게 지침을 조정하십시오.

또한 실제 장치에서 회귀 및 자동화된 기능 테스트를 수행합니다. Chrome의 모바일 에뮬레이터는 터치에 최적화된 양식을 테스트하기에 충분하지 않습니다. 나는 모바일에서 작동하지 않는 검색 양식으로 전자 상거래 웹 사이트를 시작했기 때문에 이것을 말합니다. 에뮬레이터를 사용하여 자동화된 테스트만 했습니다. 여기 무슨 일이 있었는지입니다. 검색 양식이 검색 아이콘 아래에 숨겨졌습니다. 버튼을 탭하면 검색 필드가 있는 상자가 열립니다. 마우스 호버를 터치 이벤트로 에뮬레이트하여 작동했습니다. 우리는 버튼을 두드리는 것을 테스트했고, 그것은 상자를 열었습니다. 아무도 검색을 시도하지 않았습니다. 따라서 사용자가 검색 필드와 상호 작용하려고 하자마자 검색 필드가 사라진 것을 아무도(클라이언트도 포함하지 않음) 보지 못했습니다. 무슨 일이에요? 입력 요소가 포커스를 받으면 버튼이 호버 상태를 잃어 필드가 있는 상자를 닫았습니다. 입력이 초점을 잃지 않았기 때문에 자동화된 테스트는 이것을 포착할 수 없었습니다. 그래서 모바일에서 검색 기능이 없는 전자상거래 웹사이트를 출시했습니다. 슈퍼 경험이 아닙니다.

이 시리즈의 두 번째 파트에서는 ​​더 발전된 모바일 전용 기술을 볼 것입니다. 멋진 HTML5 기능을 사용하여 필드 형식을 지정하는 방법과 모바일 기능을 사용하여 모바일 사용자 경험을 한 차원 높이는 방법을 살펴보겠습니다.