Benking

我们是如何做产品的

一 01

Ben产品设计, 投资理财, 项目&管理 产品设计, 原型设计, 基金比较, 基金筛选, 用户调查, 竞争对手分析, 需求分析, 项目管理 No Comments

最近刚完成基金筛选器、基金比较，这两个小产品。但其实在我的构想中，她们俩是同一个产品一下的子功能（这个产品我称她为“选基平台”），只是由于时间、资源等因素，目前仅实现这两个功能。

由于“刚出炉”，放在手头还比较热，于是趁热用她来做一个例子，谈谈我们是如何做产品的。

1、思路思路

如何确定要做一个产品，理由可能是多种多样的，这里就不再详细叙述了，留在以后的篇幅中。而我们确定要做选基类产品是在年初定下来的，相关人员聚在一起讨论今年的KPI，这个时候就会定下来今年大致的产品发展思路。

到了具体要做的时候，就会想了，咱们的选基平台到底会实现什么样的功能？在设计之前，我通常会首先做几件事情：

• 用户调查：目前这是最弱的部分，仅收集与总结用户的反馈，看看这方面的需求情况；
• 竞争对手分析：这一步比较重要，我会把所有对手的类似产品都看一遍，找出他们的优缺点，该吸取的吸取，该抛弃的抛弃。当然也得结合自己的特色；
• 大量广泛的查阅：如果在你要做一个产品之前，对她的概念比较模糊或根本不知道应该怎么做，你应该大量、广泛的查阅。并适当的做记录，对以后的设计阶段会有帮助；

当然还有很多工作，如需求分析、可行性验证等。一边做这些准备工作，一边整理这些思路。准备工作做好后，产品构想大体就完成了：

这个时候，可以把大大小小的相关人员聚在一起，谈谈你的构思。大家会对的构思提出各种各样的建议与意见，如果顺利，差不多这样一次会议就确定了。

2、原型设计

大家对你的构思认可后，接下来基本上是真刀真枪的干活了。大一点的公司，通常是一组人一起做设计（这些人我们称为PM）。像我们这样的小公司，没实力请这么多人一起做，通常由内部人员兼任。

由于前期已经有了很好的构思，这个阶段基本上就是按照你的构思做设计，在设计的时候会考虑到很多问题，比如：

• 整体布局应该怎样：两栏、三栏，还是其他。通常在这个问题上会纠结很久，确定以后，接下来的事情就好办了；
• 如何布局页面元素：例如，如何合适的摆放大量的筛选条件，这成了这次设计的难点之一。当然最终还是解决了，具体解决的好与不好，需要看上线后的反馈；
• 以使用者的角度来思考：易用性的好坏实际上大多数取决于设计者所处的角度。我是从技术出身的，在设计的时候一些技术上的事情难免会左右我的想法。但我还是会尽力以用户的角度去思考如何设计；
• 商业价值思考：这一点也应该考虑。在一个初期版本中，也许不会有这些内容，但在设计阶段至少应该考虑一下，留一些口子；
• 结合推广的一些思路：对于初始版本的产品，通常这一步比较困难，记得我们在开产品设计PK会的时候，运营负责人就会想是不是应该加入一些有利于推广的内容在里面。但由于这样一个产品功能性太强，不便于在这个版本上实现，因此也暂时搁浅了，留在后期版本上实现；

整个原型设计阶段，可能都需要你全身心的投入进去，以至于达到“走火入魔”的状态最好（开玩笑的，呵呵）。最终完成原型设计：

+ 

接下来可以开展原型讨论会，这是比较“痛苦”的一个环节，大家会提出各种各样的需求与建议。你会根据这些建议进一步的思考是否或应该如何改善设计，并找时间再次组织讨论。

通常这类会议进行2～3次，具体最终什么时候能够敲定，就看你在做产品原型演示时的忽悠功底了。最后老板发言：“好，就这样做吧”，得到这样的信息后，说明你的产品原型设计阶段顺利完成，可以正式开工了。

3、项目排期与开发

这个阶段，你需要一个或多个Excel表格，或者Project文档，来分解出产品的Features。然后找到相关人员（通常为开发、测试与UI设计人员）一起开会，大家一起来评估时间。比如本文中的基金筛选器，我们就用一个project文件就足够了。

这个过程基本上是一个协调与驱动的过程，协调各种人员的配合，如开发、美工等。适当的给相关人员一些培训，让他们深入理解你的设计理念，这样才能更好的发挥他们的想象力，尤其是美工设计人员。

最终，美工会根据你的设计完成UI美化，开发人员会根据你的设计完成程序开发。这其中有一个度，也许你的想法还有很多，想实现更多更实用、更酷的功能与技巧。但需要把握一下时间与工作量，优先实现核心功能，锦上添花的功能可以安排的后期完成（如Alpha测试期、Beta 测试期）。

4、测试与上线

待开发完成，总得测试一下吧。对于网站而言，需不需要测试人员也是一个争论的焦点，同样在我们公司也有这样的问题，某些产品负责人认为根本不需要测试，有测试也不一定能帮你测试出Bug。

当然他们说的也有道理，毕竟我们网站的行业性比较强，是有点难上手。但产品开发完成总得还是要测试一下。

没有测试人员，怎么办呢？只能发动全公司人员一起测试了，虽然不能保证最终完全没有Bug，但好歹还是测试过。

最后，我们发出Beta版，正式和用户见面：

+

有兴趣的朋友，可以点击这里、那里看看效果。

我们为什么要改版

十二 14

Ben产品设计 产品设计, 改版, 用户体验, 需求管理, 需求采集 No Comments

前段时间收到用户的站内短信，内容是这样的：

为什么总是更换或升级？给我们的工作带来了很多的麻烦！！！

当天的确是服务器故障，导致部分用户访问受到影响。从短信内容中可以看出，用户已经忍了一段时间，实在忍无可忍，于是发短信向我们抱怨。

我们必须勇于承认错误与不足，看来是某个环节有问题，导致这样那样的问题，而原因可能是多种多样的。尤其是针对大用户量产品的改动，更要慎之又慎。

回到为什么要改版这个问题上来，如果单纯回答这个问题，不外乎有以下几点：

• 页面调整，为了更利于SEO；
• 为了提升用户体验；
• 为满足更多的用户需求，不断对功能点进行改进；
• 构架性调整，如将产品推向一个更高的层次；

总而言之，世界在发展，我们也得发展，改版是为了提供更好的服务。要不然怎么会有人说“政府工程是拉动中国经济的三驾马车之一”呢。

但是，有几个问题得首先想想，你新增的功能一定是用户想要的吗？或者大部分接受。是不是应该先考虑习惯性这个问题？你的用户群体有什么样的特点？

过去一年，我们对若干产品进行升级改版，不断的满足用户的需求，也得到了一些好评。但后来我们分析，其实有些得不偿失，新增的功能在一定程度上影响了一些老用户的使用。虽然这样情况不可避免，但如果影响的群体过大，可能就有问题了。

于是我们开始对提出抱怨的用户进行调查，接受调查的用户几乎都有同样的回答：“目前的功能已经够他们用了 or 习惯了”。我们也对比了竞争对手的同类产品。不客气的说，其中某些产品其实做的很烂，但还是有很多用户使用，而且这些用户不会因为你的用户体验好，功能多就转过来用你的。

通过分析这些的现象的背后，我们似乎可以得出一些结论。

• 需求：从需求的层面上说，目前的需求已经满足用户的需求，而且这些需求是刚性的。对于锦上添花的需求，用户貌似漠不关心。
• 用户：只要你满足了我的需要，而且这些都是我必须的（刚性的），就算你的UI做的再烂，我也不会轻易放弃使用你的产品。久而久之，用户已经习惯于你的产品。
• 既然用户已经“习惯了”你的产品，因此你对产品的任何改动，都会对用户产生影响。

那么，还要不要改版呢？还是那句话，由于这个世界在永不停息的发展，因此改版也要继续。但不是盲目的改版，而是要找准用户的真正想要的需求，且应满足绝大多数用户的需求，要摸清用户的习性与特点。做到有的放矢，应该就没问题了。

我们是如何作需求管理的

十一 11

Ben产品设计, 项目&管理 产品设计, 特性列表, 需求分析, 需求管理, 需求评审, 需求采集 No Comments

毫无疑问，需求管理在产品设计中占有非常重要的地位。那到底有多重要呢？回答这个问题之前要先反问自己，你为什么要做这个产品？而你可能有如下回答：

• 老板项目，不做也得做
• 我们觉得这个值得做，因为有很多人需要她
• 我们的用户对我们产品提出了更多的要求
• ……

就是说，因为有需求，所以我们才做这个产品，她是一切产品产生的源头。既然这么重要，对于需求的管理就显得更加重要了。首先来看一张图：

看上去东西挺多的，实际上可以把图分成三部分：

1、需求采集

需求采集包括需求收集与提交，需求收集的渠道可能很多，最直接的就是和用户交流，比如用户调查、意见征集、网站论坛、站内短信（实践证明，这是比较高效的收集用户需求的方式之一）等。

客服也是一个比较重要的渠道，如果你有时间，也可以自己去冒充客服人员。另外，某些需求也来源于团队、公司内部，比如用户数据分析衍生的需求，老板的直接需求等，总的来说，需求的途径可能有：用户、公司or团队内部、客服、市场等。

在提交需求时，需要记录好需求来源，原始需求人，原始需求，提交人，提交时间等。这个阶段，需求的状态应该是“待讨论”。

2、需求评审

在一定时期内，应该开需求评审会，参与人员可多可少，视需求、团队的情况而定。做需求评审时，参与人员可以对需求发表意见，大家一起讨论这个需求值不值得做，实现难度等。纳入评审的需求的状态一般会有如下变更：

• 接受：当然，这需要综合考虑这个需求能给我们带来什么样的价值，也要考虑实现这个需求的成本
• 暂缓：暂缓的需求可能由于此阶段还不适合实现，或者在资源分配上存在问题，又或者启动的条件尚不成熟
• 拒绝：拒绝的需求可能是一些和我们的目标价值相背离的需求

在需求的状态变更时，我们会记录下变更的原因，比如“暂缓”的需求，我们还应该记录下重启的条件。完成需求评审后，我们会对需求进行分析。

3、需求分析

为什么要进行需求分析，一个原始需求应该代表原始需求人内心的欲望，需求人只是向你提出他所需要的东西，需要达到的目的。而我们做需求分析就是要从这个原始欲望中挖掘出用户真正想要的东西，也许是一个功能，也许是一个产品。我们还应该考虑怎样实现这个需求才能满足大部分用户的需要，或者不影响大部分用户的使用等。

待需求分析完成，会产生一个或多个产品特性，这时需要把特性录入至特性列表，最后我们会实现需求，包括特性分析、设计、开发、测试、发布等。

这样，我们满足了用户的需求，并实现与需求对应的功能特性或产品，提供给用户使用，用户在使用产品时，可能又会产生新的需求，而我们又开始想办法满足这些新需求…..基本上就是从用户中来，到用户中去这样一个周而复始过程。

工具方面，想起以前团队培训时用过的一句话：什么是最佳项目管理工具，excel, excel, excel。个人认为，这些工作用Excel就可以搞定了。当然也有一些其他很好的工具，具体用什么，跟很多因素有关，比如个人偏好、文化、团队大小、环境、心情……总的来说，最适合自己的就是最好的。

可用性的前提条件

十一 08

Ben产品设计, 项目&管理 UCD, 产品设计, 以用户为中心, 可用性 2 Comments

额～我承认，可用性很重要，一个完全没有任何可用性的产品是没有必要发布的，因为它只会给用户增加烦恼，不能解决用户的问题。

因此，可用性就变得更加重要了，为了解决这个问题，某些公司专门成立了UCD部门，这些人专门干一些与用户相关的一系列事情（如上图），比如用户调查、访谈；用户行为、需求分析等。当然也直接参与产品设计，因为在以用户为中心的设计上他们最有发言权。

显然，成立这样一个部门或团队，需要大量的投入，需要成熟的企业文化与管理制度。

对于一些尚不成熟的中小企业来说，摆在他们面前的问题是生存问题，需要快速盈利。没有精力与金钱投入去解决可用性这个问题。于是在这些企业中，由于没人专职研究，也没人懂，就是说，大家言论自由，人人都可以谈可用性咯。

如果你是产品设计者，那你要小心了。因为人人都可以用可用性的眼光来批判你，大家可能群起而攻之。最后，妥协吧，OK，咱们推翻重新做吧。

也许，设计者的确设计的很烂，这是能接受的，咱们改进就是。但可怕的是，设计者往往不知道烂在哪里？导致改进的余地都没有。

要谈可用性吗，行，请给我资源吧。

我们还要不要支持IE6

十一 04

Ben产品设计, 其他&IT观察, 技术相关 IE6, 产品设计, 浏览器兼容, 用户体验 No Comments

最近在做一个产品：基金筛选器，为了有更好的用户体验，我们使用的脚本特别多，包括异步请求、拖拽、浮动层、大量的DOM控制等等。

在产品设计阶段给团队的要求中其中有几条是这样的：

• 要做到精细，注意其中的两个字：精和细
• 执行效率要高，速度要快
• 尽量让用户用更少操作做更多的事

要达到这些要求，我们不得不使用大量的脚本来控制，比如动态构建、添加与移除筛选条件、自动筛选结果并显示、快速保存自己的筛选方案等等。

这样做下来，测试初期细节方面的问题会非常多，尤其是浏览器兼容性方面。我大致看了一下，每一段特殊的脚本，我们都会做5中浏览器兼容测试（IE6、7、8，Firefox，Chrome），说实话，挺累的。

当然，大部分浏览器都是不用过分的去关照的，比如FF，Chrome，包括后来的IE8。但处理IE6这个问题上，着实要我们头痛。

因为IE6的脚本和W3C的标准出入太大，而且DOM的结构都不一样，所以我们不得不在上面花更多的时间。有时候忙活了半天，可能有些问题就是解决不了，这才是最头痛的。

比如，在处理筛选并自动显示结果（当条件改变，自动执行筛选并实时显示结果）这个Feature上，若结果记录数太多，IE6下的性能会非常差，对于这个问题，我们做了很多针对性的措施，最后还是不满意，于是我们不负责任的用下面的提示代替了结果列表：

这样做的确很不负责任，也算是一次大胆的尝试，因为我们IE6的用户群还是占很大一部分。但倘若不这样做，用户体验会更差。说不定还会砍掉一些更好的功能。

我们需要对用户负责，因此无论如何我们也要支持IE6；但从未来的发展趋势上来说，为了兼容IE6可能会使得我们放弃一些更先进的技术。

有时候在面对这样的取舍问题时，的确让人难以抉择。希望和有缘见到这篇文章的朋友一起讨论这个话题。

互联网产品管理流程思考

十 31

Ben产品设计, 项目&管理 KPI, 互联网, 产品经理, 产品设计, 产品运营, 管理流程 2 Comments

写这篇文章之前，心里纠结了很久。期间收集过不少资料，私下里向一些前辈咨询过此类事情，今天决定放出来，希望能收集更多的意见或建议。

说起产品运营，大家都会觉得这是一个非常重要的环节，就像在这篇文章里的观点：一个好的产品多半是运营出来的，这点我也很认同，尤其是在讲究效率的互联网类公司。但某些互联网公司的产品研发是这样一个流程：

==========正文分割一下，下面会出现很多A、B，这是代号==========

比如要做一个产品，首先由技术负责人（下称A同学）进行一些前期工作（如需求采集、分析、调查、产品构思等）；然后组织公司相关人员讨论需求、构思；确定下来后，A同学要开始原型设计，组织公司相关人员对原型进行讨论；原型确定后，找美工美化UI、开始分解工作量、项目排期，驱动开发完成；最后组织进行测试。完成测试后，A同学就告诉运营负责人（下称B同学），说这个产品做完了。B 同学拿过去看看并学习一下，做一些简单的推广广告，上线、推广。

可是，A同学和B同学是分属于不同的部门，有各自不同的KPI，意思就是说我得优先我的KPI，然后才能配合你。问题就出来了，A同学可以根据自己的KPI不断的开发出新产品或升级原有的产品，然后扔给B同学，由于各种不可抗拒的原因，B同学只能将这些新（升级）的产品以队列的形式排列在那里，不能立马上线。对于这个问题，小弟认为很严重。

另外，设计者是A同学，前期的所有工作都是A同学完成。由于B同学对前期的工作不了解，当然对产品的认识也不会很透彻，在运营推广上也许会出现问题，或者是不能根据产品的特性来运营，对产品来说，这也是一种不好的现象。

对于这个事情，前段时间和苏杰交流过，认为这种问题可以采用充分沟通的方式来解决，B应该充分的参与到A的前期工作中来；A也应该充分的参与到B的后期运营上来。这的确是一个好办法，只要沟通充分，我想问题就会慢慢化解。

但试想一下，如果把A和B这两个角色合并起来，会不会更好呢？合并后的角色就有点类似于互联网产品经理了，似乎也是比较好的一种做法。但话说回来，实行产品经理制也不是那么容易的，对于年轻中小型互联网公司来说，由于内部管理、企业文化、团队等的不成熟，也会给实行产品经理制带来不少的障碍，在执行力上可能会出现问题。

每当想到这些，自己只能阿Q一下：“嗯，也许对于2～3岁的公司，应该都是这样的一种情况，这是必不可少的过渡期，就像老师教我们的，社会主义社会是共产主义社会的必不可少的过渡期一样”。但我们是不是可以试图去尝试改进一下呢？

细心者作为，无细心者无作为

十 28

Ben生活体会 产品设计, 细心 2 Comments

4年前，我第一天上班时的情形是这样的：

自己的第一份工作，也是自己期望的职业，心情很好，迫不及待的想上班。在去公司的公交车上和同去的两位同学聊的很high，到地方后和同学们一起下车，见到了来接我们的HR。接着往公司走，刚走不远，突然发现少了什么东西。“完了，我的包忘在公交车上了”，这包可不能丢，里面有学生证、三方协议等。还好下车的地方离终点站不远，追过去拿了回来。回头HR给了我这样一句话：“丢三落四的，还来做软件工程师啊？”，那时候我就告诫自己，不要丢三落四的。

4年后，以为自己当初已经吸取教训，可今天的事情让我明白了，我还做的不够：

下班后，准备回家，到了车棚，发现自己的车不见了，找了一遍又一遍：没有，心想不会是丢了吧。摸了一下兜里，钥匙也不见了。心一慌，赶紧找到了大楼保安，保安见了我，笑容满面。我告诉他我的车不见了，他依然笑着和我对答如流，好像他感觉不到我的心急如焚，倒像是在有心调戏我，搞得让我有些不知所措。“你的钥匙呢？”，“本来在兜里的，刚才发现不见了。”，“车锁了吗？”，“车我是锁了的，这点我确定。”，“你车锁了的，别人怎么能偷走呢，钥匙是不是忘在车上了？”，“……”。其实我真搞不清楚到底是不是把钥匙忘在车上了。后来保安从抽屉里拿出了我的钥匙，告诉我车在哪里，并好心告诫我千万不要再把钥匙忘在车上。原来为了安全，保安把我的车挪了到了地下车库。

今天在这里做个记录，并再次告诫自己，做任何事情，都应该心思周密、精力集中。就好象我们做产品，尤其是互联网产品，往往一个小细节会让你丢失大量的用户，同样也可能让你抓住成千上万的用户。最后送自己一句话：细心者作为，无细心者无作为。

切忌轻易对大用户量产品动大手术

九 27

Ben产品设计 产品设计, 大产品设计, 改版, 用户体验 1 Comment

记得08年，我们对“我的基金”做了一次大手术，原因很简单，对于老版本，实在是看不下去了。大家都觉得页面很丑，且易用性、系统结构等都不是很好，因此大家伙一致认为要改版。

关于产品原型设计的一些想法

九 25

Ben产品设计 交互设计, 产品设计, 原型设计 No Comments

对于产品设计阶段的原型设计这个事情，我本人是非常看重的，而且原型做的越逼真越好（如果时间充裕的话）。对于到底是否要做的逼真一点（因为这样花的时间更多），这也是一个比较有争议的话题，可能每个人的观点都会不一样。比如有些朋友认为，不必花太多的心思在原型设计上，在纸上随便画画，然后交给美工人员设计美化，更甚者直接口述。

当然，纸笔是最直接的原型设计工具，对于一些比较简单的产品设计，也是可以直接这样做的。我自己在真正设计之前，首先会在草稿纸上用笔画画，然后再用绘图工具设计原型。之所以要做的逼真一点，目的在于便于沟通，因为你需要把你的想法告诉产品相关人员，如果采用口述或草图的形式，恐怕会出现沟通障碍。再者如果需要存档的话，口述或草图恐怕就不太合适了。

原型设计工具很多，主要看自己适合用什么样的工具。我自己用过一些，比如 Visio、MS Publisher、Axure Pro等，如果是简单且没有交互的东西，可以直接用Visio画画。如果是基于Web的产品，建议用 Microsoft Publisher 或 Axure Pro。对与交互比较复杂的产品，建议用 Axure Pro，用这个工具可以让你的原型设计的非常逼真，在开评审会的时候，可有利于沟通；在美工参与阶段，可让美工把握每个设计上的细节，可进一步避免返工。

如果你有一些开发基础，你甚至可以用某些开发环境做原型，比如 Dreamweaver、Visual Studio系列等。这样做出的原型，几乎可以作为一个半成品拿出来演示，当然这样做花的时间就更多了。不过在某些项目中，这样做还是值得的，比如你要去竞标某个项目，给客户演示等。

回顾一下去年做的一个IPTV产品

九 21

Ben产品设计 IPTV, 产品设计, 原型设计 No Comments

去年10月，数米同另一家专门做IPTV的公司一起给某地方电信开发一套IPTV产品，该产品包含基金以及股票投资理财服务，我们负责其中的基金部分，内容就不说了，凡是和基金相关的，都会做（除了交易）。

在业务上，我们是比较熟悉的，因此整个产品的设计自然就落在我们头上。我在这里回顾并整理一下进行IPTV设计需要注意的一些问题，给自己做个记录，同时看能不能给正在摸索的朋友给些帮助。

机顶盒部分我这里就不说了，自己本身也不是很懂。我只说说在设计上的一些约束以及需要注意的地方：

页面布局

页面大小一般是 640×526（宽×高），最好不要超过这个标准，大部分的机顶盒都认这个标准，如果想要你的产品保持通用性，应该采用这个标准。布局的形式可能是多种多样的，但建议给你的内容显示多留一点空间，毕竟可显示的内容不多。常用的形式有上中下，上面为菜单、下面可以放一个通栏，用来放一些“后退”、“帮助引导”（如按F1、F2是什么功能）等，中间是内容区域，这种布局方式可以把你的内容区域预留的足够大，如果你的产品是内容为主，我想这种布局形式应该是不错的，如下图：

另外还可以采用左右形式，采用这种形式的产品通常为娱乐类产品，如游戏、视频等。

字体、颜色

关于字体和颜色，由于绝大部分机顶盒支持的颜色不多（256色居多），因此在设计的时候，颜色建议都使用RGB标准色。字体用宋体就足够了，且应使用大字体（14pt较为合适），因为在电视上显示字体太小，会影响用户正常浏览。

脚本特效

尽量不要使用太多的脚本特效，机顶盒所支持的脚本版本较低，功能也较弱，所以尽量不要使用太多的效果。

其他

小数点是不能输入的；最好不要有让用户输入汉字的地方，能支持输入汉字的机顶盒很少；操作尽量简单，用遥控板不好操作，（在体验上，你可以把遥控板想象成手机，适当的yy一下。因此在设计的时候，你可以参考WAP产品的设计思路）；如果有数据表单，设计不宜过于复杂；