There is a new trend called Lean UX, apparently stemming from the Lean Start-up approach. What are its main principles? What are good or recommended reference, sources or education for learning about it?
Tell me more
×
User Experience Stack Exchange is a question and answer site for
user experience researchers and experts. It's 100% free, no registration required.
|
|
|||||||||
|
|
Personally speaking, lean UX is not a type of UX strategy, it is more like the business strategy which accommodates the fundamental UX principles. In UX Design you Design -> Prototype -> Validate as is, but when you do this in sync with other development units in the organization, it becomes lean UX. Anyways, here are some of the links/books/what-have-you. Lean UX model:
|
|||||||||
|
|
I think there needs to be more clarification on this concept in general. Even reading some of the comments so far I’m getting confused when UX within Agile is equated with Lean UX. There's a gap there that isn't really addressed in most content on the subject. And I imagine that's just because it's a challenge in general for which I'm not sure there's a single magic answer. Lean UX, as explained by Jeff Gothelf, is one solution to the Agile UX problem. It is NOT necessarily the final answer to “Agile UX” and it definitely is not "Agile UX" itself. It was developed based on the lean start up concept as mentioned earlier, it was not based on Agile. I think this is an important distinction, because so many articles on the subject make it seem as though Lean UX is a very clear answer to the UX within Agile question. When I see things that seem to imply that somehow you'll know how to manage all of this because you're doing Lean UX, I get kind of confused. Maybe it's just me, but it doesn't seem like it. Even Gothelf doesn’t seem to equate the two in any of his presentations or writings. He does a presentation on Lean UX within Agile and it’s a whole separate beast. You take those Lean UX principles, sure, but there are new challenges to face and new questions to answer. We have to separate the concept of Lean UX and the concept of Lean UX within Agile. Lean UX itself is a separate method that could be used regardless of the development process. Can it help in Agile? Of course. But that's an additional topic to me. Lean UX within Agile is another situation entirely and one that I don’t think is often even well covered. There is little, if anything, in the charts and articles generally provided on this subject that will give you any major clues on how to suddenly do UX within the constraints of Agile's tight development iterations. The challenge of integrating Lean UX into Agile to come up with some sort of new, hybrid Agile UX methodology still remains. Equating the two seems to just lead to confusion, in my opinion. Many articles only touch upon that gap in platitudes, if at all. I think there are ways to address the gap that remains between Lean UX and Agile UX of this (largely making UX equal on the team like a developer or QA member -- maybe the points should include that work like it would any other work), but that’s kind of an additional concept. I’m not arguing against Lean UX, quite the contrary. I just think you need to be careful in assuming that you’ll take Lean UX and clearly and easily slot it into Agile with developers and QA. It’s not that simple. However, Lean UX forms a mindset and approach that’s more similar (and therefore more suited) to Agile and I think it’s the way to go in general. I’ve worked on a team where we’ve done Lean UX in general to great success. But we were always ahead of development. We also tried an iteration where we designed and developed with a team on the same two week iteration – and it’s a whole different scenario. Lean UX principles were used in both situations, but I would never refer to them as the “same”. Beyond all of that, I would argue heavily in favor of Lean UX in general for your UX team. It's not just a "buzz word", the tenets of it have actual practical purpose. At my last job, we had a project where we were able to take the business needs, do contextual inquiry with our users, form the personas we needed and then write realistic tasks that got to what they actually would want to do in reality. Along the way we involved developers, business and marketing by letting them attend the tests and by immersing them in the information we had acquired. We then did paper prototyping around those tasks and tested those designs with actual users. And because it was paper, we were iterating between tests -- sometimes even during tests. The task approach is a good one because we wound up with chunks of the site that could be moved on to development while we then in turn worked on the next set of tasks. I'm sure other places do it differently, but this went pretty well for us overall. We eliminated the "toss it over the fence" mentality, we were constantly improving the product before it even got to development and (I think most importantly) everyone involved had a SHARED UNDERSTANDING of what the user needed and how we were addressing that need. Doing all of this in a linear fashion, as you may see on a waterfall project a lot of the time, would have diminished all of that. |
|||||||
|
|
I took the Luxr course a couple years back - their blog is a nice resource: http://blog.luxr.co/
|
|||
|
