Writings

Writings

글쓰기는 이용자(셀러 및 회원)에게 publ의 서비스를 이해하고 사용하는데 가장 중요한 요소입니다. Writings는 UI 에서 적용되는 문구 뿐만 아니라, 에러 메세지나 공지사항 게시글 처럼 회사의 글쓰기가 서비스 내부에서 제공될 때 적용되어야 하는 원칙입니다.

Writings 원칙은 작업자가 텍스트를 작성하고 고민하는데에 시간을 줄여줄 수 있고, 특별한 브랜딩 없이도 일관되게 메세지를 전달할 수 있습니다.

기본 원칙

PDS에서 제안하는 원칙을 고려하여, 글쓰기도 기본 원칙을 갖습니다.

명확하게, 정확한 의미를 전달하기

셀러와 회원이 원하는 기능/목표를 달성할 수 있도록 명확하게 전달합니다. 제약조건이 있는 경우 이용자(셀러 및 회원)가 정확하게 이해할 수 있도록 글을 작성합니다. 또한, 전문 용어나 어려운 표현을 가급적 배제하여 의미를 이해하는데 있어 소외되는 이용자가 없도록 노력합니다.

목표를 달성할 때 까지 일관된 경험을 제공하기

셀러와 회원이 publ 서비스를 이용할 때, 최대한 자신의 목표 달성을 이룰 수 있도록 일관된 경험과 커뮤니케이션을 수행합니다. 단어나 개념을 새롭게 이해하지 않아도 이용할 수 있도록, 익숙한 표현을 사용하고  서비스 전체에서 일관된 표현과 메뉴 이름, 기능 이름을 사용합니다. 

이용자의 어려움을 공감하고 설명해주기

다양한 기능들을 제공해주는 만큼, 복잡한 사용자 여정을 거쳐야 하는 이용자의 입장을 고려하여 원하는 목표를 달성할때까지 포기하지 않도록 돕습니다. 어려운 학습을 해야할 때에는 설명을 반드시 덧붙여주고, 어려운 상황에 처하지 않도록 바로 해야할 일을 알려주어 목표까지 도달을 수 있도록 도와줍니다. 실수를 하더라도 바로 수습 할 수 있는 방안을 제시해 줍니다. 또한 다양한 배경의 사람들이 우리 서비스를 이용하게 되므로, 특정 집단의 사람들이 소외감이나 불쾌함을 느끼지 않도록 노력을 기울입니다.

시스템이 아닌 사람으로 다가가기

이용자가 서비스를 이용할 때, 딱딱한 말투보다는 인간적인 소통을 수행하고 신뢰할 수 있는 가이드처럼 친근하지만 존중해주는 말투를 사용합니다. 여기서 가이드는 친구가 아님으로 과도한 친근함이나 장난스러운 표현, 은어 등은 배제합니다.

어조와 어투, 표현

올바른 표준어를 사용하도록 노력하기 (맞춤법 검사 수행하기)

올바른 표준어를 구사하여 전달할 수 있도록 노력합니다. 문법에 맞는 표현과 단어를 사용하고, 긴 글의 경우 맞춤법 검사를 수행하여 검토합니다.

추천 : 도움이 되는 맞춤법 검사 사이트

신뢰감있는 말투를 사용하여, 이용자가 이해할 수 있게 글쓰기

• 이용자에게 어떤 행동을 부탁할 때에는 '~해주세요'를 사용합니다.

• 이용자가 얻을 수 있거나 상황에 처할 때에는 '~할 수 있습니다'를 사용합니다.

1. 이용자가 이해할 수 있게 표현합니다.

이용자의 상황 및 이해 수준을 고려하여 이야기합니다. 전문 용어나 특수 용어, 과도한 단순화나 축약, 시각적 표현을 사용하지 않도록 합니다.

1. 과도한 친근감의 표현, 감탄사 남발은 피해주세요.

너무 많은 이모티콘과 '~해요' 등의 표현은 publ 서비스의 신뢰도를 낮출 수 있습니다. 하나의 맥락을 갖는 단락(Paragraph)에서는 1개의 기호 또는 이모티콘을 사용하고, 감탄사를 남발하지 않습니다.

명확한 의미 전달하기

비유나 묘사를 가급적 지양하고, 명확한 의미를 전달할 수 있도록 합니다.

서비스에서 '용어'나 기능을 지칭할 때에는 일관된 표현을 사용해야 합니다.

이용자의 행동을 지적하지 않기

이용자의 실수나 행동에 의해 뜨는 메세지들이 이용자의 행동을 지적하고 탓하는 느낌이 들지 않게 합니다. 아래 상황에서, 이용자가 잘못 행한 것에 초점을 맞추지 않고, 일어난 결과/상태를 알려주는 것이 좋은 글쓰기 입니다.

외래어를 표기하는 경우

국립국어원에서 제시하는 가이드라인에 맞추어 작성 합니다.

참고 : 국립국어원 한국어 어문 규범 중 외래어 사전

문장 작성 시 기본적으로 지켜야 할 사항

구두점 사용하기

문장은 반드시 구두점을 사용합니다. 명사형으로 끝마치는 경우에는 마침표(.)를 사용하지 않는 것이 일반적이며, 보통 개요 항목을 사용할때에 구두점을 사용하지 않습니다.

참고 : 국립국어원 한국어 어문 규범 중

짧은 문장으로 시작하기

긴 문장의 글을 시작할 때에는 간결한 단문으로 시작합니다. 주어와 동사를 명확하게 사용하고, 대명사를 사용하지 않습니다.

Case 1 : 예약권 정기지급 수량의 설명을 표시할 때
Don't	이 구독상품을 이용하는 구독자들은 설정하신 수량만큼의 예약권을 매 구독시마다 정기적으로 지급받을 수 있습니다.
Do	채널 구독 시 지급할 예약권의 수량을 입력해주세요. 회원은 구독을 갱신할 때 마다 정기적으로 예약권을 지급 받게 됩니다.

Case 2 : 회원가입 시 이메일 정보를 입력받을 때
Don't	이메일은 비밀번호 찾기 및 주문 정보, 필수 정보 안내를 위해 사용됩니다.
Do	이메일은 로그인 시 아이디로 사용됩니다. 또한 이메일 주소로 비밀번호 찾기, 주문 정보, 필수정보 안내를 위해 사용됩니다.

페이지나 새로운 개념이 나오면 의미를 먼저 설명하기

설명할 공간이 충분하다면, 가장 먼저 개념의 의미를 설명합니다. publ 서비스는 다양한 기능으로 이루어져 있으며, 특히 셀러의 경우에는 개념을 이해해야 정확하게 기능을 사용할 수 있습니다. 때문에, 단문으로 먼저 의미를 설명합니다.

Case 1 : 재생목록 라벨 페이지를 설명할 때
위 이미지에서, [재생목록 라벨] 페이지를 설명하는 문구를 먼저 하단에 작성하고, 그 다음에 부수적인 내용을 설명하는 것이 좋은 글쓰기 입니다.
Don't	한번 추가된 라벨은 더이상 변경할 수 없습니다.
Do	재생목록 라벨은 재생목록을 분류할 수 있는 표시입니다. 구독자는 재생목록을 볼 때, 셀러가 분류한 기준에 따라 목록을 구분할 수 있습니다. 한번 추가된 라벨은 더 이상 변경할 수 없습니다.

무엇을 얻을 수 있는지 알려주기

이용자는 반드시 얻고자 하는 목적을 갖고 있습니다. 채널을 생성하거나 구독상품을 만드는 것 처럼, 불편하거나 귀찮은 작업을 순차적으로 해나갈 때에는 시작하기 전에 앞서 무엇을 얻을 수 있는지 먼저 알려줍니다.

Case 1 : 재생목록 라벨 페이지를 설명할 때
위 이미지에서, [재생목록 라벨]을 설정하는 것이 구독자에게 어떤 의미를 갖는지 알아야 기능을 사용할 수 있습니다. 때문에, "구독자가 ~하게 이용할 수 있다"를 알려주는 것이 올바른 글쓰기 입니다.
Don't	한번 추가된 라벨은 더이상 변경할 수 없습니다.
Do	재생목록 라벨은 재생목록을 분류할 수 있는 표시입니다. 구독자는 재생목록을 볼 때, 셀러가 분류한 기준에 따라 목록을 구분할 수 있습니다. 한번 추가된 라벨은 더 이상 변경할 수 없습니다.

Case 2 : pApp 설정화면에서 설명할 때
위 이미지에서는, 버튼을 눌렀을 때 예상되는 변화/기대를 설명하고 있습니다.
Do	pApp을 활성화합니다. 구독자에게 표시하기 위해서는, 반드시 활성화 되어 있어야 합니다. (중략)

제약조건을 명확하게 알려주기

입력 필드의 문장인 경우, 제약조건은 명확하게 기술되어야 합니다. 특히 [다음]이나 [제출]과 같은 행위를 통해 양식이 제출되어야만 제약조건을 알 수 있다면, 반드시 문장으로 기술되어야 합니다. 단, 입력 시 유효성 검사를 수행한다면, 입력하지 않습니다.

Case 1 : 회원가입 시 이메일 정보를 입력할 때
위 시안에서 이메일 정보를 제출해야만 유효성 검사를 수행한다면, 문장 내에 제약 조건이 포함되어야 합니다.
Do	이메일은 로그인 시 아이디로 사용됩니다. 또한 이메일 주소로 비밀번호 찾기, 주문 정보, 필수정보 안내를 위해 사용됩니다. 올바른 이메일 형식으로 입력되어야 합니다. 추가로, 버튼을 눌러 유효성을 검증한 뒤 잘못 되었다면 "올바른 이메일 형식으로 입력되어야 합니다." 메세지를 표시합니다.

Case 2 : 회원가입 시 이메일 정보를 입력할 때
위 시안에서 이메일 정보를 입력 시 유효성 검사를 수행한다면, 문장에서 제약조건을 별도로 알리지 않습니다.
Do	이메일은 로그인 시 아이디로 사용됩니다. 또한 이메일 주소로 비밀번호 찾기, 주문 정보, 필수정보 안내를 위해 사용됩니다. 이메일 유효성 검증 문구 : 올바른 이메일 형식으로 입력되어야 합니다.

조치/지시를 안내할 때 지켜야 할 사항

조치/지시를 안내하는 경우 : 해야할 일을 알리고, 예상 결과를 안내하기

에러 등 즉각적인 조치를 요하거나 지시하는 경우에는, 먼저 해야할 일(Action)을 먼저 설명합니다. 그리고 할 일(Action)에 대한 예상 결과를 같이 안내합니다.

Case 1 : pApp 설정화면에서 활성화 버튼을 눌렀을 때
위 이미지에서, pApp을 활성화 시켰을 때 어떤 변화가 있는지를 예상할 수 있다면 더 좋은 글이라 볼 수 있습니다.
Do	이 pApp을 활성화 하겠습니까? pApp을 활성화하면 구독자가 pApp의 기능을 사용할 수 있습니다.

한꺼번에 알려주지 말고, 해야할 일을 하나씩 안내하기

이용자가 여러 번의 작업 또는 여러 페이지를 통해 목표를 도달할 수 있다면, 고민에 빠지지 않게 해야할 일을 명시적으로 하나씩 알려줍니다.

지시사항에서 UI 요소를 지칭하는 경우, 대괄호 [ ] 를 사용하고, 강조합니다.

정확한 지시를 할 때, UI 요소를 지칭하는 경우 대괄호 [ ] 를 사용하고 강조합니다. 도움말이나 이용방법을 설명하는 등의 문장에서 사용됩니다.

지시사항이나 설명에서 제목을 지칭할때는, 꺾인 괄호 < > 를 사용하고, 강조합니다.

지시사항이나 설명 등에서 제목을 지칭하는 경우, 꺾인 괄호 < > 를 사용하고 강조합니다.

UI 요소에 작성할 때 확인할 사항

맥락을 이어가기

'삭제하기'를 눌렀으면, 대화상자의 버튼은 '삭제'여야 합니다.

이용자는 어떤 행동을 달성하기 위하여 UI 요소를 찾고 반응합니다. 따라서 UI 요소의 문구와 결과로 표시되는 문구는 동일한 용어를 사용하거나 맥락을 이어가야 합니다.

Case 1 : 예약 pApp에서 예약 일정을 변경할 때
Do	예약에서 [수정] 버튼을 누르면, <일정 수정> 제목과 함께 Modal이 표시되고 있습니다.	일정의 변경사항을 적용하는 버튼 역시 [수정]으로 표시되어, 맥락을 이어가고 있습니다.

Case 2 : 구독자 추방 안내 시
Don't	강제 추방코드를 입력한 다음, 해당 값을 서버에 제출 하므로 [제출] 버튼을 표시합니다.
Do	본 Modal의 제목이 <구독자 강제 추방> 이라는 목표를 갖고 있으므로, 추방 코드를 입력한 뒤에 원래 목적이었던 [추방]으로 맥락을 이어가고 있습니다.

버튼의 경우, 명칭은 위치에 따라 어미를 다르게 사용합니다.

버튼 명칭은 표시되는 위치에 따라 사용하는 어미를 다르게 사용합니다. Modal 이나 좁은 범위에서의 버튼은 짧게, 명사형으로 사용합니다.

Case 1 : 새 재생목록을 생성할 때
본 화면은 Modal 이기 때문에 [취소], [생성]를 사용하고 있습니다.
Don't	[취소하기], [생성하기] 버튼
Do	[취소], [생성] 버튼

(특히 모바일에서) 유일한 하나의 목표를 제안하거나 제공하는 경우, '-하기'를 제한적으로 사용할 수 있습니다. '-하기'를 사용하면 더 친숙하고, '해야할 것' 처럼 유도할 수 있습니다.

	Case 1 : 사용자가 계정을 만들 때	Case 2 : 사용자가 채널을 결제할 때
Do	사용자는 회원으로 가입하기 위해 본 화면에 진입하였습니다. 때문에, [가입하기] 라고 버튼을 표시하면 목적을 잊지 않게 강조해줄 수 있습니다.	사용자는 채널을 결제하기 위해 본 화면에 진입하였습니다. 때문에, [결제하기] 라고 버튼을 표시하면 목적을 잊지 않게 강조해줄 수 있습니다.

다만 '-하기'는 제한적으로 사용합니다. 내용이 길다면 사용하지 않는 편이 자연스럽습니다. 또한, 동등한 위계를 갖고 있는 버튼이라면 사용하지 않습니다.

	Case 1 : 회원이 비밀번호를 재설정할 때	Case 2 : 회원이 설정화면을 확인할 때
Do	버튼의 명칭이 길기 때문에, [인증 메일 발송] 이라고 표시하는게 자연스럽습니다.	동등한 위계의 항목으로 버튼이 배열되어 있으므로 [서비스 건의 하기], [로그아웃 하기] 라고 사용하지 않습니다.

문제 상황을 알릴 때 확인할 사항

Dead-end 피하기

예기치 못한 에러나 상황이 발생하여 안내 메세지를 표시해야 한다면, 아래 원칙을 확인해주세요.

짧게 표현할 때 : 해야할 일을 알려주기

여유롭게 설명할 수 없다면, 상황을 해결할 수 있는 방법을 명확하게 지시 합니다.

길게 표현할 때 : 원인/이유를 짧게 설명하고 해야할 일 알려주기

설명을 할 수 있다면, 짧게 현 상황을 안내하고 상황을 해결할 수 있는 방법을 명확하게 지시합니다.

에러코드가 정의되어 있는 경우, 괄호 ( )를 사용하여 에러코드를 같이 표시합니다.

에러 코드가 정의된 문제상황의 경우, CS 등에서 안내할 수 있도록 에러 코드를 같이 표시합니다.

대처할 방법이 없을 때에는 상황을 짧게 설명합니다.

별도의 대처 방법이 없는 경우에는 상황을 짧게 설명하고, 다시 시도해달라고 일괄적으로 표현합니다.

문서 작성 정보