Session Notes: Lean UX @ BostonPHP

Presented by: Jeff Gothelf, the Ladders

Principal at Proof, @jboogie, jeff@proof-nyc.com

Lean UX is one solution to the Agile problem

  • Focus on delivery, not deliverables (build SOMETHING)
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Lean Startup

  • Every startup is a grand experiment that attempts to answer a question: not “CAN I build it,” but “SHOULD I build it?”
  • How do you spend the least amount of time designing/building the wrong thing?
  • Steps:
    • Formulate concept and create minimum level of fidelity to communicate and validate
    • Validate internally: stakeholders, developers, other designers, etc.
    • Prototype: get something out quickly so you can get it in front of customers or proxy customers
    • Test externally: get someone in front of your prototype and see what happens; is it usable? Is it USEFUL?
    • Learn from user behavior
    • Iterate
  • Designers need to step from behind their monitors and show early work much earlier and more often

First five things you need to do in order to make Lean UX happen:

  • Solve the problem together; don’t implement someone else’s solution
    • Bring the team you’re working with further into the process
    • Involve them in ideation and problem solving
    • Build shared understanding, which relieves the focus on deliverables
    • Let people know why certain decisions are being made
    • There’s no reason a developer can’t contribute to the design phase of a product and vice versa
  • Sketch
    • Remember, you’re not DRAWING; you’re sketching ideas together
    • If you can draw a circle, a square and a triangle, you can draw every interface that exists.
    • Work together on sketching and iterating, then work in parallel to build the thing
    • By working together, you don’t need to document things because you’ve already talked about it
  • Prototyping
    • Get your experience out, not the document
    • Validate hypothesis
    • What is the fastest way to get something into peoples’ hands that helps communicate the concept and its usefulness?
      • Axure
      • Straight into code
      • Other prototyping frameworks
  • Pair up cross-functionally
    • designer with developer
    • builds a common language and trust between the pair
    • makes the team more efficient
    • “design in the browser”
    • helps develop working code really quickly
  • Style guides are ESSENTIAL
    • could also be pattern or component libraries
    • make it a living document
    • make accessible to the entire team
    • button styles and logic
    • color palettes
    • default values for drop down menus
    • add code assets where applicable
    • helps the team put things together more quickly over time; assets can be grabbed and “dropped in” to a prototype
  • Critique early and often on designs that don’t feel “finished”
    • Designers have trained their clients to believe that the first thing they see will always be beautiful and “right”
    • NOBODY gets it right the first time, and nobody else is expected to.
    • It’s about getting concepts out early, and moving towards the “right” solution based on validated learning
  • It’s not the “Spec” that gives control
    • Lead with conversation, trail with documentation
    • designers are there to lead and facilitate the design process
  • Keep everyone moving forward
    • Provide team members with insight into the design process
    • Build momentum and engagement
    • Build shared understanding

How to manage quality vs. speed

  • “Speed first, aesthetics second” — Jason Fried, 37Signals
  • “It’s not iterative if you only do it once”
  • Iterations mean quality continually improves.
  • Move from minimally viable (simply works) to minimally desirable (works well, looks good, people want it)
  • Once you’ve validated your concepts, demo to the team
    • get them started building on a parallel path while you work on exception cases

Everything you put out into the world is a hypothesis. Your goal is to validate that hypothesis as quickly as possible and learn from the results.

  • Lean UX builds user testing into every sprint cycle
  • Don’t build things that people don’t want
  • Use data to settle subjective issues
    • A/B testing
    • Qualitative testing (user testing, etc.)
    • Use qualitative data to find out what people prefer; use A/B testing to validate that they prefer it.
  • Fill in the gaps through shared understanding
    • the more you talk about it, the better people understand why decisions were made, and more easily they can put the pieces together.
    • allows for estimation and prioritization within the flow of the building the project
  • Form factor is ultimately irrelevant
    • Many ways to test hypothesis
    • Testing doesn’t have to be expensive
    • Proto.io

Lean UX is NOT

  • Lazy. You still have to work hard, perhaps even more than what you did before
    • Collaboration level is significantly increased
    • What’s being removed is the WASTE that comes from the traditional UX process
    • Using the right tool at the right time
  • Design by committee
    • Yes, you’re involving other people, but it’s the DESIGNER’s job to synthesize that info into a concrete design

Getting started: in-house

  • Start small on an internal project
  • Ask for forgiveness
  • As you build camaraderie and start seeing results, others will start to notice and build interest
  • You are in the business of solving problems; you don’t solve problems with design documentation

Getting started: startups

  • This is the way to go, particularly in B2C

Getting started: interactive services/agency world

  • It’s a tougher sell, because agencies are in the deliverables business.
  • Give your clients the power. They like that.
    • Concept
    • Validate with client
    • Iterate
    • Validate with client
    • Prototype
    • Learn from user behavior
  • Can you get to the clients’ customers, or a similar proxy?
  • Gives clients the ability to see their “fingerprints” in the work; increases ownership.
  • Prevents “seagull management” — “swoop in and poop on it” — they can’t blame the agency anymore
  • Builds a more collaborative, less adversarial, relationship with clients

Getting started: Consultants

  • Consultants are mini-agencies

Distributed teams

Considerations

  • With content heavy experiences, some up front planning is necessary
    • Must understand what those content blocks will be, where they come from, and what they’ll contain
  • Highly experiential consumer sites may suffer under lean; hard to gauge experience with a usability test
  • Letting people into the design process makes them realize that design is HARD
  • Designers must evolve in order to stay relevant

 

I pray that my child never becomes an actress (assuming it’s a girl)

Because if she does, she’s doomed to a life of being judged not because of her character or her talent, but because of what she wears on the red carpet, or how skinny she is compared to the women ogling the obscene fashion show at home.

Don’t get me wrong; I’m as much a fan as anyone of all the gorgeous curvy actresses we’re starting to see. And I do believe that they’re an excellent role model for girls—showing that a beautiful woman comes at any size. But when I log into Facebook and see a bunch of housewives bitching about how skinny Angelina is, and coming out with that whole “what a horrible role model/she’s gonna make our daughters anorexic” nonsense, I can’t help thinking that’s a really old fucking story, and shouldn’t we be focused on getting *more* attention to the beautiful curvy girls, instead of constantly demonizing the skinny ones?

Here’s the thing: women’s bodies are beautiful. Big ones, small ones, tall ones, skinny and fat ones. I hope that the skinny ones are healthy; I hope the curvy ones are as well. But sitting around bitching about whether someone’s too skinny for someone’s liking sends the message that women are still, and always will be, judged for their bodies, not what they can do, or what they think. Including, and especially, by our own fucking kind.

And that, frankly, is a hell of a lot more damaging than seeing Angelina’s skinny ass on the red carpet.

Session Notes, Sessions 7–9: Agile UX Summit, 2/25/12

Anders Ramsay: Learning to play UX Rugby

  • Feeding the beast
    • Whole team of devs and they’re building shit faster than I can design it
  • Half-baked UX
    • PO’s under pressure to deliver the next release and signing off on crap
  • Sprint-tunnel vision
    • Yes, we delivered all the features we were supposed to deliver this sprint, but the design is an incoherent mess!
  • Why the dysfunction?
    • Playing the old waterfall game on an Agile playing field without knowing it.
    • Lacking the thinking tools to understand how the Agile game is played.
      • Scrum is not an acronym; it’s related to rugby.
      • “stop running the relay race, and take up rugby.”
  • Relay race
    • Team members run alone
    • Collaboration isn’t built into the game; the baton is handed to the next person
  • Rugby game
    • Intensive and continuous collaboration is core to the game
    • Reach the goal line again and again to win the game
  • Rugby in design
    • Team communication
      • Workshops, not meetings
      • Intensive passing game across roles/perspectives
      • Iterating towards shared understanding
      • Move away towards “debugging,” more towards a collaboration-centered design process
    • Collaboration-centered design
      • Shift towards facilitation as a core skill set
      • Cardstorming
      • Collaborative Chartering
      • Dot-voting
      • Story mapping
      • Card sorting
    • Ideation clearinghouse
      • Capturing the imagined final product.
      • Complete in an hour or less
      • There is a tremendous cost to not knowing what’s in the head of your project’s stakeholders (i.e. cutting off the project because you didn’t “get the vision”)
      • Step 1: Set focus/boundaries for the workshop
      • Step 2: Do a warm up; introduce people to the raw materials
        • 4-5 minute time window
        • Write every feature you expect on a separate sticky
        • Becomes a feature palette for sketching
      • Step 3: Sketching timebox
        • Give 5 minutes
        • Ensure safety; it’s okay if you “can’t draw”
        • Everyone in the room sketches SOMETHING
        • Sketch individually
        • No rules — someone wants to write text, they can
        • Clarify that this is research, NOT design.
      • Step 4: Critique
        • 2-min round-robin where people explain the vision/design
        • Take careful notes, attach to respective sketches
        • Look for and work to resolve differences in vision among stakeholders
    • Designing with workshops
      • Learn, apply and recombine workshop patterns
      • Cardstorming + dot-voting + sketching, etc.
    • Pairing
      • an intensive one-on-one passing game
      • Continuous problem debugging and knowledge distribution
      • One person “drives” and the other “navigates”
      • Use to debug and fix code in a continuous and collaborative way.
      • Change partners each day
    • Cross-functional pairing
      • Designing in multiple dimensions at the same time
      • Better collaboration means less/lighter documentation
      • Move from whiteboarding/sketches straight to building things together.
      • Developers can help with the transition from talking about building to actually building
      • Each medium/perspective informs the other
      • Move from wireframes to building the structure to HTML/CSS in a simultaneous process.

Todd Zaki Warfel: The Design Studio Method

  • Borne out of architecture and Industrial design
  • Three phases (charette):
    • Create: generate and prototype the concept
    • Pitch: presenting the design concept
    • Critique: talking about the design concept
  • Approach: 6.8.5
  • Tools:
    • Butcher paper
    • Sharpies (rougher feel; it’s about generating ideas)
    • Personas
    • Design challenge/scenarios
    • Templates, e.g. 6-up or 1-up grids
    • STOPWATCH
  • Teams should be CROSS-FUNCTIONAL. Represent 3 viewpoints:
    • Design side
    • Business side
    • Development side
  • Each team gets a different persona, and ONLY focuses on their persona for the duration of the studio
  • Design studio kicks off the design process
  • Step 1: Create
    • Create 6-8 concept sketches individually, within 5 minutes
    • Give templates with 6-8 blocks (like a storyboard) with grids and space for notes
    • Either storyboard a flow, or use the time to sketch multiple approaches to the same screen
    • Don’t forget a warmup session
    • Use paper and pencil to get people out of their element/comfort zone
    • Don’t worry about details; just get the elements down
    • Goal: get just enough of the concept on the page to be able to pitch your idea to the team
    • Don’t create more than you can pitch in 3 minutes
  • Step 2: Pitch
    • Put all sketches on the wall with personas, “inspiration gallery”
    • Everyone gets 3 minutes to pitch their idea:
      • What did you intend to achieve?
      • How does your idea achieve that goal?
  • Step 3: Critique
    • While someone’s pitching their concept, nobody is allowed to speak.
    • Once the 3 minutes is over, team gets 2 minutes to critique the concepts.
    • This is NOT feedback, i.e. “I don’t like this” or “I like this.”
    • Critique based on the goals for the design: where it achieved or failed to achieve the goals.
      • 2-3 ways it achieves the goals, EVEN IF YOU HATE IT (green markers)
      • 1-2 ways it can be improved upon, EVEN IF YOU LOVE IT (red markers)
  • Step 4: take feedback and iterate on designs
    • Stealing is highly encouraged; if another team does something you love, steal it and make it better.
  • Benefits
    • Generate two weeks of work in less than six hours (420 different design concepts)
    • Instant buy-in from team members: since team members help create the designs, they’re already buying into the concepts
    • Get team members to own and invest in the concepts
    • Engineers said their estimates on time were 50% more accurate
    • Having five minutes as a rule means you don’t have time to worry about it; just execute
    • Everyone gets to vet concepts as they go: it’s not as good as usability testing, but the benefit is that only the strongest concepts survive

Jonathan Berger, Code Literacy for Lean Teams

  • Coding as literacy
    • gets rid of the binary nature of “you can code or you can’t”
    • If you work in technology, the medium is power
    • “I can get this code to work or not” can be frustrating to those just learning
  • LITERACY DOES NOT EQUAL FLUENCY
    • Just because you can code doesn’t mean you’ll be good at it
    • Getting technical doesn’t have to be a full time commitment
    • Many resources available (books, sites, tutorials, etc.) are geared towards people who want to be full timers
  • More and more shops won’t hire designers who can’t code.
  • How does code literacy help lean teams?
    • More literacy leads to more sustainable projects and more successful outcomes
    • Fine details are important, but often get shoved to the wayside by devs moving on quickly to the next feature
    • There’s a whole class of things that are easier/less time consuming to do than to explain
    • Being able to fix details yourself saves the developers time,
    • Gives team more hands on deck, fewer bottlenecks
    • Builds camaraderie
  • How does it hurt?
    • Time/cost in learning curve
    • Potential for overstepping bounds (humility is important)
    • Harder to look at things with an “innocent” eye (i.e. without thinking about how it can be made)
    • Tunnel vision in devs can skew priorities towards problems that are “easy” to fix
    • DON’T LET CODE OVERSHADOW DESIGN
  • Ways to become literate
    • Use in browser mockups (HTML/CSS/JQuery)
    • Use Inspector (Chrome) or Firebug (Firefox) to inspect and change elements, then import changes into code mockups
    • Align product/development/design
    • Set up a local dev environment (e.g. MAMP, Rails)
    • Get started with Git
      • Designers can contribute small changes, e.g. copy or CSS, and push to production without interrupting the developers’ workflow
      • You can make the fixes that matter to you but aren’t crucial to the developers
      • Watch out for breaking tests (e.g. when copy is changed)
    • Learn JQuery & the DOM
      • Make better mockups—directly in the browser
      • Make more changes for the team
    • Learn the language your team is developing in—PHP, Rails, Drupal, etc.

Session Notes, Sessions 4–6: Agile UX Summit, 2/25/12

Tomer Sharon: Getting out of the (Agile) Building

  • How do you do UX Research in an Agile environment?
    • OLD: Fast Usability testing rounds
  • Tips for Agile Usability testing
    • Make it relevant to what the team is doing NOW.
    • It should be a small thing, not a BIG thing, and do it 3-4 times per sprint (i.e. once a week)
    • Recruit participants in advance.
    • Plan really fast.
    • One-page usability test plan on Smashing Mag: http://uxdesign.smashingmagazine.com/2012/01/26/ux-research-plan-stakeholders-love/
    • Make it a team thing. If nobody was there to hear about it, it didn’t happen.
    • No reports. Try a spreadsheet with observations, and just color or code where observations repeat.
  • “Getting out of the Building”
    • Getting an understanding of what the users actually need;
    • What you find isn’t necessarily going to relate to what the team is doing right now.
    • Bring users in in some way.
    • “Virtual Visit”
      • schedule phone call with potential or existing user of product.
      • No specific goal other than having engineers, project managers, etc. to “see” a user.
      • Use screen sharing software to watch customers using the product.
      • Get the product team talking to the user, asking the questions.
      • If the same problem is noted multiple times, it may turn into a product change/sprint.
    • “Field Fridays”
      • Take some engineers to visit a client for 60-90 minutes
    • “Collaging”
      • Ask participants to use collage to express their feelings about a topic.
      • Collect images around the topic.
      • Gives people a chance to express themselves more easily around the topic; uncover user needs in a less direct way.
  • Getting buy-in for user research
    • Become one with the team. There is ONE team who works on creating something. If you understand that, you can do these things.
    • If we want to get buy-in, our route to work should include stopping and talking with people within the organization
      • Identify what people care about.
      • Identify new research questions.
    • It’s OUR research: Getting buy-in for UX Research projects.
    • Elsevierdirect.com Code MKFLYER for 20% discount.

Andres Glusman: Managing your Malkovich Bias

  • Building something isn’t the problem; getting people to *use* what you build is.
  • On track to do 600-800 tests a year
    • Test 2-3 days a week
    • Setup tests prior to knowing what will be tested
    • Objectives are discovered via conversations, etc.
    • Recruit participants from community and through recruiter (compensate for their time)
    • Use GoToMeeting to broadcast sessions to developers
    • Record sessions using Silverback, JUST IN CASE you want to view it again
    • Follow up each session with discussion and notes/video
  • Everyone suffers from Malkovich bias: the tendency to believe that everyone uses technology like you do.
  • Watching people use the stuff you build helps solve the Malkovich bias
  • Experiment then double down;
    • First question: what are people going to respond to?
    • Test the most simple concepts you possibly can.
    • Use A/B testing to test experiments.
    • Know that your most likely outcome is failure; look for the points of heat (where people are staying)
  • Look at short and long-term experiments
    • Short term: trying out new messaging or graphics
    • Long term: creating new service areas, profiles, etc.
  • Lessons learned:
    • Give team direct access to customers
    • Look for the boulders in the road; be comfortable with error
    • Substitute frequency for precision; if one screws up, there’s another right behind it
    • Have discussions
    • Launch and Learn
    • Accept that failure is the most likely outcome
    • Experiment, then double down. Once you’ve found something that works, start working on implementation.
  • Other lessons learned:
    • Don’t buy your coworkers books and expect them to read them
    • Don’t try to sell the process; people don’t want to buy the process, they buy the results
    • JUST START DOING IT and let the results show you how successful it is.
    • Snuggle up to failure
      • We are more often wrong than we are right.
      • What would you do if you assumed you would fail?
      • Go after what will cause you to fail as often (and as FAST) as you possibly can.
      • The longer you put off getting people in front of your work, the longer you can live under the delusion that you won’t fail.

Lane Halley: Quick, Visual, Collaborative and Continuous

  • The old days of waterfall: PLAN-BUILD-TEST-SHIP
    • Based on shipping physical discs that the user would have to install.
  • Then, we started having:
    • Web services
    • Web apps
    • Web analytics
    • Mobile devices
    • “Permanent beta”
  • Things don’t have to be built in one big chunk; you can iterate and learn as you go.
  • Many UX processes are still stuck in the Waterfall “over the wall” mode
  • Changing role of design
    • Design as team responsibility, not a single designer’s responsibility
    • Cross-functional pairing
    • Designer as facilitator, not a lone wolf
    • Team as product owner
    • Bringing things into the entire process: smaller, lighter, more continuous
  • UX finally has a “seat at the table;” but the processes we’re using are causing backlog and distress
  • How to make it “leaner?”
  • Team discussions: who do we want to talk to, and what do we want to learn?
    • Create an interview guide with themes
      • Intro:
      • About you:
      • Collect a story about what you want to talk about
      • What devices do you own, and what do you use it for?
  • Provisional personas
    • Defines user hypothesis
    • Shared visual artifact
    • Evolves over time
  • Get “permission” to interview users: start by asking the team who the users are. What are their pain points? How do we delight them? If the team can’t answer, that’s a step towards getting permission
  • Interviews can give you an insight into personas (i.e. USERS) you didn’t know existed.
  • Team Interviewing
    • Pair interviewing
    • Multiple note-takers
    • Group synthesis
    • Visual radiators, sketchboards
  • Continuous customer engagement
    • Five users every Friday
    • “Talk to us” or “give us feedback” button on the website
    • Just-in-time recruiters
    • The point isn’t how many people you talk to; it’s that you’re doing it regularly
    • Schedule time in advance, EVEN IF YOU DON’T KNOW what you’re going to talk about
  • Use one session for multiple activities
    • Listen, gather context
    • use collaborative activities
    • get product or prototype feedback
  • Collaborative design sessions
    • Put everything on the board
      • “You can only have 5; which ones?” then prioritize.
      • “You can have 5 more; which ones?” etc.
    • Collect everything and start talking about priorities, hierarchy, etc.