第五章 方法和多人协作.docVIP

Yahoo!的项目工作流程 找到一份重要参考资料，采访时间是2006年2月。 王小丹：主要网络产品设计工作流程是这样的： 网络产品设计：产品制作人写产品计划书，确定新产品或新功能的市场意义和经济效益，提交部门审批，同意后，确认需要设计的部分，和用户体验研究员(user researcher)，信息建构师(information architect)，视觉设计师(visual designer)、user interface designer，互动设计师(interaction designer)，web developer，工程师(engineer)一起讨论需要的支持，然后订出时间计划分工合作。一般是先由用户体验研究员作调查、分析后由信息建构师设计产品架构，然后由互动设计师作出互动流程，之后交给视觉设计师(visual designer)和user interface designer作出视觉设计。然后web developer把设计通过编写程序(html, dhtml, JavaScript)等等再现出来，最后交给工程师。做完后用户体验研究员需要做用户测试，QA(Quality assurance) 需要测验这一产品的每一步骤，确认产品的使用质量，如果有问题需要让工程师或相关人员解决。 HYPERLINK /article.jsp?code=200603100039 雅虎欧洲设计师王小丹访谈 总结起来就是： 产品制作人，写产品计划书。 用户体验研究员，作调查分析。 信息建构师，设计产品结构。 互动设计师，作出互动流程。 视觉设计师和用户界面设计师，作出页面视觉设计。 前台工程师，前台开发。 后台工程师，后台开发。 用户体验研究员，做用户测试确保质量。 应该算是一个比较完善成熟的流程了，信息建构(IA)和互动设计(ID)明显处于很重要的位置。 国内项目普遍流程就是“策划＋设计＋制作＋开发”，普遍忽略的是第2, 3, 4，或者说是其他某个流程附带完成，第6前台开发也是只存在于大型正规公司，或者说有普遍进一步完善的趋势。 至于UE, IA, ID如何进行，我觉得没有绝对固定的模式，根据项目实际情况，关键在于团队的默契。不是说国内从业者不知道如何进行，而是根本没有这个习惯，把项目环节细分一下，就很清楚各自职能了。这些流程的核心目的就是逐步保证产品质量，减少“前台开发”和“后台开发”的重复劳动。 就Yahoo这个流程来看，应该是针对大型的应用型产品项目。看看人家??“确认设计需求”时，就需要几乎所有项目环节参与者进行综合讨论，让人狂汗不已；定开发计划都是大家讨论进行，而不是单方面强制决定，多么人性化啊。 把用户体验整合进流程 两位朋友不约而同提出了两个观点： UE目前还处于探索阶段。 公司貌似很重视UE，其实还需要多教育。 关于工作方式和团队协作，几点个人看法： 1. 把职责分散给设计师和产品经理，而不建议由专职UE团队来把控产品质量，第一责任太大，第二职权失衡，第三增加管理成本，第四降低工作效率。 2. 分工协作不应该横向，而是纵向，避免不同环节交叉沟通，同事之间良好合作的基础是信任。但理想状态有个前提，同一个产品Team内同事的水准和经验差不多，也就是强者恒强的道理。 3. 除了方法、流程的规范，交付物、过程文档也应该有相应的准则，我倒觉得这些才是落实问题的关键，看似简单，协调起来可不是那么容易。 4. 思想远比方法重要，如果你不是天才，也没有足够的领悟，掌握再多的方法也难见提高，方法只能加快智者前进的步伐。 5. 对于规范，主要是理解，而不是遵守，如果你能总结出更好的规范，要么说明以前的东西不合格，要么说明你的能力已经超越了公司前辈。 6. 谷歌的工程师说UCD，雅虎的设计师说UCD，百度的产品经理说UCD。谁更能代表用户，其实主要看谁在公司说了算。 大部分失败案例堪比当年国民党，天才的决策，蠢才的执行，最冤枉的却是下边士兵。 信息架构的流程引入 对内对外讨论甚至争论了无数次，分享几条不成熟看法： 交互能解决一个个功能，但用户的需求是一串串功能，这是我理解为什么交互算过得去，但网站还是那么烂的原因，行为上user friendly远不能满足用户的底层认知需求。 能够拿得出东西，明确用户需求，我认为是合格产品经理必备的能力。关于落实和传达，逻辑关系复杂到一定程度，文字无法准确表达，于是很容易造成交互设计师对概念的理解缺失，或者说不知道拿什么来交互。 形成规模的产品，需要类似做信息逻辑搭建的角色，来衔接产品经理和交互设计师之间的断层。产品经理通常不具备完成结构图和线框图等类似信息描述交付物的能力，最关键的问题，麻烦不在解决，而是统一和协调（预防问题），尤其是平台级应用。 信息架构与交互设计在提方案时无法绝对