Blog

[AgileUX Summit] Session Notes: Investing in Design

Phin Barnes: Investing in Design

  • The building blocks of the web are getting bigger and bigger, and easier to manipulate by clumsier and clumsier hands.
    • modern languages (PHP, Ruby, etc)
    • cloud services
    • ability to code and test relatively quickly
  • The web has returned to the basics of customer development; design must follow. Four stages:
    • Problem Definition
    • Sketch or Prototype
    • Improve Solutions
    • Implement Best Solution
  • Mindset > Skill set
  • Rules
    • No Unicorns and No A**holes: avoid the person who "knows everything" and doesn't listen
      • Someone who listens and pivots improves over time
      • Someone who develops a "vision" and argues for it won't listen to feedback; won't listen to data.
      • Avoid making multiple minor iterations on the same bad vision.
    • Look at the feedback loop process
      • It's easy to fake some of these things, i.e. talk the talk
      • If there's one place where craft really counts, it's in the feedback process
      • avoid comments that don't move the project forward, or aren't actionable
      • Feedback = an effort to understand where the person who created the feedback was coming from
      • Great feedback sessions are:
        • Casual
        • Scheduled
        • Planned out, in terms of what you want from the session
        • Organized in terms of decision points, and problem statements: what are you expecting to solve? What are you expecting the user to do here?
        • Watch people using the product, and videotape them; discuss it with the product team
    • What moves the crowd at your company?
      • Data, or a "visionary unicorn?"
      • At the best orgs, qualitative and quantitative data work together.
      • What are you measuring within your company?
    • If you're going to adopt a design mindset, it has to be full staff
      • Get the rest of the org on board.
      • Make it tangible; find ways to get folks into the process and want to contribute to the product.

[AgileUX Summit] Session Notes: Want to win with Agile? Pivot your culture.

Eric Burd: Want to win with Agile? Pivot your culture.

  • If you don't have everyone on board, you have a problem.
  • How do you get the business side on board with lean/agile?
  • How do you set expectations on Minimum Viable Product?
  • Focus on one clear end goal, and try different ways of getting to that goal; "Keep one foot on Everest"
  • Two groups to win over:
    • Dev Team: they're the ones who "get it."
    • Sales, Marketing, Ops people
  • Many articles, books, etc. focus on winning over the tech and product teams; who's talking about winning over the rest of the business team?
  • Agile isn't as much about mitigating the tech risk; it's about mitigating the market risk—building something nobody wants.
  • The business side believes that WATERFALL is about risk mitigation
    • clear beginning, middle and end
    • "campaigns" and "budgets" — long term thinking
  • We can't get these sides of the business (marketing, ops, finance) into an Agile process, but we can do better at informing them of what we're up to.
  • Six tips:
    • Find or light a "fire:" tie it to another issue within the organization (e.g. morale of dev team)
    • Listen to the customers; by being user-centric in our thinking, we can build better products. HOWEVER, you can't get execs to actually listen to focus groups or usability labs. What you can do is bring customers in to have "lunch" with the executives, and customers can help sell execs on the process.
    • Get sales team in on it. Hearing from sales (i.e. people who regularly talk to customers and are trained at knocking down objections) that the process will help the org can make great strides towards getting the rest of the team on board. If the sales team can start hearing that customers are having product-driven issues that you can fix with Agile/Lean, you're halfway there.
    • Words matter. When we're using jargon, being self-referential, we're essentially talking to ourselves. Other folks don't get it. Start learning the language of the people you're trying to sell to.
    • Train the exec team.
    • Focus on small wins. Find small wins within the org, and attach those to agile/lean vs. focusing on a "big bang."

[AgileUX Summit] Session Notes: Quick, Visual, Collaborative and Continuous

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.

[AgileUX Summit] Session Notes: Managing your Malkovich Bias

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.

[AgileUX Summit] Session Notes: Getting out of the (Agile) Building

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.

Pages

Subscribe to Blog