[chrome dev summit 2021] Payment and address form best practices

 

결제 과정 결제 정보 입력 폼에 대한 베스트 예제 결제 양식에 대한 모범 사례를 구현하는 방법

HTML

• 올바른 형식의 HTML은 좋은 결제 환경의 핵심 추가적인 예시는 이 링크(sign in form best practices)를 통해 확인
• built-in element를 사용할 것을 권장
• 적극 활용 시, 크로스플랫폼, 인앱 브라우저, 접근성을 향상시킬 수 있음

<form>

• (form을 사용하지 않고 div 등으로 래핑하는 것과 같이) 자바스크립트로만 양식 제출을 할 수 있게 처리하게 하는 유혹을 느낄 수 있음
• form은 코드에 결함이 생기거나 일부의 자바스크립트를 비활성화한(왜?) 유저들에게도 실행되게 할 수 있음

<input>

• type 속성: 모바일 유저들에게 적절한 키보드를 제공함
  • 기본 내장 브라우저 유효성 검사를 자바스크립트 없이 활성화함
  • 주의할 점은 신용카드 번호나 pin 번호와 같은 데이터에는 type에 number를 할당하지 말 것. 넘버 타입은 숫자를 증감시키는 화살표가 같이 나타남. 대신 inputmode="numeric" 으로 지정할 수 있음
• autocomplete 속성: 사용자들이 같은 정보를 다시 입력하지 않아도 됨
  • 자동 완성 기능의 보안이 더 높아졌음
  • 사용 가능한 autocomplete 속성 (링크)
    

    address-line-1
    address-line-2
    address-line-3
    bday
    bday-day
    bday-month
    bday-year
    cc-name
    cc-number
    cc-exp
    country
    country-name
    current-password
    email
    family-name
    given-name
    language
    mobile
    name
    new-password
    nickname
    organization
    postal-code
    tel
    url

  •  
• required 속성
  • form을 제출할 때, 사용자들이 입력되지 않은 데이터에 집중하게 할 수 있음

<label>

• input 태그를 레이블링할 때에 레이블을 사용
• input 태그의 id에 해당하는 값을 label의 for 속성에 입력

  • <label for="email">Email</label> 
    <input id="email" ...>

• 하나의 input과 하나의 label이 매칭되게 할 것
• 모바일 환경에서 label 영역을 클릭하면 input 태그로 autofocus 될 수 있음
• 스크린 리더는 label에서 해당하는 텍스트를 읽음
• placeholders는 도움이 될 수는 있지만 라벨이 없다면 입력 중 잊기 쉬우므로 사용하지 않을 것을 권장

<button>

• 접근 가능한 동작을 제공
• 버튼의 비활성화를 고려해야 함
• 입력이 완료된 상황에서는 버튼은 항상 활성화되어야 함

UX

• 모든 유저들에게 각각의 피로도 예산(fatigue budget)이 있다고 가정
  • 이를 너무 많이 소비하면 사용자는 떠나므로 마찰을 줄이고 집중할 것
• 대부분의 사이트는 모바일 환경에서 큰 트래픽을 얻지만 데스크탑 환경에서 더 많은 전환이 일어남
  • 우리의 목표
    • 모바일에서는 손실된 전환율을 최소화
    • 데스크탑에서는 전환율을 극대화
  • 목표를 위해 확인할 것
    1. 너무 많은 정보를 입력 받지 않을 것
    2. 구매하기 전에 계정을 만들게 할 것
       • (예시) 비회원 구매를 할 경우, 사실 회원가입에 필요한 대부분의 정보를 가지고 있을 경우가 많음 → 결제 후 해당 정보로 회원가입 유도 → 회원가입 후 구매한 내역과 계정이 연결됨
         • 더 자세한 정보는 링크
    3. 각 스텝에서 수행해야 하는 작업을 명확하게 보여줌으로서 결제 과정을 덜 복잡하게 만들 수 있음 → 구매를 위한 진행상황이 프로그레스바 등으로 명확하게 표현될 것
    4. 사용자가 구매 외의 다른 행동을 할 수 있는 유혹할 만한 것들을 제거할 것
       • 볼 필요가 없는 데이터는 숨기기
       • 결제의 마지막 단계에서는 요약된 정보만 보여줄 것
         • 수량은 간단하게 조작 가능할 것

피로도 줄이기

• 특히 모바일 장치에서 양식 작성의 피로도를 줄일 것

1. Ask for as little as possible
2. Avoid privacy 'data debt'
   • 이름을 입력할 때에는 하나의 인풋만 입력하게 할 것
     • autocomplete="name" 에서 name은 풀네임을 의미하기 때문에 성과 이름을 (굳이) 따로 받는다면 그에 해당하는 다른 속성을 이용할 것
   • 이름, 주소 등에 유효성 검사를 넣을 순 있지만 덜 제한적이어야 함
     • 라틴 문자가 있는지에 대한 검증만 할 것을 권장
     • 주소에는 여러 인풋 형식이 있을 수 있음
     • 두개의 주소 라인을 사용할 것을 권장
     • 나라마다 주소 형식이 다르고 나라마다 우편번호를 부르는 명칭이 다름을 유의할 것

결제 form

• autocomplete
  • 날짜의 경우 일반적인 경험 규칙으로 사용하지 말 것
  • 카드번호의 경우 네자리마다 끊어서 박스를 만들지 말 것

    • <input autocomplete="cc-number" id="" inputmode="numeric" pattern="[\\d ]{10, 30}" ...>

  • 아래와 같이 작성하여 자바스크립트 없이도 유효성 검사를 할 수 있음
  • 더 강력한 유효성 검사가 필요하다면 자바스크립트를 사용해야 함
  • codelab에서 더 많은 정보를 얻을 수 있음
  • 클라이언트에서는 백엔드에서도 처리하는지 확인해야 함
  • SMS OPT FORM 더 보기

사용성 및 성능 측정

• analytics + RUM(real user measurements)
  • 결제 페이지를 로드하는 시간
  • 결제를 완료하는 데에 걸리는 시간
• page analytics
  • 페이지 조회수
  • 이탈률
• interaction analytics
  • 전환 퍼널
  • checkout payments 과정에서 이탈하는 유저 확인
  • 유저가 수행하는 이벤트
• website performance
  • → 자세히 보기
• 위 세가지 analytics가 서버 로그와 전환율 데이터, AB테스트까지 만나게 된다면 최고
  • 할인 코드가 수익을 증가시킬지
  • 디자인의 변경이 전환율을 향상시킬지
  • 등등의 다음으로 수행할 수 있는 우선순위를 정할 수 있음

• 더 많은 정보를 얻고 싶다면?

https://web.dev/payment-and-address-form-best-practices/