——再读《web信息架构》

准备在今年的UCD年会工作坊与来自豆瓣的设计师Tony一起分享关于“Web信息架构”实践心得，假期特意借了本《Web信息架构》重新温习，结合实践查漏补缺梳理知识体系。这本书我认为是比较值得反复推敲的拔高类，而非指导操作类专业书，也确实如某些网友评价有晦涩难懂实用性不佳的特点。遗憾的是，相对两年前认识的层次上似乎没有更多突破。

顺便翻看了豆瓣上的所有书评和反馈，以及关联的blog推荐。从整个大环境看，关注“信息架构”不乏其人，但好像大家更热衷于去做评议性质的“证明题”，而非从0到1的去真正实施搭建架构体系。当然，我理解这类主题非常难写，并且要把理论运用到工作项目中也不是易事。但信息架构可大可小，可以做自己做些小产品尝试，也可以直接运用到个人网站或博客上。凡事一试便知，否则永远是——书一打开什么都知道，一合上什么都忘了。

其实我不倒太困惑于在产品上的落实效果，不是知识无用，只是功夫未到。我发现最有意义并且实用的是知识管理，用“架构”的思想来学习和总结“架构理论”。比如“互联网产品设计”知识体系的话题，经常会讨论，碰到的问题基本我都有答案，并且能很快指出错误。但要自始自终把整个过程的知识点落实成知识面，每次尝试都会卡壳。

第4到9章纯理论的基本原理，枯燥乏味，我感觉是懂的自然懂，不懂的看了也不懂。这部分其实就是信息架构实施的核心思想，即之后为什么要这么做的解答，现在我看问题很简单，凡是出问题都是因为对业务的理解不够或者有偏差，否则怎么能搞错功能权重？混乱传达优先级？错用术语行话？中间全部“所谓”解决问题的原理，其实都不关键。有时解释烦了，扔下一句话“自己看书去。”很多东西书上明明就写清楚了，但没有实践经验无论如何也无法理解，那是因为思考问题的方法差异所致。但也不要偏激的看不起“专业”理论，服务的客户或者同事对你专业程度的认知，基本都来自专业方法和术语，关键是要用的恰到好处，玩的收放自如，解决问题而不是卖弄炫耀。

第13章探讨了“教育”问题，作者还是建议最好有些专业技术背景。就Web Design来讲，我认为初学者不应该直接去学习“信息架构”（同样我认为“管理”也不是靠学习能成的），而得有能力先意识到有“信息架构”的存在。否则学了也白学，也看不懂任何专业书，甚至可能因为术语太多而更糊涂（比如“信息架构”和“导航设计”的关系）。首先你得是合格的设计师，其次得是有经验的设计师，最后才可能具备架构能力。信息架构是一项踏实的技能，所以不太适合于“聪明”的投机取巧者，比如大部分中国人。

第18和19章谈到的“商业”主题，其实在公司和企业里边，并不可能理论上的某“职位”或“部门”中心化。尤其在互联网公司做产品，“业务架构、信息架构、技术架构”都有可能更突出的把控产品节奏，说到底还是看个人能力。国内客户的普遍特点是，不愿在前期投入过多时间和资源做准备工作，宁愿将来多花数倍的时间和资源来反复做调整。好的东西市场不一定认可，但作为专业技术工作者，可以用时间来证明一切。

问题拔高一点，信息架构得不到“真正”的重视是市场决定的，而市场环境又是终端用户给造成的。不久前阐述产品为王的观点时，结合目前国内的互联网环境，我觉得才想清楚。

那么“信息架构”到底有什么用，或者如何给别人解释，作者“解决信息超载问题”的观点我比较赞同。信息架构理论能够涉及的职能职位非常广，只不过各自用到了不同的方面，也因此增大了学习和理解的难度。自认为已经掌握了学习的技巧，并且也已初步具备了认真学习的态度。看过很多书，做过很多事，以至于我现在学会了怀疑一切，尤其怀疑专家（推荐看专业理论书，而非入门畅销书）。网络上的公共资讯，除了大量雷同转载，还有大量掺杂个人主观意见的错误，信息架构理论也能够帮助甄别。

零零散散写了这么多，都是近期感悟，《Web信息架构》本身的理论和方法其实没有太多嚼头。内容就很零散，这种务虚和理论化的话题也只能如此，但我认为目前书中目录做的知识体系还是领先了国内很多，值得参考借鉴。关键价值点，我认为是倡导架构思想，以及在架构层面提升用户体验的角度问题。

关于分享，目前正在规划内容，还是一如既往的理论与实践相结合，既要讲清楚理论，也需要有分量的案例来演绎。我们会认真准备，我诚恳的希望在这个领域有经验、有心得的同行来一起来探讨，可以提前联系我。

打印  |  相关话题：《web信息架构》   |  类别：信息和交互  |  源地址