이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
앱·웹 통합 서비스 과제에서 '저장하기' 버튼 문구를 모바일과 웹에서 동일하게 쓰다가 문제가 생긴 경험이 있습니다.
모바일에서는 버튼이 화면 하단에 고정되어 있어서 짧은 문구가 적합했지만, 웹은 사이드바에 위치해 있어 설명이 더 필요했습니다. 사용자 테스트에서 모바일 참가자들은 짧은 문구를 선호했고, 웹 참가자들은 '저장하기' 옆에 괄호로 '자동저장 꺼짐' 같은 상태 표시를 원했습니다. 이후 플랫폼별로 다른 문구 가이드를 만들었습니다.
이 경험에서 프로덕트 글쓰기는 플랫폼의 화면 구조와 사용 맥락을 함께 고려해야 한다는 것을 배웠습니다. 같은 기능이라도 화면 환경이 다르면 문구도 달라져야 한다는 점을 깨달았습니다.
개인 프로젝트로 만든 할 일 관리 앱에서 푸시 알림 문구와 앱 내 알림 메시지를 처음에 똑같이 썼던 경험이 있어요.
푸시 알림은 잠금화면에서 보이는 거라 길고 공식적인 문구가 이상하게 느껴진다는 피드백이 왔어요. '오늘 완료하지 못한 할 일이 3건 있습니다.'를 '아직 3개 남았어요 ☑'로 바꾸니 친구들의 반응이 달랐습니다. 인앱 알림은 반대로 짧고 비공식적인 문구가 신뢰감을 떨어뜨린다는 피드백도 왔어요.
이 경험에서 알림 채널마다 사용자가 처한 상황이 달라서 글쓰기 톤도 달라야 한다는 걸 배웠어요. 플랫폼 문법은 단어 선택이 아니라 맥락과 상황에 대한 이해라고 생각합니다.
수업 프로젝트에서 로그인 실패 에러 메시지를 '인증 오류가 발생했습니다'로 썼다가 사용자 테스트에서 문제가 된 경험이 있어요.
테스트 참가자 4명 중 3명이 '인증 오류'가 무슨 뜻인지 모르겠다고 했어요. '비밀번호를 다시 확인해주세요'로 바꿨더니 참가자들이 즉시 뭘 해야 하는지 알게 됐습니다. 같은 에러라도 앱에서는 다음 행동을 안내하는 문구가, 웹 관리자 페이지에서는 오류 코드를 함께 보여주는 방식이 더 맞았어요.
이 경험에서 에러 메시지도 누가 어디서 보느냐에 따라 다르게 써야 한다는 걸 배웠어요. 기술적 표현과 사용자 언어 사이의 간격을 좁히는 게 프로덕트 글쓰기의 핵심이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 UX 리서처 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.