Handouts

I need to start off with this mainly because I don’t want it to be overlooked. My main FAIL last night was forgetting to set context around the handouts I made available online. Let us remedy that now…

Both are meant as primers; documents to get you started assessing both what you need to design and did what you design work well. If you download these and decide, “Hey this will be handy,” remember these are not all-inclusive. You will likely find things that don’t apply to you, or things that seem missing. That’s okay.

Task Analysis. This document highlights a number of types of task analysis. I am using these by permission from my good friend Steve Fadden. He used it in a talk he gave at UPA a few years ago and I found it to be a good synopsis of the types of methods you can use to understand what your users need.

Each style of analysis has pros and cons, which are noted, and a decent description of what the method entails. It doesn’t give you a step by step process for carrying out each method, but like I said it’s a primer.

Heuristic Checklist. This is a list of items that should be used with a modicum of salt. They are rules of thumb that have worked for me in the realm of software development. Most of them can be applied to web applications and some can be applied to web sites. Take what applies to what you do and toss the rest. Add on to it if you need.

The Checklist can be used in two basic ways: solo and as a small group. Solo is just you going through an application and seeing to what extent each statement is true. A small group would proceed the same way, but typically would get together after each person has done it on their own to talk about the reasons behind the scores and typically to average or negotiate final scores and priorities.

If you have any questions about these documents or how to use them, please let me know.

The Talk

We estimated between 60 and 70 people came last night, which is great considering the weather wasn’t all that pleasant.

I tried to cover a lot in my hour and I think it went okay. If you attended, you can rate my talk. All constructive feedback is welcome. Seriously! I want to be more usable. :)

While the talk was titled Usability, I covered topics that typically get termed User Research, Business Analysis, Risk Analysis, Change Management, and oblique Simpsons references. While most people think of Usability Testing when they thing of Usability, I believe that most of the skills you learn to assess products or services can be applied to all of those other areas as well. It’s about figuring out What is trying to be done, then How to do it, then How Well that worked.

My motif was doing it right at the beginning will same you a lots of rework at the end. Which when written like that is a totally DUH statement. But I think it bears repeating, and repeating until eventually we all remember to do it on a regular basis.

Self-Assessment

Pro-tip #1: Always start by charming the audience…

It’s funny, but I did something I don’t normally do: as people were coming in and getting settled, I walked around and introduced myself to everyone, thanked them for coming, and gave them my card. Hopefully that made them feel welcome, but to be honest I did it for selfish reasons. I wanted to chill out and stop being so nervous!

I have Stage Fright. Always have. Even in my acting days. The good thing has always been that as soon as I begin my nervousness melts away (mostly). And last night was no exception. I used introducing myself to people as a way to begin before beginning. Plus it was a great way to make a connection with the audience even before that first slide went up.

Overall I think my talk was well structured, and I feel like my presentation style was professional but also “me.” I dropped one F-Bomb. And I’m okay with that. There were some things I flubbed. I had a couple of example stories I told that didn’t seem to come out as well during the talk as they did when I was practicing in my head earlier in the week.

I told the audience to ask questions as I talked. I like that. I get bored as a speaker just seeing eyeballs and only hearing my voice. But I need to remember that when answering a question there’s a difference between having an answer and having an opinion. I was asked a question about inserting Usability into the Agile (or the like) process. I don’t have a good answer for that, but I have an opinion. And I think that came across in my answer.

I liked that I remembered to pause as each new slide displayed. When there’s movement on a big screen the audience is not paying attention to you. I gave them a few seconds to take in the new slide and then started talking about it. Doing this also allowed me to collect my thoughts so it’s a double benefit really.

We broadcast the whole talk on Ustream. I wish I had been able to bring that aspect into the talk. If you watch online, please let me know how that worked so when we do it in the future we can make it better.

I made a mix tape for the talk which I played while people we settling. I liked the effect. It felt like a party with people mingling, eating food, and music playing in the background. I know this won’t work in every setting, but I think it worked well here.

What Did You Think

I really, really hope to get constructive feedback from everyone who attended. As an audience member you have a responsibility and opportunity to make speakers better by teling them what you liked and didn’t like. And I am totally open to that. So… comment here, send me an email, @ me on Twitter, rate me on SpeakerRate.

Above (click the image to embiggen, the image that is. I’m not selling anything here.) please find one info graphic comparison of salsa hotness. See those little chili peppers? They’re telling you something.

We are a two-salsa household. My wife prefers Hot salsa and my daughter and I prefer Medium. We shop at Trader Joe’s (TJs) a lot so it’s easy to grab a jar of Trader Joe’s® Double Roasted Salsa (Medium) and a jar of Trader José’s Hot Chipotle Salsa (Hot, as the name suggests).

Above, the Meduim is on the left and the Hot is on the right. Now, I realise that the graphics used to indicate hotness on each jar are “for illustrative purposes only.” But taking a closer look, as I was wont to do during dinner tonight, you notice that each graphic uses a different scale by which to measure calienteness.

Medium uses 0-7 while Hot uses 0-11. From a scale perspective, their spiciness becomes virtually the same. By taste however, they are not the same. At all. ¡Ai yi yi!

Label Design

While these salsas are not made by TJs, they are made for TJs. As such, and as evidenced by the labels here, TJs has control over how the labels are designed.

Here is an opportunity. You have a category of product (salsa) with different varieties. There is a single identifying characteristic about salsa in which everyone is interested. You have an easily identifiable icon with which to indicate said characteristic.

Why not use a standard graphic?

I am not an aficionado of salsa (or chili peppers), but would the Scoville Scale provide a reference in this case?

Supporting the Decision Making Process

Yes, yes. I am “going off” on salsa label design. But think about all the salsa you’ve ever bought. Go ahead, I’ll wait.

Sometimes you’ll get a Medium and it will burn your tongue off. Other times you go for a Hot and get barely a tingle. It isn’t enough to say Mild, Medium, or Hot (I’m looking at you Indian restaurants!).

That might be enough to get the consumer to the right class of salsa, but if there was a 0-12 scale and the graphic neatly identified a Medium as a 6 (compared to a Medium 5 or 7 let’s say) you’d have a better understanding of just how spicy that fancy-pants Corn Pepper Black Bean Relish Salsa was going to be.

There’s a lot going on in a grocery store. Particularly TJs on a Saturday. Designing your labels to support decision making can help your customer. It would ensure your customers are getting exactly what they want. It could also get your customer to branch out a little and buy 2 different Mediums instead of one. “Matthew! Increase sales, you say? ¡Ai yi yi!”

¡Ai yi yi! indeed.

Do they wonder how the inhabitants of the buildings they’ve worked on changed the space or if the inhabitants have adapted in negative ways?

Here’s my case in point.

Someone here at work, probably walking up the stairs, likely hit or scraped their shoulder on the post that attaches the glass retainer above the stairwell to the wall. My guess is it has happened more than once and someone got fed up and redesigned the post.

If I were the architect or interior designer (not sure whose shoulders this falls on) of this building and I saw this… I’d feel ashamed. In software terms, this is the equivalent of sticky notes on the monitor, or cheat sheets, or… training! Something that had to be made in order to get the user safely around the poorly designed interface.

Post-Launch Assessment

Design is a cyclical process. At least that’s how I view it. And viewing it that way provides me with more work, which equals more money so you should agree with me. :)

It isn’t enough to design something, test it, build it, then launch. If you plan on maintaining what you launch (or your client does) you need to understand how people interact with and use what you’ve made.

That means giving them a few months to use it, then going out and seeing what they’ve done to make things better. Your findings can lead into the next round of requirements for v2. This is why having someone who is good at interviewing people (interaction designers, HCI people, usability specialists, whathaveyou) involved in all aspects of the design and development cycle.

These are the people you can rely on to tell you about the sticky notes, cheat sheets, and tennis balls.

Artifacts

Some of the workarounds I’ve mentioned are artifacts: physical items that help users deal with their everyday world. You won’t find them with a survey, or a remote usability test, or reading tech support tickets.

You have to step into the user’s world and see how they live. If you are in the biz, this is your Contextual Inquiry or Ethnography. But you don’t need fancy names to make a case for getting out into the user’s domain and talking with them.

Yes, it has a cost and it can be high. But it also has a distinct reward: you never know what people are really going to do with your product until you watch them use it. There could be opportunities abound.

Opportunities not only to fix problems you introduced in your design (for you will introduce problems) but gaps you didn’t know were there in the first place that you can fill with future revs or alternate products.

Consider

The next time you deliver a design to a client, or ship a product from your company consider including a free tennis ball for your customer. They probably won’t understand why, but then again you never know when a tennis ball will be handy to have around.