The first keynote Thursday was presented by Jeff Patton, a self-described art school dropout turned UI developer.

His art background served him well, as his keynote was definitely one of the most visually engaging—he alternated between showing slides and transmitting live video from a camera positioned over a pad of paper on his podium, where he used several colors of Sharpie to write, sketch, and doodle his ideas. This had a lot of people in the audience holding up their phones to take photos of his diagrams and illustrations (including me).

Jeff started by asking how many people in the room are user experience practitioners. Only three or four people stood up, and he quipped, “Why am I even here talking about user experience, then?” But then he told the audience that even if they didn’t think of themselves as “UX people,” he thinks they just might be, and he would try to convince them why.

He then asked another poll question: Have you watched someone use something you shipped? The great majority of the audience stood. “Can you remember the first time you watched that?” Jeff asked. “How did that go?” There were many groans.

Jeff said that as a UI developer, he discovered he was wrong a lot. He thought audiences would like the product as much as he did, but many times, that was not the case. He said it can be painful watching a user actually interact with your product.

Much of what ends up in your product is based on the initial requirements, Jeff said. However, if this results in features none of your audience actually ends up using, that’s bad. If it results in features your audience ends up using but hating, that’s worse. “This is a bit like driving using only your rearview mirror,” Jeff said. “You can’t tell you have a problem until you’ve already run over it.”

When developing products, features, and enhancements, you have to have your customers’ best interests at heart. “We’re not just creating software,” Jeff said. “We’re changing the world.” You need to better understand the people you’re building things for, and the only way to do that is to spend more time with them. The requirements you should be using aren’t out there hiding; you should trust your users to let you know what they want. He quoted Alistair Cockburn, one of the initiators of the agile movement in software development: “If it’s your decision to make, then it’s design; if it’s not, then it is a requirement.”

However, Jeff cautioned, that adage “Don’t judge a book by its cover” exists because, well, people judge books by their covers. In your app or product, of course utility is important, but to customers, usability and aesthetics are also very important. Your product could have great features and capabilities, but if it’s not easy to use and doesn’t look cool, chances are users won’t like it.

In the mid-2000s, Jeff said, he discovered a process called “design thinking.” It involves collaboration among cross-functional teams, rather than the traditional design method of siloed designers each responsible for isolated processes. Design thinking uses five not necessarily linear steps—the whole team can move through them and back and forth as needed.

The first step is Empathize. It means you get out there, spend time with people, understand them, and, if possible, work alongside them. That’s how you’ll learn what problems they have.

The next step is Define. You need to focus on what specific issues you’re going to target to solve.

The third step is Ideate. You come up with many different ideas from all people on the cross-functional team, who will have varying points of view. These proposals don’t have to be gold-plated; you’re looking for the best ideas, not the best artist.

The next step is Prototype, where you expand on some of those ideas and build some solutions. This happens on pads of paper and sticky notes, so you can move really fast. (“You think agile people use a lot of sticky notes?” Jeff asked. “You ain’t seen nothing.”)

The last step is test. Take some of your best prototypes to your users and find out whether any of those models actually solve their problems.

What it comes down to, Jeff said, is getting out there to your customers. His presentation was full of photos he took of the people he has created design solutions for, with him shown in their environments, seeing what their days are like and understanding their workflows. “You will not prioritize the features in your backlog the same way after you’ve looked your users in the face,” he said. Make friends with your users, because you won’t want to disappoint your friends.

Jeff ended his presentation bluntly: by writing on his broadcast pad of paper, “You’re wrong.” He said so many people believe good design is as simple as building only the features people will want to use. “That’s a bit like saying, ‘Oh, just buy the stocks that will only go up,’” Jeff said.

“What user experience looks like today is an acknowledgment that we’re going to be wrong,” he continued. Lean UX is about iterating fast—going out and talking to people, coming up with many hypotheses, and realizing that many of them will fail. You just need to take your “biggest guesses” to your customer, and if they don’t work, keep coming up with solutions and trying them until you find one your user will validate.

“So let me ask again: Are you a UX designer?” Jeff concluded. “I think you are.”