社区产品结构与设计.pptx

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