폼을 정성껏 만들어놨는데, 오히려 그게 문제였다는 걸 알고 계셨습니까? 저는 이커머스 결제 외주를 하면서 처음에는 "입력 필드가 많을수록 정보를 더 많이 얻으니까 좋다"고 생각했습니다. 그런데 직접 써봤는데, 길고 단조로운 폼은 사용자를 이탈시킬 뿐이었습니다. 폼이 필터 역할을 해야 한다는 사실을 그때서야 제대로 이해했습니다.
조건 논리 폼이 필요한 이유
프리랜서로 일하다 보면 문의 폼에 연락처를 남긴 사람과 30분짜리 통화를 하고 나서야 "예산이 50만 원이에요" 라는 말을 듣는 경우가 생깁니다. 혹은 "아직 옵션 탐색 중이라 6개월 후에 결정할 것 같아요"라는 답변을 받기도 합니다. 이 상황이 반복되면 일주일에 10시간 넘는 시간이 실제로 계약으로 이어지지 않을 상담에 사라지는 셈입니다.
여기서 조건 논리(Conditional Logic)란, 사용자가 선택한 답변에 따라 다음에 보여줄 질문이나 페이지가 달라지는 분기 처리 방식을 말합니다. 예를 들어 "새 웹사이트 제작"을 선택한 사람에게는 브랜딩 보유 여부를 묻고, "기존 사이트 리디자인"을 선택한 사람에게는 현재 URL을 입력받는 식입니다. 불필요한 질문을 건너뛰고 관련 있는 정보만 수집할 수 있어서, 응답자 입장에서는 훨씬 가볍게 느껴집니다.
일반적으로 폼 완성률은 단순 길이보다 구조와 흐름이 더 크게 영향을 미친다고 알려져 있습니다. 제가 직접 써봤는데, 6단계 결제 폼을 4단계로 줄이고 회원/비회원 분기와 해외/국내 배송 분기를 추가한 결과 결제 완료율이 58%에서 71%로 올랐습니다. 단순히 줄이는 게 아니라, 각 사용자에게 맞는 경로를 만드는 것이 핵심이었습니다.
Tally로 멀티스텝 폼 설계하기
Framer의 네이티브 폼으로도 기본적인 입력 필드 구성은 가능합니다. 그런데 제가 직접 써봤는데, 멀티스텝 폼으로 전환하는 과정에서 기능이 깨지는 경우가 생겼습니다. 무엇보다 조건 논리를 네이티브 폼에서는 구현할 수 없다는 점이 가장 큰 한계였습니다.
Tally는 Notion과 비슷한 블록 기반 인터페이스를 갖춘 폼 빌더입니다. 새 페이지(New Page) 블록을 추가할 때마다 자동으로 멀티스텝 폼이 구성되며, 여기서 멀티스텝 폼이란 하나의 긴 입력 화면 대신 여러 단계로 나눠 질문을 제시하는 방식을 뜻합니다. 응답자는 "다음" 버튼을 누를 때마다 다음 단계로 진입하기 때문에 심리적 부담이 줄어듭니다.
Tally에서 조건 논리를 설정하는 방법은 다음과 같습니다.
- 분기를 적용할 질문 아래에 "조건부 논리(Conditional Logic)" 블록을 추가합니다.
- 특정 답변이 선택되었을 때 "페이지 이동(Jump to Page)" 액션을 지정합니다.
- 예산이 기준 이하일 경우에는 "프로젝트 최소 금액 안내 페이지"로 이동시켜 미적합 리드를 자동으로 걸러냅니다.
- 예산이 기준 이상이면 "프로젝트 상세 질문 페이지"로 넘어가 본격적인 정보를 수집합니다.
이 흐름대로 폼을 구성하면, 통화를 시작하기 전에 이미 클라이언트의 예산·일정·목적을 파악한 상태에서 미팅에 들어갈 수 있습니다. 제 경험상 이건 시간 절약이 아니라 대화의 질 자체를 바꿉니다.
UX 리서치 분야에서도 사용자 여정(User Journey) 최적화의 핵심으로 단계 수 축소와 맥락 기반 분기가 꼽힙니다. 닐슨 노먼 그룹의 연구에 따르면 폼의 불필요한 필드를 줄이면 완성률이 평균 20% 이상 개선되는 것으로 보고됩니다(출처: Nielsen Norman Group).
AI로 질문 설계하고 Framer에 임베드하기
폼을 만들기 전에 저는 AI에게 프롬프트를 던집니다. 내용은 대략 이렇습니다. "나는 프리랜서 웹 디자이너인데, 미적합 리드와의 통화를 줄이고 싶다. 예산·일정·목적을 걸러내는 클라이언트 인테이크 폼(Client Intake Form)에 어떤 필드가 필요한지 설계해줘." 여기서 인테이크 폼이란 프로젝트를 시작하기 전 클라이언트의 기본 정보와 요구사항을 수집하는 사전 질문지를 의미합니다.
AI가 제안해주는 항목은 대부분 기본에 충실합니다. 비즈니스 정보, 프로젝트 목표, 필요 페이지 수, 브랜딩 보유 여부, 예산 범위, 마감 일정, 유입 경로 등입니다. 솔직히 이건 예상 밖이었습니다. AI가 제안한 구조가 제가 수개월 외주를 하면서 시행착오 끝에 도달한 구조와 거의 일치했거든요. 질문 설계에 쓰는 시간을 확 줄일 수 있다는 게 실질적인 이득입니다.
Tally에서 폼을 완성하면 Framer에 임베드하는 방법은 간단합니다. Tally의 공유 링크를 복사한 뒤, Framer 내 Tally 플러그인에 붙여넣으면 폼이 그대로 삽입됩니다. 임베드(Embed)란 외부 서비스의 콘텐츠를 현재 페이지 안에서 끊김 없이 표시하는 방식으로, 방문자는 별도 페이지로 이동하지 않아도 폼을 바로 작성할 수 있습니다. Google Sheets 연동까지 설정해두면 제출된 데이터가 스프레드시트에 자동 저장되어 리드 관리가 훨씬 편해집니다.
코드 기반 폼으로 확장할 때 주의할 점
Tally 같은 노코드 도구는 빠르게 검증하기에 충분하지만, 실제 서비스 코드베이스에 통합해야 할 때는 React Hook Form이나 Zod 같은 라이브러리가 필요합니다. React Hook Form은 React 환경에서 폼 상태를 효율적으로 관리해주는 라이브러리이고, Zod는 TypeScript 기반의 스키마 유효성 검사 도구로 입력값이 정해진 형식에 맞는지 런타임에서 검증합니다.
저는 시청 후 멀티스텝 폼 컨테이너를 컴포넌트 라이브러리로 정리했습니다. 상단에 진행률 표시줄(Progress Bar), 하단에 이전/다음 버튼, 중앙에 현재 단계 콘텐츠가 들어가는 구조입니다. 결제 4단계, 가입 3단계, 설정 마법사 5단계 이렇게 세 가지 Variants를 만들어뒀고, localStorage 임시 저장 로직은 useStepFormDraft라는 5줄짜리 React 커스텀 훅으로 정리해서 외주 4건에 재사용 중입니다. 평균 폼 완료율이 12%p 개선됐습니다.
한국 서비스에서 한 가지 더 고려해야 할 부분이 있습니다. 본인 인증 단계입니다. PASS·NICE·KCP 같은 본인 인증 SDK는 별도 팝업 또는 리다이렉트 방식으로 동작하기 때문에, 인증이 완료된 후 원래 폼의 컨텍스트(Context), 즉 어느 단계에서 어떤 값을 입력했는지 상태가 날아가는 문제가 생깁니다. 영상에서 다루는 글로벌 영문 흐름에는 이 단계가 없기 때문에, 한국 환경에서 멀티스텝 폼을 구현할 때는 인증 전 입력값 보존 전략을 별도로 설계해야 합니다. 제 경험상 이 부분을 놓치면 인증 직후 이탈률이 급격히 오릅니다.
폼 하나를 제대로 다듬는 데 생각보다 많은 시간이 필요합니다. 제가 결제 폼 단계를 줄이는 데만 한 달간 사용자 테스트를 거쳤습니다. 하지만 그 결과로 얻은 결제 완료율 13%p 개선은 그 시간이 충분히 가치 있었다는 걸 보여줬습니다. 폼은 단순한 입력창이 아니라 사용자와의 첫 대화입니다. 어떤 질문을 어느 순서로 꺼내느냐가 전환율을 결정합니다. Tally로 빠르게 조건 논리 폼을 검증해보고, 코드 기반으로 확장할 때 useStepFormDraft 같은 재사용 가능한 훅을 미리 만들어두는 흐름을 추천드립니다. 폼 최적화는 한 번 구조를 잡아두면 이후 모든 프로젝트에서 복리로 돌아옵니다. 구글 개발자 문서의 폼 UX 가이드라인도 함께 참고하시면 실무에 바로 적용할 수 있는 기준점을 얻을 수 있습니다(출처: Google web.dev).