UXPA Lean UX Bridging the gap between UX and Developers
11 likes2,870 views
Lean UX is an approach that bridges UX and development by focusing on early and frequent user testing of prototypes. This helps build a shared understanding across teams through discovering user needs together. Key aspects include embedding UX in cross-functional Agile teams, prototyping at varying levels of fidelity, and testing assumptions with real users regularly throughout the design and development process. The goal is to iteratively learn and improve the product based on direct user feedback.
UXPA Lean UX Bridging the gap between UX and Developers
- 1. LEAN UX Bridging the gap between UX and Development Andrew Mottaz CTO ProtoShare
- 2. Is Agile Compatible with Modern UX? • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan Agile Manifesto
- 3. Good: • User-focused • Iterative • User is ultimate judge Conclusion: Modern UX and Agile have shared values. Is Agile Compatible with Modern UX?
- 4. Bad: • Developer-centric. • Minimal requirements in the form of written user stories. • Hermetically sealed sprints with no interference from outside. • We‟ll show you what we‟ve come up with when its done. Answer: Maybe? Lean UX is one way to try. Is Agile Compatible with Modern UX?
- 5. Lean Manufacturing -> Lean Startup -> Lean UX "Lean," is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. - Wikipedia
- 6. Lean UX in a Nutshell • Every design is a hypothesis and must be tested. • The focus on a giant spec doc is replaced by a focus on a shared understanding. • Shadow Sprint ( Prototype the Backlog ) • Embedded UX with Cross-functional teams (UX is part of the sprint, Developers are part of the planning)
- 7. Shared Understanding. Shared With whom? • Business Analysts, Clients and other high-level stakeholders. • User experience team • Development team • QA Understanding of What? • Who the user is. (Personas, User testing, User stories) • What the user wants and needs. (User stories, User testing) • What solutions are being proposed and why. (Prototypes, detailed requirements, developer input, documentation, discussion, user testing) • How the solutions behave ( Prototypes, written documentation, discussion, user testing ) • Whether the solution is successful. ( User testing )
- 8. Shared Understanding: User Stories • Verbal, user-centered, abstract. (What and why) • Audience: People who have intimate knowledge of product. • Drawbacks: Different people can have radically different understanding. • User stories are explored, supplemented, decomposed and validated using visual prototypes of varying levels of fidelity
- 9. Shared Understanding: Sketches, Wireframes and Prototypes • Internal validation • Walkthroughs and Spec Meetings • Visualizations are a far more effective way than written specifications to communicate the core vision. • Start low fidelity, evolve to get as high fidelity as you need to get your point across. • Higher fidelity = more engagement. Use this to your advantage.
- 10. Creating a Shared Understanding What is the best way to build consensus among your team? • Talk about it? You can have a 3 hour conversation about what the meaning of the word „is‟ is. • Impose it from above? Risky and difficult. • Trusted authority? Getting better – over time a UX practitioner can gain credence.
- 11. EVERYONE participate in user testing! • User acts as neutral 3rd party judge. • Better than actual judge, because you don‟t have to take their word, you get to watch their behavior. • There is a galvanizing emotional content to user testing that will convince even the most obstinate developer. • Watching someone struggle with YOUR product is excruciating, exhilarating and hair-pulling. Bonus! You get to validate your hypothesis at the same time.
- 12. An Example: Problem: We built an awesome library of stencils and widgets To speed prototyping, but users were having difficulty finding it. Solution: Place an „advertisement‟ in the UI in a prominent location.
- 13. How did we do? Answer: “Not Well” NO ONE SAW IT. Why? Inattentional Blindness When the palette was open, people focused on the content, not the chrome. ( Google: change blindness gorilla video )
- 14. Solution: Color, but also, put the ad in the area that had the users attention.
- 15. Lean UX is User Testing • Schedule user testing on a regular basis. Don‟t wait • 3-5 users every week, month or quarter, but do it. • You can user test paper prototypes, low fidelity wireframes, high fidelity prototypes or working code. • Have all team members participate at least once. • You can sell this approach by having management participate in some user tests.
- 16. Start User Testing Early with Prototypes Internal Validation • Do this all the time • Train yourself to share early • Regular Reviews • Part of cadence External Validation • Formative User Testing • Small number ( 2 to 3 ) • Informal • Face-to-face or monitored • Validative User Testing • Larger number • Analytics • More formal • Watching a small subset of users still useful • Impractical to watch all users.
- 17. Prototypes • Iterate, Iterate, Iterate • Visual, experiential, concrete ( What and how ) • User Testing: Do this regularly, don‟t wait until you‟re ready. • Prototypes start low fidelity, and evolve to as high fidelity as we need them to be. • Regular review of prototypes by team members creates a shared understanding • When are you done prototyping? When developers have a reasonable amount of certainty that they can build what‟s being proposed.
- 18. Iterating in code • Just because you‟ve started engineering, doesn‟t mean you‟re done validating. • Continue Internal and External Validation • Validative User Testing
Editor's Notes
- #3: ----- Meeting Notes (5/20/13 17:16) -----A lot of lean is a response to Agile development practices.
- #4: Waterfall has 1000 flaws – its inflexible, you make huge mistakes instead of small ones, its slow, cumbersome, etc. BUT at least there was a role for a UX professional/Designer to try to make a coherent impact.Agile if flexible, can make course corrections, smaller mistakes, but where does UX fit in? I once heard an Agile Dev. From Nike say that as far as feature requirements, they want one page, or better yet, one sentence. Developers get UX by default. At least they can validate but . . .
- #5: Waterfall has 1000 flaws – its inflexible, you make huge mistakes instead of small ones, its slow, cumbersome, etc. BUT at least there was a role for a UX professional/Designer to try to make a coherent impact.Agile if flexible, can make course corrections, smaller mistakes, but where does UX fit in? I once heard an Agile Dev. From Nike say that as far as feature requirements, they want one page, or better yet, one sentence. Developers get UX by default. At least they can validate but . . . If you’re not on the Agile team, you will constantly be playing catch-up and trying to influence development as an interfering outsider.----- Meeting Notes (5/20/13 17:16) -----Waterfall tended to make UX into a requirement writer.
- #9: ----- Meeting Notes (5/20/13 17:16) -----Who here uses User Stories as part of their process? Who writes them? Who reviews them?
- #10: ----- Meeting Notes (5/20/13 17:16) -----Who does this with user stories? Do you do it before writing user stories?
- #11: Communicate the ‘why’ of decisions to create a shared understanding.----- Meeting Notes (5/20/13 17:16) -----Would anyone like to speculate about the one best way to create a shared understanding?
- #12: Communicate the ‘why’ of decisions to create a shared understanding.
- #13: Communicate the ‘why’ of decisions to create a shared understanding.
- #14: This is the solution we came up with. We did all the things I said – user stories, sketches, wireframes, prototypes, reviews, discussions. How did we miss this?
- #15: Communicate the ‘why’ of decisions to create a shared understanding.
- #16: No one on the team would have believed it without seeing it.Had you said ‘the user didn’t see it’, the reaction would have been: wellThere must be something wrong with the user.When you watch the test, it is much harder to do that.You’ll notice the button stayed in the chrome – that’s how convinced we wereThat it was the right place for it. And it was, but not for new users.
- #19: Agile agrees – get to working code quickly and iterate to improve.