For our monthly "designer forum" meeting this month, the team decided to get together and watch Jeff Gothelf's introductory presentation of Lean UX. While we've all read the book at some point in time and practice these methods daily in the office, it's always great to get a refresher from the man himself. The presentation was given at the UX Immersion conference in 2012 and is now available to watch on YouTube here: https://www.youtube.com/watch?v=eOJWss8_BVA. After the video, we all discussed together what we are currently doing and how we could improve our workflows and introduce new practices. Overall, this was a great team building activity and everyone left with a few new strategies to better integrate our UX design with the agile software development teams we support. My notes from the video and our discussion follow.

• Agile user experience design killed the functional spec
• You cannot expect to deliver a pixel-level spec in the agile software development world, it simply isn't maintainable with such short design cycles
• Wireframes and lightweight prototypes tend to pick up the heavy lifting that specs have left behind
• To practice agile UX, you have to be fully part of the team. share in successes and failures of the whole team
• When first implementing agile at Jeff's old company, his team left this graphic on his desk to show their dismay for the process, our team has been experiencing some of the same pain points:
• 
• Conduct user testing every week or t the minimum, every other week
• Show whatever you have ready, this will begin to get you away from pixel perfect things
• Show anything and everything you have on test day, validate ideas and iterate
• Formal, fixed design reviews are difficult to enforce; getting everyone into the same room, etc
• UX designers supporting multiple agile projects doesn't work, as there are competing top level priorities from product owners
• Design needs to be integrated into the team, as this clears priority issues and builds camaraderie & communication within the team
• Lean UX is focused on the true nature of design and less reliance on documentation and deliverables
• Lean UX embraces change and coarse correction along the way, you may never end up where you initially headed out to
• Lean Startup is all about asking "SHOULD we be building this?"
• You want to find out as quickly as possible if you're designing something that people really want
• Designers have to be active and seek out this feedback - get out from behind your monitors
• You must externalize your early, raw unfinished work to get the ball rolling and the necessary conversations started
• Design and developers should be working at the same pace, not shadow sprinting
• Sketching together is visually articulating concepts and real business solutions
• Sketching together builds shared understanding. When you leave a sketching session, both teams can work separately and build in parallel, based on a shared understanding of what needs to be built
• Cross-functional pairing saves time and increases understanding
• Save time by refining the UI in the browser. When you're done, you're done. You don't have a document of what it should be, you have IT. The code. The work is done and you can test the thing.
• Pairing sets designers free as it builds efficiency into your team over time
• Style guides solve many, many problems of agile experience design
• These become the building blocks of new experiences
• You can reuse 80% of these things and can hugely quicken future design iterations
• Living style guides mean when you make an update to the style guide, it will live update the entire website - this is growing in popularity nowadays for obvious reasons
• Designers shouldn't be expected to get it right the first time - critique early, often and together
• Specs are wasting time, as they never get 100% built - they are comfortable, but a waste of time
• Quality should never be compromised in Lean UX
• Speed first, aesthetic second
• We're going for the bronze, iterating to silver then iterating to gold
• Prototype your designs to validate that they can actually be built
• Build just the frame of it, just enough to get your point across
• Lean UX is about customer validation, your design is a hypothesis
• Keep the customer constantly in the loop, other people started piggybacking on this and suggesting new things to test
• Take the subjectivity out of design by testing with real customers constantly
• Design has to be part of estimates and prioritization - base priority on customer asks and build this into the project backlog
• Informal and quick design iterations are far better than perfect and late
• Lean UX is not lazy, it's not about doing less work - Lean is actually much harder than waterfall design cycles
• The only thing lean UX removes from the process is the waste
• Focus is on just what you need and create things only when you need them
• Don't worry; Lean is not design by committee
• You solve your business problems with working software
• This is the lonely way to work in a startup business
• One of the biggest lies in corporate america is phase two. or, the icebox in our case