精益设计读后感10篇
《精益设计》是一本由Jeff Gothelf著作，人民邮电出版社出版的平装图书，本书定价：49.00元，页数：132，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
《精益设计》读后感(一)：产品精益的开端
1. 精益设计的三大基础
gt; 设计思维
gt; 敏捷开发方法
gt; 个人和互动重于流程和工具
gt; 能用的软件重于详尽的文档
gt; 与客户写作重于合同谈判
gt; 应对变化重于遵循计划
gt; 精益创业法
精益设计使用协作、跨职能合作的方式，不依赖完备的文档，强调让整个团队对真实产品体验达成共识，从而尽快把产品的本质展示出来。
2. 精益设计的基本理念
gt; 跨职能团队
gt; 团队小、专、聚
gt; 要成果，不要产出
gt; 解决问题的团队
gt; 消除浪费
gt; 小批量
gt; 持续探索
gt; GOOB才是真正的以人为本（getting out of the building）
gt; 共识
gt; 牛人、名人、高手都是反面教材
gt; 把你的工作具体化
gt; 多做事，少分析
gt; 多提认识，少将增长
gt; 失败的权利
gt; 不要再谈交付
3. 精益设计的流程
我们的工作始于假设，而不是需求，我们提出假设，然后验证假设，评估是否取得了预想的成果。
3.1 设想
问题陈述
gt; 产品或系统目标
gt; 利益相关者希望解决的问题
gt; 对于没有指明具体解决方案的，提出明确的改善需求
业务设想
gt; 我认为我的客户有什么样的需求
gt; 这些需求可以如何解决
gt; 我们的首批客户是：
gt; 客户还可以得到的附加好处是：
gt; 主要客户获取渠道是：
gt; 赚钱的方式是：
gt; 主要竞争对手是：
gt; 能打败竞争对手的原因是：
gt; 我们最大的产品风险是：
gt; 解决风险的方法是：
gt; 还有哪些假设，一旦不成立，就会导致项目或产品风险
用户设想
gt; 我们的用户是谁
gt; 我们的产品如何融入他们的工作或者生活
gt; 我们的产品用于解决什么问题
gt; 用户会在什么时候用什么方式来使用我们的产品
gt; 哪些功能最重要
gt; 我们的产品应该是什么样，该如何工作
3.2 假设
我们认为为某些人群/某类人物角色来这样做/开发某种功能/提供某种体验，可以让我们获得某种成果
我们验证的方式是看市场是否有某种反馈/某个量化指标/某个定性指标
把各种假设串联起来，然后用头脑风暴来得出以下结论：
我们要创建某个功能为某个人物原型提供/实现某种成果
注意一定要排列优先级！！！
3.3 制作MVP
协作设计
建设并维护风格指南
风格指南应该包括所有屏幕上显示的东西，所有的交互设计元素都应该定义清楚。如表单中的填表框、标签、下拉菜单、单选按钮、UI行为、ajax和jquery等。
每个交互元素都应该包括三个属性：
外观：最大和最小尺寸，横向和纵向的限制，以及任何样式要求。
常用摆放位置，清楚阐述是否应该一直摆放在屏幕的某个区域，以及所有可能例外情况。
什么时候使用，阐述选择元素时需要考虑的因素。
制作MVP
原则：简明扼要、排序要狠、保持敏捷、评估行为、使用call to action、能派上用场、和现有系统对接、和谐一致
MVP包括原型和非原型两类，最重要的是根据自己要了解的目标来制作原型
3.4 反馈和研究
《精益设计》读后感(二)：Lean UX 与团队协作
几乎国内大一点的互联网公司都会设立独立的用户体验团队，虽然名称上各家稍有差别，不过在协作上多数还是传统瀑布式流程：设计部门从上游产品部门获得需求，完成交互和视觉设计之后，再交付给技术和测试等下游环节，交付完成后再来应付下一波产品需求，要是遇到些问题还需要反复修改的话，下游的进度也会一并耽误。
这样的协作流程把整个流程中各个部门的职责分的很开（包括办公位置也是），所以各个部门的人也会理所当然的给自己部门画出一个隐形的「职责边界」：产品只负责产出需求、交互负责产出原型、技术只负责开发… 每个人只对项目中的一个环节负责，对职责边界以外的事情就放手不管了，于是整个团队中只能看到只对自己的环节负责的人，却找不到对整个产品负责的人。
在这种协作模式下，很多时候遇到职责边界不那么明确的事情，又没有及时沟通，就很容易出现各部门互相推诿的情况。即使这次的问题被明确到某个部门的职责边界中，下次出现个其他不明确的问题，这样的情况依然会往复发生。
把产品协作的各个环节作为独立部门，会带来很大的浪费，包括冗长流程带来的效率浪费，一种是各部门对项目缺少整体的理解带来的沟通浪费。
Lean UX 就是为了减少这两部分浪费提出的。
协作的本质是沟通，环节越长、团队越分散，沟通成本就越高，就不能保证信息传递的准确性和及时性，Lean UX 就是通过精简环节、注重沟通来提升效率。
Lean UX 的精髓在于跨职能小团队和集体决策——确定项目后，把参与项目的成员聚集在一起，建立跨职能小团队。小意味着快，因为沟通的环节减少了，沟通的成本下降了，效率自然会提升，然后通过团队集体快速决策 、简化流程和交付物等方法使协作的效率最大化。而且以「项目」驱动的小团队更能明确集体目标，会有更强的参与感和责任心，也会让团队成员有更强的意愿参与决策，产品在做之前团队成员就已经达成了一致，而不像瀑布式的流程开发中经常出现的下游环节对上游决策的质疑。
这样的跨职能团队一定是以目标驱动的，团队有权力直接针对业务问题设计解决方案。也就是说，由团队自主决定用哪些功能来实现公司的目标。产品需求也必须从成果的角度来谈：我们希望通过这个产品达成什么目的？设计也是如此。
Lean UX 涉及到的另外两个概念是精益创业的 MVP（最简可行产品）和敏捷开发中的 Scrum 方法。
精益创业法使用了“开发-评估-认识”的反馈环来降低风险，让团队可以快速开发和认清现实。精益创业团队开发出最简可行产品（MVP）之后，就迅速把产品推向市场，以便及早地认识市场。
crum
一种敏捷方法论，推崇限时迭代，自行组织，具有高度团队责任感。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
《精益设计》读后感(三)：敏捷设计, 精益UX
*本书令我印象最深的就是Lean UX的与敏捷开发相同的几个原则，以人为本的沟通、小版本持续迭代、让市场验证是否可行。书中也提供了一些精益设计用到的一些技巧，假设法其实就是虚化以往设计过程中的产出物，将设计过程的想法明确的定为假设，需市场/用户验证的假设，然后最快的时间输出最小可测量的成果，投入市场验证是否可行，持续改进、开发。
1.为什么要用Lean UX ？
* 答：传统的设计过程，需要把细节都确定下来，然后多次评审，修改....需要花费较长的时间设计，才投入生产，投放市场，周期长、花费大，如果该产品进入市场后发现并非用户所需要的，那损失的也很大。随着互联网的发展，在线销售不再受限于实体生产流程，缩短了客户和厂商的交易流程，缩短了时间，在这种情况下，可以选择更短的产品周期，最快的开发。现在很多团队使用敏捷开发，即快速开发迭代、持续集成、持续部署，降低了发布的难度，提高发布的频率，以往的设计流程已经不再适用敏捷开发，需要适应到新的协作模式中。
* 2.什么是Lean UX？
* 答：Lean UX 具有一套基本的理论，涵盖流程、协作、管理。包括三个基础： 1）设计思维，设计思维指生活中所有问题都可以用设计的方法来解决，鼓励团队中的每个成员都协同合作，参与到设计，将设计视为一个整体。 2）敏捷开发：敏捷开发的四个原则和Lean UX不谋而合。成果重于文档、互动重于流程和工具、协作重于谈判、应对变化重于遵循计划。3）精益创业法：即设计--评估--认识，即快速开发出最简可行产品（MVP）后，迅速推出市场验证效果，及早认识市场。
《精益设计》读后感(四)：lean ux与敏捷开发、精益创业
精益设计方法的几个观点：用户访谈是一个持续性的过程，可能要花上一个月才能验证一个结论。不要丢弃异常数据，留着慢慢观察说不定后面会发现类似的情况。用户访谈和sprint需要整个团队的参与协作，更清楚目标是什么，结论是什么。交错式sprint模式意味着设计先一个sprint，这样开发资源不会闲置。但需求评审、设计评审环节，产品经理、开发、设计、测试都参与，也是为了减少后续信息不对称带来的额外沟通成本，并且提前沟通可以尽早发现问题。scrum敏捷开发模式下，会有各种小会，但它是有效的，可能一个会议上只有10%的信息与你相关，但你能知道结论是如何形成的，可以节省后面的沟通时间。如何避免管理层干扰迭代节奏：积极沟通（进展、规划）。和管理层寻求目标一致，避免与管理层沟通具体需求。用MVP快速测试，速度第一美化第二并不是说降低质量保证速度而是选择费时最少最容易讲清楚的方案，快速执行修正。在需求验证阶段，小团队效率比大团队高。不要要求设计一步到位（big disign up front）。
《精益设计》读后感(五)：可惜知易而行难
不得不说，真的是一本好书。但阅读容易，想要实施却真的如履高山。
首先，书中的方法不适于传统的设计公司，而是面向所有的互联网公司，将设计的理念从交付转而为目标，这与仅是提供交付的设计公司完全背道而驰。
而对于大部分企业来说，拥有设计的思维，能够跨越部门协同向前这种需求所带来的体制改变、管理难度的提升是何其艰难，没有阵痛，没有高层的真正认识与强力支持，没有人员上的大批量换血，基本上不可能得以实现。或许只有初创型的公司才更合适从一开始就走这一条路。
从组织架构上来说，人数不多，协同作战，快速响应，务实的小团队确实是比一般的分工明确，部门森严的大团队有太多的优势，如果现有公司仍然不能认识到这一点，那真的就可能迟了。
《精益设计》读后感(六)：比较简单，但道理都讲到位了
作为一名敏捷教练（精益软件开发、敏捷、看板方法、精益创业属于相交的知识范畴），平时我们更多地是希望设计人员能够配合软件研发部门的工作方式的转变。而这本书可能侧重是面向设计人员，介绍他们在精益的理念下如何转变工作方式，与研发团队和其他干系人协作。我估计这是它并没有在具体如何跟研发团队配合，或具体如何做UX上面讲很多细节。
如下是我认为书中比较重要的一些部分：
5 Lean UX有三大基础：
- 第一个基础是设计思维。
- 第二个基础是敏捷开发方法。
- 第三个基础是Eric Ries的精益创业法。
7 Lean UX的基本理念：
1，跨职能团队
2，小、专、聚
3，要成果，不要产出
4，解决问题的团队
5，消除浪费
6，小批量
7，持续探索
8，GOOB才是真正的以人为本
9，共识
10，牛人、名人、高手——都是反面教材
11，把你的工作具体化
12，多做事，少分析
13，多提认识，少讲增长
14，失败的权利
15，不要再谈交付
GOOB，全文Getting Out Of the Building，意为“走出办公楼”
16 “描述设想”是Lean UX流程中的第一个步骤。其准备工作主要包括以下几项：
1，现有产品使用情况的分析报告
2，阐明用户行为原因的易用性报告
3，过去解决问题的方法和经验教训
4，利益相关者的看法，即解决问题会带给公司什么效益
5，展示竞争者如何解决同样问题的竞争者分析报告
17 问题陈述模板由以下三部分组成：
1，产品或系统的目标
2，利益相关者希望解决的问题（即某个部分未能达成目标）
3，对于没有指明具体解决方案的，提出明确的改善需求
24 人物型格格式（田字格）
- 左上：画像和名字
- 右上：影响行为的基本信息
- 左下：痛点和需求
- 右下：潜在的解决方案
30 协作式设计可以让团队共同完善产品理念，让团队在设计问题和解决方案上达成共识，一起决定到底用哪些功能或者界面元素来验证假设。
30 一般来说，在协作设计的时候，整个团队一起画草图，发现问题就指出来，最后选定一个大家认为成功率最高的解决方案。
30 协作设计的产出物一般是低保真的草图和线框图。
52 原型产品可以模拟最终用户体验，是一种非常高效的MVP工具。你的目标是花最少的时间做出原型，所以工具的选择就很重要了。
- 低保真度原型：纸质原型
- 低保真度原型：可点击的线框图
- 中高保真度的原型产品：AxureRP、Adobe Fireworks
- 代码式原型：手写代码和活用式原型
- Google AdWords
- 着陆页面
- 无用按钮
61 混合型和创新型MVP：例如“专人服务式”
61 Lean UX的精髓就是：只设计你需要设计的部分，快速交付，多和客户接触，获取有效的反馈。
95 组织层面的转变
- 从输出到成果的转变
- 从各自为战到协同合作的转变
- 愿意学习新的技能
- 建立跨职能团队
- 建立小团队
- 建立开发、协作式的工作空间
- 不依靠明星员工
- 避免“一次到位式设计”
- 速度第一，美化第二
- 推崇从问题入手的思维
- 接受“UX孽债”
- 和其他公司合作
- 改变文档标准
- 自下而上、自内而外的管理模式
98 Robert Dailey的研究：The Role of Team and Task Characteristics in R&D Team Collaboration Problem Solving and Productivity。他发现，团队解决问题的效率和四个因素有关，他称之为“四个预测因素”：任务的明确度、任务的独立程度、团队的规模、团队的凝聚度。
104 雷恩·哈利：“开篇用对话，收尾用文档”。