버전 관리: UX 라이터 (새 탭에서 열림)

Figma의 UX Writer Henry Freedland는 프로토타입 오프라인 기능의 메뉴 문구를 다듬으며, 단어 하나가 사용자의 기대와 실제 시스템 동작 사이의 신뢰를 좌우한다고 설명합니다. 기술적으로 정확한 표현보다 사용자가 무엇을 하려는지, 클릭 후 어떤 결과를 기대하는지를 명확히 연결하는 표현이 중요합니다. 결국 UX 글쓰기는 단순한 문구 수정이 아니라 제품의 동작과 사용자 경험을 정렬하는 작업입니다.

UX 글쓰기가 드러내는 제품의 본질

• Figma는 인터넷 없이도 프로토타입을 안정적으로 발표할 수 있도록 오프라인 기능을 개발했습니다.
• 기능 구현이 거의 끝난 시점에 메뉴 문구를 정하려 했지만, 어떤 단어를 선택할지 논의하는 과정에서 제품이 실제로 무엇을 하는지에 대한 근본적인 질문이 드러났습니다.
• UX 문구는 사용자가 시스템의 동작 방식을 이해하고 예측하도록 돕는 일종의 안내 규칙입니다.
• 동작 자체가 명확하지 않다면, 아무리 짧고 자연스러운 문구라도 사용자 기대와 실제 결과 사이에 혼란이 생깁니다.

1차 시도: “Preload prototype”의 기술적 정확성

• 초기 문구는 **“Preload prototype”**이었습니다.
• 프로토타입을 화면을 이동할 때마다 불러오는 대신, 필요한 리소스를 미리 모두 로드한다는 기술적 동작을 정확히 표현합니다.
• 하지만 “pre-”라는 접두사는 보통 어떤 일이 일어나기 전에 수행되는 작업을 뜻합니다.
  • 예: 오븐을 미리 데우는 “preheat”
• 사용자는 이미 프로토타입을 로드한 뒤 이 옵션을 보게 되므로, 무엇을 “미리” 로드한다는 것인지 직관적으로 이해하기 어렵습니다.
• 기술 배경이 있는 사람에게는 익숙하지만, 일반 사용자에게는 다음과 같은 추가 설명이 필요합니다.
  • 현재 무엇이 이미 로드되었는가?
  • 무엇을 추가로 로드하는가?
  • 언제 오프라인 상태로 전환되는가?

“Load full prototype”이 해결하지 못한 신뢰 문제

• 더 익숙한 동사인 **“load”**를 사용해 다음과 같은 표현도 검토했습니다.
  • “Load full prototype”
  • “Load all screens”
  • “Load all assets”
• 그러나 사용자는 이미 프로토타입을 열었기 때문에, “전체 프로토타입을 로드한다”는 표현이 현재 상태와 충돌할 수 있습니다.
• 컴퓨터가 “로드 중”이라고 알려주면 사용자는 그 과정을 신뢰하지만, 로딩이 끝난 뒤에는 모든 것이 준비되었다고 믿게 됩니다.
• 따라서 “Load full prototype”은 현재 화면이 사실은 완전히 준비된 상태가 아니라는 인상을 주며, 프로그램과 사용자 사이의 신뢰를 약화시킬 수 있습니다.
• 기술적으로 정확한 명칭이라도 사용자의 현재 상황과 맞지 않으면 좋은 UX 문구가 되지 않습니다.

2차 시도: 사용자의 목적을 직접 표현하기

• 기능의 목적은 인터넷이 없어도 프로토타입을 안정적으로 발표하는 것이므로 다음 표현도 제안되었습니다.
  • “Present prototype offline”
  • “Prepare to present offline”
• 소프트웨어 문구는 사용자가 왜 어떤 행동을 하는지부터 고려해야 합니다.
• Terry Winograd의 표현처럼 사람은 언어를 통해 행동하므로, 메뉴 문구는 사용자의 의도와 컴퓨터의 실행 동작을 연결해야 합니다.
• **“Present prototype offline”**은 실제로 클릭하는 순간 발표가 시작되지 않는다는 점에서 문제가 있습니다.
  • 사용자는 즉시 발표 화면이 나타날 것이라고 기대할 수 있습니다.
• **“Prepare to present offline”**은 준비의 의미가 모호합니다.
  • 무엇을 준비하는가?
  • 얼마나 일찍 눌러야 하는가?
  • 준비가 끝났다는 것을 어떻게 알 수 있는가?
• 이 표현들은 사용자를 위한 단계별 안내나 후속 화면이 있다면 사용할 수 있지만, 단순한 토글 메뉴에는 지나치게 무겁고 불명확합니다.

문구 선택 기준: 생각·언어·시스템 동작의 일치

• 좋은 UX 문구는 다음 세 가지를 일치시켜야 합니다.
  • 사용자가 머릿속으로 생각하는 목표
  • 메뉴에 표시된 언어
  • 실제 시스템이 수행하는 동작
• 세 요소 사이의 간격이 크면 사용자는 클릭 결과를 예측하기 어렵습니다.
• 기술 용어를 그대로 노출하면 구현 방식은 설명할 수 있지만 사용자의 목적을 놓칠 수 있습니다.
• 반대로 사용자의 목표만 강조하면 시스템이 실제로 무엇을 하는지 알 수 없게 될 수 있습니다.
• 특히 토글 메뉴에서는 문구만 보고도 현재 옵션의 의미와 활성화 후 결과를 이해할 수 있어야 합니다.

실용적인 결론

오프라인 기능처럼 내부적으로는 복잡한 동작을 수행하는 기능일수록, 기술적 구현명보다 사용자의 기대와 실제 결과를 정확히 연결하는 문구를 선택해야 합니다. 메뉴 문구를 정할 때는 “무엇을 하는가”뿐 아니라 “사용자는 왜 이 기능을 켜는가”, “클릭 직후 무엇이 일어날 것이라고 기대하는가”를 함께 검토하는 것이 좋습니다.