Agile UX NYC

Earlier this year, I attended the AgileUX NYC conference. It was a great one-day conference with 14 presentations on how to do design in an Agile environment, with a focus on Lean UX. Looking back through my notes on the experience, I was inspired all over again to try new approaches, and I wanted to share them here.

So, what is The Lean Startup?

The Lean Startup is a software development approach outlined by Eric Ries: “Because startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build – the thing the customers want and will pay for – as quickly as possible.” The key method is constant adjustments to strategy via the Build-Measure-Learn feedback loop. The focus is not on shipping working software. The focus is on achieving validated learning on what customers value in your product. This means features aren’t “done” until you have proven with an experiment that what you built solves your customers’ problem.

Ok, then, what’s Lean UX?

There are lots of definitions and lots of different ways to do this, but basically it centers around doing UX in an way you can to shorten the build-measure-learn cycle - that is, get faster to learning from the customer. From the LeanUX Residency: “By reducing long product cycles into smaller, shorter chunks and validating these iterations with people that will use our products, we gain the important information needed to avoid expensive development cycles that are laden with risk.”

More reading on Lean UX:

Key takeaways from the conference

  • Get out from behind Photoshop. Everyone is talking about designers learning to code, sketching, running design studios with their teams, pairing with developers.
  • Quick, continuous design testing - and plan it the day before. Meetup tests three times a week, many others at least once a week. Keep tests and results informal (no deliverables!) Collaboration is key.
  • Mentor and get mentored across functional and departmental lines. Reach out especially to sales and marketing departments. Make it visual.
  • Visual artifacts such as sketches, post-it notes, and personas on the walls get everyone involved and sell the experience. They act as “visual radiators.”
  • Get data and use it. You can’t run experiments or track successes without data.
  • Almost every presenter acknowledged that working with remote teams this way is challenging.

Presenter slides and video of the conference

Notes from my favorite presentations

4 Keys to Success in a Design Driven Company (slides)

  • Get through the loop (idea-feedback-revise-prototype-validate…) as fast as possible.
  • Defining the problem is what's hard.
  • Listening vs Vision – if you focus only on your vision you're not open to feedback. To experiment, you have to be willing to change course.
  • Evolve thinking, not the pixels on the page.

Replacing Requirements with Hypothesis (slides)

  • Requirements don't expose the customer needs to teams.
  • Hypotheses are assumptions about the product or users to be tested.
  • Validated learning, not software (code), is the measure of progress.
  • Reduce time from product idea to learning if users want it (3months to 3 hours, in one of his examples).
  • Awesome example: success for a product he worked on was based on whether users installed the product. But, users weren't installing product. They think (hypothesis) installation is too hard and they need to build a customer installer. Tested by putting a button on their site ("Install for me!").  When the user clicks, there is a customer service rep behind the scenes manually doing the installation. A Wizard of OZ prototype let them know if the feature was worth building.

Agile Lessons Learned (slides)

  • They test 2-3x/week – and don't plan the test until the day before.
  • Their experiments are not just A/B Testing, they do long term experiments involving people (e.g., customer reps directly emailing new Meet Up organizers). They test which reps are successful and what it is that they are doing.
  • Don't try to explain process because people don't care! Just start doing it.
  • Have the freedom to fail – "What would you do if you knew you would fail?"

Demystifying Design (slides)

  • Make the entire process of design work visible to your teams. They'll see that design is hard! Teams will start to own the design work along with you.
  • Tell everyone what you are doing and why.
  • More on visibility: hang artifacts on walls, blog, celebrate wins, teach design to teams.