SXSWi: Lean UX – Getting out of the deliverables business

Session:Tuesday 15th March, 2011
Speaker: Jeff Gothelf (@jboogie) from TheLadders
Hashtag: #leanux
Get the slides:  Slideshare
Also read Jeff’s Smashing Magazine article. It’s a little more eloquent than my notes ;)

This was the session I’d been hanging out for.  I’d read Jeff Gothelf’s post on Smashing Magazine a week before I came to SXSW, and it intrigued me.  We’ve been trialling a similar “lean” process at Massive, but starting with an internal project, which has worked fantastically.  However we still found we needed some form of documentation, where the prototypes could not fully express the overarching intent to the developers.

So this talk was really interesting for me, and validated much of the process we’ve already been undergoing in the latest project I have been leading back home. Here’s the notes:

We began by looking at the how UX got into the deliverables business in the first place:

UX began with information architecture, which no one had ever heard of.

Deliverables initially helped to define the practice. And this was good.
It helped to show the value of UX to the project. It helped people understand the difference between what we did, and it’s distinction from visual design and coding,

What’s happened over time?

The value of the practice has been placed on the deliverable. You get measured, hired and compensated for the value of your deliverable, not necessarily the outcome of the experience that has been created.

The value of the deliverable may not always translate into the value of the experience.

However, with interactive experiences, things evolve rapidly.

Lean UX
Inspired by the lean startup and agile movement. It’s about bringing the true nature of our work to light faster. With less emphasis on the deliverables and a greater focus on the actual experience being designed. Note: Jeff stresses the “less” – this is different to no emphasis.

What is agile?

Agile focuses on:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

What is lean?
Lean startup advocates the creation of rapid prototypes designed to test market assumptions, and uses customer feedback to evolve them much faster than traditional software engineering processes.

The Lean UX Process

Rough and quick and throwaway – sketch, sketch, sketch. This means you are less attached to ideas and concepts — the idea is there is little waste.


Quick and dirty- whatever you need to express/test the core flow.
Validate internally
Check with the internal teams, business owners, etc

Validate externally – with your clients, with users

Learn from user behavior

And then iterate!

You can’t hide behind your monitor anymore.

You need to show your work in a much more raw format. Even if it’s not finished. Share concepts and ideas early.  Get it out there, fast. In public so people can see it.

What lean UX is not.
It’s not lazy UX, you still have to work hard. You’re actually using the full gamut of your toolset.
The only thing being removed is waste.

It’s not design by committee…
You are aligning the team early, ensuring everyone feels heard, but you’re still making the final decisions as a designer.

You’re still in control. You are minimizing the amount of time going down the wrong path, as you are communicating where you are heading to your dev team early.

You don’t need the spec to keep control.
That can come at the end.

Designers don’t have to get it right the first time.

Coders don’t, they have bugs. Why do designers think they have to get it right the first time? In reality, you’ll veer off the solution path. It’s the feedback loop that aligns it back onto the right path.

You’re still the keeper of the vision.

Lean UX keeps everyone moving forward. Your clients, stakeholders, and you.
They see their fingerprints in the work itself… which is valuable.

Quality – don’t compromise.
Speed first, aesthetics second.

What about the quality of the design?

Iterations mean quality continually improves. You can get there faster, with less waste.

Talking to your developers early.
Prototype it. But not all of it! Just what you need.
Show the developers, demo it to the team.

Then show it to your customers

Fill in the gaps - the more you talk about it, the more you realize what’s missing.

Lean UX in companies

In a internal product company – focus is on getting software out. Lean UX integrates easily in this model.

Agencies don’t want to work this way, because agencies are in the deliverables business.

How to tweak the process to make it work in the agency world

Similar but different. Iterate with your client.
They become more invested in the work. They can see their fingerprints in the work.

You have to use lean UX where it makes sense.
Functional, task flown projects work really well. There’s a clear end goal.
Highly experiential marketing projects will struggle. Time to ideate and create options is essential.
Content heavy experiences – some upfront planning is necessary.
Distributed teams- it’s a bit more challenging here. If the team is part of your organization, it’s still feasible.
How to get started

  • Get everyone involved early.
  • Get cross functional team together
  • Everyone draws, presents and critiques
  • Refine ideas through 3 rounds
  • Generate tons of raw ideas
  • Huge headstart for UX
  • Early team-wide alignment
  • Team wide feeling of ownership

Lean UX is:

Being transparent, building trust throughout that transparency.
This is an evolution, not a revolution.

My opinions
Overall this was a fantastic session – the ballroom was packed out, and it was well received by the audience. As I mentioned earlier, the session really helped to validate the new process I have been trialling with the latest internal project I am working on.

The one area I would add to, is where Jeff talks about prototyping.

We need to be careful here, as prototypes can quickly end up having a high overhead if the purpose of the prototype is not defined upfront. When using prototyping for lean ux, we need to think of it as a communication tool. As Jeff mentions in his talk – prototype what you need to get the basic flow, and communicate to your team. This doesn’t necessarily mean, create an end to end prototype.

Another issue I’ve found with using prototypes as the deliverable is that to be truly lean, you don’t necessarily want to make everything work in your prototype. In many cases, when you’re doing low fidelity prototypes to test a concept, they need to be of the throwaway variety. It’s not meant to be an end to end demo.

Using a prototype as the only form of documentation is risky. In fact, when I tried this with my internal project, the general comment was, that the developers didn’t know which parts of the prototype were working (as it wasn’t end to end). It was great for me to clickthrough it and to explain the solution to developers, as I had built it. For others to click through a low fidelity prototype, it’s not as easy.

I still believe you need some form of documentation to supplement your prototypes, to “fill in the gaps”. I also believe that there are some overarching key principles that cannot be expressed and communicated solely in a prototype.

  • Jeff Young

    “I still believe you need some form of documentation to supplement your prototypes, to “fill in the gaps”.

    Agree. Prototypes help you keep focus on the UX of the key scenarios without getting sidetracked by edge cases. They also help you iterate faster and facilitate user testing.

    In smaller developments, and particularly when the UX and development teams are in the same company, lean deliverables like prototypes seem the way to go. The gaps can be filled by walking across the floor to your co-worker – a far more organic and efficient process in general. And as an added bonus – less finger pointing when the going gets tough :)

    When the projects get bigger, complexity rises or where teams are more physically and commercially separated the deliverables start to become an important reference point to keep everyone involved on the same page. The important point here is that you don’t start doing deliverables until 80% of the key UX decisions are made and agreed.

    Using deliverables (like detailed functional wireframes or requirements documents) early in the process is like trying to run in concrete boots. No fun at all. I hope never to go there again!

    Judging what kind of deliverables you’re going to need isn’t that easy at the start of a project. I’m interested in other opinions on when you need detailed specs/wireframes and when a sketch on the back of an envelope does the job.