Here are my non-comprehensive notes from Day 1 of Lean UX NYC conference. The notes are on things that I want to remember, but could be useful to others.

Lean Branding — Cindy Gallop, Make Love Not Porn

When trying to push forward with a startup lots of people will try to shoot you down with their common sense. Cindy uses this as motivation and aims to fucking well show them, with data.

From Waterfall to Lean — Bruce Eckfeld, Dev team consultant

There are 2 different types of software development:

• Predictive – Where you know all of the specs so can go waterfall. (like building a house)
• Adaptive – Where there are a lot of unknowns and things are going to change. (like startups)

There are 2 different causes of disruption and waste to your dev cycle:

• Common – Things like bad process within your dev team.
• Special – Things like your CEO coming in and changing things mid dev cycle.

You need to make sure you’re focused on fixing the right waste. The one that’ll have the biggest impact in value when fixed.

Lean Product Management — Melissa Perri, Conductor

“This isn’t what I needed” really isn’t what you want to hear from your customers after you’ve built something.

Customers will only use a product if it fills a need.

Don’t build all of the things. You CAN’T built all of the features. You should be pushing back on the vast majority of them. Also you HAVE to validate before building.

Melissa used a formula to work out the amount of $ that it would have cost to built a feature that didn’t work, and shows that to people when she proves that it wouldn’t have worked. She uses costs by working it out using developer salaries, then can compare this to profit made directly from the feature too.

This talk emphasized that boss’s, business, etc really are focused on building stuff. Shipping stuff. Rather than shipping stuff that’s validated to work.

MVPs are just a test, not a feature. It should never be left up. If you’re building an MVP out enough to be left up then you’re building an MVP wrong. It should be much more minimal.

Lean Startup in Design Consulting — Johanna Kollman, Sidekick

Sprints are good if you know what you’re making. Experiments are needed if you don’t know what you’re making.

Always ask the CEO/stakeholders what success looks like. What your goal is.

When building things really think about how they’re going to help with where the money comes from. How they’re going to help the stakeholders pitch. Steve Jacobs of Gilt went straight to this too when we spoke with him.

You should always be about the problem, knowing the problem inside out and solving it. You shouldn’t be solution focused, you should be problem focused.

Lean Branding for Startups — Adrian Howard, Quietstars

Showing slides for stuff the audience already knows sucks. Showing unique things that you’ve learned rocks.

You’re going to be wrong often. Remember that. You’re going to conduct a lot of experiments, as you should, and you’re going to be wrong often.

Minimum Viable UX — Grace Ng, Lean Startup Machine

During customer interviews you need to understand how painful the customers problem is. It needs to be really painful for them to really want your product. It also needs to be a frequent problem. You want high pain, high frequency.

By delivering the service manually to a customer you can always see the customers problems and reactions. So you can always keep your focus on the huge problem. You can move extremely fast on the customer’s data. You should go for conceirge your idea with roughly 10 customers.

Grace always details the Existing Behaviour (how the customer currently solves the problem). Something covered a fantastically at detail by Jason Evanish.

Fast UX Research for Engineers — Tomer Sharon, Google

The big focus on Tomer’s talk was: Don’t listen to users, watch their behaviour.

Observe what they do. There’s a big difference between what people say they do and what they actually do, so you can’t ask them questions, you can’t ask for feedback. It’s doesn’t work. You have to observe what they actually do.

Never ask for feedback, instead watch them we it. Even if its a paper prototype.

Noticability test: Use this test to find out if a user has seen a piece of functionality or UI that’s on the screen. Ask users to complete a task, then give them a cut of piece of paper with all of the functionality jumbled up. Also add some elements that weren’t there, and take a few out. Ask them to reassemble it. Ask them to sketch in what was missing. Did they leave out why doesn’t belong? Did they put in extra things that they want?

A/B usability test: A standalone a/b test only tells you what happened, not why. You have to observe and question your user if you want to find out why. An A/B with a competitor can be really motivating to get shit done. If someone at your company finds out that you product isn’t nearly as good as a competitors then it’s going to get fixed!

The rainbow spreadsheet: Totally awesome framework and system for recording UX tests. Detailed heavily here, including a template. http://uxdesign.smashingmagazine.com/2013/04/11/rainbow-spreadsheet-collaborative-ux-research-tool/

Mixing Lean UX and Agile — Lane Halley and Courtney Hemphill, Carbonfive

They use a 1 week sprint to focus on experimentation in sprints.

Sprint Structure:

• Monday: Reflect and design — Big whiteboards, lots of feedback, define hypothesis, then team takes the afternoon to clean up random work and prep.
• Tuesday: Spec — Write user stories (include role, feature, business value), pair sketching with design, story mapping
• Wednesday & Thursday: Build and refine — Coding, more collaboration, lots of whiteboard wire framing, creation of a living style guide (a must have so that coders don’t get blocked by design), coders get feedback and make decisions with designers on the spot—no need for mocks, story acceptance (should probably find out what this is…).
• Friday: Customer feedback — Always do testing on Friday. Always. Never skip this. Can use task rabbit to bring in users. Specify testing as broad or specific. There were lots of other details for how to do this testing, but this is covered heavily elsewhere. Google Ventures do a great job of providing resources for it.

IBM Design — Ari Font Llitjos, IBM

If there was one thing I took away from this talk it was this awesome quote:

“You can’t dictate great outcomes”

Also, you should provide your team with a framework for a freedom to act, giving them autonomy. This will get shit done WAY quicker, rather than being blocked on requiring multiple signoffs for projects.

Your Mom’s a User: Communicating With Users in your UX — Bill Beard,

What a fucking fantastic talk. Follow @writebeard now. Do it.

Copy is a guide not a crutch — don’t explain your UX with copy.

If you take more than 8 words or less to say something, fix the design instead. This comes from a scientific study on readability: http://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_test

Your UX should be like a conversation with the user. For some reason when we communicate to the user in computer software we turn into robots and use jargon. Explain things to the user in concise plain text instead. The user is a person, talk to them like one. Example of the “Job goals” UX at TheLadders being misunderstood by most people. Whereas “Tell us about the job you want” was extremely clear.

Never use internal terminology.

Have we prepared the user for what we’re about to show to them? Are they ready for our signup flow? Or are we going to be surprising and/or jarring them?

Are we using the same language on twitter, email, etc as we are in the product. Does it provide a good UX when you come from email, twitter to the product? Take some time each month to sit down and run through these flows—just looking at the copy.

Sustainable Pace, Agile and the Big Design Refactor — Jonathan Berger, Pivotal Labs

Incorporating designers alongside the engineering team in an agile process is tough.

Designers feel overwhelmed as things quickly pile up for them. Designers feel rushed and disempowered.

Designers need to adopt a pace that’s sustainable to them. Jonathan is pushing this as something that designers need to push back on and stand for as a value.

Putting less than perfect work out there doesn’t feel easy or natural for designers, especially as they’re trained in college only to put out their best work. Whereas often in Lean or Agile it’s important to get less than perfect work out there. This can be a lot tougher for a designer to do than for a developer, they don’t want their work to receive criticism.

During a big redesign the design team often has a deliverable to dev that can talk multiple sprints to complete, then after that it’s handed off to tech to gradually stab away at. It’s super often that tech have to prioritize other features and leave design elements out or unfinished. This can be tough for a design team that have spent a lot of time creating those elements.

After the redesign is implemented (and during implementation) it’s frequent that things should be changed too as the redesign received user feedback. That can be tough for designers who have spent a lot of time creating the project too.

The key here is to involve designers in the agile process more. Pairing up with developers to make these changes on the developer’s screen, rather than in Adobe.

There is no silver bullet for this right now, it’s tricky.

The Lean Team Experiene — Jabe Bloom

If you develop your product in a waterfall production line kind of way then you need to push your product at the end. So you end up with this product and you hope users use it, if they don’t then you’re going to have to push it on them.

It’s potentially a lot better to be putting things out there quickly and iterating, feeling out what the customer wants, attempting to provide it, and iterating to meet the customer needs. This is “pull” rather than “push”.

If you take time to craft code of little or moderate value to users, you’re wasting time and money.

When in experimental phase don’t spend time creating code that’s amazing and works for everything. Just get it done and optimize later when you’re I’m production phase.

Kill 50-80% of your products after experimentation. These shouldn’t go to the production phase. Taking failed products to production is a huge waste.

People spend a lot of time making decisions based on nonsense. No one has done experimentation, no one knows what they’re talking about, everyone spends ages to get consensus. Product building at a lot of companies is a huge amount of time getting consensus from people who are just voicing their uninformed opinions.