Yesterday, I reviewed the premise that Jeff Gothelf based his argument for Lean UX on. With that out of the way, let’s take a look at what exactly Lean UX is.
Inspired by Lean and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.
A couple things strike me right off the bat. First is the term “deliverables”. He actually means documentation. Not all documentation is delivered (to the customer), and I’ve created plenty of prototypes that were delivered to the customer, so that’s a little misleading. Second is the goal of being “faster”. I’m not going to pick on this too much, because Jeff is clear that Lean UX is intended for startups and quick-to-market product strategies. Speed is important in that context. I just point it out because it’s important to keep this in mind as we continue. Faster is not always the main goal. Faster often requires trade-offs with other goals,.
Now we come to an aspect of Lean UX that I’m completely on board with. Jeff says we can’t have solitary designers perfecting every pixel in private. We must collaborate with the entire team early and often. And while I’m in complete agreement, I don’t think this is something for Lean UX to hang its hat on. This applies to every type of design and has for years. Important? Absolutely. Unique to Lean UX? Definitely not. Moving on…
Next Jeff lays out the Lean UX process: Concept > Prototype > Validate Internally > Test Externally > Learn from User Behavior > Iterate. At first glance, this just appears to be a typical, high-level design process. What you must realize, however, is that this is the detailed process. Concept doesn’t have sub-steps in which you brainstorm on a whiteboard, formalize those sketches into wireframes, and annotate them with notes about behavior. Jeff proposes that “the initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction.” What he’s inferring is that once you have a quick whiteboard sketch, you’re ready to start creating a working prototype. Spending time revising and documenting that sketch is wasteful. That’s not to say that you go with the very first sketch—there is still iteration—but there isn’t much refinement.
In some projects, this is a perfect approach, and I’ve done just that. I’ve rapidly sketched and iterated a UI concept, showed the sketches to a developer to ensure technical feasibility, and then scanned in the sketches and hooked them together to mimic navigating through the application. I presented the prototype to the customer to get their buy-in on the approach. I chose this process because it was a non-standard method of navigating the content that I thought would be particularly suitable. The customer agreed, and I continued to flesh out the details.
In other projects, I consider a prototype to be more time consuming and wasteful than some simple documentation. If I’m designing a multi-page form using tabs, I don’t have to create a working prototype for the customer to understand how it’s going to behave. They are familiar with tabs.
What I’m most uncomfortable with in Jeff’s description is the lack of any kind of formal documentation of decisions. Sure, you can throw up a rough flow on a whiteboard and hash it out with the product owner, but what are you going to do three months down the road when another stakeholder asks a question about the flow and is pressuring the team to change it? You know you had a reason for doing it that way, but it’s gone through several revisions, and you can’t quite remember the rationale. Wouldn’t it be great if you could quickly check a wiki page or PDF to see the history of decisions that led to the current design? I don’t mind admitting that I bounce around from project to project so often that I have a hard time remembering off the top of my head what I did a few days ago, let alone months. But when a developer comes to me with a question, I have a folder within reach that will provide the context necessary to focus my thoughts.
So far, the only thing that sets Lean UX apart from plain old UX is the abandonment of documentation. I don’t see much value in that. Perhaps we’ll find something more tomorrow.