解答提问：多产品间的融合与产品结构

我是做设计的，近两年一直在关注用户体验方面的东西，今年开始接触产品开发方面的东西，想往产品经理这方面发展。 最近有一问题一直困扰着我，想向您请教一下。 目前我们网站的整个产品都很混乱，相互之间的关系很独立，没有一个整体的结构，我想做一个网站产品结构图，但一直不知道该从哪个角度来组织。我这前看过你的“以话题为主旨的社区产品结构”的文章，当中的逻辑，用户与产品间的交互组织的非常好，但你这个是针对社区这一单一产品的结构。如果是多个产品与用户之间的交互，该以哪个角度来组织？我看到你那篇是以一个产品（内容为线索）与用户（以人为线索）介绍的，多个产品是不是要分开来组织？但多个产品中有很多东西是共用的，比如评论、收藏、分享这些，真是无从下手。 我们公司目前的产品有：网上劳务、圈子（开发中）、论坛、资讯、企业小站、中劳通（收费服务），将来可能还会有对企业的口碑指数、博客、相册等产品的开发，多产品的组织交互该以产品角度来还是以用户角度来写？ ———————————————— 我的回复： 兄弟你好，感谢你参与和对此地的信任！我也是摸索中前行，那就从现有的经验中分享一点认识给你。 1. 对网站还没有找到核心主业或产品需求还在快速增长和变化中的时候，我们不能急于想着尽快规划一个“网站产品结构图”。而是将产品根据当前的运营重点依次列出个梯度。根据梯度合理分配投入精力，在一个大的产品周期内对各个梯度的产品单独做规划处理。梯度最高的产品应该是投入精力最大，考虑最细致周密，产品概念名词最易理解与使用，程序及服务器性能最可靠的。梯度较低的一些探索性产品则是围绕梯度高的产品独立开发、运作一段时间，待应用和设计成熟了再增补到核心主业务当中，像Google等各大公司都有Lab实验室就是这样来运作的。若不成熟的产品应用直接就挂到了梯度最高的主业务里，直接会影响产品在用户使用时的可靠性。很多时候都不是用户真的需要那些新增的功能，而频繁的产品变化及性能的不可靠性让用户放弃你的主业务。 2.关于多个产品与用户之间的关系：用户的基本属性要一直保持统一的，如：ID、密码、姓名、生日、所在地...等，至于在各个产品中需要额外增加的“属性”和各个产品的功能“设置”则是在各个产品中去完成。在设计登录、注册时就按统一项里包含的内容去让用户完成注册。待统一的ID，用户已经获得之后，点“下一步”时再去让用户尽一步完善在该产品中需要完善的资料。不可每个产品都单独设计登录或注册，这样当各产品用户属性不一致时，各产品间用户信息的同步将是困难的事。简单的说就是：区分清楚哪些是统一共有的用户属性，哪些是高级的附加属性。登录及注册部分用统一共有的属性去处理。高级的属性和设置在各产品中完成。 3.关于多个产品中共用的东西：你举了“评论”、“收藏”、“分享”，如果这些都有单独的用户管理入口。你需要有一个像Google一样的“个人中心” https://www.google.com/accounts/ManageAccount ，将用户开通的产品与服务列在一起，可以进入管理或设置。多产品共用的功能，如“资讯”使用了“评论”功能，只是从各个不同的产品向“评论”产品传递了数据。各个产品的设计还是在各个产品里完成。“评论”在各个产品前台的外观可以有不同。但若你的“评论”有的需要“评星”有的不需要“评星”。要么你把这两个评论分开单独做，要么在配置项里让“评星”根据应用是可开关的。 4.补充一点关于上边提到的产品概念名词的认识：产品根据需求而设计，当需求范围已经明确的时候，你就要尽量从需求中抽化出你将要确定的产品名词。服务范围没有扩大，产品名词越少用户理解和熟悉起来越快。将复杂的应用简单化说的就是这个意思。比如你列举的公司目前的产品有：网上劳务、圈子（开发中）、论坛、资讯、企业小站、中劳通（收费服务），将来还有博客……等。实际我们分析圈子、论坛、博客甚至包括资讯都可以算是即有重复又有区别的社区型产品，而看你的产品线“社区”只是你实现目确中必要的一部分，你并不是只有社区，那为什么不化繁从简的将它们统一归入“社区”中呢？而这样你们网站就大致分成了四大块：网上劳务（人才招聘）、社区（社区+资讯）、企业小站（企业博客+电子商务）、中劳通（高级收费服务）。这样在划分梯度的时候，优先发展哪些业务就比较清楚了。