Always one year removed from incompetence

As my wife will happily tell you, I have many, many faults. For example, I am incapable of finding the ketchup in the refrigerator. My wife can talk on the phone, make a craft, help the kids with their homework, and watch Oprah at the same time... I can watch a bad movie for two hours and not notice the house is on fire. My fashion sense has not changed or improved since I discovered jeans and t-shirts in second grade.

And I consistently hold my own opinion in higher regard than it deserves.

On the bright side, I eventually recognize that I was an idiot... it just takes about a year. Then I look back in horror at how incompetent I was. This became a yearly rite of passage for me - marveling at my newfound wisdom compared to the previous year. It was nicely validating for awhile, until I started looking ahead and wondering what I was doing now that I'd be embarrassed about next year. Takes all the fun out of feeling superior to... er, myself.

Looking back over my learning curve to date, one thing that strikes me is that in addition to simply learning through mistakes and casual chaos, I've always worked with a team of user experience professionals, and they are the ones who have helped me grow into the proud, just-beyond-incompetent UXer that I am today. I don't think you can overestimate how important that is - UXers who are isolated on development teams are almost doomed to stagnation, IMO. For those folks, the only way to avoid this fate is the virtual UX team on the internet. Bravo to all the UXers who make the net a vibrant community from which to learn.

Which brings me back to my original point - what am I going to learn over the next year that is going to make me feel incompetent now? I'm not sure (if I knew, I'd just go ahead and learn it now), but it's very likely that I'll learn it from someone on the internet. Not in one place on one day... in a hundred blog posts and comments and articles and research, all providing a tiny piece of the puzzle leading to the next minor epiphany.

I'm looking forward to it. In the meantime, I'll just have to make do with what I've learned so far. And ask my wife to find the ketchup for me.

Is there such a thing as too much technical knowledge?

When I started my career in User Experience, back before it was called User Experience, I proudly avoided becoming too advanced in my technical knowledge of the product I was supporting. There was a perception at the time that if a UXer became a domain expert they'd lose touch with how user's perceive the product (or at least novice users). We even coined a term for when a UXer would get a little too close to the development team -- "going native". If we caught a UXer saying things like, "Well, if users don't understand shell scripts, they shouldn't be using the product", they were quickly admonished for going native.

Obviously every UXer had to have some domain knowledge, but there was a largely unspoken agreement that we should avoid going too far with it. Bear in mind, when it comes to enterprise software, technical domain mastery is very expensive. For example, my first job was working on DB2 on the mainframe... becoming a domain expert could take a decade. But the issue isn't laziness, it was philosophical -- a UXer should be an expert in design and usability methodologies, not in whatever product domain they happen to be supporting. AND not only is domain knowledge not necessary, it could also be dangerous, because it could cause the UXer to not see usability problems that a non-expert would encounter.

I now think I was completely wrong.

Well, not completely wrong. I still believe that many design issues require no domain knowledge to recognize and fix, and most product designs are so bad that a decent UXer can spend many releases just trying to fix standard design problems without ever needing more in-depth knowledge about the product. In other words, I don't need to know anything about a product to point out that the developer's grandiose tabs-within-tabs-within-tabs design might be flawed.

But at some point you start to hit the really tough design decisions. Where the answers are not obvious, and it becomes unreasonable and expensive to always address those questions with "let's run another usability test." This is where the intersection of design abilities and technical domain knowledge becomes truly valuable. The technical architects have the domain knowledge and they care about the users, but they (usually) aren't design experts and unlike the UX professional, they have many competing incentives. The UXer only cares about the user.

I now believe that technical domain knowledge is one of the most important tools in a UXer's toolbox, and should be pursued with vigor.