UX 라이터의 글쓰기 - 그렇게 쓰면 아무도 안 읽습니다.
📚 오늘의 책 : 그렇게 쓰면 아무도 안 읽습니다
- 저자 : 전주경 (LINE UX Writer)
- https://brunch.co.kr/@joojun/155 (2023년 저자 브런치 출간 소개글)
Intro
왜 책을 읽어야 할까?
- 외서로 ux라이팅을 공부하다보니 한국어에 잘 안맞는 부분이 많음
- 사회문화적, 언어적 특성이 반영이 안된 상태로 무작정 외국의 성공한 케이스를 따라하면 안됨
- 현업에서 외국의 대형서비스의 레이블을 배끼는 사례도 많음
- 서비스와 사용자 사이의 편안한 대화가 끊임없이 이어지는게 곧 서비스의 성공이다
1장 : UX 라이팅, UX 라이터
UX 라이팅이란 뭘까?
- 사용자에게 알려줄 정보를 디자인 하는 일
- 구체적인 정보의 상호작용
- 화려하고 과장된 보이스로 존재를 각인시키기 위함이 아님
- 오롯이 사용자의 목표 달성에 초점
- 사용자에게 존재가 거의 인지되지 않는 문구
UX라이팅을 바라보는 왜곡된 시각과 그 이유
- 유명한 해외 서비스의 레이블을 번역해서 가져다 쓰는 경우
- 규모가 작은 서비스에서 대형 서비스의 텍스트를 똑같이 쓰는 경우
- 어떤 서비스가 자신들의 ux라이팅을 잘한다고 홍보하면 다른 서비스들이 따라가는 경우가 왕왕있음 → 해요체
- 깔끔한 디자인을 위해 텍스트를 간과하는 경향
UX 라이팅이 할 수 있는 일, 없는일
- 예)구글 호텔 예약화면 버튼 개선 book a room → check avaliability
- 해도그만, 안해도 그만이 아니라 제대로 안하면 서비스의 사용성이 매우 나빠질 수 있는게 UX라이팅
- UX적으로 근본적인 문제 해결이 어려울 때 UX라이팅이 불완전함을 잠시 커버칠 수 있다.
무슨 일을 하는지?
- 가이드라인에 따라 텍스트를 작성 (UI text mostly)
- 플로우상 텍스트의 역할, 위상, 표시위치, 노출 타이밍 고려
- 기존 텍스트 히스토리 고려
- 유사 서비스 고려
- 답이 안나와서 새로운 언어를 만들어야 할 때는 난감함
- 그냥 글을 잘 쓰는 사람이 아니라 어떤 이유에서 이 텍스트가 작성되었는지 객관적인 근거 마련과 언어지식으로 잘 설명할 수 있는사람
- 서비스에 존재하는 모든 텍스트를 시스템화 해서 관리
<aside> 💡
실무에서 UX 라이터와 함께 일해본 경험?
- 개인적 경험은 없음 - 보통 기획과 디자이너가 함께 진행
- 국내에서 토스, 네이버웹툰, 야놀자 등에서 따로 채용하고 있는 것으로 보입니다
<aside> 💡
LLM이 UX 라이터를 대체할 수 있을까? 에 대한 저자의 생각
- (1) 윤리적 취약성 (2) 결과물의 퀄리티 (3) 맥락에 대한 이해부족
- 완전히 대체하기는 어려우나 UX Writer의 글쓰기 보조도구로 생산성 향상 가능
- 요즘에는 항상 AI가 특정 직군을 대체할 수 있을지에 대한 논의가 이루어지는 것 같습니다
- 개인적으로는 AI가 번역가를 완전하게 대체할 수 없는 것과 동일한 맥락이지 않나 싶습니다
- 하지만 비용을 줄이고 싶어하는 비용이라면? : 그런데 애초에 큰 기업 아니고서는 UX Writer가 존재하지도 않기 때문에 그냥 AI를 쓰는편이지 않나 싶습니다.
2장 : UX 라이팅 기본원칙
살아남고 싶다면, UX 라이팅 원칙을 지켜라
구글:
애플:
- Purpose 목적
- Anticipation 예측가능
- Context 맥락
- Enpathy 공감
사실 전세계가 정한 UX라이팅 원칙같은건 없다. 상황에 맞게 각 회사가 경험을 토대로 정립할 뿐… 저자가 말하는 한국어 UX 라이팅 원칙은 다음과 같음
- 정확성 Clear
- 간결성 Concise
- 일관성 Consistent
정확하게 쓴다라는 것은?
UI 텍스트가 사용자에게 전달해야 하는 3가지 정보
- 서비스 전체 구조에 대한 정보
- 네비게이션의 메뉴, 화면 타이틀 등의 레이블 (언어로 서비스의 청사진 설명)
- 서비스만의 다양한 기능과 관련 개념, 액션에 대한 정보
- 기능명, 서비스의 특정 컨셉, 인터렉션 이름
- 나눠내기, N빵 / 길게 눌렀다가 오른쪽으로 천천히 옮기기
- 기능명, 서비스의 특정 컨셉, 인터렉션 이름
- 사용자가 처한 상황에 대한 정보
- 여긴 어디고, 당신은 누구고, 지금 무슨 일이 생겼고, 이제 당신이 할 수 있는 일로는 이런것들이 있다 → 를 사용자에게 명료하게 설명해 주는 것
- 토스트메세지, 승인팝업, 각종 오류 메세지
UI 텍스트를 정확히 쓰려면 어떻게 해야할까?
- 틀린 정보가 화면에 남아있지 않게 챙긴다.
- 서비스의 규모가 커서, 업데이트가 잦아서 모든 텍스트를 챙기지 못할 때 이런일이 많음
- 이미지 텍스트는 검색이 안되기 때문에 꼼꼼히 확인해야 함
- 여러 디바이스와 OS를 지원하는 서비스에서도 이런일이 잘 발생함
- 사용자가 알아야 할 정보를 충분히 제공한다.
- 이 정보가 없으면 우리 사용자가 앞으로 나아갈 수 있느냐, 없느냐를 기준으로 했을 때, 아무래도 사용자가 수월하게 전진하기 어려울 것 같다고 생각되면 충분하지 않음
- e.g. 평평한곳을 비춰주세요 → 책상, 바닥과 같이 평평한 곳을 비춰보세요
- 포괄적이고 범용적인 문구를 사용하지 않는다.
- 포괄적인 오류메세지의 가장 큰 문제는 사용자가 메세지를 보고 오류상황을 해결할 수 없다는 것이다. ‘우린 망했어’ ‘돌아가’
- e.g. 잘못된 입력입니다 → 메일형식에 @가 빠졌어요, 입력 최대 글자를 초과했어요, 네트워크 입력이 끊겼어요
- 사용자에게 문제상황과 해결할 길을 명확하게 제시해야 한다.
- 포괄적으로 쓰지 않으려면 문장의 주어에는 정확한 기능명이나 특정 상황 명시, 서술어에는 실질적인 의미를 가진 동사를 쓰는게 좋다.
- 한 문장에 또는, 혹은 -거나 같은 상황을 2개이상 병렬 나열하는 접속사 사용 x
- 오류, 예외상황에 대한 케이스를 잘게 쪼갠다.
- 딱 맞는 표현을 사용해야한다
- 텍스트를 확정하기 전 맞춤법 검사기를 돌려보자
- 어휘의 보편성, 사용자 친화성을 알고 싶다면 주요 일간지, 네이버 트랜드나 구글 트랜드의 키워드를 이용하자
- 최종 텍스트를 확정하기 전에 반드시 쿨타임을 두도록 한다.
간결하게 쓴다. 투 머치 토커 입장 금지
- 짧은 글은 누구나 좋아한다.
- UI 텍스트는 공간과 시간이 제한적으로 노출된다. → 가독성이 중요
- 핵심은 남기고, 불필요한것은 빼고
- 주어와 동사 하나로 구성되는 문장, 단문을 최대 한두문장만 쓴다.
- 텍스트에 중복이 있는지를 살펴보고 가능하면 모두 제거한다.
- 계좌 이름변경, 계좌 색상변경, 계좌번호 복사 → 이름변경, 색상변경, 계좌번호 복사
- → 동일 단어로 시작하면 한국인들이 한눈에 구분하기 어렵다
- 삭제하기, 변경하기, 확인하기 → 삭제, 변경, 확인
- → 셀프 미션 발화 ㄴㄴ, 복잡함
- 계좌 이름변경, 계좌 색상변경, 계좌번호 복사 → 이름변경, 색상변경, 계좌번호 복사
- 간결성과 정확성이 충돌할 때
- 개발에서 다른 컴포넌트로 변경하거나, 정보를 다른 화면으로 옮기거나
- 처음부터 …이 나오지 않게 최대한 간결하게 쓰는 것이 최선이지만, 잘림이 발생 할 때 무엇을 잘라낼지 결정해야 함
- Alexandra Josepjus Mary Smith 님 외 345명이 Leo Anderson 님의 노트에…
- Alexandra Josepjus…님 외 345명이 Leo Anderson 님의 노트에 댓글을 달았습니다.
일관되게 쓴다. 다중인격자처럼 보이지 않는 법
- 일관성이 떨어지면 서비스를 의심한다.
- 여기서는 친구추가, 저기서는 팔로우, 친구 되기 → ??? 내가 모르는 다른 기능이 또 있나?
- 브랜드 이미지, 신뢰도 떨어짐
- 서비스 규모, 조직, 소통, 시스템의 영향을 받는 텍스트 일관성
- 텍스트 데이터 관리 시스템을 만드는게 어려운 일이 아님에도 불구하고 텍스트 관련 업무가 뒤로 밀림
- 일관성에 영향을 미치는 여섯가지 요소
- 스타일
- 대소문자 규정, 문장부호와 각종 숫자 표기 (마침표 생략 상황, 띄어쓰기 무시 상황 설정)
- 시각적 표현
- 글꼴, 글자 크기, 굵기, 컬러 등
- 구문법
- 명사형 / 문장형 쓰이는 상황 구분
- 삭제할 기록이 무엇인가요? - 삭제할 기록 선택 : 이런식 혼용 ㄴ
- 명사형 / 문장형 쓰이는 상황 구분
- 포괄성
- 텍스트의 구성요소들이 중복 누락 겹침이 없이 온전히 전체를 이루고 있어야 사용자가 전체적인 의미 체계를 이해할 수 있다
- 입자성
- 정보의 상세한 정도의 양을 일관적으로 유지해야한다. 어디는 상세예시까지 다 쓰고 어디는 정보가 적고 하면 안됨
- 대상
- 사용자 집단을 고려한 언어 선택 (간세포성 암종 ↔ 배앓이 섞어쓰지 말기)
- 스타일
- 일관성의 다층적 유지
- 브랜드>연계서비스>앱>기능>화면
- 모바일 기기와 가전의 텍스트 일관성
- 브랜드>연계서비스>앱>기능>화면
- 일관되게 쓰고 일관되게 관리
- 텍스트 가이드라인
- UI 텍스트의 목적, 대상, 보이스, 문체, 사동및 피동법의 사용, 각종 문장부호, 기호, 숫자표기법, 경로표기법, 외국어 약어 표기법, 들여쓰기 및 줄바꿈, 단어 끊어쓰기, 고유명사 표기, 서비스 핵심용어 목록
- 컴포넌트별 스타일 : 팝업의 타이틀은 어떤 구문법 적용, 플레이스 홀더, 툴팁의 길이제한 어느정도
- 사용자를 어떻게 부를지?
- 텍스트 가이드라인
<aside> 💡
- 포괄적이고 범용적인 문구 사용에 대한 실무 이야기
- “일시적인 오류가 발생했습니다.”
- 이런 오류 메세지의 불친절함은 만드는 사람의 귀찮음 때문일 확률이 큽니다 ㅎㅎ
<aside> 💡
- 서비스 일관성
- 대부분의 회사에서 UX Writer가 없을텐데 어떤 방법으로 동일한 톤앤매너를 유지할까?
- 프로덕트 부서를 넘어서 브랜딩 / 마케팅 차원까지 가는 경우 가능할 수 있을 것 같습니다.
- 대부분의 회사에서 UX Writer가 없을텐데 어떤 방법으로 동일한 톤앤매너를 유지할까?
3장 : 보이스와 톤, 서비스의 목소리 더빙하기
돋보이고 싶다면 보이스와 톤을 정리하자
- 보이스: 사용자가 느끼는 분위기, 이미지와 밀접한 연관, 서비스의 성격과 인상
- 톤: 구체적인 맥락에 따라 변동 가능(오류메세지는 진지하게)
한국어 보이스와 톤에 영향을 미치는 네가지 요소
(다른 언어권의 이론을 한국어에 적용할때 비판적인 자세를 견지해야 한다)
- 문체: 해요체와 하십시오체의 비율
- 공식성, 격식성, 전문성의 정도, 친밀감, 위계관계에서 차이가 있음
- 한국어에서는 상대를 적당히 높이면서 공식적으로 말하기 어렵고, 상대를 아주 높이면서 사적인 느낌을 주며 말하기 어렵다.
- 결국 해요체와 하십시오 체 섞어쓰게 되어있음
- 어미의 중복을 피해야함
- 해요체 = 친근 ? : 서비스 제작자의 바람일뿐 서비스 완성도가 낮으면 미성숙해보일 수 있음
- 해요체는 온보딩이나 사용 가이드 등 서비스 초반부에 등장하는 텍스트에서 큰 활약을 한다. (사용자의 편안한 서비스 접근) 사용자에게 부탁하거나 요구하는 문장을 쓸 때도 유용
- 나중에 다시 시도하세요, 불필요한 파일을 삭제하세요 → 시도해주세요, 삭제해보세요
- 어휘 및 문장: 어휘 난이도와 문장 길이
- 대상에 따라 다르다: 단문과 복문을 조화롭게 섞고, 높은 수준의 어휘도 문장에서 적절하게 사용해야 함
- 유머: 위트있는 표현과 이모티콘 사용
- 사용자의 긴장감 감소, 브랜드의 호감
- 세심한 유머 관리의 필요성 :
- 같은 유머가 반복되어서는 안된다.
- 짜증남, 사용자가 두번다시 보지않을 메세지(온보딩 환영, 튜토리얼, 버전 릴리즈노트)
- 지속적으로 유머 표현 업데이트 필요 (트랜드 탈 수 있음, 상황이 바뀔수 있음)
- 타깃 사용자가 해당 표현을 유머로 받아들일 수 있는지 보수적 판단
- 같은 유머가 반복되어서는 안된다.
- 거리감: 심리적 퍼스널 스페이스의 설정
- 사용자 이름 부르기
- 퍼스널 스페이스를 넘나드는 민감한 행동이 될 수 있기 때문에 조심해야 한다.
- 강한 주목성: 누군가 내 이름이 화면에 나오면 지나치지 못한다.
- 반드시 빈도를 조정해야 써야 함
- 주의를 끌기 위해 너무 이름을 자주 표기하면 사용자의 피로도가 급격히 높아진다.
- 사용자 주의를 강하게 끌어야 할 때, 서비스로부터 특별히 대우받는 다고 느껴야 할 때
- e.g. 성은님 생일축하해요
- 독이 될 수 있는 공감표현
- 사용사의 상황에대해 서비스가 잘 아는 듯 말하거나 감정을 예단하는건 위험
- e.g. 이번달에도 열심히 대출 갚았나요? 수고하셨어요 / 이번달 카드 값이 늘었어요!
- 민감한 주제에 큰 고민없이 공감표현 쓰지 말자
- 공감표현을 UI 텍스트에 시도할 경우 위트와 마찬가지로 같은 문구가 반복 노출되지 않도록 해야 한다. (시스템적인 공감인거 티난다…)
- 사용사의 상황에대해 서비스가 잘 아는 듯 말하거나 감정을 예단하는건 위험
- 사용자 이름 부르기
라인의 보이스
- 명확하게 : 명확하지만 단정적이지 않습니다.
- 정확하고 명확한 언어로 정보 안내, 사용자가 정보를 토대로 선택하도록 자율성
- 사람과 대화하듯이 : 사람과 대화하듯이 말하지만 결코 가볍지 않습니다
- 구어체로 쓰되, 구어체의 가벼운, 비전문적인 한계를 극복하고자 함
- 아시아 문화 특유의 겸손함, 배려, 친절함이 녹아들어있음
- 사려깊게 : 사려깊지만 걱정이 많지 않습니다.
- 서비스에 불필요한 경고나 우려, 제약이 없어야 함.
<aside> 💡
- 유머
- 슬랙이나 디스코드가 농담을 잘 하는 서비스인 듯 하지만 이들도 욕을 많이 먹고 있습니다.. ㅎㅎ
<aside> 💡
사용자 이름 부르기
- 가끔 이름을 너무 불러대서 짜증난 적 있음 (하지만 확실히 주목하게 하는 효과는 있는 듯) 역효과에 주의해야 한다
- 윤님 회사에서 수정된 건 중에
- {유저이름}님 {유저연령대} {성별} ?? 이런 타이틀로 상품 추천을 진행했는데 대표님의 핸드폰에서 '대표님! 50대 남성 상품 추천' ←이런 식으로 나온걸 보고 기분 나빠하셔서 수정된 웃픈 사례가 있습니다. (50대 남성 맞는데 50대 남성이라고 하면 기분 나빠 하심)
4장 : UI 컴포넌트 별 텍스트 작성 팁
레이블
- 서비스에 존재하는 수많은 정보 덩어리 각각의 이름
- 네비게이션의 메뉴명, 설정화면의 메뉴 타이틀, 아이콘 이름 등
- 레이블링 어려움
- 대상의 특성, 서비스내의 위상, 인접 레이블과의 어울림, 표시되는 맥락과 타이밍속에서 해당 이름이 가져야 하는 특별한 의미 두루 고려 필요.
- 오너십이있는 설계자가 조직화 시스템, 네비게이션 시스템의 개념과 구상을 먼저 해 버리면 이 구조에 대해서 완벽히 동의하지 않는 한 레이블링 할 때 어려움
- 레이블링 시 주의점
- 대표성 : 해당 텍스트가 포괄하고있는 개념을 대표할 수 있을까?
- 변별성: 다른 레이블과의 변별성
- 주변 레이블과의 어울림, 비교대조를 통해 그 뜻이 명확해지거나 의미가 강화되는 특성이 있다.
- 일관성 : 사용자의 서비스 지형파악에 도움이 되어야함
- 아이콘레이블
- 모든 아이콘에는 모호함이 있기 때문에 가급적 아이콘 하단에 이름을 병기해야 함
팝업 : 사용자가 가는 길을 막고 해야 할 중요한 이야기
- 사용자에게 아주 중요한 정보를 전달하거나, 사용자의 의사 결정이 반드시 필요할 때
- 사용자에게 너무 많은 것을 물어보며 괴롭혀서는 안된다.
- 타이틀
- 타이틀 / 본문 여부: 상황에 따라 취사 선택
- 단, 팝업 타이틀을 쓸 때는 반드시 본문과 내용적 중복이 없어야 한다.
- 사용자는 버튼을 먼저 읽고, 정보가 부족하면 타이틀까지 읽고 의사결정한다
- 타이틀에는 버튼의 행위 대상(목적어), 주요 액션’ 등의 핵심 정보가 담겨야 한다.
- 1버튼 팝업의 경우에는 평서문, 2버튼 팝업의 경우에는 의문문을 포함시키는게 자연스럽다.
- 본문
- 반드시 한 문장, 어쩔 수 없다면 최대 두 문장
- 사용자 버튼 선택에 도움이 되는 포석과 같은 구체적인 정보를 담아야 한다.
- 버튼
- 왼쪽 or 아래 보조 버튼 : 부정동사 (지금 하려는 행위를 중지하고 이전으로 돌아감)
- 오른쪽 or 위 기본 버튼 : 전진, 확정을 의미하는 긍정동사
- 1버튼 팝업 레이블은 보통 ‘확인’ 많이 씀
커맨드 버튼 : 사용자의 유일한 의사 표현 수단 (CTA)
- 버튼 텍스트는 짧게, 구체적인 동사로 쓴다
- 취소/확인, 아니오/네 → 뭐가 취소고, 아니라는거지!?!?
- 버튼의 동사는 원미래가 아닌 근미래 상황을 지시해야 한다 → 사용자를 낚는 이벤트성 카피
- 버튼 형태에 따른 텍스트 스타일
- 버튼 형태와 사용 맥락에 따라 정보, 길이, 문체 조정
- 텍스트 버튼 (hyperlink)
- 명사로 된, 연결된 랜딩페이지 이름 or 자세히보기/더보기
- 가로/세로형 박스버튼
- 가로형 : 확인 상황, 짧은 텍스트로 결정 속도 높임
- 세로형: 공간이 많아서 더 자세히 작성
- 대화체 버튼
- 사용자 본인이 직접 UI에서 발화한다는 느낌을 줘서 조금이나마 관여도를 높이게 됨
- 자기 선택에 대한 다짐을 상기시킴 (구매할래요, 네, 지금 확인할게요)
- 주의점
- 해요체
- 버튼이 길어짐
- 서비스와 사용자의 권력관계와 상황이 미묘하게 달라짐
- 동등 or 살짝 낮게
- 가장 문제 : 사용자의 이익과 관련된 중요한 선택 순간에만 버튼의 톤을 조정해서 뭔가 이익을 얻어보려는 시도 (현재 이용권 유지할래요!/ 나중에 인상된 가격으로 구매할래요)
- 해요체
- 텍스트 버튼 (hyperlink)
- 버튼 형태와 사용 맥락에 따라 정보, 길이, 문체 조정
토스트, 스낵바, 툴팁: 시간과 공간에 예민한 컴포넌트
- 토스트, 스낵바
- 방금 시스템이 수행한 결과를 간단히 알려줌 (덜 중요한 결과)
- 사용자의 불안감을 해소하기위해 짧게 보고 메세지 표현
- 사용자가 현재 보는 화면에서 수행결과를 확인할 수 있다면 필요 없음(즐겨찾기 버튼 색 바뀜)
- 사용자의 읽는 속도를 심각하게 고려해야 함
- 최대 2줄, 10단어 이하로 작성
- 툴팁
- 사용자가 잘 모를말한 정보를 말풍선으로 제공
- 사용자가 모를 것 같은 정보만 넣는다
- 너무 자주쓰면 구차해보임 / 다른 요소 가림
- 한 화면에 2개 이상의 툴팁 노출 금지
- 사용자가 모를 것 같은 정보만 넣는다
- 사용자가 잘 모를말한 정보를 말풍선으로 제공
오류메세지 : 어려움에 처한 사용자를 돕는 일
- 서비스의 태도가 너무 부정적, 방어적, 저자세여서는 안됨
- 잦은 사과 금물
- 상황, 이유, 대안을 맥락에 맞게 제공하라
- 서버에 연결되지 않아 → 사람들이 그래서 어쩌라구? 싶다. 서버라는 용어는 쓰지 않는게 좋다.
5장 : UX라이팅 실무 이슈
사용자 친화
- 쉽게 쓰기는 모두가 원하지만 모두가 만족하는 쉽게 쓰기 사실상 어려움
- UT에서 텍스트가 어렵다는 피드백이 나왔을 때
- 다른 ux문제더라도 엉뚱하게 익숙한 텍스트 퀄에 문제삼는 경우 있음
- 단어, 문장이 어렵다 등 구체적인 피드백이 나왔을 때는 수정하자..
- 보통 중2 수준 단어 사용
- 용어를 풀어 쓸 경우 오인이 되지 않는가?
- 서비스에서 해당 표현의 중요도가 너무 높으면 섣불리 수정하면 안됨
- 사용자에게 어려운 말을 이해시키는 2가지 방법
- 1: 사용자가 용어를 처음 만나느 시점에 그 단어를 한번 풀어서 설명
- 2: 어려운 단어와 쉬운 단어를 맥락에 맞게 병기해서 사용자가 자연스럽게 두 어휘의 의미가 같다는 사실을 알게 하는 방법
- 주변 맥락을 통해 단어의 의미 추측하도록 함
- 00기업 5주를 매도하시겠습니까? 지금 주식을 팔면 내일 기준 종가로 입금됩니다.
- 서비스 전반에 지속적으로 사용해야 함
UX 라이팅 윤리
- 다크패턴
- 컨펌 셰이밍 / 네거티브 옵트아웃: 사용자에게 불안, 걱정, 수치심, 본인의 판단 능력에 대한 불신을 일으켜서 원치 않는 선택을 하도록 하는 기법
- 그냥 비싸게 구입할래요, 불편하지만 웹으로 볼래요 (어리고 바보같아지는 해요체)
- 컨펌 셰이밍 / 네거티브 옵트아웃: 사용자에게 불안, 걱정, 수치심, 본인의 판단 능력에 대한 불신을 일으켜서 원치 않는 선택을 하도록 하는 기법
세계화와 현지화
- 보편화, 국제화: 타겟 시장에 상관없이 적용할 수 있는 일반화된 프로덕트 설계 및 개발
- 각 문화권의 차이 고려: 날짜표기방식, 숫자형식, 이름, 주소 표기법
- 현지화: 현지 문화에 최적화, 번역 + 문화전반 입히기
- 세계화: 보편화+현지화
- 라인의 현지화 :
- 보편적: 한국어 → 영어 → 현지어
- 라인은 초반부터 현지화 PM이 프로덕트 개발 참여, 개발과 동시에 한/중/일 언어라이팅
- 글로벌 서비스를 위한 현지화 팁
- 성공적인 현지화를 위해서는 소스가되는 UI텍스트가 정확해야 한다
- 영어 네이티브가 아닌 한국어 기획자가 번역기써서 쓴 영어 텍스트는 정확하지 않다.
- 글로벌 프로덕트는 중립적, 포괄적 텍스트 스타일이 필요하다
- 개성적 스타일 적용이 좀 어렵다. 문화권에 따라 달리 받아들여질 수 있음
- 각 문화권에 맞는 개성은 마케팅적 텍스트에서 하자
- 현지 전문가와 현지화 PM이 서비스 멤버로 적극 참여해야한다.
- 성공적인 현지화를 위해서는 소스가되는 UI텍스트가 정확해야 한다
토스증권에 대한 저자 브런치
https://brunch.co.kr/@joojun/99
https://brunch.co.kr/@joojun/102
저는 사실 이 분 브런치를 보고 재미있어서 책을 샀습니다
사용자들이 서비스 텍스트를 통해서 어휘를 학습한다는 생각은 한 번도 해보지 못한 접근이어서 신선했어요