**风格一致性** * 统一命名风格（使用相同名词命名不同组件的子元素）便于理解。 **表述直接** * 比如：“验证码错误”优于“验证码不正确” **第二人称** * 采用系统与用户对话的模式，比如“当您投资成功时，我们会发送短信提示” **主动语态** * 比如：“您已修改此设置”（用户作为主语的主动态）优于“此设置已被您修改” **动词** * 多用及物动词，少用不及物动词和名词，比如“请修改验证码”（及物动词）优于“请对验证码进行修改”（不及物动词），更优于“请进行验证码的修改”（名词）。 **多使用积极的指令** * 比如：“为了顺利投资，请您进行以下操作”优于“为防止投资失败，请您进行以下操作”。 * 起报错、提醒或警示作用时，消极用词能更直接的点明重点，比如：“验证码错误”优于“验证码不正确”。 **词汇统一** * 系统中一个含义只用一个词 **“先说目的”法则** * 先说明操作的目的和重要性，能促使用户更愿意去执行。这就是“先说结论”法则。 * 比如，“为了让您的账户更安全，请设置手势密码”，如果此处不提目的，直接指示“请设置手势密码”，用户在不了解这个新功能时就会产生疑虑，不明白这个操作的意图，甚至产生不信任感，最后无视这个指令。 **“问题-方案”法则** * “说明问题（理由/原因）—给出解决方案（需要用户去做某个操作）” * 比如：验证码错误，请重新输入。 **“问题-后果-方案”法则** * 当方案A-“退出编辑”，后果C-“无法保存所输入的信息”，方案B-“先去保存” * 比如：退出编辑则无法保存所输入的信息，建议您先去保存，您确认要立即退出吗？ **“最简”原则** * 在涵义不变的情况下，优先选择最简洁、字数最少的内容； **“委婉”原则** * 文案有时候并不是为了某个目的和功能，而是为了隐藏不能明说的原因和问题，或者只为了安抚用户情感，这时文案就不能那么生硬直接。 * 比如，“支付需要一些时间，请稍候”优于“支付尚未成功”；“抱歉，出现了一些问题，请稍后刷新重试”优于“系统错误”。 **绝对禁止的文案** * 英文或其他外语 * “banner”“后端开发”等内部术语 * 设计稿暂定文字，比如“X天后”“须PM确认”