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

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.

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?