交付物不是越多越好
这本书在07年理论满天飞的大环境下是一支独秀，起码看起来更像在做事。书主题讲设计沟通，价值在于针对不同流程、方法交付物提出了成体系里的实践结论。上月的阅读推荐书单中，我对《Communicating Design》的定义是贯穿Structure, Skeleton, Surface三层的指导。
看得出作者对每种方法都有较深入的研究，作为一本总结性的实践大全，指导性自然很强。但我想如此严谨的交付应该是作者多年的工作总结，不太可能在一两个项目中完整施展出来，搞不好还会误导读者。结合瀑布递推、敏捷迭代两种流程写写不同观点。
*文档先行
其实就是瀑布递推的流程应用，但本书所涉及的交付物知识结构，我认为定义有小问题。上月在操作参考中也顺便提到本书某些缺陷，同时给出了蓝图、文档、原型的交付物组织参考。又快速浏览了一遍，仔细阐述几个点：
其一通用性不够强，没有明确轻重缓急，什么是必须的？什么是次要的？什么是加分的？成功产品不一定都经过了专业方法的洗礼，或者说只是一笔带过。
其二关系模糊，所定义的用户需求文档、策略文档、设计文档组织有点混乱。比如第三章可用性测试计划、第四章可用性报告，出现在第一部分用户需求文档中，我开始怀疑现实了。
其三缺乏前瞻性，我坚信xhtml原型的发展空间、美好前景，但也归属于文档显然不合适。还是曾经那个观点：用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。
*文档滞后
其实就是敏捷迭代的流程应用，首先应该强调，敏捷迭代不是反对文档，而是滞后。最重要的，设计师必须对传统文档应用了如指掌之后，才可能在敏捷中把控好节奏、有所失必有所得。本书没有提，或者说作者认为不与主题相关。
著名的Flickr概念模型，好多同行看了叹为观止，第117页也有引用例子。但据我所知，这幅图是在产品正式运营两年之后所画，阶段性总结而已。或者在专业角度，本书更适合做咨询。
设计师积累到一定程度，必然会形成自己的交付物标准，并且在实践中不断优化迭代。但如果是团队，个人标准还远远不够，得需要团队标准来规范。本书就是作者经过积累、总结，提供给同行们的一份参考答案。也许我们一时半会无法领会其中的内涵，但不管从理论、还是实践入手，这本书的价值都不可磨灭。
原文链接地址
http://blog.rexsong.com/?p=3581
看得出作者对每种方法都有较深入的研究，作为一本总结性的实践大全，指导性自然很强。但我想如此严谨的交付应该是作者多年的工作总结，不太可能在一两个项目中完整施展出来，搞不好还会误导读者。结合瀑布递推、敏捷迭代两种流程写写不同观点。
*文档先行
其实就是瀑布递推的流程应用，但本书所涉及的交付物知识结构，我认为定义有小问题。上月在操作参考中也顺便提到本书某些缺陷，同时给出了蓝图、文档、原型的交付物组织参考。又快速浏览了一遍，仔细阐述几个点：
其一通用性不够强，没有明确轻重缓急，什么是必须的？什么是次要的？什么是加分的？成功产品不一定都经过了专业方法的洗礼，或者说只是一笔带过。
其二关系模糊，所定义的用户需求文档、策略文档、设计文档组织有点混乱。比如第三章可用性测试计划、第四章可用性报告，出现在第一部分用户需求文档中，我开始怀疑现实了。
其三缺乏前瞻性，我坚信xhtml原型的发展空间、美好前景，但也归属于文档显然不合适。还是曾经那个观点：用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。
*文档滞后
其实就是敏捷迭代的流程应用，首先应该强调，敏捷迭代不是反对文档，而是滞后。最重要的，设计师必须对传统文档应用了如指掌之后，才可能在敏捷中把控好节奏、有所失必有所得。本书没有提，或者说作者认为不与主题相关。
著名的Flickr概念模型，好多同行看了叹为观止，第117页也有引用例子。但据我所知，这幅图是在产品正式运营两年之后所画，阶段性总结而已。或者在专业角度，本书更适合做咨询。
设计师积累到一定程度，必然会形成自己的交付物标准，并且在实践中不断优化迭代。但如果是团队，个人标准还远远不够，得需要团队标准来规范。本书就是作者经过积累、总结，提供给同行们的一份参考答案。也许我们一时半会无法领会其中的内涵，但不管从理论、还是实践入手，这本书的价值都不可磨灭。
原文链接地址
http://blog.rexsong.com/?p=3581
有关键情节透露
