Deliverables. Designers need something better to aim for if they're going to work well and care about the right things on product teams.
When a project gets close to deadline, designers can make a really big mess. I've been designing (yes, for money) for most of my life. And if I am asked at random, there's a non-zero chance I just spent the last six hours designing a custom SVG icon for an app UI.
The primary aim of a project is completion—on budget, on time, on plan. Project-led teams are bogged down by building ideas to their highest fidelity before getting any feedback. Each milestone and deliverable represents money spent on making users wait.
UX vision is stale by the time it's presented in PowerPoint.
After that, if it's not horribly disfigured by the manufacturing process, all strategic plans wind up in the creative recycling bin when reality pushes back. Rather than digging through my Figma prototypes for current design documentation, product teams are starved for new ways to view their products and understand how users interact with them beyond the interface.
As a DesignOps veteran of a variety of cross-disciplined scenarios, I have found Lean UX to be a methodology that aligns to the values and principles successful product-led teams—and even project teams looking to approach problems differently.
I spent most of 2016 experimenting with product design techniques while trying to align myself to the cadences of two software engineering teams running SCRUM. At the time, I succumbed to the misconception that Lean UX was all about squeezing as much efficiency and waste from product design budgets—an almost Brutalist focus on speed over quality and user needs.
Then, In the summer of 2018, while working with Agile teams for the Department of Defense, I discovered that Lean UX enhances Agile by enshrining a feedback loop and rigorous prioritization directly into the design process—a continuous pipeline of product user behavior and measurable business insight can be established.
By December 2021, I'd worked closely with enough product and design teams in a humble, midwestern-headquartered global technology consulting firm to become the most annoying guy in the office—The Lean UX Guy. I helped our team establish and refine foundational content and activities that convinced our design department leadership that we could begin engaging Agile teams with the training.
My job was to write the facilitation script and direct the development of key workshop activities. My team and I were a little late to the Lean UX practitioner party—experimenting directly with methods from Gothelf & Seid's book five years after it was first published. Still, we were able to extend core concepts across activities in meticulously designed whiteboards—a set of remote-first Lean UX coaching activities. I facilitated the first of these workshops and trained another facilitator in the second. It's important to note that, while I would like to praise each of the amazing people who made these two projects possible, none of what you're about to read in this case reveals proprietary client information or compromises confidentiality agreements.
In each workshop, participants were divided into two groups for what the DM in me wants to call, "Character Creation." Each group developed a proto-persona and an empathy map to represent a group of end-users. Creating characters for whom empathy can exist, enabled participants to consider users other than themselves during subsequent design decisions.
This exercise also allowed any end-users of the product in the workshop to provide additional context about their needs and behaviors.
This was the fun part—solving the problem. Both workshop groups were guided to brainstorm a number of solutions they believed would be necessary to change outcomes during the moments they identified in their Journey Map.
Each solution was carefully aligned to business objectives and user outcomes during those critical moments. This alignment ensured that their designs would deliver value during key interactions and support organizational goals.
The executive sponsors of the Sales Performance workshop expected the participants to deliver UI designs that would guide the development of a project budget. However, the workshop teams focused on using existing tools to test their hypotheses and busted critical assumptions about the nature of the product and the technical architecture required for its success. Their lean approach enabled them to test their hypotheses without a budget and ensure that their solutions were both practical and aligned with user needs.
In contrast, the team in the Public Utility workshop approached their tasks with a sprint mindset, treating the workshop as an opportunity to implement "design spikes" or focused design improvements. They concentrated on enhancing the usability of their existing product by leveraging an open-source design system to define specific UI enhancements that could be executed within their next sprint iteration, allowing for quick, iterative testing and implementation.
The hypothesis-driven approach demonstrated that even without extensive budgets, meaningful and user-centered product development is possible. By busting critical assumptions, teams can create solutions that truly meet user needs and deliver real value. This methodology encourages collaboration, continuous improvement, and a relentless focus on the user, ensuring that the right product is built, not just built right.