Here are my book notes from Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seined
"… Lean UX, which can literally transform the way you bring experiences to life."
"… a new way of working…"
"How is it that our departmental silos are operating with agility, but our companies are hopelessly and rigid and slow? . . . Although our departments may value agility, the interconnections between them are still mired in an antiquated industrial past."
"The problem is the systems we use to build companies. We are still building linear organizations in a world that demands constant change."
"… return the focus to where it belongs . . . delighting customers."
"… remove waste from our UX design process. We move away from heavily documented handoffs to a process that creates only the design artifacts we need to move the team's learning forward. Second, they drive us to harmonize our "system" of designers, developers, product managers, quality assurance engineers, marketers, and others . . . Instead of relying on a hero designer to divine the best solution from a single point of view, we use rapid experimentation and measurement to learn quickly how well (or not) our ideas meet our goals."
"Lean UX breaks down the barriers that have kept software designers isolated from real business needs on the one hand and actual implementation on the other."
"simultaneously trying to discover how this new product or service will be used, how it will behave, and how we are going to build it."
"This book is for interaction designers who know they can contribute more and be more effectives with their teams."
"innovation powered by … direct observation of what people want and need in their lives . . . "
"Individuals and interactions over processes and tools . . . conversations with colleagues."
"Responding to change over following a plan. The assumption in Lean UX is that the initial product designs will be wrong, so the goal should be to find out what's wrong with them as soon as possible."
"Lean Startup uses a feedback loop called "build-measure-learn" to minimize project risk and gets team building quickly and learning quickly.
"Each design is a proposed business solution - a hypothesis."
"Principle: Progress=Outcomes, Not Output"
GOOB = "getting out of the building"
Principle: Externalizing Your Work
Principle: Making over Analysis
Principle: Learning over Growth
Lean UX favors a focus on learning first and scaling second . . . scaling an idea that is unproven is risky. It might work. And it might not. If it doesn't work and you've scaled it out to your entire user base, your team has wasted valuable time and resources. Ensuring that an idea is right before scaling it out mitigates the risk inherent in broad feature deployment."
"stakeholder conversation becomes less about what artifact is being created and more about which outcome is being achieved."
"Outcomes: The signal we seek from the market to help us validate or invalidate our hypothesis. These are often quantitative but can also be qualitative."
"DECLARE ASSUMPTIONS >> CREATE AN MVP >> RUN AN EXPERIMENT >> FEEDBACK & RESEARCH"
Problem Statement Template
1. The current goals of the product or system
2. The problem the business stakeholder wants addressed (i.e., where the goals aren't being met)
3. An explicit request for improvement that doesn't dictate a specific solution.
4. The #1 Value a customer wants to get out of my service is . . .
6. I will acquire the majority of my customers through ….
7. I will make money by …
8. My primary competition in the market will be …
1. Who is the user?
2. Where does our product fit in his work or life?
3. What problems does our product solve?
4 When and how is our product used?
We will [create this feature] for [this persona] In order to achieve [this outcome]
"But its not design-by-committee"
"Over the long-haul, collaboration yields better results than hero-based design (the practice of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project.)
Design Studio . . . diverge . . . emerge . . . converge
Style Guide . . . 3 data points for each interaction design element . . . What the element looks like. Where its usually placed on the screen. When it should be used.
open sourcing the design process brings the entire team deeper into the project
Creating an MVP: Is there a need fro the solution I'm designing? Is there value in the solution and features I'm offering?
Measure behavior. Build MVPs that allow you to observe and measure what people are actually do, not just what people say. In digital product design, behavior trumps opinion.
Regardless of your desire outcome, build the smallest MVP possible. Remember that it is a tool for learning. Your will be iterating. You will be modifying it. You may very well be throwing it away entirely.
To plan your MVP, asking yourself the following questions: 1 What am I trying to learn? 2. What are the main signals I need from the market to validate my hypothesis? Are there any signals I can test for that will serve as indicators for my main signal?
Types of Non-prototype MVPs
Email, open-rates, click-throughs, and task completion rates, Google Ad-words, landing page.
Design only what you need. Deliver it quickly. Create enough customer contact to get meaningful feedback fast.
assumptions and validation
Collaborative research techniques that allow you to build shared understanding with your team
Continuous Collaborative, collaborative discovery
Collaborative discovery in the field. As a team review your questions, assumptions, hypotheses . . .working as a team, decide whom you'll need to speak to in order to address your learning goals . . . interview guide . . . interview pairs . . . Arm each pair with a version of the MVP … meet with customers/users … one team member conducts interviews while the other takes notes … Demonstrate the MVP later in the session and allow the customer to interact with it
sequential funnel: first try to identify whether the customer is in your target audience. Then try to confirm any problem hypotheses you have for this segment. Finally, if you have a prototype or mockup with you, show this to the customer last to avoid limiting the conversation to your vision of the solution.
building a regular cadence of customer involvement . . . hypothesis creation, experiment design, and user feedback, allowing you to validate your hypothesis quickly.
three users every Thursday
Spend no more than an hour with each customer, everyone on the team should take notes . . . its spreads understanding of your customers deep into your organization.
minimally viable process
The team scaled up from three users once a week to testing every day except Monday. Their core objective was to minimize the time between concept and customer feedback.
process is often handed over to specialists who are asked to synthesize research findings. You shouldn't do things this way. Instead, work as hard as you can to make sense of the data as a team.
we always asked a regular set of level-setting questions to capture the "vital signs" of the job seeker's search, not matter what other questions, features, or products we were testing.
Customer support agents . . . What do customers love this month? What do they hate?
We did this with a standing monthly meeting with our customer service reps. Each month, they would provide us with the top 10 things customers were complaining about.
The meeting cadences of Scrum are clear guideposts for Lean UX integration.
A truly cross-functional process requires that everyone be a part of it.
Design as a team sport. Ensuring that the once-closed design process is now open to all team members is key to your success.
User Story: As a [user-type] I want to [accomplish something] so that [some benefit happens]
Each theme should be kicked off with a series of brainstorming and validation exercises … The point of kickoff is to get the entire team sketching and ideating together, creating a backlog of ideas to test and learn from.
Beyond the Scrum Team
Management check-ins are one of the biggest obstacles to maintaining team momentum. Designers are used to doing design review, but unfortunately, check-ins don't end there. Product owners, stakeholders, CEOs, and clients all want to know how things are going. They all want to bless the project plan going forward. The challenge for outcome-focused teams is that their project plans are dependent on what they are learning. They are responsive, so their typical plan lays out only small batches of work at a time. At most, these teams plan an iteration or two ahead. This perceived "short-sightedness" tends not to satisfy most high-level managers. How then do you keep the check-ins at bay while maintaining the pace of your Lean UX and Scrum processes? TWO WORDS: PROACTIVE COMMUNICATION . . . keep the conversation focused on outcomes (how you're trending toward your goal), not feature sets.
Lean UX is a mindset … key methods … a process … management method … shifting from output to outcomes … collaborative capabilities … embracing new skills … creating cross-functional teams … small teams … open, collaborative workspaces … not relying on heroes … eliminating "Big Design Up Front" … speed first, aesthetics second … UX debt … managing up and out
Lean UX teams measure their success not in terms of features completed but in terms of progress toward specific outcomes … they must be empowered to decide for themselves which features will create the outcomes their organizations require … which business metrics require the most attention.
Product requirements conversations must then be grounded in business outcomes; what are we trying to achieve by building this product? Success criteria must be redefined and roadmaps must be done away with.
Silos are the death of collaborative teams
Designers must add facilitation as one of their core competencies.
The team -- not the individual -- must own the product design.
Designers must take a leadership role on their team.
Your colleagues are used to critiquing your design work. What they're not used to doing is co-creating that design with you. Your leadership and facilitation in group brainstorming activities such as Design Studio can create safe forums for the entire team to conceptualize your product.
Allow your designers to attend "developer meetings" and vice versa.
Larger groups of people are less efficient than smaller ones. This makes intuitive sense. But less obvious is this: a smaller team must work on smaller problems.
Break down the physical barriers that prevent collaboration. Co-locate your teams and create workspaces for them that keep everyone visible and accessible. Make space for your team to put their work up on walls and other work surfaces . . . Your space planners may not like it at first, but your stakeholders will thank you.
Many designers want to be heroes.
Requirements go in one end of the design machine and gorgeous artwork makes its way out … however those glossy deliverables can drive bad corporate decisions.
The entire concept of design as hypothesis immediately dethrones notions of heroism: as a designer you must expect that many of your ideas will fail in testing.
Speed first, aesthetics second. Get it done. Get it out there. Discuss. Move on.
Speed trumps aesthetic perfection
For some designers, Lean UX threatens what they see as their collective body of work, their portfolio, and perhaps even their future employability.
To use the concept of UX debt, write stories to capture a gap analysis between where the experience is today and where you'd like it to be. Add these stories to your backlog. Advocate for them.
The basic agency business model is simple, after all: clients pay for deliverables, not outcomes. But agency culture is a huge obstacle as well.
increasing collaboration between client and agency, and working to change the focus from outputs to outcomes.
time and materials … remember, you are building software to learn, and that learning will cause your plans to change. Plan for that change, and structure your vendor relationships around it.
lead with conversation, and trail with documentation
Lean UX gives teams a lot of freedom to pursue effective solutions. It does this by stepping away from a product roadmap approach, instead empowering teams to discover the features they think will best serve the business. But abandoning the product roadmap has a cost - it removes a key tool that the business uses to coordinate the activity of teams. So with the freedom to pursue your agenda comes a responsibility to communicate that agenda.