[UPDATED] I added the results of the quiz below. Check out those swanky graphs!

I’ve been re-reading one of my go-to UX books, Human Performance Engineering by Dr Robert Bailey.

Particularly, I’ve been focusing on the chapter about assessing the validity of test results. I mean, who doesn’t need a refresher on f testing? The chapter starts off with a bit about “Common Sense” design versus “Fact Finding” design. I asked Dr Bailey if I could reproduce the quiz for fun and he said yes.

So, here we go. Put on your UX vest, your Interaction Design belt, and your Usability britches. No need for your Graphic Design undies as you can see from the illustration below.

Consider the best design to be the one which causes the fewest burns and the least damage.

The Results

71 responses. 59% got it wrong.

The correct answer is #1. While this may not be the absolute “best design evar,” it was the best design of the original study. And for the record, I guessed #2, which is what prompted me to do this quiz in the first place.

Common sense is all well and good, but you shouldn’t rely on it solely. For the 40% that got it right, it either means you have good design sense or you are good at multiple choice guessing.

My takeaway: there’s nothing wrong with guessing, but we should all be testing more often.

* Illustration from Johns Hopkins University Press, © 1959, p. 7.

Embiggen Your Knowledge: How Cromulent Design Would Make The Simpsons Less Funny

View more of my presentations on SlideShare.

Traditionally, people who aren’t your customers are hard to convince to help you make your site better. But we were able to find quite a few people to give good feedback and find areas not only to fix, but to make the site more engaging as well.

I clicked the X in the lower right corner of the screenshot above. Just as I was about to click it I thought, “That&srquo;s an odd place for a Delete button…”

Only, of course, it wasn’t a Delete button. It’s the button you click when you want to tell the good people at Google Voice that their transcription wasn’t helpful.

I know why I clicked it. I was looking for a way to delete a voice mail and that was the first thing I saw that matched my mental model, so to speak. Back to my mistake. It wasn’t really a user error. Well, maybe it was if I could easily recover from it, but I can’t.

There’s no way to deselect a radio button. That’s just not how they function. I know. You know this already. So do most smart people like you and me. And yet…

Radio buttons are very handy, but I don’t think they are useful for a binary choice. At least, not Yes/No.

Better Yes/No

Yes. Makes sense. I’m a great designer. You are, too. This isn’t an earth-shattering design change. But it does allow for a user to recover from a mistake. You can deselect a checkbox.

So consider this a friendly reminder: Radio buttons are for choosing between mutually exclusive… um, choices. But for the most part, they are better suited when the user has to choose between 3 or more things.

My friend & college Matt Wallens asked me a few weeks ago if I was interested in presenting at Interaction10. I said sure, but “What are we going to talk about?”

D’oh!

Somehow, in the time between that question and this post, we found ourselves researching (notice the lack of sarcasm quote marks) by watching hours and hours of The Simpsons.

Here’s the thing: Matt and I both love The Simpsons. Not so much over the last few years, but if you can be a Cubs fan, you can be a Simpsons fan. With all that history, and our zany ability to quote on the spot from the show in the context of any current conversation, we realized there was a wealth of cautionary tales dealing with bad User Experience in every season.

It was honestly more of a problem narrowing down ideas than finding them.

The Session

We’ve titled it: Embiggen Your Knowledge: How Cromulent Design Could Make The Simpsons Less Funny. Below is the session outline. The plan is to introduce each topic with an associated clip from the show, then talk in terms of, “Now what can we learn from Homer’s [insert disastrous idea here].”

The Simpsons has been on TV for 20 years, longer than many of us have been in the User Experience field. Although yellow and limited to four fingers, The Simpsons have been continuously ahead of their time as it relates to UX, by way of poking fun of it by doing things oh-so-wrong. Discover the lessons that The Simspons have taught us about the dangers of bad design, UX practices, and not standing in the way of a t-shirt cannon. This presentation (with lots of room for discussion) features case studies of some of The Simpsons’ questionable techniques.

And yes, we will watch clips from the show!

10 Questions to be Answered:

1. What can go wrong when you let users design your product? (The Homermobile)
2. Why is it important to establish success criteria before a study? (”Is my brother dumber than a hamster?”)
3. How not to behave when you’re “behind the glass”? (What’s Wrong With Itchy & Scratchy?)
4. Why you should understand the problem before paying for a slick solution? (Monorail!)
5. How can you make customers happy by designing a very specific product. (Leftorium)
6. How can you solve a complex problem with a simple solution? (Inanimate Carbon Rod)
7. Why it’s OK to recognize (and go with) a better design. (Soap Box Racer)
8. Can you re-purpose a niche design/product and make it sell? (Springy the Olympic Mascot)
9. How soon should you show your design? (Dr. Homer’s Miracle Spine-o-Cylinder)
10. When should you build and when should you buy? (CompuGlobalHyperMegaNet)

Since it’s a 45 minute session, we’ll crowdsource the list down to a reasonable size in advance of the event.

I encourage you to go to the Interaction10 site and comment on our proposal, even if you aren’t going to attend our talk or the conference. The more feedback we get, the more likely it will be (I hope) that our talk is accepted.

I’ve had a number of Begin Agains since. And in that spirit, I’ve repurposed my site in order to promote myself as a UXer for Hire.

How We Got Here

I spent the last few months trying to find a new job with varying degrees of success: degrees all the way from Almost to Not So Much. As time progressed (it’s only been the summer) I realized I was getting bored. Really bored. So I reached out to a few friends who have their own overflowing work and offered my help.

Within a week I was on a new project. With 4 more projects from various sources in the works. I thought, while it will be tough, especially as the sole income for the fam, being a freelancer really fits the way I like to work.

I like to solve problems. I like to make things work better. I like variety. I like working with different people (sometimes engineers, sometimes marketers). I like challenging problems. I like dropping off and picking up my daughter from the bus stop.

While being an employee certainly brought me many good things like experience, stability, and low-cost insurance it just wasn’t me.

I don’t like having a boss. I don’t like having to be in the office even when I don’t need to be. I don’t like bureaucrats.

Where We Are Going

So. Freelancing. For Hire. Indie. Call it what you want (I’ve been using many terms interchangeably) it means a lot of opportunity, freedom, and challenges. Which is cool. By which I mean both, “Holy Crap!” and “Fun!”

All those aforementioned terms can be pretty vague. So let me tell you what it is I do do. Briefly… User Experience Strategy & Design, Interaction Design, Information Architecture, Usability Testing (remote & in-person), Copy Editing, Business Analysis, Communication Strategy, and, and, and.

All that stuff? Really? Well, as I say on my handsome-picture-of-me-having About page:

I take a “big D” approach to design. Which is to say I think anything that is created goes through a design process; even design processes.

You start with a problem or opportunity and need to create something to fill a perceived gap. How well one perceives a gap usually influences how well one bridges it.

And strangely enough, I’m really good at both perceiving and bridging.

Login required.

Login & account(s) required for access.