That Conference 2016, Kalahari Resort, Lake Delton, WI
Not Just Arts & Crafts: A Developer’s Guide to Incorporating Lean UX Practices into the Devleopment Process
Rachel Krause

Day 3, 10 Aug 2016

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2016 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

• An argument for a lean/agile approach to UX design

Contact Info

@rachelbabiak // #thatconference
centare
– On site, on SCRUM teams
– Consulting, be UX person on client team
– UX coaching

UX / UI

• Not just putting a pretty picture on something
• UX is the experience that the user goes through
• What will help the user in the best way possible

Example: Dominoe’s Pizza Tracker

• Visually, see where pizza order is in the process
• Distracts the user a bit while they’re waiting
• Really helped Dominoe’s competitively

UX Schools of Thought

• Genius Designer
• Mindset of experimentation

Genius Designer

• Research, work done up front
• Outside of development team
• Developers have no say
• “Best design possible”
• If something goes wrong, blame the user

Mindset of experimentation

• No matter how brilliant you are, you can’t figure it out
• Release early/often

Lean UX

• Book: Jeff Gothelf
• Focus on experience being designed
• Move us forward

Focusing on 3 principles from book today

• Accept failure
  • It’s okay to be wrong
• Reduce waste
  • Get rid of high fidelity mockups
• Collaborate
  • Everyone gets a say in the design
  • Gets everyone on the same page

Trying to fit Lean UX into Agile

Explain via cake metaphor

• Big Design
  • Pretty picture of cake–you’ll get this at end of project
  • During development, you get cake that looks similar
  • Pivot when necessary, make changes
• Lean UX
  • Start with wish list, rather than picture
  • Everything about the list can and will change
  • Scary to think of UX as just a list of features
  • Start with something small, e.g. cupcake
    • Everything there, but on smaller scale
    • Will release to users
  • Users give feedback
  • Then come out with something bigger
    • More features
  • Eventually get to something bigger, but matching what users need
  • Or cupcake might be all that the users need

Example: Pokemon Go

• Added feature after field testing
  • Take screenshot

Best UIs are designed by the entire team

• Different roles bring different perspectives

Example: A website

• QA might add opinion about usability
• Dev weighs in
• Product Manager weighs in
• Design changes as people offer thoughts

No complicated software necessary

• Nothing that you have to pay money for
• Need to use something that will work for entire team
  • E.g. Just a whiteboard
• No time for high value mockups
• Don’t get too attached to mockups

Personas

• Traditionally–heavily researched, validating
  • Packaged up and given to stakeholders
  • This takes a lot of time

Proto-Personas

• Easier, lean
• Originate from brainstorming sessions
• Based on stakeholders’ domain expertise
• Starting point for understanding users
• Think about role
  • E.g. Administrator, Warehouse Worker, Read-only User

Demo: Proto-Personas

• Four quadrants
• Upper left–name and face
  • Gives up empathy for the user
• Upper right–basic biographical information
  • Who, where coming from, what devices
  • Can be specific, e.g. married with 2 kids
• Lower left–pain points & needs
  • Frustrations with current solutions / products
• Lower right–potential solutions
  • Can be subjective, e.g. wants things super easy

• Do this on whiteboard, can take photo
• Stakeholders invited in on this process
• Talk through things and zero in on who you’re building software for
• If you can validate with real people, your assumptions were correct

Kids Experiment

• Had kids run through this process, with superheroes

User Journeys

• Once you have persona, give him a journey
• Series of steps that user is going to go through when working with software
• [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.

Now map the process

• Steps in user journey
• What happens, what the user does
  • Can do the journey for pre-solution or post-solution
• Needs, activities and expectations
  • At each step
• Persona’s emotional state
  • Graph between + (delightful) and – ()
  • Give rating for each step in the journey
• Opportunities for Improvement
  • At each step
  • Don’t worry about scope at this point
• Can do in Google Slides
  • Something simple

Design Sessions

• In place of Photoshop stuff
• Get an idea of the layout
• On whiteboard
  • User needs, check things off as you address them
  • Have small journey map to see where you’re at
• Do this collaboratively
• Why do this
  • We might think we’re all on the same page
  • Once we draw it out, we realize we’re thinking differently
  • Then hash through things and come to the same vision

When?

• Don’t have to do all of this than every single thing
• Proto-personas
  • At start of project
  • Or later, if you don’t already have them
• User Journeys
  • Whenever you don’t have enough information to fill out acceptance criteria
• Design Sessions
  • When you need to be on the same page
• Don’t do extra meetings for this
  • Can piggyback on existing Scrum meetings

Example: salesforce ux

• Wanted to redesign their core web product
• Had 85 designers and 60 Scrum teams
• Used Lean UX to revisit assumptions
• Then collaborated, included everyone on the team
• Lightweight, just using Sharpie
• How, with so many people?
  • Regular UX reviews on the calendar
  • Developers in design process early and often

Got a story?

• Let Rachel know successes and failures

Info

• @rachelbabiak // #ThatConference
• linkedin.com/in/rachelkrau
• speakerdeck.com/rachelkrau

Questions

• Remote teams?
  • Some tools out there for virtual design session
  • E.g. Peer.in, Google Slides
• Comment – When documenting, ask why you’re creating the document
• Comment – Balsamic
  • Cartoony layout keeps people from focusing on the details
  • Rachel: Challenge that, since it’s a paid application
    • Why not just use whiteboard
• What to during design process
  • Translate some of the needs and pain points into design elements
  • Not a formal process, but doing gut check w/user’s pain points
• Examples of turning negatives in journeys into positives
  • Often quick wins, e.g. confirmation dialog to avoid unintentional deletes
  • For bigger ones, you talk about how much value is in an improvement
• How do you validate a design after it’s out there?
  • Identify who your users are, then do beta test
  • Do beta testings with stakeholders and users
  • Watch them walk through the journey, validate
  • If you have no users, you’ll have to make assumptions
  • Might go down hallway and use someone else, e.g. product manager