문의 모듈은, 한 명이 만들지 않습니다.

문의 폼에서 사람이 가장 많이 떠나는 순간이 언제인지 아세요? 입력칸이 가득 찬 첫 화면을 본 직후입니다. 이름, 회사, 연락처, 이메일, 예산, 일정, 내용… 다 채워야 할 것 같으면 사람은 ‘다음에 하자’며 닫습니다. 그래서 저희는 문의 모듈을 ‘기능 목록’이 아니라 ‘떠나는 지점을 하나씩 없애는 작업’으로 봅니다. 그리고 그 지점마다 담당이 다릅니다.

왜 한 화면에 다 넣지 않나요?

한 화면에 칸이 일곱 개면 부담이 일곱 배로 보입니다. 한 번에 하나씩 물으면 ‘이 정도면 금방 끝나겠다’가 됩니다. 여기에 진행 막대로 ‘거의 다 왔다’는 신호를 더하면, 끝까지 가는 비율이 올라갑니다. 아래 모듈을 직접 진행해 보세요. 멀티스텝 폼·인라인 검증·버튼·마이크로카피·완료 화면이 한 덩어리로 움직입니다.

오류는 언제, 어디서 알려야 할까요?

제출을 다 누른 뒤에 화면 맨 위로 빨간 오류가 몰려 뜨는 폼, 많이 보셨을 겁니다. 사용자는 그제야 어디가 틀렸는지 거꾸로 찾아 올라가야 합니다. 인라인 검증은 그 칸 바로 아래에서, ‘다음’으로 넘어가려는 순간에 알려줍니다. 위 데모에서 이름을 비운 채 ‘다음’을 눌러보세요 — 칸 아래에 안내가 바로 뜹니다. 고칠 곳이 명확하니 좌절이 줄어듭니다.

제출 버튼은 ‘눌린 다음’이 더 중요하다고요?

그렇습니다. 사용자가 제출을 눌렀는데 아무 일도 안 일어나면, 사람은 한 번 더 누릅니다. 문의가 두 번 들어오고, 결제라면 두 번 빠져나갑니다. 그래서 제출 버튼은 누른 직후 비활성화되고, 처리 중임을 보여주고, 끝나면 완료 신호를 줘야 합니다. ‘상태를 가진 버튼’은 개발이 맡는 부분인데, 이게 빠지면 위의 멀티스텝도 검증도 마지막 한 걸음에서 무너집니다.

안내 문구 한 줄이 그렇게 차이를 만드나요?

만듭니다. ‘오류’ 대신 ‘연락처를 입력해 주세요’, ‘제출’ 대신 ‘무료 진단 신청’, 완료 화면의 ‘영업일 1일 안에 연락드립니다’ 한 줄 — 같은 폼이라도 말투가 사람을 안심시키거나 밀어냅니다. 마이크로카피는 가장 적은 비용으로 마찰을 줄이는 레버입니다. 위 모듈의 라벨·플레이스홀더·완료 문구는 모두 그 관점에서 고른 것입니다.

완료를 토스트로 알리는 게 좋을까요, 화면으로 알리는 게 좋을까요?

둘 다 ‘피드백’입니다. 페이지 이동 없이 가벼운 확인이면 토스트가 좋습니다. 위 모듈 아래 ‘저장 토스트’·‘오류 토스트’ 버튼을 눌러보세요 — 화면 흐름을 끊지 않고 결과만 알립니다. 반대로 ‘무엇을 했고 다음에 무엇이 일어나는지’까지 안내해야 하면 완료 화면이 낫습니다. 문의 모듈에서는 둘을 섞습니다. 큰 결과는 완료 화면으로, 작은 동작은 토스트로.

이 다섯을 따로 잘 만들면 안 되나요?

각각 잘 만들어도, 이어 붙였을 때 어긋나면 사용자는 그 틈으로 빠져나갑니다. 검증 문구의 말투와 버튼 라벨의 말투가 다르거나, 토스트 색이 브랜드와 따로 놀거나, 단계 사이 간격이 들쭉날쭉하면 ‘덜 만든 느낌’이 납니다. 그래서 문의 모듈은 합작이되 한 기준으로 묶습니다. 색·간격·말투·동작이 한 손에서 나오는 것 — 그게 ‘완성형’의 의미입니다.

합작 분해 — 누가 무엇을 했나

저는 문의 모듈을 만들 때 ‘떠나는 지점’마다 다른 담당을 붙여 칸으로 나눕니다.

각각 좋아도 이어 붙였을 때 어긋나면 사용자가 그 틈으로 빠진다는 걸, 저는 이 표로 묶어 둡니다.

그리고 저는 이 문의 한 모듈에 들어간 기술을 칩으로 펼쳐 둡니다 — 데모 폼이지만 동작은 실제입니다.

색·간격·말투·동작이 한 손에서 나오도록 고른 도구들 — 그게 ‘완성형’의 의미입니다.