INTERVIEW - Like many other improvement methodologies, LeanUX shares a lot of principles with traditional lean. Yet, the two communities don’t know a lot about each other. We ask an expert to bridge the gap.

Interviewee: Will Evans, Chief Design Officer, PraxisFlow and expert in lean software development, LeanUX and lean startup

Planet Lean: What can lean and LeanUX learn from one another?

Will Evans: Over the last few years the LeanUX community has emerged, together with the lean startup community, and we have noticed that all these communities of practice share a lot of commonality. Ours [LeanUX] is very vibrant and new, but these people didn’t understand the origins and general principles of lean.

We looked to find ways to see each other’s communities and share ideas, to make connections so that we could all learn from each other and benefit. The LeanUX community focuses on customer research and understanding and validating what customer value is, and we have been able to bring that into the lean community. At the same time, they have taught us a lot, especially around managing our flow, thinking in terms of cycle times, reducing batches, constantly looking for kaizen, etc. There is a lot of common, but I think it is the differences that we learn most from.

PL: Another immediate connection that comes to mind is between LeanUX and lean product and process development (LPPD) – can we have an example of something the two communities have in common?

WE: One specific example is the LPPD notion of set design, especially as it refers to early product discovery. You know your customer has a problem and you want to create a solution, but you don’t necessarily know what it is and so you create a number of possible options, through prototyping for instance. Then you gather data by putting the prototype in front of customers, you slowly apply constraints until you end up developing something that really meets customer needs. The nice thing there is that it de-risks your system while also preventing a lot of rework.

LeanUX has a lot of the same notions: once we have explored the customer and their problem, we generate a lot of possible solutions (starting with sketching, all the way to prototyping) testing three, four, five different options and then starting to apply the constraints based on feedback, analytics, qualitative research. This allows us to slowly narrow what we are actually going to deliver before we have spent any engineering time building the product.

This is one of the places where there is a lot in common between LPPD and LeanUX. We use different words, but the underlying principles and processes are very similar. This is one of the bridges we can build to find common ground, to then start exploring new places together.

That’s the key – how do we translate LPPD language to LeanUX, LeanUX language to LPPD, and so on. Rubbing these communities together will improve all of us, and give us all opportunities to learn.

PL:  You took part in this year’s Lean Transformation summit in New Orleans. What was your presentation about?

WE: I was very excited to be invited by John Shook to speak at the summit. The session I held was called, Designing Experiments Using Lean User Experience Design. What I wanted to cover was the step-by-step process through which teams can figure out how to design an experiment to learn, move forward and solve the problems they are facing. I had quite a number of good people that came in. I think they appreciated the session as well as Lean Coffee [a new structured, but agenda-less format for meetings co-created by Jim Benson]: instead of people asking me questions directly and me being the expert dictating what the answer should be, attendees share their questions around the table and unpack each of them. People really enjoyed that.

_{THE INTERVIEWEE}