Back_to_Basics

{3줄 요약}

인터페이스 텍스트는 읽는 글이 아니라 사용자의 행동을 바로 이끄는 신호예요.
문장이 모호하거나 시스템 말투면 사용자가 멈추고 다음 행동을 망설이게 돼요.
이 원칙을 알면 버튼과 안내와 오류 문구를 더 짧고 명확하게 설계하게 돼요.

인터페이스 텍스트가 다른 글쓰기와 다른 이유

소설을 쓸 때는 독자가 처음부터 끝까지 읽어요.
인터페이스 텍스트는 달라요.

사용자는 버튼 텍스트를 "읽는" 게 아니라 0.2초 만에 인식해요.
에러 메시지가 뜰 때는 이미 당황하거나 짜증이 난 상태예요.
길고 설명적인 문장을 읽을 여유가 없어요.

이 원칙을 무시하면 어떻게 될까요?
회원가입 화면에서 "개인정보처리방침에 동의하셔야 다음 단계로 진행하실 수 있습니다"라는 에러 메시지가 뜨면 - 사용자는 무엇을 해야 하는지 한눈에 안 들어와요.
"개인정보 동의 필요"라고 쓰는 것보다 두 배 오래 걸려서 이해해야 해요.

Sarah Richards는 《Content Design》에서 이렇게 말해요.
콘텐츠는 사용자의 필요에서 시작해야 하지, 만드는 쪽의 논리에서 시작하면 안 된다고요.

동사로 시작하고 결과를 말해요

버튼 텍스트는 누르면 무슨 일이 일어나는지를 정확히 말해야 해요.

동사로 시작하는 이유: 사용자는 "이 버튼을 누르면 내가 무엇을 하게 되나"를 알고 싶어요.
동사가 그 행동을 명확하게 전달해요.

나쁜 예	좋은 예
확인	결제 완료
제출	리뷰 등록하기
취소	이전으로
처리	계좌 이체
진행	다음 단계로

"확인"이 나쁜 예인 이유: 무엇을 확인하는지 불분명해요.
정말 이것을 완료하겠냐는 확인인가요, 아니면 다음 화면으로 이동하는 건가요?
맥락에 따라 달라요.

카카오페이에서 이체 버튼이 "보내기"인 이유, 토스에서 충전이 "충전하기"인 이유 - 동사 + 명확한 행동이에요.

비파괴적 행동 vs 위험한 행동 구분: "삭제"처럼 되돌릴 수 없는 행동은 버튼 텍스트에서부터 명확하게 표시해야 해요.
"삭제"보다 "영구 삭제"가, "취소"보다 "구독 해지"가 사용자에게 더 솔직해요.

사용자의 언어로 써요

입력창 레이블, 메뉴 항목, 필터 옵션 - 이 텍스트들이 사용자가 서비스 구조를 이해하는 언어예요.

가장 흔한 실수: 내부 용어나 시스템 언어를 그대로 쓰는 것.

❌ "사용자 식별 코드 입력" → ✅ "아이디 입력"
❌ "콘텐츠 등록" (메뉴) → ✅ "글 쓰기"
❌ "계정 관리 서비스" → ✅ "내 계정"

내부에서 부르는 이름 ! = 사용자가 이해하는 이름.
개발팀이나 기획팀에서 부르는 명칭이 사용자 인터페이스에 그대로 나오면 사용자가 "이게 뭐지?"라고 멈춰요.

검증 방법: 이 레이블을 처음 보는 사람에게 "이 메뉴가 뭘 하는 곳인 것 같아요?"라고 물어봐요.
바로 답이 나오지 않으면 수정이 필요해요.

문제 + 해결책을 함께 줘요

에러 메시지는 가장 중요한 인터페이스 텍스트 중 하나예요.
뭔가 잘못된 순간, 사용자가 가장 필요한 정보를 줘야 해요.

좋은 에러 메시지의 구조: [무엇이 문제] + [어떻게 해결]

나쁜 예	좋은 예
오류가 발생했습니다	비밀번호를 다시 확인해주세요
잘못된 입력입니다	이메일 형식이 아니에요 (예: name@email.com)
처리 실패	결제가 실패했어요. 카드 정보를 확인하거나 다른 카드를 써보세요

사용자를 탓하는 표현도 피해야 해요.
"잘못 입력하셨습니다"는 사용자 잘못처럼 들려요.
"이 형식으로 입력해주세요"처럼 해결 중심으로 써요.

Gmail의 에러 메시지가 잘 설계된 사례예요.
"받는 사람 주소를 추가해주세요", "제목을 비워두셨어요. 이대로 보내시겠어요?"처럼 정확히 뭐가 문제이고 어떻게 하면 되는지를 말해요.

기회로 써요

목록이 비어있거나 검색 결과가 없을 때 뜨는 텍스트도 인터페이스 텍스트예요.

나쁜 빈 상태: "데이터가 없습니다. " 좋은 빈 상태: "아직 장바구니가 비어 있어요. 마음에 드는 상품을 찾아볼까요?" + [쇼핑 시작] 버튼

빈 상태 메시지는 사용자가 막힌 순간에 다음 행동을 안내할 기회예요.

이 원칙을 적용할 때 스스로에게 물어보세요

이 텍스트를 처음 보는 사람이 0.5초 안에 의미를 파악할 수 있나요?
사용자의 언어(일상어)로 쓰였나요, 아니면 시스템·내부 언어인가요?
에러 메시지에 해결책이 포함되어 있나요?
버튼 텍스트가 동사로 시작하고 결과를 설명하나요?
이 원칙이 제품 전체에서 일관되게 지켜지고 있나요? (어떤 화면은 "확인", 다른 화면은 "완료" - 이런 불일치가 없는지)

Interface 텍스트를 시스템화하는 방법은 UI Typography에서, 이 원칙이 UX Writing 전체와 어떻게 연결되는지는 UX Writing에서 다뤄요.

참고 문헌

Sarah Richards, 《Content Design》(2017) - 인터페이스 텍스트를 사용자 중심으로 설계하는 원칙과 방법론이에요.
Steve Krug, 《Don't Make Me Think》(2014) - 텍스트가 사용자를 멈추지 않게 만드는 원칙의 기반이에요.

Interface 텍스트 디자인