what is lean ux?

Download What is Lean UX?

If you can't read please download the document

Post on 27-Jul-2015




2 download

Embed Size (px)


1. Applying Lean Principles to Improve User Experience in Agile Environment Darren F. Gideon Principal Web Developer UI Citrix Web Services 2. Its focus is strictly on the design phase of software development process. Best practice is to use staggered sprints also known as Cycle 0 and Sprint Zero. Design activity takes place one sprint ahead of development. 3. It is a methodology inspired by Lean Startup and Agile for bringing UX designs to light faster with less emphasis on deliverables and with greater focus on the actual experiences being designed. 4. It accomplishes this by getting out of the deliverables business and instead focusing on successful experiences. It focuses more on creating successful experiences by: 1. Removing waste from design process 2. Harmonizing the interaction of designers, developers, product manager, QA, etc. into a transparent cross functional collaboration of all involved parties. 3. Relying on rapid experimentation and measurement to quickly learn how well or not ideas are meeting the users goals. The designers role is one of design facilitation instead of sole point of view. 5. Not being judged by the depth and breadth of delivered documents (delivery of pixel perfect hi-defs and extensive documentation before presenting to collaborative team, customer, and or users). Being judged by the success of the end-state experience for the user. 6. It focuses on ensuring the ideas that have the most value get the most resources via: 1. Experimentation 2. Rapid Iteration 3. Evolutionary Process 7. Hi, HR its Darth Vader here. I need some personnel for a planetary operation. 8. No problem Darth Vader. Will this candidate do? He says he knows Photoshop. 9. No, I dont need a designer. I need canon fodder for a ground assault. 10. Oh, he knows COBOL too. What if we can outfit him with Storm Trooper equipment? Would he fulfill what you need then? 11. He knows COBOL? He definitely will be good canon fodder then. But I dont need a Storm Trooper. The assault is on the ice planet Hoth. 12. Oh, so you need him outfitted with cold weather gear. How about him now as a Snow Trooper? 13. Perfect! Get him outfitted with full Snow Trooper armor, weapons, and cold weather gear. Then put him on the next transport to Hoth. Oh, make sure he signs the proper RELEASE forms before he goes. 14. 1. Darth Vader makes a request to fulfill an outcome 2. A minimum viable product (MVP) is presented to be critiqued. 3. The MVP is critiqued and sent back, starting the next iteration. 4. The MVP is adjusted just enough to prove the concept and then presented again for critique. 5. Additional rapid iterations happen where the MVP is evolved until it meets the desired outcome. 6. The MVP is then prototyped and goes through the iteration process again until approved. It is then sent to Hoth to be validated in battle. 15. Because the biggest lie in software development is Phase II. A successful experience is a feature that actually ships that meets the customer and business goal(s). Delivering an experience that doesnt do this with a promise of finishing the experience in Phase II is delivering a bad / incomplete experience to the end user that might never be rectified. So why does this happen? Usually because a team ran out of time and then there never was a phase II. Or the customer goals change in phase II leaving a bad / incomplete end-state experience in place. 16. LEAN UX is based on three processes that are used to reduce waste and achieve a better end-state experience faster: 1. Design thinking 2. Agile development 3. Feedback loop that where a team works collaboratively to iterate repeatedly through a path to achieve a desired outcome 17. Design thinking starts with the goal or what is desired to be achieved by the user instead of starting with a certain problem. Direct observation of what users want to accomplish and what they like and dislike leads to innovation and the achievement of a successful outcome. 18. 1. Emphasis on individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over rigidly following a plan. 5. The realization that the initial design will have something wrong in it. So the goal should be find out what is wrong as soon as possible, then adjust, and test again. 19. A feedback loop is the process where you create the minimum viable product (MVP) to quickly test your assumptions, adjust the MVP based on feedback, and test again. Getting your collaborative team and then customer feedback avoids you making incorrect market assumptions. Your design is a hypothesis and your goal is to validate the solution by team and customer feedback. 20. By providing insight into the design work to your teammates sooner rather than later you accomplish the following: 1. It ensure that youre aligned with the broader team and the business vision 2. Give developers a sneak peek at the direction of the application enabling them to spot challenges earlier and speed up development 3. Fleshes out your thinking, since displaying your concepts to others forces you to focus on areas that you didnt initially think of or deemed important 21. 1. Cross Functional teams 2. Progress equals outcomes not output 3. Problem focused not features implemented 4. Remove waste 5. GOOB, the new user centricity 6. Small batch size 7. Continuous discovery 8. Shared understanding 9. Externalizing your work 10. Dont over analysis 11. Learning over growth 12. Get out of the deliverables business 13. Permission to fail 22. Teams made up of the various disciplines involved in creating your product. Their involvement should be continuous from the first day of the project until the end. The creation of a diverse team collapses the handoff process known as waterfall. Allows insight and foresight on each idea for all those involved. Which fosters greater team efficiency. 23. Features and services are outputs. The business goals they are meant to achieve our outcomes. By managing and measuring against outcomes we gain insight of whether the features we are building meat those outcomes. If a feature is not performing well we can objectively decide as to if it should be kept, changed, or replaced. 24. A problem focused team is one that has been assigned a business problem to solve (or an outcome to achieve) instead of a set of features to implement. It allows for innovation by the team It shows trust in the team to find a solution It fosters an investment by the team in the outcome 25. A core tenant is the removal of anything that doesnt lead to the ultimate goal. Which is improved outcomes. You do this because team resources are limited. The more waste a team can eliminate, the faster they can move. 26. Getting out of the Building coined by Steven Blank. Meeting room debates about user needs wont be settled in your office. The answers lie out in the marketplace. So you should give potential users a chance to provide feedback on your ideas as soon as possible. It is better to find out early if you are missing the mark BEFORE you spent the time and resources to build a product that nobody wants. The success of failure of a product isnt the teams decision but ultimately the end user. 27. Create only the design that is necessary to move the team forward and avoid a big inventory of untested and unimplemented ideas. Large batch forces a team to wait for big deliverables. It also keeps them from learning whether the ideas are valid or not. 28. The ongoing process of engaging the customer during the design and development process. The goal is to understand what users are doing with your products and why the are doing it. Research must be frequent and the entire team should be involved. The involvement of the team will build empathy and understanding for the users and the problems they face. 29. Its the collective knowledge a team builds up over time as they work together. The more a team collectively understands not only what it is doing but why, the less it has to depend on second hand reports and detail documents to continue it work. 30. Getting your ides out of your head and into public view allows everyone to see where the team stands. This can be done by whiteboards, printouts, etc. You do this to create a flow of information across the team. Which helps to inspire ideas off of ones that have already been shared. It also more quickly exposes possible issues with ideas that then can be interated on or discarded. 31. There is more value in creating a first version of an idea than spending half a day debating its merits in a conference room. The most difficult questions will not be answered in a conference room debate but by users in the field. To get user input you need to make ideas concrete so that they have something to respond to. 32. Its difficult to figure out the right thing to build and scale a business around it at the same time. Scaling an idea that is unproven is risky. It might work and it might not. If it doesnt work and you scaled it to your entire user base you have wasted valuable time and resources. Ensuring the idea is right on a smaller scale mitigates this risk (e.g. Canary releases, beta groups, etc.) 33. The focus of the design process should be creating the successful outcomes not documents. Documents dont solve customer problems good products do. The teams focus should be on learning which features have the biggest impact on their customers. The artifacts the team uses to gain that knowledge is irrelevant. 34. In order to find the best solutions to problems the team needs to experiment with ideas. Most of these ideas will fail. The team must be safe to fail if they are to be successful. So permission to fail means a team has a safe environment to experiment in which cr