How I got involved in user experience design

For my entire career as a software and internet product manager and product marketer, I've been a strong proponent for focus on optimizing the user experience.  Here's the story of how it all began.

I majored in English.  My thinking at the time (which turned out to be valid, by the way) was that most people are in jobs that you can't major in, implying that most people are doing something other than their major in college.  So while many of my friends were choosing to major in organic chemistry or electrical engineering, I instead spent four years of my life on something I absolutely loved.

Coming out of college I did have the practical problem of getting a job.  I asked myself, "What salable skills do you have, Tim Callan?"  One obvious answer was writing.  So I hunted around for writing jobs, and eventually I went to work for a small Windows ISV as the documentation department.

My first job was to create all documentation for upcoming product releases.  That meant writing and layout for manuals and quick start guides and creating help systems.  So I had to sit down and explain how to use our powerful but complex products.  Complex and too often counterintuitive.  I found myself writing long explanations to make sense of obscure functions.  I found myself going to great pains to emphasize or highlight a few key product points that would prevent people from getting lost in the weeds of the product's functionality.  I found myself patiently articulating how a certain function actually behaved, as opposed to how you'd expect it to behave.

Let me give you a simple example.  Our flagship product had a calendaring function and one of the things you could do was set alarms that would go off at specific times.  It happens that there were no concepts of noon and midnight in this product.  Rather there were 12:00 am and 12:00 pm.  Now, it wasn't obvious to me which of these meant noon and which meant midnight.  I mentioned this fact to the VP of development, who said, "12:00 am is midnight, of course."  Then I mentioned it to the VP of marketing, who said, "Everybody knows that 12:00 am is noon."  Or vice versa.  I can't really remember, but then that's the point.

I took a quick survey of the employees in our twenty-person company and determined that roughly 50% of us felt that 12:00 am was noon, and 50% felt it was midnight.  In the intervening years I've discussed this topic with plenty of other people, and I can confidently say that there exists no consensus on this matter in our culture.  That make sense, of course, because 12:00 am and 12:00 pm are nonsense words.  The true, meaningful words are noon and midnight.

But this product had an expectation for what these terms meant.  You could type in an alert for 12:00 am (or 12:00 pm) on a certain day, and the program would accept it.  And then somewhere along the line, the alert would go.  But according to my quick and dirty research, 50% of the time this alert would go off at midnight, therefore failing in its function to let you know that it was time for your noon appointment.

It was easy enough to determine which was which.  At 11:55 one day I set a pair of alerts called A and P, set for 12:00 am and 12:00 pm, respectively.  One or the other popped up five minutes later and I wrote that fact in big bold letters in the manual in the hopes that users would see it and notice.  But that seems a backward approach, now doesn't it?  A better approach would be for the machines to work the way the humans expect them to.

That's one pithy example, but this kind of thing was going on all the time.  I had become familiar in college with a concept in psychology they called human factors, and right around this time the software development community was rediscovering it under the name usability.  So I appointed myself usability manager and started proposing how to change the product to be more intuitive to human beings.  I did on-the-cheap testing by walking around with a yellow pad and watching people perform tasks in the product.  As the company grew I developed a department under me and eventually got to the point where I had a full time interface designer working for me.  He was much better at it than I had been.

During that time I postulated Tim Rules of Human-Machine Interactions, which state,

1. Machines are here to serve humans and not the other way around.
2. If humans expect a machine to behave in a certain way, and it behaves differently, then the machine is always wrong.
3. Machines that defy the expectations of the target user are misdesigned, even if the actual creator understands how to use the machine.
4. To the extent it is possible, it is more efficient to create a machine that works as target users expect it to than to educate target users to change their behavior.

In the intervening twenty years usability became user interface and then user experience.  The tools got more sophisticated, with multivariate testing and heat mapping and follow-home studies and discreet choice analysis and so many others.  But these four rules have always served me.  My conviction in them has not wavered, and I continue to use them to this day.