社区产品结构与设计.ppt

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