More than anything, I solve problems. And I'm really good at it.

I'm a consultant for a global firm named Sapient where I lead project creative efforts, design, evaluate, and user-test interfaces, craft information architectural solutions, collect and create requirements, publish white papers and articles, participate in proposals, screen and interview job candidates, sporadically provide user experience guidance to solve other people's problems, and I've even bailed out a struggling project or two. I'm spending a great deal of energy building the Gov 2.0 expertise for Sapient's Government Services team as well as fine tuning our approach to user experience.

In my early days, solving problems meant planning print newspaper Metro sections, designing news pages, and creating information graphics. I was the art director for a start-up print magazine and an editor for another.

I designed and coded my first Web site in 1996, managed interactive design and production staffs and influenced the Tribune Co.'s early online efforts. I was washingtonpost.com's first Director of User Experience back when people still laughed at the title. I was PBS Interactive's Director of User Experience as well, but by then people had gotten used to the term.

I spoke at what I thought was a lot of conferences in 2009, but I'm scheduled to do even more this year. I also maintain UX Crank, a blog for user experience professionals specifically, but one that's hopefully useful for other folks as well. If nothing else, some of the articles have pretty pictures.

It's been my experience that many problems come down to our unrealistically high expectations for what are essentially a bunch of bald apes. Hey, the whole primate, opposable thumb thing is just an experiment and it's far from clear whether or not the experiment will be successful.

For example, have you ever noticed how we tend to intertwine The What and The How for any emerging issue? If you ask somebody what's wrong, they'll start telling you how you need to solve the thing. There's smoke coming out of a house? Call 911, get a hose, locate the closest fire hydrant. A project is late? Adjust the schedule, fire somebody.

One thing you can always count on is that as soon as you intertwine The What and The How, you're done talking about The What. But if you've defined the problem poorly and moved onto how you're going to address that problem too early, you'll spend the rest of your time chasing symptoms instead of curing the real disease and the symptoms will never stop coming. The house wasn't on fire, it was a busted toaster; the project was late because the client just laid off the staff that was supposed to use the application you're building.

Another piece of coaching I give myself and just about everybody else I work with is to be selfish. People spend so much energy settling for less than they want, thinking that it'll lead to a greater good. But it almost never does! I find that if people are selfish and explicitly list everything they want and need and if you get all the players to do the same, then the volume and quality of the data you collect gives you the best possible chance for success.