Does Lean UX allow working on a bigger vision?

Question

I’m working in an agile software development environment. We are currently planning on implementing three big new features within our existing enterprise software. All of them are experiencing a long and breathtaking concept phase. Large documents and high fidelity wireframes are produced and being discussed after a longer research period.

On the one hand this has nothing to do with an agile UX approach. On the other hand we do need some kind of vision for these rather big new functions. At the moment we are in some kind of transition phase where a leaner way of working will sooner or later evolve when first increments of these new functions are implemented.

Does "Lean UX" say one always has to work in a lean manner without trying to work on the big picture? Shall we always respond instantly (in small frequency) to users and stakeholders needs or is it legit in our current situation to work on the big picture for some time?

Answer 1

I'm always very allergic to articles about these kind of topics saying "this way of working is the new hype and it totally works for enterprise businesses".

My problem with Lean UX is that is says that you can focus more on the User Experience by spending less time on wireframes and prototyping and letting your user use the product sooner, but the user experience is also created in these wireframes. Spending some more time on these fases isn't a bad thing to my opinion.

And what if you work on software that you can't iterate on like you can with a web app. With software, you often have to get it right the first time. Updates shouldn't bring UI changes.

Fact is every company works different and you should implement the strategy that works best and feels best for you. So if working on the big picture for some time works for you, just do it and don't be hung up in thinking you're not working lean anymore.
Just take the lean UX rules as guidelines and make sure the concept phase doesn't take unnecessarily long.

Answer 2

Lean UX is driven by principles, not prescriptions

As Lean UX has gained popularity, it's not surprising that it's been translated into a set of prescriptions like "don't create hi-fi wireframes", or "design must be cross-functional".

In fact, Lean is not about these rigid prescriptions at all. Lean UX is driven by a core set of informed principles such as:

• A belief in the benefits of early and cross functional collaboration, because that collapses isolated, disconnected, and time-consuming linear/waterfall processes
• A belief in small team development, because that improves focus, communications, and overall teamwork
• A belief in continuous and early discovery, because that reduces waste in the development process
• etc.

(for a fuller list, Jeff Gothelf starts his book on Lean UX by defining a set of core lean UX principles).

These principles don't require you to avoid hi-fi wireframes, or to charge recklessly towards a premature customer release. What they provide instead is a clear set of principles around how and why to practice lean UX in a method that is effective for your situation.

---

For example, hi-fi wireframes may not make sense for many environments because they come at the cost of early customer validation. But in some environments, a hi-fi wireframe may be the right Lean UX approach:

1. In a complex enterprise systems a hi-fi design wireframe may help reduce expensive and time-consuming front-end coding time, allowing a product to reach customer validation faster.

2. For a large, multi-tiered application, a detailed high-level storyboard may provide a much better unifying document for sub-teams, which can then work effectively with low-fi wireframes and prototypes while minimizing wasted miscommunication across modules and teams.

For both of these examples, high fidelity design provides the right Lean UX practice because the approach maximizes the use of Lean principles to drive real benefits to the project.

The same applies for any other Lean UX prescription (like "early customer validation"....sometimes premature validation can waste more time and effort than a later, more thoughtful prototype).

Hope that helps.

Answer 3

The fundamental goal of Lean UX, as I understand it, is to reduce uncertainty.

A desired side-effect of this is that you don't waste time & resources, but this is merely a pleasant byproduct, not the process or goal itself. If racing into design iterations doesn't help answer more questions than it overlooks it can be detrimental to the project.

Before you can user-test an idea you still have to engage in the wide-open brainstorming & creative processes that allow for idea generation in the first place. Otherwise you put on blinders and test/refine the 1st thing you come up with, only to discover weeks later that it was a bad idea & you need to start over. Working this way your team burns momentum and might find it harder to constantly pop in & out of a creative mindset.

Those "big picture" sessions remain important, but you can still apply a Lean approach: use them to reduce uncertainty and iterate internally to uncover the inter-team questions & complications you might not otherwise consider if you jump right into prototyping.

Maybe it takes a few discussions & some experimentation before programmers realize that great UI concept is not technically feasible/affordable. Maybe the designers have an inaccurate understanding of the project's purpose and business goals, and this only emerges through discussion. There still needs to be room in the process for broad discussion to help everybody answer the questions they didn't know they had, or which they aren't qualified to realize need to be asked.

Answering those internal questions early on is equally (if not more) important as collecting & integrating user feedback. Otherwise, what 1 person does w/the meticulously validated user feedback might be entirely different from what other people expect, undermining the entire Lean process anyway.

Answer 4

There is a risk

Lean doesn’t prescribe an ignorance of the big picture, but that can creep in if you’re not careful. When you take the approach of learning and adjusting in production (which is an excellent thing) you can become a sort of UX Dev Ops, always bogged down with “bugs”.

And a solution

If you find that a lean approach is eating up all of your big picture time, you have to choose a path. You can structure your team into discovery and production groups (or whatever label works for you). Or just box your time out to create a similar division in a smaller, undivided team.