Lean UX

, or give customers better software faster.

I started reading ‘LEAN UX, Designing Great Products with Agile Teams’. Good ideas, but I’ve had a hard time reading it. It takes an approach to convince the reader why they should do Lean UX, and this permeates the book. The actionable information is drowned out with things like history, benefits, and more “why you should do this”.

The thing is, I’m already convinced. Let’s do it. Get to the point so I can start doing it.

So, instead of being all negative, I’m going to write the version I would have preferred: an actionable guide to doing Lean UX. This will probably take a few posts to do, so follow me to find out when the next one is posted.

This is a condensed version of Part 1 of the book. Buy & read it if you want. I’ll even add page numbers. Here’s a link I don’t get kickbacks for.

Principles of Lean UX (pg. 7)

1. User experience (UX) design, meaning designing products based on human factors, like how we perceive & process information.
2. Agile software development: If you don’t do this, start. It’s a long road to implement at your organization, but it’s non-negotiable. After 20+ years and widespread adoption from successful companies, if you’re company isn’t doing it, they’re arguably wasting time and money, and not trying to make customers happy.
3. Lean startup, or a tight build-measure-learn feedback loop with your product development. Another no-brainer.

Aspects of the Team doing Lean UX (pg. 10)

1. The agile team should be cross-functional. Folks on the team shouldn’t have to go outside the team for answers.
2. The agile team should be small, dedicated, and colocated. On dedicated, if a team member is split 50/50 with another team, it increases the amount of time the team will interacts with them. On colocated, getting a response via chat can take anywhere from a few seconds to a few days. Getting a response from someone next to you is almost always a few seconds. Do the math.
3. The agile team should be self-sufficient and empowered. They should be able to make their own decisions, and to learn from them.
4. The agile team should be problem-focused. There’s a quote on Product Managers I think applies to anyone in software development: “You should love the problem, not the solution”. This is because the team is focused on solving something for customers, and not having preconceived notions on how to do that.

Team Culture (pg. 12)

1. Move from doubt to certainty.
2. The focus should be on outcomes, not outputs. It’s not what’s built. It’s how what’s built affects customers.
3. Remove waste. Tighten the build-measure-learn feedback loop.
4. Share understanding so you raise everyone’s product knowledge.
5. There isn’t/shouldn’t be a single person who carries the team. Everyone contributes equally.
6. Failure is part of success, not the opposite of it.

The Lean UX process at a high level (pg. 14)

1. Work in small increments to minimize risk.
2. Adopt continuous discovery, like usability testing, customer interviews, and quantitative product data.
3. Test ideas with customers as soon, and as often, as possible to find things out sooner rather than later.
4. Externalize work, like poster boards, sticky notes, and whiteboards to encourage interaction, ideas, & include everyone’s voice. Physical content always gets noticed more than digital. It’s why we still have billboards.
5. Build > discuss & meet. The law of decreasing returns is particularly unforgiving to opinions when considering what should be built.
6. I won’t go into this one because I I think it’s redundant.

There you go: the 18 pages (team culture ends on page 17) of Part 1 condensed to a single, 3 minute read, post. If you want more info, or need convincing why you should do the above, read the book. Another link here.

Otherwise, this will do.

Stay tuned for my “actionable guide” version of Part 2. It’s 94 pages. Let’s see if it can boil it down to 1 post…