我很粗略的阅读了本书，如果以后有机会，我还想对有些篇章精读下，作为一个菜鸟，书中很多观点和建议我还是很受用的，特别是能够引发我在实际工作中的一些思考。

      用户体验和可用性设计并不是很玄的东西，书中九个章节谈到的内容-不管是“了解用户、了解需求”，还是“设计方案和制作原型”，或者“测试可用性”等等-我所在的团队在实际的产品开发中似乎都有涉及，但仔细琢磨下，没个方面都有不足，最终的结果是产品的用户体验和可用性上比较弱。

      以下是我读后的一些思考：

1. 原型的力量

本书中作者很推崇原型的作用，不管是初级原型还是高级原型。我自己的团队中的产品有原型吗？有。原型的作用有那么大吗？我觉得没有。有时我们的原型与实际的产品设计混淆了，我们把某个阶段或迭代的产品作为原型推送个用户，去做产品体验了，‘推倒重来’的悲剧偶有发生，付出的代价比改进或从新设计原型要大。为什么会这样呢？我觉得有2个主要原因：1.迭代中缺失了这个环节（这个环节是否必要我觉得要因项目和产品而定），我所在团队的产品人员所制作的初级模型我觉得很不错了，但就初级模型与用户的交互这一块我觉得可能还有待加强，这不仅仅是可以获取用户的反馈，更重要的是有助于解决开发人员关于产品设计的争议；2.我们作为开发人员或产品人员的模型制作能力不是很强。至少对我来说，有时觉得制作模型与实际开发的成本差不多，往往头脑中想的差不多了就动手编码了（难道Web开发很容易这样），最终的产品人员和用户的反馈我并没有多少把握，于是悲剧就在酝酿之中了。

2.Showcase离用户可用性测试有多远

主观和客观的条件决定我所在的团队无法实现较严格的产品可用性测试。我觉得我们比较接近可用性测试的研发环节就是用户Showcase。Showcase时先有一番发布特性的知会和教育，其后用户会进行反馈和交流，偶尔会演示其在实际操作中遇到的问题；最终的效果我臆测估计不会太好-从获取一些改进意见的角度来看。如果要想Showcase能够承载更多的用户可用性测试的作用，我觉得至少要在showcase的人数规模（不用太多人，给用户一个宽松的环境和公平发表意见的机会）和次数（要坚持多轮次，逐步发现更多的可用性问题）上加以改进。本书中提到这样的观点：用户可用性测试，测试用户数不是关键，测试的轮数比较重要，我觉得挺有道理的。

3.用户真的参与了开发吗

这是个复杂的问题，以我现在的能力无法掌控其中的奥秘，但我肯定不能闭门造车，完全将用户和客户排除在开发过程之外。一直高举“以用户价值为依归”的伟大旗帜，但实际开发中对用户的一些需求还是有想法的，甚至有时有排斥和不理解的情况，借口通常是用户不熟悉技术实现的难度，现在我决定时常提醒下自己，如果真的到了用户需求与技术实现产生冲突时，应该下定决心满足用户，克服技术困难。

4.一些有用的Web开发常识

书中比较零散地散布着一些法则和常识，对我挺有启发，特别是结合实际工作时。略举几例：

 * 摩西的十戒：依赖识别而不是记忆；提倡一致性和标准化；给予用户控制权和自主权……；

 * 控件的左对齐与右对齐法则；

 * 标签只能用来导航，不能选择数据；

 * 时隐时现的菜单项体验并不好；

 * 国内的门户网站首页的信息量和闪动广告是一大的“奇葩”。

   一点感受，暂时写这么多吧，希望以后自己能多读些书。