UCD 书友会 - 2010年8月杭州

今天参加了 UCD China 在杭州的聚会. 第一次参加, 我甚至不知道 UCD 是以用户为中心的设计的意思. 耐不住周末独宅在家, 也忍受不了夏日炎炎, 本想过来凑凑热闹, 却是受益匪浅.

UCD 书友会聚会挪了地点, 赶到新址时话题已经展开一段时间. 话题是: 互联网产品设计软件及工具, 听得我那个一头雾水. 这里说的工具应该是产品原型设计和交互设计采用的方法和工具. 如何通过设计提前暴露项目存在的问题? 如何在高保真原型和紧急产品发布间取得平衡? 运营会以什么身份介入项目, 此时产品经理在扮演什么角色? 话题由产品设计工具聊到产品设计流程...

大家对设计流程都有很多想法, 后面的话题都是围绕这个来分享的. 其中有几个议题我印象比较深.

允许提出意见, 可以选择采纳或拒绝. 但需要明确回复是否采纳, 如果拒绝需说明原因.

一个人很难将问题想得特别透彻, 所以每个议案都会获得很多建议和质疑. 可以采纳, 也可以拒绝, 但关键是给出明确答复. 我也吃过这方面的亏, 某人向我提出意见, 我婉言拒绝, 但他认为我认同了, 并因为后来没有被采用而感到不爽. 其实无所谓采纳和拒绝, 关键是达成共识. 会议室内可以斗个你死我活, 但室外应该是口径一致的.

产品性质决定开发流程, 可以由不同特性的人来完成.

白鸦用百度知道和百度 Hi 来说明短交互和长交互对产品经理的不同要求, 产品属性的差异对开发流程有不同的要求. 我在想另一个问题: 前端能做些什么? 一般来说, 产品经理可以获取的业务数据和商业 sense 都在前端之上, 我们很难与之竞争资源. 但我们可以做一些他们无法触及的需求和项目, 比如通过优化代码提升页面效率, 减少开发量, 提高安全性, 甚至一些新技术的尝试.

用头脑风暴的方式罗列所有能想到的产品特性, 再分几段实施, 并明确各阶段要做哪些点.

我曾参加过的一个 PM 培训也有提及这个话题, 有一个原则: 不对任何建议给予评论, 只需 listing them. 对于新产品尤其有效, 将需求细化, 明确现在要做些什么, 以后会做成什么样.

将产品设计放在产品线上, 而不是在设计部门 YY.

可能工作环境和工作内容不同, 这条对于我们不适用. 前端被划分在某条产品线上可以为项目开发提供资源保证, 也就是减少项目风险. 但是前端之间透明度不够, 不能清楚知道其他前端同学都在做些什么, 容易迷失在网站的某个区块上; 更有甚者, 小黑屋里的前端死跟一两个项目, 与 "页面仔" 无异. 我们需要的不是简单地拼砌页面, 而是全面了解网站, 站在全站的角度提供有效的技术支持.

如何跨区域, 甚至跨国部门交流.

有位女生描述了他们公司与海外团队的交流方式, 你来我往地多次交流, 最后未达成共识产品就做好了. 海外规范严谨, 国内追求快速解决, 最后结果是做出来的产品与设计有很大差异. 我在外包公司呆过, 对这种跨洋交流深有体会, 主要抓住两点:

1. 信息平衡, 你需要了解对方需要什么? 也就是他真正想要的是什么.
2. 提供有效的, 但尽量少的选择 (个人建议不要超过 3 个), 列出来让对方选择或者回答 Yes/No. 而不是反复的讨论.

还有很多观点我也不能一一列举... 以上是我零碎的一些想法, 今天很多问题没想好, 聚会上没插上话, 所以睡前花点时间记录一下.

今天 UCD 都围绕产品交互和设计展开的讨论, 我一前端遇到很多未曾听闻的术语, 表示压力很大. 但是嘛... 什么都了如指掌就没必要来了, 我会继续参加的, 这次你说我听, 下次你听我说.