Drilling Into Lean UX

Ambrose: In a couple places, you mention the value of keeping your teams small. I’m sure you are quite aware that there are some pretty large software projects out there, though.

Do you have any ideas/recommendations for those in that kind of situation? Are there ways of, for instance, breaking into smaller teams for Lean UX while still tackling larger solutions that you have seen work well?

Jeff: As team sizes grow, communication suffers. As communication suffers, the team increasingly relies on documentation to ensure nothing is missed. This increases the workload on the team, focusing them on tasks that add little value to the project and taking them away from tasks that move the team forward.

In these situations, look for logical ways to break the larger team up into smaller, more nimble groups. Keep those groups as cross-functional as you can and provide regular opportunities for them to coordinate with each other, such as daily standups, scrum of scrums, and the like.

Ambrose: In Chapter 3, one of the early activities you describe is “feature brainstorming.” I have seen a tension between thinking about features and thinking in terms of user stories. It is similar to problem vs. solution, and my experience has been that it is way too easy for team members to jump to solutions, often bypassing taking time to really understand contexts of use, actual users, and their desires. It felt like this was being short-circuited in favor of a focus on features.

Maybe it’s a terminology issue, but do you see value in capturing and starting from stories and/or storyboards rather than from features?

Jeff: The main focus of the team should be the outcomes the project or product is trying to achieve. These can initially be captured as user outcomes but should ultimately be translated up into business outcomes. Using our desired outcomes as a filter we can prioritize features more objectively–whatever technique gets you to the point where you have an objectively prioritized list of hypotheses fastest is the one you should use.

I’ve been in situations where bringing in some visualization artifacts has moved the process along faster. The goal is not to present them as “done deals” but more of conversation starters for the rest of the team to take inspiration from and to drive discussion.

Ambrose: One of the things that I loved was your treatment of MVPs as prototypes. “P” is for both Product and Prototype, right? I also liked thinking about MVPs as more of an MVF—Minimum Viable Feature, if you will.

I think the concept of Minimum Viable Product is challenging for new and potentially innovative products.There is the concern about competitors poaching ideas before you can get your full value into the market, but maybe more so there is the concern of being too minimal—not having enough value or just missing too much, and so exposing yourself to the potential for being prejudged by the market/users.

Do you have any advice for figuring out the Viable part?

Jeff: In our work, we define MVP as the smallest thing you can do or make to test your hypotheses. Sometimes that’s a workflow and sometimes that’s a feature. The scope of the experiments you run to test your MVP’s doesn’t have to yield statistical significance– just enough direction to let you know if you should continue exploring this path. This will inevitably require you to expose your work to your market.

Is there risk of having your idea poached? Sure, but it’s small. And even if it is stolen, that’s simply further validation that you’re on to something.

Ambrose: You advocate for involving the whole cross-functional team in research instead of having a dedicated team focused on research. When do you see this approach not working for product teams, and do you have any suggestions for maybe meeting halfway?

Jeff: The fastest way to gain insight from customers AND to build team-wide shared understanding of the customer and their needs is through collaborative discovery. That being said, there will come a time in the project where people must return to their core competencies at which time, reducing the number of people actively running the research is fine.

This does not, however, excuse the rest of the team from ignoring the findings of the ongoing research activities, nor should it keep them from being invited to continually participate.

Ambrose: In Chapter 7, you say, if “you work on packaged software, or embedded software, or deliver software to an environment in which continuous deployment is difficult or impossible, Lean UX may not be a great fit for your team.” As someone who has worked in such environments, I don’t like this answer.

Have you thought any more and/or discovered ways to bridge the gap to a more Lean UX approach for those sorts of environments?

Jeff: The concern here is that you don’t get to continuously improve the product. You get, for example, an annual release to correct and improve the experience. Of course you can still use many of the Lean UX techniques to build shared understanding and to inform the existing release cycle and plan and nudge the product in a more accurate direction, but until you can launch actual software into the market, the quantitative side of the puzzle will be missing.

Ambrose: In Chapter 8, you say:

“For some designers, Lean UX threatens what they see as their collective body of work, their portfolio, and perhaps even their future employability. These emotions are based on what many hiring managers have valued to date—sexy deliverables. Rough sketches, ‘version one’ of a project, and other low-fidelity artifacts are not the makings of a ‘killer portfolio,’ but all of that is now changing.”

What is the evidence you see for that changing?

Jeff: For better or worse, you’re seeing job descriptions now for “lean ux designers.” I know from our hiring experience what we’re interested in is the story a candidate can tell about their contribution to a project and how they solved challenging problems.

Other evidence has been largely anecdotal from conversations with hiring managers who are not impressed by a wireframe deck. They want to know the thinking behind the straight lines and drop shadows. That’s where the real insight lies.

Ambrose: What are you working on now that you feel is important to advancing the practice of Lean UX?

Jeff: The most recent thing that I’ve been working on and pretty pumped about is Lean Day: West (www.leandaywest.com). Would love for your readers to know about it and attend if they can!

Ambrose: Lastly, if there was one thing that didn’t make it into the book but that you have learned since and would now add, what is it?

Jeff: One thing we focus on a lot these days is transparency. Working in a lean way is new to many organizations as well as the managers in those companies. Change is always scary especially when other bosses are asking the same questions they always have.

If you’re trying these new methods and want to do as much as you can to clear the path ahead of you, be transparent. Make sure your colleagues and your managers know what you’re doing, what’s going well, what’s not, what you’re learning and what you’re planning on doing next. Make it public. Use monitors or printouts all over the office. Hold demo days and invite everyone (free food helps).

The more people know what you’re up to, the more interested they’ll be. In addition, the more informed your managers will be–which gives them comfort–which keeps them out of your way.