플레이스홀더를 라벨 대신 쓴 가입 폼 하나가 완료율을 통째로 갉아먹고 있었습니다. 저도 직접 겪은 일입니다. 라벨 원칙 하나를 바꿨더니 완료율이 5%p 올랐고, 그때부터 인풋 컴포넌트 설계를 완전히 다시 공부했습니다. Figma에서 인풋을 제대로 만드는 방법, 한국 환경에서 빠지는 함정까지 정리했습니다.
라벨과 플레이스홀더, 이 둘을 혼용하면 생기는 문제
가입 폼 외주를 진행하던 중, 디자인 검수 단계에서 한 가지 이상한 피드백이 반복됐습니다. 사용자들이 입력을 시작한 뒤에 "내가 지금 뭘 쓰는 거지?"라고 헷갈린다는 것이었습니다. 원인을 파악해 보니 플레이스홀더(placeholder)가 라벨 역할을 대신하고 있었습니다. 플레이스홀더란 인풋 필드 안에 표시되는 예시 텍스트로, 사용자가 타이핑을 시작하는 순간 사라집니다. 즉, 입력 도중에는 이 필드가 무엇을 요구하는지 알 방법이 없어집니다.
UX 설계 원칙상 라벨(label)은 항상 인풋 위에 고정되거나, 입력 시작 시 위로 떠오르는 플로팅(floating) 형태로 유지되어야 합니다. 여기서 플로팅 라벨이란 입력 전에는 필드 안에 위치해 있다가 포커스가 잡히면 필드 상단으로 이동하는 인터랙션 패턴을 말합니다. 이 원칙 하나만 적용했는데 폼 완료율이 5%p 올랐습니다. 수치가 크지 않아 보일 수 있지만, 가입 퍼널에서 5%p는 꽤 의미 있는 차이입니다.
닐슨 노먼 그룹의 UX 리서치에 따르면 라벨이 사라지는 폼은 사용자가 입력 중 실수를 발견했을 때 컨텍스트를 잃어 오류 수정 속도가 느려진다고 보고된 바 있습니다(출처: Nielsen Norman Group). 제가 직접 써봤는데, 이 내용이 과장이 아닙니다. 특히 주소나 카드 정보처럼 필드가 많은 폼일수록 라벨 소실 문제가 치명적으로 작용합니다.
Figma에서 인풋 컴포넌트를 구조적으로 만드는 법
Figma에서 인풋을 제대로 만들려면 Auto Layout부터 시작해야 합니다. Auto Layout이란 Figma의 레이아웃 시스템으로, 내부 요소들의 간격과 패딩을 유연하게 제어할 수 있어 반응형 컴포넌트 제작에 핵심적인 기능입니다. 단순히 사각형을 그려서 텍스트를 올려놓는 방식은 나중에 컴포넌트를 수정할 때 반드시 후회하게 됩니다. 저도 초반에는 그렇게 만들었다가 인풋 크기 하나 바꾸는 데 30분을 날린 적이 있습니다.
인풋 컴포넌트의 기본 구조는 다음 요소들로 이루어집니다.
- 라벨(label): 필드 위에 고정되어 무엇을 입력해야 하는지 설명
- 플레이스홀더(placeholder): 입력 예시 또는 힌트 텍스트, 입력 시 사라짐
- 옵셔널 라벨(optional label): 필수 여부를 사용자에게 안내
- 헬퍼 텍스트(helper text): 입력 안내 또는 에러 메시지 표시 영역
- 캐릭터 카운터(character counter): 글자 수 제한이 있는 필드에 표시
- 아이콘(icon): 비밀번호 표시/숨기기, 드롭다운 화살표 등 기능성 아이콘
이 구조를 Figma에서 구현할 때는 Boolean Property를 활용합니다. Boolean Property란 특정 레이어를 켜거나 끌 수 있는 컴포넌트 속성으로, show icon, show helper text, show label 같은 토글을 하나의 컴포넌트 안에 넣어 상황에 따라 유연하게 조합할 수 있게 해줍니다. 이 기능 덕분에 라벨 없는 인풋, 아이콘 없는 인풋, 헬퍼 텍스트 있는 인풋을 별도 컴포넌트로 만들 필요 없이 하나로 관리할 수 있습니다.
텍스트 레이어에는 Vertical Trim을 꼭 설정해야 합니다. Vertical Trim이란 텍스트 레이어 상하의 불필요한 여백을 제거하는 설정으로, cap height to baseline으로 지정하면 텍스트가 실제 높이에 정확히 맞게 배치됩니다. 이걸 빠뜨리면 패딩 계산이 틀어져 정렬이 어긋나 보이는 경우가 생깁니다.
Variants로 상태(State)를 모두 커버해야 하는 이유
인풋 컴포넌트에서 가장 많이 빠지는 부분이 Variants 설계입니다. Variants란 하나의 컴포넌트가 가질 수 있는 다양한 상태를 하나의 컴포넌트 셋으로 묶어 관리하는 Figma 기능입니다. 신입 디자이너들이 가입 폼을 디자인할 때 default 상태 하나만 만들고 끝내는 경우를 자주 봤는데, 개발 단계에서 에러 상태, 비활성 상태를 설계 없이 구현해달라는 요청이 들어오면 난감해집니다.
제가 정리한 인풋 Variants는 최소 6가지 상태를 포함합니다.
- Default: 아무 입력도 없는 기본 상태
- Focus: 필드가 활성화된 상태, 보통 파란색 테두리로 구분
- Text(filled in progress): 입력 중인 상태, 커서 표시
- Filled: 입력이 완료된 상태
- Error: 유효성 검사 실패 상태, 빨간색 테두리와 에러 메시지
- Disabled: 입력 불가 상태, 회색 처리
이 6가지를 모두 만들어 두면, 실제 폼 디자인 시 어떤 상황에서도 가져다 쓸 수 있습니다. 저는 여기에 텍스트·이메일·전화·비밀번호·숫자·검색·텍스트에리어·페어드(쌍으로 묶인 인풋) 8종을 Variants로 정리해 컴포넌트 라이브러리를 구성했습니다. 라벨 위치(top·floating·left), 헬퍼 텍스트 위치(below·right), 에러 메시지 위치(below·right)를 3축 옵션으로 설정하니 조합 가능한 경우의 수가 대폭 늘었고, 실제 외주 5건에서 이 라이브러리를 재사용하고 있습니다.
한국 환경에서 반드시 챙겨야 할 IME와 모바일 키보드 처리
일반적으로 글로벌 UX 가이드에서 인풋 검증 로직은 onChange 이벤트 기준으로 작성됩니다. 그런데 한국어 IME(Input Method Editor) 환경에서는 이 로직이 깨집니다. IME란 한글, 중국어, 일본어처럼 조합형 문자를 입력하기 위한 입력기로, 자모 단위로 composing 이벤트가 발생하기 때문에 onChange가 완성된 글자가 아닌 중간 상태에서도 반복 호출됩니다.
예를 들어 "가나다"를 입력하는 도중 "ㄱ", "가", "가ㄴ", "가나" 순서로 onChange가 연속 발생합니다. 검증 로직이 이 중간 상태를 처리하지 못하면 에러 메시지가 잘못된 타이밍에 노출되거나, 실시간 검색 기능이 의도치 않게 자모 단위로 API를 호출하는 문제가 생깁니다. 저는 이 문제를 해결하기 위해 compositionstart, compositionend 이벤트를 감지해 조합 중 여부를 추적하는 useImeAware React 훅을 만들었고, 현재 외주 5건에서 재사용하고 있습니다.
모바일 키보드 타입 매핑도 한국 프로젝트에서 놓치기 쉬운 부분입니다. HTML의 inputMode 속성은 모바일 키보드 종류를 제어하는 속성으로, 전화번호 필드에 inputMode="tel"을 지정하면 숫자 키패드가 바로 열리고, 이메일 필드에 inputMode="email"을 지정하면 @ 키가 포함된 키보드가 노출됩니다. autocomplete 속성은 브라우저가 자동완성 데이터를 어떤 카테고리로 채울지 지정하는 속성입니다. 이 두 가지를 체계적으로 정리한 매핑 가이드를 컴포넌트 라이브러리에 함께 문서화해 두면 개발 핸드오프 시 커뮤니케이션 비용이 크게 줄어듭니다.
W3C의 웹 접근성 가이드라인(WCAG 2.1)에서도 인풋 필드의 autocomplete 속성 명시를 접근성 기준 항목(1.3.5 Identify Input Purpose)으로 포함하고 있습니다(출처: W3C). 단순한 편의 기능이 아니라 접근성 기준에서도 요구하는 사항이라는 점에서, 한국 서비스를 만들 때도 반드시 챙겨야 하는 부분입니다.
인풋 하나를 제대로 설계하는 것이 귀찮게 느껴질 수 있습니다. 하지만 폼 완료율에 직접 영향을 주는 컴포넌트가 인풋이고, 설계가 부실할수록 개발 단계에서 돌아오는 피드백이 많아집니다. Figma에서 Variants와 Boolean Property로 인풋 라이브러리를 한 번 제대로 구성해 두면, 이후 프로젝트에서는 가져다 쓰는 시간만 남습니다. 한국 프로젝트라면 IME 처리와 모바일 키보드 매핑까지 한 묶음으로 문서화해 두는 것을 권장합니다.