I just realized that I had forgotten to link to the video of the AltConf design panel that I participated in last week.
AltConf: “user research for awesome products”
Installing OS X Yosemite on Fusion and vSphere
Virtually Ghetto has full instructions for installing the beta of Yosemite on both the Fusion 2014 Tech Preview and vSphere 5.5.
my perception, your perception
After a presentation, I never know how it went. I know how I feel after the presentation, which is a mix of still-lingering stage fright and relief that the presentation is over. There’s also that annoying awareness and self-consciousness that I forgot a point1, which bothers me because I practiced and practiced and still it got lost somewhere in between making sure that the presentation clicker actually worked and that I’m on the slide that I’m intending to be on and making sure that I’m making eye contact with my audience and all of the million other things that are going on in my head when I’m presenting.
As I was driving home after my AltConf talk today, it struck me that this is a lot like what we go through in user experience (and, for that matter, in software engineering). We remember that awesome thing that we designed back at the very beginning of our project. And during the project, as we had to make hard decisions about what would stay and what would go, that awesome thing that we designed could become slightly less awesome. We intended to deliver a whole new world, and the reality of software development is that we don’t always get to deliver that whole new world. Sometimes we only get to deliver a part of that whole new world. We measure what we actually delivered versus our perception of what we had planned to deliver, back before we found out that something would be a lot more difficult than we thought it would be or before a key member of the team had a family emergency that set development back six weeks. We don’t measure what we actually delivered versus our user’s perception of what is available today. Our users compare our new shiny thing to the old version. We compare our new shiny thing to the much more shiny thing that only ever existed in our heads and perhaps on an early schedule.
A presentation is the same. The audience doesn’t know what you intended to say. It doesn’t know about that fantastically funny anecdote that you intended to include. It doesn’t know about that quote that perfectly illustrates the point that you wanted to make. It doesn’t know that you had fantastic bridges from one section to the next constructed. Your audience only knows what you actually presented in your time on stage, and whether what you presented gave them something new to think about.
I hope that, some day, I’ll be able to divorce my own feelings about a presentation from the presentation itself. As I said to someone today, watching video of yourself give a presentation is one of the worst forms of torture available. You can see exactly when you stumbled or stuttered, you can see that point where you skipped that fantastically funny anecdote. You get to watch yourself make mistakes, and you are watching for an external sign that you made a mistake. If you’ve done a great job, the audience is never aware of the stumble. If you’ve done a really good job, they might notice the stumble at the time, but forget it instantly because the presentation continues and they get something out of the presentation. If you’ve done a good job, they might notice the stumble and even remember it, and they forgive you because you’re human and they know that giving a presentation is hard.
If you attended or watched my AltConf talk today, this is a great example of confirmation bias. My belief is that I’m not good at giving presentations. When I watch a video of myself giving a presentation, I see all of the mistakes that I made, or I imagine that I see mistakes. I notice the mistakes, and I remember them, and it confirms my belief that I’m not good at giving presentations. I’m not at the point where I can see past my self-consciousness.
To be clear: I’m not fishing for compliments. I won’t believe you anyway, because you’re not confirming my strongly-held bias.
Slides forthcoming, possibly tomorrow. The video is available now.
- … or two … or more … ↩
User research for amazing products
On Tuesday, June 3, at 11am PT, I will be giving a talk titled “User research for amazing products” at AltConf. It should be available via streaming live, as well as archived for the sake of posterity, below.
“The Top 10 User Testing Bad Habits (and How to Fix Them)”
UserTesting.com has a great article up about The Top 10 User Testing Bad Habits (and How to Fix Them). I disagree with their #1 (it feels more like an ad for their product than a bad habit). The rest is a great reminder about how to get a user study right. I really liked this one:
#6 Do a data dump
If you run the study, then you’re familiar with everything — the instructions, the tasks, the results. But if you just hand the data and the video recordings to someone else, they may be overwhelmed. You need to summarize the results, draw conclusions, and present a cohesive summary to your team and stakeholders, not just hand them a lot of data.
Yes! The job of a user researcher is not to take dictation. The job of a user researcher is to collect and analyze the data. I see too many researchers doing a great job of collecting data and not a great job of analyzing the data. You know the data better than anyone else. Do the analysis so that your team knows what matters and what action to take.
“4 myths of Apple design”
Mark Kawano, who spent 7 years as a designer and designer evangelist at Apple, was interviewed by Co.Design about Apple’s design culture1. “4 Myths About Apple Design, From An Ex-Apple Designer” is a great article about how Apple delivers great products. I think that this is a great point:
It’s actually the engineering culture, and the way the organization is structured to appreciate and support design. Everybody there is thinking about UX and design, not just the designers. And that’s what makes everything about the product so much better . . . much more than any individual designer or design team.
If your UX team are the only people who care about the user experience, you’re not going to deliver a product with an awesome user experience.
- Thanks to John C. Welch for making sure I saw it. ↩
AltConf talk: “user research the Apple way”
I was invited to give a talk at AltConf. Here’s my current title and description.
User research the Apple Way
Steve Jobs told us many times that you cannot design by focus group because people don’t know what they want. He is right: the way to deliver the right user experience is to develop a deep understanding of what is important to your users. We will discuss how Apple has developed this deep understanding and maintained their focus to enable them to deliver amazing products.
What do you think? Is this a talk that you’d attend?
the sysadmin as tinkerer
I’ve spent most of the past four years talking to sysadmins. Sysadmins come in many different varieties. Some sysadmins work by themselves, and they either know enough about everything under their purview or they know how to work a search engine well enough to fake it. Other sysadmins are specialists, and they know one thing backwards and forwards, and they know a lot about what hooks up to their one thing, and they usually know at least something about many other things.
When I’m asked to describe sysadmins, I often describe them as people who are very good at solving problems. I still think that this is true. Now I think it’s the side effect of something more central.
Sysadmins are tinkerers. They might be buttoned-up tinkerers who always have a backup of whatever it is that they’re working on so that they can revert to a known good state. They might be inveterate tinkerers who will have an idea and just try it out, and rely on their tinkering skills to be able to get themselves out of a jam. In either case, they’re tinkering to get it to work better. “Better” can mean anything from using less power to integrating with another application to giving more meaningful alarms.
Sysadmins tinker not just for the satisfaction of tinkering. They tinker to make their lives easier. A friend told me that the best sysadmins are lazy. They don’t want to get woken up in the middle of the night, they don’t want to have to repeat the same thing. They tinker so that they have less to worry about and less work to do.
The form that this tinkering takes can be of many types. It could be learning all of the internals of an application so that they can better integrate it into their infrastructure. It could be scripting so that they can automate something that is important to them, or annoys them, or that they just wish that they didn’t have to do. It could be playing with the latest and greatest technology to see if it really is as great as the hype to see if it meets their needs.
The sysadmin gets an idea and tries out solutions. They tinker with it to see if they can get it right. They poke and prod at it, and try it from different angles, and see what works. They don’t decide on a solution (although they might have a solution decided for them) and go out and read up everything on it and get trained on that solution. They try out the solution to see if it really does fit their needs. If their tinkering results in something really useful, they might invest in something like training, or they might just continue tinkering and figuring it out on their own.
“Invest time in listening to your customers”
I don’t know how I missed this! In February, the Wall Street Journal posted a great article from Braden Kowitz, design partner at Google Ventures, titled Why You Should Listen to the Customer. It contains lots of reasons why you need to conduct user research, and responses to many of the excuses against user research. Here’s the intro:
“How can my company become great at design?” Founders ask me this question more than any other. They’re often considering hiring a hotshot designer or an expensive design agency. And while those might help, neither will bake design deep into how the company operates. Founders need a way to make great design become automatic, and there’s only one way I’ve found to do that reliably: invest time in listening to your customers.
Go read the whole thing, and then come tell me what user research you want to do.