《精益设计》读后感摘抄

《精益设计》是一本由Jeff Gothelf著作，人民邮电出版社出版的平装图书，本书定价：49.00元，页数：132，特精心收集的读后感，希望对大家能有帮助。

《精益设计》读后感(一)：可惜知易而行难

不得不说，真的是一本好书。但阅读容易，想要实施却真的如履高山。

首先，书中的方法不适于传统的设计公司，而是面向所有的互联网公司，将设计的理念从交付转而为目标，这与仅是提供交付的设计公司完全背道而驰。

而对于大部分企业来说，拥有设计的思维，能够跨越部门协同向前这种需求所带来的体制改变、管理难度的提升是何其艰难，没有阵痛，没有高层的真正认识与强力支持，没有人员上的大批量换血，基本上不可能得以实现。或许只有初创型的公司才更合适从一开始就走这一条路。

从组织架构上来说，人数不多，协同作战，快速响应，务实的小团队确实是比一般的分工明确，部门森严的大团队有太多的优势，如果现有公司仍然不能认识到这一点，那真的就可能迟了。

《精益设计》读后感(二)：lean ux与敏捷开发、精益创业

精益设计方法的几个观点：用户访谈是一个持续性的过程，可能要花上一个月才能验证一个结论。不要丢弃异常数据，留着慢慢观察说不定后面会发现类似的情况。用户访谈和sprint需要整个团队的参与协作，更清楚目标是什么，结论是什么。交错式sprint模式意味着设计先一个sprint，这样开发资源不会闲置。但需求评审、设计评审环节，产品经理、开发、设计、测试都参与，也是为了减少后续信息不对称带来的额外沟通成本，并且提前沟通可以尽早发现问题。scrum敏捷开发模式下，会有各种小会，但它是有效的，可能一个会议上只有10%的信息与你相关，但你能知道结论是如何形成的，可以节省后面的沟通时间。如何避免管理层干扰迭代节奏：积极沟通（进展、规划）。和管理层寻求目标一致，避免与管理层沟通具体需求。用MVP快速测试，速度第一美化第二并不是说降低质量保证速度而是选择费时最少最容易讲清楚的方案，快速执行修正。在需求验证阶段，小团队效率比大团队高。不要要求设计一步到位（big disign up front）。

《精益设计》读后感(三)：敏捷设计, 精益UX

*本书令我印象最深的就是Lean UX的与敏捷开发相同的几个原则，以人为本的沟通、小版本持续迭代、让市场验证是否可行。书中也提供了一些精益设计用到的一些技巧，假设法其实就是虚化以往设计过程中的产出物，将设计过程的想法明确的定为假设，需市场/用户验证的假设，然后最快的时间输出最小可测量的成果，投入市场验证是否可行，持续改进、开发。

1.为什么要用Lean UX ？

* 答：传统的设计过程，需要把细节都确定下来，然后多次评审，修改....需要花费较长的时间设计，才投入生产，投放市场，周期长、花费大，如果该产品进入市场后发现并非用户所需要的，那损失的也很大。随着互联网的发展，在线销售不再受限于实体生产流程，缩短了客户和厂商的交易流程，缩短了时间，在这种情况下，可以选择更短的产品周期，最快的开发。现在很多团队使用敏捷开发，即快速开发迭代、持续集成、持续部署，降低了发布的难度，提高发布的频率，以往的设计流程已经不再适用敏捷开发，需要适应到新的协作模式中。

* 2.什么是Lean UX？

* 答：Lean UX 具有一套基本的理论，涵盖流程、协作、管理。包括三个基础： 1）设计思维，设计思维指生活中所有问题都可以用设计的方法来解决，鼓励团队中的每个成员都协同合作，参与到设计，将设计视为一个整体。 2）敏捷开发：敏捷开发的四个原则和Lean UX不谋而合。成果重于文档、互动重于流程和工具、协作重于谈判、应对变化重于遵循计划。3）精益创业法：即设计--评估--认识，即快速开发出最简可行产品（MVP）后，迅速推出市场验证效果，及早认识市场。

《精益设计》读后感(四)：比较简单，但道理都讲到位了

作为一名敏捷教练（精益软件开发、敏捷、看板方法、精益创业属于相交的知识范畴），平时我们更多地是希望设计人员能够配合软件研发部门的工作方式的转变。而这本书可能侧重是面向设计人员，介绍他们在精益的理念下如何转变工作方式，与研发团队和其他干系人协作。我估计这是它并没有在具体如何跟研发团队配合，或具体如何做UX上面讲很多细节。

如下是我认为书中比较重要的一些部分：

p5 Lean UX有三大基础：

- 第一个基础是设计思维。

- 第二个基础是敏捷开发方法。

- 第三个基础是Eric Ries的精益创业法。

p7 Lean UX的基本理念：

1，跨职能团队

2，小、专、聚

3，要成果，不要产出

4，解决问题的团队

5，消除浪费

6，小批量

7，持续探索

8，GOOB才是真正的以人为本

9，共识

10，牛人、名人、高手——都是反面教材

11，把你的工作具体化

12，多做事，少分析

13，多提认识，少讲增长

14，失败的权利

15，不要再谈交付

GOOB，全文Getting Out Of the Building，意为“走出办公楼”

p16 “描述设想”是Lean UX流程中的第一个步骤。其准备工作主要包括以下几项：

1，现有产品使用情况的分析报告

2，阐明用户行为原因的易用性报告

3，过去解决问题的方法和经验教训

4，利益相关者的看法，即解决问题会带给公司什么效益

5，展示竞争者如何解决同样问题的竞争者分析报告

p17 问题陈述模板由以下三部分组成：

1，产品或系统的目标

2，利益相关者希望解决的问题（即某个部分未能达成目标）

3，对于没有指明具体解决方案的，提出明确的改善需求

p24 人物型格格式（田字格）

- 左上：画像和名字

- 右上：影响行为的基本信息

- 左下：痛点和需求

- 右下：潜在的解决方案

p30 协作式设计可以让团队共同完善产品理念，让团队在设计问题和解决方案上达成共识，一起决定到底用哪些功能或者界面元素来验证假设。

p30 一般来说，在协作设计的时候，整个团队一起画草图，发现问题就指出来，最后选定一个大家认为成功率最高的解决方案。

p30 协作设计的产出物一般是低保真的草图和线框图。

p52 原型产品可以模拟最终用户体验，是一种非常高效的MVP工具。你的目标是花最少的时间做出原型，所以工具的选择就很重要了。

- 低保真度原型：纸质原型

- 低保真度原型：可点击的线框图

- 中高保真度的原型产品：AxureRP、Adobe Fireworks

- 代码式原型：手写代码和活用式原型

p60 比如说，你的团队需要确定某个新产品或新功能的价值，那么就可以使用非原型类MVP来做验证。秘诀是能简则简。

- Email

- Google AdWords

- 着陆页面

- 无用按钮

p61 混合型和创新型MVP：例如“专人服务式”

p61 Lean UX的精髓就是：只设计你需要设计的部分，快速交付，多和客户接触，获取有效的反馈。

p95 组织层面的转变

- 从输出到成果的转变

- 从各自为战到协同合作的转变

- 愿意学习新的技能

- 建立跨职能团队

- 建立小团队

- 建立开发、协作式的工作空间

- 不依靠明星员工

- 避免“一次到位式设计”

- 速度第一，美化第二

- 推崇从问题入手的思维

- 接受“UX孽债”

- 和其他公司合作

- 改变文档标准

- 自下而上、自内而外的管理模式

p98 Robert Dailey的研究：The Role of Team and Task Characteristics in R&D Team Collaboration Problem Solving and Productivity。他发现，团队解决问题的效率和四个因素有关，他称之为“四个预测因素”：任务的明确度、任务的独立程度、团队的规模、团队的凝聚度。

p104 雷恩·哈利：“开篇用对话，收尾用文档”。

《精益设计》读后感(五)：Lean UX 与团队协作

几乎国内大一点的互联网公司都会设立独立的用户体验团队，虽然名称上各家稍有差别，不过在协作上多数还是传统瀑布式流程：设计部门从上游产品部门获得需求，完成交互和视觉设计之后，再交付给技术和测试等下游环节，交付完成后再来应付下一波产品需求，要是遇到些问题还需要反复修改的话，下游的进度也会一并耽误。

这样的协作流程把整个流程中各个部门的职责分的很开（包括办公位置也是），所以各个部门的人也会理所当然的给自己部门画出一个隐形的「职责边界」：产品只负责产出需求、交互负责产出原型、技术只负责开发… 每个人只对项目中的一个环节负责，对职责边界以外的事情就放手不管了，于是整个团队中只能看到只对自己的环节负责的人，却找不到对整个产品负责的人。

在这种协作模式下，很多时候遇到职责边界不那么明确的事情，又没有及时沟通，就很容易出现各部门互相推诿的情况。即使这次的问题被明确到某个部门的职责边界中，下次出现个其他不明确的问题，这样的情况依然会往复发生。

那么问题出现在哪呢？公司的产品是按照「项目」划分的，但是却不是按照项目整体推进的，完成项目的方法是一环接一环的传递，参与项目协作的人也分散在各个部门，所有人对项目并没有整体的概念，例如项目的目标、价值、成员所做事情的意义等等。而且项目成功了并不带来好处，失败了也不会影响绩效，所以大家只能埋头做好自己的分内工作，就好了。

把产品协作的各个环节作为独立部门，会带来很大的浪费，包括冗长流程带来的效率浪费，一种是各部门对项目缺少整体的理解带来的沟通浪费。

Lean UX 就是为了减少这两部分浪费提出的。

协作的本质是沟通，环节越长、团队越分散，沟通成本就越高，就不能保证信息传递的准确性和及时性，Lean UX 就是通过精简环节、注重沟通来提升效率。

Lean UX 的精髓在于跨职能小团队和集体决策——确定项目后，把参与项目的成员聚集在一起，建立跨职能小团队。小意味着快，因为沟通的环节减少了，沟通的成本下降了，效率自然会提升，然后通过团队集体快速决策 、简化流程和交付物等方法使协作的效率最大化。而且以「项目」驱动的小团队更能明确集体目标，会有更强的参与感和责任心，也会让团队成员有更强的意愿参与决策，产品在做之前团队成员就已经达成了一致，而不像瀑布式的流程开发中经常出现的下游环节对上游决策的质疑。

这样的跨职能团队一定是以目标驱动的，团队有权力直接针对业务问题设计解决方案。也就是说，由团队自主决定用哪些功能来实现公司的目标。产品需求也必须从成果的角度来谈：我们希望通过这个产品达成什么目的？设计也是如此。

Lean UX 涉及到的另外两个概念是精益创业的 MVP（最简可行产品）和敏捷开发中的 Scrum 方法。

精益创业法使用了“开发-评估-认识”的反馈环来降低风险，让团队可以快速开发和认清现实。精益创业团队开发出最简可行产品（MVP）之后，就迅速把产品推向市场，以便及早地认识市场。

Scrum

一种敏捷方法论，推崇限时迭代，自行组织，具有高度团队责任感。Scrum是运用最广的敏捷方法论。大多数Scrum团队都把两周算作一个 sprint，sprint 的目的是交付可用的软件。

建立跨职能小团队后，融合 Scrum 工作方法进行快速迭代，然后通过 MVP 快速验证产品方向，然后根据用户的反馈继续调整方向，开始下一个迭代……

另外 Lean UX 也是有理论依据的，罗伯特·戴利（Robert Dailey）在20世纪70年代末做过一次研究，称为“论团队和任务特征对于研发团队协作式问题解决和生产效率的作用”（The Role of Team and Task Characteristics in R&D Team Collaborative Problem Solving and Productivity）。在这次研究中，戴利发现团队解决问题的效率和四个因素有关，他称之为“四个预测因素”：任务的明确度，任务的独立程度，团队的规模，团队的凝聚度。

所以你看，落实到团队协作中，Lean UX 提到的工作方法基本也是以上几点的延伸。另外说一句，虽然介绍 Lean UX 这本书叫《精益设计》，不过里面的方法多数是围绕团队协作展开的，推荐阅读。

如果懒得翻书，就先看看我的书摘吧：https://www.evernote.com/shard/s25/sh/ff8d35b3-2592-4286-b7f8-712d9ab7700a/e77860b264bf80d735595192ee56dceb