社区产品结构与设计.pptVIP

尹广磊的经验分享 沟通问题的普遍性 Axure RP的使用 社区产品结构与设计 2009-5-9 第一页，共十六页。 沟通问题的普遍性 图形反映人脑思维方式的不同 普通用户、网站编辑、运营人员 网站产品设计人员 网站技术开发人员 第二页，共十六页。 沟通问题的普遍性 字面理解“沟”、“通”： 有了衔接规则（沟），事情就通顺了。 在项目中沟通的标志在于建立起了不同分工人员之后相互协作的规则，而非是我过去跟他们“说话”了或以我的职位我摆平了某些人或事。 建立规则的目的就是同样在避免曲解和误差的情况下尽量减少不必要的沟通。如果你是一个项目Leader,团队成员每天还是要通过说很多的话或是争论来完成工作，那么不是谁的沟通能力有问题，而是你给团队的规则没有建立起来。 建立或主张沟通规则的人需要对不同分工人员的专业有一定的专业认识。 第三页，共十六页。 沟通问题的普遍性 沟通要认清自己所能指导的范围 对待自己职责与专业内的要坚持，可以通过理论和举证来获得理解；对待他人工作成果或超出自己专业能力外的要时刻注意仅仅发表自己的建议权。 以下是超出专业外评价别人的表现： 运营人员让他对这一阶段的运营情况写一个运营报告写不出来，但他对产品的规划设计却常常振振有词； 产品设计人员对信息架构与流程设计拿不出好的方案，但却对UI设计人员的配色问题抓住不放； 开发经理对如何提高当前的技术储备表现的情绪怠慢，但却对细节功能要求的必要性表现的情绪高亢。 第四页，共十六页。 沟通问题的普遍性 沟通需要交付物的必要性 从运营需求——产品规划——UI设计——程序开发——测试上线都需要在过程中有交付物作为沟通的基础。 　运营的各种要求、建议都需要有邮件描述作记录，这样才能在多条意见中划分梯度、优先排序且做到不会有问题遗漏。如果是各种口头意见，你一言我一语，最终只会让你的设计与运营人员一起陷入众口难调的沟通僵局。 产品设计人员的设计方案也要包括总体的项目说明，整体结构图、流程图、原型界面、原型上的功能注释等等，避免因为自己的文档粗糙而让开发人员在过程中太多依靠想像去完成功能。 第五页，共十六页。 当团队技术实现水平确实有限时，请产品设计人员认真听取和了解当前团队的技术实现能力，然后根据实际情况重新调整产品的规划要求和设计。 第六页，共十六页。 Axure RP的使用 引入原型的概念 快速且低成本地获得反馈； 在多种可能中对比试验； 轻松修改或者放弃设计。 Axure RP就是这样一款快速实现、准确表达、带有交互效果且易于上手的原型设计利器。 第七页，共十六页。 在内网建立一个这样的原型文档列表，以便项目成员查看。 第八页，共十六页。 在每一个文档首页写上文档说明，包括版本号、完成的部分、名词注释、较上一版更新。 第九页，共十六页。 社区产品架构与设计 第十页，共十六页。 社区产品架构与设计 身份 允许用户在自己的ID身上丰富他需要的各种属性，可以在社区中通过兴趣、爱好、特征等快速定位到自己可能感兴趣的人。 分享 简单说是分享，实际上用户是记录并选择性分享。建议将用户自己建立的分类作为内容管理的第一要素，而把按类型（文章、相册、视频等）、按标签、按日历等作为次一级的管理要素。 第十一页，共十六页。 社区产品架构与设计 交流 对人的交流：通常指短消息、站内信、小纸条等功能。建议以会话方式呈现交流的内容。不建议像处理邮件那样分收件箱、发件箱，发一句短消息还需要填写标题。 　对内容的交流：通常指对用户分享内容的评论。不同的内容有不同的评论要求。有的简单评论即可，有的需要高级回复，有的需要把设为答案的优先显示，有的需要区分好评坏评等。详细建议见完整指导书的举例。 第十二页，共十六页。