IOGraph的记录鼠标指针的移动是用户行为分析中的一种，用户研究中，通常通过访谈、问卷、实际操作观察这三个方式确定网站的可用性。而研究鼠标轨迹和点击热区则是分析用户行为的一种很好的方式。当用户的鼠标轨迹和点击热区配合眼动议一起使用，并结合相关行为和时间的记录是，就可以提供最完整的页面可用性分析报告，从而支持需求分析及产品设计。

不过，这是理想化的状态，IOGraph目前只能针对用户鼠标在屏幕上的轨迹和点击进行记录，还远远达不到我们的要求。但对于一款仅有400多KB大小的IOGraph而言，还需要苛求什么呢？

作为有史以来占硬盘最小的用户行为分析工具，IOGraph还可以设置是否进行鼠标点击统计、背景实时显示以及多显示器的支持。并且可以随时暂定和恢复使用。它工作3小时后占用的内存仅相当于多开了一个QQ。最后你可以吧IOGraph记录的一切生成一张.PIN格式的图片以供分析使用。下面是我1小时的点击轨迹和2小时的无点击轨迹：

上午1小时写产品使用文档时IOGraph鼠标停留、点击、轨迹，中间的鼠标停留较多因为在打字

下午2小时杂事的IOGraph鼠标轨迹，上方密集处为Firefox页签切换，你能看出返回和关闭么？

使用IOGraph类的工具分析用户行为是专业化细分的结果，优秀的用户体验固然重要，但不等于用户体验就是一切。好的产品能带给用户更多的价值，而用户就能容忍更多用户体验的不足，因此这些研究更适用于大中型互联网和软件企业在红海中树立标杆，在蓝海中拼搏的兄弟还是先做好产品管理，把精力用在产品价值上吧。

至于IOGraph，作为艺术品做幅画挂在墙上也不错-_-

>>猛击这里免费下载官方提供的鼠标轨迹记录软件IOGraph<<

相关日志

• 关于互联网产品管理与产品设计 (4)
• 需求调研与产品设计10条经验 (1)
• 软件/互联网产品设计流程 (11)
• 结项是产品的另一个起点 (0)
• 如何设定分类目录–我的目录是这样规划的 (0)

1.用80%的时间去研究需求，用20%的时间设计产品；

2.理解用户—>装成用户—>比用户还像用户—>改变你的用户；

3.高效使用产品设计工具会事 半功倍；

4.随时跟用户沟通，用户看到并认同了DEMO后需求变更的风险才开始降低；

5.随时跟技术沟 通，否则技术一句“不能实现”会否掉你N人/日的成果；

6.产品设计末期，你除了需要忙于修改产品，更重要的是对用户Say NO；

7.经常说：“这部分需求我们计划放在下一个版本中实现”；

8.重视的细节，不只是功能和界面，别忽略数据流转和容错；

9.技术只考虑“如何实现”，而你需要告诉他们“实现什么”；

10.需求评审时要散发出自己的气场，告诉所有人，这份需求文档是无懈可击的。

相关日志

• 关于互联网产品管理与产品设计 (4)
• 软件/互联网产品设计流程 (11)
• 需求变更-要效率还是要规矩？ (1)
• 用户行为分析软件IOGraph：记录你的鼠标轨迹和停留点击 (2)
• 环保万年历，一点也不环保 (0)

这本书以UML为载体，将面向对象的分析设计思路融入的建模过程中，从理论到实践，深入浅出，是一本不可多得的好书！

适用于软件设计师、架构师、程序员、产品经理、产品设计师……当然，其中的建模方法对其他行业的童鞋认识和分析事物也有所帮助。

站在产品经理的角度讲，这本书提出了需求分析的一种标准化方法，并介绍了建模工具Rational Rose的使用。用Visio画流程图，用Rational Rose建模做用例，用Axure设计交互原型，很好很强大的产品设计组合。

点击以上购买链接可以直接购买《Thinking in UML》，相信我，绝对值这个价！

最近太忙了，让博客休了个长假。在这期间付出了很多，也收获了很多，生活也有了新的憧憬，下周开始继续更新博客吧。

相关日志

• 需求调研与产品设计10条经验 (1)
• 需求变更-要效率还是要规矩？ (1)
• 软件/互联网产品设计流程 (11)
• 结项是产品的另一个起点 (0)
• 用户行为分析软件IOGraph：记录你的鼠标轨迹和停留点击 (2)

关于互联网产品管理和产品设计，曾一度有些迷茫。虽然一直沉淫于产品设计和用户体验，但确实也做了很多产品管理的相关工作，并且这部分“沟通”的时间所占自己工作的比重也在逐步加大。而除了互联网产品设计外，产品管理更是涉及到了软件/互联网企业经营的方方面面：

如图，需求端的沟通主要来自于销售和内容，技术段的沟通又涉及到了产品开发的相关方面。我本身是做销售起家转做产品的，因此对用户需求和用户体验非常敏感，但涉及到产品的具体实现上，又暴露出了技术基础不扎实的软肋。产品设计不用深入考虑技术开发，但在明确业务流程并设计产品外，也应该考虑到数据的流转甚至数据表的字段，而不是只设计出产品的骨架外壳，就将剩下的工作一脚踢给技术，否则会加大许多沟通成本，比如我现在连每天的午饭都在跟技术架构师一起吃…

去年拿下年度优秀员工并不是一件容易的事，但即便如此，我依然觉得自己欠缺的还很多。从用户研究到角色建模，从流程设计到产品架构，从交互设计到UI设计，从可用性分析到用户体验，甚至最基本的产品工具比如Axure、Visio都只是“办事儿”的程度，远没有达到精通，更谈不上什么核心竞争力了。低调做人，闷头做事，再给自己一年的时间学习，总结，希望年底时会发现，2010年，我在互联网产品领域又迈出了坚实的一步。

相关日志

• 需求调研与产品设计10条经验 (1)
• 软件/互联网产品设计流程 (11)
• 用户行为分析软件IOGraph：记录你的鼠标轨迹和停留点击 (2)
• 需求变更-要效率还是要规矩？ (1)
• 结项是产品的另一个起点 (0)

1.产品调研

产品的调研属于市场范畴，由市场部门负责。产品调研是为了提高产品决策质量，解决存在于产品设计及产品上线后销售中的问题而系统、客观的收集、分析市场综合情况的行为。所以与内部产品不同的是，外部产品调研需要撰写市场需求文档即MRD，只有符合公司战略和市场需求的产品，方可进入产品立项阶段。而内部产品调研由于不涉及市场环境，为了产品设计流程的敏捷和高效，不需要提交调研产出物。经过确认必要且可行的产品，可直接进入产品立项阶段。

2.产品立项与评审

产品立项是产品设计项目流程的起点，产出物主要为《产品立项说明书》。产品经理负责产品立项时的文档撰写以及项目时间和人力计划安排。产品立项后，直接进入立项评审流程。立项评审是对产品立项说明书和项目计划的综合评审。立项评审各节点的负责人需要填写《产品立项评审表》，评审通过时评审自动流入下一节点直至归档。立项评审通过后直接进入产品详细需求及设计阶段。

3.产品需求与DEMO设计

产品需求是项目流程的重要组成部分。主要由产品经理负责，对内部业务需求进行详细的调研分析。根据需求，产品经理需要设计业务流程以及构建产品框架，使产品能够满足业务方需求；同时与技术部门协同确保产品方案能够顺利实现。当产品需求明确后，需要设计产品线框图即DEMO展示，确保良好的可用性和用户体验。详细交互情况需要在产品需求说明书中注明。本阶段主要产出物为《产品需求说明书》，以及产品DEMO。应用工具主要为Visio、Axure等。当需求阶段结束后，进入需求评审流程。另外，需求变更一般是在设计阶段，用户的需求发生变化时进行的，当需求评审结束后进入开发阶段时的需求变更应该尽力避免。

4.需求评审

需求评审需要业务需求、产品、技术共同参与，由该项目产品经理对产品的需求说明书以及DEMO做详细汇报，并解答各方面疑问。参与的评审人员需要填写《产品需求评审表》，评审通过后项目自动流入UI设计流程。需求评审的结束是项目的里程碑。

5.UI设计与美术评审

UI设计主要是针对产品表现层的设计，包括框架、元素、界面、文字等等的标准化设计。与DEMO的线框图不同，经过UI设计后，经过确认产出物产品原型需要直接作为前端开发的标准。因此UI设计结束后，需要进行美术评审，征求公司领导和相关产品负责人对产品原型直观印象，直到最终原型确定进入前端开发流程。部分内部产品不涉及UI设计的，可直接进入技术开发。

6.技术开发及前端开发

通常情况下，技术开发在需求评审结束后即可开始介入。即根据产品需求文档和DEMO原型，开始架构产品底层，由架构师负责。随后展开源码撰写的技术段工作，主要由技术部门负责。当产品UI标准及美术交互原型完成后，根据底层开发情况，可以开展产品前端开发。部分网站产品如板块变更，不涉及底层开发部分的，可直接进行前端开发。

7.测试及上线

当开发完成时，由测试部门（测试部门在需求阶段即可参与项目）撰写用例并测试。新产品需要首先发布到测试平台使用测试，网站产品进行大范围改变时，需要上线测试版经过客户熟悉和认可后方可正式上线。

8.产品跟踪

产品上线结项后，产品经理开始对产品持续关注和跟踪。了解业务使用情况，同时针对产品使用过程中出现的问题进行修复；当业务需求变化时，及时对产品进行升级或进行二次开发。产品经理需要在产品的生命周期中持续跟进产品。

相关日志

• 关于互联网产品管理与产品设计 (4)
• 需求调研与产品设计10条经验 (1)
• 需求变更-要效率还是要规矩？ (1)
• 用户行为分析软件IOGraph：记录你的鼠标轨迹和停留点击 (2)
• 环保万年历，一点也不环保 (0)

chinapm 中汤圆将 PRD 的核心概括为

该文档中，侧重的是对产品产品功能和性能（即“产品需求”）的说明，相对于MRD中的同样内容，要更加详细，并进行量化。

而 PRD 中这个“详细”和“量化”究竟到什么程度，是产品管理者经常遇到的问题。一方面，如果 PRD 中的需求描述或用例说明没有具体到具体细节操作，一旦开发人员理解有误或不完整，则会对出现不断的变更或返工（通常，开发人员喜欢闷头开发）；另一方面，如果将 PRD 内容描述得过分细致，则又会出现很高的成本，何况百密一疏的情况也是非常多见的。如何解决这个问题呢？

《编写有效用例》一书中提到了描述事件流程的基本方法，不论具体的用例是由需求人员做，还是技术人员做，都是需要了解的。对于用例中的 include 部分一定要细致入微，而 refine 部分则可以分清优先级考虑。

include，表示你要在一个用例当中包含另一个用例，并且被包含的用例是必须的，如果缺少被包含用例，则主用例就不能完成。比方，在用户管理场景中，要删除一个用户，你必须先查询到该用户，然后再点击删除。那么查询用户用例就是删除用户用例的一个include用例。
refine，是指对一个用例更精细化的描述。精化过程不会改变原来用例要包含的内容，只是更加细致。比方，取钱是一个用例，在描述用例场景时，你会用核对帐号，效验密码等活动来描述取钱的场景。在概念分析时，你可以把核对帐号，效验密码等定义为用例来描述取钱的过程，这时核对帐号，效验密码这些用例就是取钱的一个精化。它们实际上描述的仍然是取钱这个过程，但是取钱在概念阶段被精化成了核对帐号，效验密码等粒度更小的用例，这此用例仍然需要描述用例场景，例如核对帐号的过程、效验密码的过程等。
这些精化出来的用例向上要能够满足取钱用例场景的需要，向下则要更进一步能接近系统分析所需要的粒度。
同样的道理，如果需要，核对帐号，效验密码等用例在系统分析阶段还可以再次精化。但是它们虽然改变了名字，所描述的内容也从业务描述精化到了系统交互，但描述的仍然是取钱这一个业务。

当然，最重要得依旧是团队合作。在项目运行中，可能发生任何事情，但只要大家做好沟通，没有什么问题是不能被解决的。coffeewoo 中有篇关于这方面的解答非常经典，我就不班门弄斧了。临近春节，快递都放假了，不然也想尽快拜读一下他的大作《大象–Thinking in UML》。

相关日志

• 需求调研与产品设计10条经验 (1)
• 需求变更-要效率还是要规矩？ (1)
• 软件/互联网产品设计流程 (11)
• 环保万年历，一点也不环保 (0)
• 关于互联网产品管理与产品设计 (4)

如何对需求变更做科学的规划和控制？在做好需求变更管理的前提下，分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时，应该如何处理呢？特别是一些在需求中非常重要，但从技术上很好实现的需求变更时，是否还要走正规的需求变更流程？要效率还是要规矩，就成了许多产品经理心头的疑问。

首先，需要确定：是否真的需要走需求变更流程？灵活点说，需求是变了，但走不走这个流程是另一码事。如果项目几乎结项了，这时的需求变更就像百米赛跑后，裁判说这个跑道不标准，少跑了一米要重新跑一样；一鼓作气后，项目团队都疲惫不堪时，再次击鼓的效果可想而知。其实针对这时需求的变化，特别是技术上很好处理的问题，直接在结项后作为升级内容即可；毕竟版本得改动可小可大，小的版本变更从流程上讲要比需求变更简单的多；

其次，还有一个偏方，是我最近经历的项目变更得解决方案，即将这个需求分解放在其他相关项目中完成。在项目日程已经排满，并且项目间有一定相关性时，这不失为一种好办法。如果项目是迭代设计的，那么采用这种办法再合适不过了；

最后，当非变更不可时，如果没有针对不同变更得不同流程得话，唯一要做得就是做好前后沟通了。在有正规流程时，走正规流程是必须的，也只有这样，项目才能真正可以控制。如果对流程不满，除非能够很快吧流程修改或完善了，否则一步一步做吧。所谓得追求效率而抛弃规矩，是对项目不负责任的原则性问题。

需求变更就像误差，可以控制，但又无可避免；但是因为前期工作没有到位而引起了需求变更，就太不应该了，错误是不应该出现的。出现需求变更时，先不忙着救火，而是冷静下来先考虑问题产生得原因，比做救火员要有意义的多。后面会详细讨论这个问题。

相关日志

• 软件/互联网产品设计流程 (11)
• 需求调研与产品设计10条经验 (1)
• 结项是产品的另一个起点 (0)
• 环保万年历，一点也不环保 (0)
• 关于互联网产品管理与产品设计 (4)

通常，一个产品项目完整的周期包括前期调研、立项、需求文档、开发、测试、部署等。其中，用户、销售、市场可能需要参与前期的调研和需求；开发到部署主要由技术部门负责；而产品经理负责整个产品项目的周期。虽然结项是这个周期的结束，但实际上项目的结项也是产品另一个周期的起点。

1、试用期-完善产品
试用期对绝大多数新产品来说都是必须的。产品本身是为需求而设计开发，最终还要回归到用户中去检验这种需求是否被满足。特别是对于技术主导的网络、软件等IT产品而言，试用期可以很好的检验这种新技术的价值；而没有试用期的产品是危险的产品，就像新研发的药物没用经过活体实验及持续不断的跟踪观察一样。
通常，试用期阶段的产品能反馈给产品经理绝大多数的 BUG 或需要再次完善的地方，如果持续关注和改进，产品本身也会不断完善，直到被用户认可。一般这个周期是三个月。

2、应用期-改进产品
在应用期前，产品应该已经能够满足用户的基本需求。其中，除了对产品正常的维护外，最需要关注的就是用户体验。在产品开发周期中，如果在用户体验方面已经足够关注，这里应该能节省绝大多数的时间，但这并不意味着你不需要对用户体验在做关注了，因为产品团队并非用户本身，真理也需要实践的检验，何况是你的产品？当然，如果这个产品在开发周期中从未关注过用户体验，那么相信这个产品已经被抱怨淹没了。你的产品是以用户为中心的吗？能用-有用-易用-好用……改进有很长的路要走。

3、升级-让用户知道你在进步
你的产品不是真金白银这种硬通货，在竞争如此激烈的今天，一成不变的产品再完美，也会转眼成为昨日黄花，时刻保持危机感，定时或不定时升级你的产品，哪怕仅仅像新款牙膏只是将牙膏口开得大了点这样的升级，也会使你的用户感到，你非常重视他们，这很可能意味着忠诚度的提高。

以上是最近做的两个项目下来的切身感受，一点浅见，适用于互联网产品以及软件产品多些，有不完善的地方，还望大家指教。

相关日志

• 需求变更-要效率还是要规矩？ (1)
• 用户行为分析软件IOGraph：记录你的鼠标轨迹和停留点击 (2)
• 关于互联网产品管理与产品设计 (4)
• 需求调研与产品设计10条经验 (1)
• 软件/互联网产品设计流程 (11)

那么，究竟什么是产品呢？早前我的博客中，有部分提到过对产品简单的认识，实际上，不同的行业中有不同的定义，但我们还是可以简单得概括一下：

产品的狭义概念：被生产出的物品；

这是产品的原始概念，即人们通过劳动生产制造出来的物品。

产品的广义概念：可以满足人们需求的载体；

产品的概念随着经济和市场的发展而被扩大了，首先产品本身可能并非是由生产制造而来的，比如天然宝石、原煤等（未被开发的自然资源并不能算是产品，虽然这些资源本身能够满足人们的需求，但也要等它们真正被发现和挖掘出后才有交换价值）；其次，产品不一定是物品，也可能是某种服务，甚至包含物质实体在内的一体化解决方案；最后，产品必须能够满足人们的某种或多种需求，比如“我们需要人体工学的键盘系统”；

有人把产品理解为商品，其实是不确切的。产品和商品的区别在于，商品是用来交换的产品，商品的生产是为了交换，而当一种产品经过交换后进入使用过程后，就不能再称之为商品了；当然，如果产品又产生了二次交换，那么在这段时间能，它又能被称之为商品了。

需要注意的是：所有的产品都是具有使用价值的，这是产品的自然属性；一旦产品失去了使用价值，就成为了废品。这一点非常重要，因为产品的使用价值越高，则越能够满足人们的需求，那么就会给你带来巨大的商机。换句话说：如果你的产品能够很好的满足市场需求，那么你的产品就是成功的产品，它可能会为你带来滚滚利润！

到这里，相信你不会再为繁琐的概念解释而无精打采了，可惜，如何通过合理的产品策略赚钱是以后要讨论的问题；本篇主要讨论什么是产品，以及产品的相关注意事项，希望这篇“什么是产品”能满足需要她的读者。

相关日志

• 环保万年历，一点也不环保 (0)
• 需求调研与产品设计10条经验 (1)
• 需求变更-要效率还是要规矩？ (1)
• 软件/互联网产品设计流程 (11)
• 关于互联网产品管理与产品设计 (4)