《Communicating Design》读后感

我们只谈互联网 — 2008-08-09 11:00:06

开始阅读《Communicating Design: Developing Web Site Documentation for Design and Planning》，本书主要介绍了 Web 项目计划和设计过程中如何编写有效的文档。

Amazon图书订阅地址：http://www.amazon.com/gp/product/0321392353

http://www.communicatingdesign.com/

http://www.google.cn/search?complete=1&hl=zh-CN&newwindow=1&q=Communicating+Design&start=10&sa=N

主要涉及了三大部分，每个部分谈了一些重要的文档形式，如下：

Introduction

    User Needs Docs 用户需求文档，即用户研究阶段的文档
    Personas 角色设计文档
    Usability Test Plan 可用性测试计划
    Usability Reports 可用性报告

    Strategy Docs 战略规划文档，其实也就是概念设计阶段的文档
    Competitive Analysis 竞争分析
    Concept Model 概念模型（概念图）
    Content Inventory 内容清单

    Design Docs 设计文档
    Site Maps 站点地图
    Flow Charts 流程图（交互流程图）
    Wireframes 线框图
    Screen Designs 视觉设计、原型设计等

    书的内容通俗易懂，并且针对每一项文档都有概述、如何编写（制作）、如何向团队成员演示、实际情况中的运用四个部分。

    它不是一本教科书，而更像一本手册，各章节之间没有联系，你可以根据自己的情况跳跃着阅读。

本书针对3类用途列出10种文件，分别着重在使用者需求文件（User Need Documentation）、策略性文件（Strategy Documentation）以及设计文件（Design Documentation）。

● 使用者定义文件（Personas）：定义主要使用者（Stakeholder），并清楚描述他们会如何使用这套系统。将所有可能会使用网站的使用者都列进来，在设计流程及测试过程时会更完整。

● 可用性测试计划（Usability Test Plan）：系统上线前必然经历测试的项目及方式过程，定义这些内容之前，针对网站对于不同对象的使用方式均需要充分了解，才能掌握正确方向。

● 可用度报告（Usability Report）：针对上述的计划执行后所产生的报告文件。

● 竞争力分析（Competitive Analysis）：就网站而言，竞争力分析等于是与其他竞争对手的优劣比较分析，从网站内容、提供的产品服务以及用户经验比较。

● 概念模型（Concept Model）：在系统分析中，在概念上定义出与系统有关的对象及彼此之间的关系，后续系统分析设计的主要基础得以扎稳。

● 信息内容（Content Inventory）：呈现网站的信息架构及分类方式。

● 网站地图（Site Map）：这应该是最常见、也最基本的网站阶层架构示意文件，让网站规画人员与设计人员可以明确得知，每个网页的内容及功能之间的关连性。

● 网站流程图（Flow Charts）：架构是静态的呈现，透过流程图能分析使用者使用网站的行为动线，以及例外状况处理。

● 视觉版面设计（Wireframes）：使网站主要内容的样式及可视化呈现具有一致性，包括版面格局、图片色系的制定、文字内容。

● 画面设计（Screen Design）：在许多系统设计方法论中，画面的呈现设计一直被视为与使用者沟通的重要文件内容。唯有使用者看到实际的画面，才有办法确认设计的成品是不是他所想要的，并且降低认知上的差异。

产品规划和设计文档示范——《Communicating Design》摘要
http://rainbowblog.blogbus.com/logs/10616667.html

我还下载了UI12_LukeW_WebForms.pdf，浏览了www.lukew.com

http://www.lukew.com/ff/archive.asp

交付物不是越多越好

千鸟 — 2008-12-25 12:59:08

——读《设计沟通十器》

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

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

文档先行

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

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

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

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

文档滞后

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

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

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

《设计沟通十器》 - UCD大社区

《Communicating Design》读后感

交付物不是越多越好

文档先行

文档滞后