Pros and Cons of Lean UX

16 Jan 2012 - 11:56am
1 year ago
4 replies
1497 reads
timjaeger
2007

After numerous discussions with others about 'Lean UX' and 'Agile Development', I wanted to understand how / when / why to use Lean UX. My latest blog post goes into some detail about the Pros and Cons of going lean vs. sticking with a more traditional waterfall-based approach:

http://www.timjaeger.com/lean-ux-pros-and-cons/

Comments

16 Jan 2012 - 8:45pm
Jared M. Spool
2003

Hi Tim,

Very good post.

I want to point out that your two cons (Lean UX doesn't work well with distributed teams or with hands-off clients) isn't a failing of Lean UX, in my opinion.

Design, in general, doesn't work well with distributed teams or with hands-off clients. The odds of getting a great design out of either condition is much less than co-located teams or hyper-involved clients. 

Lean UX needs to be considered in context with the success rates of alternative UX approaches to be judged fairly.

Jared

p.s. I tried to leave this as a comment on your blog, but got a password-required error that seemed odd.

16 Jan 2012 - 9:20pm
timjaeger
2007

Jared,

First, I had some spam protection on my blog that wasn't quite working...I disabled it, so you should be able to post this as a comment there (if you so choose).

Thanks for reading the post..it comes from a few years of experience working both Lean and not-so-lean. I'm not sure that having 'everyone in the same room' necessarily produces the best designs...sometimes it causes more stress and anxiety than the freedom to delve into your work without fear of instant retribution :)

I would like to see some examples of Lean UX in distributed work environments. It's tough to see Lean UX work without everyone huddled around a whiteboard brainstorming...Haven't seen it yet..hope to someday!

Tim

17 Jan 2012 - 10:42am
jonkarpoff
2009

At the agency where I work, we've been moving to Lean UX over the last 3-4 years with limited success.

These changes have worked fairly well in speeding up the process:

 

  1. Replacing massive requirements documents with User Stories
  2. Rapid sketching, storyboarding and whiteboarding with IAs, Content Strategists and Interaction Designers
The UX is developed faster, there is tighter agreement between IA and Designer and excessive documentation is reduced.
These advantages are seen both in Agile and non-Agile models.
However, we have yet to find a way to fully integrate UX with Agile. There are three main issues:
Good usability drives consistency in UI elements and interaction models for a project. It is almost inevitable that developing the UI on a piecemeal basis either results in poor usability due to UI inconsistencies or the need late in a project to schedule large amounts of iterative work to rationalize the UI. True with Agile you're initially seeking to satisfice the user with frequently updates rapidily improving the usability.
Developers tend to see UX as outside of Agile. To minimize their risk, they want complete specs to scope to -- particularly when our build partner is our client's internal tech group. This leads to a 4-6 month "Sprint 0" which isn't nimble and tends to still generate more documentation than is  desirable.
Finally, even successful integration of UX into Agile creates an ungainly dance of intertwining but essentially separate sprints for UX and Build. UX strives to stay just ahead of the Developers. This dance is easily tripped up by changes in the sprint backlogs due to client changes or other drivers. This means the project tends to be much less Agile than it should be.
Over the last 15 years, I've seen UX then Agile Build, UX with the Build and even waterfall (rarely) work well. But none of these has yet produced the optimal nimble, lightweight, tightly collaborative project teams capable of delivering usable software quickly with rapid iterative improvements. Our external clients are rarely trained in Agile, properly empowered or have sufficient time to dedicate to the project. External build partners find it hard to merge UX into their processes. Client build teams tend to be highly risk adverse even when using an Agile process and resist UX in the sprints.
Finally, one of the greatest impediments (as metioned before in this thread) is geographical dispersion of the project team. With low or no travel budgets and outsourcing this presents an immense roadblock to success. We have incredible telepresence services available but these reduce but do not eliminate the barriers of time zones, language and noncontiguous interaction. When the team is made up of different prganizations each with their own flavor of Agile the recipe is most often one of disaster -- or at best frustration.

 

 

18 Jan 2012 - 10:12am
Brian Mila
2009

Jon,

Loved your post.  Would you mind if I contacted you to discuss it in more depth?  

Brian

brian dot mila at gmail dot com 

 

Syndicate content Get the feed