지난 편에서 UX 라이팅 프로세스를 다뤘어요. 이번 편에서는 버튼, 빈 상태, 에러 메시지, 알림 등과 같은 요소들에서 마이크로카피를 어떻게 작성해야하는지 알아볼게요.
1. 버튼 텍스트
1) 버튼 카피의 핵심 원칙
버튼은 제품에서 가장 영향력이 큰 텍스트 중 하나예요. 의사결정 지점에 등장하고, 사용자가 행동을 취할지 여부에 직접 영향을 미치거든요.
| 원칙 | 설명 | 예시 |
|---|---|---|
| 동사로 시작 | 버튼은 행동을 유발해야 해요 | “만들기”, “보내기”, “다운로드” |
| 결과를 명시 | 버튼을 클릭하면 무슨 일이 일어나는지 알려줘야 해요 | “제출하기” 대신 “계정 만들기” |
| 짧게 유지 | 1~4단어가 이상적이에요 | “변경 사항 저장하기” (O), “여기를 클릭해서 변경 사항을 저장하세요” (X) |
| 사용자 의도와 일치 | 사용자가 달성하려는 것을 반영해야 해요 | “검색하기” 대신 “항공편 찾기” |
2) 흔한 버튼 문제와 개선 예시
버튼 텍스트를 쓸 때 자문할 세 가지가 있어요.
- 사용자가 이걸 클릭하면 무슨 일이 일어나는가?
- 사용자가 달성하고 싶은 것은 무엇인가?
- 그 결과를 1~4단어로 표현할 수 있는가?
| 일반적인 표현 | 구체적인 표현 |
|---|---|
| 제출 | 계정 만들기 / 메시지 보내기 / 주문하기 |
| 여기를 클릭 | 가격 보기 / 보안 정책 자세히 보기 |
| 예 / 아니오 | 파일 삭제 / 파일 유지 |
| 확인 | 알겠어요 / 계속하기 |
2. 에러 메시지의 심각도별 톤
| 에러 유형 | 톤 | 예시 |
|---|---|---|
| 가벼운 / 쉽게 수정 가능 | 중립적, 안내하는 | “올바른 전화번호를 입력하세요 (예: 010-1234-5678)” |
| 사용자 행동 실패 | 도움이 되는, 해결 중심 | “메시지를 보내지 못했어요. 연결을 확인하고 다시 시도하세요.” |
| 시스템 오류 | 사과하는, 안심시키는 | “저희 쪽에서 문제가 발생했어요. 데이터는 안전해요. 잠시 후 다시 시도해 주세요.” |
| 심각한 / 데이터 위험 | 차분한, 명확한, 긴급한 | “세션이 만료됐어요. 저장하지 않은 변경 사항을 잃지 않으려면 다시 로그인하세요.” |
에러 메시지에서 피해야 할 단어도 있어요.
- “잘못된(Invalid)”은 비난하는 느낌,
- “실패(Failed)”만 단독으로 쓰면 맥락이 없고,
- “이런(Oops)”은 심각한 에러에서는 가볍게 느껴지며,
- 에러 코드나 예외(Exception) 같은 기술 용어는 사용자에게 무의미하죠.
3. 빈 상태: 비어있는 이유와 다음 행동 안내
빈 상태(Empty State)는 화면에 표시할 콘텐츠가 없을 때 발생해요. 이 순간은 단순히 “데이터 없음”을 알리는 대신 사용자를 안내하는 기회가 돼요.
완전한 빈 상태는 네 가지 요소를 포함해요.
- 현재 상태(사용자가 보고 있는 것)
- 비어있는 이유(콘텐츠 부재의 맥락)
- 채우는 방법(사용자가 취할 수 있는 행동)
- CTA 버튼(행동으로 향하는 직접 경로)
| 화면 | 부족한 빈 상태 | 더 나은 빈 상태 |
|---|---|---|
| 받은편지함 | “메시지 없음” | “아직 메시지가 없어요. 팀과의 대화가 여기 표시돼요. 대화 시작하기 →” |
| 검색 결과 | “결과 없음” | “‘prodct’에 대한 결과가 없어요. ‘product’를 찾으시나요? 또는 카테고리 탐색 →” |
| 즐겨찾기 | “비어있음” | “즐겨찾기한 항목이 여기 표시돼요. 빠른 접근을 위해 항목을 즐겨찾기해 보세요. 항목 둘러보기 →” |
| 활동 피드 | “활동 없음” | “팀원이 내 작업에 코멘트를 남기면 여기서 확인할 수 있어요.” |
4. 온보딩과 툴팁: 점진적 공개
첫 방문 사용자에게 안내가 필요하지만, 너무 많은 정보는 오히려 압도해요. 핵심은 점진적 공개(Progressive Disclosure), 즉 사용자가 필요한 시점에 정보를 드러내는 거예요.
| 원칙 | 적용 방법 |
|---|---|
| 한 번에 하나의 개념 | 각 화면이나 툴팁이 하나만 다루기 |
| 말하지 말고 보여주기 | 추상적으로 설명하지 말고 UI 요소를 직접 가리키기 |
| 탈출구 제공 | 항상 “건너뛰기” 또는 “나중에 하기” 옵션 |
| 가치에 집중 | 기능이 어떻게 작동하는지가 아니라, 무엇을 할 수 있는지 설명 |
툴팁은
- 필요한 순간에 나타나고(미리 나타나지 않고),
- 하나의 요소나 행동만 설명하며, 짧게 유지되고(1~2문장),
- 인터랙션을 방해하지 않으면서 쉽게 닫혀야 효과적이에요.
| 너무 긴 툴팁 | 적절한 길이 |
|---|---|
| “이 버튼으로 데이터를 CSV, Excel, PDF 등 다양한 형식으로 내보낼 수 있어요. 내보내기 전에 열을 선택하고 필터를 설정할 수 있어요.” | “데이터를 CSV, Excel, PDF로 내보내기” |
5. 알림: 끼어들 자격을 갖춰야 한다
알림(Notification)은 사용자를 방해하기 때문에, 그 방해에 합당한 명확한 가치를 제공해야 해요.
| 유형 | 목적 | 톤 | 예시 |
|---|---|---|---|
| 성공 | 완료된 행동 확인 | 긍정적, 간결한 | “메시지 전송됨” |
| 정보 | 유용한 업데이트 제공 | 중립적, 명확한 | “내 게시물에 새 댓글이 달렸어요.” |
| 경고 | 잠재적 문제 예방 | 차분한, 도움이 되는 | “구독이 3일 후 갱신돼요” |
| 에러 | 문제 알림 | 긴급하지만 건설적 | “결제 실패. 카드 정보 업데이트하기 →” |
알림 카피를 쓸 때 네 가지를 자문하세요.
- 왜 지금인가?(이 알림의 트리거)
- 무엇을 해야 하는가?(필요한 행동)
- 얼마나 긴급한가?(즉시 주의가 필요한지)
- 무시해도 되는가?(정보 제공인지 행동 필수인지)
6. 폼 라벨과 플레이스홀더
폼(Form)은 사용자가 데이터를 입력하는 곳이에요. 라벨이 부실하면 마찰과 오류가 생기죠.
| 요소 | 목적 | 가시성 | 예시 |
|---|---|---|---|
| 라벨 | 무엇을 입력하는지 식별 | 항상 보임 | “이메일 주소” |
| 플레이스홀더 | 형식이나 예시를 표시 | 입력 시 사라짐 | “name@example.com” |
중요한 규칙: 플레이스홀더 텍스트를 유일한 라벨로 사용하면 안 돼요. 사용자가 타이핑을 시작하면 플레이스홀더가 사라지면서, 이 필드에 무엇을 입력해야 했는지 기억할 수 없게 되니까요.
폼 작성 체크리스트는 이래요.
- 모든 필드에 플레이스홀더만이 아닌 보이는 라벨이 있는가?
- 필수 vs. 선택 여부가 명확한가?
- 형식 기대치가 표시되어 있는가(예: “YYYY-MM-DD”)?
- 글자 수 제한이 초과 전에 보이는가?
- 에러 메시지가 해당 필드 옆에 나타나는가?
7. 확인 및 성공 메시지
사용자가 행동을 완료한 뒤, 확인 메시지가 과정을 명시적으로 마무리 시켜줘요. 모호한 확인 메세지는 사용자를 불확실하게 만들죠.
| 구체성이 떨어지는 표현 | 구체적인 표현 |
|---|---|
| “성공!” | “주문이 완료됐어요. 확인 이메일을 보냈어요.” |
| “완료” | “변경 사항이 저장됐어요. 새 설정이 적용됐어요.” |
| “완료됨” | “계정이 만들어졌어요. 프로필 설정으로 시작해 보세요 →” |
확인 메시지의 구조는 세 가지예요.
- 무엇이 완료됐는지(구체적인 행동 이름),
- 결과나 영향(지금 무슨 일이 일어나는지),
- 다음 단계(관련된 후속 행동).
다음 편에서는 실무에서 자주 발생하는 UX 라이팅 실수와 그 개선 방법을 구체적으로 살펴볼 거예요.
UX 라이팅 시리즈