Skip to main content

Lean User Experience: Using UX on an Agile Project

User Experience is a discipline that has a strange relationship with Agile. On the one hand, traditional UX work involves research, testing, and other steps that seem inconsistent with working in the context of an agile project. It also seems to be a discipline where practitioner often seem to be committed to a Big Design Up Front approach, which is inconsistent with Agile. On the other hand, getting the user experience right seems like an essential part of delivering value. The book Lean UX: Applying Lean Principles to Improve User Experience explains how UX work integrates with agile.

The book combines the themes of The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (including MVP: Minimum Viable Product) with those of user experience and agile methods like Scrum, in a concise, book that can serve both as a quick overview of the concepts which you can read in one or two sittings, as well as a reference for how to apply the process on your team.

This book has stories, templates, guidelines to help you both use User Experience Design in an agile team as well as to 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.

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: there are too many principles.

The book starts with a list of 15 (related) principles of Lean UX, which 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. It is worth pushing past the principles section to learn the value of Lean UX, and techniques to use it effectively.

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.

(Note: This review was based on a review copy of the book.)



Popular posts from this blog

Continuous Integration of Python Code with Unit Tests and Maven

My main development language is Java, but I also some work in Python for deployment and related tools. Being a big fan of unit testing I write unit tests in Python using PyUnit. Being a big fan of Maven and Continuous Integration, I really want the  Python unit tests to run as part of the build. I wanted to have a solution that met the following criteria:
Used commonly available pluginsKeep the maven structure of test and src files in the appropriate directories.Have the tests run in the test phase and fail the build when the tests fail.
The simplest approach I came up with to do this was to use the Exec Maven Plugin by adding the following configuration to your (python) project's POM.

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <executions> <execution> <configuration> <executable>python</executable> <workingDirectory>src/test/python</workingDirect…

Displaying Build Numbers in Grails Apps

Being a fan of Continuous Delivery, identifiable builds, and Continuous Integration: I like to deploy web apps with a visible build number, or some other way of identifying the version. For example, having the build number on the login screen for example. In the Maven/Java world, this is straightforward. Or at least I know the idioms. I struggled with this a bit while working on a Grails app,  and wanted to share my solution. There may be other, better, solutions, but the ones I found approaches that didn't quite work they way that I'd hoped.

My requirements were:
To display a build number from my CI tool, where the number was passed in on the command line. In Bamboo, for example you might configure a grails build as
-Dbuild.number=${bamboo.buildNumber} warTo only change build artifacts and not any source files.To not misuse the app version, or change the names of any artifacts.To be simple and idiomatic.I realized that that Grails itself changes the application metadata (appl…

Motivation Visibility, and Unit Testing

I've always been interested in organizational patterns (such as those in Organizational Patterns of Agile Software Development). I've recently found myself thinking a lot about motivation. I'm now reading Drive: The Surprising Truth About What Motivates Us and just finished Rob Austin's book on performance measurement. Being the parent of a three year old, I'm finding more and more that "because I said so, and I'm right" isn't too effective at home. My interests in motivation are closely related to my interest in writing software effectively. Writing software is partially a technical problem about frameworks, coding, and the like, but the harder (and perhaps more interesting) problem is how to get a group of people working together towards a common goal. Agile practices, both technical and organizational, build a framework which makes having the right amount of collaboration and feedback possible. But there's a bootstrapping process: How do yo…