UI는 말한다: 사용자는 카피를 어떻게 읽나

오늘 「확인」을 몇 번 눌렀는지 세어 보세요. 삭제·제출·종료·덮어쓰기·비우기 다이얼로그에 같은 단어가 백 가지 결과를 보증해요. 문제는 여기예요: 버튼 자체에 답이 없고, 답은 본문에 있어요. 사용자는 문단을 다 읽어야 이번 탭이 뭔지 알죠. 「확인 / 취소」 짝은 게으른 거예요—읽기 비용을 사용자에게 떠넘겨요.

처방은 버튼에 결과를 실는 거예요. 「확인」을 「이 3개 삭제」로, 「취소」를 「그대로 두기」로 바꾸세요. 본문을 한 글자도 안 읽어도 버튼만 훑으면 안전하게 답할 수 있어요. Cooper는 About Face 4 21장에서 기능 다이얼로그에 같은 규칙을 세워요: 제목에 동사를 쓰세요. 제목은 뭘 확인하는지, 버튼은 누르면 뭐가 되는지—양쪽 다 사용자가 추측하지 않게.

이 규칙의 테스트 버전도 있어요: 본문을 가리고 제목과 버튼만 보고 안전하게 답할 수 있나요? 되면 카피 합격, 본문을 다시 봐야 하면 여전히 「확인 / 취소」의 게으른 변종이에요. 먼저 몇 가지 대조를 보며 동사 버튼의 감촉을 익혀 보세요.

「결과를 실은 버전」의 부산물도 보세요: 수량과 대상이 버튼에 함께 들어가요(12개, 138****2046)—사용자를 대신해 마지막 확인을 한 셈이죠. 오조작은 대개 「다른 묶음을 고른 줄 알았어」에서 나와요. 버튼이 대상을 말해 주면 그 오해가 바로 풀려요.

버튼 밖, 두 번째 재난 구역은 명사예요. 화면에 「필드 user_mobile 검증 실패」「유일성 제약 위반」이 적혀 있어요—사용자 아무도 모르는 말, DB와 로그에서 그대로 끌어온 거죠. Cooper는 14장에서 뿌리를 파요: 개발자가 DB 요구를 사용자 요구보다 앞에 두니, 소프트웨어는 CPU를 섬기고 사용자는 소프트웨어를 위해 일하는 꼴이 돼요.

14장에는 자주 인용되는 원칙도 있어요: 오류가 프로그램 탓이 아닐 수 있어도, 책임은 프로그램의 것. 휴대폰 번호가 한 자리 모자라고 사용자명이 중복되는 건 사용자 「실수」지만, 그 오류를 듣고 고칠 수 있는 말로 번역하는 건 프로그램 몫이에요. 메뉴 이름도 예외가 없어요. Cooper는 「파일」조차 구현 모델의 말이라 보고, 인보이스 앱 메뉴는 「인보이스」여야 한다고 해요. 사용자가 자기 물건을 뭐라고 부르면, UI도 그렇게 부르세요.

AI가 UI를 쓸 때 이 병에 특히 잘 걸려요: 데이터 구조를 보고 카피를 만들고, 필드 이름이 곧 라벨이 돼요. 막지 않으면 DB가 무대에 올라 연설하죠. 아래에서 다이얼로그를 직접 고쳐, 카피 세 곳을 사람 말로 바꾸고 mock이 바로 바뀌는 걸 보세요.