Lean UXmas 2014

That's it for Lean UXmas this year!

“It is really important that no one in the team can point to someone over in the corner and put all the burden of user experience on that guy. No one person, no small group of people can be made responsible for the user experience of a service.”

“Instead of focusing on safe approaches we devised polarizing ideas to get actionable feedback faster. Results were often surprising, people would love something we thought was too complex. Other times they’d prove us right; rejecting something we knew was pushing things too far. Each time we learned tons about what resonated with users.”

“When our hypothesis is specific and falsifiable, we can run an Evaluative Experiment such as a smoke test. When our hypothesis is vague or we don’t even have a hypothesis, we need to do Generative Research such as getting out of the building and talking to potential customers to get new ideas or refine our hypothesis.”

“If you get organizational support for solving a problem that has measurable goals, you maintain room to change strategies as you get feedback from the market. If the goal is important and you are making progress towards the goal, it shouldn’t matter what features get you there.”

“Roadmaps are born of all sorts of compromises: between committing to a plan while remaining agile; between giving product teams autonomy while aligning their work to business goals; and between improving existing software versus getting new stuff out the door.”

“Working with users, not just as people to be researched, but as active partners in helping us understand what we need to know, opens doors to issues and problems we cannot anticipate because our own life history and experience has not encountered them.”

“Design simply, get it right, and move on. You are not shooting for perfection, but a high-functioning product that you can refine and enhance the core of in the next stages of design and development.”

“The moment that users are willing to buy the current latest version of the product, it will have proven demand and be ready to take to market. Given the pace of innovation and change in so many industries, having a product that meets the needs of users today - not 6 months or 1 year ago - can be key to success.”

“We liked the focus that sprints gave us, but also wanted a way to track and design the overall experiences we were creating. The solution came when we started to build ‘service design’ thinking into our sprint process. A service design approach helped us consider specific challenges in the context of the whole service or product. It also highlights the context and needs that a user might bring to your product.”

“If you find yourself condescending to your potential customer or thinking they are dumb, find a new target market or a new problem to solve. Your disrespect will come through in your interviews, your product, and/or your marketing.”

“… at Google, it was easy to get three or four designers together for a few days. At a startup, they might be lucky to have one. So we need design and critique processes that engineers and CEOs could do as easily as designers.”

“The goals and benefits of a Style Guide were exactly what we wanted but, not knowing how to achieve them, we started by extracting as much of our UI into components and moving them outside of the applications. This also gave us the opportunity to normalise and condense our UI.”

“If you’re not in charge of your company’s R&D team, how can you persuade whoever is in charge to put everything on hold and dedicate an entire day to user experience? Especially when you can’t even seem to get them to give user experience an hour or two?”

“User research is a team sport — not only observation but analysis too. We’ve found that different people remember different details — encouraging everyone who watched a session to join the analysis helps us gather more information and perspectives.”

“When we’re working on a team, getting the entire team to work together from the same approach becomes job one. Smaller teams (such as those with six or less folks) have always had an easier time of this than larger ones. This is because it’s more likely the smaller teams are checking in and talking to each other. Fortunately, there’s help for larger teams. It comes in a technique that is as old as humanity — storytelling.”