当前位置: 首页> 书评> 正文

设计沟通十器《交付物不是越多越好》

  • 小小评论家小小评论家
  • 书评
  • 2023-03-26 07:33:23
  • 68

这本书在07年理论满天飞的大环境下是一支独秀,起码看起来更像在做事。书主题讲设计沟通,价值在于针对不同流程、方法交付物提出了成体系里的实践结论。上月的阅读推荐书单中,我对《Communicating Design》的定义是贯穿Structure Skeleton Surface三层的指导。

看得出作者对每种方法都有较深入的研究,作为一本总结性的实践大全,指导性自然很强。但我想如此严谨的交付应该是作者多年的工作总结,不太可能在一两个项目中完整施展出来,搞不好还会误导读者。结合瀑布递推、敏捷迭代两种流程写写不同观点。

*文档先行

其实就是瀑布递推的流程应用,但本书所涉及的交付物知识结构,我认为定义有小问题。上月在操作参考中也顺便提到本书某些缺陷,同时给出了蓝图、文档、原型的交付物组织参考。又快速浏览了一遍,仔细阐述几个点:

其一通用性不够强,没有明确轻重缓急,什么是必须的?什么是次要的?什么是加分的?成功产品不一定都经过了专业方法的洗礼,或者说只是一笔带过。

其二关系模糊,所定义的用户需求文档、策略文档、设计文档组织有点混乱。比如第三章可用性测试计划、第四章可用性报告,出现在第一部分用户需求文档中,我开始怀疑现实了。

其三缺乏前瞻性,我坚信xhtml原型的发展空间、美好前景,但也归属于文档显然不合适。还是曾经那个观点:用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。

*文档滞后

其实就是敏捷迭代的流程应用,首先应该强调,敏捷迭代不是反对文档,而是滞后。最重要的,设计师必须对传统文档应用了如指掌之后,才可能在敏捷中把控好节奏、有所失必有所得。本书没有提,或者说作者认为不与主题相关。

著名的Flickr概念模型,好多同行看了叹为观止,第117页也有引用例子。但据我所知,这幅图是在产品正式运营两年之后所画,阶段性总结而已。或者在专业角度,本书更适合做咨询。

设计师积累到一定程度,必然会形成自己的交付物标准,并且在实践中不断优化迭代。但如果是团队,个人标准还远远不够,得需要团队标准来规范。本书就是作者经过积累、总结,提供给同行们的一份参考答案。也许我们一时半会无法领会其中的内涵,但不管从理论、还是实践入手,这本书的价值都不可磨灭。

原文链接地址

http://blog.rexsong.com/?p=3581

阅读全文