Kathy Sierra nails it again in her latest blog post “Presentation Skills Considered Harmful”.  She makes the most awesome point that focusing too much on your presentation skills, and not about why your audience wants to see your presentation, means that you’re focusing on the wrong thing.  Focus on your audience and what they will take away.

It’s hard to pick out one quote, so I’ll go with this paragraph:

When you design for a user experience, you quit focusing on your skills and start focusing on their skills. What experience can you help them have? Can you give them a more powerful perspective? Can you give them a new idea with immediate implementation steps they can’t wait to work on? Can you give them a clear way to finally explain something to others that they’ve been feeling but could not articulate? Can you give them a new tip or trick that has such a high-payoff it feels like a superpower? Can you give them knowledge and insight into a tough topic, so they can have more interesting, high-resolution conversations in the hallway?

You might need to improve your presentation skills or style so that your audience can focus on the important message of the presentation.  She puts it this way: “I am a UI.  Nothing more.  And what’s a key attribute of a good UI?  It disappears.”

There’s already plenty of research out there that says that multi-tasking is a myth, that you’re just context-switching and not actually getting any of your individual tasks done any faster.  New research suggests that it’s actually worse than that: not only does your multi-tasking keep you from getting your stuff done any faster, but it also impedes others from paying attention.

Let’s look at this the context of Anil Dash’s recent strawman-filled diatribe against those who wish people would turn off their mobile devices when they’re at the cinema, in which he says the following:

I hear the arguments the fussy film people are making. They’re all super, uniquely sensitive to light pollution, and the brightness of the screen is incredibly distracting to viewing the screen.

It’s not just people who are “fussy” or who are “super, uniquely sensitive to light pollution”.  It’s distracting, and (as the author of the study I referenced above puts it) disrespectful to your fellow audience members.

I’ve been trying to leave my laptop back in my office when I’m in meetings, unless I’m actively taking notes with the laptop (since I type faster than I write).  This gives me even more reason to do it.

This blog post is amusing and yet accurate: The Difference Between User Experience and User Interface: Subtleties Explained in Cereal.

I mentioned that you could do a quick test of your product by asking your users to describe it to you.  There’s a related but different test of your product that you should do.  Get the senior leaders of your application to describe, in a sentence or two, why people buy your product today.  Make sure they focus on the version of the application that your users are using today, not the version that they’re working on.

Doing this by itself will tell you what your team thinks your app does and why people buy it.  You’ll learn a lot if their answers are similar or disparate.  If their answers are similar,  then you’ve got a great starting point for making design decisions.  If their answers are disparate, then a useful exercise is to understand what the points of commonality are and where the points of disagreement are, and then try to determine how to bring the team into alignment.

If you do this in conjunction with asking the same question of your users, then you can compare the answers of the two groups and make sure that they’re aligned.  If they’re not aligned, then you’ve got the opportunity to help your team better understand what your users actually do, or want to do, with your application.  If they are aligned, then you’re in an awesome position of being able to make an even better product in the future.

This is a very small piece of research that you can conduct, often just in hallway conversations, and is very illuminating.  If I’m working on a product that I’m not familiar with, or with a new team, I’ll often start here to understand the landscape.  It’s quick, it’s easy, and can form the basis of future research efforts.

Kathy Sierra has returned to the world of blogging after a 6-year hiatus, and her first post on her new blog is stellar.  It’s called “Your app makes me fat”, and it’s a fantastic piece about cognitive load — that is, how much brain power you have to put into completing a task.

She talks about how cognitive load not only impacts how our users interact with our applications, but also how it impacts the lives of our users.  It’s a great reminder that our user experience doesn’t stand by itself.  Instead, our user experience is just a part of the day for our users.  We often talk about “death by a thousand paper cuts”, and I think that we forget that those paper cuts still hurt even when our users leave their desks.  After all, who hasn’t gone home after a bad technology day at the office and been unable to focus on anything else because they were so drained by what they’d experienced that day?

It’s a long post, and there’s a lot in there to think about.  Make sure that you’re ready to settle in, read the post, and think about her points.  I know I’m going to have to re-read it at another time when I’ve got more energy to focus on it.

I read a great blog post about cognitive overhead, and it reminded me of one of the simplest pieces of user research you can do on an established product.  I’ll quote the article:

Let people use your product, and then ask them to tell you what it does. They’ll think you are crazy for not knowing already, but what you hear can point to cognitive hurdles you’ve missed.

This is an awesome way to get some fantastic data about how your users see your application.  If their answers surprise you, either because they talk about things that you don’t think are important, or they miss things that you think are essential to your product, then you’ve got some problems that you need to address.