$30 off During Our Annual Pro Sale. View Details »

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

[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. View Slide

  2. View Slide

  3. 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

    View Slide

  4. - Multiple scrum teams
    - PO, SM, Dev(s), QA(s), UX
    - UX consulting
    - UX coaching
    - Practice and preach lightweight and collaborative UX

    View Slide

  5. UX / UI
    - UX is more than just a UI or pretty picture
    - Not just Bootstrap and Font Awesome

    View Slide

  6. UX / UI
    - UX is about the experience a user has when using your application

    View Slide

  7. - 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

    View Slide

  8. - 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

    View Slide

  9. What about you?
    - UX embedded on team
    - UX external from team
    - No UX

    View Slide

  10. 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

    View Slide

  11. 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

    View Slide

  12. 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

    View Slide

  13. Trying to fit UX into
    the Agile process:
    http://uxreactions.com/post/124329440924/trying-to-fit-ux-into-the-agile-process

    View Slide

  14. Trying to do design and
    development in the same sprint:
    http://uxreactions.com/post/143482973394/trying-to-do-design-and-development-in-the-same

    View Slide

  15. 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

    View Slide

  16. 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

    View Slide

  17. 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/

    View Slide

  18. 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/

    View Slide

  19. 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

    View Slide

  20. 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

    View Slide

  21. 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

    View Slide

  22. 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

    View Slide

  23. 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

    View Slide

  24. 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

    View Slide

  25. - Won’t feel attached if not a lot of time has been put in

    View Slide

  26. Personas
    - Traditional personas
    - Heavily researched representations of the company’s target audience
    - Validated ahead of project
    - Packaged nicely and presented to leadership

    View Slide

  27. https://xtensio.com/user-persona/

    View Slide

  28. 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

    View Slide

  29. 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

    View Slide

  30. - 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

    View Slide

  31. - 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

    View Slide

  32. - Exercise to try out for first time
    - Create a superhero

    View Slide

  33. 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

    View Slide

  34. 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

    View Slide

  35. [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

    View Slide

  36. 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

    View Slide

  37. - 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

    View Slide

  38. - 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

    View Slide

  39. Design Sessions
    - Get team / stakeholders on the same page when it comes to design direction

    View Slide

  40. View Slide

  41. 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

    View Slide

  42. 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

    View Slide

  43. - More meetings = less attendees
    - Utilize meetings currently on the books

    View Slide

  44. 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

    View Slide

  45. 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

    View Slide

  46. 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

    View Slide

  47. 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

    View Slide

  48. View Slide

  49. @rachelbabiak // #ThatConference
    linkedin.com/in/rachelkrau
    speakerdeck.com/rachelkrau
    Got a story?

    View Slide

  50. View Slide