产品设计体会(2006)外行眼中的技术分工

技术人员的全面介入,可以简单的看作以“需求分析初稿完成”为界,需求完成以后,派生出几个设计:交互设计、编码设计、数据库设计、测试设计,各自设计完成并执行以后,再部署发布。

具体的说一下,交互设计这块,主要是做软件和用户交互的工作,分工有从最直接的视觉设计师到使用感受上的用户体验师(交互设计师)再到偏代码实现的前端工程师

编码设计,比较偏概要设计的有软件架构师(比如整个系统的表结构设计),具体到coding的层面就是最常见的开发工程师,他们也会有分工,比如偏应用、偏底层数据库、专做搜索引擎,等等。

数据库设计,对于大用户量的应用特别重要,而阿里的用户数实在是比较多,所以相应的人员——DBA数据库管理员,在业界也确实是比较强的。

测试设计,就比较单纯了,相应的人员就是测试工程师,再细分一点就有功能、性能等等,一般来说性能测试会写一些自动执行的脚本,感觉更高科技一点。

上述各项工作完成之后,就要把各方面准备好的产出物拼在一起部署发布,那么就牵涉到硬件方面的管理,这就是SA系统管理员。对于BS应用,感觉部署方面的工作比传统CS软件简单一些。

对于软件项目的整个过程,需要在流程/规范上做控制以防止低级失误的发生,比如有时候需求人员会觉得某个功能的改动很小,就直接叫开发人员改而跳过测试人员,这样违反流程的行为对于复杂的系统是极其危险的。所以产生了SQA,也就是软件质量控制人员,这块和测试不一样。

对于多次不断发布的产品、多分支开发的产品,配置管理员SCM)就显得非常重要了,有他们的控制,就不会发生“某个bug在新代码发布之后重新出现”这样的低级失误,或者分支切来切去乱成一团的情况。像简单的用SVNCVS来管理文档、代码的更新、软件版本的变更、日构建/发布的控制,就是SCM的雏形。

产品设计体会(2005)细节设计之文案

这次来谈一个很细节的内容——文案,这里不是指网站里大段文字的编辑工作,而是指产品中随处可见的文字。自己的体会:因为文案问题很隐蔽,所以在各个产品中都普遍存在,虽说不会对产品功能造成太大的伤害,但是过多的文案问题会使得产品整体感觉降一个档次。个人把文案问题分为三个级别。

低级阶段:错别字,病句,错误标点。比如常见的错别字:登录、登陆;账户、帐户;语句逻辑关系混乱;中文与英文的标点混合不分等等。没啥好说的,要极力避免。

中级阶段:用词统一,准确。比如“新建”、“新增”、“添加”其实说的都是一个意思——new,用哪个本无所谓,但是在产品中的不统一会给人不专业的感觉;菜单用词的主谓、动宾结构不统一,经常看到同一个产品中同时出现主谓结构的“系统配置”和动宾结构的“管理帐户”等菜单;又如“保存”、“确定”不分,前者是伴随信息的提交(一般有写数据库的动作),后者只是让用户肯定刚才的行为;再如“邮局”、“邮箱”、“邮件”等较难辨析词的准确使用。

高级阶段:语言风格,产品气质。我们经常会发现,产品里同时存在由开发工程师随手写的成功/出错提示,和运营mm写的欢迎/促销信息,一边是“数据库错误/CorpID不能为空”这种过于的专业术语,另一边是“哦”、“啊”、“:)”结尾的感情丰富的句子,这两种明显不同的风格同时出现在文案中,简直是让用户冰火两重天。所以在语言风格上由一个人最终来统一是很有必要的,这又是由商业目标决定的,比如myspace中国可以在用户登录后的欢迎词里写“好久没见,你是不是忙着去拯救全人类?”,而这句要是在Oracle的财务系统里出现那简直让人崩溃。

另外,产品里的文案应该尽量少,用户很少会仔细去看的,如果一个功能需要配合100个字的说明,那我们就要考虑这个功能是不是做的有问题了。

中文系的同学毕业通常不好找工作,这个方向倒是提供了一个思路,不过国内有专门职位的公司实在太少(听说百度有),确实,虽然可做的事情很多,但就目前产业的现状来说,这样分工也确实太细了点。

产品设计体会(2004)产品概念设计

2007年秋,UCDChina上有一个专门的话题来讨论概念设计,并且提到了产出物:产品“概念图”。结合我们的产品周期来看,这个阶段应该是在BRD(商业需求文档)与PRD(产品需求文档)之间。

从思维导图和概念图的关系开始扯,用户需求采集上来,我们可以话一张思维导图,然后经过需求分析,又可以形成一张产品需求的思维导图,它更多的是一群PD一起BrainStorm的产物,围绕产品的商业目标,尽量发散出各种可能的功能,并简单的划分为几个模块。思维导图在乎的是发散,宁可错杀一千,不能漏一个,至于想到的这些点之间有什么联系,那个重要那个不重要,先不管。那么问题就来了,我们需要整理“思维导图”里这堆乱七八糟的东西。

我们现在的做法比较简单,就在思维导图的基础上勾勾画画,连几条线,打几个标记,注一些说明就算完成概念图了,并没有去重画一下整个产品的系统关系。当然形式并不重要,没有好坏只有合适不合适,我觉得概念图重点要表达出下面两点“关系”:

1.  产品与外界(上下级系统、并列系统)的关系,可能的话,勾勒出产业链结构;

2.  产品内模块间的关系,不用涉及数据流等细节,我比较看重描述清楚不同actor在系统里的身份,因为最近设计的几个产品,都包含了前台、代理商后台、系统后台等多级关系;

我很认同的出概念图的方式,是找个会议室,在白板上先画出自己的想法,然后大家一起讨论改进。这步做完,产品相当于有了基本的业务架构,同时这些功能点应该进入Feature List,并管理起来,下面我们要决定功能们的“性价比”了。

iamsujie补:手绘概念图很酷,大家可以试试,完了再拍下来!)

“概念设计”可能也会在PRD中出现,不用纠缠这个词的本身。不过这是下一个层次的,针对某个功能的“概念设计”了,会涉及更多的细节,比如功能的业务流程图,用户/系统/管理员之间的关系等。