Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[That Conference 2016] Not Just Arts & Crafts: ...

[That Conference 2016] Not Just Arts & Crafts: A Developer's Guide to Incorporating Lean UX Practices into the Development Process

Given at That Conference 2016

A good app design is more than just modifying Bootstrap and clever usage of Font Awesome — it starts with a solid understanding of your users. In this session we’ll walk through lightweight and collaborative UX techniques that you can use in your development process to better understand your users and their workflows. We'll demonstrate how user experience goes beyond UI design and discuss real world examples of how knowing your users can put your application ahead of the pack. You’ll leave this session with techniques that you can apply to your current team without the need for complicated software or a complete shift in your corporate culture.

No UX experience? No problem! We’ll introduce you to lean UX practices that you can start using with your teams right away.

Come sit around the (metaphorical) campfire while we sing Kumbaya and learn how to get in touch with your users on an emotional level.

Rachel Krause

August 10, 2016
Tweet

More Decks by Rachel Krause

Other Decks in Technology

Transcript

  1. Not Just Arts & Crafts: 
 A Developer's Guide to

    Incorporating Lean UX Practices into the Development Process Rachel Krause @rachelbabiak // #ThatConference - Came from a waterfall environment - Didn’t buy in to Lean UX - Saw how hard it was to keep up with all of the deliverables in two weeks - Had to adapt and use what worked for the team
  2. - Multiple scrum teams - PO, SM, Dev(s), QA(s), UX

    - UX consulting - UX coaching - Practice and preach lightweight and collaborative UX
  3. UX / UI - UX is more than just a

    UI or pretty picture - Not just Bootstrap and Font Awesome
  4. UX / UI - UX is about the experience a

    user has when using your application
  5. - Personas identifiable through different themes - Many pizza options,

    how do they differentiate? - Makes waiting for pizza more delightful - Domino’s consistently outpaced Pizza Hut in same store sales from 2011 through 2014
  6. - Personas identifiable through different themes - Many pizza options,

    how do they differentiate? - Makes waiting for pizza more delightful - Domino’s consistently outpaced Pizza Hut in same store sales from 2011 through 2014
  7. What about you? - UX embedded on team - UX

    external from team - No UX
  8. Genius Designer http://blog.invisionapp.com/genius-designer-mindset-experimentation - Assumes their work is correct -

    Work is done up front or outside of development team - Developers are not part of the process - Pixel perfect mockups / comps delivered to developers to implement - Technical constraints / design feedback is irrelevant because the design is the best design possible - Design is not the problem; users are ignorant - This used to be me - http://blog.invisionapp.com/genius-designer-mindset-experimentation
  9. Mindset of Experimentation http://blog.invisionapp.com/genius-designer-mindset-experimentation - No matter how brilliant or

    experienced they are, they accept that they’ll be wrong about something - Figure out what they’re wrong about as quickly as possible - Release early and often - Get feedback from users - Pivot if necessary - http://blog.invisionapp.com/genius-designer-mindset-experimentation
  10. Accept failure Reduce waste Collaborate - Jeff Gothelf, Lean UX

    - Lean UX principles, tactics and techniques for teams - Focused on the experience being designed, not the deliverables - Main principles - Don’t be afraid to fail - Mindset of experimentation - Failure in software in some capacity is guaranteed - Accept this reality and plan for it - Reduce waste - Don’t rely on heavy artifacts - UX activities are not necessarily deliverables - Collaborate - Get everyone on the same page
  11. Trying to do design and development in the same sprint:

    http://uxreactions.com/post/143482973394/trying-to-do-design-and-development-in-the-same
  12. Big Design - Not just in waterfall environments - Mockups

    done before development begins - Cake example - Start with cake, then filling, then decorating, then final cake - If filling doesn’t taste good with cake, then what? - Pivot but then the end result is not what the picture looked like - Stakeholders still have picture in their head as end result - Waste of mockups - Lose-lose situation for stakeholder - High probability that the end result will not look like what was designed - Humidity in kitchen; unexpected things come up
  13. Lean UX - Wish list of features - Expectation: priority,

    features, etc. will change as the product evolves - There is no pretty picture to start off - Can be scary to the team, including UX - People like to think big picture - What if client runs out of money? - Have you waited too long to incorporate UX? (frosting, decoration) - Bake in UX at each step - Create a little, test it, create a little more - Can stop at any stage
  14. https://www.nianticlabs.com/blog/e3-2016/ - Many of these refinements are inspired by feedback

    received from field testers - https://www.nianticlabs.com/blog/e3-2016/
  15. June 15, 2016 https://www.nianticlabs.com/blog/e3-2016/ - Many of these refinements are

    inspired by feedback received from field testers - https://www.nianticlabs.com/blog/e3-2016/
  16. Best UIs are designed by the entire team - Sum

    up theory intro - Everyone has used software before and knows what they like and don’t like - Different roles bring new perspectives to the design process - Everyone is a designer in their own way
  17. What We Do Lorem ipsum dolor sit amet, consectetur adipiscing

    elit. Integer vel tempor justo, eget placerat purus. In ut augue sit amet nisi viverra ullamcorper. How We Do It Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vel tempor justo, eget placerat purus. In ut augue sit amet nisi viverra ullamcorper. Our Cool Website This carousel will show you lots of content
 and only give you 5 seconds to read it. COMPANY NAME - Devs can point out high effort - QAs can identify potential pain points - POs can speak for the client
  18. What We Do Lorem ipsum dolor sit amet, consectetur adipiscing

    elit. Integer vel tempor justo, eget placerat purus. In ut augue sit amet nisi viverra ullamcorper. How We Do It Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vel tempor justo, eget placerat purus. In ut augue sit amet nisi viverra ullamcorper. Our Cool Website This carousel will show you lots of content
 and only give you 5 seconds to read it. COMPANY NAME What We Do How We Do It Contact - Devs can point out high effort - QAs can identify potential pain points - POs can speak for the client
  19. What We Do Lorem ipsum dolor sit amet, consectetur adipiscing

    elit. Integer vel tempor justo, eget placerat purus. In ut augue sit amet nisi viverra ullamcorper. How We Do It Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer vel tempor justo, eget placerat purus. In ut augue sit amet nisi viverra ullamcorper. COMPANY NAME What We Do How We Do It Contact We Build for You We create custom software. View our work and get to know us better. View Our Work - Devs can point out high effort - QAs can identify potential pain points - POs can speak for the client
  20. What We Do How We Do It COMPANY NAME What

    We Do How We Do It Contact We Build for You We create custom software. View our work and get to know us better. View Our Work Get in Touch - Devs can point out high effort - QAs can identify potential pain points - POs can speak for the client
  21. No complicated software necessary - Whiteboard, sketch preferred - Boxes

    and arrows are all you need - ”I can’t draw” - Google Slides / PowerPoint / Keynote if more fidelity needed - Something that will be used by the entire team without a large learning curve - No time for high-fidelity mockups and UX deliverables - Don’t think of UX activities as deliverables to clients - Continuous discovery = info has potential to change - More work to keep artifacts up to date if only one person can make changes
  22. Personas - Traditional personas - Heavily researched representations of the

    company’s target audience - Validated ahead of project - Packaged nicely and presented to leadership
  23. Proto-Personas - Proto-personas - Originate from brainstorming sessions - Based

    on gut feel and domain expertise - Who is using system - What is their motivation - Gives organization a starting point to develop design hypotheses - Do you use personas now? - Roles - Narrow down to main types of users, then define specific people - Can create multiple personas for each role
  24. Name & Picture Biographical Information Pain Points & Needs Potential

    Solutions James • 42 years old • Married, 2 kids • Paid hourly • Been with company for 5+ years • Not tech savvy • Uses iPhone 5S as personal phone • Doesn’t have a lot of time to go on the computer • Needs access to all areas of the warehouse • Keep app restrictions light • Tasks have to be quick and easy • Needs multiple access points into the application - Name & picture - Refer to this person by name - Picture doesn’t need to be pretty - Can envision a specific person or make someone up - Biographical information - Base on user research or assumptions from team - This information can/will change as you meet your actual users - Who is this person? What devices do they use? Where are they coming from? - Pain Points & Needs - User’s needs and frustrations with the current product or situation - Specific pain points your product is trying to solve - Why do they need this application? - What don’t they like about software? - Potential Solutions - Capture features and solution ideas - How can we help? - Solutions to pain points
  25. - Get everyone on the same page about who your

    users are - Help make decisions on backlog and functionality - Creates empathy for users - Prevents team and stakeholders from making decisions that don’t affect the user
  26. - Develop as a team and/or with stakeholders - Stakeholders

    may have an idea in mind but be completely off base - Personas are living and can change as you discover new information - If you can validate with real users, it means your assumptions were correct
  27. picture Biography Weaknesses Goals ⚡ From planet krypton ⚡ Alias:

    Clark Kent ⚡ Works at Daily Planet Newspaper ⚡ Ability to fly ⚡ Kryptonite ⚡ Lex Luther ⚡ Lois Lane ⚡ Help people ⚡ Prevent disasters ⚡ Make his father proud ⚡ Maintain Clark Kent image
  28. User Journeys - A user journey is a series of

    steps which represent a scenario in which a user might interact with the feature you are designing. - A way to understand how users walk through a specific feature - Understand user pain points and mindset
  29. [Persona] wants to [action] because [need], but [friction]. James wants

    to check in an inbound shipment because a railcar just arrived, but he doesn’t have accurate weights yet. - A scenario is a plausible future story about a persona using the feature from start to finish. - Pain point from personas - Looks like a user story; use this in your PBIs
  30. Five basic sections - Persona & Scenario - Journey Steps

    - First step is trigger - Last step is right after user is done using the feature - Everything in between is the user using the feature - Needs, Activities & Expectations - What is the user doing? - What devices are they using? - Where are they? - User’s Emotional State - Scale of delightful (+) and frustrating (-) - Include quotes from actual user interview - Opportunities for Improvement - How can we bring the dot from below the line to above the line? - Come up with solutions to pain points as a group - Compelling solutions can change constraints - Quick wins vs. high effort / high value
  31. - Whiteboarding sessions - Goals for session / user needs

    - Acceptance criteria / feature needs - Drawing / ideas on board - Journey map represented - Can start development from this - Doesn’t need to have all five sections - Apply what works best for your team - If something is too complicated, the team won’t use it
  32. - Whiteboarding sessions - Goals for session / user needs

    - Acceptance criteria / feature needs - Drawing / ideas on board - Journey map represented - Can start development from this - Doesn’t need to have all five sections - Apply what works best for your team - If something is too complicated, the team won’t use it
  33. Design Sessions - Get team / stakeholders on the same

    page when it comes to design direction
  34. Jeff Gothelf, Lean UX - Everyone thinks they’re on the

    same page, but each has a slightly different image in their head - The team can make decisions together to come up with the best solution
  35. When? Proto-Personas User Journeys Design Sessions - Proto-personas - Beginning

    of a project - Anytime you need more info on users - User testing - Continue validating throughout the project - Journey maps & scenarios - Not enough info for acceptance criteria - Not a clear workflow established for users - Design session - Same page about layout - Design and development in same sprint
  36. Salesforce UX, Making Design Core to the Agile Process by

    Ian Schoen - Lightning experience, a redesign of their core web-based product - 85 designers, 60 scrum teams - Revisited user goals, pain points and needs (personas) - Collaborating brings out ideas from every perspective - Lightweight design keeps everyone on an even playing field - Product leadership from UX, product management and engineering came together for big picture ideas - Smaller scale teams during brainstorming process, then brought initial ideas to greater product team - Regular UX reviews - Elevated UI-related bugs - Brought developers into design process earlier - Monthly sprint reviews and Friday lunch demos
  37. Salesforce UX, Making Design Core to the Agile Process by

    Ian Schoen “We had to know the right thing to build before we could build the thing right.” - Lightning experience, a redesign of their core web-based product - 85 designers, 60 scrum teams - Revisited user goals, pain points and needs (personas) - Collaborating brings out ideas from every perspective - Lightweight design keeps everyone on an even playing field - Product leadership from UX, product management and engineering came together for big picture ideas - Smaller scale teams during brainstorming process, then brought initial ideas to greater product team - Regular UX reviews - Elevated UI-related bugs - Brought developers into design process earlier - Monthly sprint reviews and Friday lunch demos
  38. Salesforce UX, Making Design Core to the Agile Process by

    Ian Schoen “Designers, developers and product managers each have their own point of view on how to make products successful…” - Lightning experience, a redesign of their core web-based product - 85 designers, 60 scrum teams - Revisited user goals, pain points and needs (personas) - Collaborating brings out ideas from every perspective - Lightweight design keeps everyone on an even playing field - Product leadership from UX, product management and engineering came together for big picture ideas - Smaller scale teams during brainstorming process, then brought initial ideas to greater product team - Regular UX reviews - Elevated UI-related bugs - Brought developers into design process earlier - Monthly sprint reviews and Friday lunch demos
  39. Salesforce UX, Making Design Core to the Agile Process by

    Ian Schoen “The Sharpie proved to be one of the most democratic tools in our process. Anyone could pick one up and put their idea out into the world.” - Lightning experience, a redesign of their core web-based product - 85 designers, 60 scrum teams - Revisited user goals, pain points and needs (personas) - Collaborating brings out ideas from every perspective - Lightweight design keeps everyone on an even playing field - Product leadership from UX, product management and engineering came together for big picture ideas - Smaller scale teams during brainstorming process, then brought initial ideas to greater product team - Regular UX reviews - Elevated UI-related bugs - Brought developers into design process earlier - Monthly sprint reviews and Friday lunch demos