Lean UX Let Me Down

Posted on September 15, 2011.

I talk a lot about the benefits of practicing a Lean UX approach todesign and software development. I also practice it daily. Through these daily trials and errors I’ve come to trust the process and, in many ways, rely on it. Today, however, Lean UX let me down.

Let me explain. The team I design with was taking on a seemingly innocuous presentation layer redesign for a highly trafficked page on our Recruiter application. We ran through our usual routine of shared understanding of the problem statement, high level sketching, initial code-based mockup and visual design refinement. Daily stand-ups facilitated regular progress updates complemented with ad hoc team-wide conversation. Business as usual.

Then, a couple of days from the end of the sprint, I pulled up a chair next to one of the engineers to do some co-design in Firebug. One question led to another and the “tweaks” grew in complexity to the point where a 15 minute session turned into 90 minutes of real-time redesigning. In the end we had to make some fundamental logic changes to the page. The rabbit hole could have gone much deeper had we not been constrained by burn rate and a pending company-mandated deadline.

With each update of the CSS and markup came more questions. Why was this happening? How had we not seen this in advance? The answer became evidently clear at the end of that co-design session: we had not grasped the complexity of the business and UX logic of the page BEFORE we started working. We dove in, like we normally do, and started designing and coding. Had we slowed down for a few minutes and asked some more questions we would’ve designed the page to accommodate the scenarios we uncovered so late in the sprint not to mention saved the team a chunk of refactoring work.

So what did we learn? We learned that:

– spinning an extra cycle or two to understand legacy systems saves
redesign and rethink work

– confirming that a proposed design meets the needs of those legacy
(and new) business rules is crucial when incorporating into existing

– creating new features is much easier and far less risky (as far as
system compatibility goes) then reworking existing ones

– a deep understanding of your existing product is crucial in order
for Lean UX to work well

I learned a valuable lesson today. Understanding where our process broke down and why helps us evolve that process and make it better. The Lean UX process we practiced today, let us down. The process we’ll practice tomorrow will be better.


4 thoughts on “Lean UX Let Me Down

  1. thanks for sharing an example of when the process isn’t all rainbows and unicorns.”creating new features is much easier and far less risky (as far as system compatibility goes) then reworking existing ones” amen. and software never dies, web apps in particular. they evolve, so they have to be designed to evolve. that’s hard.

  2. This is a helpful scenario to discuss for those transitioning to Agile from a more structured UX practice. It seems valuable to find that sweet spot of learning the right amount without diving further than you need to for the current sprint.

  3. Not quite what I expected — I popped over here after listening to your UIE Brain Sparks podcast follow-up to your Lean UX seminar.  You mentioned this blog entry addressed the challenges of working with a large, legacy corporation using Lean UX.  But your anecdote is really about the challenges of converting an old system rather than designing a brand new one.

    I’d be *really* interested to hear more about the challenges you’ve faced with legacy corporate *cultures* and their adoption of Lean UX.  How do you get a waterfall culture (that thinks they’re preventing risk by writing huge piles of documentation) to  feel safe trying agile UX?  What are the dangers?  I can sell the concept, but a heads-up re: what to expect once we’re running with the process would be greatly appreciated. 🙂

Comments are closed.