서문

• 내수 서비스의 경우 애초부터 화면에 표시되는 문구의 초안을 한국어로 작성하기 때문에 사용 맥락, 화면 내 위치, 서비스 콘셉트, 브랜드 이미지와 UI 텍스트 간의 어울림이 더 좋은 경우가 많다.
• 하지만 한국 내수 사용자만을 대상으로 하는 서비스의 한국인 기획자, 디자이너가 작성한 문장임에도 어색하고 이해할 수 없는 문장이 꽤 자주 보인다. 아마도 그동안 영어 UX 라이팅 사례를 보고 글쓰기 훈련을 해오고 있었기 때문이 아닐까.
• 각 언어가 가지는 보편성과 특수성을 겸허하게 받아들이고, 그 이해 위에서 한국어 UX 라이팅 실무에 도움이 되는 구체적인 이야기

💬 우리 회사에서는 번역팀이 별도로 없기 때문에, 프로덕트 I18n작업을 프론트 개발자가 파파고나 구글 번역기를 돌려서 대충 하는데, 글로벌팀이 생기고 글로벌 서비스로 확장하게 되면서 번역된 영문의 라이팅이 눈에 들어오기 시작했다. 쓸데없이 목적어나 수식어구를 써서 버튼 라벨이 길어지는 경우도 있고, 가끔은 번역이 잘못된 경우도 있었다. 한국어에서는 명사 수식어구가 있는 것이 자연스러운데, 영문에서는 ‘굳이’ 들어가 있는 느낌이 드는 경우가 꽤 자주있다. 각 언어가 가지는 특성을 잘 알고 있다면 자연스러운 번역, 라이팅을 할 수 있겠다. 싶었다.

마이크로카피 vs. UI 텍스트

• UX라이팅의 대상이자 결과물을 지칭하기 위해 ‘UI 텍스트’라는 용어를 사용

• 근래 IT 업계에서 ‘마이크로카피’라는 용어가 UI 텍스트라는 용어를 대체하고 있고, 유머가 고루한 UI 텍스트의 해결책인 것처럼 이해되는 분위기가 있다.

• 하지만 이 책에서는 UI 텍스트라는 용어를 사용하여 UX/UI 디자인의 중요 요소라는 의미를 담고 싶다. 실제로 UI 텍스트는 마이크로카피보다 더 넓은 영역을 지칭한다(주의사항, 공지사항, 릴리즈노트와 같은 마이크로하지 않은 텍스트도 많기 때문). ‘Micro-’는 미시적이고 단발적인 인상을 가지기 때문에 서비스의 시작에서 끝까지 쉼없이 이어지는 긴 담화, 적극적 대화의 특성을 담기는 어려운 면이 있다.

• UI 텍스트는 서비스상에서 마이크로한 차란의 감정과 움직임을 불러일으키는 트리거이기보다, 매크로한 사용 경험 서사의 한 요소에 가깝다.

  ⇒ 한 서비스의 UI 텍스트가 이러한 매크로한 경험 서사의 요소라고 생각할 수 있으려면 그만큼 그 서비스가 UI 텍스트의 톤앤 매너, 역할, 사용자 페르소나 정의, 기능과의 연결성, 플로우가 모두 유기적으로 연결되어있고, 디자이너, 개발자, 라이터가 이를 잘 이해하고 있어야할 것 같다.

UX 라이팅, UX 라이터

UX 라이팅은 무엇일까

• UI 텍스트는 사용자의 생각과 의사, 행동에 따라 비선형적(예측할 수 없게)으로 등장하는 텍스트, 즉 상대의 반응에 따라 달라질 수 있는 상호작용을 위한 텍스트
• 우리의 목적은 오로지 사용자와 서비스 사이에 매끄러운 티키타카가 끊김 없이 이루어지도록 하는 것이다.
• 오프라인 접객(예: 파인다이닝 레스토랑의 직원과 손님의 대화)의 경험을 온라인으로 확장시키는 것과 크게 다르지 않다.
• UX 라이팅은 결국 사용자에게 알려줄 정보를 디자인하는 일이며, 구체적 맥락과 내용을 끼고 진행되는 흐름이 있는 대화, ‘구체적인 정보 상호작용’
• 사용자: 서비스를 통해 정보를 얻고자함., UX 라이터: 사용자가 서비스를 이용하며 만나는 모든 콘텐츠를 창작, 배열한다. 정보디자이너라고 할 수 있다.

사람과 대화하듯 쓰라는 말에 대한 오해

• ‘사람과 대화하듯 쓰라’는 말은 ‘구어체로 사람처럼 말하라, 서비스를 의인화하라, 보이스와 톤을 해요체로 말해서 서비스가 마치 실재하는 인간인 것처럼 연기하고 꾸며내라’는 말이 아니다.

UX 텍스트는 대화와 같아야한다고 말한 것은 ‘캐주얼한 대화’ 또는 ‘친근하고 격식 없는’ 보이스나 톤 등을 지칭한 것이 아닙니다. 나는 인간이 단어와의 상호작용을 통해 어떤 것을 인식할 수 있다는 것을 말하고자 했습니다.

• 토레이 파드마저스키-

• UX 라이팅은 마치 컴퓨터가 인간이 된 것처럼 흉내내는 미미크리 놀이가 아니다. 외리ㅕ 너무 사람인 척 굴면 불쾌한 골짜기 효과가 발현될 수 있고, 종국에는 자신이 구축한 브랜드의 서비스의 캐릭터를 더 이상 감당 못 하게 될 수도 있다.
• 자신의 존재를 사용자에게 각인시키기 위해 글을 쓰는 것이 아님을 기억해야한다. UX 라이팅은 오로지 사용자의 목표 달성과 훌륭한 사용 경험을 위한 글쓰기이며, 가장 훌륭한 UI텍스트는 맥락에 자연스럽게 녹아든 나머지 사용자에게 그 자신의 존재가 거의 인지되지 않는 문구이다.
• 문체, 어투, 보이스와 톤에 대한 고민은 일단 저 뒤쪽으로 미뤄두길 바란다. 가장 우선해야하는 것은 사용자 과업의 완성을 위해 적정한 정보를 생산하고 전달하는 일이고, 정보를 어떻게 디자인해서 진정한 의미의 대화를 할지이다.

UX writing 원칙

(다른 원칙들도 많지만 몇개만 추려서)

1. 간결하게 써라 (TMI 금지)

• UI 텍스트는 공간과 시간에 민감한 텍스트
  • 휴대폰 기종별로 해상도가 다르면 텍스트 길이에 영향을 미침
  • 토스트, 스낵바, 툴팁 등에 표시되는 경우 텍스트 표시되는 시간이 짧음
• 글을 짧게 써야하는 다른 이유로는, UI 텍스트는 가독성이 중요한 글이기 때문
  • 사용자는 화면에 진입 후 글자부터 읽지않고 전체적 형태, 레이아웃으로 의미를 파악하려함. 그 때 판단이 어려우면 그제서야 텍스트를 읽으려고 함.
  • 따라서 몇 음절, 어절만에 사용자를 빠르게 이해시키는 것이 중요
• 린매스업: 핵심은 남기고, 불필요한 것은 빼기
  • 단문(주어 동사 하나로 구성되는 문장)을 최대 한두문장마나 쓰기.
    • 복문이 될 바에야 끊어서 가는게 나음
  • 텍스트에 중복 제거

    • 어미, 조사, 앞뒤의 음절 등 작은 요소까지 중복되는 부분을 삭제

      • 예시 (’계좌 설정’이라는 subheader가 있는 메뉴)

      ‘계좌 이름 변경’ ’계좌 색상 변경’ ‘계좌 번호 복사’

      vs

      ‘이름 변경’ ’색상 변경’ ’계좌 번호 복사’

      💬 변수 이름 짓기와 비슷하다는 생각이 든다. 코딩할 때 주니어, 시니어 개발자 모두가 가장 고민하는 것이 바로 ‘변수 이름 짓기’라는 말이 있는데, (실제로 이것 때문에 30분 넘게 고민하고, 몇년차든지 머리를 싸매고 고민하고… 정한 이름을 몇 번이고 바꾸고들 한다.) 이 때 ‘컨텍스트에서 이미 알 수 정보가 있으면 생략’하라는 원칙?이 있는데, 코드로 예를 들면 다음과 같다. 😄 특히나 변수명은 길어질 수록 빠르게 어떤 정보를 담고있는지 파악하기 어렵기 때문에, 최대한 간결하면서도 어떤 정보를 담고 있는지 명확히 짓는 것이 중요하다. 이름짓기가 중요한 이유중 큰 이유는 ‘나 혼자서만 개발하는 것이 아니기’ 때문이다. 누구나 읽어도 빠르게 이해할 수 있어야하는 명확하고 간결한 이름이 좋다.

      // 굳이 'account'라는 단어를 앞에 붙임으로써 가독성이 저해됨
      interface Account {
        accountNumber: string;
        accountColor: string;
        accountId: string;
       }
       
      interface Account {
        name: string;
        color: string
        id: number; 
      }
  • 한국어 사용자는 일반적으로 ‘F자형 읽기’를 한다. 그런데 앞에 동일한 단어가 반복되면 메뉴의 차이를 빠르게 인지하기 어렵다.
    • 그렇다고 어미는 반복되어도 된다는 것은 아니다! 이들은 괜히 화면만 무겁게 하는 꼬리.
    • 특히 최근 유행하고있는 ‘~하기’!
      • ‘하기’는 염원, 기원, 다짐, 미래, 예정의 의미를 담은 명사형 전성어미. 마치 사용자 스스로가 해당 액션을 다짐하는 듯한 인상을 줌. 그래서 요즘 많은 서비스에서 모튼 버튼에 이 어미를 붙이는 경향이 있다.
      • 하지만 버튼당 2음절씩 늘어나면서 화면 복잡도가 늘어나고, 가독성도 저하됨
      • ‘-하기’를 쓰는게 무조건 잘못된 것도 아니고, 적절한 곳도 있겠지만, ‘멤버십 해지하기’, ‘서비스 탈퇴하기’같은 곳에 ‘하기’를 붙인 곳은 마치 서비스를 반드시 탈퇴하기로 마음먹은 느낌을 주기 때문에.. 신중히 사용하는 것이 좋다.
      💬 언제부턴가 ‘하기’ 어미를 많이 발견하곤 했고, 나도 서비스 만들 때 버릇처럼 사용했던 것 같다. 언젠가 이 풍조(?)에 대해 비판하는 글을 발견했었는데, 그 때 당시에는 ‘그 두 음절이 얼마나 큰 영향을 미친다고’ 이렇게 까지 하나 싶었으나, 이 부분을 읽고 모든 화면에서 불필요한 상황에서도 꼬리표처럼 붙는다면 서비스 많은 영향을 미치겠구나 싶었다.

(보이스와 톤 생략 - 다음에 좀더 집중해서 읽기. 언어의 뇌과학 완독 후 읽어도 좋을 것 같음!)

UI 컴포넌트 별 텍스트 작성법

• UI 컴포넌트와 UI 텍스트는 한 몸
  • UI 컴포넌트에 동일한 이해를 갖고 있으면 작업이 순조로움
  • 조직 내 사용하는 컴포넌트 명칭도 통일되는 것이 좋음
  • 적용법, 패턴, 예외 케이스도 합의되어야 함
  💬 이 모든 것은 디자인 시스템이 잘 정리되어있다면 걱정하지 않아도 될 부분. 우리회사에서도 UI 컴포넌트 명칭을 통일해서 사용하지 않는 것이 있는데, 항상 고민이다. 디자이너 개발자와 합의를 해야하지만 우리는 새로운 기능을 런칭하기 바쁘다…