## 产品设计体会(二八)——细节之文案v
这 次来谈一下很细节的内容——文案,这里不是指网站里大段文字的编辑工作,而是指产品中随处可见的文字。自己的体会:因为文案问题很隐蔽,所以在各个产品中 都普遍存在,虽说不会对产品功能造成太大的伤害,但是过多的文案问题会使得产品整体感觉降一个档次。个人把文案问题分为三个级别。
低级阶段:错别字,病句,错误标点。比如常见的错别字:登录、登陆;语句逻辑关系混乱;中文与英文的标点混合不分等等。
中级阶段:用词统一,准确。比如“新建”、“新增”、“添加”其实说的都是一个意思——new, 用哪个本无所谓,但是在产品中的不统一会给人不专业的感觉;菜单用词的主谓、动宾结构不统一,经常看到同一个产品中同时出现“系统配置”、“管理帐户”等 菜单;又如“保存”、“确定”不分,前者是伴随信息的提交(一般有写数据库的动作),后者只是让用户肯定刚才的行为;再如“邮局”、“邮箱”、“邮件”等 较难辨析词的准确使用。
高级阶段:语言风格,产品气质。我们经常会发现,产品里同时存在由开发工程师随手写的成功/出错提示,和运营mm写的欢迎/促销信息,一边是“数据库错误/CorpID不能为空”这种过于的专业术语,另一边是“哦”、“啊”、“J”结尾的感情丰富的句子,这两种明显不同的风格同时出现在文案中,简直是让用户冰火两重天。所以在语言风格上由一个人最终来统一是很有必要的,这又是由商业目标决定的,比如myspace中国可以在用户登录后的欢迎词里写“好久没见到你了,最近是不是忙着拯救全人类去啦”,而这句要是在Oracle的财务系统里出现那简直让人崩溃。
另外,产品里的文案应该尽量少,用户很少会仔细去看的,如果一个功能需要配合100个字的说明,那我们就要考虑这个功能是不是做的有问题了。
中文系的同学毕业通常不好找工作,这个方向倒是提供了一个思路,不过国内有专门职位的公司实在太少(听说百度有),确实,虽然可做的事情很多,但就目前产业的现状来说,这样分工也太细了点。
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录