Lean + UX + Agile: Putting It All Together
•
94 likes•9,932 views
This document discusses how lean startup, user experience design, and agile software development can be combined to more effectively build products. It outlines some of the common pitfalls of traditional waterfall development approaches and how lean, UX, and agile aim to address them. Specifically, it emphasizes the importance of getting early customer feedback through minimum viable products and iterative development to reduce risk and build the right product.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Lean + UX + Agile: Putting It All Together
Similar to Lean + UX + Agile: Putting It All Together (20)
More from Orthogonal
More from Orthogonal (14)
Recently uploaded
Recently uploaded (20)
Lean + UX + Agile: Putting It All Together
- 1. Lean + UX + Agile: Putting It All Together Rocket Fuel For Your Product Growth Lean Startup Strategy Amy Willis Bernhard Kappe Reid MacTavish User Experience Design Lead UX Designer Founder and CEO Senior Agile PM awillis@pathf.com bkappe@pathf.com rmactavish@pathf.com Agile Software Development 312.372.1058 x 6002 @bernhardkappe Customer Acquisition and Retention pathfindersoftware.com/blog http://pathfindersoftware.com http://pathfindersoftware.com Copyright © 2011 Pathfinder Software
- 2. Pathfinder: 300+ Successful Releases
- 4. A typical waterfall project produces pages and page of end-to-end requirements for the entire project as it is envisioned (but not necessarily as it will be built). The people compiling these requirements are, of course, part of an assembly with only the most cursory involvement with others outside their department.
- 5. After all 9,238 lbs. of paper are heaved over the wall with a hearty “good luck!” and a cheery wave, the silos are once again in place and silence is golden.
- 6. The development team begins. As they develop, they begin to see gaps, inconsistencies and missing requirements. The timeline starts to stretch out...
- 7. After a long march, the software can be shown to the stakeholders. It’s not what they expected, and it’s not what they want. The software requirements need to be changed. The project falls further behind ...
- 8. The team size is doubled, but strangely, things don’t move faster.
- 9. When QA starts, lots of bugs are discovered, and when those are fixed, more bugs crop up. The project is way behind and way over budget, but finally launches.
- 10. 3 months after launch. Customers aren’t buying it. It’s not what they need (even though they requested all of the features.) The few that use it only use 20% of the features.
- 11. What went wrong?
- 12. Diagnosis I: A Failure to Communicate • No one reads the requirements and specifications • Requirements documents don’t let you visualize or experience the solution • Real feedback and communication between stakeholders is too little, too late • Software product development is inherently uncertain - change is inevitable. • Set up for failure: finger pointing instead of teamwork. “Hi Jim, Please Review For Today’s Meeting”
- 13. Agile • Self organizing teams • Deliver working software every one to two weeks • Just enough documentation • Get feedback, adjust to change, improve your processes
- 14. Feedback Loop
- 15. Diagnosis II: Bad Usability Problems: • Software isn’t intuitive to use • Software doesn’t take the user into account: their needs, their knowledge base, their environment, the flow of their activity, the way they behave • Software is written for the stakeholders not the actual users.
- 17. User Experience Design Focus: Optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product. Process: • Who are your users? • Learn as much as you can about them in the context of the problem you’re trying to solve for them/their goals. • Take that + knowledge of design best practices, cognition/psychology, ergonomics, sociology, etc. to design solutions that help them meet their goals. • Test the validity of assumptions with regards to user behavior and effectiveness of designs in real world tests with actual users.
- 18. Diagnosis III: No One Cares No one asked: “Is this problem worth solving?” “Does anyone care about your solution?”
- 19. 9 Out of 10 New Products Fail http://pathfindersoftware.com Copyright © 2011 Pathfinder Software
- 20. Business Model Problem Solution Unique Value Unfair Customer Proposition Advantage Segments Top 3 Problems Top 3 features that address the problem Single, clear, Can’t be easily Target Customers compelling message copied or bought why you are different and worth buying Key Activities Channel Activity that drives Path to customers acquisition/revenue for marketing and sales Cost Structure Revenue Model • Customer acquisition costs • Revenue Model • Distribution costs • Lifetime Value • Hosting • Revenue • People, etc. • Gross Margin
- 21. Existing Products: Validated Model Problem Solution Unique Value Unfair Customer Proposition Advantage Segments Top 3 Problems Top 3 features that address the problem Single, clear, Can’t be easily Target Customers ✔ ✔ compelling message copied or bought why you are different and worth buying ✔ ✔ Key Activities Channel Activity that drives acquisition/revenue ✔ Path to customers for marketing and ✔ ✔ sales Cost Structure Revenue Model • Customer acquisition costs • Revenue Model • Distribution costs • Hosting • People, etc. ✔ • Lifetime Value • Revenue • Gross Margin ✔
- 22. New Product: Uncertainty ? Problem Solution Unique Value Unfair Customer Proposition Advantage Segments ? Top 3 Problems Top 3 features that address the problem Single, clear, Can’t be easily Target Customers ? compelling message copied or bought ? why you are different and worth buying ? ? Key Activities Channel ? Activity that drives Path to customers acquisition/revenue for marketing and sales Cost Structure Revenue Model ? ? • Customer acquisition costs • Revenue Model • Distribution costs • Lifetime Value • Hosting • Revenue • People, etc. • Gross Margin
- 23. Your Job as an Entrepreneur: Discover a Business Model that works before you run out of Money and Time. (Then scale it.)
- 24. Feedback Loop
- 25. Customer/Problem Hypotheses Problem Solution Unique Value Unfair Customer Proposition Advantage Segments Top 3 Problems Top 3 features that address the problem Single, clear, Can’t be easily Target Customers compelling message copied or bought ? why you are different and worth buying ? ? Key Activities Channel ? Activity that drives acquisition/revenue ? Path to customers for marketing and sales ? ? Cost Structure Revenue Model • Customer acquisition costs • Revenue Model • Distribution costs • Lifetime Value • Hosting • People, etc. ? • Revenue • Gross Margin ?
- 26. Problem Interviews • Customer Demographics 1 4 (Discover Subsegments) • Validate Their Top Three Problems • Discover New Problems 2 5 • Rank the Problems • How Do They Solve Them Now? 3
- 27. Solution Hypotheses Problem Solution Unique Value Unfair Customer Proposition Advantage Segments Top 3 Problems Top 3 features that address the problem Single, clear, Can’t be easily Target Customers compelling message copied or bought ? why you are different and worth buying ? ? Key Activities Channel ? Activity that drives acquisition/revenue ? Path to customers for marketing and sales ? ? Cost Structure Revenue Model • Customer acquisition costs • Revenue Model • Distribution costs • Lifetime Value • Hosting • People, etc. ? • Revenue • Gross Margin ?
- 28. Solution Design
- 29. Solution Interviews • Recap Demographics and Problem • Describe and Show Solution (don’t 1 4 sell it!) • Does it Resonate? 2 • What’s most important, what’s missing, what can you take away? 5 • How do they find out about solutions to this problem? 3 6 • Will they pay $X?
- 30. Drill down to Minimum Viable Product (MVP) 1 4 2 5 X 3 X 6
- 31. Customer Discovery Business Model Problem Generation Interviews MVP Solution Solution Design Interviews
- 32. Example MVP Question: Are enough people interested in our service? Measure: People signing up for the product Experiment: • Create a video of clicking through visual mockups • Post it on a landing page with a sign up button • Post and promote on Digg, Hacker News, etc.
- 33. Example MVP Result: 90,000 Signups in less than three days Development completed 18 months later
- 34. Example MVP
- 35. More on MVP • Not one snapshot, but a progression of experiments • At some point, you need to start development. That’s where Agile comes in
- 36. Lean Startup: Two Fast Feedback Loops
- 37. CustDev + UX + Agile Customer Development UX Agile Development
- 38. Lean Startup = Custdev + UX + Agile Customer Development Agile Development Business Model Problem Agile Agile Generation Interviews Inception Development Path to Product Market Fit 9000 6750 4500 2250 0 Month 1 Month 6 Month 11 Solution Solution Metrics and MVP Design Interviews A/B Testing
- 39. Workflow analysis (as is, to be) Personas and Goals User Stories INCEPTION WORKSHOPS “Breadth” Visualization or Preparation for Iteration 1 Storyboarding Estimating and Prioritization CONDUCT WORKSHOPS TO BRING THE VISION TO LIFE
- 40. Personas and Goals Workshop Who: UXD, PM, Visual Designer, Lead Developer, Client •Determine the universe of people that are using or influencing the use of the product •Persona is a “representative” for each type of user •Allows for easy reference in future discussions •Includes stock photo, goals, major tasks, etc.
- 41. Workflows Workshop Who: UXD, PM, Visual Designer, Lead Developer, Client •Determine all of the workflows for each persona. •No activity should reside outside of a flow.
- 42. Why do Flows Make or Break a Project? • Help with prioritization - identify the most frequent or important flows. What are people doing 80% of the time? • Make sure important options aren’t forgotten • Confirm with the client we did not forget anything
- 43. USER STORIES WORKSHOP Who: UXD, PM, Visual Designer, Lead Developer, Client • Starting from the workflows, create a list of user stories for each feature. The format is: As a <persona>, I want to <do something> so I can <achieve something> • This is the master story list (MSL)
- 44. “BREADTH” VISUALIZATION or STORYBOARD WORKSHOP Who: UXD, PM, Visual Designer, Lead Developer, Client • Break the user story list into sections (probably flows). • Create low-fi, REALLY low-fi pictures of each screen. A quick sketch with a sharpie on an 8.5 x 11 paper is all you need • Visualize, don’t design! These pictures are not designs. They don’t have to be efficient or good from a UX perspective. The key is to visualize with speed, not design. • Everyone involved participates, including the client • the functionality is completely represented. you may come up with new stories as you go • Now go through the story list and write the name of each story on its appropriate page on the wall. No doubt, in doing this you will add new stories and find some that did not get visualized (you’ll need to make pictures for those) • Once a wall is built, write story numbers on the pictures from the MSL (master story list). As you do, you will likely come up with more stories. Also, the pictures will often suggest stories you have missed. This cross check between the stories and pictures is a great method to insure the scope of the project is well understood by everyone.
- 45. ESTIMATING AND PRIORITIZATION WORKSHOP Who: UXD, PM, Visual Designer (optional), Lead Developer, Client •Estimate the point value of each story. •Next, prioritize each story as High, Medium or Low. •Order the stories such that the early iterations give the designer time for more refinement of the overall concept.
- 46. PREPARATION FOR ITERATION 1 Who: UXD, PM, Visual Designer (optional), Lead Developer, Client •Wireframes •Acceptance tests
- 47. Wireframes
- 48. Acceptance Tests
- 49. Good Inception 1. In workshops, get things DONE 2. Avoid the tangents and rabbit holes during workshops 3. Plan in advance all the needed workshops
- 50. Agile Iterations
- 51. Waterfall Requirements Gathering Design Implementation Test
- 52. Getting from Point A to Point B B A
- 53. How to get there? Waterfall
- 54. How to get there? Waterfall Agile
- 55. Launch B A
- 56. Paddle B A
- 57. How does this work? B A
- 58. The Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan http://agilemanifesto.org/
- 59. Anatomy of a User Story Persona Goal Benefit = “As a clinician, I want to see my patient’s test results so that I can understand their health status” 1 2 3 5
- 60. Acceptance Criteria Each story is accompanied with explicit criteria that help us define being “Done” *Given* X *When* Y *Then* Z
- 62. Life of a Story Design Implementation Acceptance Test Done 1 5 3 2 3 1 2 5
- 63. Iteration Iteration Planning Meeting (IPM) 1 2 Review 2 weeks Showcase Planning
- 64. Iteration Design stories here … IPM 1 2 … so they can be Preview period implemented and tested here
- 65. Team Composition Design Implementation Test 2 UXD 4 devs 1 QA 1 BA 1 PO PM
- 66. Zoom Out – Release Timeline Inception Agile Iterations Release Target ... Intended functionality
- 67. Engineering practices • Test-Driven Development (TDD) • Pair-programming • Continuous Integration and Alpha Environment
- 69. Ultimate MVP Product
- 70. Qualitative Learning Ultimate Product MVP Qualitative and Quantitative Learning
- 71. Fast feedback Responding to change Working code delivering business value
- 72. Launch! (The team waves bye bye)
- 73. Product/Market Fit Path to Product Market Fit 9000 Customer Acquisition Cost Customer Lifetime Value/3 You Are Here 6750 4500 You Need to Get Here! Product/Market Fit: 2250 LTV/3 >= CAC 0 Month 1 Month 2 Month 3 Month 6 Month 5 Month 6 Month ? Month 8 Month 9 Month 16 Month 11 Month 12
- 74. Post Launch Goal: Increase LTV and Decrease CAC Decrease CAC Increase LTV • Changes to messaging • Improve value to customer • Changes to marketing • Add features channels • Improve Features • Does the Experience Match the Marketing? • Remove features • Changes to Optimize • Find and foster loyalty Customer Acquisition Funnel/ behaviors Experience for New Users
- 75. Post Launch Fast Feedback Loops • You have real users and precise usage data on individuals - analyze it! • Make small changes fast (hours, not weeks to get into production) • When you make changes - A/B test (or do multivariate if you have big enough volumes.)
- 77. Build Metrics Into Your MVP
- 78. Lean Startup = Custdev + UX + Agile Customer Development Agile Development Business Model Problem Agile Agile Generation Interviews Inception Development Path to Product Market Fit 9000 6750 4500 2250 0 Month 1 Month 6 Month 11 Solution Solution Metrics and MVP Design Interviews A/B Testing
- 79. Want to learn more on Lean + UX + Agile? Half Day Workshop on Friday, January 20th • Details on lean startup as well as pragmatic marketing Rocket Fuel approach For Your Product • More details on how to run a successful inception Growth • More details on agile techniques Lean Startup Strategy User Experience Design • Metrics, Continuous Deployment, A/B testing Agile Software Development • Whom to hire and how to recruit Customer Acquisition and Retention http://pathfinderleanux.eventbrite.com/ http://pathfindersoftware.com http://pathfindersoftware.com Copyright © 2011 Pathfinder Software
- 80. Lean + UX + Agile: Putting It All Together Rocket Fuel For Your Product Growth Lean Startup Strategy Amy Willis Bernhard Kappe Reid MacTavish User Experience Design Lead UX Designer Founder and CEO Senior Agile PM awillis@pathf.com bkappe@pathf.com rmactavish@pathf.com Agile Software Development 312.372.1058 x 6002 @bernhardkappe Customer Acquisition and Retention pathfindersoftware.com/blog http://pathfindersoftware.com http://pathfindersoftware.com Copyright © 2011 Pathfinder Software
Editor's Notes
- \n
- A little bit of background on Pathfinder. Been around for about 10 years, Help companies launch software products. Have over 300 successful releases under our belts. We work with startups and established companies, Medical devices, web applications, educational iPad apps for kindergartners and first graders. \n
- We&#x2019;re here in Chicago, river north in a big open, loft environment, where we incubate a number of startups.\nLots of meetings, groups that meet there in the evenings, people ride their bikes in, we&#x2019;ve got a shower in the space, lots of smart people dedicated to launching great products. \nSo we incorporated ux into our process about 8 years ago, and the lean startup approach starting about two years ago. \nShow of hands - how many product managers? designers? agile pms? enterepreneurs? non-agile pms?\nJobs.\n\n\n
- We&#x2019;ll start with a little story of a software development project.\nA typical waterfall project produces page after page documenting the end-to-end requirements for the entire project -- not for the phase or for the iteration but for the entire project. All of this work, of course, is done in a silo with only the most cursory involvement with development.\n
- Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery &#x201C;good luck!&#x201D;, the silos are once again inhabited and silence is golden.\n
- Whether the application is being implemented as designed is the big mystery until the final unveiling n months later. Unless you are one of those fortunate designers who&#x2019;s embedded in a development team and is, therefore, accessible for questions. But those types were rare.\n
- Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery &#x201C;good luck!&#x201D;, the silos are once again inhabited and silence is golden.\n
- Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery &#x201C;good luck!&#x201D;, the silos are once again inhabited and silence is golden.\n
- Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery &#x201C;good luck!&#x201D;, the silos are once again inhabited and silence is golden.\n
- Once all 9,238 lbs. are heaved over the wall at the handoff meeting with a cheery &#x201C;good luck!&#x201D;, the silos are once again inhabited and silence is golden.\n
- \n
- No one reads the requirements. They aren&#x2019;t written for non technical people, and those people don&#x2019;t have time. They&#x2019;re boring, and it&#x2019;s hard to visualize. So you don&#x2019;t get good feedback until it&#x2019;s too late.\nPlus, there&#x2019;s a fundamental mismatch of the process to how software development is. It&#x2019;s fundamentally uncertain - you will discover new things. Not measuring that, not measuring real progress. \nChange is inevitable. Discover things, come up with better ideas, get feedback, respond to market changes and technology changes - they happen fast.\nSo you&#x2019;re set up for failure: a bad process, bad communication, no teamwork and no responsibility - finger pointing. I do not envy waterfall project managers.\n\n
- A series of different approaches, from scrum and xp to crystal, etc. that address this, practitioners and leaders came together to come up with the Agile Manifesto. A lot of techniques that are used in this body of knowledge.\n\nBuild software and show it to stakeholders. Do it early, do it often. \nDon't waste time on unnecessary documentation.\nGood people take responsibility if they are given it.\nWork together and communicate. \nadapt to change.\n\n
- The key thing here is the feedback loop. Discovering, not all known. So you build, you measure, and then you learn. In agile, you&#x2019;ve got a time box for this - a rhythm - once a week or every two weeks in our case. Self organizing teams, delivering working code on regular intervals. Reid will get into that in more detail later.\n
- Problems with old system:\n* software isn't intuitive to use\n* software doesn't address user's needs\n\nWhy? \n* because everyone uses technology, they think they can design it - it it was really that easy, we wouldn't have so many bad interfaces/websites/programs\n* stuff is designed by executives\n* stuff is designed by developers\n* both of the last 2 groups are rarely the user - and when they are they are too knowledgeable about the inner workings of the product to be representative of normal users\n\nHow did this come about?\n* in the early days, software was used by the folks who wrote it, so they really were the user\n* not true anymore, but dev process hasn't changed\n\n*most people are developing software for other people, not products they would use\n* even if they would use it, just by being involved in the development process they know too much to be representative of their audience\n
- So there&#x2019;s a discipline meant to address this. There are at least a dozen different names and flavors, continuously evolving. Interaction Design, Information Architecture, Human Computer Interaction, User Centered Design, User Experience Design.\n
- We like to call it User Experience Design\nFocus: User experience design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product.\n\nWho are your users? \nLearn as much as you can about them in the context of the problem you&#x2019;re trying to solve for them/their goals.\nTake that + knowledge of design best practices, cognition/psychology, ergonomics, sociology, etc. to design solutions that help them meet their goals.\nTest the validity of assumptions with regards to user behavior and effectiveness of designs in real world tests with actual users. \n
- So there&#x2019;s another diagnosis. Maybe no one cares about the problem or your solution. It doesn&#x2019;t matter how usable it is if the problem it&#x2019;s addressing isn&#x2019;t big enough. \n
- 9 out of 10 new products, startups, etc. fail. Most of them fail because of a lack of customers and markets, not product development. They built the wrong product for the wrong people.\n\n
- Business Model - Complicated\nMaking a Business work is a complicated thing.\n\nThere's lots of moving parts that need to work together. Usually, there's lot's of ways to approach it. [business model canvas]\n\n\n
- Existing Business\nWith an existing business, a lot of those things are already well defined. \nBut at the beginning, they weren't. They had to find those things.\n\n
- New Business\nWhen you're doing a new product, starting up a new business to disrupt an industry or meet an unmet need, you're where those companies were at the beginning. \n\nNew Market, unmet need, underserved people\nA lot of those business model elements are unknown. You have hypotheses, but they are as yet unproven. And for some things, you may not even have a hypothesis.\nYour job is discovery, not \n\n\n
- Startups uncertainty\nPlus, as a startup, you have limited time to figure it out. Even if you're well funded, and you're doing new product development at a big company. No results, no job, no funding.\nSo there&#x2019;s an approach for this called customer development. \n
- So we&#x2019;re back to the feedback loop we&#x2019;ve already seen: This is like the scientific method. We have business model hypothesis. We figure out how to measure whether it&#x2019;s valid or not, and then design the minimal experiment to get that measurement. You have a lot of validation to do, and some of your hypotheses are going to be invalid. In that case you pivot. You want to run through a lot of learning loops quickly, before you run out of budget and time. \n
- At the start, we tackle the big problems \n
- What we do is &#x201C;genchi gembutsu&#x201D; as they say in lean manufacturing - go to the source, the customer and find out. It&#x2019;s about as fast and easy a way to find out if you&#x2019;re solving a problem worth solving. You interview them on their problems. Demographic questions let you find subsegments of earlyvangelists. Validate, ask them if there are problems you haven&#x2019;t mentioned, have them rank the problems. If you&#x2019;ve nailed the problems, you&#x2019;ll know. If it&#x2019;s not a top 3 problem, problem $10.\n
- \ntypically, the big assumptions. a problem worth tackling, does anyone care?\n
- In solution design, you&#x2019;re using information from customer interviews to put together personas, workflows, and low fi wireframes (hand sketched, paper is usually good enough to start. You&#x2019;re designing a high level solution to show to customers. By the way, when you&#x2019;re doing problem interviews, solution design and customer interviews, you know who&#x2019;s good to have involved? User Experience Designers.\n
- So again, usually the easiest thing to do is to take these hand sketched wireframes to prospective customers and get their feedback. Does it solve their problem? If they need a feature, ask them wy - drill down further on the problem, don&#x2019;t just take the answer at face value. If you&#x2019;re on the right track, you&#x2019;ll know from the feedback. What&#x2019;s most important, what&#x2019;s missing, what can you take away?\n
- What you can take away is really important. Remember, you&#x2019;re trying to run the minimal experiment that validates or invalidates your hypotheses. \n
- So this part of customer development, getting down to mvp is called customer discovery. \n\n\n\n
- \n
- \n
- \n
- The main point here is that mvp isn&#x2019;t a snapshot - it&#x2019;s a progression of experiments to validate hypotheses, and the early experiments often don&#x2019;t involve building software. Dropbox is only one example.\n
- Lean Startup takes the customer development fast feedback loop for hypothesis testing and couples that with another fast feedback loop - agile development. As an aside, customer development is the approach we use for new products. We use pragmatic marketing&#x2019;s product management approach. \n
- UX was involved in the early customer development to get to mvp, but in continues to be involved in agile development. It overlaps on both.\n
- So our approach integrates lean startup thinking, validating business model assumptions by going out and talking to customers about their problems and how they solve them (otherwise known as user research) sketching and prototyping solutions, drilling down to a minimum viable product, and building rapidly and delivering software weekly with agile iterations, or multiple times a day with continuous deployment, and then measuring the effectiveness with user based metrics. \n\n\n\n
- The purpose of inception is to figure out the entire breadth of the product and get ready for efficient development. You take the results of customer development as inputs. Do an iterative series of structured workshops that enable you to drill down into more detail and gain new insights into the solution space. Typically one to four weeks, depending on the size of the project. \n
- Personas: Who you are building this for. Includes not just obvious users, but other people who influence or are influenced by those that are using product. Ex: client who thought they had 4 users, one of which was a doctor. We determined that while doctors were a stakeholder - the software was used in their offices - but the doctor wasn&#x2019;t actually using the software, their administrative staff is. And the administrative staff could be a nurse, who has clinical background and would understand medical terminology, or the front office secretary who probably doesn&#x2019;t. Knowing that not all users have clinical background could affect things like terminology used. In the end, we identified 28 users for this client&#x2019;s product, not the 4 they originally thought.\nAnother example: educational games. Kids are clearly target audience. But parents have a stake in what is designed for their kids. As might teachers and school administrators who need to track progress of their students.\nHelps client frame who really uses their product, who they need to take into consideration. Also provides reference later in dev cycle when they want to add a feature you don&#x2019;t think is necessary or useful. Discussion becomes not about what the client wants or what you want, but which user would find this useful and to accomplish what goal.\nFor UX folks, there is an ongoing debate about the usefulness of personas. We don&#x2019;t do detailed ones about the life of the person (&#x201C;Sally, who is 45, has 3 kids and a dog, and likes long walks in the park&#x201D; We concentrate on useful information related to the the software, their knowledge base, their goals, and how they will use the software.\n
- Flows: show steps at a high level that the user needs to go through to accomplish a task. Looks at the what, not the how\nIncludes decision points and alternate routes\nEx: Beginning of a flow may be that the user logs in. Need to include an option for a user that doesn&#x2019;t have an account. Might be forgotten otherwise.\n\nFlows are the key to expressing a digital product, even a complex one, in a digestible set of &#x201C;things.&#x201D; A product may have 200 user stories (individual steps), but only about 10 or 15 major flows. It&#x2019;s easier to grapple with 15 things than 200. \n
- \n
- purpose: finer details than flows. each step w/in flow and all options\n
- purpose: visualize entire product\nmake sure you haven&#x2019;t missed any steps\neverything user needs to complete each task is accounted for\neasier to judge scope and estimate time it will take for development (Reid will talk about this more in a few minutes)\n\n
- Purpose is to figure out how long this will take to build. Then scale back based on time and/or prioritize what to build first.\nPoint value is how long it will take to build - includes dev team to determine points.\n\nUX folks will notice a standard component of our jobs is missing this far - WIREFRAMES.\nThey come last, and are part of the next step\n
- Identify technical spikes and environment set up that the developers can work on to enable more time to evolve the design organizing concept or information architecture\n\nThe designer&#x2019;s mission during an iteration is to get the stories for the next iteration specified. This includes wireframes and acceptance tests. The designer must also respond to issues in the design that come up as well as address higher level design issues that may not yet be addressed. Time management is important, especially in one week iterations. It&#x2019;s also important to get help when necessary, almost every project at some point needs more than one person addressing wireframes and acceptance test creation. \n\nWireframes are generally done with call outs and logical notes on the side. This format allows the developer to work from the picture and get needed logic in context. \n
- Wireframe is the detailed design of each page/screen, including details about all the interactions (what happens when a user selects this, moves that, enters data here)\nAre traditional part of UX work\nCan be as detailed as needed\nDon&#x2019;t include visual design - often black and white \nAre UX equivalent of architect&#x2019;s blueprints - show scale, what, where, how to build, but not decorations and where individual furniture will go, but takes into consideration what needs to fit in the room\n\nWireframes are generally done with call outs and logical notes on the side. This format allows the developer to work from the picture and get needed logic in context. \n
- The designer should stay one iteration ahead of the developers in the idealized case\n
- 4. Three Pieces of Advice for a Good Inception\nInception is crucial to project success. It&#x2019;s important to get off to a good start. Here are three key pieces of advice that can help lead to a good inception:\n\nIn workshops, get things DONEEach workshop needs to define what needs to get done after the workshop is over. If the workshop is to generate personas and goals, personas and goals must be done after that workshop (including the follow up time to produce the artifacts). \nAvoid the tangents and rabbit holes during workshopsWorkshops MUST stay focused on the objective. ANYTHING that comes up that is not related to the objective should be put in a parking lot immediately. Set the rules up front so when someone goes off on a tangent you can quickly get the issue in the parking lot and get back on topic. Have a part of a white board or a sticky sheet on the wall for parking lot items. If you don&#x2019;t stay on topic, you won&#x2019;t get things done. This can&#x2019;t be emphasized enough. If the designer is running the workshop, the PM (or another team member) can play the role of keeping everyone on track. \nPlan in advance all the needed workshopsEvery project is different. Plan in advance the exact workshops you need during the inception. Don&#x2019;t leave things out. Use the process description to reference which workshops you need. Ideally, all of the needed workshops should be included in the estimate of how long inception will take. \n\n
- \n
- I&#x2019;d like to further explain Agile by comparing it to waterfall. \n\n<Walk-through model>\n\nIf, for example, during the Implementation phase you run into Integration problems or you missed some key requirements, earlier phases (which occurred months ago) are put to blame. \n\nTo be fair, I have seen some models of Waterfall that attempt to build in room for course correction with various loops. \n\nBut this model illustrates the prevailing mindset with Waterfall. \n
- \n&#xA0; &#xA0; &#xA0;Imagine our organization is at the origin. We need to build a product that our market wants &#x2013; symbolized by this buoy\n
- So, how do you want to travel?\n\nWith Waterfall, the decisions made at the beginning of the project are crucial. You have to know exactly how far and in what direction to travel. It&#x2019;s like launching a catapult. And the danger is you&#x2019;ll miss the target.\n\n\nNow, there are some arguments to be made in favor of catapulting. It&#x2019;s fast. Until it gets to the landing part, it feels really good. \n\n\n\n\n\nAgile is a lot like kayaking. It has a specific cadence. It&#x2019;s a much more reasonable way to travel. \n
- Agile is a lot like kayaking. It has a specific cadence. It&#x2019;s a much more reasonable way to travel. \n
- To operate a catapult, you have to carefully enter the coordinates. With Water fall, the decisions made at the beginning of the project are crucial. You have to know exactly how far and in what direction to travel. It&#x2019;s like launching a rocket. And the danger is you&#x2019;ll miss the target.\n\n\n&#xA0; &#xA0; It&#x2019;s easy to over-design or over engineer the product that the market actually wants. \n\nThe Pareto Principle confirms this &#x2013; 80% of your users will actually only use 20% of your feature set. Why not just figure out what is actually in the 20% and just build that?\n
- &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;\n\n\nWith Agile, it&#x2019;s more like paddling a kayak. Every stroke (an iteration) is an opportunity to adjust the direction of the boat. \n\n\nIn highly regulated industries, course corrections have compliance and quality ramifications. It can cause cost of quality to increase. <Give an example>. The best solution is to automatically generate documentation. In the short term, this cost of compliance could blind you from the larger opportunities in the marketplace by building a product that fits. You may incur 50k more in documentation costs, but you&#x2019;ll reap millions more in the marketplace. Don&#x2019;t undervalue Product-Market fit by fixating on development expediency. \n
- &#xA0; &#xA0; &#xA0; &#xA0; &#xA0;\n\n\nWith Agile, it&#x2019;s more like paddling a kayak. Every stroke (an iteration) is an opportunity to adjust the direction of the boat. \n\n\nIn highly regulated industries, course corrections have compliance and quality ramifications. It can cause cost of quality to increase. <Give an example>. The best solution is to automatically generate documentation. In the short term, this cost of compliance could blind you from the larger opportunities in the marketplace by building a product that fits. You may incur 50k more in documentation costs, but you&#x2019;ll reap millions more in the marketplace. Don&#x2019;t undervalue Product-Market fit by fixating on development expediency. \n
- Agile is an umbrella term; there are many flavors of Agile thrown around. Scrum, etc\n\nI won&#x2019;t be going into a lot of detail on Agile &#x2013; it is it&#x2019;s own field of study.\n\nBut I hope to give you a rough sense of process, and then focus on the touch points among Agile and Lean Startup and Lean UX.\n\n____\nAny new endeavor with Agile needs to start with the Agile manifesto - \n\n____\nAgile is predicated on self-organizing teams, short-feedback cycles, and building working code that delivers business value. \n
- A small chunk of functionality that carries some business value. It is widely considered the atomic unit of work in Agile. \n\n\nA story can be implemented in roughly a week\n\nAs you can see, a lot of the key ingredients in a story where discovered and developed during Inception using Lean UX techniques. \n\nBefore they are worked, stories are rated by points. Story points reflect relative complexity. \n\nThe business also needs to prioritize these stories\n
- \n
- The designer should stay one iteration ahead of the developers in the idealized case\n
- Chunks of functionality flow through Design, Implementation, and Test phases. Usually a story is designed an iteration or two before it is taken on for implementation and testing. \n\nThe chunks of functionality stack up on the right, representing the functionality your software currently offers\n\nThe rate that you can move these stories through the phases is called your velocity, which is the typical number of points you can move through in an iteration. It&#x2019;s one of our most useful metrics. \n
- We&#x2019;ve talked about the story, the atomic unit of work. But when is the work done? \n\nThe software should be in a potentially shippable state at the end of each iteration. \n\nWhat happens on IPM day? Closeout, Retrospective, Showcase, and Iteration Planning\n\nIt might not do much, but it should have functionality that is designed, implemented, and tested. \n
- \n
- \nSo who is on the team? \n\nStrict&#xA0;Scrum roles:\n\nProduct Owner\nScrum Master\nThe &#x201C;Team&#x201D;\n(Developer, QA, etc)\n\nIt&#x2019;s practical to differentiate further, to include User Experience Designers and Business Analysts\n
- incremental release strategy, with iterations\n&#xA0; &#xA0; &#xA0;Release planning - Prioritization and Deployment\n&#xA0;Story points - Invest until it's not worth it\n \nKeep in mind that the goal is to have a potentially shippable product at the end of each iteration. So if circumstances change, and think we can go to market with a smaller set of functionality, we should be able to. \n\nInvest til it&#x2019;s not worth it &#x2013; \nThere is not a fixed schedule. You can release whenever you are ready. You can continue to invest. Once you have a well-established velocity, it is simple to approximate the cost per story point. This flexibility in the release plan leads us to challenge the conventional definition of a &#x2018;project&#x2019;. \n
- Agile is built to accommodate shifting requirements and circumstances. To pull that off, there are some very specific engineering practices that you need to institute. \n\nTDD\nRefactor with Confidence\nPair-programming\n2 sets of eyes, a shared understanding of the code\nContinuous Integration and Alpha Environment\nKnow immediately if there&#x2019;s a problem\n
- &#xA0; &#xA0; &#xA0; &#xA0;\n
- &#xA0; &#xA0; &#xA0; &#xA0;\n
- &#xA0; &#xA0; &#xA0;\nGetting back to the kayaking versus catapulting analogy.\n\nSome may argue that a skilled catapulter would get there before a kayak. Even if that were true, what if the target moves during travel? Will your competitors politely stand still for 2 years? 1 year? 6 months?\n\nThis approach should be a Product Manager&#x2019;s dream. There are many opportunities for course correction. You aren&#x2019;t bound by decisions made months ago in Requirements Gathering. You can react to a moving target. You can release whenever you are ready. \n
- \n
- So you launch your MVP - it&#x2019;s time for the team to wave bye bye and move on to something else. \n
- Wrong. You&#x2019;ve only just started. You&#x2019;re trying to get to product market fit - a point where you can scale and make money. A rough measure for product/market fit is LTV 3x or more of CAC. Your job after MVP is to get to product/market fit. \n
- Changes to test might be things like layouts, calls to action, lazy vs. upfront registration, help, chat, button colors, sequencing of flows, how much functionality gets exposed for new users, etc. \n
- So you don&#x2019;t stop with the experiments and fast feedback loops just because you launched - you keep going! There&#x2019;s one thing here: you need metrics. \n
- There are different ways of measuring. I like Dave McClure&#x2019;s metrics for pirates - AARRR! One problem: these are person based metrics, so google analytics don&#x2019;t cut it.\n
- Don&#x2019;t wait to retrofit this until after launch: We bake person based metrics into mvp development, so you have funnel analysis, customer lifecycle analytics, and cohort analysis for customer retention right from launch. Other metrics like on Net Promoter score as well. \n
- So in summary - for new products, we start with customer development, get to an idea of what mvp is, do an inception, agile development iterations to deliver final mvp, and then start improving based on metrics. \nThere&#x2019;s a lot more to all of this. \n\n\n
- \n
- \n