Here are my book notes from Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seined<\/p>\n
<\/p>\n
(pi)
\n“\u2026 Lean UX, which can literally transform the way you bring experiences to life.”<\/p>\n
(piX)
\n“\u2026 a new way of working\u2026”<\/p>\n
(pX)
\n“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.”<\/p>\n
(pXi)
\n“The problem is the systems we use to build companies. We are still building linear organizations in a world that demands constant change.”<\/p>\n
(pXi)
\n“\u2026 return the focus to where it belongs . . . delighting customers.”<\/p>\n
(pXiii)
\n“\u2026 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 . . .\u00a0 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.”<\/p>\n
(pXiv)
\n“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.”<\/p>\n
(pXV)
\n“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.”<\/p>\n
(pXV)
\n“This book is for interaction designers who know they can contribute more and be more effectives with their teams.”<\/p>\n
(p5)
\n“innovation powered by \u2026 direct observation of what people want and need in their lives . . . ”<\/p>\n
(p6)
\n“Individuals and interactions over processes and tools . . . conversations with colleagues.”<\/p>\n
(p6)
\n“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.”<\/p>\n
(p7)
\n“Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and gets team building quickly and learning quickly.<\/p>\n
(p7)
\n“Each design is a proposed business solution – a hypothesis.”<\/p>\n
(p8)
\n“Principle: Progress=Outcomes, Not Output”<\/p>\n
(p9)
\nGOOB = “getting out of the building”<\/p>\n
(p10)
\nPrinciple: Externalizing Your Work<\/p>\n
(p11)
\nPrinciple: Making over Analysis<\/p>\n
(p11)
\nPrinciple: Learning over Growth
\nLean UX favors a focus on learning first and scaling second . . . scaling an idea that is unproven is risky. It might work. And it\u00a0 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.”<\/p>\n
(p12)
\n“stakeholder conversation becomes less about what artifact is being created and more about which outcome is being achieved.”<\/p>\n
(p18)
\n“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.”<\/p>\n
(p18)
\n“DECLARE ASSUMPTIONS >> CREATE AN MVP >> RUN AN EXPERIMENT >> FEEDBACK & RESEARCH”<\/p>\n
(p20)
\nProblem Statement Template
\n1. The current goals of the product or system
\n2. The problem the business stakeholder wants addressed (i.e., where the goals aren’t being met)
\n3. An explicit request for improvement that doesn’t dictate a specific solution.<\/p>\n
(p21)
\nBusiness Assumptions
\n4. The #1 Value a customer wants to get out of my service is . . .
\n6. I will acquire the majority of my customers through \u2026.
\n7. I will make money by \u2026
\n8. My primary competition in the market will be \u2026<\/p>\n
(p21)
\nUser Assumptions
\n1. Who is the user?
\n2. Where does our product fit in his work or life?
\n3. What problems does our product solve?
\n4 When and how is our product used?<\/p>\n
(p30)
\nWe will [create this feature] for [this persona] In order to achieve [this outcome]<\/p>\n
(p33)
\n“But its not design-by-committee”<\/p>\n
(p34)
\n“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.)<\/p>\n
(p37)
\nDesign Studio . . . diverge . . . emerge . . . converge<\/p>\n
(p47)
\nStyle 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.<\/p>\n
(p54)
\nopen sourcing the design process brings the entire team deeper into the project<\/p>\n
(p57)
\nCreating an MVP: Is there a need fro the solution I’m designing? Is there value in the solution and features I’m offering?<\/p>\n
(p58)
\nPrioritize ruthlessly<\/p>\n
(p58)
\nMeasure 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.<\/p>\n
(p58)
\nRegardless 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.<\/p>\n
(p68)
\nTo 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?<\/p>\n
(p69)
\nTypes of Non-prototype MVPs
\nEmail, open-rates, click-throughs, and task completion rates, Google Ad-words, landing page.<\/p>\n
(p70)
\nDesign only what you need. Deliver it quickly. Create enough customer contact to get meaningful feedback fast.<\/p>\n
(p73)
\nassumptions and validation<\/p>\n
(p73)
\nCollaborative research techniques that allow you to build shared understanding with your team<\/p>\n
(p74)
\nContinuous Collaborative, collaborative discovery<\/p>\n
(p75)
\nCollaborative discovery in the field. As a team review your questions, assumptions, hypotheses . .\u00a0 .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 \u2026 meet with customers\/users \u2026 one team member conducts interviews while the other takes notes \u2026 Demonstrate the MVP later in the session and allow the customer to interact with it<\/p>\n
(p76)
\nsequential 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.<\/p>\n
(p76)
\nContinuous Discovery
\nbuilding a regular cadence of customer involvement . . . hypothesis creation, experiment design, and user feedback, allowing you to validate your hypothesis quickly.<\/p>\n
(p77)
\nthree users every Thursday<\/p>\n
(p78)
\nSpend 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.<\/p>\n
(p79)
\nminimally viable process<\/p>\n
(p79)
\nThe 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.<\/p>\n
(p81)
\nprocess is often handed over to specialists who are asked to synthesize research findings.\u00a0 You shouldn’t do things this way. Instead, work as hard as you can to make sense of the data as a team.<\/p>\n
(p82)
\nwe 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.<\/p>\n
(p86-87)
\nCustomer support agents . . . What do customers love this month? What do they hate?<\/p>\n
(p87)
\nWe 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.<\/p>\n
(p95)
\nThe meeting cadences of Scrum are clear guideposts for Lean UX integration.<\/p>\n
(p95)
\nA truly cross-functional process requires that everyone be a part of it.<\/p>\n
(p95)
\nDesign as a team sport. Ensuring that the once-closed design process is now open to all team members is key to your success.<\/p>\n
(p96)
\nUser Story: As a [user-type] I want to [accomplish something] so that [some benefit happens]<\/p>\n
(p99)
\nEach theme should be kicked off with a series of brainstorming and validation exercises \u2026 The point of kickoff is to get the entire team sketching and ideating together, creating a backlog of ideas to test and learn from.<\/p>\n
(p105)
\nBeyond the Scrum Team
\nManagement 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.\u00a0 Product owners, stakeholders, CEOs, and clients all want to know how things are going. They all want to bless the project plan going forward.\u00a0 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.\u00a0 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.<\/p>\n
(p109-110)
\nLean UX is a mindset \u2026 key methods \u2026 a process \u2026 management method \u2026 shifting from output to outcomes \u2026 collaborative capabilities \u2026 embracing new skills \u2026 creating cross-functional teams \u2026 small teams \u2026 open, collaborative workspaces \u2026 not relying on heroes \u2026 eliminating “Big Design Up Front” \u2026 speed first, aesthetics second \u2026 UX debt \u2026 managing up and out<\/p>\n
(p110)
\nLean UX teams measure their success not in terms of features completed but in terms of progress toward specific outcomes \u2026 they must be empowered to decide for themselves which features will create the outcomes their organizations require \u2026 which business metrics require the most attention.<\/p>\n
(p110)
\nProduct 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.<\/p>\n
(p111)
\nSilos are the death of collaborative teams<\/p>\n
(p111)
\nDesigners must add facilitation as one of their core competencies.<\/p>\n
(p112)
\nThe team — not the individual — must own the product design.<\/p>\n
(p112)
\nDesigners must take a leadership role on their team.
\nYour colleagues are used to critiquing your design work. What they’re not used to doing is co-creating that design with you.\u00a0 Your leadership and facilitation in group brainstorming activities such as Design Studio can create safe forums for the entire team to conceptualize your product.<\/p>\n
(p112)
\nAllow your designers to attend “developer meetings” and vice versa.<\/p>\n
(p113)
\nLarger groups of people are less efficient than smaller ones.\u00a0 This makes intuitive sense. But less obvious is this: a smaller team must work on smaller problems.<\/p>\n
(p113)
\nBreak 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.<\/p>\n
(p114)
\nMany designers want to be heroes.<\/p>\n
(p114)
\nRequirements go in one end of the design machine and gorgeous artwork makes its way out \u2026 however those glossy deliverables can drive bad corporate decisions.<\/p>\n
(p114)
\nThe 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.<\/p>\n
(p116)
\nSpeed first, aesthetics second. Get it done. Get it out there. Discuss. Move on.<\/p>\n
(p116)
\nSpeed trumps aesthetic perfection<\/p>\n
(p116)
\nFor some designers, Lean UX threatens what they see as their collective body of work, their portfolio, and perhaps even their future employability.<\/p>\n
(p117)
\nTo 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.\u00a0 Add these stories to your backlog. Advocate for them.<\/p>\n
(p117)
\nThe basic agency business model is simple, after all: clients pay for deliverables, not outcomes. But agency culture is a huge obstacle as well.<\/p>\n
(p118)
\nincreasing collaboration between client and agency, and working to change the focus from outputs to outcomes.<\/p>\n
(p119)
\ntime and materials \u2026 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.<\/p>\n
(p119)
\nlead with conversation, and trail with documentation<\/p>\n
(p120)
\nLean 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. \u00a0 So with the freedom to pursue your agenda comes a responsibility to communicate that agenda.<\/p>\n","protected":false},"excerpt":{"rendered":"
Here are my book notes from Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seined (pi) “\u2026 Lean UX, which can literally transform the way you bring experiences to life.” (piX) “\u2026 a new way of working\u2026” (pX) “How is it that our departmental silos are operating with […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2949","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/tibetantailor.com\/index.php?rest_route=\/wp\/v2\/posts\/2949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/tibetantailor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/tibetantailor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/tibetantailor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/tibetantailor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2949"}],"version-history":[{"count":17,"href":"http:\/\/tibetantailor.com\/index.php?rest_route=\/wp\/v2\/posts\/2949\/revisions"}],"predecessor-version":[{"id":2967,"href":"http:\/\/tibetantailor.com\/index.php?rest_route=\/wp\/v2\/posts\/2949\/revisions\/2967"}],"wp:attachment":[{"href":"http:\/\/tibetantailor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/tibetantailor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2949"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/tibetantailor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}