Lean UX: Creating Great Products with Agile Teams

by Jeff Gothelf, Josh Seiden

User experience (UX) web design has traditionally been a deliverables-based practice, defined by wireframes, site maps, flow diagrams, content inventories, taxonomies, and mockups. But that tradition is not the best way to serve the user. With this hands-on guide, you’ll learn that UX is about the experience, not the deliverables, and that as a UX designer you need to focus on the user and not the documentation. By applying a set of lean design practices and principles, you’ll learn how to keep the user’s needs first and foremost. Refined through the real-world experiences of dozens of startup companies, these techniques are part of Eric Ries’ Lean Startup methodology.Get a tactical understanding of how Lean and UX/Design can integrate successfully Understand why this integration has failed in the past, and learn how to avoid the pitfalls Break down the silos created by job titles and learn to trust your teammates despite their different skillsets/offerings Improve the quality and productivity of your teams, and focus on experiences as opposed to deliverables/documents

Genres: Design, Business, Nonfiction, Technology, Startup, Programming, Professional Development

225 pages, Hardcover

First published June 22, 2012

About the author

In a world of continuous change, improvement and optimisation the delivery of products to market is no longer the right measure of success. Instead we must focus on outcomes — meaningful changes in human behavior — to tell us if we’ve delivered anything valuable to our customers.
I teach executives and teams — through remote training, workshops, keynotes, & books — to focus on their customers, learn from mistakes and create a customer-obsessed culture based in humility and agility that continuously improves their products and services and the way they work.
I am the co-author of Sense and Respond, Lean UX and Lean vs Agile vs Design Thinking. My most recent book is called Forever Employable: How to stop looking for work and let your next job find you.
I am currently writing a book on Objectives and Key Results.

Reviews

[Mikal · Rating 3 out of 5]

Lean UX is a compelling case study that offers the foundational thinking behind, and the practical argument for a shift to Lean UX.
This book is best suited for individuals who are already familiar with and have some experience with Lean methodologies. You won't get lost in any of the concepts if you have no experience in the space-- just the argument for and the nuts and bolts of putting it to use may appear weak if you don't have a stronger foundation.

Lean UX is a wicked problem. The author doesn't offer it here as a wicked problem but as you conclude the book you can't help but reach that conclusion. THe only way to develop and implement a Lean UX system that works is to implement it wrong and cultivate enough political capital to earn the right to implement it 'right' over a sustained period of time.

Jeff does a good job here providing a best first answer to many of these problems. But just as there is no one size fits all agile approach and agile is best when you're not dogmatic about it, so to is lean UX. Lean UX is a response to a business and software development environment where closer integration and iteration are the key currency of the day.

I recommend this book as a contributor to anyone who is looking to learn about Lean UX and apply the principles in their work. But I would strongly encourage you to read this topic from multiple angles, including the software development angle.

Jeff borrows aggressively from Lean Startup thinking but I think that does a disservice, I think the principles of Lean UX extend far beyond the Lean Startup philosophy. One area I believe I will continue to refer to is Jeff's summary on how to integrate user research into the design process.

Over the next year, I suspect the volume of books on Lean UX to increase in volumes. I don't suppose this book will standout in a larger collection of books on the topic of agile UX.

[Rebecca Karasik · Rating 4 out of 5]

Surprisingly much better than I expected. Usually I find these types of books don't offer enough examples, but in this case the authors offered specific examples from their own work experience. Several of the concepts were new for me and for the ones that weren't this book provided a great refresher.

[azarakhsh · Rating 4 out of 5]

A must read for the designers and agile practitioners.
Despite some outdated tools and information, the insight provided by the book is invaluable. Maybe including more examples and real case studies could push it to whole new level. All in all, if you want to broaden your understanding on how UX design and agile practices could go hand in hand, you should give it a try.

[Quinten Vandermeulen · Rating 3 out of 5]

Read Sprint from Jake Knapp instead. It’s the Lean-UX-on-steroids of 2020. The Lean UX book is a bit outdated with no new insights if you are already accustomed with lean and agile development and design thinking.

I hoped for more detailed info on how to conduct user research (crucial in lean UX), but was left with only some general info. I advice Steve Krug’s books and the Mom Test instead.

For its time (2013), it must have been pretty revolutionary. Now, there are better books to read.

[Alp Turgut · Rating 4 out of 5]

Okudukça yeni şeyler öğrenebileceğiniz "Lean UX: Creating Great Products with Agile Teams", bir tasarımcının başucunda olması gereken belki de tek kitap olabilir. Agile ile Lean UX yöntemlerinin uygulanabilirliği konusunda harikulade bir rehber niteliğinde.

23.05.2022
Londra, Birleşik Krallık

Alp Turgut

[Olivia Law]

Read this for work (i work in tech now lol) and LOVE the concepts of this, was super useful. However, definitely dragged on a bit, like after a while, you just get it. Didn't feel like I got much out of the last 1/3 of the book.

[Stephen · Rating 4 out of 5]

Lean UX is a great overview of how to do User Experience work in an agile team. As a follow on to The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses this book has stories, templates, guidelines to help you both use User Experience Design in an agile team as well as use User Experience to help your agile team do a better job of building the right thing. Much of what you'll read will strike you as "common sense," which, sadly, does not translate to common practice in many organizations.

The book is short, so it's quick to read and get an overview, but it is also structured in a way that makes it amenable to reference as you execute. This is a rare book that is information dense, yet which does not allow that information density to compromise readability. The viability of the book as a reference compensates for the one flaw I see in it's presentation of the principles of Lean UX: defining Lean UX too many (15) principles.
15 (related) is far more than most people can keep in their head, making it harder to both sell and internalize the ideas. I understand that there is a lot to do to implement Lean UX, but I can't help think there must be a way to distill the 15 principles into 5-7 key ones which incorporate the spirit of the whole set. This may sound like a petty detail, but I suspect that it would be hard for someone not as versed in the concepts as the authors to sell the concept based on those 15. If you can't sell an idea, it is that much harder to break down opposition to it. The concrete, concise way the authors describe how to implement Lean UX in various environments compensates for this, but since the book started out with an overview of principles, I was initially concerned about how the rest of the book would go.

Ignoring my concern about the laundry list of principles, the book will be useful to managers, UX designers and developers and anyone wondering how UX can work in an agile environment. Since user experience is such a central part of the product definition it will also be useful to anyone who simply wants a better understanding of agile product development.

[Lars K Jensen · Rating 4 out of 5]

This book is part of the newer Lean movement, which followed Eric Ries 'Lean Startup' work. Therefore it might be a good idea to start with Ries's book, but it's not a must.

This book is noticeably shorter, which is both a good and a bad thing. Good, because 'Lean Startup' just wants to cover too much and short, because Gothelf touches on some subjects that should be explored further.

For me the absolutely best part of this book was chapters 7 (combining Lean UX with Agile/Scrum) and 8 (on the organizational changes needed to succeed with Lean UX and Agile approaches).

I work in a development department where we are consolidating our Scrum work and we will probably need to address the UX/Scrum challenge. And what I mean when I say that some subjects should be further explored, this is a case in point. We get a few pages and someone from some company explaining what she done. It doesn't really dive into the challenge of combining UX and Agile/Scrum, which is a shame.

Chapter 8 is built as a kind of index on key things that need to change. This works very well but again, a more in-depth approach would have been nice.

Still, it gets your mind running - and that's the most important thing.

A great deal of this book was (to me) classic UX. The MVP here doesn't really sound as the same MVP in 'Lean Startup' (here it's basically a prototype). I am in no position to say which approach is the best but I know which is my favorite.

And that is a big part of all this: Dive into it and decide for yourself.

[Ruchil]

Notes


“Teams are pushing new code to production as fast as you can save a Photoshop file”

“This continuous engagement allows us to strip away heavy deliverables in favor of techniques that allow us to build shared understanding with our teammates.
Lean UX also lets us change the way we talk about design. Instead of talking about features and documents, we can talk about what works. In this new reality, we have more access to market feedback than ever before. This feedback allows us to reframe design conversations in terms of objective business goals. We can measure what works, learn, and adjust.”

“Lean UX is three things. It’s easiest to understand as a process change for designers. But it’s more than that. It’s a mindset that lets us approach our work in new ways. It’s also a way of thinking about managing software.

Chapter - 2 : Principle

“Lean UX stands on three foundations. The first foundation is design thinking.
Tim Brown, CEO and president of legendary design firm IDEO, described design thinking as “innovation powered by...direct observation of what people want and need in their lives and what they like or dislike about the way particular products are made, packaged, marketed, sold, and supported...[It’s] a discipline that uses the designer’s sensibility”

“The second foundation of Lean UX is Agile software development. Software developers have been using Agile methods for years to reduce their cycle times and deliver customer value in a continuous manner. Although Agile methods can”

Agile principles

“of Lean UX. Lean UX applies the four core principles of Agile development to product design:
Individuals and interactions over processes and tools. To generate the best solutions quickly, you must engage the entire team. Ideas must be exchanged freely and frequently. The constraints of current processes and production tools are eschewed in favor of conversation with colleagues.

Working software over comprehensive documentation. Every business problem has endless solutions, and each member of a team will have an opinion on which is best. The challenge is figuring out which solution is most viable. By building working software sooner “solutions can be assessed for market fit and viability.

Customer collaboration over contract negotiation. Collaborating with your teammates and customers builds a shared understanding of the problem space and proposed solutions. It creates consensus behind decisions. The result? Faster iterations, real involvement in product making, and team investment in validated learning. It also lessens dependency on heavy documentation, as everyone on the team has already participated in making the decisions that were used to require written communication and defense.”

Responding to change over following a plan. The assumption in Lean UX is that the initial product designs will be wrong, so the goal “should be to find out what’s wrong with them as soon as possible. Once we discover what’s working and what’s not, we adjust our proposals and test again. This input from the market keeps us agile, constantly nudging us in a “more right” direction.

The third foundation of Lean UX is the Lean Startup method founded by Eric Ries. Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and gets teams building quickly and learning quickly. Teams build Minimum Viable Products (MVPs) and ship them quickly to begin the process of learning as early as possible.

“The practice of Lean UX is: Lean UX is the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way that reduces the emphasis on thorough documentation while increasing the focus on building a “shared understanding of the actual product experience being designed.”


Principles

In the rest of this chapter, I’ll lay out the principles behind Lean UX. As you explore the Lean UX approach, keep these principles in mind. Think of your experience with Lean UX as a learning journey. Use these principles to keep you and your team on course.
Principle: Cross-Functional Teams
What is it? Cross-functional teams are made up of the various disciplines involved in creating your product. Software engineering, product management, interaction design, visual design, content strategy, marketing, and quality assurance (QA) should all be included in a Lean UX team. Lean UX demands a high “level of collaboration between these disciplines. Their involvement must be continuous, from day one of the project until the end of the engagement.
Why do it? The creation of these diverse teams collapses the gated-handoff process known as waterfall. Insight on each idea is brought in from all relevant disciplines earlier in the process. Conversation is encouraged across functional silos, which drives greater team efficiency.”

“Principle: Small, Dedicated, Colocated
What is it? Keep your teams small—no more than 10 total core people. Dedicate them to one project and staff it all out of the same location.
Why do it? The benefit of small teams comes down to three words: communication, focus, and camaraderie. Smaller teams are easier to keep current on”

GOOB : “What is it? It may sound like a baby’s first word, but GOOB is actually an acronym for what Stanford professor, entrepreneur, and author Steve Blank calls “getting out of the building.” It’s the realization that meeting-room debates about user needs won’t be settled conclusively within your office. Instead, the answers lie out in the marketplace, outside of your building”

“Principle: Anti-Pattern: Rockstars, Gurus, and Ninjas
What is it? Lean UX advocates a team-based mentality. Rockstars, gurus, ninjas, and other elite experts of their craft break down team cohesion and eschew collaboration.
Why do it? Rockstars don’t share—neither their ideas nor the spotlight. Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars. When collaboration breaks down, you lose the environment you need to create the shared understanding that allows you [to avoid repetition] to move forward effectively.”

“Principle: Permission to Fail
What is it? In order to find the best solution to business problems, Lean UX teams need to experiment with ideas. Most of these ideas will fail. The team must be safe to fail if they are to be successful. Permission to fail means that the team has a safe environment in which to experiment. That philosophy applies to both the technical environment (they can push out ideas in a safe way) and the cultural environment (they won’t be penalized for trying ideas that don’t succeed).
Why do it? Permission to fail breeds a culture of experimentation. Experimentation breeds creativity. Creativity, in turn, yields innovative solutions. When teams don’t fear for their jobs if they get something wrong, they’re more apt to take risks. It is from”

“Why do it? Documents don’t solve customer problems—good products do. The team’s focus should be on learning which features have the biggest impact on the their customers. The artifacts the team uses to gain that knowledge are irrelevant. All that matters is the quality of the product, as measured by the market’s reaction to it”

Part II : Processes

“This is the day-to-day rhythm of Lean UX: a team working collaboratively, iteratively, and in parallel, with few handoffs, minimal deliverables, and a focus on working software and market feedback. In this section, you’ll see how it’s done”

“Chapter 3. Vision, Framing, and Outcomes”

“Our goal is not to create a deliverable, it’s to change something in the world—to create an outcome”

“Assumptions
A high-level declaration of what we believe to be true.

Hypotheses
More granular descriptions of our assumptions that target specific areas of our product or workflow for experimentation.
Outcomes
The signal we seek from the market to help us validate or invalidate our hypothesis. “These are often quantitative but can also be qualitative.
Personas
Models of the people for whom we believe we are solving a problem.
Features
The product changes or improvements we believe will drive the outcomes we seek.”


Hypothesis Testing

“Sometimes—if not most of the time—you will discover that your hypothesis is too big to test with one test. It will contain too many moving parts, too many subhypotheses. When this happens, I find it helpful to break the hypothesis down into smaller and more specific parts. Though there are many ways to do this, for product work I have found that this format is very helpful:
We believe that
[doing this/building this feature/creating this experience]
for [these people/personas]
will achieve [this outcome].
We will know this is true when we see
[this market feedback, quantitative measure, or qualitative insight].
The first field is completed with the feature or improvement you’re considering making to your product. The second field describes exactly which of your target customers will benefit from this feature. The last field speaks to the benefit those”

“Proto-personas are our best guess as to who is using (or will use) our product and why. We sketch them on paper with the entire team contributing—we want to capture everyone’s assumptions. Then, as we learn from our ongoing research, we quickly find out how accurate our initial guesses are, and how we’ll need to adjust our target audience (and persona)—and thus our design”


Chapter - 4. Collaborative Design

As you navigate through the rest of your life, be open to collaboration. Other people and other people’s ideas are often better than your own. Find a group of people who challenge and inspire you, spend a lot of time with them, and it will change your life.”

“Finally, collaborative design builds team-wide shared understanding. It is this shared understanding that is the currency of Lean UX. The more the team collectively understands, the less it has to document in order to move forward.”

Style Guides

One tool that makes collaborative design easier is the style guide. A style guide is a broadly “accepted pattern library that codifies the interactive, visual, and copy elements of a user interface and system. Style guides (also known as pattern libraries) are a living collection of all of your product’s customer-facing components. If it’s made of pixels, it goes in the style guide. Headers, footers, grids, forms, labels, button logic, and everything else that goes into your product’s user experience goes in the style guide.”

“Interaction and visual designers benefit as well. They no longer have to recreate representations of experiences that already exist. They become free to focus on new design challenges—novel interaction problems or extending the visual system to new elements. Approval cycles are streamlined because the repetitive elements (e.g., the treatment of the global navigation) are no longer up for debate. Reviews become more focused on the core product challenge and broader views of the proposed solution.”

“On the whole, men become aroused a lot faster than a woman. And while a man can rape a woman, the reverse is not true as she can’t force him to achieve an erection though that’s not to say, as studies have shown, that a woman can’t coerce a man into having sex even if she can’t physically force him into doing so. But still, all these factors have to be integrated in how humans act when it comes to entering the sexual continuum.

And let’s face it, the man still is the one expected to push the sexual side of the relationship forward. That’s not to say that there aren’t plenty of women who aren’t afraid of being sexually assertive but they also understand that they risk turning the man they’re with off if they come on too strong”
“use where and at what size/weight). The same attributes of what, where, and when provided for interaction design elements should also be included here.
Finally, ensure that copywriting styles are codified as well. Capture the tone of your brand, specific words you will and won’t use, grammatical choices, tolerated (and not tolerated) colloquialisms, along with button language (OK? Yes? Go? etc.) and other navigation language (previous/next, more/less, etc.).”


Types of design

“Separate your TOC into interaction design, visual design, copywriting, branding guidelines, accessibility needs, and any other high-level sections that make sense for your business.

The big bang approach (in which your team creates the entire style guide in advance of any project) works well if you have a young product or a relatively simple one”

“The slow drip approach works well if you have a legacy or complex product.


“Creating an MVP
When you start planning your MVP, the first thing you have to do is consider what you’re trying to learn. It’s useful to think about these three basic questions:
Is there a need for the solution I’m designing?
Is there value in the solution and features I’m offering?
Is my solution usable?”

“Be clear and concise
Spend your time distilling your idea to its core value proposition and present that to your customers

Prioritize ruthlessly
Ideas, like artifacts, are transient. Let the best ones prove themselves.”

“Stay agile
Information will come in quickly, so make sure that you’re working in a medium that allows you to make updates easily.
Measure behavior
Build MVPs that allow you to observe and measure what people actually do, not just what people say. In digital product design, behavior trumps opinion.”

“Chapter 6. Feedback and Research

Research is formalized curiosity. It is poking and prying with a purpose.
—Zora Neale Hurston”

“Collaborative research techniques that allow you to build shared understanding with your team
Continuous research techniques that allow you to build small, informal qualitative research studies into every iteration
Which artifacts to test and what results you can expect from each of these tests
How to incorporate the voice of the customer throughout the Lean UX cycle
How to use A/B testing (described later in this chapter) in your research
How to reconcile contradictory feedback from multiple sources”

[Haley · Rating 5 out of 5]

The best UX book I've read. Very practical, gives actual exercises and templates. Lots of examples and organized well.

[Miguel Angel Pedrajas · Rating 4 out of 5]

Un libro que tenía pendiente desde hace un tiempo y que es todo un clásico en el mundo del diseño UX y las metodologías ágiles. En él se exploran los principios del método Lean y cómo aplicarlos para mejorar la experiencia de usuario. Es un libro lleno de consejos prácticos y herramientas útiles. Se nota que está escrito por dos profesionales con mucha experiencia.

Sin embargo, hay que tener en cuenta que el libro se publicó en 2012 y algunos de los puntos que trata ya están un poco manidos para la gente que lleva tiempo en el sector. Sin duda este libro habrá servido de pilar fundamental para muchos de los conceptos se han desarrollado y explicado con más profundidad en libros más recientes.

Si eres nuevo en el mundo del UX y las metodologías ágiles, este libro te será una lectura valiosísima. Lleno de ejemplos y con un tono sencillo y asequible para todo el mundo, te ayudará a entender los fundamentos del método Lean y cómo aplicarlo en tu trabajo diario. Sin embargo, si ya tienes experiencia en UX o el método Lean, es posible que algunos de los conceptos te resulten ya conocidos o demasiado básicos. Eso sí, ten en cuenta que el libro no pierde el punto de vista de negocio, por lo que sus aportaciones tienen una perspectiva que a veces se olvida en otros libros del sector y suelen ser importantes.

[Cindy · Rating 4 out of 5]

Lean UX is a great book for beginners from an Agile/Scrum developmental process viewpoint (frankly a smart choice because most software dev teams usually go through these two since it's so efficient). It has several gold pages delineating questions a designer should ask of any project and quite a few golden principles for people going into UX.

Four stars because there were some pages in there that had a needlessly heavy number of pages for what they were- things like "every get 30 seconds to write on a whiteboard and hold it up!", or "write ideas on sticky notes/flashcards and share in a roundtable!". There was also a good chunk of pages dedicated to his personal projects, which while an entertaining read, wasn't anything particularly enlightening. I was also disappointed in the lack of UX prototypical examples (before and after, in particular), especially because of how amazing he said he did in several of his projects. Back it up and annotate your design specs, please! Other than that, it's an ok book. GR has a spot-on rating.

[Webb Henderson · Rating 3 out of 5]

In a nutshell – design should be continuous (lean startup) and collaborative (this book):

- Use cross-functional teams
- Share understanding of the problem, constraints, assumptions, and potential solutions
- Share ownership of the product design and customer experience (avoid 'hero design')
- Focus on outcomes (vs. outputs)
- Encourage colleagues to contribute through any discipline (vs. established roles)
- Embed design thinking (particularly exposure to customer behavior, emotions, motivations)
- Designers need to lead and facilitate...not just execute

[Ihor · Rating 5 out of 5]

Плануємо, дизайнимо, тестуємо, а іноді дизайнимо, плануємо тестуємо, а ще іноді плануємо, дизайнимо й тестуємо водночас. Молоді й гарячі, творчі та динамічні, такі що змінюють світ. Книжка, як і вся наша сучасна цивілізація, дуже динамічна та без зайвої інформації.

[Jordana Simon · Rating 2 out of 5]

I've read a lot of other books that hive you the same information in a better and shorter way

[Grant Baker · Rating 2 out of 5]

Lean UX is a staple for many UX and Product designers today. This third edition is sure to evolve the practice even further.

There are some gems hidden inside the pedestrian prose, though this third edition is much like the products it produces—watery, bloated, and banal. At one point, it favorably mentions a company leveraging Lean UX to bring in customers for rounds of people who do research to talk to them for 15 minutes. That’s not even enough time to build rapport. Trusting data gained this way is suspect at best and leads to these types of “ask ‘em if they like it” products that please few.

There were gems as mentioned above, the best of which is the concept of Design Studio. I have personally used this play many times to build engagement on the team and alignment within constraints.

A few suggestions for alternatives:
* Designing for the Digital Age by Kim Goodwin
* About Face by Alan Cooper et. al.
* Sensemaking by Christian Madsbjerg

[Valentin · Rating 3 out of 5]

The lesson taken from this book is this one:
"Focus on outcomes, not goals or, even worse, metrics."
Goals and metrics are useful tools, but be careful to not worship tools. Always the outcome primes.

And this can be applied in Agile, in own business(es) or even daily life, tasks and goals.


Also, it seems like a really really short summary on what I have learned at a Minor course during University.

Really like that it mentions A/B testing towards the end.

It is really concise, but it feels like something is missing from it.

[Oliver · Rating 4 out of 5]

The interesting aspect of this book is the integration of User Experience Design in an agile workflow. I like the idea of collaborative design and collaborative evaluation. I'm not sure if research and analysis as it is described in this process isn't perhaps a bit too lean, especially when quite a complex task is to be solved.

[Juan Serenellini · Rating 3 out of 5]

algunas ideas buenas, pero no pasa de ahí. muy de la época de internet inicial y dónde estaba de moda escribir en whiteboards y hacer grafiquitos jugando a trabajar e imaginar que las personas son NPC y que uno le diseña un negocio alrededor como cuando jugas al Sims y le diseñas la casa y le pones ropita.

[Yaroslav Tykhonchuk · Rating 3 out of 5]

Сподобався підхід як думати до вирішення задачі, що все є припущенням, яке важливо чітко сформувати в гіпотезу (що ми робимо, для кого, навіщо, яку користь це принесе користувачам і компанії), і потім перевірити її результат.

Але також дуже багато води, і не цікаво було як саме вписувати Lean UX в Agile

[Basma · Rating 4 out of 5]

Great book! Loved it and enjoyed reading it and learned so much! Although felt that some stuff that are mentioned might be a bit outdated as of now, and if you enjoyed reading the sprint book I think you might enjoy Lean UX as they are pretty much similar in concept.

[Kars · Rating 4 out of 5]

I picked this up because I am once again in a situation where I want to improve my effectiveness as a designer inside an agile (startup) team.

This is a quick, surprisingly good read. (I've this far been skeptical of the lean hype, expecting it to be old ideas in new dress.) But this book probably offers the most convincing description of how to marry a user centered design process with an agile software development process I have read to date.

The weakest point for me was an early section on shifting from features (or output) to outcomes, and declaring assumptions. The exact process outlined for articulating outcomes is confusing due to an overuse of jargon.

Things I really appreciated were the emphasis on cross functional teams and design sessions which include all roles. I also liked the idea of proto-personas (a quick and dirty way of modeling target users).

The suggestion to do a user test each week with three users sounds awesome to me, except recruitment for such an effort would be a nightmare. The authors wave this objection away by saying: "outsource it". Easier said than done in many cases.

I was also pleasantly surprised with the treatment of the much bandied about MVP term, which it turns out does not mean the smallest product you can build but is actually a thing you make to run an experiment. More often than not it isn't a product but part of a product: a feature or a microinteraction even.

The very best part, like I already said, is one of the final chapters in which a complete and coherent process framework is sketched of scrum with product design added. It's simple, but I expect it to be very effective too. I plan to put it into practice and see where it leads.

[Jimmy Longley · Rating 5 out of 5]

Reviewed as part of my 100 books challenge: http://jimmylongley.com/blog/books/

Run-on Sentence Summary
A short manifesto on how to integrate design work with a software team employing the lean strategy.

Impressions
When I picked this up, I hadn’t read any of the other "lean startup" books, but understood the basic premise. The fundamental concept of this book, as well as lean in general, is that to build a successful product a team needs to iterate quickly and test often. This book goes into specifics about how to integrate designers into that iterative approach.

Too often, design is treated as a black box where a developer contracts out a designer to create a mockup one time, and then fills in the functionality. This book preaches that to build the thing the customer wants, design and elopement need to work closely together in an iterative fashion. Its full of good examples and specific practical advice.

Final Thoughts
I wish I had read this book earlier, back when I was learning UX with Prime Air. I am drinking the lean cool aid.

Favorite Quote
""It’s not iterative if you only do it once." Teams need to make a commitment to continuous improvement, and that means not simply refactoring code and addressing technical debt but also reworking and improving user interfaces."

[Pedro Silva · Rating 2 out of 5]

I had my expectations set wrong for this book. For some reason I was hoping for more insights on ux examples/best practices and not on the process part. My fault here.

One very simplistic idea that stuck is that everyone should be involved in the processes. It's all fine and good as with much of the concepts presented but hard to see it really working in practice. Sometimes the developers actually do want to code (instead of having meetings, alignments, design studios, customer feedbacks, etc.) it's a fine balance sometimes.

I found the book to be heavy reading with too much text together. I'm also not a fan of bullet indexes or wrap ups/recaps for every chapter! It's good if you want to use the book as reference for specific topics but if you read it all at once it kind of feels like the information is repeated and I should have gone for the "long story short" part only instead of reading the whole chapter.

I was personally interested in the customer feedback section so that's probably what I got most value from.

Some examples presented but personally I like examples of things that did not work. We can learn so much from them when we dissect them. A few are present but they did not stuck to me like all the "good" examples shown.

Not easy to read in one go. I might come back to research for a particular topic.

[Ahmad hosseini · Rating 5 out of 5]

What is the definition of Lean UX?
It’s the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way.

Foundations of Lean UX are:
• User experience design
• Agile software development
• Lean startup
Lean UX team principles:
• Problem-focused
• Cross-functional
• Small, dedicated, collocated
• Self-sufficient and empowered

Lean UX breaks down the barriers that have kept software designers isolated from real business needs on the one hand and actual implementation on the other.
For those new to this methodology, great start on learning a different process and mindset for development, especially in software, but useful in other businesses too. A fantastic combination of case studies and practical advice that your team can use today.
This book is for designers, product managers, and developers.

[Henry · Rating 2 out of 5]

Pretty disappointed by this text - it feels and read likes a 15 slide powerpoint that got expanded to 80 pages plus pictures.

The concepts are unimaginative and not presented with very much grace. The narrating author leaned heavily on his experience at The Ladder, and so almost all of the advice was geared towards large organizations that are trying to make themselves more lean. There was practically nothing for smaller, more nimble companies about how to implement best practices up front - or manage the complexity in even smaller, more diverse teams.

Overall, I ended up skimming this book lightly and maybe got one or two good ideas. Wouldn't recommend except for a very narrow niche of professionals in a very specific professional context.

[Mohammad Saadeh · Rating 3 out of 5]

لم يضف هذا الكتاب الشيء الكثير خصوصا بعد قراءتي لكتاب The Lean Startup لإيريك ريس.
لم أستطيع تقييم الكتاب بشكل مستقل لأن الكاتب ذكر في البداية بأن فكرة الكتاب مأخوذة من كتاب إريك ريس, ولذلك وجب عليه أن يحتوي أضافات تذكر كي يكون كتابا يستحق القراءة.
لا أنكر أنه احتوى على العديد من المعلومات حول تحسين تجربة المستخدم, ولكن كان بالإمكان أن يكون أفضل.
وأود القول بأني شعرت أن محتوى الكتاب كان حول الجانب الإداري والتنظيمي لتجربة المستخدم, ولم يكن حول الموضوع نفسه بشكل مفصل, وربما كان هذا بسبب طبيعة عنوان الكتاب ألا وهو الأسلوب اللين لتجربة المستخدم حيث أنه لا يمكن تحسين تجربة المستخدم من هذه الناحية إلا في شكلها الإداري, ولكن كما قلت فلا أرى أنه من الضروري تأليف كتاب بهذا الطول حول هذا الموضوع خصوصا في ظل وجود كتاب ككتاب إيريك ريس.

[Mriystic · Rating 2 out of 5]

Lean UX is the most misunderstood as well as most difficult philosophy (esp. in the service industry) to implement. Although a good starting point on Lean UX the book leaves lots of questions unanswered. It relies heavily on an ideal scenario and top driven implementation approach that may require a complete organizational change.Nevertheless, its a good read esp. to keep the faff, at distance, around Lean UX, which many claim to know and some even claim to be experts.

[Daniel · Rating 5 out of 5]

Great book which I got for attending Jeff's workshop in Graz (Austria) from the man himself. I liked that it was easy to read and follow, yet provided real world examples in addition to the "theory of Lean UX".

The only downside is that I would like to see more on how to fight against traditional "feature factories". As a "lone wolf" it's incredibly hard to fight against dozens if not hundreds of people for a change that many won't understand.

[Zoltán Dósa · Rating 4 out of 5]

Although I think this is a really useful book to have, the structure of the book is quite ad-hoc, and without actual experience in the field will not give you a coherent image of the methodology.
A new edition would be welcomed featuring content that is actually taught in Jeff Gothelf's workshops.
In the absence of that, i strongly encourage anyone reading this book to go check out the lean ux canvas, it gives the frame for many things in the book.