이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프로젝트에서 '제출하기'라는 버튼 문구가 사용자에게 막막하게 느껴진다는 피드백을 받은 적이 있습니다. 제출 후 어떤 일이 생기는지 모르니 누르기 망설여진다는 것이었습니다.
'신청서 보내기'로 바꾸고 테스트했더니 클릭 주저함이 눈에 띄게 줄었습니다. 동사와 목적어를 함께 쓰니 사용자가 다음에 무슨 일이 생기는지 예측할 수 있게 되었다고 생각했습니다. 이 작은 변경으로 이탈률이 줄었다는 결과를 보고, 텍스트가 UI만큼 중요하다는 것을 실감했습니다.
이 경험에서 텍스트 개선의 첫 기준은 사용자가 다음을 예측할 수 있는가라고 생각하게 되었습니다. 기능을 설명하는 것보다 결과를 예측할 수 있게 쓰는 것이 더 효과적이라는 것을 배웠습니다.
팀 프로젝트에서 팀원마다 버튼 문구와 안내 메시지 스타일이 달라서 통일이 필요했어요. 어떤 팀원은 '~하세요', 다른 팀원은 '~해주시기 바랍니다'를 쓰고 있었습니다.
간단한 텍스트 스타일 가이드를 만들어서 명확성, 간결성, 일관성 세 원칙을 정했어요. '~해주세요'로 통일하고, 안내 메시지는 15자 이내로 제한했습니다. 처음엔 팀원들이 번거로워했는데, 사용자 테스트에서 메시지 이해 속도가 빨라졌다는 피드백이 오니 모두 따르기 시작했어요.
이 경험에서 Writing Principles는 문서보다 팀이 공유한 판단 기준이라는 걸 배웠어요. 기준이 있으면 매번 논쟁하지 않아도 된다는 실용적인 효과가 있었습니다.
앱 출시 후 '오류가 발생했습니다'라는 에러 메시지를 보고 어떻게 해야 할지 모르겠다는 피드백이 여러 건 왔어요.
기술 팀은 에러 로그를 보기 위한 메시지였는데, 사용자는 다음 행동을 알려주는 메시지를 원한다는 걸 몰랐던 거였습니다. '인터넷 연결을 확인하고 다시 시도해 주세요'로 바꾸니 같은 오류에서 재시도율이 올라갔어요. 에러 메시지 하나로 이렇게 차이가 날 줄 몰랐습니다.
이 경험에서 에러 메시지도 사용자 경험의 일부라는 걸 배웠어요. 텍스트를 개선할 때는 개발자 관점이 아니라 사용자가 읽을 때 어떤 행동을 취할지를 기준으로 써야 한다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 UX 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.