I was asked the question where a new information architect could get started to learn about the field and I explained that there are experiences all around us that enable all of us to learn. It could be anything from buying speakers for your television to how to book an airline ticket: all of us is uniquely qualified to start as one if we’ve used a computer, and all it takes is just observing how users think and use technology to improve what we have today.

After that explanation, during which her eyes glazed over, the response was, “How about just telling me what books to read.”

Here are five books I like a lot.

Note that none of them (well, one) is written by one of the user experience experts that are most often cited in blogs. There are many authors out there that present equally valid points that should get equal time, and I found these books to be extremely useful and valuable. Most of the books describe the patterns and theory of information architecture and user experience, but a couple of them go into detail about the tools we use to communicate, and how we fit into the software development and web design process.

The last five books I would read if I wanted to learn about information architecture

Why We Buy: The Science Of Shopping

By Paco Underhill, Why We Buy is a great read on the observational study of why people shop, how they shop, and what they buy. Most importantly, it sets the stage for triggers for the motivations of completing an action, which is the basis of all interactive interactions.

This book is not too scientific, but honestly, you can look other places for that; what we’re seeing through the eyes of Paco is the emotions of browsing and shopping in the real world.

Don’t Make Me Think

By Steve Krug, Don’t Make Me Think is the cut-and-dry version of information architecture and the best methods of web navigation. Covered in 216 pages are enough screen shots, design patterns and quick points that just about anyone can get started on building their own websites or improving them dramatically.

What I like most about this book is that Steve doesn’t talk down to the reader like some other specialists, he informs the reader in a very comfortable, friendly tone.

Designing Interfaces

By Jenifer Tidwell, Designing Interfaces most importantly shows exactly what is most important about designing software and web sites: that all applications should follow a very well defined set of a patterns so the user interactions follow exactly what the user expects.

Jenifer’s book goes into excruciating detail of what interface widgets to use when, and why the widget should be used, how to use them, and examples of how the widgets were used in other applications.

Web ReDesign 2.0: Workflow The Works

By Kelly Goto and Emily Cotler, Web ReDesign works through not only examples of wireframes, site maps, and how to quote projects, but looks at the project management process of web development. What I like best is that the book shows exactly how Information Architects, Web Designers, Programmers and the client fit together in an orchestra of what happens before, during and after a site launch.

Kelly and Emily also do a masterful job of including other expert voices and opinions like Christina Wodtke and Lynda Weinman about what it takes to launch a successful and user-friendly website.

Grids for the Internet & Other Digital Media

By Veruschka Götz, Grids is a out-of-print but very valuable publication that goes into amazing detail about the usage of grids for interactive applications (not just the Internet but also for multimedia applications and print design).

The book also covers the lost art of typography, how it should be used in websites, and usage of type on a grid. Even if you aren’t a designer, you’ll appreciate the clear and concise examples displayed in a very modern fashion of this title.

Upload a photo and get a really bad retro picture of yourself in a yearbook.

That’s a hoot.

From NYTimes Via Good Experience:

Netflix, the DVD-by-mail service, largely ceased shipping DVDs to its 8.4 million subscribers for three days this week. The company vaguely blames a technology glitch.

Yet, as a result of the mess — which was resolved earlier Friday — customers are now applauding the company’s honesty. Its stock, as of now, is up on the week, not down. Just imagine if McDonald’s stopped serving burgers for three days.

So what are the lessons for other companies, and for people who follow Netflix’s business?

That saying you’re sorry is okay. Read on…

Other sites that agree:

• Electric Venom
• Hacking Netflix

I’m taking a break from reviewing them this week because I want to offer a few tips that hopefully someone will take note of. Most of the MySpace applications aren’t very good from an usability standpoint, and it’s usually the little things they are missing that separate a good application from a great application. Additionally, the MySpace platform is still a moving target, but the end user doesn’t have to see that.

Don’t be that Johnny Bedroom hack developer that we considered when building the MySpace developer site; think of solutions that would make your application better.

Here are a few tips that might improve the user experience.

Show a loading message when the application is loading

The MySpace platform is sometimes slow, and the end user is subjected to half-loaded pages with arrows in places where there shouldn’t be arrows for navigation. Since it’s all JavaScript, and at the beginning a loading image could be show, why not do that? All it takes is showing a layer at the beginning of the JavaScript call, and hiding that loading layer as soon as the page is built.

We’re talking three lines of code.

Please, don’t you want a better experience for your users for three lines of code?

Test your application

As I have posted previously, nothing frustrates an end user more than an application that doesn’t appear to work, because they think it’s their fault. Test, test, and test again. This is especially true with some of the Flash applications on the platform — most of them have some kind of issue that makes them break.

Consider all the edge cases and build error messages around them

What happens to your application when the connection to the platform breaks, or it returns a malformed result? There should be some code in the JavaScript that considers all error messages that could happen when interacting with the platform, and provide a solution for each one. It doesn’t have to be elegant, but it should hide that there was some kind of issue with the system.

Make the application look good

Most of the applications I’ve seen so far look like the Omaha, Nebraska Greyhound Terminal (don’t ask, I’ve never been there). Hire a designer to work with you, and make the application look better — that will encourage usage, and give legitimacy to the application as a quality product.

There are other ways to encourage the viral spread of the application without sending out bulletins

The MySpace terms of use for the application platform doesn’t allow spamming the users, but that doesn’t mean you can’t reward people for encouraging installs; some of the applications have come up with some unique ideas, like giving out bonuses if over a certain amount of friends have the application installed, or another bonus when someone installs the application from your profile through a link. There are many, many ways to make promoting your application fun without breaking the rules.

One of my pet peeves is when I click on a link, I get sent to page that asks me to sign in. Some sites require it, which I understand, but if they do require it, they should make the process as painless and obvious as possible. Digg.com requires a sign in when you submit a new link for obvious reasons: to validate you are an actual user, and to limit spam.

Keep the options in your face

The vast majority of people that come to the page are new users, but I would guess a good percentage are returning users without the cookie saved. Why ask them to go above when sign in can be placed in line right here? It would take up 50, maybe 60 pixels of vertical space, tops, which is more important than losing a user.

Keep the options obvious and limited

Additionally, where it says Top In All Topics, that encourages leakage, meaning users are going to click there when they can’t figure out how to sign in. Just about every usability test I’ve seen regarding web forms is that the more places the user has to click, the more places they are going to click. there are metrics that show the number of people leaving a page were directly related to the number of links on that page.

Keep the forms simple

This registration form requires 12 pieces of information.

Twelve.

That’s great, if you are marketing cars, but this is an internet news site.

This is way too long, especially when the target audience is bloggers, most of whom don’t want to give up this much information. At the very most, digg should only be asking for the user name, email address, a password, and the CAPTCHA. Everything short of the gender and birthday could be assumed from the IP address to a certain amount of accuracy, and if the users really want to add those two, they can do that later or on a second screen.

When the user signs in or registers, return them to the page they were expecting

When I signed in, was I returned to a page where I could enter information about the article?

No.

I was returned to the home page. I have to return to the blog so auto-capture the article information. Not only does this irritate the user who clicked on the link to Digg, but it also irritates the blog owner (me), because I took the time to place a link on the article to promote my blog.

From The Man In Blue — yeah, this is about right:

This really qualifies as general project and product management, but SharePoint Shelter has a wonderful post about saying no to feature requests using SharePoint.

Some of the reasons that a project manager, in the context of SharePoint, should say no is:

• While this feature will extend our SharePoint environment, it is more of a nice-to-have, and not really a baseline requirement for this project
• The calculated effort requirement by either/both the development or operations staff doesn’t really justify the production of the feature
• The subproject in the terms of the current contract constraints doesn’t procure a practical baseline for reallocation (or allocation) of resources to make it a tangible production.
• While this feature from the development or operations end is awesome, it is something that client doesn’t immediately realize the need for, or will never be noticed by the client
• Holy crap, this doesn’t even qualify because it is so experimental, it isn’t funny (kind of like when a client asked me to build neural networks for forecasting models off SharePoint lists. Probably should have nixed that one).

You have this cool client that has this really great idea, and they want to turn it into a sure thing.

They approach you about joining their start up, and they have money sticking out of their pockets, just waiting to be given to you as a (gasp!) full-time employee where you can enjoy in the fruits of their idea that’s going to stop traffic and replace sliced bread as the next great invention.

As soon as you take off the rose-colored glasses, start ups are not all they are cracked up to be. I’ve been connected to a few of them, and they are your basic kill-your-own, do-it-yourself places where nothing is set up correctly, from the office cubicles down to the process of developing software. If you need structure, this isn’t the environment for it.

Here’s a few things I’ve learned over the years, some of them I learned by turning down jobs, some I learned through painful first hand experience. Start ups can be rewarding, at least what you learn, and maybe financially. Here’s a few tips.

Make Sure They Have Money

Very few businesses make money right away (we’re talking one in a million), so there needs to be some runway time to execute the idea. Whatever money they have, they probably need double to do it right, and most venture capitalists intentionally don’t give start ups enough money just to see how resourceful their management is, or to see how dedicated they are in making the idea work.

Make Sure They Have Money To Pay You

What that means is even if they have a decent sized budget, if they are offering you the low base salary and the high percentage commission or bonus (or a high number of stock options), the start up probably doesn’t have enough money to pay you.

If you do decide to join a start up with a high upside, get whatever agreement you have with them in writing, and pay for a lawyer to review it. Have them poke holes in it, just to make sure that you are going to get rewarded for your time, because you are going to be spending a lot of your time on their idea.

If they offer you something low, and they’re not going to show you a list of what everyone else is making, there’s a good chance they are low-balling you.

Make Sure That There’s A Market For It

There’s nothing worse with coming up with this really great idea, and there’s no market for it. Or they come up with this really great idea, and the market’s too crowded. Or they come up with this great idea, and you have three friends that have worked with start ups that have had the same great idea, and all three of their start ups have failed for the same general season.

Unless you’re Apple (and let me tell you, the idea for the iPod was not original), there are no more original ideas, just a twist or two on existing ideas. Having competitors that are profitable in the market is a good thing, because it proves that the basic idea works, and can make money.

Make Sure The Idea Can Work With A One Percent Penetration Rate

Really, really, really big ideas take really, really, really big bank accounts, so whatever idea they have should be reflected in the amount of money they have to spend. Even if they have the money to spend, there should be some thought put into, “will this idea work with a smaller market penetration rate.” If it can’t, or you don’t think the company can be made profitable if their penetration is half of what they are projecting (and they should be doing some market research, regardless), it’s time to run the other way.

There’s no shame in working for a smaller start up that’s poised to be a double instead of a home run, especially if the team is smaller, and you see a larger portion of the riches.

Make Sure The Team Can Execute

Look at the team you’ll be working with — do you think they can execute? There’s nothing worse than working for a startup that has a few people that just can’t get it done, because that affects everyone’s bottom line. Additionally, most startups have friends of the founders they wanted to give jobs, but aren’t qualified to do those jobs. If you don’t think the team can execute, it’s not the right startup for you. There’s always the good first impression, but be realistic: can they get the job done and ship product?

Make Sure You Share Their Vision

There’s nothing worse than joining a start up, and finding out three weeks in you share a completely different philosophy than the founders. And you know what? No matter how much you are right, it’s their baby, and until the VC’s come in and replace them, it will still be their baby. Like any corporate environment, if you don’t share the vision (read this account of what’s going on over at Facebook), you’re going to be uncomfortable the whole time.

When you’re uncomfortable, it’s worse when you are working 60 hours a week, trust me.

At the end of the day, it’s just a job, maybe one where you can make a lot of money, but the reason they want there is that you can make a lot of money for them, and it will only flow downhill if they value your skills.

User experience isn’t just a one time thing — everytime you use an application or website, they get to know the brand for better or for worse. Bad customer service can also affect user experience.

When something really bad happens (say, your site goes down for hours or days like eBay, Amazon, and MySpace have all experienced), there are three simple rules to follow.

Say you’re sorry

The last thing a customer wants to hear is that it isn’t your fault, especially when it is. Google, one of the largest email providers in the world, had issues with Gmail the other day — and said they were sorry. Like it or not, email for many of us is a very personal experience, and the Gmail Product team acknowledged that.

I had an issue with United Airlines (and Expedia) over a mis-booked ticket. United did a really good job making my life easier and rebooking the ticket so there wasn’t an issue.

Say it in public

Some companies are completely open about some of the issues they are having. Dreamhost had a billing issue earlier this year, and they posted about what happened, and how they were going to fix it. Because of their honesty and candor, I personally like them as one of the better companies out there (and so do many of their companies). Their blog is amazing for company news, and that makes me a happy customer.

MySpace does it all the time. We all know it’s not the most stable platform, but it’s gotten much better over the last few years, and even when there are issues, they publish notices notifying users about the issues with the system, and that it will be fixed soon. MySpace is a bit different because of the informal nature of how they speak to their audience, but they do speak to their audience in language their audience understands, and not some obscure error message.

Say how you’re going to fix it

What Google didn’t do very well was explain what the issue was, which is ironic, because many of the Google users are very technically savvy, and know when they’re being given a line, or something else is being used as an excuse.

All end users want is to be told, “this is how we’re going to make your life easier.” They don’t want excuses of how the weather affected their flight, or why their credit card number was being resold to Indonesians and Romanians. They just don’t want to happen again. You might not be able to prevent it again, but you can take steps to lessen the chance.

Funny as hell. Enough said.

F*** me dead I just opened mine eyes, and lo! I have not updated this since I fell in love. You would not believe that I actually have a life. Jealous much? Don’t be, it was very painful.

I am recuperating with drinking a lot of water, playing The Sims, just generally being a coach to the local soccer team, my day lasts forever from 4:55am to till I fall into bed at midnight. I am so over it. I need a holiday.

I wish one day I will have time to blog again. One day I will find my magic genie! I keep looking, anyway!