Category Archives: Nadyne

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.

  1. … or two … or more …

“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.

  1. 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?

“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.

on being a role model

Alison Gianotto wrote a great post after she was invited to speak at a Linux conference, and assigned the topic of women in technology.  Since that’s not a topic that she’s interested in talking about, and she has lots of things that she would like to speak about at a Linux conference, she gave some other ideas.  They passed.

The whole post is awesome.  These two paragraphs match my philosophy about speaking at tech conferences:

My position is that the best way for me to be a role model for women (and men) in technology isn’t to give talks about being a woman in technology, but to kick ass and take names at being a technologist, and to give great presentations on technology topics. This is my way of showing men and women in technology that women are as capable and badass as the bros.

It’s the same reason I always agree to speak at conferences even when I know I’m a token. I frequently spend my own money to fly out to speak at conferences that can’t afford to fly me out or cover my hotel, and I do this because it’s important for men and women to get used to seeing women at the podium, demonstrating their skills as an authority in technology. If we can get a few more women on that stage, maybe we won’t feel like such a rarity anymore, and the perceptions of us in technology will shift.

At MacIT 2014, she gave a great talk about security.  She knows her stuff, and she knows how to talk about it in such a way that other people will get it too.  I’m so glad she was one of our speakers, and I’m glad that her talk was a topic that she’s an expert in and that she’s passionate about.

I’m speaking at AltConf, and I need your help

I got great news today.  I’ll be speaking at AltConf.  I haven’t yet decided on how I’m going to approach this one.  Rest assured that you will walk away with a better understanding of how you can create a deep understanding of users to make your application a better one.

I have a request of you, dear audience.  One of the ideas that I have kicking around is using quotes that seem pretty set against user research from Steve Jobs and other Apple execs.  Jobs referenced the apocryphal Henry Ford horses quote quite a lot.  I know that there are others, though.  What other Apple anti-research quotes do you know of?

“a statistical analysis of Bob Ross”

Dear FiveThirtyEight: I love you.  You are the only ones doing awesome analyses such as looking at the 381 paintings done by PBS painter Bob Ross and analyzing his work.  You gain such insights as:

About 18 percent of his paintings feature a cabin. Given that Ross painted a cabin, there’s a 35 percent chance that it’s on a lake, and a 40 percent chance there’s snow on the ground.

This might be the most readable article about conditional probability.  My math degree feels much less lonely tonight.