We have a winner for the Trading answers for posts contest.

Congratulations to Natasha Lloyd! (Read the winning post.)

Thanks so much to all who entered. Hopefully, your posts helped get the word out about both books and I’ll be able to write more of them sooner than later. Thank you!

Designers have something in common with doctors.

Even when a person fits the profile for Carpal Tunnel Syndrome, and has identical symptoms as everyone who’s ever had it, the doctor tells the patient he needs a full round of blood work and two different nerve tests.

Why? Because insurance companies want scientific verification that something needs to be treated before they’ll pay for it it. They don’t trust the doctors to make the call—they want proof.

Some companies treat their web and software designers the same way. Instead of trusting even the best designers, managers demand that usability tests be run to surface problems with designs no matter how obvious, get feedback on new ideas no matter how standard, and validate recommendations no matter how basic.

But we all know that a good designer can be right a lot of the time without all that busy work getting in his way. And we all know it costs a lot less money to trust a good designer’s instincts than it does to waste his time in a bunch of usability sessions that will only prove what everyone already knows.

When a design has Carpal Tunnel Syndrome, don’t be afraid to call it Carpal Tunnel Syndrome. Instead, be afraid of wasting a lot of money proving it.

Figure out who the doctors are in your organization, and start trusting them. Save the testing for the things that aren’t obvious.

Yesterday’s contest announcement raised a question from quite a few people: “Why don’t old blog posts about the books count for this contest?”

Is it because I want bigger royalty checks? Is it that I want to be more “famous”?

Nope. I couldn’t care less about the royalty checks. And I don’t need to be more famous than I already am.

I just want to write more books.

To do this, I need to sell more copies of the two I already have out.

See, book buyers (Amazon, B&N, Borders, etc) look at the sales numbers for previous titles by an author when deciding how many copies of a new book to buy. This makes perfect sense, of course, but it means that in order for me to write a new book, I need to sell more of the two I already have.

Designing the Obvious has been selling well (it’s been on the Amazon bestseller list a number of times), but Designing the Moment is still very new and hasn’t yet sold enough copies for my publisher to pitch another new Hoekman book.

To sell more copies of the current books, I need to generate new buzz, hence the rule about old blog posts. I need new blog posts.

So why is it that I’m so desperate to get things moving?

Right now, I’m attempting to work out deals for 3 different books, all of which have the potential to become must-have resources for web professionals for years to come. I’m that confident about all 3 of them.

But I can’t get another solo book published until I sell more copies of the current two.

So, if you’ve read either (or both) of the first two books, and you’d like to read more from me, please …. go tell someone about Designing the Obvious and Designing the Moment right now. The sooner we get the sales numbers we need, the sooner I can get started on the next book. And the next. And the next.

Thanks for understanding.

Got a little blogging contest for you. Here are the rules.

1. Write a blog post that links to the Amazon pages for Designing the Moment or Designing the Obvious.
2. Send me the link to your blog post.

If you win, I’ll do a free, 1-hour Q&A session, by phone, for you and 5 of your closest friends, where you can ask me anything you want.

The contest starts right now (posts written before today don’t count — UPDATE: find out why here) and ends on Tuesday, July 15th at 11:59pm. I’ll notify the winner by email, and we’ll arrange a date and time for the call then.

To choose the winner, I’ll write up the names of everyone who sends me a link to a qualifying blog post on a piece of paper, cut it up, and throw the pieces into a hat, then have an innocent bystander choose a name from the hat.

(Hint! Get your 5 friends to do a blog post as well to increase your group’s odds of being picked.)

Good luck!

Some designers think User-Centered Design (UCD) is a “philosophy”—one to be developed and nurtured throughout an organization, from the ground up.

It’s not.

First, a little perspective on UCD and its friends. UCD, Activity-Centered Design (ACD), Goal-Directed Design (GDD), the unfortunately named “Genius Design” (GD), and others have many things in common, but they also have very real differences. These approaches are defined through their goals and their deliverables. Through their pros and cons. Through their areas of overlap (of which there are many). And through the ways they fit into typical development processes (Agile, for example).

All of these approaches have a common goal—to create valuable, useful, and usable (and hopefully even enjoyable) products and services for customers.

But beyond this commonality, practitioners of each approach take a different path to achieving that goal. With UCD, the design effort is, obviously, centered on users (what they need, what they want, etc). With ACD, the design effort is centered around a user’s whole activity. In GDD, the design effort is centered around a user’s goals. While these approaches have a lot of overlap, the differences are mainly in the practices and deliverables.

With UCD, a practice is to perform user research and a deliverable is a set of persona descriptions. With ACD, a practice is activity research, and a deliverable is a breakdown of the activity’s tasks, actions, and operations. And so on.

On any given project, we can mix and match practices and deliverables quite a bit, and ultimately, it really doesn’t matter to managers how success is achieved or what the approach is used or what it’s called, as long as it is successful and repeatable.

But other departments within a company have different purposes, different methods, different processes and practices and deliverables. Yes, they should still be focused on customers, but they achieve this in very different ways than a designer. The Accounting department, for example, should be very focused on customers, but it would defy logic to use UCD practices in an Accounting department.

Hence, User-Centered Design is not a philosophy. It’s an action. It’s an approach.

So what is the organization-wide philosophy to be developed and nurtured?

“Focus on the customer”.

Simple as that. And it doesn’t matter how you do it, as long as you do it.