wensity/wensity-ui-copy

Wensity UI 카피

단어는 디자인의 일부입니다. 모호하거나 과장된 카피는 정교한 인터페이스도 평범하게 느껴지게 하고, 평범하고 구체적인 카피는 평범한 인터페이스도 신뢰할 수 있게 만듭니다. 모든 문자열의 테스트는 이것입니다: 누군가가 이해하거나 행동하는 데 도움이 되는가?

1. 톤(Tone)

• 평이한 단어. 도움이 되는 사람이 말하듯이 쓰세요. "변경사항 저장", "수정 사항 유지"가 아니라. "크레딧이 부족합니다", "크레딧 잔액 소진"이 아니라.
• 사용자의 언어로, 시스템의 언어가 아닌. "알림", "웹훅 전송 설정"이 아니라. 사람들이 무엇을 하는지에 따라 이름을 지으세요.
• 짧게. 의미를 바꾸지 않는 단어는 모두 자르세요. 그리고 다시 자르세요.
• 모든 곳에 문장형 대문자 사용: 제목, 버튼, 메뉴 항목, 탭, 레이블. "새 프로젝트 만들기", "새 프로젝트 만들기"(영어와 달리 한국어는 대소문자 구분이 없으므로 원문의 취지를 살려 평어체로 통일)가 아니라.
• 능동태, 사용자에게 직접 말하기. "이 프로젝트에 접근 권한이 없습니다", "이 프로젝트에 대한 접근이 허용되지 않습니다"가 아니라. 시스템이 실패했다면 솔직하게 말하세요: "파일을 저장할 수 없었습니다", "파일을 저장할 수 없습니다"가 아니라.
• 차분하게. 진정한 축하가 있을 때를 제외하고 느낌표는 사용하지 말고, 오류에 사과하지 말고, 오류 상태에 농담을 넣지 마세요.

2. 카피가 생성된 것처럼 보이게 만드는 단어들

다음을 피하세요. 독자가 확인할 수 있는 내용이 전혀 없습니다:

• 동사: 잠금 해제, 발휘, 고양, 강화, 가속, 혁신, 변환, 간소화, 활용, 제어, 재창조, 급등.
• 형용사: 완벽한, 수월한, 최첨단, 차세대, 세계적 수준, 강력한, 직관적인, 혁신적, 올인원.
• 구문: "오늘날 빠르게 변화하는 세상에서", "당신의 X를 다음 단계로", "당신이 X든 Y든", "안녕을 고하세요", "더 이상 찾지 마세요".
• 형태: 세 개의 형용사를 연속으로 나열("빠름. 안전. 간편."), 가운뎃점 목록(디자인 · 빌드 · 제공), 그리고 제품 텍스트 내의 어디든 있는 em 대시(페이지 <title>, 메타 설명, 대체 텍스트 포함). 콜론, 쉼표 또는 두 개의 문장을 사용하세요: "Ledgerline: 모든 통화의 인보이스".

각각을 구체적인 사실로 대체하세요: 무엇을 하는지, 얼마나 빠른지, 누구를 위한 것인지, 어떤 결과를 가져오는지. "40분짜리 보고서를 2분으로 단축"이 "워크플로우 가속화"보다 낫습니다.

3. 제목

• 제목은 요점을 말합니다. 주제가 아닙니다. "인보이스가 9일 더 빨리 지급됩니다"가 "기능"보다 낫습니다. "워크스페이스가 비어 있습니다"가 "워크스페이스"보다 낫습니다.
• 눈썹 없음. 제목 위에 작은 대문자 레이블("기능", "가격", "작동 방식")을 두지 마세요. 독립적으로 서는 제목을 쓰세요.
• 페이지 제목은 사람들이 자신이 어디에 있는지 알 수 있도록 페이지 이름을 지정합니다: "결제", "팀 멤버".

4. 버튼과 링크

• 동사로 시작하고 결과를 명명하세요: "인보이스 만들기", "초대 보내기", "CSV 내보내기". "제출", "확인", "예", "여기를 클릭", "더 알아보기" 단독으로 사용하지 마세요.
• 버튼을 다음에 일어날 일과 일치시키세요. 버튼이 "게시"라고 표시되면 토스트는 "게시됨"이라고 표시되고 페이지는 게시된 상태를 보여줍니다.
• 기본 및 보조 작업은 명확히 달라야 합니다: "프로젝트 삭제"와 "취소", "예"와 "아니오"가 아니라.
• 1~3단어가 이상적입니다. CTA는 구체적인 이점을 추가한다면 5단어까지 갈 수 있습니다("무료로 시작, 카드 불필요").
• 링크 텍스트는 단독으로 의미가 있어야 합니다(스크린 리더는 링크를 컨텍스트 밖에서 나열합니다): "API 가이드 읽기", "여기"가 아니라.
• 파괴적인 작업은 대상을 명명하세요: "파일 3개 삭제", "팀에서 Sam 제거".

5. 폼

• 입력 필드 위에 레이블은 항상 표시됩니다. 플레이스홀더 텍스트는 레이블이 아닙니다. 입력을 시작하면 사라집니다.
• 플레이스홀더는 형식을 보여줍니다. 지시사항이 아닙니다: [email protected], MM / YY. 레이블만으로 충분하면 생략하세요.
• 도움말 텍스트는 입력 전에 알아야 할 규칙을 필드 아래에 표시합니다: "최소 12자".
• 필수 필드가 대부분인 경우 필수 필드가 아닌 선택 필드를 표시하세요: "회사 (선택 사항)".
• 포커스 해제 시 또는 제출 시에 유효성 검사를 하고, 키 입력마다 하지 마세요. 오류는 해당 필드 옆에 표시하세요.

6. 오류

모든 오류는 두 가지 질문에 답합니다: 무슨 일이 일어났는지, 그리고 지금 무엇을 해야 하는지.

좋지 않음	더 나음
잘못된 입력	오늘 이후의 날짜를 입력하세요
문제가 발생했습니다	서버에 연결할 수 없습니다. 연결을 확인하고 다시 시도하세요.
오류 403	이 프로젝트에 접근 권한이 없습니다. 소유자에게 초대를 요청하세요.
업로드 실패	이 파일은 24MB입니다. 제한은 10MB입니다.
결제 거부됨	카드가 거부되었습니다. 다른 카드를 사용하거나 은행에 문의하세요.

• 절대 사용자를 비난하지 마세요("잘못된 이메일을 입력했습니다"). 수정 방법을 설명하세요("[email protected]과 같은 이메일을 입력하세요").
• 코드와 스택 트레이스를 메시지에 포함하지 마세요. 지원팀이 필요로 한다면 참조 ID를 끝에 넣으세요.
• 사용자가 입력한 내용을 유지하세요. 하나의 필드가 실패했다고 해서 폼을 절대 지우지 마세요.

7. 빈 상태

빈 상태는 새 사용자가 가장 먼저 보는 것입니다. 온보딩으로 취급하세요:

1. 여기에 무엇이 표시될지 말하세요: "보낸 인보이스가 여기에 표시됩니다."
2. 그 빈 상태를 채울 하나의 작업을 제시하세요: 기본 버튼, "인보이스 만들기".
3. 선택 사항: 가져오기 링크, 템플릿 또는 짧은 가이드.

"검색 결과 없음" 빈 상태의 경우, 검색한 내용과 검색 범위를 넓히는 방법을 말하세요: "'인보이스'에 대한 결과가 없습니다. 철자를 확인하거나 필터를 지우세요."

8. 로딩, 성공 및 토스트

• 로딩: 1초 이상 걸릴 때 무슨 일이 일어나고 있는지 말하세요: "보고서 생성 중…". 줄임표 문자를 사용하세요.
• 성공 토스트: 작업의 과거형과 대상을 포함하세요: "[email protected]으로 초대 전송됨", "프로젝트 삭제됨. 실행 취소".
• 되돌릴 수 있는 작업의 경우 확인 대화상자 대신 실행 취소를 제공하세요. 되돌릴 수 없는 경우에만 확인을 요청하세요.
• 확인 대화상자: 제목은 실제 질문을 합니다("'Q3 보고서' 삭제?"), 본문은 결과를 명시합니다("모든 사람에게서 제거됩니다. 되돌릴 수 없습니다."), 버튼은 작업을 명명합니다("보고서 삭제" / "취소").

9. 숫자, 날짜 및 단위

• 숫자를 사용하세요: "파일 3개", "세 개의 파일"이 아니라.
• 사용자의 로케일로 형식 지정: 수동으로 만든 문자열 대신 Intl.NumberFormat 및 Intl.DateTimeFormat(또는 toLocaleString)을 사용하세요.
• 최근 이벤트는 상대적 시간("2분 전"), 오래된 이벤트는 절대 날짜("3월 4일"), 툴팁에 전체 타임스탬프를 표시하세요.
• 복수형을 올바르게 사용하세요: "파일 1개", "파일 2개", "파일 0개". Intl.PluralRules 또는 헬퍼를 사용하고, 절대 "파일(들)"을 사용하지 마세요.
• 숫자와 단위를 줄바꿈되지 않는 공백으로 함께 유지하세요(HTML에서는 10 MB, JavaScript에서는 "10\u00A0MB").

10. 현실적인 플레이스홀더 콘텐츠

실제 콘텐츠 없이 디자인을 구축할 때는 실제처럼 보이는 콘텐츠를 작성하세요:

• 구체적인 이름과 데이터: "마야 첸, Northwind의 프로덕트 디자이너", "$12,480.00", "인보이스 INV-2041". "홍길동", "$XX", "로렘 입숨"이 아니라.
• 현실적인 길이. 일부 긴 것도 포함하여 레이아웃이 테스트되도록 합니다: 40자 이름, 1줄 설명 옆에 3줄 설명.
• 증거를 절대 만들어 내지 마세요. 가짜 고객 로고, 별점, 사용자 수 또는 실제인 것처럼 제시된 사용 후기를 사용하지 마세요. 표시된 플레이스홀더([고객 인용], [로고])를 사용하거나 사용자에게 실제 것을 요청하세요.
• 제품의 세계와 일치시키세요. 개발 도구의 샘플 데이터는 리포지토리와 배포입니다. 클리닉 앱의 샘플 데이터는 약속과 환자입니다.

11. 카피의 접근성

• 모든 아이콘 전용 버튼에는 접근 가능한 이름이 있어야 합니다: aria-label="대화상자 닫기".
• 대체 텍스트는 이미지가 정보를 전달할 때 무엇을 보여주는지 설명합니다("막대 차트: 1월 이후 수익 24% 증가"). 장식용 이미지는 alt=""를 받습니다.
• 색상 단어에만 의존하지 마세요("초록색 버튼을 클릭하세요").
• 청중이 매일 사용하지 않는 한 약어는 처음 사용 시 전체로 확장하세요.

12. 완료 전 확인 사항

• 섹션 2의 군더더기 단어, 세 형용사 태그라인, 인터페이스 문자열의 em 대시가 없습니다.
• 모든 제목이 요점을 말합니다. 눈썹이 없습니다.
• 모든 버튼이 동사로 시작하고 결과를 명명합니다.
• 모든 오류가 무슨 일이 일어났는지와 무엇을 해야 하는지 말합니다.
• 모든 빈 상태가 스스로를 설명하고 다음 작업을 제공합니다.
• 모든 곳에 문장형 대문자 사용이 적용되었습니다.
• 샘플 콘텐츠는 구체적이고, 길이가 다양하며, 만들어진 증거가 없습니다.
• 아이콘 전용 컨트롤과 의미 있는 이미지에 접근 가능한 텍스트가 있습니다.