主办
赞助
媒体支持
互联网／软件产品规划设计应用专家论坛
200905
10
B e i
j i n
g
S e
m
i n a
r
-2-
互联网/软件产品团队中，产品经理是为产品整体的商业需求而负责的，而交互设计人员则需要在此基础上，考虑如何实现并最大化保障良好的用户体验。双方之间因为职责不同，对待产品设计也有不同的看法。产品经理会担心交互设计师是否真正理解他的需求，而交互设计师则会质疑产品经理所谓商业需求的合理性。建立有效的沟通模式，变成了产品经理与交互设计师之间不得不面对的问题。
为此，DDF.UPA 中国与悠识公司(UserXper) 携手合作，共同推出主题为“互联网／软件产品规划设计应用”的专家论坛。
邀请多位专业产品经理作为主讲人，分享互联网／软件产品经理的工作与心得，如何才能成为优秀的产品经理，在工作过程中，采取怎样的方式才能与研发与设计人员有效的沟通，开发出既能满足商业需求又能保证良好用户体验的设计。
互联网／软件产品规划设计应用专家论坛
200905
10
B e i
j i n
g
S e
m
i n a
r
尹广磊的经验分享
1.
个人介绍
2.社区产品架构与设计
3.沟通问题的普遍性
4.
Axure RP 的使用
2009-5-9
发布：www.WebPPD.com
200905
10
B e i
j i n
g
S e
m
i n a
r
个人介绍
l
尹广磊
主要从事社区产品的研究、规划、设计；发表有《社区产品架构与设计意见指导书》；
擅长从需求中划分有梯度、分主次的产品结构设计；
善于分阶段实现产品的整体规划，以满足用户需求、突显特色、实用先行的原则在迭代开发中完善产品服务；
追求用户在操作流程中的简便、快捷、有效，不提倡单一页面的过分布局与内容堆积；
精通使用快速原型工具Axure RP 制作交互性良好的产品原型，并自己创办有Axure RP 答疑社区；www.axure.org
主张“我是什么，我就是什么，我强调我就是什么”的专注做事态度。
长期研究中外知名网站的产品结构、交互体验、项目需求与前景分析等。
就职过的公司Csdn ，Yaolan.com 。
200905
10
B e i
j i n
g
S e
m
i n a
r
社区产品架构与设计
l
社区产品要素
下面简要介绍一下对各要素的认识。
详细完整的指导书到下面地址下载：
http://www.webppd.com/t hread-32-1-1.html
200905
10
B e i
j i n
g
S e
m
i n a
r
社区产品架构与设计
l
身份
允许用户在自己的ID 身上丰富他需要的各种属性，可以在社区中通过兴趣、爱好、特征等快速定位到自己可能感兴趣的人。
l
分享
简单说是分享，实际上用户是记录并选择性分享。建议将用户自己建立的分类作为内容管理的第一要素，而把按类型（文章、相册、视频等）、按标签、按日历等作为次一级的管理要素。
200905
10
B e i
j i n
g
S e
m
i n a
r
社区产品架构与设计
l
交流
对人的交流：通常指短消息、站内信、小纸条等功能。建议以会话方式呈现交流的内容。不建议像处理邮件那样分收件箱、发件箱，发一句短消息还需要填写标题。
对内容的交流：通常指对用户分享内容的评论。不同的内容有不同的评论要求。有的简单评论即可，有的需要高级回复，有的需要把设为答案的优先显示，有的需要区分好评坏评等。详细建议见完整指导书的举例。
200905
10
B e i
j i n
g
S e
m
i n a
r
社区产品架构与设计
l
关系
社区中人与人之间建议使用相对松散自由关系模式，而且双向确认的好友模式。某个用户可以通过收藏其他用户时进一步设置是否要关注此人的动态，是否要在自己主页显示该人的链接等来建立联系。
l
小组
以自己为中心的小组：通过给自己收藏的人设置分组来关注这些组成员的动态。如我的同学、我的同行等。
以话题、地区建立的群组：如HitFM 音乐交流等，建议通过各种手段控制进入群组的内容为主，弱化对群组中成员的控制。
200905
10
B e i
j i n
g
S e
m
i n a
r
社区产品架构与设计
l
名誉
建议将每个用户在社区中受到的“关注度”作为反映用户名誉的首要指标。（如，该用户被358人设为关注）
该关注度反映了这些人对该用户未来更新内容的一种认可与期待。另外还可以通过人工授予勋章、接受其他用户的留言评价等侧面反映该用户在社区中的名誉。
l
状态
指用户的状态签名、微博客、在线状态等。在线状态涉及一些隐私内容，别忘了允许用户隐身或关闭在线状态功能。
200905
10
B e i
j i n
g
S e
m
i n a
r
沟通问题的普遍性
l
图形反映人脑思维方式的不
同
普通用户、网站编辑、运营人员
网站产品设计人员
网站技术开发人员
200905
10
B e i
j i n
g
S e
m
i n a
r
沟通问题的普遍性
l
字面理解“沟”、“通”：
有了衔接规则（沟），事情就通顺了。
在项目中沟通的标志在于建立起了不同分工人员之后相互协作的规则，而非是我过去跟他们“说话”了或以我的职位我摆平了某些人或事。
建立规则的目的就是同样在避免曲解和误差的情况下尽量减少不必要的沟通。如果你是一个项目Leader,团队成员每天还是要通过说很多的话或是争论来完成工作，那么不是谁的沟通能力有问题，而是你给团队的规则没有建立起来。
建立或主张沟通规则的人需要对不同分工人员的专业有一定的专业认识。
200905
10
B e i
j i n
g
S e
m
i n a
r
沟通问题的普遍性
l
沟通要认清自己所能指导的范围
对待自己职责与专业内的要坚持，可以通过理论和举证来获得理解；对待他人工作成果或超出自己专业能力外的要时刻注意仅仅发表自己的建议权。以下是超出专业外评价别人的表现：
运营人员让他对这一阶段的运营情况写一个运营报告写不出来，但他对产品的规划设计却常常振振有词；
产品设计人员对信息架构与流程设计拿不出好的方案，但却对UI 设计人员的配色问题抓住不放；
开发经理对如何提高当前的技术储备表现的情绪怠慢，但却对细节功能要求的必要性表现的情绪高亢。
200905
10
B e i
j i n
g
S e
m
i n a
r
沟通问题的普遍性
l
沟通需要交付物的必要性
从运营需求——产品规划——UI 设计——程序开发——测试上线都需要在过程中有交付物作为沟通的基础。运营的各种要求、建议都需要有邮件描述作记录，这样才能在多条意见中划分梯度、优先排序且做到不会有问题遗漏。如果是各种口头意见，你一言我一语，最终只会让你的设计与运营人员一起陷入众口难调的沟通僵局。
产品设计人员的设计方案也要包括总体的项目说明，整体结构图、流程图、原型界面、原型上的功能注释等等，避免因为自己的文档粗糙而让开发人员在过程中太多依靠想像去完成功能。
200905
10
B e i
j i n
g
S e
m
i n a
r
当团队技术实现水平确实有限时，请产品设计人员认真听取和了解当前团队的技术实现能力，然后根据实际情况重新调整产品的规划要求和设计。
200905
10
B e i
j i n
g
S e
m
i n a
r
Axure RP 的使用
l
引入原型的概念
快速且低成本地获得反馈；在多种可能中对比试验；轻松修改或者放弃设计。
Axure RP 就是这样一款快速实现、准确表达、带有交互效果且易于上手的原型设计利器。
讨论Web 产品原型设计http://www.axure.org
200905
10
B e i
j i n
g
S e
m
i n a
r
在内网建立一个这样的原型文档列表，以便项目成员查看。
200905
10
B e i
j i n
g
S e
m
i n a
r
在每一个文档首页写上文档说明，包括版本号、完成的部分、名词注释、较上一版更新。
200905
10
B e i
j i n
g
S e
m
i n a
r
结束
l
感谢各位！l
更多
交流：
200905
10
B e i
j i n
g
S e
m
i n a
r
「悠识」是一家专注于「网站用户体验(Web User Experience)」相关服务的专业公司。公司名称简称「悠识」是英文User 的谐音。我们提供三种主要的服务：分别是Axure RP 快速原型设计软件，网站策划培训及网站策划项目。http://cn.userxper.com
「DDF.UPA 中国」是中国本土的第一个非盈利性可用性组织，成立于2004年。这是为我们中国那些活跃在产品分析，设计，实现，和评估等领域内，旨在为为人类创造更高可用性的产品的人们提供一个专业的交流和学习平台。
http://www.upachina.org/
悠识数字顾问有限公司
UserXper Digital Consulting Co., Ltd.关于UPA 中国与悠识尹广磊 / 社区产品架构与设计
互联网／软件产品规划设计应用专家论坛 20090510 B e i j i n g S e m i n a r下载本文
